@NollipfSense Yes. [image: 1585028368075-social_networking.png]

LOL I feel ya. Thing is tho, if you do it/get it started now when Snort3 is actually released you'll be in good standing. Or alternatively it could be radically different from the beta and need another rewrite Although I think that is not very likely. Like I say I very much appreciate your work. Maybe you can put out the feelers for some other devs to help with the rewrite?

@andrewdr said in Record client address in snort: @bmeeks We are running a mail server and openvpn server so maybe a bit more research before a wholesale change to snort - thanks. You would be fine to put a Snort instance (or instances) on the firewall interfaces where those servers are located. Hopefully you have them in a DMZ of some sort. If so, then put Snort on the DMZ interface. Remember that Snort is not there to protect the firewall, it is there to protect clients behind the firewall. I say this because a firewall is generally very secure and when properly configured has a very minimal attack surface. Client machines (PCs and servers), on the other hand, have tons of attack surfaces. And the biggest attack surface of all is the human sitting at the client's keyboard clicking "yes" and "OK" to just about every single prompt ... .

@bmeeks BTW Bill, it did sort itself out...I didn't needed to do anything.

@justme2 I am running pfSense 2.5, and Snort 4.0...noticed the same also; however, I have not experienced any performance issue. [image: 1584577574564-screen-shot-2020-03-18-at-7.21.58-pm.png]

For high alerts traffic like that you really need to export the logs off to an external processor and access them there. There is just not enough allocated PHP memory in the pfSense system to handle huge string arrays which are what get created when looking through a huge alerts list in the GUI. You can use the Barnyard2 tab to export logs to a remote syslog server. You could also probably configure something like an ELK stack and put an export client on pfSense and offload logs that way.

Thanks for the replys! they are appreciated. I will check them out :)

No, OpenAppID is a Snort-only feature. It was invented by Sourcefire which was later absorbed in 2013 into Cisco along with Snort . Cisco eventually open-sourced some of the OpenAppID stuff and included it in Snort. To date, the Suricata upstream development team has shown no interest in porting something similar into Suricata. If they ever do that, then it will be included in the pfSense Suricata package.

It's really packets per second (pps) that matter in these benchmarks. See, I can send 10,000 8KB jumbo frame packets chock full of data each and then claim about 655 MBits/sec of throughput (8192 bytes x 8 = 65,536 bits per packet x 10,000 packets/sec = 655 MBits/sec). However, if those same 10,000 packets were only 64-byte UDP packets, for example, now my throughput is only 5.1 Mbits/sec (64 bytes x 8 = 512 bits per packet X 10,000 packets/sec = 5.12 Mbits/sec). But in both cases the firewall is essentially doing the same amount of work by processing those 10,000 packets per second. Real world network traffic is a mixture of full-frame payloads and small payloads. When doing performance test benchmarks, especially for "selling points", some amount of "poetic license" is taken to make the results look their best. So my point is that when comparing raw Megabits/second throughput make sure you know the frame size and the data payload size used for the test. What really matters is how many packets per second the firewall can handle. There is usually no big penalty with the size of a given packet, it's the overhead of processing the packet itself that matters most. To make sure you are comparing apples to apples, find out what frame size and data payload was used for the test. Was the frame's payload completely filled, or was it just a tiny payload? In terms of tuning Suricata, there are a few articles to be found on the web, but don't expect some precise cookbook process of do this, then this and finally this to get petabits/sec performance ... . The amount of free RAM, the number and types of enabled rules and finally the specific configuration of Suricata's various run modes and CPU core affinity settings determine packet processing throughput. There are also tweakable parameters for the various NIC drivers that influence throughput. The pfSense Suricata package uses the same general defaults that are shipped in the Suricata source code. There is room for tweaking performance with specific hardware combinations. That tweaking would be a blend of Suricata config changes and adjustments to various sysctl parameters in the OS kernel.

look/ask here if you aren't running it under pfSense:- https://snort.org/community

@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. [image: 1583056743200-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.