Page 1 of 2 12 LastLast
Results 1 to 10 of 19

Thread: Snort IDS Question

  1. #1

    Snort IDS Question

    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?

  2. #2
    BANNED
    Join Date
    Nov 2003
    Location
    San Diego
    Posts
    724
    I may be wrong but it still has to respond in someway to "drop" the packet.
    When death sleeps it dreams of you...

  3. #3
    Is there a log file I can watch to see what get drops?

    under /var/logs or somewhere?

    will tcpdump show them being dropped?

  4. #4
    Jaded Network Admin nebulus200's Avatar
    Join Date
    Jun 2002
    Posts
    1,356
    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...
    There is only one constant, one universal, it is the only real truth: causality. Action. Reaction. Cause and effect...There is no escape from it, we are forever slaves to it. Our only hope, our only peace is to understand it, to understand the 'why'. 'Why' is what separates us from them, you from me. 'Why' is the only real social power, without it you are powerless.

    (Merovingian - Matrix Reloaded)

  5. #5
    I'll try that, thanks.

  6. #6
    Senior Member
    Join Date
    Jun 2003
    Posts
    236
    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)
    That which does not kill me makes me stronger -- Friedrich Nietzche

  7. #7
    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)
    I did some more investigating today...

    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.

  8. #8
    Senior Member IKnowNot's Avatar
    Join Date
    Jan 2003
    Posts
    792
    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?
    Yes, that is normal if SNORT is on the box with the firewall.

    Is there a log file I can watch to see what get drops?
    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.

    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?
    " And maddest of all, to see life as it is and not as it should be" --Miguel Cervantes

  9. #9
    Those were the iptables commands I was looking for in my second question.

    Thanks

  10. #10
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •