@bmeeks

Thank you for the response. I didn't have the proper tarball file name set, but after doing so everything is working great.

Also the sticky you provided was a good read.

Thanks

@serbus:

The Pass List has no function unless Legacy Mode blocking is enabled. That's why the GUI code hides the drop-down when that mode of blocking is disabled. It's an attempt to keep the screen a bit less cluttered by removing options that have no role in the currently selected operational mode.

@bmeeks

Kk Sounds good,

Thanks my friend will check it out, and I will ask my isp about that because I am seeing a whole range of ips in the same scope as my public wan ip as well as ips that look to be going to different ip addresses not related to me at all and are on the same subnet as my public wan.

Thanks again.

@wintok said in How to Block Potentially Bad traffic:

Hi, I have checked my snort alert and see the bad traffic (see below), and it makes me wonder if this is really bad traffic and if it is how to block it. I did further search in the whois database on this ip and it is the ip address of the United States Of America Ashburn Akamai Technologies Inc.

alert1.PNG

The HTTP_INSPECT rules triggering is almost never the result of something malicious. These rules are sort of like the "grammar police" for HTTP traffic and will alert on anything they see that is not RFC compliant. Unfortunately, with Snort in the pfSense-2.4 branch, the only option is to block on all alerts or block on no alerts. So you would need to either suppress or disable this rule in your environment if you determine it is a false positive (which it likely is).

Snort in the 2.5 branch of pfSense offers a new Inline IPS Mode like Suricata has. That mode lets you set some rules to just ALERT on traffic while others can be set to DROP or REJECT traffic. So using that mode the rule you referenced would generate an alert but would not block (or drop) the traffic.

I can't speak for the 7100, I built my own and use Community, however, I have wan lan and guest vlan interfaces set up, with snort and pfblockerng (even open VPN) on an old gaming PC that has a quad core i7, 8gb ram.

Ram usage easily 50% with tld checkbox active as well highest percentage I've seen so far is 65% memory usage, and at most 15% CPU usage (spikes - avg is less than 8%)

That, granted is only supporting at most 15 devices at any given time. It also is an asymmetrical gigabit connection 935/40 (cable) and does not slow down even over internal VPN connection (realized I needed to set up lagg afterwards as VPN maxes at 500 - gigabit one way sliced in half when back and forth on same interface). I assume separate up and down links to my managed switch would also help accomplish this.

Grain of salt, hope this helps

Hello!

OK.

Looks like it is fixed in the devel branch.

John

yeah, i called you on purpose to explain things better 😁 and i used the wrong nickname 😂

@NogBadTheBad i have send test is work .. i will try next day . tq

@strongthany said in Does supression in suricata mean blocking or hiding the alert?:

On the note of that, how would one check if their interface supports netmap/inline?

These NIC drivers currently support the netmap device in FreeBSD: em(4), igb(4), ixbge(4), lem(4), re(4).

Features such as limiters and alternate queing algorithms do not work with netmap. So if your NIC is using one of the drivers listed above, and you are not doing using limiters, then inline mode with netmap should work for you.

Information on configuring the supported Intel NICs can be found in this forum sticky post: https://forum.netgate.com/topic/138613/configuring-pfsense-netmap-for-suricata-inline-ips-mode-on-em-igb-interfaces.

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
Immagine2.jpg
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!