Printable View
I hope I word this correctly.
I am running IPcop firewall and I always see a lot of garbage traffic coming from over seas. I see a lot of misc MS-SQL attacks from the same range of IPs. I got tired of seeing them and decided to drop packets from entire continets.
I did "iptables -A INPUT -s 213.0.0.0/8 -j DROP" for a bunch of other ip ranges.
I thought that by droping the packets the IDS would ignore all the attack attempts but it still shows up on the IDS logs.
Is that normal?
I may be wrong but it still has to respond in someway to "drop" the packet.
Is there a log file I can watch to see what get drops?
under /var/logs or somewhere?
will tcpdump show them being dropped?
You shouldn't do it that way....
Either use thresholds (look at threshold.conf), where you can supress a signature either by source or destination IP, make sure you select the last option (in the examples of threshold.conf) to totally supress the signature. This is the easiest way.
The other way is to use a pass rule. Basically, you create a rule the same as you would a normal rule, but make sure it matches whatever you are trying to filter out, so for example:
pass <ip_to_ignore> any -> any 1434 (msg:"Ignore 1434 from X"; sid:15000000;)
You MUST be EXTREMELY careful with pass rules. A poorly written one can cause real stuff to be missed, make sure it matches exactly with the circumstance.
In your case, I'd recommend the threshold...
I'll try that, thanks.
actually there may be something wrong here
im not 100% sure but if your using iptables to drop packets from that class A then you should not be getting any events to your IDS, snort generally uses libpcap which I believe would 'grab' packets higher up in the protocol stack, now if you using snort inline then this pulls packets from the kernel that could be jumped from the INPUT chain as well so it would then be a matter of how your iptables rules are ordered
have you taken a look at your iptables to verify that packets are going to the DROP chain (iptables -vnL)
I did some more investigating today...Quote:
Originally posted here by S3cur|ty4ng31
actually there may be something wrong here
im not 100% sure but if your using iptables to drop packets from that class A then you should not be getting any events to your IDS, snort generally uses libpcap which I believe would 'grab' packets higher up in the protocol stack, now if you using snort inline then this pulls packets from the kernel that could be jumped from the INPUT chain as well so it would then be a matter of how your iptables rules are ordered
have you taken a look at your iptables to verify that packets are going to the DROP chain (iptables -vnL)
Iptables is dropping the packets , but Snort reads the packets before IPtables does on the NIC connected to the internet. I guess how the machine is setup, snort is higher on the kernel stack then iptables.
Snort is reading the garbage attacks coming to the NIC connected to the internet, then Iptables is dropping them. The internal NIC connected to the LAN sees them all being droped, and nothing goes through.
Yes, that is normal if SNORT is on the box with the firewall.Quote:
I thought that by droping the packets the IDS would ignore all the attack attempts but it still shows up on the IDS logs.
Is that normal?
Just to make things clear, in the first question you were talking about what SNORT is logging, in the second you are speaking of firewall logging.Quote:
Is there a log file I can watch to see what get drops?
Many things should be logged as routine. Some things however you may not want to.
This has to be tuned by experience, for what works best for your systems.
If you really want to log them to see if they are being dropped, when you first add a rule such as you did, add a rule before the one you added, then one after into your IPTables:
iptables -A INPUT -s 213.0.0.0/8 -j log --log-level info --log-prefix "213.0.0.0/8 before"
iptables -A INPUT -s 213.0.0.0/8 -j DROP
iptables -A INPUT -s 213.0.0.0/8 -j log --log-level info --log-prefix "213.0.0.0/8 after"
Then check your firewall log.
If you see any with the word before, you know packets from those addresses are reaching your firewall.
If you see any with the word after, something is wrong!
If you see any other reference to that IP block, you probably have the rules in the wrong place.
Once it seems to be working ok and you no longer want to see these in your ( firewall )
log, you can delete the logging rules, keeping the original drop rule.
Then you can set up snort to ignore them too. ( see the snort faq, 3.9 How do I ignore traffic coming from a particular host or hosts? )
Did that make things a little clearer?
Those were the iptables commands I was looking for in my second question.
Thanks
I have another question, I get some alerts that say "(http_inspect) OVERSIZE CHUNK ENCODING"
from my ip going out to port 80.
Can anyone explain to me what that means? I tried searching on the topic but I haven't found much.
I have an answer, but I do not consider myself that proficient in the SNORT rules or the rational behind them ....
I would prefer someone with more knowledge reply.
Maybe I have had too much of the grape, but I could not find how to bump this thread ( even though I tried assigning points to it as we used to be able to,) so I included this in response in hopes it would bring attention to it.
Although henry95's question would be better directed to the SNORT lists, I believe that many here could answer, as it is more a general question ( albeit a little more specific since the packets in question appear to be coming from within. )
Anyone care to take a stab ?
http://www.snort.org/docs/snort_htma...00000000000000
I am assuming this is self explanatory? If not, just search for 'chunked encoding' and read up on it. The documenation on the above page states 'This option is an anomaly detector for abnormally large chunk sizes. This picks up the Apache chunk encoding exploits, and may also alert on HTTP tunneling that uses chunk encoding.'Quote:
chunk encoding alert on chunks larger than 500000 bytes
Thx guys.
henry,
What this means is that you need to make an entry for each of your http servers in your http_inspect_server configuration and tune each line to the specific webserver running at the IP. (IIS + Apache have their own configs, but others need custom tuning)
Check out the examples in your snort.conf.
The alert is coming from an outbound connection. So when I visit that site, the alert comes up. But I know the site is legit, and I just filtered out alerts from it.
I understand what you are saying. The reason you are getting the alerts is because you do not have your http_inspect_server lines set. Therefore the Snort process has to say "ALL traffic in OR out is mine".
If you tell it which is YOURS then it doesn't have to analyze outbound traffic except in web-client.rules.
ahh ok, I'll tinker more with it.
I checked my snort.conf and this is what I have for http_inspect_Server
I added no_alerts just so it would stop showing up in my logs.Code:preprocessor http_inspect: global iis_unicode_map unicode.map 1252
preprocessor http_inspect_server: server default profile all ports { 80 8080 } no_alerts
That's kinda like using a sledgehammer to tap in a nail...
Shutting off all the alerts isn't really the answer, proper tuning is. Your global line should be configured to reflect the majority of the http server present on your network. Then any deviations from that need to have their own lines. (Different ports, different server types).
Shutting off the alerts, yes, gets rid of the alerts and just makes http_inspect normalize traffic, however, you are not seeing some of the benefit of http_inspct, in that it has its own alerting!