And one is not necessarily any better than the other (Suricata versus Snort) in terms of security. They are really equals in most very way. Snort has OpenAppID which Suricata lacks, but Suricata offers lots of EVE logging options which Snort lacks. And I did not make it clear in my earlier post about the Emerging Threats rules. There are two sets of rules within each category (the free ones and the paid ones). One set is optimized for Snort, and the other set is optimized for Suricata. Suricata on pfSense is internally configured to always download the Suricata-optimized Emerging Threats rules while Snort on pfSense will always download the Snort-optimized Emerging Threats rules.

I think I recall seeing a bug report on the Suricata Redmine site about the DNS analyzer truncating some metadata. Not 100% sure about that, but it does ring a bell of some type. If you have all of the EVE JSON output enabled, then check those log files. They will be located in the /var/log/suricata path. In that path you will find a sub-directory for each configured interface.

@deleted said in Suricata - double check: Okay I understand. Most of it is blocked by firewall and the rest by the respective interface. Can this lead to security problems? When I think about it in an amateurish way, the IDS only checks further "in the back" of the system. I address my security problems for the firewall itself. A firewall itself is pretty secure. At least it is if you don't add a ton of third-party software to it. That's why a lot of us old pros on here give folks grief when they submit new posts asking how they can add this third-party package and that third-party package to their pfSense system such as Midnight Commander or PBX software or Samba, etc. Each added package brings in more shared libraries that might contain security issues. So if you run a pretty clean firewall, then you are fairly secure in terms of vulnerabilities within the firewall itself. And you're not really running the IDS/IPS to protect the firewall. Instead, the IDS/IPS is protecting the hosts behind the firewall because that's where you have the wild west of software installed with things like Flash, Windows, Java and such.

Thank you for the help! It's must appreciated.

@jesscanada said in Snort is blocking our pentesters: Thank you for your reply. I wasn't sure if we had restarted the interfaces before, so I did it just now and had them re-run their scan. I got a lot of Alerts on the WAN interface, with the Source IP being one of the ones we have whitelisted. The IP did not, however, show up on the Blocked list. (We do have blocks set to flush after 1 hour, but we are within that window). Does that mean that it worked? I'm just surprised to see anything in the Alerts section and not under Blocked. Since we have the Block Offenders interface option checked ("Checking this option will automatically block hosts that generate a Snort alert") I am surprised to see it on the Alerts section but not the Blocked section. But if it's not blocking the testers I guess it's still ok to see an alert about it. I think it might be working. What do you think? Yes, it sounds like it is working properly. Putting an IP on a Pass List prevents that IP from being blocked, but it does not prevent the corresponding alerts. If you don't want to see the alert, then you would use a Suppression List entry or else disable the alerting rule. The difference in suppression versus disabling is that when suppressed, a rule is still evaluated and burns CPU cycles for that, but no alert is logged. Disabling a rule prevents it from being evaluated and thus saves those CPU cycles. Alerts do in fact generate blocks, but only if the alerting IP is NOT on a Pass List. If the alerting IP is covered by a Pass List entry, then it is not blocked. The other setting that has some influence is whether you have the "Which IP to Block" parameter set to SRC, DST or BOTH. The default is BOTH. That setting is on the INTERFACE SETTINGS tab under the section where blocking is enabled. Again, though, if SRC or DST is covered by a Pass List entry, then that IP won't be blocked even though it will generate an alert.

@kiokoman said in HA Failover occurs like clockwork, why?: 00:30 is the default rule update start time for suricata suricata will do a hard reset unless you tick Live Rule Swap on Update [image: 1582193062012-immagine2.jpg] [image: 1582192968839-immagine.jpg] That was it. Turned on live update and last night was the first time the failover didn't happen. Problem solved. Thanks.

Neither Snort nor Suricata support FQDN aliases. The package attempts to determine what type of alias you specify when saving a Pass List, but if the aliases are nested then the package code cannot reliably determine which of them might be FQDN and which are not. Many times when a Pass List is deemed not to be working, one of the following will usually be the cause: The Pass List is not actually assigned to the interface on the INTERFACE SETTINGS tab; or if it is assigned, the Snort instance has not been restarted since assigning the list. Pass Lists are only read once during initial startup of the Snort binary; There is one or more duplicate Snort processes running on the same interface. This can happen if some external event caused the pfSense "restart all packages" command to be executed several times in a short period of time. In this case, one of the Snort instances may not be configured with the same Pass List as the other.

@jeremym said in Snort not blocking ET trojan Alerts: But sadly I think its just something as dumb as my looking at the block logs incorrectly. I might have been assuming the newest alert was on top. As I already cleared everything and watching again I will keep an eye out to see if thats the case now that I noticed the logs in in defending order with the newest last and the oldest listed first in the list. The ALERTS tab data is sortable by column. So if you click on the columns the data will sort using the selected column as the sort key. The default is to sort by event time descending which would put the most recent alerts at the top of the page. The BLOCKS tab is just reading out the contents of the snort2c pf table and displaying the data. It also reads the alert log to get some extra data to associate with the blocked IP addresses so it can show some context around each block. All it gets from the snort2c table is just the IP address, so without reading some context from the alert log the blocked tab results would be pretty plain. So it reads in the currently active alert log file and finds all the alerts whose IP addresses (source and/or destination) match up with an IP address currently stored in the snort2c table. It is basically impossible within the blocking module code for some rules to block and others not. The logic does not look at the rule's content or action at all. The only two things that can prevent a block are if the alerting packet has an invalid IP header (which is highly unlikely) or if one of the IP addresses in the packet matches a pass list entry.

