NEW - Suricata 1.4.6 IDS pkg. v0.2-BETA Released
-
2 things I've noticed….
I don't think the suppress list is working. I added an item to the default suppress list and did a full stop/restart of Suricata and still got alerts.
I just noticed this in my testing as well. I will look into it. The curious part is if you look in the suricata.log file, you will see where it parsed the list (they call it threshold) and read the entries from it. However, it still does not seem to actually suppress the alerts.
The other is I don't think there is any port scanning detection. I noticed a lack of any port scan hits in the alerts so I ran GRC's Shields Up! and did a full service port scan and nothing new was in my Suricata logs.
I get alerts on scans. I have a virtual machine test environment where a Kali Linux VM scans my various firewall VMs. When I do a nmap scan against the Suricata VM I get alerts. However, you do have to enable the Emerging Threats scan rules (or at least that's what I did). From some Mailing List posts, it appears Suricata does not contain a native port scan processor like Snort does. The omission is apparently by design according to this thread:
https://lists.openinfosecfoundation.org/pipermail/oisf-users/2011-April/000598.html
There is some validity to the "false positive" comment in that thread. I see port scan FPs frequently in my Snort setups.
Bill
-
2 things I've noticed….
I don't think the suppress list is working. I added an item to the default suppress list and did a full stop/restart of Suricata and still got alerts.
I just noticed this in my testing as well. I will look into it. The curious part is if you look in the suricata.log file, you will see where it parsed the list (they call it threshold) and read the entries from it. However, it still does not seem to actually suppress the alerts.
The other is I don't think there is any port scanning detection. I noticed a lack of any port scan hits in the alerts so I ran GRC's Shields Up! and did a full service port scan and nothing new was in my Suricata logs.
I get alerts on scans. I have a virtual machine test environment where a Kali Linux VM scans my various firewall VMs. When I do a nmap scan against the Suricata VM I get alerts. However, you do have to enable the Emerging Threats scan rules (or at least that's what I did). From some Mailing List posts, it appears Suricata does not contain a native port scan processor like Snort does. The omission is apparently by design according to this thread:
https://lists.openinfosecfoundation.org/pipermail/oisf-users/2011-April/000598.html
There is some validity to the "false positive" comment in that thread. I see port scan FPs frequently in my Snort setups.
Bill
I just ran an nmap remotely and show nothing on my alerts and I'm running all ET open rules except the p2p rules.It does seem to pick up nmap scans after I figured out a few PEBKAC issues. However, the scanning tool here triggers a TCP portscan in Snort and nothing in Suricata. I guess there isn't much you can do about it since it's by design so it will be somewhat of a tradeoff with Snort.
-
were any fixes put in to correct the multiple instances because of filter reload when interfaces go up and down? You were able to correct it for snort (barnyard2 in snort still fires up multiples tho)
root 65751 6.0 1.8 73192 55536 ?? SNs 3:45PM 0:01.19 /usr/pbi/suricata-i386/bin/suricata -i em3 -D -c /usr/pbi/suricata-i386/etc/suricata/suricata_34793_em3/suricata.yaml --pidfile /var/r root 65005 0.6 0.0 3644 1440 ?? IN 3:45PM 0:00.01 /bin/sh /usr/local/etc/rc.d/suricata.sh start root 65187 0.3 0.9 31008 27220 ?? SN 3:45PM 0:00.23 /usr/pbi/suricata-i386/bin/suricata -i em3 -D -c /usr/pbi/suricata-i386/etc/suricata/suricata_34793_em3/suricata.yaml --pidfile /var/r
-
were any fixes put in to correct the multiple instances because of filter reload when interfaces go up and down? You were able to correct it for snort (barnyard2 in snort still fires up multiples tho)
root 65751 6.0 1.8 73192 55536 ?? SNs 3:45PM 0:01.19 /usr/pbi/suricata-i386/bin/suricata -i em3 -D -c /usr/pbi/suricata-i386/etc/suricata/suricata_34793_em3/suricata.yaml --pidfile /var/r root 65005 0.6 0.0 3644 1440 ?? IN 3:45PM 0:00.01 /bin/sh /usr/local/etc/rc.d/suricata.sh start root 65187 0.3 0.9 31008 27220 ?? SN 3:45PM 0:00.23 /usr/pbi/suricata-i386/bin/suricata -i em3 -D -c /usr/pbi/suricata-i386/etc/suricata/suricata_34793_em3/suricata.yaml --pidfile /var/r
No, I'm sorry that one slipped my mind in the rush to get Suricata 0.2 out. I will write it down on my list of TODO fixes for the next version.
So you are saying you get multiple instances of Barnyard2 on Snort with the exact same command-line parameters? I did not know that was still happening for anyone.
Bill
-
No, I'm sorry that one slipped my mind in the rush to get Suricata 0.2 out. I will write it down on my list of TODO fixes for the next version.
So you are saying you get multiple instances of Barnyard2 on Snort with the exact same command-line parameters? I did not know that was still happening for anyone.
Bill
Np, it happens. Hoping its an easy fix… Barnyard2, yes. I will see multiple instances of it running. I can reproduce on the fly by resetting my cable modem. I think I may have reported it but to be honest, I can't remember...
-
No, I'm sorry that one slipped my mind in the rush to get Suricata 0.2 out. I will write it down on my list of TODO fixes for the next version.
So you are saying you get multiple instances of Barnyard2 on Snort with the exact same command-line parameters? I did not know that was still happening for anyone.
Bill
Np, it happens. Hoping its an easy fix… Barnyard2, yes. I will see multiple instances of it running. I can reproduce on the fly by resetting my cable modem. I think I may have reported it but to be honest, I can't remember...
Since you reported this, I checked last night and I am seeing that Barnyard2 problem on my Snort setup as well. When my cable modem reboots and bounces my firewall's WAN interface, Barnyard2 is not reliably restarting. I'm working on it. Hopefully it's just a dumb typo someplace since Snort works OK. They are both supposed to be using essentially the same shell script commands. I will put my glasses on and examine the code carefully to find the mistake. There has to be one someplace… :-[
Bill
-
Very minor thing, but passing it along. When the widget gets an IPv6 alert, it causes the right side border to extend past the normal alignment. The Snort widget wraps the address.
Here it is with only IPv4 alerts and with an IPv6 alert changing the alignment.
-
** Problem - Cannot Disable Interface **
Problem: Cannot disable Suricata on an interface, it faults to "The following input errors were detected: The value for Maximum-Pending-Packets must be between 1 and 65,000!"
Steps to Reproduce:
-
Have Suricata enable and running on an interface. Max Pending Packets is at the default 1024.
-
Uncheck "Enable" and hit "Save".
-
The error box "The following input errors were detected: The value for Maximum-Pending-Packets must be between 1 and 65,000!" pops up.
-
Go back to interfaces and the disable action did not take.
-
-
** Problem - Cannot Disable Interface **
FYI - This also occurred in the previous version. Hope that helps diagnose.
-
** Problem - Cannot Disable Interface **
Problem: Cannot disable Suricata on an interface, it faults to "The following input errors were detected: The value for Maximum-Pending-Packets must be between 1 and 65,000!"
Steps to Reproduce:
-
Have Suricata enable and running on an interface. Max Pending Packets is at the default 1024.
-
Uncheck "Enable" and hit "Save".
-
The error box "The following input errors were detected: The value for Maximum-Pending-Packets must be between 1 and 65,000!" pops up.
-
Go back to interfaces and the disable action did not take.
I will fix it. I screwed up the order of input validation and also forgot to skip it all when just disabling the interface. My bad… :-[
I will post the Pull Request today, and hopefully one of the Core Team devs will have a chance to review and approve.
Bill
-
-
Very minor thing, but passing it along. When the widget gets an IPv6 alert, it causes the right side border to extend past the normal alignment. The Snort widget wraps the address.
Here it is with only IPv4 alerts and with an IPv6 alert changing the alignment.
I will try to get this fixed in the next update as well. The only way I've found around this is to insert zero-length spaces next to every colon in an IPv6 address. These don't display, but they offer the browser a "line break" opportunity. This makes the prettiest line break (breaking on a colon, that is). The other option is a forced wrap, but that can happen in odd places and makes readability more difficult.
Related to this, what is the preference among users for how to delimit ports when displaying IPv6 addresses? The IPv4 standard is a colon at the end of the address, but since IPv6 already has colons, things are more confusing.
Bill
-
Related to this, what is the preference among users for how to delimit ports when displaying IPv6 addresses? The IPv4 standard is a colon at the end of the address, but since IPv6 already has colons, things are more confusing.
I believe square brackets around the address portion of the address is the standard.
-
Related to this, what is the preference among users for how to delimit ports when displaying IPv6 addresses? The IPv4 standard is a colon at the end of the address, but since IPv6 already has colons, things are more confusing.
I believe square brackets around the address portion of the address is the standard.
Thanks! I will make the adjustment in the widget display.
Bill
-
Bug Fix Update
Just FYI. A new Pull Request was posted today containing fixes for the bugs reported thus far with the Suricata package. The version number will remain the same for now, but I will post an update when the pull request is merged and then interested parties can do a quick reinstall of the Suricata package GUI components to pick up the fixes.
Here is a link to the Pull Request with the details: https://github.com/pfsense/pfsense-packages/pull/622
Bill
-
What are the possibilities of adding in some log file rotation routines? alerts.log and http.log have grown to the point that it's not practical to view them in the Logs Browser.
1041187808 Mar 13 21:52 alerts.log ( a very unhappy checksum rule filled this up rather quickly )
47180176 Mar 14 07:31 http.logEven just a daily rotation with date in the file name (ex: alerts_20140314.log) would be nice.
-
What are the possibilities of adding in some log file rotation routines? alerts.log and http.log have grown to the point that it's not practical to view them in the Logs Browser.
1041187808 Mar 13 21:52 alerts.log ( a very unhappy checksum rule filled this up rather quickly )
47180176 Mar 14 07:31 http.logEven just a daily rotation with date in the file name (ex: alerts_20140314.log) would be nice.
I can do that. I also noticed that Suricata can be quite chatty. I will make the rotation a configurable cron job so the user can select from several rotation options.
Bill
-
ET has finally killed the RBN rulesets.
"Emerging Threats would like to remind and/or inform everyone that this ruleset does not contain the Russian Business Network (RBN) rules. These rules are obsolete and will not be distributed in future releases."
Another feature for Snort/Suricata that would help is to have two Alert screens.
One for the noisy alerts like Scans/CINS/DROP/MYSQL/SQL etc.
One for all other alerts which would make it easier to see from the Alert screen without all of the other alerts on the same log. -
Time to update the blueprint with the removed rules then. Open to suggestions for lists to replace those.
-
For ET changes, these three seem to still be online -
pfBlocker ET Blocker
http://rules.emergingthreats.net/fwrules/emerging-Block-IPs.txt
http://rules.emergingthreats.net/blockrules/compromised-ips.txt
http://doc.emergingthreats.net/pub/Main/RussianBusinessNetwork/RussianBusinessNetworkIPs.txtFor Snort/Suricta, I would always recommend that people start with as many rules as their box can handle (Memory and CPU) and start in non-blocking mode, remove all the false positives over several weeks of review. And then putting it into Blocking mode. With Bills new tweeks removing Rules from the Alert Page makes it easier. If we had the endablesid.conf and disablesid.conf files we could populate those files with our settings and it would be even easier to manage.
–-----------------------------------------
Here is a list for pfBlocker.
I like to keep the lists separate so I can see what is triggering a block. This helps to weed out False Positives.
pfblockerlists
pfBlocker iBlockList
http://list.iblocklist.com/?list=bt_hijacked&fileformat=p2p
http://list.iblocklist.com/?list=ficutxiwawokxlcyoeye&fileformat=p2p
http://list.iblocklist.com/?list=ghlzqtqxnzctvvajwwag&fileformat=p2p
http://list.iblocklist.com/?list=tbnuqfclfkemqivekikv&fileformat=p2p
http://list.iblocklist.com/?list=bt_spyware&fileformat=p2p
http://list.iblocklist.com/?list=bt_templist&fileformat=p2ppfBlocker ET Blocker
http://rules.emergingthreats.net/fwrules/emerging-Block-IPs.txt
http://rules.emergingthreats.net/blockrules/compromised-ips.txt
http://doc.emergingthreats.net/pub/Main/RussianBusinessNetwork/RussianBusinessNetworkIPs.txtSpamhaus
http://www.spamhaus.org/drop/drop.txt
http://www.spamhaus.org/drop/edrop.txtpfBlocker Other
http://www.ciarmy.com/list/ci-badguys.txt
http://danger.rulez.sk/projects/bruteforceblocker/blist.php
http://www.us.openbl.org/lists/base_30days.txt
http://malc0de.com/bl/IP_Blacklist.txtpfBlocker Zeus/SpyEye/Palevo
https://zeustracker.abuse.ch/blocklist.php?download=ipblocklist
https://spyeyetracker.abuse.ch/blocklist.php?download=ipblocklist
https://palevotracker.abuse.ch/blocklists.php?download=ipblocklistpfBlocker dShield
http://feeds.dshield.org/top10-2.txtpfBlocker Arbor Networks - Atlas
https://atlas.arbor.net/summary/attacks.csv
https://atlas.arbor.net/summary/botnets.csv
https://atlas.arbor.net/summary/fastflux.csv
https://atlas.arbor.net/summary/phishing.csv
https://atlas.arbor.net/summary/scans.csv
http://atlas-public.ec2.arbor.net/public/ssh_attackerspfBlocker Malware Domain List
http://www.malwaredomainlist.com/hostslist/ip.txtpfBlocker No Think!
http://www.nothink.org/blacklist/blacklist_malware_http.txt
http://www.nothink.org/blacklist/blacklist_ssh_week.txt
http://www.nothink.org/blacklist/blacklist_malware_dns.txtpfBlocker SRI
http://cgi.mtc.sri.com/download/attackers/01-17-2014/Get_Top-51_30-Day_Filterset.html
http://cgi.mtc.sri.com/download/cc_servers/01-17-2014/Get_Top-1_30-Day_Filterset.htmlpfBlocker Infiltrated
http://www.infiltrated.net/blacklistedpfBlocker AlienVault
https://reputation.alienvault.com/reputation.snortDRG
http://www.dragonresearchgroup.org/insight/sshpwauth.txt
http://www.dragonresearchgroup.org/insight/vncprobe.txt
http://www.dragonresearchgroup.org/insight/http-report.txtpfBlocker Feodo
https://feodotracker.abuse.ch/blocklist/?download=ipblocklist
https://feodotracker.abuse.ch/blocklist/?download=badipspfBlocker Blocklist.de
http://lists.blocklist.de/lists/all.txt
http://www.senderbase.org/static/spam/#tab=2pfBlocker StopForumSpam
Local List (.CSV script to convert)pfBlocker Autoshun
Local List (.CSV script to convert) -
http://doc.emergingthreats.net/pub/Main/RussianBusinessNetwork/RussianBusinessNetworkIPs.txt
I think that's the one that was causing problems for a number of people, so I switched from that to the "new" RBN list (now obsolete).
A couple of interesting lists there, will test them out. If you are ok with it, I'll add them in due time to the blueprint and credit you.