Thank you for the quick update

Thank you for the quick update

still open … and keeps crashing. Either remove bro-ids from options of barnyard2 or try to fix it. Last would more the sufficient way. Thanks

@bmeeks: My own Snort VRT rules last updated on November 21.  So probably nothing to worry about.  Either nothing has been needed on the rule creation front for a while, or the Snort VRT folks took a long holiday for Thanksgiving in the U.S. …  :) You can follow the Snort VRT rules releases here:  https://www.snort.org/downloads/#rule-downloads Bill Thank you. As it turns out, yes, I was simply being impatient: Starting rules update…  Time: 2017-11-29 04:30:00 Downloading Emerging Threats Open rules md5 file emerging.rules.tar.gz.md5... Checking Emerging Threats Open rules md5 file... There is a new set of Emerging Threats Open rules posted. Downloading file 'emerging.rules.tar.gz'... Done downloading rules file. Downloading Snort VRT rules md5 file snortrules-snapshot-2990.tar.gz.md5... Checking Snort VRT rules md5 file... There is a new set of Snort VRT rules posted. Downloading file 'snortrules-snapshot-2990.tar.gz'... Done downloading rules file. Extracting and installing Emerging Threats Open rules... Installation of Emerging Threats Open rules completed. Extracting and installing Snort VRT rules... Installation of Snort VRT rules completed. Copying new config and map files... Updating rules configuration for: WAN ... Updating rules configuration for: LAN ... Restarting Suricata to activate the new set of rules... Suricata has restarted with your new set of rules. The Rules update has finished.  Time: 2017-11-29 04:32:20 Thank you again for all your very informative help.

Thankyou ! Will be using it to teach myself some things

@kejianshi: I looked into that, of course, but it was very automatic.  Anything I'd have wanted to add was already there. Yeah, it was… Since I turned NAT off and made into IP Public, I should put that IP in HOME_NET list.

@EWBtCiaST: Bill, Thanks for the reply. I don't think that's the problem as I'm in the U.S. and I was just able to download the rules using a test virtual machine with the same public IP as the one that doesn't work. Are you running any other blocking packages?  pfBlockerNG, for example.  Some of the IP lists there have blocked access to rules downloads for folks using them.  Do you have a proxy of some sort in use? The download process is just a simple call to the curl() functions in PHP with the rules URL.  The exact same code is used for all the rules downloads, so if one works that means the underlying code is good.  Otherwise, no downloads would work. Bill

Related: https://forum.pfsense.org/index.php?topic=139273.15

@drewsaur: Removing the quotation marks was the trick. Thanks. Not sure why the examples in the files include them!!! To separate them from the other text, but perhaps it would be useful to add a disclaimer in the examples that the quotation marks should not be included. You put only exactly what you are searching for after the pcre: keyword in the SID management conf files. Bill

Bill, Snort has been working fine for the last few weeks. I haven't received any notifications from the watchdog service for snort. I'll post back here if anything comes up again, but it seems solid now. Thanks for the fix! Raffi

Incredible explanation - beyond awesome - Thank you…

@bmeeks: My answer to the question for those TCP rules is the same as it was for the previous UDP rules.  What is the point?  The firewall will drop all unsolicited TCP packets as well.  I just didn't state that in my earlier response since we were specifically just talking UDP, but pfSense out of the box drops all unsolicited inbound traffic on the WAN. If you don't open a port and specify a protocol in a firewall rule, then nothing gets in.  So if you don't have an explicit firewall rule allowing MS-SQL inbound (TCP port 1433), then nothing can connect to that port.  Putting a MS-SQL drop rule in Suricata does not accomplish much in my view.  Instead of having Suricata munch through a bunch of rules to drop traffic the firewall is going to block anyway, I would reserve Suricata's processing to protect stuff where I have actual vulnerabilities (such as rules looking for local clients attempting communication with known malware BOT nets, various JavaScript or PDF attacks from web sites, etc.). Bill Thanks for clarification.

Thank you for your assistance.  I uninstalled, ran the command and re-installed snort and can now set up my snort service.

I understood,  just in my opinion it's much cheaper to buy a video card with the support of CUDA than to buy a new processor. Well, we'll wait, but for now we'll try to customize Suriсata. Maybe this will help improve performance. :)

@bmeeks: @Koenig: @bmeeks: @Koenig: Just got suricata working but it floods the log with "suricata 5498 [1:2200075:2] SURICATA UDPv4 invalid checksum [Classification: Generic Protocol Command Decode] [Priority: 3] {UDP}" What to do about it? Try toggling the Hardware Checksum Offloading feature under SYSTEM > NETWORKING > ADVANCED.  If that does not do it, you can simply disable that particular rule by either clicking the red X icon on the Alerts tab in the GID/SID column, or you can find and selectively disable that rule on the Rules tab for the interface. Bill I have Intel NIC's so the (QOTOM I5) hardware checksum should be working or shouldn't it? Waiting for an answer here I googled it, and from what I gather it is better to supress it for until I get into it more? I'm a total newbie when it comes to suricata. See this thread from the official Suricata documentation Wiki for details:  http://suricata.readthedocs.io/en/latest/performance/packet-capture.html, but the short answer is you want hardware checksum offloading disabled as well as LRO (it is already off by default in pfSense).  Suricata uses PCAP for packet capture during Legacy Blocking Mode operation, and Netmap for Inline IPS Mode operation.  In both cases, hardware checksum offloading needs to be disabled. Bill Thank you! All disabled.

Thanks for your reply Bill. Again you are quite right about the fact that, after a given FQDN, it may be a lot of IP addresses. But this problem also applies to any FQDNs used all around the platform. There is no guarantee that two consecutive requests result in the same IP addresses returned and if you use them to have any sort of inter-dependence between them you could get undeseired results. But I think it may be better to have this than nothing. Because of DNS caching it is very probable that two requests get the same result because they both may be using the same DNS server or even the pfSense itself as a DNS caching server. Instead of the message telling that FQDNs are not supported a message could advert the admin that she should use the same DNS server for the pfSense and the internal clients and that using FQDNs is not fool proof because of the chance that two consecutive requests receive different replies. I am aware of the problem of blocking access to youtube or other undesired sites by IP lists; that does not work and a different approach (protocol analisys) has to be taken instead. But, unlesss the effort to put this into place is so high that makes the task unrewarding, being able to use FQDNs may have more advantages that inconveniences under my point of view. Miguel.

Then I just have to wait until the powers that be fix it. I do have one more question for the community. Does anyone out there not see the bad pkts in the console? If so, what NIC is in use and what interface. I am using inline on the WAN interface. Maybe the WAN is just too active to handle the packets with netmap. I want to make sure that it is not just me .