Suricata/Snort Kills Data Streaming
-
We need to see the blocked tab list in Snort.
Otherwise its guess work.
-
Sorry for the late reply everyone I got stuck doing some business travel. So here is what i found. Turning off the "block " function and clearing the block list made the problem go away. Looking at the alert list I see a gigashitton of errors saying things like "packet out of window", packet time incorrect" and one more I don't remember now from my desk at work. My current set up is i am using a media bridge to connect to my buildings WIFI and running the Ethernet cable from the media bridge to my pFsense box.
Any ideas why so many errors? Do i have too many rules enabled? Do I have a messed up configuration with my media bridge? right now my suricata implementation's only use is to fill logs with those three errors so i don't really think its helping me much…
-
Disable the stream-events.rules via SID Mgmt. (Yeah, I mean the whole category. Zillions of FPs.)
-
Disable the stream-events.rules via SID Mgmt. (Yeah, I mean the whole category. Zillions of FPs.)
I second that motion! That whole category seems to be a waste of time IMHO.
Bill
-
The stream engine works quite good when inline tho ;) Maybe…maybe one day...we will see it inline on pfsense !!!
And for pfsense in copy packet acquisition, its also helps to set the same state/flow timeouts on the pfsense and suricata.
F.
-
Disable the stream-events.rules via SID Mgmt. (Yeah, I mean the whole category. Zillions of FPs.)
How do you do that, Dok? Could I see an example of your file?
Thank you ;D
-
Edit the disablesid-sample.conf, delete everything there, put a line with
stream-events.rules
there, save under a different filename, like - disablesid.conf. Assign that file to interfaces from the "Disable SID File" dropdown menu, tick the Rebuild checkbox, save.
@Mr.:
Could I see an example of your file?
disablesid.conf
########################## ### Suricata Overrides ### ########################## ### decoder-events.rules FPs # Loads of noise, DNS and others 1:2200038 # SURICATA UDP packet too small # Messes up some DNS traffic 1:2200070 # SURICATA FRAG IPv4 Fragmentation overlap 1:2200072 # SURICATA FRAG IPv6 Fragmentation overlap # Messes up with DNS resolution on LAN 1:2200073 # SURICATA IPv4 invalid checksum # Bittorrent noise, DNS 1:2200075 # SURICATA UDPv4 invalid checksum 1:2200078 # SURICATA UDPv6 invalid checksum # Lots of useless noise 1:2200076 # SURICATA ICMPv4 invalid checksum 1:2200079 # SURICATA ICMPv6 invalid checksum # Messes with IPv6 DNS resolution with some DNS servers 1:2200080 # SURICATA IPv6 useless Fragment extension header ### dns-events.rules FPs # DNS Servers FPs 1:2240001 # SURICATA DNS Unsollicited response 1:2240002 # SURICATA DNS malformed request data 1:2240003 # SURICATA DNS malformed response data ### http-events.rules FPs # breaks Windows updates 1:2221000 # SURICATA HTTP unknown error # http://www.bundesfinanzministerium.de 1:2221021 # SURICATA HTTP response header invalid ### stream-events.rules FPs # disable all, way too many FPs stream-events.rules ### tls-events.rules FPs # Random FPs (e.g. Yahoo) 1:2230002 # SURICATA TLS invalid record type # breaks Viber 1:2230003 # SURICATA TLS invalid handshake message ########################## ########################## ### ET Open Overrides ### ########################## ### emerging-dns.rules # generic unwanted rules 1:2012811 # ET DNS DNS Query to a .tk domain - Likely Hostile 1:2018438 # ET DNS DNS Query for vpnoverdns - indicates DNS tunnelling # FPs with Bittorrent peers using port 53 1:2014703 # ET DNS Non-DNS or Non-Compliant DNS traffic on DNS port Reserved Bit Set - Likely Kazy 1:2014701 # ET DNS Non-DNS or Non-Compliant DNS traffic on DNS port Opcode 6 or 7 set - Likely Kazy ### emerging-scan.rules # FPs with Total Commander SFTP, PuTTY etc. 1:2003068 # ET SCAN Potential SSH Scan OUTBOUND # FPs with RDP automatic reconnect 1:2013479 # ET SCAN Behavioral Unusually fast Terminal Server Traffic, Potential Scan or Infection (Outbound) ### emerging-shellcode.rules # Fires up when syncing debian mirror 1:2012086 # ET SHELLCODE Possible Call with No Offset TCP Shellcode 1:2012088 # ET SHELLCODE Possible Call with No Offset TCP Shellcode 1:2012252 # ET SHELLCODE Common 0a0a0a0a Heap Spray String 1:2013319 # ET SHELLCODE Unicode UTF-8 Heap Spray Attempt # Dangerous rule based on cleartext HTTP. Fires up on known good sites when repeated occurences of *heap* is encountered. 1:2013222 # ET SHELLCODE Excessive Use of HeapLib Objects Likely Malicious Heap Spray Attempt ### emerging-web_client.rules # generic unwanted rules 1:2011507 # ET WEB_CLIENT PDF With Embedded File 1:2010514 # ET WEB_CLIENT Possible HTTP 401 XSS Attempt (External Source) 1:2010516 # ET WEB_CLIENT Possible HTTP 403 XSS Attempt (External Source) 1:2010518 # ET WEB_CLIENT Possible HTTP 404 XSS Attempt (External Source) 1:2010520 # ET WEB_CLIENT Possible HTTP 405 XSS Attempt (External Source) 1:2010522 # ET WEB_CLIENT Possible HTTP 406 XSS Attempt (External Source) 1:2010525 # ET WEB_CLIENT Possible HTTP 500 XSS Attempt (External Source) 1:2010527 # ET WEB_CLIENT Possible HTTP 503 XSS Attempt (External Source) # fires up when downloading zipped drivers 1:2012266 # ET WEB_CLIENT Hex Obfuscation of unescape % Encoding 1:2012272 # ET WEB_CLIENT Hex Obfuscation of eval % Encoding 1:2012398 # ET WEB_CLIENT Hex Obfuscation of replace Javascript Function % Encoding ### emerging-web_server.rules # generic unwanted rules 1:2101201 # GPL WEB_SERVER 403 Forbidden 1:2101852 # GPL WEB_SERVER robots.txt access 1:2016672 # ET WEB_SERVER SQL Errors in HTTP 200 Response (error in your SQL syntax) ##########################
Also, some suppress stuff for the automagically enabled flowbits (This goes to the Suppress tab, not SIG Mgmt!)
## -- This rule manually suppressed from the Auto-Flowbits list. -- ## # ET POLICY PE EXE or DLL Windows file download suppress gen_id 1, sig_id 2000419 ## -- This rule manually suppressed from the Auto-Flowbits list. -- ## # ET POLICY ASProtect/ASPack Packed Binary suppress gen_id 1, sig_id 2008575 ## -- This rule manually suppressed from the Auto-Flowbits list. -- ## # ET POLICY PE EXE or DLL Windows file download HTTP suppress gen_id 1, sig_id 2018959 ## -- This rule manually suppressed from the Auto-Flowbits list. -- ## # ET POLICY Executable and linking format (ELF) file download suppress gen_id 1, sig_id 2000418 ## -- This rule manually suppressed from the Auto-Flowbits list. -- ## # ET POLICY Executable and linking format (ELF) file download Over HTTP suppress gen_id 1, sig_id 2019240 ## -- This rule manually suppressed from the Auto-Flowbits list. -- ## # ET CHAT IRC USER command suppress gen_id 1, sig_id 2002023 ## -- This rule manually suppressed from the Auto-Flowbits list. -- ## # ET CHAT IRC NICK command suppress gen_id 1, sig_id 2002024 ## -- This rule manually suppressed from the Auto-Flowbits list. -- ## # ET CHAT IRC JOIN command suppress gen_id 1, sig_id 2002025 ## -- This rule manually suppressed from the Auto-Flowbits list. -- ## # ET CHAT IRC PRIVMSG command suppress gen_id 1, sig_id 2002026 ## -- This rule manually suppressed from the Auto-Flowbits list. -- ## # ET CHAT IRC PING command suppress gen_id 1, sig_id 2002027 ## -- This rule manually suppressed from the Auto-Flowbits list. -- ## # ET CHAT IRC PONG response suppress gen_id 1, sig_id 2002028 ## -- This rule manually suppressed from the Auto-Flowbits list. -- ## # ET POLICY Vulnerable Java Version 1.8.x Detected suppress gen_id 1, sig_id 2019401 ## -- This rule manually suppressed from the Auto-Flowbits list. -- ## # ET POLICY Vulnerable Java Version 1.7.x Detected suppress gen_id 1, sig_id 2014297 ## -- This rule manually suppressed from the Auto-Flowbits list. -- ## # FILE-IDENTIFY Portable Executable binary file magic detected suppress gen_id 1, sig_id 23725
-
Is there a functional difference between disabling the stream rules this way, instead of the interface's WAN Rules tab?
-
Yeah. The difference is many hours of time spared waiting for disable - live reload - disable - live reload - disable - live reload… because the "$iface Rules" GUI is just not fit for mass disable. Desperately missing checkboxes on the left side for marking multiple rules.
-
suppress stuff for the automagically enabled flowbits (This goes to the Suppress tab, not SIG Mgmt!)
I put the troublesome ET POLICY rules generated from the Flowbits Autorules in the disableSID tab and it seems to work fine. I am not using a suppress file. Under Services/Suricata/Edit Interface Settings - LAN, the Alert Suppression and Filtering file is set to "default".
I am running:
pfSense 2.3.3-RELEASE-p1 (amd64)
Suticata 3.1.2_2Is there a reason to put the Flowbit Autorules under suppress instead of disableSID?
-
suppress stuff for the automagically enabled flowbits (This goes to the Suppress tab, not SIG Mgmt!)
I put the troublesome ET POLICY rules generated from the Flowbits Autorules in the disableSID tab and it seems to work fine. I am not using a suppress file. Under Services/Suricata/Edit Interface Settings - LAN, the Alert Suppression and Filtering file is set to "default".
I am running:
pfSense 2.3.3-RELEASE-p1 (amd64)
Suticata 3.1.2_2Is there a reason to put the Flowbit Autorules under suppress instead of disableSID?
You need to do a little research on Google about flowbits and the role they play in Snort. They are triggers that other rules can depend on. Think of them as similar to dependency DLLs in a Windows application. If you don't have the dependency DLLs, the application may not work correctly. If you do some research on flowbits and what they do in Snort, you can answer your question.
Generally speaking it would be better to suppress the alerts from flowbit signatures. The ET folks are notorious for not using the "noalert" option with their flowbit rules. The Snort VRT folks are pretty meticulous about adding the "noalert" option to their flowbit rules. The "noalert" option will suppress the alert from a flowbit rule but still set the corresponding flowbit. Adding the ET Policy rules that are firing for you to a suppress list will accomplish the same thing as if the ET writers had included "noalert".
Bill
-
Hmm, when I go to automatic flowbit rules, I have nothing there. Whats the deal here? I use Snort VRT & ET Open Rules.
-
Hmm, when I go to automatic flowbit rules, I have nothing there. Whats the deal here? I use Snort VRT & ET Open Rules.
Whether or not auto-flowbit rules get enabled is based upon the particular rules you have enabled. Some rule categories do not have any flowbit dependencies. For example, there are rule categories that can detect malicious PDF files. However, those signatures depend on flowbits being set whenever Snort detects a PDF file is transiting the IDS. The signatures that look for malicious PDF content don't fire unless one of the "we are processing a PDF file" flowbits is set. This is a way to prevent false positives. For instance, assume that in a GIF or JPG some bit pattern may be totally benign, but in a PDF that same bit pattern indicates a malicious payload is present. You don't want the PDF malicious payload signature to fire on the GIF or JPG, but you do want it to fire on a PDF. So that's what dependent flowbits are all about. When the file type detection signatures sense a PDF is coming through (by reading the PDF file header info), then specific flowbits are set. The other signatures that scan for malicious PDF content will first check those flowbits to see if a PDF is coming through. Only then will they fire. So if you don't have any of the categories that scan for malicious PDF content enabled, then those flowbit rules won't get auto-enabled as they are not needed.
Now my example above is very simplistic, but it describes the general idea behind flowbits. They get much more complicated. The auto-flowbits part of Snort and Suricata is something I added a long time ago that I adapted from PulledPork. It helps make sure an admin does not shoot themselves in the foot by neglecting to turn on required flowbit category rules. So going back to my simple example, if all that process were manual (as in no checkbox for auto-enabling required flowbit rules) and you neglected to turn on those category rules that set PDF flowbits, then none of your PDF malicious signature rules that read those same PDF flowbits would ever fire even when a PDF with malicious content was traversing the IDS.
Bill
-
Hi, may i know how do I access the file? through shell script?
Kindly provide some guides. Thanks