Hi I see your need some thing more f. Try it create a custom rules in Snort for pass the traffic with dst 192.168.1.9 port 65000 and block the rest. alert tcp any any -> !192.168.1.9/32 65000 (msg:"IgnoreIPtcp";  sid:9000001; classtype:misc-activity; rev:1;) alert udp any any -> !192.168.1.9/32 65000 (msg:"IgnoreIPudp";  sid:9000002; classtype:misc-activity; rev:1;) Regards

@jgkpffrm: connect to the pfsense server with filezilla and go to /var/log/snort/<interface>/  download snort.log.xxxxx turn off ssh Run Wireshark and look at the data</interface> What you mean is to use wireshark on a local PC and run an analyzer-session against the log-file (snort.log.xxxx)? Does this mean that snort.log.xxxx in reality has all the data, it is just more readable through WireShark?

From: https://forum.pfsense.org/index.php?topic=91438.msg506088#msg506088 @fsansfil: They are covered in ET Trojan Rules. Have a look. F. If I read the above correctly it is already available?

Just to update, I have used a BPF file to bypass Snort on the media ports to the VOIP hosts. This has resolved the CPU issue, although this is a workaround rather than a fix so I would still appreciate any input. To achieve this I created /etc/snort.bpf with the following contents not (host 10.0.200.161 and udp portrange 16384-32768) and added the following line to the advanced configuration pass-through config bpf_file: /etc/snort.bpf saved the configuration and restarted snort. Now calls do not hog the CPU.

We have a somewhat similar problem. We have several external IP addresses, one for mail, one for our web server and one for everything else. We would like snort to scan and block two of the three official IP-addresses and leave the third untouched or better phrased unscanned. I have no real Idea how to do that. At first I thought I can put the IP which should not be scanned out of the home net or external net but I couldn't get snort to not scan the IP. Has someone a helping hand for me?

I have alredy tried that without success. Fortunately I solved the problem. As I suspected the problem was the vmxnet3 drivers. Netmap doesn't support it. Alerts appeared using Suricata inline with E1000 drivers on one of my bridge interfaces. I found this reference in another post: https://www.freebsd.org/cgi/man.cgi?query=netmap&apropos=0&sektion=4&manpath=FreeBSD+10.2-RELEASE&arch=default&format=html#SUPPORTED_DEVICES Lesson: DON'T use VMXNET3 with Suricata INLINE mode!

Oops, I am also facing this situation. So the reason is from Snort VRT Website :(

thanks BBcan177 After adding``` .amazonaws.com

I don't think it's possible to do it the way you are asking. One way to solve would be to use modifysid on the SID MGMT tab to exclude port 123 from the rules that are being triggered. Another option would be to suppress the internal host(s) that are triggering these rules for each specific rule.

I assumed that this warning was a false positive, since I checked IP and found that it's belong to Surfeasy which are the ones who are behind the opera VPN But still catches the eye when this warning pops up in snort alerts.I don't know what is the reason then why this alert appears?I was doing fresh  (backup/restore) install on that phone with android and it doesn't have nothing like bloatware or crapware apps on it.I was just testing Opera max & vpn from the official play store.

@jimp: That and other packages will need to be adapted for the new code on 2.4. Many things will likely be broken for a while yet until we get around to patching them up as we go. Excited to see this progress. I might consider switching to suricata over snort in pf 2.4. Thanks for all of the support, Jimp!

@mikesamo: Hello, work for me… That picture doesn't help, because in Legacy mode, it will look the same. If you are in Inline mode for both Interfaces, I believe you, I'll try to delete the configuration for suricata by hand. For me it only works for the second interface like bellow Thanks  

@ntct: https://forum.pfsense.org/index.php?topic=100256.0 Honestly, I disabled that rule yesterday to provide the service for end-users. But I still want to know this is the reason from rules or Snort. Thank you for your link.

Emerging Threats is the brand name. There are two ET main rulesets: Emerging Threats Open is free and provides (in my opinion) a decent amount of coverage Emerging Threats Pro is $750 per year per sensor and includes more rules and provides better coverage. On pfSense Snort only supports what is now referred to as legacy IPS mode. Suricata supports both legacy and inline IPS mode. With either Snort or Suricata in non-blocking mode you will only get alerts for whichever rules you are running With either Snort or Suricata in legacy IPS mode you will block the IP of the offending traffic  for whichever rules you are running. Some amount of traffic will pass before the IP is blocked and the states killed. With Suricata in inline mode you must specify which rules you want to run in drop mode. Any rules specified for drop mode will drop the traffic before it passes, and the IP address will not be blocked entirely. Any rules that are active that are not specified for drop mode will generate alerts without any dropping/blocking.