Suricata/Snort master SID disablesid.conf



  • Just wanted to share my Snort suppress list. After months of being frustrated with many false positives and snort ultimately blocking them, I have carefully put up this list. A few of them I got from other forum posts like the sensitive data section, so its a mix of everything. I have turned on all categories and now rarely get a false positive (though I do find some once every other week). This is in no ways a perfect list but for me Snort is now less of an annoyance. You might identify some as required and not supposed to be on this list. Please let me know and I will ensure this list gets updated and has the right false positives that can be safely ignored.

    suppress gen_id 1, sig_id 536
    suppress gen_id 1, sig_id 648
    suppress gen_id 1, sig_id 8375
    suppress gen_id 1, sig_id 11192
    suppress gen_id 1, sig_id 12286
    suppress gen_id 1, sig_id 15147
    suppress gen_id 1, sig_id 15306
    suppress gen_id 1, sig_id 15362
    suppress gen_id 1, sig_id 17458
    suppress gen_id 1, sig_id 20583
    suppress gen_id 1, sig_id 2000334
    suppress gen_id 1, sig_id 2010516
    suppress gen_id 1, sig_id 2012088
    suppress gen_id 1, sig_id 2013222
    suppress gen_id 1, sig_id 2014819
    suppress gen_id 1, sig_id 2014520
    suppress gen_id 1, sig_id 2101390
    suppress gen_id 1, sig_id 2103134
    suppress gen_id 1, sig_id 2500056
    suppress gen_id 119, sig_id 2
    suppress gen_id 119, sig_id 4
    suppress gen_id 119, sig_id 14
    suppress gen_id 119, sig_id 31
    suppress gen_id 119, sig_id 32
    suppress gen_id 120, sig_id 2
    suppress gen_id 120, sig_id 3
    suppress gen_id 120, sig_id 4
    suppress gen_id 120, sig_id 6
    suppress gen_id 120, sig_id 8
    suppress gen_id 120, sig_id 9
    suppress gen_id 122, sig_id 19
    suppress gen_id 122, sig_id 21
    suppress gen_id 122, sig_id 22
    suppress gen_id 122, sig_id 23
    suppress gen_id 122, sig_id 26
    suppress gen_id 137, sig_id 1

    Sensitive Data disable

    Credit Card Numbers

    suppress gen_id 138, sig_id 2

    U.S. Social Security Numbers (with dashes)

    suppress gen_id 138, sig_id 3

    U.S. Social Security Numbers (w/out dashes)

    suppress gen_id 138, sig_id 4

    Email Addresses

    suppress gen_id 138, sig_id 5

    U.S. Phone Numbers

    suppress gen_id 138, sig_id 6



  • :D

    Dude this is awesome, I just started using snort, on study purposes, before trying to gather some money with it… And I was getting a hard time with all those false-positives.
    But now that I know what's going on, and how to debug it, I'm feeling more confident.



  • Your most welcome.

    New addition.

    suppress gen_id 1, sig_id 16313



  • Here is what I've compiled so far, added to your list.  I run an ALL unix/BSD/OSX network here with only a single Microsoft OS machine on the network.  (It's the token Winblows machine just in case I need to remember what EPIC FAILURE looks like.)  Therefore if you are running Windows you may not want to suppress a few of these.  I've left some of the documentation lines in-tact to help with identification.  All alerts that were triggered by the rules in this set were verified as false positives.  However you are advised to suppress at your own risk, as your alerts might be real. :-)

    gen_id_1

    suppress gen_id 1, sig_id 536
    #"GPL SHELLCODE x86 NOOP"
    suppress gen_id 1, sig_id 648
    #GPL SHELLCODE x86 0x90 unicode NOOP
    suppress gen_id 1, sig_id 653

    This set of instructions can be used as a NOOP to pad buffers on an x86 architecture machines.

    suppress gen_id 1, sig_id 1390
    suppress gen_id 1, sig_id 2452
    suppress gen_id 1, sig_id 8375

    FILE-IDENTIFY download of executable content -> stops file downloads

    suppress gen_id 1, sig_id 11192
    suppress gen_id 1, sig_id 12286
    suppress gen_id 1, sig_id 15147

    This event indicates that a portable executable file has been downloaded.

    suppress gen_id 1, sig_id 15306
    suppress gen_id 1, sig_id 15362

    FILE-IDENTIFY download of executable content - x-header  -> stops windows download

    suppress gen_id 1, sig_id 16313
    #WEB-CLIENT Microsoft Internet Explorer userdata behavior memory corruption attempt
    suppress gen_id 1, sig_id 16482
    suppress gen_id 1, sig_id 17458
    suppress gen_id 1, sig_id 20583
    suppress gen_id 1, sig_id 23098
    suppress gen_id 1, sig_id 2000334
    #"ET TFTP Outbound TFTP Read Request" – VONAGE
    suppress gen_id 1, sig_id 2008120
    suppress gen_id 1, sig_id 2010516
    suppress gen_id 1, sig_id 2012088
    #ET SHELLCODE Common 0a0a0a0a Heap Spray String
    suppress gen_id 1, sig_id 2012252
    suppress gen_id 1, sig_id 2012758
    suppress gen_id 1, sig_id 2013222
    #ET INFO EXE - OSX Disk Image Download
    suppress gen_id 1, sig_id 2014518
    suppress gen_id 1, sig_id 2014520
    suppress gen_id 1, sig_id 2014819
    #ET INFO PDF Using CCITTFax Filter
    suppress gen_id 1, sig_id 2015561
    suppress gen_id 1, sig_id 2100366
    suppress gen_id 1, sig_id 2100368
    #GPL SHELLCODE x86 stealth NOOP
    suppress gen_id 1, sig_id 2100651
    suppress gen_id 1, sig_id 2101390
    #GPL SHELLCODE x86 0xEB0C NOOP
    suppress gen_id 1, sig_id 2101424
    suppress gen_id 1, sig_id 2102314
    suppress gen_id 1, sig_id 2103134
    suppress gen_id 1, sig_id 2500056
    suppress gen_id 1, sig_id 100000230

    #WEB-CLIENT libpng malformed chunk denial of service attempt
    suppress gen_id 3, sig_id 14772

    #(http_inspect) DOUBLE DECODING ATTACK
    suppress gen_id 119, sig_id 2
    suppress gen_id 119, sig_id 4
    #(http_inspect) NON-RFC DEFINED CHAR
    suppress gen_id 119, sig_id 14
    suppress gen_id 119, sig_id 31
    suppress gen_id 119, sig_id 32

    HTTP Inspect Errors

    suppress gen_id 120, sig_id 2
    suppress gen_id 120, sig_id 3
    suppress gen_id 120, sig_id 4
    suppress gen_id 120, sig_id 6
    suppress gen_id 120, sig_id 8
    suppress gen_id 120, sig_id 9
    suppress gen_id 120, sig_id 10

    suppress gen_id 122, sig_id 19
    suppress gen_id 122, sig_id 21
    suppress gen_id 122, sig_id 22
    suppress gen_id 122, sig_id 23
    suppress gen_id 122, sig_id 26

    #(spp_frag3) Bogus fragmentation packet. Possible BSD attack
    suppress gen_id 123, sig_id 10

    suppress gen_id 137, sig_id 1

    Sensitive Data disable

    Credit Card Numbers

    suppress gen_id 138, sig_id 2

    U.S. Social Security Numbers (with dashes)

    suppress gen_id 138, sig_id 3

    U.S. Social Security Numbers (w/out dashes)

    suppress gen_id 138, sig_id 4

    Email Addresses

    suppress gen_id 138, sig_id 5

    U.S. Phone Numbers

    suppress gen_id 138, sig_id 6

    ==========
    Hope this helps someone out there.

    David



  • Adding this to the list :-)

    #FILE-IDENTIFY Armadillo v1.71 packer file magic detected
    suppress gen_id 1, sig_id 23256



  • Thanks for posting the list.  Really helpful.



  • 2 more..

    #GPL WEB_CLIENT Windows Media Player directory traversal via Content-Disposition attempt
    suppress gen_id 1, sig_id 2103192
    #ET SHELLCODE Possible Call with No Offset TCP Shellcode
    suppress gen_id 1, sig_id 2012086



  • I now have a pretty solid suppress list. Have tested it for a good 8 months.

    suppress gen_id 1, sig_id 536
    suppress gen_id 1, sig_id 648
    suppress gen_id 1, sig_id 653
    suppress gen_id 1, sig_id 1390
    suppress gen_id 1, sig_id 2452
    suppress gen_id 1, sig_id 8375
    suppress gen_id 1, sig_id 11192
    suppress gen_id 1, sig_id 12286
    suppress gen_id 1, sig_id 15147
    suppress gen_id 1, sig_id 15306
    suppress gen_id 1, sig_id 15362
    suppress gen_id 1, sig_id 16313
    suppress gen_id 1, sig_id 16482
    suppress gen_id 1, sig_id 17458
    suppress gen_id 1, sig_id 20583
    suppress gen_id 1, sig_id 23098
    suppress gen_id 1, sig_id 23256
    suppress gen_id 1, sig_id 24889
    suppress gen_id 1, sig_id 2000334
    suppress gen_id 1, sig_id 2000419
    suppress gen_id 1, sig_id 2003195
    suppress gen_id 1, sig_id 2008120
    suppress gen_id 1, sig_id 2008578
    suppress gen_id 1, sig_id 2010516
    suppress gen_id 1, sig_id 2010935
    suppress gen_id 1, sig_id 2010937
    suppress gen_id 1, sig_id 2011716
    suppress gen_id 1, sig_id 2012086
    suppress gen_id 1, sig_id 2012088
    suppress gen_id 1, sig_id 2012141
    suppress gen_id 1, sig_id 2012252
    suppress gen_id 1, sig_id 2012758
    suppress gen_id 1, sig_id 2013222
    suppress gen_id 1, sig_id 2013414
    suppress gen_id 1, sig_id 2014518
    suppress gen_id 1, sig_id 2014520
    suppress gen_id 1, sig_id 2014726
    suppress gen_id 1, sig_id 2014819
    suppress gen_id 1, sig_id 2015561
    suppress gen_id 1, sig_id 2100366
    suppress gen_id 1, sig_id 2100368
    suppress gen_id 1, sig_id 2100651
    suppress gen_id 1, sig_id 2101390
    suppress gen_id 1, sig_id 2101424
    suppress gen_id 1, sig_id 2102314
    suppress gen_id 1, sig_id 2103134
    suppress gen_id 1, sig_id 2103192
    suppress gen_id 1, sig_id 2013504
    suppress gen_id 1, sig_id 2406003
    suppress gen_id 1, sig_id 2406067
    suppress gen_id 1, sig_id 2406069
    suppress gen_id 1, sig_id 2406424
    suppress gen_id 1, sig_id 2500056
    suppress gen_id 1, sig_id 100000230
    suppress gen_id 3, sig_id 14772
    #(http_inspect) DOUBLE DECODING ATTACK
    suppress gen_id 119, sig_id 2
    #(http_inspect) BARE BYTE UNICODE ENCODING
    suppress gen_id 119, sig_id 4
    #(http_inspect) IIS UNICODE CODEPOINT ENCODING
    suppress gen_id 119, sig_id 7
    #(http_inspect) NON-RFC DEFINED CHAR [**]
    suppress gen_id 119, sig_id 14
    #(http_inspect) UNKNOWN METHOD
    suppress gen_id 119, sig_id 31
    #(http_inspect) SIMPLE REQUEST
    suppress gen_id 119, sig_id 32
    #(http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE
    suppress gen_id 120, sig_id 2
    #(http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE
    suppress gen_id 120, sig_id 3
    #(http_inspect) HTTP RESPONSE HAS UTF CHARSET WHICH FAILED TO NORMALIZE
    suppress gen_id 120, sig_id 4
    #(http_inspect) HTTP RESPONSE GZIP DECOMPRESSION FAILED
    suppress gen_id 120, sig_id 6
    #(http_inspect) INVALID CONTENT-LENGTH OR CHUNK SIZE
    suppress gen_id 120, sig_id 8
    #(http_inspect) JAVASCRIPT OBFUSCATION LEVELS EXCEEDS 1
    suppress gen_id 120, sig_id 9

    Unknown

    suppress gen_id 120, sig_id 10
    suppress gen_id 122, sig_id 19
    suppress gen_id 122, sig_id 21
    suppress gen_id 122, sig_id 22
    suppress gen_id 122, sig_id 23
    suppress gen_id 122, sig_id 26
    #(spp_frag3) Bogus fragmentation packet. Possible BSD attack
    suppress gen_id 123, sig_id 10
    #(smtp) Attempted response buffer overflow: 1448 chars
    suppress gen_id 124, sig_id 3
    #(ftp_telnet) Invalid FTP Command
    suppress gen_id 125, sig_id 2
    #(ssp_ssl) Invalid Client HELLO after Server HELLO Detected
    suppress gen_id 137, sig_id 1

    Credit Card Numbers

    suppress gen_id 138, sig_id 2

    U.S. Social Security Numbers (with dashes)

    suppress gen_id 138, sig_id 3

    U.S. Social Security Numbers (w/out dashes)

    suppress gen_id 138, sig_id 4

    Email Addresses

    suppress gen_id 138, sig_id 5

    U.S. Phone Numbers

    suppress gen_id 138, sig_id 6
    #(spp_sip) Maximum dialogs within a session reached
    suppress gen_id 140, sig_id 27
    #(IMAP) Unknown IMAP4 command
    suppress gen_id 141, sig_id 1





  • Being a bit frank here..

    I understand what you are trying to do about saving CPU cycles.. but look at my list.. do you think going in and changing rules for the entire list is really that efficient? Maybe for an Atom or old Celeron based CPU.. but in my view doing this is just waste of time. Processing that list of suppression is not that CPU intensive and honestly a waste of time to go in and change rulesets while setting up pfSense.. especially when you rebuild your box frequently.

    Its not thousands of suppressions .. not even hundreds..



  • Being a bit frank here..
    Everything looks like a nail when all you have is a hammer.

    I stated the correct way of making sure snort is under control. Disable a rule, if you cannot find it (one of the preprocessor rules) use suppression.

    Disclaimer: This is not a personal attack and should not be considered as such. This is my personal opinion and does not necessarily reflect the view of the company I work for, nor any of my colleagues. You are hereby granted the right to use this opinion as you see fit, provided that you do not change and/or modify and/or alter it in any way and/or shape and/or form, including but not limited to removing this disclaimer.

    Maybe for a home network a 1ms latency does not matter. Then again, my opinion is not based on a home network.



  • Even for an enterprise network this procedure impractical for saving 1ms…  15-20ms maybe. But that can be solved easily with faster CPU.

    If u have a hammer don't go hunting for nails just for the sake of using it.



  • I thought this was bsd and not linux? I mean everyone working together instead of against each other? (Comment for all random people reading this:I will never retract that statement, even on my deathbed. Deal with it)

    There are a lot more people out there using older boxes to run pfsense and snort. I'm using a couple of P4s for an enterprise network. Why? Because the brand new 5 year warranty PSU in one of them blew up and the box still works, and it costs 2 times as much as a single box (box does not include PSU). Just making sure I'm not misunderstood here, the motherboards in them are brand new supermicros and cost 35EUR. Did I mention that it was behind a datacenter grade UPS?

    There are certainly a LOT more people out there using Atom boxes. Atoms can be thought like P4s. On prescription medicine, so they work a bit faster, but still they are weak and need to recover from that illness they have before they work a bit faster. Don't get me wrong, they saturate most connections easily.

    There is a small, I'll go ahead and name it 0.1%, of the whole of pfsense ecosystem that is using E3s. And a 0.1% of that 0.1% has access to a >500Mbit connection to put those boxes under any serious stress (yes I know speed is not the limit, it's packets, but this is not a court of law so stop using everything I say against me). I'm still talking about pfsense+snort btw.
    My point? exit through the door, and not through the window, because it's the proper way to exit. It might take a couple of steps longer, but everyone will not think you are mad.

    And now I have to prove my point, which I always hate to do. Since it has already hit the fan, you are already in the snort alerts tab looking to disable/suppress a rule. It takes 5 secs to click on an alert to auto suppress it,1 sec to click on interfaces and depending on the rules active, 15 seconds to restart an interface. Mine take a minute, but I've been known to break snort's pages by having too many rules enabled. Back in alerts.1 sec to figure out where a rule is, 1 sec to click on Interfaces, 2 secs to get to the edit page, and 1 sec to get to the rule page. That's where my method is screwed. It takes 5 whole seconds to render the GPL rules (since that's the starting rule page). Lets disable a rule. It takes 20 secs to disable a rule, apply changes, click interface tab, restart interface (again depends on how many rules you have active).
    Lets sum it up: 21 secs to autosuppress a rule. 30 secs to disable a rule. So far looks like you win. But I always save up an ace just in case. My method makes sure that if someone screws up a rule, snort will start when it autoupdates.

    My final statement: Always disable rules. If you can't find a rule, then suppress it. It might take longer/be a bit trickier, but it's still nothing compared to 16 hours daily monitoring boxes. Learn to do something the right way from the start and be done with it.

    PS.
    Re-reading my post (bad habit, I know, I'm planning to quit any time now) makes me sound like a crazy-haired/raving/demented scientist locked up in a basement somewhere. I'm just trying to get everyone to follow the correct way. The way of the Lo… oh wait  ;D
    If you find it easier to suppress rules, go ahead and suppress them. The difference in speed yes it's too small, but there are other downsides to suppressing a rule as mentioned above. Most of the times you will not notice anything and everyone will be happy. Except me. I'll still think anyone that suppresses before disabling is jumping out the window.  :D

    P-PS
    I WILL NOT retract my linux statement. I am a linux user though, for full disclosure.



  • If someone is using Atoms or P4s then they shouldn't be running Snort on that box.. period.

    For me .. I still go by suppression list as its quicker and I like to make use of my CPU rather then letting it sit idle and just consume power… :P



  • I'm running an atom, 4 snort sensors(using different suppression list) , squid3, traffic shaping, 2 openvpn connections. Everything runs great thru my 30mbit WAN.



  • Yes,  I forgot to add.. number of active snort rules affect your UTM's response/performance. I select the entire list found in the categories section along with GPLv2.

    I had a fully loaded i3 system on VMware but when I changed to a Xeon CPU X5550@2.67GHz the difference in response was like night and day.

    This is based on a non-stop extremely heavy usage of 30+ users on a 50Mbps downlink.



  • Wrote a small book as a reply but then the cookie expired. I'll try to keep it short this time.

    IDS: Detects anomalies in traffic without actually affecting traffic. Actually affecting traffic means you are not using so much power for the IDS processing that starves the rest of the system causing it to drop packets. An example of this is pfsense running snort

    IPS: Intercepts, stores and analyses traffic. More power means faster processing, which comes out as more packets analyzed, which equates to higher bandwidth through the sensor. An example of this is suricata running inline on a separate box/vm and snort running as inline (not recommended).

    With that out of the way, as I said previously, MOST users will not need anything more than a P4/atom for their home connection. No atom out there will choke when running snort for a home connection. Let me restate that to make more sense. NO ATOM OUT THERE WILL CHOKE WHEN RUNNING SNORT FOR A HOME CONNECTION. My lists are not for home usage, since they include rules that only make sense when running servers (eg. no need to analyze traffic destined for an apache server if you have no server listening for that traffic). They can be used though to identify false positives affecting home connections.

    Since I see that you are simply throwing more money as a solution, I'll recommend you run a suricata system in a vm passing traffic to a pfsense vm (NOT running snort), then passing that onto the network. Yes I know the risks running a virtualized gateway, and since you do like to throw even more money into it, run it on a separate box. Better still, set up a loadbalancer just before the upstream switch, load balance across 4 i7 boxes with 768GB RAM each running suricata, then pass on the traffic to pfsense.
    A simple 2 node cluster will not do it for this task. You need at least 5 boxes running CARP to fully utilize all available bandwidth. Don't forget the juniper upstream switch and definitely don't forget the brand new cisco switch downstream. Running CAT6 cables is a guaranteed requirement. Just make sure you use 10Gbit both just after the upstream box (could be a modem) and the downstream network (LAN, DMZ).  It doesn't actually matter if your download/upload speeds are less than that.  I really hope everyone sees the sarcasm in this and I don't get flamed for it.
    "the difference in response was like night and day" makes no sense, since it doesn't matter if you run an atom or a cluster with different geographically diverse datacenters sucking down the entire planet's electricity production and you have developed next generation solar panels because it's still not enough since a) snort still passes traffic through it without affecting it (running on pfsense) and b) snort is not multithreaded.
    Running more sensors can make a small difference if they run on separate cores, but that assumes you are not starving the box and actually allowing it to process regular routing (which can be easily achieved even on a single core box when you implement CPU limits to those sensors).

    Just to keep the discussion going, I'll throw a "period" here.



  • You made no sense.

    I have tested well over 25 diff configs and yes better processor makes a lot of difference while working with snort.  Just coz u r on Atom does not mean its a universal solution. You can load windows 7 on the P4, that does not mean it will fly.

    My previous i3 cpu hosted a vmware esxi hence the performance wasnt that great. Even upgrading to i5 was not upto par as other VMs kinda competed for resources. On just straight i3 pfsense ran great and the cpu never went over 25%, hence I switched to vmware to make use of the cpu resources that were never used.

    atom is nothing compared to i3. Fully loaded snort rules, dansguardian with clamd, squid,  pfblocker and openvpn on atom, I can only imagine the response times.



  • @asterix:

    You made no sense.

    I'll be happy to try and explain what you did not understand in great detail.
    @asterix:

    I have tested well over 25 diff configs and yes better processor makes a lot of difference while working with snort.  Just coz u r on Atom does not mean its a universal solution. You can load windows 7 on the P4, that does not mean it will fly.

    You missed an important part of my post. Snort is NOT multithreaded. Neither is pf. It does NOT matter if you run them both on a dual core cpu, or a 256 core cluster. Performance WILL always be the same, assuming that all cores finish an instruction in the same cycles. Why? They cannot take advantage of the rest of the cores, so you are essentially wasting 254 cores. Windows 7 has nothing to do with our discussion.
    @asterix:

    My previous i3 cpu hosted a vmware esxi hence the performance wasnt that great. Even upgrading to i5 was not upto par as other VMs kinda competed for resources. On just straight i3 pfsense ran great and the cpu never went over 25%, hence I switched to vmware to make use of the cpu resources that were never used.

    "IDS: Detects anomalies in traffic without actually affecting traffic. Actually affecting traffic means you are not using so much power for the IDS processing that starves the rest of the system causing it to drop packets. An example of this is pfsense running snort" the bolded part can also be said if your pfsense vm runs on a host along with other high load VMs. Snort has nothing to do with it, you are just starving the box and not allowing it to route correctly, hence the "performance wasn't that great."
    @asterix:

    atom is nothing compared to i3. Fully loaded snort rules, dansguardian with clamd, squid,  pfblocker and openvpn on atom, I can only imagine the response times.

    Atom, for all intents and purposes of a home router/firewall is EXACTLY the same as an i3.Even fully loaded snort. Notice I do NOT mention any other packages. "dansguardian with clamd, squid,[snip] and openvpn" have nothing to do with our discussion.

    You went off topic twice. That's not a good sign. The topic is pfsense running snort. pfblocker is just a way to add more "rules" to pfsense, that's why I snipped it above. To eliminate any further misunderstandings and save some of my time because I have better things to do than argue on a forum about things I know are correct, we are talking about pfsense running snort, which is an IDS.
    More details on IDS vs IPS:
    IDS: You sit in front of a monitor, watching the output of several CCTV cameras. People pass in front of the cameras without you having to do anything. You notice something strange, pick up the radio and radio to the security personel "guy in the red jacket, pick him up". You in no way affect or interact with all the other persons passing in front of the cameras.
    IPS: You wall off part of the corridor. Even install gates. Each person wishing to pass through has to stop, pass through the metal detector, get his suitcases x-rayed, pass a full body search, then he is allowed to pass. All other persons must wait until he is finished. Unless you use a multithreaded IPS (NOT snort), in which case persons getting frisked=your ability to process them. Again, all other persons must wait in line.

    That said, please do explain based on your 25 configs tested how an IDS affects performance. I'd be more than happy to know how you are managing to affect traffic. AGAIN withOUT you actually starving the box of resources (since that can be misunderstood, executing more processes than your CPU can handle simultaneously (including but not limited to keeping the CPU preoccupied so that it cannot respond to the NIC's polling requests), using more RAM than available causing it to swap out to disk/ssd, having a network issue causing it to drop packets and having to resend them). I'm very interested in how you manage to affect traffic without doing any of that.

    Hammering my point in place: pfsense running snort and pfblocker. Nothing else. No "windows 7", no other VMs running on the same box, no martians in the PCI bus stealing packets. Nothing. pfsense running snort and pfblocker. Everything NOT having a DIRECT relation to how pfsense+snort+pfblocker works is completely off topic and simply wasting everyone's time.



  • My configs have always been fully loaded.. not just snort..but dans (clamd), squid, pfblocker..etc. Atom is not up to handling such packages at higher routing speeds.

    You say "Atom for firewall is exactly the same as an i3"… I rest my case there on your CPU knowledge.

    Please open you own thread for supporting Atom processors instead of hijacking threads.



  • @asterix:

    My configs have always been fully loaded.. not just snort..but dans (clamd), squid, pfblocker..etc. Atom is not up to handling such packages at higher routing speeds.

    @asterix:

    You made no sense.

    I have tested well over 25 diff configs and yes better processor makes a lot of difference while working with snort.  Just coz u r on Atom does not mean its a universal solution. You can load windows 7 on the P4, that does not mean it will fly.

    My previous i3 cpu hosted a vmware esxi hence the performance wasnt that great. Even upgrading to i5 was not upto par as other VMs kinda competed for resources. On just straight i3 pfsense ran great and the cpu never went over 25%, hence I switched to vmware to make use of the cpu resources that were never used.

    atom is nothing compared to i3. Fully loaded snort rules, dansguardian with clamd, squid,  pfblocker and openvpn on atom, I can only imagine the response times.

    No further comments from me.
    @asterix:

    You say "Atom for firewall is exactly the same as an i3"… I rest my case there on your CPU knowledge.

    Please open you own thread for supporting Atom processors instead of hijacking threads.

    @jflsakfja:

    Atom, for all intents and purposes of a home router/firewall is EXACTLY the same as an i3.Even fully loaded snort. Notice I do NOT mention any other packages. "dansguardian with clamd, squid,[snip] and openvpn" have nothing to do with our discussion.

    It takes 200Mbits duplex (that's download+upload) for an Atom to even begin sweating while running snort. As I said, for a >>>>>>HOME<<<<<< connection it's more than enough. It's not the end all be all solution, but for most users stumbling upon this thread in the future and reading this
    @asterix:

    If someone is using Atoms or P4s then they shouldn't be running Snort on that box.. period.

    For me .. I still go by suppression list as its quicker and I like to make use of my CPU rather then letting it sit idle and just consume power… :P

    It has been proven to be wrong. The author has repeatedly refused to acknowledge the fact that low power systems can and do run snort as well as an i3 for a  >>>>>>HOME<<<<<<
    @Cino:

    I'm running an atom, 4 snort sensors(using different suppression list) , squid3, traffic shaping, 2 openvpn connections. Everything runs great thru my 30mbit WAN.

    Atom is not the solution for a "business" type connection (that translates to higher than 200Mbits/s duplex, so that someone doesn't quote me saying that I use it for protecting servers behind a P4 box). I'll try and clarify it better, so that "someone" doesn't mistakenly quote a fraction of that and start insulting me. If you want to use pfsense and snort to protect a couple of servers in a datacenter with high speed connectivity and others depend and use those servers (ie you get paid for them being online), use an i3 system as asterix has said, (and there was a recent post that an i3 system goes up to 4Gbits/s routing, so I'll make a wild guess it's right up there even if snorting) or do what I charge a great deal of money to implement. Proper IPS systems. Snort is not such a system, as I have repeatedly said.
    Many, including the thread author will ask "then why are you using snort?". An IDS system just makes sure that despite all the security precautions you took to secure servers, someone still manages to break in, you get some warning about it. Servers behind that snort box do not rely on it for protection. They have their own security implemented. Even if the snort box was broken into, they cannot island hop in to the servers (read a bit more about island hoping, I'll not explain it here since it is off topic).

    Personally I don't believe I'm hijacking the thread, since I posted the correct way of dealing with snort alerts and almost immediately I got attacked with wrong comments. I tried to correct those comments, only to get nitpicked on things I haven't even said. If someone believes otherwise please report my posts to a moderator and he'll be happy to deal with them.

    To sum it up (and end my contribution to this thread, because frankly I'm starting to get annoyed):
    Always disable rules before suppressing. Speed is not the only pro doing this, it makes sure that even if a rule somehow gets messed up in an update (which is more likely to occur if a rule is FPing a lot because someone is trying to correct it and you have already disabled it until they finish correcting it) then snort will still start after the update. Yes I have seen snort failing to start after a rule update.
    You don't need a lot of "horsepower" (that translates to CPU+RAM) to run snort for a home connection. An atom system consuming 25W (that includes mirrored disks) and costing EUR400 in total (supermicro dual core mobo+RAM+PSU+case+disks) still provides plenty of power to handle 200Mbit/s connections (ie. most HOME connections).
    If you are looking to use snort on a connection with anything higher than that then either use an i3, or use an i3 with a proper IPS system (which provides a LOT more security).



  • Yaawwwwwnnnnnn  ..  ::)

    Here is the most up to date suppression list. Have seen barely any false positives. Feel free to add/update the list..

    suppress gen_id 1, sig_id 536
    suppress gen_id 1, sig_id 648
    suppress gen_id 1, sig_id 653
    suppress gen_id 1, sig_id 1390
    suppress gen_id 1, sig_id 2452
    suppress gen_id 1, sig_id 8375
    suppress gen_id 1, sig_id 11192
    suppress gen_id 1, sig_id 12286
    suppress gen_id 1, sig_id 15147
    suppress gen_id 1, sig_id 15306
    suppress gen_id 1, sig_id 15362
    suppress gen_id 1, sig_id 16313
    suppress gen_id 1, sig_id 16482
    suppress gen_id 1, sig_id 17458
    suppress gen_id 1, sig_id 20583
    suppress gen_id 1, sig_id 23098
    suppress gen_id 1, sig_id 23256
    suppress gen_id 1, sig_id 24889
    suppress gen_id 1, sig_id 2000334
    suppress gen_id 1, sig_id 2000419
    suppress gen_id 1, sig_id 2003195
    suppress gen_id 1, sig_id 2008120
    suppress gen_id 1, sig_id 2008578
    suppress gen_id 1, sig_id 2010516
    suppress gen_id 1, sig_id 2010935
    suppress gen_id 1, sig_id 2010937
    suppress gen_id 1, sig_id 2011716
    suppress gen_id 1, sig_id 2012086
    suppress gen_id 1, sig_id 2012087
    suppress gen_id 1, sig_id 2012088
    suppress gen_id 1, sig_id 2012089
    suppress gen_id 1, sig_id 2012141
    suppress gen_id 1, sig_id 2012252
    suppress gen_id 1, sig_id 2012758
    suppress gen_id 1, sig_id 2013222
    suppress gen_id 1, sig_id 2013414
    suppress gen_id 1, sig_id 2014518
    suppress gen_id 1, sig_id 2014520
    suppress gen_id 1, sig_id 2014726
    suppress gen_id 1, sig_id 2014819
    suppress gen_id 1, sig_id 2015561
    suppress gen_id 1, sig_id 2100366
    suppress gen_id 1, sig_id 2100368
    suppress gen_id 1, sig_id 2100651
    suppress gen_id 1, sig_id 2101390
    suppress gen_id 1, sig_id 2101424
    suppress gen_id 1, sig_id 2102314
    suppress gen_id 1, sig_id 2103134
    suppress gen_id 1, sig_id 2103192
    suppress gen_id 1, sig_id 2013504
    suppress gen_id 1, sig_id 2406003
    suppress gen_id 1, sig_id 2406067
    suppress gen_id 1, sig_id 2406069
    suppress gen_id 1, sig_id 2406424
    suppress gen_id 1, sig_id 2500056
    suppress gen_id 1, sig_id 100000230
    suppress gen_id 3, sig_id 14772
    #(http_inspect) DOUBLE DECODING ATTACK
    suppress gen_id 119, sig_id 2
    #(http_inspect) BARE BYTE UNICODE ENCODING
    suppress gen_id 119, sig_id 4
    #(http_inspect) IIS UNICODE CODEPOINT ENCODING
    suppress gen_id 119, sig_id 7
    #(http_inspect) NON-RFC DEFINED CHAR [**]
    suppress gen_id 119, sig_id 14
    #(http_inspect) UNKNOWN METHOD
    suppress gen_id 119, sig_id 31
    #(http_inspect) SIMPLE REQUEST
    suppress gen_id 119, sig_id 32
    #(http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE
    suppress gen_id 120, sig_id 2
    #(http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE
    suppress gen_id 120, sig_id 3
    #(http_inspect) HTTP RESPONSE HAS UTF CHARSET WHICH FAILED TO NORMALIZE
    suppress gen_id 120, sig_id 4
    #(http_inspect) HTTP RESPONSE GZIP DECOMPRESSION FAILED
    suppress gen_id 120, sig_id 6
    #(http_inspect) INVALID CONTENT-LENGTH OR CHUNK SIZE
    suppress gen_id 120, sig_id 8
    #(http_inspect) JAVASCRIPT OBFUSCATION LEVELS EXCEEDS 1
    suppress gen_id 120, sig_id 9

    Unknown

    suppress gen_id 120, sig_id 10
    suppress gen_id 122, sig_id 19
    suppress gen_id 122, sig_id 21
    suppress gen_id 122, sig_id 22
    suppress gen_id 122, sig_id 23
    suppress gen_id 122, sig_id 26
    #(spp_frag3) Bogus fragmentation packet. Possible BSD attack
    suppress gen_id 123, sig_id 10
    #(smtp) Attempted response buffer overflow: 1448 chars
    suppress gen_id 124, sig_id 3
    #(ftp_telnet) Invalid FTP Command
    suppress gen_id 125, sig_id 2
    #(ssp_ssl) Invalid Client HELLO after Server HELLO Detected
    suppress gen_id 137, sig_id 1

    Credit Card Numbers

    suppress gen_id 138, sig_id 2

    U.S. Social Security Numbers (with dashes)

    suppress gen_id 138, sig_id 3

    U.S. Social Security Numbers (w/out dashes)

    suppress gen_id 138, sig_id 4

    Email Addresses

    suppress gen_id 138, sig_id 5

    U.S. Phone Numbers

    suppress gen_id 138, sig_id 6
    #(spp_sip) Maximum dialogs within a session reached
    suppress gen_id 140, sig_id 27
    #(IMAP) Unknown IMAP4 command
    suppress gen_id 141, sig_id 1



  • Could more people with snort/security experience confirm that this list would not compromise a home network environment.



  • I am using it with snort vrt and emergingthreats pro

    But i wonder what those are for?

    suppress gen_id 1, sig_id 536
    suppress gen_id 1, sig_id 648
    suppress gen_id 1, sig_id 8375
    suppress gen_id 1, sig_id 11192
    suppress gen_id 1, sig_id 12286
    suppress gen_id 1, sig_id 15147
    suppress gen_id 1, sig_id 15306
    suppress gen_id 1, sig_id 15362
    suppress gen_id 1, sig_id 17458
    suppress gen_id 1, sig_id 20583
    suppress gen_id 1, sig_id 2000334
    suppress gen_id 1, sig_id 2010516
    suppress gen_id 1, sig_id 2012088
    suppress gen_id 1, sig_id 2013222
    suppress gen_id 1, sig_id 2014819
    suppress gen_id 1, sig_id 2014520
    suppress gen_id 1, sig_id 2101390
    suppress gen_id 1, sig_id 2103134
    suppress gen_id 1, sig_id 2500056
    suppress gen_id 119, sig_id 2
    suppress gen_id 119, sig_id 4
    suppress gen_id 119, sig_id 14
    suppress gen_id 119, sig_id 31
    suppress gen_id 119, sig_id 32
    suppress gen_id 120, sig_id 2
    suppress gen_id 120, sig_id 3
    suppress gen_id 120, sig_id 4
    suppress gen_id 120, sig_id 6
    suppress gen_id 120, sig_id 8
    suppress gen_id 120, sig_id 9
    suppress gen_id 122, sig_id 19
    suppress gen_id 122, sig_id 21
    suppress gen_id 122, sig_id 22
    suppress gen_id 122, sig_id 23
    suppress gen_id 122, sig_id 26
    suppress gen_id 137, sig_id 1
    

    I like to have a comment  for why this is excluded from the snort.conf alert/block



  • thats alot of suppressions for normal use.


  • Moderator

    I believe that rules should be disabled first before using a suppression. I only use a suppression if I want to configure a rule for a particular IP.

    Pre-Processors (ssp_ssl, spp_sip, spp_gtp, http_inspect, smtp etc…) would also need to be suppressed as needed.

    Either way, Disabling Rules or Suppressing Rules opens up your network to potential harm. I have installed a Full Packet Capture IDS system called "Security Onion" installed immediately behind pfSense so any rules that I have disabled or suppressed can be looked at in more detail.



  • @lindsay:

    I am using it with snort vrt and emergingthreats pro

    But i wonder what those are for?

    suppress gen_id 1, sig_id 536
    suppress gen_id 1, sig_id 648
    suppress gen_id 1, sig_id 8375
    suppress gen_id 1, sig_id 11192
    suppress gen_id 1, sig_id 12286
    suppress gen_id 1, sig_id 15147
    suppress gen_id 1, sig_id 15306
    suppress gen_id 1, sig_id 15362
    suppress gen_id 1, sig_id 17458
    suppress gen_id 1, sig_id 20583
    suppress gen_id 1, sig_id 2000334
    suppress gen_id 1, sig_id 2010516
    suppress gen_id 1, sig_id 2012088
    suppress gen_id 1, sig_id 2013222
    suppress gen_id 1, sig_id 2014819
    suppress gen_id 1, sig_id 2014520
    suppress gen_id 1, sig_id 2101390
    suppress gen_id 1, sig_id 2103134
    suppress gen_id 1, sig_id 2500056
    suppress gen_id 119, sig_id 2
    suppress gen_id 119, sig_id 4
    suppress gen_id 119, sig_id 14
    suppress gen_id 119, sig_id 31
    suppress gen_id 119, sig_id 32
    suppress gen_id 120, sig_id 2
    suppress gen_id 120, sig_id 3
    suppress gen_id 120, sig_id 4
    suppress gen_id 120, sig_id 6
    suppress gen_id 120, sig_id 8
    suppress gen_id 120, sig_id 9
    suppress gen_id 122, sig_id 19
    suppress gen_id 122, sig_id 21
    suppress gen_id 122, sig_id 22
    suppress gen_id 122, sig_id 23
    suppress gen_id 122, sig_id 26
    suppress gen_id 137, sig_id 1
    

    I like to have a comment  for why this is excluded from the snort.conf alert/block

    Do a search on google and you will find them.

    This is a consolidated list from users who have tested and re-tested the alerts and found them to be false positives. If you are feeling insecure by this list then please go ahead and remove them. Do your own testing and add the ones you feel are false positives.



  • I propose to add to the Suppress List this entry:

    #(spp_frag3) Fragmentation overlap
    suppress gen_id 123, sig_id 8

    my internal LAN has some machines that need to connect to a VPN provider (AirVPN): without this entry, the connection to the VPN servers is lost after about 10 minutes.



  • @panz:

    I propose to add to the Suppress List this entry:

    #(spp_frag3) Fragmentation overlap
    suppress gen_id 123, sig_id 8

    my internal LAN has some machines that need to connect to a VPN provider (AirVPN): without this entry, the connection to the VPN servers is lost after about 10 minutes.

    panz:

    There are some customizable settings for the Frag3 preprocessor that could help with your issue without having to disable the rule.  Go to the PREPROCESSORS tab and then scroll down to the Frag3 section.  Click the e icon to edit the default setting.  On the page that opens you will find a fragment overlap limit setting.  Try some other values in there if you want.  You can also create a custom Frag3 configuration just for a particular network subnet or IP address.  To do this, first create an Alias under Firewall…Aliases to identify the VPN.  Now return to the PREPROCESSORS tab and in the Frag3 section click the up-arrow icon to import a defined alias as a new Frag3 engine.  In the dialog that opens, choose the alias you created.  When back on the PREPROCESSORS tab, click the e icon beside the new Frag3 engine entry and edit the settings.

    A number of the preprocessors offer this per-subnet or host customization of key settings.  The HTTP_INSEPCT, FRAG3, STREAM5 and both FTP-TELNET preprocessors can have multiple engines.

    Bill



  • @bmeeks:

    @panz:

    I propose to add to the Suppress List this entry:

    #(spp_frag3) Fragmentation overlap
    suppress gen_id 123, sig_id 8

    my internal LAN has some machines that need to connect to a VPN provider (AirVPN): without this entry, the connection to the VPN servers is lost after about 10 minutes.

    panz:

    […] first create an Alias under Firewall…Aliases to identify the VPN.  Now return to the PREPROCESSORS tab and in the Frag3 section click the up-arrow icon to import a defined alias as a new Frag3 engine.  In the dialog that opens, choose the alias you created.  When back on the PREPROCESSORS tab, click the e icon beside the new Frag3 engine entry and edit the settings.

    Bill

    I'll go to the Alias method + create a new Frag3 engine, as I don't want to touch this setting(s) for the others networks. Now, I have a few questions:

    1. which IP address range am I going to enter as an Alias? Let's say the OpenVPN client on the Windows machine gets an IP address in the 10.4.0.0/16 range.  Is this the correct Alias range or do I need to look at the IP address of the exit node? (that's obviously a public IP).

    2. Have I to repeat the same procedure ( = creating a new Frag3 engine) for both WAN and LAN PREPROCESSORS tab?

    Thank you :)



  • @panz:

    I'll go to the Alias method + create a new Frag3 engine, as I don't want to touch this setting(s) for the others networks. Now, I have a few questions:

    1. which IP address range am I going to enter as an Alias? Let's say the OpenVPN client on the Windows machine gets an IP address in the 10.4.0.0/16 range.  Is this the correct Alias range or do I need to look at the IP address of the exit node? (that's obviously a public IP).

    2. Have I to repeat the same procedure ( = creating a new Frag3 engine) for both WAN and LAN PREPROCESSORS tab?

    Thank you :)

    Frag3 engines (and the other customizable engines) work on the destination IP addresses for the packets.  So look on the ALERTS tab and see what destination IP is associated with those fragmentation overlap alerts.  Create the new Frag3 engine configuration using that IP subnet (or single address) where you have been seeing the blocks inserted.  You would only need to repeat the procedure on the other interface's PREPROCESSORS tab if you wanted the custom configuration there as well.

    Once you get a suitable Frag3 engine created, try unchecking the "detect anomalies" checkbox when editing the settings.  That should stop the alerts on fragmentation overlap.

    Bill



  • @bmeeks:

    […] So look on the ALERTS tab and see what destination IP is associated with those fragmentation overlap alerts.  Create the new Frag3 engine configuration using that IP subnet (or single address) where you have been seeing the blocks inserted.

    Bill,

    The destination IP is always my WAN address (I'm on a ADSL line, so it changes sometimes). Inserting this address seems to me like disabling the Frag3 engine…

    I thought I had to build the Alias inserting the Source: the Source is always an AirVPN exit node IP address and I have a full list of them.



  • @panz:

    @bmeeks:

    […] So look on the ALERTS tab and see what destination IP is associated with those fragmentation overlap alerts.  Create the new Frag3 engine configuration using that IP subnet (or single address) where you have been seeing the blocks inserted.

    Bill,

    The destination IP is always my WAN address (I'm on a ADSL line, so it changes sometimes). Inserting this address seems to me like disabling the Frag3 engine…

    I thought I had to build the Alias inserting the Source: the Source is always an AirVPN exit node IP address and I have a full list of them.

    It's the nature of how the target-configurable engines work within Snort.  They are designed mainly for customizing the protection of public-facing servers, and thus key off the destination IP for inbound packets.  You can try setting up one using an Alias targeted to your AirVPN exit node addresses.  For that particular Frag3 setup, uncheck the "detect anomalies" checkbox and see if the alerts stop.

    In your case, are you getting Alerts on the inbound VPN packets (from your WAN back into the LAN), or on your outbound VPN packets (from the LAN out to the WAN)?  If the former, then the "destination" is most likely your AirVPN node and thus the customized Frag3 engine approach should work for you.

    Bill



  • @bmeeks:

    In your case, are you getting Alerts on the inbound VPN packets (from your WAN back into the LAN), or on your outbound VPN packets (from the LAN out to the WAN)?  If the former, then the "destination" is most likely your AirVPN node and thus the customized Frag3 engine approach should work for you.

    I'm getting the alerts with Source: the AirVPN exit node and Destination: the IP Address of my WAN interface.



  • I'm just getting into playing with snort and this was an interesting thread.  :)  I have a question and I don't know if it's dumb to ask or not but….when you suppress a rule does that mean that further triggers of that rule will no longer be visible?  I know most of the ones in the lists here are false positives but what about if it's a real intrusion?  I guess another question is, if all of these generate so many false positives, why are they including in the rule sets to begin with?  Shouldn't the owners of those updates just remove them since everyone else seems to be doing so?

    LoboTiger



  • @lobotiger:

    I'm just getting into playing with snort and this was an interesting thread.  :)  I have a question and I don't know if it's dumb to ask or not but….when you suppress a rule does that mean that further triggers of that rule will no longer be visible?  I know most of the ones in the lists here are false positives but what about if it's a real intrusion?  I guess another question is, if all of these generate so many false positives, why are they including in the rule sets to begin with?  Shouldn't the owners of those updates just remove them since everyone else seems to be doing so?

    LoboTiger

    The answer to your first question is "yes, when suppressed you no longer get alerts from the rule or preprocessor".  So be sure it really is a false positive before you routinely suppress an alert.

    As for your second question, you have hit upon something that puzzles me as well.  The problem is caused, I believe, by the fact many software packages (servers and clients) do not follow all the various RFC standards to the letter.  Some deviations are due to mistakes or alternate interpretations of the RFC, and some may just be certain vendors trying to "one up or be one better" than their competition by "tweaking" how their software complies with an RFC.  No matter which is the true cause, the result is software than can generate false positives because Snort (and Suricata as well) inspect traffic according to the RFCs (well, most of the time).  There are also bugs from time to time in the detection code for Snort and Suricata.  For example, Snort today has a problem with parts of the SSL handshake (it loses track of the stream and sees client and server HELO messages out of order and then generates an alert).  The Snort VRT is working on fixing this bug.

    Bill



  • Cool, thanks for the answers Bill.

    LoboTiger



  • I share the same concern as lobotiger and I want to try and understand the logic of a master supress list and whether it is good idea to use such a list.

    I'll take one example from the list as posted, this is the first one with a description so I'll use this:

    #(http_inspect) DOUBLE DECODING ATTACK
    suppress gen_id 119, sig_id 2

    Lets assume a 'Double Decoding Attack' is bad and you would want to block that type of traffic.  Lets assume you go to a trusted website and it is blocked by this rule… i.e. a false positive.  Doesn't it make sense to only supress the rule for that specific IP address only?  Why supress the rule as it is listed with no specific IP?  Am I correct in thinking the rule is now supressed for all IP's?  Isn't that a bad thing in the sense that you would now never detect any Double Decoding Attack from any source?

    Can anyone please clarify?


  • Moderator

    The general consensus is to Disable (false positive) rules before adding suppression for False Positives. However, as you said, if the Alert is only generated from a few IPs than its best to use suppression for those particular IPs only.

    What you don't want to do is add a suppression without the "track_by src/dst" in the suppression. So in these cases, using suppression is wasting processing power and its best to disable the rule.

    As Bill Meeks stated above, some alerts are false positive due to non-compliance to RFCs etc.

    For Alerts like HTTP Inspect, you can look at the HTTP Pre-Processor to see if you can tune it to your setup to avoid these false positives.

    Some Alerts can't be disabled by the Rules and the Pre-Processors might not be configurable via the GUI, so for a few alerts, you might need to use Suppression. I believe that with each version of Snort, more of the Pre-Processors are being added, so we have more buttons to play with to help tune it. For Suricata, it has a "Wan App Parser" which you could take a look at or for Stream Alerts, the "Wan Flow/Stream".

    These are Threads in the forum for what people are using as a Baseline for Disabling Rules.

    https://forum.pfsense.org/index.php?topic=78062.0
    https://forum.pfsense.org/index.php?topic=64674.0



  • I had this problem and tuning didn't solve anything; I had to disable the detection :(

    https://forum.pfsense.org/index.php?topic=80068.msg436866#msg436866