Snort - what does this mean?

[ostefan]

Hi guys,

I installed snort on my computer a while ago, and today I decided to take a look in
the snort log-files.

I found this line:

15:13:02.147356 213.66.247.247 > 172.16.0.20: icmp: host 217.209.203.66 unreachable (DF)
15:13:05.371134 213.66.247.247 > 172.16.0.20: icmp: host 217.209.203.66 unreachable (DF)
15:13:11.957263 213.66.247.247 > 172.16.0.20: icmp: host 217.209.203.66 unreachable (DF)

I use NAT on my FW, my internal addresses are 172.16.0.0/24, 213.66.247.247 and
217.209.203.66 are the ones I am curious about.

Does this mean that someone is pinging/probing my computer spoofing the reply address, or something like that?

[ostefan]

Hi guys,

I installed snort on my computer a while ago, and today I decided to take a look in
the snort log-files.

I found this line:

15:13:02.147356 213.66.247.247 > 172.16.0.20: icmp: host 217.209.203.66 unreachable (DF)
15:13:05.371134 213.66.247.247 > 172.16.0.20: icmp: host 217.209.203.66 unreachable (DF)
15:13:11.957263 213.66.247.247 > 172.16.0.20: icmp: host 217.209.203.66 unreachable (DF)

I use NAT on my FW, my internal addresses are 172.16.0.0/24, 213.66.247.247 and
217.209.203.66 are the ones I am curious about.

Does this mean that someone is pinging/probing my computer spoofing the reply address, or something like that?

[aeallison]

I am not positive, but, these IPs could be something it is looking for rather than finding. You probably already have this link, but....

http://www.snort.org/docs/

[aeallison]

I am not positive, but, these IPs could be something it is looking for rather than finding. You probably already have this link, but....

http://www.snort.org/docs/

[slarty]

There is a router whose IP address is 213.66.247.247 which is telling internal host 172.16.0.20 that host 217.209.203.66 is unreachable.

This is presumably as a result of the internal machine trying to contact that IP in some way- for example a web server running there.

unreachable typically means that that IP either is unassigned (there is no route at all there), is temporarily unavailable (for instance the only route there is down), or communication with it is denied by policy (i.e. a firewall)

This is perfectly normal, happens a lot and I'm not sure why snort is logging it. Have you tuned your snort.conf properly?

An IDS is not an install-and-forget piece of software, it requires tuning. A well tuned IDS is a good thing, a badly tuned IDS is useless.

[slarty]

There is a router whose IP address is 213.66.247.247 which is telling internal host 172.16.0.20 that host 217.209.203.66 is unreachable.

This is presumably as a result of the internal machine trying to contact that IP in some way- for example a web server running there.

unreachable typically means that that IP either is unassigned (there is no route at all there), is temporarily unavailable (for instance the only route there is down), or communication with it is denied by policy (i.e. a firewall)

This is perfectly normal, happens a lot and I'm not sure why snort is logging it. Have you tuned your snort.conf properly?

An IDS is not an install-and-forget piece of software, it requires tuning. A well tuned IDS is a good thing, a badly tuned IDS is useless.

[ostefan]

Hi Slarty,

I tried to look at the snort logfile using tethereal instead of tcpdump, and using that tool everything looked okay. Meaning that it was just a host unreachable "thing", just like you said, perfectly normal.

I am pretty new at using Snort, or rather - I haven't looked much at how to tune and setup configuration files and rules, and what's inside the logfiles, but I have been running it for a while. I am just now trying to understand the context of the logfiles, and how to setup and define rulesets.

Thanks!

[ostefan]

Hi Slarty,

I tried to look at the snort logfile using tethereal instead of tcpdump, and using that tool everything looked okay. Meaning that it was just a host unreachable "thing", just like you said, perfectly normal.

I am pretty new at using Snort, or rather - I haven't looked much at how to tune and setup configuration files and rules, and what's inside the logfiles, but I have been running it for a while. I am just now trying to understand the context of the logfiles, and how to setup and define rulesets.

Thanks!

[nebulus200]

Very good points Slarty.

Ostefan, if you will look at the rules directory (there should have been a tarball that when you untar it, it will create a directory (rules under your installation directory), and in that directory are various classifications of attacks/informative type things. This is where you look to turn rules on/off (for example, you might not care that you are getting ICMP unreachables, (i think, not 100% sure on this, I don't use snort very often), there will be something to the effect of an icmp.conf (grep -i icmp rules/* that will tell you for sure), if you don't want a signature there, comment out the line (i think a '#' works, not 100% sure on that either). If you aren't interested in an entire series of rules (for example, maybe the web ones since you aren't running a web server), just move the entire .conf file to the preceding directory).

Anytime you make changes to the configuration file, you will need to restart snort. My suggestion would be to look at the log file, in the log file you will see (usually) a reference to a CVE article, follow the link and read about it (if you don't understand what it is talking about, do a google search, usually more than enough information out there, securityfocus.com is a good place to look, so is cert.org). Based on what the article tells you, decide whether you think it is important or not (or decide if all of the reports you are seeing are false positives), and if so, turn the check off. A false positive would be something that triggers the signature to report that something bad has happened when it really hasn't (yes, there are plenty of poorly written signatures that would cause this to happen). Eventually after much work, you will get a configuration that only reports the very serious problems and doesn't bug you about the things that you should worry about (like the icmp unreachable).

Also, don't forget to periodically check back at snort.org for updated signatures (minimum of every couple of weeks), otherwise you will be missing the attacks that you are most likely to see.

/nebulus

[nebulus200]

Very good points Slarty.

Ostefan, if you will look at the rules directory (there should have been a tarball that when you untar it, it will create a directory (rules under your installation directory), and in that directory are various classifications of attacks/informative type things. This is where you look to turn rules on/off (for example, you might not care that you are getting ICMP unreachables, (i think, not 100% sure on this, I don't use snort very often), there will be something to the effect of an icmp.conf (grep -i icmp rules/* that will tell you for sure), if you don't want a signature there, comment out the line (i think a '#' works, not 100% sure on that either). If you aren't interested in an entire series of rules (for example, maybe the web ones since you aren't running a web server), just move the entire .conf file to the preceding directory).

Anytime you make changes to the configuration file, you will need to restart snort. My suggestion would be to look at the log file, in the log file you will see (usually) a reference to a CVE article, follow the link and read about it (if you don't understand what it is talking about, do a google search, usually more than enough information out there, securityfocus.com is a good place to look, so is cert.org). Based on what the article tells you, decide whether you think it is important or not (or decide if all of the reports you are seeing are false positives), and if so, turn the check off. A false positive would be something that triggers the signature to report that something bad has happened when it really hasn't (yes, there are plenty of poorly written signatures that would cause this to happen). Eventually after much work, you will get a configuration that only reports the very serious problems and doesn't bug you about the things that you should worry about (like the icmp unreachable).

Also, don't forget to periodically check back at snort.org for updated signatures (minimum of every couple of weeks), otherwise you will be missing the attacks that you are most likely to see.

/nebulus

[ostefan]

Thanks nebulus,

You are both absolutely right. I work with security on a daily basis, and I know that computer related security issues are not of the static kind. But, till now my work has been related to working with firewalls and commercial IDS products. I haven't had to worry about how the rules work, and why they work. At least not down to the core. I know a little bit about data packets, icmp, how to use a sniffer, and how to analyze packets (as long as I know what I am looking for). But, when I look in the snort log files I get scared. They are growing fast and furious, and I really do not feel up to try to analyze all the data that's in there.

I have been subscribing the CERT mailing lists for quite some time, and sometimes I even have the energy to read what's in them too. :-)

I took your advice and started to remove rules that are not that important. Rules that fill up the log files with false positives. The # works.

It looks like the rules in Snort are divided up in several priorities that are related to the seriousness of the logged data. (Which of course can be wrong..)

For example:
# config classification:shortname,short description,priority
config classification: icmp-event,Generic ICMP event,3

And it looks like most of the priority 3 rules gathers data that are not important, and I have already commented most of them out of the rule files.

After doing a: grep "Priority: 3" alert | wc -l
I ended up with about 1820 priority 3 alerts of a total 2140.. The alert file is a couple of days old..

I do run a web server, but I guess I do not need to include the rule files that are related to IIS, FrontPage or Cold fusion, since I do not run either of them.

Point taken, thanks.

I guess my goal now will be to try to understand how the rules are built up and how they work, and hopefully I will be able to modify existing rules or write my own.

Thank you for taking your time to answer me. I have a feeling that I will get back to you all with questions that are a bit more challenging.

Ole S.
Oslo/Norway

[ostefan]

Thanks nebulus,

You are both absolutely right. I work with security on a daily basis, and I know that computer related security issues are not of the static kind. But, till now my work has been related to working with firewalls and commercial IDS products. I haven't had to worry about how the rules work, and why they work. At least not down to the core. I know a little bit about data packets, icmp, how to use a sniffer, and how to analyze packets (as long as I know what I am looking for). But, when I look in the snort log files I get scared. They are growing fast and furious, and I really do not feel up to try to analyze all the data that's in there.

I have been subscribing the CERT mailing lists for quite some time, and sometimes I even have the energy to read what's in them too. :-)

I took your advice and started to remove rules that are not that important. Rules that fill up the log files with false positives. The # works.

It looks like the rules in Snort are divided up in several priorities that are related to the seriousness of the logged data. (Which of course can be wrong..)

For example:
# config classification:shortname,short description,priority
config classification: icmp-event,Generic ICMP event,3

And it looks like most of the priority 3 rules gathers data that are not important, and I have already commented most of them out of the rule files.

After doing a: grep "Priority: 3" alert | wc -l
I ended up with about 1820 priority 3 alerts of a total 2140.. The alert file is a couple of days old..

I do run a web server, but I guess I do not need to include the rule files that are related to IIS, FrontPage or Cold fusion, since I do not run either of them.

Point taken, thanks.

I guess my goal now will be to try to understand how the rules are built up and how they work, and hopefully I will be able to modify existing rules or write my own.

Thank you for taking your time to answer me. I have a feeling that I will get back to you all with questions that are a bit more challenging.

Ole S.
Oslo/Norway

[Tiger Shark]

Ostefan: You need to be quite careful which rules you comment out. The most useful thing a NIDS does is warn you that something is coming.... ie. It can show you the reconnaisance phase of an attack if the attacker is a little too "devil may care", which many are. Armed with that info you can simply have the firewall drop all packets from his IP(s).

If you comment out all the rules that don't apply to you you may not see much of "Mr. Nasty's" probes etc. and then the attack may come as a surprise. I agree that you don't want a bunch of false positives and rules that are not significant that are producing falses can be commented out or altered to ignore the host causing them. It does help however to be able to see that "stupid" is sending IIS exploits at your Apache server for example... That tells me that "stupid" hasn't done his homework and "stupid" probably has little chance of getting in. If however you see "Mr. Nasty" Nmapping only the open ports on the available servers you gotta wonder where he got such precise information without showing up in the logs before.... That would make me wanna start blocking and/or packet capturing him..... :)

Just my 2 cents....

[gold eagle]

slarty and nebulus covered this already, so I'll just add that tiger shark does bring up an issue that may need looking into. If your ids is not logging enough info it is not able to warn you. Be astute in its tuning.

[ostefan]

Yes, and I agree with all of you, even though I do not feel that I am capable of telling
what's important and what is not. At least not at that level.

Some of the rules provided with snort seem to be very general, the same rule seem to be
triggered on different types of events, which makes it difficult to know if it is important
or not. Or rather, it is difficult to find that one event in the log files that are important.

Most of the events related to "host, network, port - not reachable" are triggered because you actually cannot connect to a computer somewhere in the world. And there are allot of these
messages in the log files. So, how do I find out if it is important or not?

In my work I am responsible for maintaining a Checkpoint FW-1 4.1 (not NG) that separates the Norwegian police and the Internet, and you can probably imagine that we have allot of "visitors". Every morning when I get to work I get a cup of coffee and sit down to look at FW-1's log files. A tedious and VERY boring job. In a normal day there are around a thousand different port scans from all over the world, and there is little I can do about that. It is not illegal to port scan in Norway, though the largest ISP's does not allow it from their networks. I have a list that tells me what ip-address belongs to which ISP, and if I do find any ip-addresses that belongs to one of them I send a report to their abuse-account.

Port scans are mostly obvious, but there are some guys (and girls) out there that are a bit more patient then the rest. They send a packet once every third hour (or something like that), so they are not easy to spot. It is those guys that worries me.

I have tried various scripts that are made for these types of events, but none of them are
good enough for our purpose. That is why I have started to look at alternatives. Snort is one of them. I have used Snort at home for a while, but until now it has mostly been laying there, unattended.

I need some kind of IDS, preferably something that I can understand, and that works. I have
tried using Puresecure (former Demarc), which use Snort in the bottom. It had a very nice
GUI, and it seemed to be working just fine until I connected (I guess) to many sensors to it.

So, maybe you understand my problem. At my home computer it's not such a big problem. I do not get that many "visitors", and I am capable of going through the log files looking for events that shouldn't be there. But, at work, Well.. A challenge?

Ole S.

[nebulus200]

Fair Points Tiger Shark, indeed, tuning your NIDS does take alot of time and patience and over-tuning it can actually work against you in that you may miss the beginnings of the attack (or miss the attack entirely if you are overzealous in the trimming of rules); however, there eventually reaches a threshold where you are wasting more of your time on wild goose chases (think you have seen 10000 matches on a signature and only a few were midly interesting). At which point, which is worse, missing something in mountains of data or maybe missing a script kiddie who runs M$ attacks against a Unix box...For me it is a hard call, and I try to fall somewhere in the middle of the two, hoping to see who is probing, but also hoping to filter out alot without hurting my ability to detect attacks.

I am wanting to say that the rules in snort are prioritized in how they are reported (sorry, don't have any logs to look at at the moment), but this could be a good indication of how serious they are (either a 1 2 or 3, or maybe it was low, medium, high).

Snort is very very good for the price (free); however, there are other commercially available NIDS out there (be prepared to spend big $$'s). Almost all of the current generation NIDS are very very good at catching moderately to very loud scans; however, at some point (each NID has its own), it will start missing scans because of the pace at which they are occuring. This lays in the reality of how much a NIDS would have to remember in order to detect a port scan (Think of a DSL connection with a fair amount of use over several hours...can be alot of data).

I have been fortunate enough to play aorund with alot of different NIDS, and this is how I would sum it up:

Snort. Good nids, not very scalable, great bargain, quick updates in signatures.
Cisco NetRanger. All around good nids (have started playing around with the integrated NIDS in the pix, but don't have an opinion yet).
ISS RealSecure 7.0. Much improved over its earlier incarnations and ISS has started integrating their product line with other people like NAI (SnifferPro), and are moving along to an interesting product line. Ghastly expensive, pretty scalable.

Now, it sounds to me you are wanting total playback, total accountability. There is only one thing I am aware of right now that can act like that, but hold on to your wallet, I think the base model is around 30000 dollars US. Look into the Niksun Netdetector. Base model can record I think around 80Gb of data, and can allow playback occuring on your network (including normal traffic), I haven't got to play around with this alot, but it looks veeerrrry cool.


Hope this helps some,

/nebulus

[Tiger Shark]

Nebulus: I couldn't agree more with what you say.... I really like snort though.... I use it with PureSecure from Demarc. This helps address the scalability issue IMO. Additionally, it allows me to run HIDs on some machines that are exposed and monitor the availability of network services. I run seven IDS through PureSecure, four of which sniff network segments including outside the firewall, the other three are HIDs on machines that I don't necessarily trust. I tune the rules on each sniffer for appropriateness with regard to it's location. They all report into a central console on my desk. It will alert me by email if things go awry too.

Cost is a great thing with PureSecure too. I work for a non-profit - so it's free.... :D - but it is only US$1500 up front and US$99 for each additional sensor. With the flexibility of Snort as it's back end I find this to be very satisfactory and easier to use/manage than ACID for example.

Of course to add to your points I have to say that relying simply on NIDS/HIDS combination would be a mistake too. I use firewall logs and archive them to CD that capture more detail and some other things than the NIDS is set to look for. I archive the Web Logs too and have full logging set there. Mail logs are also kept for a month or more so I can see anything funny happening there. Then - to assist me I have written a quick database to import all this data from it's different sources, clean it up a bit and then allow me to see a complete picture of an IP's activity over any period I wish. I got fed up of searching the logs from all the different sources.... what can I say..... :)

[nebulus200]

Heh heh, at seven I don't think scalability would be too much of an issue. Demarc is a good front end, I hated when it went commerical, but acid still works pretty well (demarc was much better IMHO). By scalable, I meant try deploying 100+...talk about nightmares...there are some slicker alternatives to NIDS on that scale, just they cost big dollars...

The integration, is that a custom thing you did or did you do it with some product? I have written some perl scripts that go through and grab important things off our firewall logs, but it is far from integrated with our NIDS and other things out there...

Good points again :)

/nebulus

[Tiger Shark]

100+...... EEEEEEK..... I run a nice little 650 w/s WAN in 20+ locations across 3 counties - it's hard enough to get the staff to manage the network let alone roll out 100+ IDS's...... :) If you're gonna work on that scale the $$$$$ are probably worth it by the time you're done.

My "log organizer" is just an Access database that has templates to import the various logfile types I pull and then routines written to dump the extraneous garbage.... It works for me - I got fed up of snooping through half a dozen different logs thinking to myself "I wonder if I've seen that IP in another log?".... It was a pain and I was always certain that missing something was highly likely. So I consolidated them and can run some stats on it like "show me IP's that scan slowly, (1 per > 2 sec)" and such like. That would give me a list and I can click on an IP and see it's entire history from the external IDS, firewall, Internal IDS, server logs, IIS logs etc.