You will develop an intruder tracing agent. The idea is to trace an intruder back to it's source. The first hop is easy - your agent will be given the local and remote address and port of a connection to trace. Your agent then migrates to the remote machine and finds the connection that is the source of the information, and repeats the process. When it gets to a machine where it is unable to find a source connection, it returns to the original machine and reports the source (or even the full discovered path, if you wish.)
Use the D'Agents system to allow your agents to move back along the connection. D'Agents is installed on three machines: blitz.cs, siege.cs, and sweep.cs. You should have access to all of them. You might get get started with some of the tutorials at the D'Agents site. The documentation is also available from that site. You may also need Tcl documentation, in particular exec.
How do you learn about connections? One way is the netstat
command. For example:
blitz% netstat -f inet TCP: IPv4 Local Address Remote Address Swind Send-Q Rwind Recv-Q State -------------------- -------------------- ----- ------ ----- ------ ------- blitz.ssh ballroom.1023 24820 0 24820 0 ESTABLISHED
This shows an X connection - the client is on ballroom, the server is on blitz.
Now we can go to ballroom, and look at the connection:
ballroom% netstat -f inet TCP: IPv4 Local Address Remote Address Swind Send-Q Rwind Recv-Q State -------------------- -------------------- ----- ------ ----- ------ ------- ballroom.1023 blitz.ssh 24820 0 24820 0 ESTABLISHED
The problem is, where does the data coming in to this connection start?
Best would be to trace the connection back to a process, and then look
for other connections from that process, but I'm not
sure how to do this. Another approach uses netstat -v:
ballroom% netstat -v -f inet TCP: IPv4 Local/Remote Address Swind Snext Suna Rwind Rnext Rack Rto Mss State -------------------- ----- -------- -------- ----- -------- -------- ----- ----- ----- ballroom.936 ector.nfsd 8760 00000000 00000000 24820 00000000 00000000 402 1460 ESTABLISHED ballroom.935 blitz.nfsd 24820 00000000 00000000 24820 00000000 00000000 400 1460 ESTABLISHED ballroom.login blitz.936 24820 00000000 00000000 24820 00000000 00000000 515 1460 ESTABLISHED ballroom.933 lucan.nfsd 8760 00000000 00000000 24820 00000000 00000000 401 1460 ESTABLISHED ballroom.1023 blitz.ssh 24820 00000000 00000000 24820 00000000 00000000 425 1460 ESTABLISHED ballroom.42563 blitz.x-server 24820 00000000 00000000 24820 00000000 00000000 486 1460 ESTABLISHED
However, if we run the same command again, we will see a change:
ballroom% netstat -v -f inet TCP: IPv4 Local/Remote Address Swind Snext Suna Rwind Rnext Rack Rto Mss State -------------------- ----- -------- -------- ----- -------- -------- ----- ----- ----- ballroom.936 ector.nfsd 8760 00000000 00000000 24820 00000000 00000000 402 1460 ESTABLISHED ballroom.935 blitz.nfsd 24820 00000000 00000000 24820 00000000 00000000 400 1460 ESTABLISHED ballroom.login blitz.936 24820 00000000 00000000 24820 00000000 00000000 517 1460 ESTABLISHED ballroom.933 lucan.nfsd 8760 00000000 00000000 24820 00000000 00000000 401 1460 ESTABLISHED ballroom.1023 blitz.ssh 24820 00000000 00000000 24820 00000000 00000000 417 1460 ESTABLISHED ballroom.42563 blitz.x-server 24820 00000000 00000000 24820 00000000 00000000 486 1460 ESTABLISHED
Note that the Rto field is changed for two connections:
ballroom.login/blitz.936 and ballroom.1023/blitz.ssh. This is because
both connections were used between the two runs of netstat. Yes, I've
done an rlogin from blitz to ballroom, then an ssh back to blitz.
The use of ballroom as a transit shows up as both connections sending data
in the same interval.
You may need to try this multiple times before your agent is able to narrow it down to a single connection - between two runs of netstat, there are several possibilities. No data may have been sent on the target connection (no change in Rto), multiple connections may have sent data (so you can narrow it down, but not determine which corresponds to the real source), or only the target connection changes (either you've run netstat between the receipt and sending of data, or you've found the source - may want to try a couple of times to make sure.)
You should provide a program or shell script that can be used to call
your agent. This should take two arguments: the source address and port,
and the destination address and port. The format for these arguments
is an IP number and port number (as in netstat -n). For example,
to track the connection in the example at the top of the page, use:
track 128.10.2.22.22 128.10.2.21.1023
In addition to code and the test program described above, please
provide documentation describing what your track
really does. For example, the design I've outlined isn't exactly
``track back to source''. You should describe what your implementation
does, and the limitations it faces in meeting the desired goal.
While email is accepted, the turnin command is preferred (e.g., turnin -c cs603 directoryname).