[Snort-users] How do you know...

Andreas Östling andreaso at ...236...
Sat Jun 9 07:54:47 EDT 2001

On Fri, 8 Jun 2001, Colin Wu wrote:
> Over the past few days we have received a number of scans and each time
> Snort picks it up just fine.  My questions is: Other than going over the
> log line-by-line, how can I tell if a system on my network answered the
> probe and is now a candidate for compromise.  My network is a /16 so
> it's not a small problem.  I'm thinking it may mean writing my own log
> scanner but just wanted to check with you folks in case someone's
> already invented the wheel.

If you mean that you quickly just want to find out how certain hosts
reacted to a regular SYN scan/sweep that hit your entire /16 and you
didn't have a Snort rule watching for outgoing SYN+ACK packets from that
port for example (those rules may not be too funny on a busy /16), it's
great to run a network session logger such as Argus

This is how the output from Argus may look like if the host 'scanner'
probes your x.y.z network for open rootshells on good old 1524/TCP for

22:13:45  tcp  scanner.2729  <|  x.y.z.214.1524  RST
22:13:45  tcp  scanner.2452  <|  x.y.z.134.1524  RST
22:13:45  tcp  scanner.2824  <|   x.y.z.27.1524  RST
22:13:45  tcp  scanner.2782  <|  x.y.z.240.1524  RST
22:13:45  tcp  scanner.2799  <|    x.y.z.2.1524  RST
22:13:45  tcp  scanner.2811  <|   x.y.z.14.1524  RST
22:13:46  tcp  scanner.3232  <-> x.y.z.123.1524  EST
22:13:47  tcp  scanner.2792  <|  x.y.z.250.1524  RST
22:13:47  tcp  scanner.2981  <|  x.y.z.134.1524  RST

Oops, all hosts except one answered back with a reset.
The entry on 23:13:46 tells there was an established connection between
scanner and x.y.z.123 to port 1524/TCP, so it might be worth checking that
host out. If you then see a couple of file transfers from
ftp.technotronic.com and some outgoing IRC traffic, it may be time to get
just a little bit more suspicious :)

This is an great tool to run together with Snort if you want to find out
what happened before, during and after a suspicious event.
(Combining this with Snort's new "tag" feature will make things even

It's also a good idea, where possible, to use/write Snort rules that looks
out for replies from hosts that indicate they are vulnerable to some
probe/exploit. Sometimes you're not so interested to know that Subseven
probe number 48 of the day just hit every single machine on your network,
but you're more interested in which hosts that actually responded to it.
Whatching for replies is sometimes even more valuable than watching for
requests (but you should obviously look for both).

Andreas Östling

More information about the Snort-users mailing list