synsniff v1.0 - a TCP SYN connection logger (c) 1996, 1998 James Abendschan http://www.jammed.com/ Original code: 29 March 1996 Last update: 15 April 1998 (boo, taxes) Background ---------- In 1996 I was a sysadmin at a university. Since we were pretty exposed (no firewalls, no packet filters), I had to have my machines nailed down tight. While tools like tcpwrappers told me of failed connections to listening services, I wanted to listen to the network on a lower level to know if people were probing my network or my non-unix systems. Towards this end, I wrote synsniff. synsniff, as the name would imply, is a simple program which watches for the first part of a TCP connection (the SYN packet) and logs it. Optionally, synsniff can detect FIN (end of session) packets with no corrosponding SYN; this is useful for discovering stealth FIN scans. Ideally, it sits watching the local network for connections destined for the local network originating from outside the local network. When it sees connections, it logs them, either via stdout or to syslog. synsniff also has rudimentary portscan detection. How well this works is really debateable, but it seemed silly not to include it. The portscan rule is "if I see x number of packets to or from the same host within a second, I'm going to complain." Of course, Mr. Intruder can just set a 1 or 2 second delay between each probe (but that would be really slow, and synsniff will still log the connections. A future project of mine is to do post-scan analysis of the logfiles to detect slow or spread portscans [e.g., attacker probes tcp port 1 on your entire network, and then port 2, and then port 3.. etc.]) synsniff serves as a very rudimentary IDS (Intrusion Detection System). Required Programs ----------------- * Perl 5. http://www.perl.com/ * tcpdump. ftp://ftp.ee.lbl.gov/tcpdump.tar.Z * Some flavour of UNIX (tested under Linux and Solaris) Suggested Usage --------------- To monitor your class C network 192.0.2.0: unix# synsniff -net 192.0.2 To monitor the same network, but log the results to the syslog: unix# synsniff -net 192.0.2 -s To *not* attempt to resolve hostnames from IPs (this is reccomended; intruders can munge DNS to return all sorts of worthless information): unix# synsniff -net 192.0.2 -n To not pay attention to IMAP probes (though why would you want to?!) unix# synsniff -net 192.0.2 -i 143 To watch for connections originating from mailhub.noodle.org: unix# synsniff -net 192.0.2 -srchost mailhub.noodle.org To watch for people running nmap -U on your network (FIN scanning), try: unix# synsniff -net 192.0.2 -f To watch for connections destined for either nntp.jammed.com or mailhub.jammed.com on any port except 119 and 25: unix# synsniff -net 192.0.2 -i 119 -i 25 -dsthost nntp.jammed.com -dsthost mailhub.jammed.com To ask for help: unix# synsniff -help I'd recommend you grab a good portscanner such as Fyodor's nmap (http://www.dhp.com/~fyodor/nmap/) to see what portscans look like to synsniff (and to your hosts :-) Sample output: -------------- A telnet from kadath to avalon. Note that the 3-way handshake has been initiated, indicating avalon responded to kadath's telnet request. 04/15 01:04:51 S kadath.jammed.com:16496 -> avalon.jammed.com:23 04/15 01:04:51 S avalon.jammed.com:23 -> kadath.jammed.com:16496 A NNTP request from gate to avalon. Again, avalon responded. 04/15 01:05:41 S gate.jammed.com:16423 -> avalon.jammed.com:119 04/15 01:05:41 S avalon.jammed.com:119 -> gate.jammed.com:16423 A NNTP request from kadath to nimue. Note that nimue doesn't respond -- it's not running a listener on port 119. 04/15 01:05:52 S kadath.jammed.com:16499 -> nimue.jammed.com:119 An "ordinary" port scan (using connect()) from kadath to avalon, scanning ports 1-10. Note the response on ports 7 and 9. 04/15 01:12:06 S kadath.jammed.com:16502 -> avalon.jammed.com:1 04/15 01:12:06 S kadath.jammed.com:16503 -> avalon.jammed.com:2 04/15 01:12:06 S kadath.jammed.com:16504 -> avalon.jammed.com:3 04/15 01:12:06 S kadath.jammed.com:16505 -> avalon.jammed.com:4 04/15 01:12:06 S kadath.jammed.com:16506 -> avalon.jammed.com:5 04/15 01:12:06 S kadath.jammed.com:16507 -> avalon.jammed.com:6 04/15 01:12:06 S kadath.jammed.com:16508 -> avalon.jammed.com:7 04/15 01:12:06 S kadath.jammed.com:16509 -> avalon.jammed.com:8 portscan-s portscan-d 04/15 01:12:06 S kadath.jammed.com:16510 -> avalon.jammed.com:9 04/15 01:12:06 S avalon.jammed.com:7 -> kadath.jammed.com:16508 04/15 01:12:06 S kadath.jammed.com:16511 -> avalon.jammed.com:10 04/15 01:12:06 S avalon.jammed.com:9 -> kadath.jammed.com:16510 A SYN-style "stealth" style port scan. Note that there is no response from avalon, except on the listening ports. Mmm, sneaky. 04/15 01:14:07 S kadath.jammed.com:49724 -> avalon.jammed.com:1 04/15 01:14:07 S kadath.jammed.com:49724 -> avalon.jammed.com:2 04/15 01:14:07 S kadath.jammed.com:49724 -> avalon.jammed.com:3 04/15 01:14:07 S kadath.jammed.com:49724 -> avalon.jammed.com:4 04/15 01:14:07 S kadath.jammed.com:49724 -> avalon.jammed.com:5 04/15 01:14:07 S kadath.jammed.com:49724 -> avalon.jammed.com:6 04/15 01:14:07 S kadath.jammed.com:49724 -> avalon.jammed.com:7 04/15 01:14:07 S avalon.jammed.com:7 -> kadath.jammed.com:49724 04/15 01:14:07 S kadath.jammed.com:49724 -> avalon.jammed.com:8 04/15 01:14:07 S kadath.jammed.com:49724 -> avalon.jammed.com:9 portscan-s portscan-d 04/15 01:14:07 S avalon.jammed.com:9 -> kadath.jammed.com:49724 04/15 01:14:07 S kadath.jammed.com:49724 -> avalon.jammed.com:10 A FIN-style stealth scan from kadath to avalon. Note the odd pattern after port 10-- ports 7 and 9 (echo and discard) are listening on avalon. !FIN is synsniff complaining "Hey, I saw an end-of-session without first seeing a beginning-of-session!") 04/15 01:10:39 F kadath.jammed.com:49724 -> avalon.jammed.com:1 !FIN 04/15 01:10:39 F kadath.jammed.com:49724 -> avalon.jammed.com:2 !FIN 04/15 01:10:39 F kadath.jammed.com:49724 -> avalon.jammed.com:3 !FIN 04/15 01:10:39 F kadath.jammed.com:49724 -> avalon.jammed.com:4 !FIN 04/15 01:10:39 F kadath.jammed.com:49724 -> avalon.jammed.com:5 !FIN 04/15 01:10:39 F kadath.jammed.com:49724 -> avalon.jammed.com:6 !FIN 04/15 01:10:39 F kadath.jammed.com:49724 -> avalon.jammed.com:7 !FIN 04/15 01:10:39 F kadath.jammed.com:49724 -> avalon.jammed.com:8 portscan-s portscan-d !FIN 04/15 01:10:39 F kadath.jammed.com:49724 -> avalon.jammed.com:9 !FIN 04/15 01:10:39 F kadath.jammed.com:49724 -> avalon.jammed.com:10 !FIN 04/15 01:10:41 F kadath.jammed.com:49724 -> avalon.jammed.com:7 !FIN 04/15 01:10:41 F kadath.jammed.com:49724 -> avalon.jammed.com:9 !FIN 04/15 01:10:42 F kadath.jammed.com:49724 -> avalon.jammed.com:7 !FIN 04/15 01:10:42 F kadath.jammed.com:49724 -> avalon.jammed.com:9 !FIN Pointing netscape at www.whitehouse.gov. Note the unexpected FIN packet; For reasons I don't fully understand, I've noticed that occasionally duplicate FINs will crop up. 04/15 01:16:57 S nimue.jammed.com:21913 -> www2.whitehouse.gov:80 04/15 01:16:59 S www2.whitehouse.gov:80 -> nimue.jammed.com:21913 04/15 01:17:06 S nimue.jammed.com:21976 -> www2.whitehouse.gov:80 04/15 01:17:08 F www2.whitehouse.gov:80 -> nimue.jammed.com:21913 !FIN 04/15 01:17:08 S www2.whitehouse.gov:80 -> nimue.jammed.com:21976 Bugs: ----- * synsniff cannot monitor a PPP connection. (This is actually a limitation of tcpdump. Try this sometime: tcpdump -i ppp0 port 23 and then telnet to a host on the other side of your PPP link. I think the VJ stuff confuses tcpdump..) * The FIN-detector uses hostnames for its hash. Fix this so it's just IPs, james.. * FIN detection requires that synsniff learn about existing connections; If you telnet to a host, start up synsniff, and then disconnect from the host, synsniff will generate a !FIN. Furthermore, if you fire up synsniff, telnet to a host, stay connected for a few days, and then disconnect, synsniff will generate a !FIN message. This is because in the interest of memory usage, synsniff will prune its list of established connections, removing any connections that are older than 1 day. Modify the $hashage variable if this bothers you. (Technically, I should be watching *all* tcp traffic, and learning about existing sessions through PSH packets as well, but tcpdump will chew an enormous amount of resources watching a busy network. Really, this feature is designed to detect FIN-style stealth probes.) * If you have problems running the program, make sure tcpdump is in the path, and make sure you're root. * Hardcore IDS people will probably want to visit http://www.nfr.net/