Please reread your own freaking statements - you just stated this is NOT a ddos.. " that we not talking here about DDoS or RST flooding as well." Your isp gives 2 shits that there is some noise.. I don't even log such noise - because it serves no purpose.. I only log syn hits to wan, because it can be interesting to what is out there from a noise point of view, of what sort of shit is common out there... Like when that modem thing was happening and seeing traffic on that port, etc. Again if your going to trigger alerts on noise - that is on you, your ISP sure and the hell is not going to care that RSTs are being sent to you IP..

An IDS/IPS can't inspect encrypted payloads. So the content of SSL packets can't be inspected. That does not mean that irregularities in the header can't be detected. Depending on the threat, certain bit patterns might trigger alerts even though technically the payload might be encrypted. For instance, if a malware coder is dumb enough to always encrypt the same data with the same key, then the encrypted result will always be the same bit pattern. An IDS/IPS rule could see and trigger on that. Unfortunately most malware authors are not that incompetent ... . There are some ways to position an IDS/IPS so it can see cleartext traffic decrypted from an SSL session, but it is difficult and usually requires some version of MITM. So as the use of encryption (SSL, TLS, etc.) spreads, the usefulness of IDS/IPS tools will naturally diminish. At least with respect to being able to inspect actual packet payloads. They will still be able to look at the headers and basic protocol info. In the alerts @Raffi_ posted, the alerts are actually from protocol anomalies in the packet header and are not related to the actual packet payload content. The rule is simply alerting on problems with the SYN, ACK or RST flags. It is not alerting on something in the SSL packet payload.

@NollipfSense Oh well, got the same warnings later today. I guess I didn't correctly refresh the interface after applying the disable checksum. So my solution is not working!

My best guess is it is simply pfBlockerNG doing a reverse PTR lookup to find the corresponding domain name, and that lookup is triggering the Snort alert. Since pfBlockerNG runs on the firewall, DNS Resolver (unbound) would perform the lookup by going directly out to the WAN. In that scenario, nothing would ever have need to cross your LAN interface because all the traffic is internal to processes on the firewall, and thus that Snort instance sees nothing to alert on. In summary, it is most likely harmless. If it bothers you, you can see what a packet capture on the WAN shows. My guess is it will show unbound on the firewall doing a lookup and that's it. The "SRC" will be the firewall itself. Similar behavior has been posted before (several months to maybe more than a year ago) and the culprit was simply a package on the firewall attempting to get a domain name for an IP address so it could write the domain to its log file. Harmless behavior.

@NollipfSense Thanks. Then I will have to go back to legacy mode.

Yes, that is correct. CPU cycles are still burned processing the rule. You just don't get alerts from those rules.

@bmeeks Thank you, exactly what I was looking for

@heliop100 If http://that.site.com/ keeps moving from one of their IP addresses to another its your only hope, can't vouch for if its safe or not.

That's were the IDS might come in handy. But ..... for security reasons you would NOT run it on a firewall / router. This one acts only asthe traffic cop. Place your reverse proxy just before your web server on a dedicated, isolated LAN. The reverse proxy will terminate the SSL traffic", exposing itself to the world as the "web server", it will unwrap the SSL traffic, inspecting (like border control) the content and passing on the traffic, it could even stay ordinary http because the ext hop = one cable away, will be the web server. IDS was nice add on ones, but then that new kid come on the block : TLS ....

@BCSNetAdminDF said in Better Blocking for Snort Package: @bmeeks said in Better Blocking for Snort Package: the only way to install and take advantage of the new Snort 4.x package is to upgrade I had no idea, thank you so much. I'll set that up in my lab right away. Once you get the new Snort 4.x package installed, have a look at this Sticky Post for configuration instructions: https://forum.netgate.com/topic/143812/snort-package-4-0-inline-ips-mode-introduction-and-configuration-instructions.

Thank you for your help.

What you have is a botnet with a brute force attack and or tcp flood attacks. Only enterprise class firewalls have this feature, ie sophos, fortinet, and there's no guarantee it will work to stop it. But I found ways. As for ISP not detecting. The ISP or most of them don't care to block or firewall any attacks from their network outbound. Most don't even have a firewall for servers they colocate for clients. Their excuse is to not block any colocation client traffic which is complete nonsense. They didn't even know if it was a server or a coworkers desktop inside frontier. Eg Frontier networks, they don't protect any customer who buys business internet from them in which botnets source from their networks. They claim to have no department to take care of a rogue hacker server in their network. They wash themselves of liability. In turn advocating hackers in their network. Frontier ISP claimed we need to change away from default ports for services which won't prevent bots from trying every port. So we had to buy both software on the server and dual firewall updates that support botnet and tcp flooding. Which are off by default. That the tech support didn't even know about what it was. Even after enabling it. It stopped some but not all of the attack. Maybe another brand firewall would have been more effective. It cost us thousands. So any normal non business and business customer are at complete risk of attacks from this server and servers listed in my logs still today. Shocking but disgusting. The sad thing was, that if I didn't turn in 'audit login' information on the servers then 1 million more attempts would have made it thru the "pseudo firewall" We called fortinet and sophos for help if they could give a demo firewall to test and 2 weeks later they wouldn't. Even though they couldn't guarantee their filter would work or not. They told us to buy and try. If you still need help with this do reach out for my services.