The source on mine was the yoyo adserver list I had enabled in pfblockerNG package.

omg, i have been getting a similar trojan alert and its driving me mad trying to work out where it is coming from https://forum.pfsense.org/index.php?topic=121123.0 i also have ublock origin, but my snort rule is only showing src as WAN. now how can i tell if this is a false positive if i cant find the local ip

Hi. I do not know if tthis akamai server is compromised. But you can submit the "false positive" (or bug) to Snort if you have a registred user in community:: https://www.snort.org/community#submit_bug Regards.

In other words : unchecking Local Networks from the pass list seems to have no effect.  :( Could it be a cosmetic issue, while clicking "View list"  ? (don't think so…) Also tried to overload HOME_NET value in Advanced Configuration Pass-Through, but Advanced Configuration Pass-Through seems to be broken too (encoded while config is saved).  :(

I am guessing it's probably your IPS policy you have set or you have set it to balanced. If not check it out and just manually set the ones you want.

Hi. More about … :) @BBcan177: I have tried to do this in postfix but couldn't find a solution, so I ended up adding a custom rule to Snort… Getting hit by a usually EHLO  ylmf-pc  (Chinese OS) Snort won't block it fast enough to prevent a couple login attempts, but it will stop an IP after about three attempts. This is because currently Snort is acting on a copy of the packet. alert tcp $EXTERNAL_NET any -> any 25 (msg:"SMTP EHLO from ylmf-pc attempt"; threshold: type limit, track by_src, count 1, seconds 60; content:"ylmf-pc"; nocase; classtype:suspicious-login; sid:9000032; rev:2;) Rgards.

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!