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 .

This has been solved. I had to remove the package lock file via the GUI and then hit the reinstall package button. This then completed the snort install but omitted all other packages. So I restored the config file one more time via the GUI. Upon reboot, the remaining packages were installed. All good but not straight forward.

thank  you for information but i'm finish to follow step bu step. Is there any alternative to block attacker like port scanning ?

I still stand by my theory that an Alias is not getting resolved to its actual IP address on the box with the error message.  The GUI code uses pfSense system calls to convert alias names to their actual IP addresses.  The actual IP addresses are then written into the pass list file when it is created.  The same thing happens for interfaces, DNS servers and the other parameters listed on the Pass List edit page.  They all get resolved to actual IP addresses with masks and are then written to the Pass List file Snort or Suricata uses. If for any reason an Alias, an interface, a DNS server or a gateway returns an empty address, then that empty address shows up in the file and generates the error.  You can open and view the actual Pass List text file being used by the interface.  Navigate to /usr/local/etc/snort/snort_xxxxx/ and open the pass list file in the directory.  The "_xxxxx" term will be your physical interface name along with a GUID random number.  You can browse to the file using DIAGNOSTICS > EDIT from the pfSense menu. Bill

Thanks Bill.

Hi Bill, How right you were. Just updated without a problem. Thank you very much for taking the time to get back to me. Kind regards John

You don't need a specific rule, but you must input the MAC/IP pairs for all hosts you want to monitor in the table under the ARP Spoof Detection section of the PREPROCESSORS tab for the interface.  Be advised this option can be quite a log spammer and is not good at detecting many types of ARP attacks.  In short, it's a feature that sounds better than it really works in practice.  That's my humble opinion.  I added the configuration to the GUI because some users wanted to implement it. Bill

@ecfx: I know about the snort rules on suricata and that was not a problem on suricata 3.2.2, the same rules were ignored and suricata still worked. The real problem it is the crash that now latest suricata version 4.0.0 cause it. To bad the previous suricata version has gone from  pfSense repo and we can't go back. In this case upgrade to suricata latest version was a mistake. Found this bug report on the Suricata Redmine site:  https://redmine.openinfosecfoundation.org/issues/2251#change-8823.  You can follow the progress there.  The pfSense package uses the Suricata binary from upstream.  The only thing the GUI package really does is just create the suricata.yaml text configuration file and then display some data from logs.  So any issues in the underlying upstream binary will also exist in the pfSense package. Bill

@ucok28: so how to make snort can block ? See my reply to you in this thread:  https://forum.pfsense.org/index.php?topic=139028.msg760114#msg760114 Bill

Yep, that was it. Now that my system disks are SSD, I really don't need the RAMDISK feature anymore. I am turning it off. Thanks again.

No, the blocks are stored in a pf table called snort2c.  That table is created by the pfSense code at startup and maintained in RAM.  On a reboot, it is dumped and recreated fresh but empty.  Persisting blocks has not real benefit anyway.  If Snort blocked the traffic once, it will block it the next time it sees it.  So why persist across reboots and add all that complexity to the code? Bill