[Snort-users] How do you know...
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).
More information about the Snort-users