[Snort-users] What am I Protecting Against?
nbachmann at ...9372...
Wed Jun 4 06:25:25 EDT 2003
Roy S. Rapoport wrote:
>Sorry, couldn't come up with something wittier.
>Now that I've got ACID running, I'm attempting to make sure I understand
>what alerts I'm seeing and why I'm seeing them. Obvious, ain't it?
That's the biggest challenge in IDS, so you're right, it's not always
>My goal is to get to the point that I log all things reasonably
>considered intrusions or recon, but to only alert on things that are
>actually threats -- in other words, I don't want to know at 2am that
>someone's trying to compromise my MS SQL Server, since it's running on
>UNIX and isn't MS SQL. Oh, and it's not available to the net :).
There are two schools of thought on this
1) I don't care, my system isn't vulnerable. (what you're saying)
2) My system isn't vulnerable, but why is somebody trying to exploit it?
You see, I'd rather know somebody is trying to exploit Code Red on my
Apache server or chunked encoding on my IIS server, before they get it
straight, you know what I mean? (Hopefully everything is patched,
though! :-) Knowing somebody is casing the establishment is useful for
putting you on hightened alert... if you know it's happening you'll be
more on the look out for patterns that you might dismiss as
coincidences. You do, however, still have to prune alerts for your
environment that are truely false positives (i.e. not someone even
looking to probe you ports) versus false positives in the sense that
you're not vulnerable.
Both methods have advantages and disadvantages. #2 is more time
consuming and leads to information overload. However, if you're well
trained and pragmatic, you'll stand a much higher chance of catching the
bad guy before he makes swiss cheese of your network.
>So I'm trying to figure out what some rules are actually trying to
>protect me against; sometimes, there are references to actual docs that
>make this obvious; sometimes, the rule documentation covers it.
>However, some rules are still undocumented. So for example, I give you
>alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC robots.txt access"; flow:to_server,established; uricontent:"/robots.txt"; nocase; reference:nessus,10302; classtype:web-application-activity; sid:1852; rev:3;)
>As I see it, this alerts you of any attempts by anyone to access
>/robots.txt on your HTTP server.
>So hey, maybe I'm an idiot, but why? Trying to get /robots.txt is a
>simple part of any search engine that spiders your site. _I_ don't see
>it as a security issue at all. Am I missing something?
These are alerts that just need to be pruned or used as part of a bigger
strategy. Say you find a suspicious IP that seems to be scanning you
and probing for unpached vulnerabilites. You can use robots.txt as part
of a corallary... they're port scanning, they're looking for the files
you don't want indexed (like private pages, good hacker food). The idea
of this rule is not to show you a major security event, but to give you
a better picture of what's happening.
>And, more generally, is there a way to find out, essentially, what the
>rule writer was thinking when they came up with the rule?
Being cynical and paranoid.
Nicholas Bachmann, SSCP
Davison Community Schools
More information about the Snort-users