Yes, if the built-in rules you select don't match your requirements, you can write a custom rule to block a specific application. I just created this custom test rule to block WhatsApp:

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"WhatsApp";flow:from_client;appid:whatsapp; sid:1000056 ; classtype:misc-activity; rev:1;)

…it blocks to a lesser or greater extent, see attached image of the alerts generated, and a lot depends on how up-to-date and accurate the Snort detectors are and how quickly the applications change. You can get a list of applications from the Snort snort-openappid.tar.gz file at https://www.snort.org/downloads#openappid

2018-05-19_15-20-44.png
2018-05-19_15-20-44.png_thumb

Read through these forums on IDS/IPS, you will notice a trend that Bill is more than helpful. I've learned so much just reading through other people's issues as well as my own. Bill goes out of his way to not be condescending, but sometimes stating things in forums may seem that way. Unfortunately, you can't type tone.

NollipfSense has great advice for this instance and in general when trying to isolate a specific case. Bill's advice is really the only long term solution. I went through the same troubles for a long time till I got my IPS working the way it does now. It takes time for trial, error, reading, more errors, more reading, watch some videos on it, and so on.

Good luck

Sorry for the late reply, but forgot to click on 'notify'

why is it not a good thing to know if your rule updates failed?

It is good to "know" that, but I do not want my config management system catching this "change". It is not a configuration change but a component state change.
Could it be stored as a global variable accessible to any component?

The download fails a bit more often than in your system.

Zsolt

I get them also; however, in my case though, my neighbor and I share the Internet so I ignore them because it's my neighbor's devices. It seems that your situation is similar to mine based on your WAN using RFC1918.

I would assume you have configured the notification app to use the email server's name instead of IP address.  If so, it appears from the error message the DNS lookup of the hostname is failing.  That's what you should investigate.

To see if Suricata is the problem, simply look on the ALERTS tab to see if any alerts are present with the IP address of your DNS server.  Have you tried disabling Suricata to be sure that is actually the cause of the problem?

Bill

@JohnSCarter:

I guess that makes more sense.

My understanding of drive by attacks is that you're "attacked" once exposed to the malicious agent, if it were an ad or webpage component wouldn't that happen once the asset was loaded when I first visited the page? could it have been delayed by nearly 15-20mins?

Also my network is back online now, fingers crossed it doesn't happen again.

Some web sites use Javascript timers that periodically cycle through different ads and display them in a common iframe on the page.  So depending on length of time at the site, it may have cycled through to an ad served from a less-than-reputable source and that's when the malicous code was detected.

Don't let Suricata make you paranoid!  It will detect a lot of stuff.  Most of what it may detect is totally harmless to most home users and even to many corporate IT users.  So long as your LAN applications are patched and up-to-date, and Suricata is detecting only inbound attempts and is not showing outbound malicious traffic from your LAN to known CnC hosts and such, then things are probably fine.  In the case of the traffic you posted, that was an inbound attempt.  Likey just a site "shooting blind" to see what was out there.  For the specific traffic you flagged, it would be targeted at BSD operating systems as it was a BSD shell code exploit.  Other than pfSense itself, do you have any BSD devices on your LAN?  If not, then no worries as pfSense itself is quite secure out-of-the-box.

Bill

@crept:

As for it to not show up in the Alerts tab, could this be a wrong configuration on my end?

Thank you Bill!

No, it's an issue with the way the Suricata binary logs drops when using Netmap.  I probably need to change the way the GUI gets alerts and drops when using the Inline IPS mode (which uses Netmap).  This happens from time to time.

Bill

I had the same issue. Turned out I had bad entry in the whitelist alias, forgot to put 0's for the Net address. Corrected it and problem went away.

@bbspace:

Thank you for this reply, Bill. I thought this was the case; I couldn't figure out why I just didn't get it.

I appreciate your work in maintaining the package. May I suggest a feature that would allow to PCRE through the rules folder and pick just the rules wanted would be nice. If I have the time maybe I'll try a submitting a PR after I delve deeper into the package source. Cheers!

All of the code for the SID MGMT rule selection logic is in the file /usr/local/pkg/snort/snort.inc and the initial function in that file is snort_prepare_rule_files().  That main function calls a number of other functions to build the rule set using the SID MGMT configurations.  It is all commented fairly well.  The one big concern would be not to break any of the existing functionality, so lots of testing would be required to verify no unexpected behavior creeps in.

Bill

UPDATE

This problem turned out to be a typo in the updated MD5 filename on the Snort.org download site.  After some email communications with the Snort team the problem was corrected on their download site.  This issue should be resolved now.

Bill

This problem should be fixed now.  I heard back from the Snort.org team and the typo in the MD5 filename has been corrected.

Bill

I apologize about the lack of info it is below. As far as I can tell the updating is working (log below).

pfSense: 2.4.3-RELEASE (amd64)
built on Mon Mar 26 18:02:04 CDT 2018
FreeBSD 11.1-RELEASE-p7

snort:3.2.9.6_1

Manage Rule Set Log:

Starting rules update…  Time: 2018-01-14 03:26:58
Downloading Snort VRT rules md5 file snortrules-snapshot-2990.tar.gz.md5...
Checking Snort VRT rules md5 file...
There is a new set of Snort VRT rules posted.
Downloading file 'snortrules-snapshot-2990.tar.gz'...
Done downloading rules file.
Downloading Snort GPLv2 Community Rules md5 file community-rules.tar.gz.md5...
Checking Snort GPLv2 Community Rules md5 file...
There is a new set of Snort GPLv2 Community Rules posted.
Downloading file 'community-rules.tar.gz'...
Done downloading rules file.
Extracting and installing Snort VRT rules...
Using Snort VRT precompiled SO rules for FreeBSD-10-0 ...
Installation of Snort VRT rules completed.
Extracting and installing Snort GPLv2 Community Rules...
Installation of Snort GPLv2 Community Rules completed.
Copying new config and map files...
Updating rules configuration for: WAN ...
The Rules update has finished.  Time: 2018-01-14 03:27:36

Starting rules update...  Time: 2018-05-02 07:56:00
Downloading Snort Subscriber rules md5 file snortrules-snapshot-2990.tar.gz.md5...
Checking Snort Subscriber rules md5 file...
There is a new set of Snort Subscriber rules posted.
Downloading file 'snortrules-snapshot-2990.tar.gz'...
Done downloading rules file.
Downloading Snort GPLv2 Community Rules md5 file community-rules.tar.gz.md5...
Checking Snort GPLv2 Community Rules md5 file...
There is a new set of Snort GPLv2 Community Rules posted.
Downloading file 'community-rules.tar.gz'...
Done downloading rules file.
Extracting and installing Snort Subscriber Ruleset...
Using Snort Subscriber precompiled SO rules for FreeBSD-10-0 ...
Installation of Snort Subscriber rules completed.
Extracting and installing Snort GPLv2 Community Rules...
Installation of Snort GPLv2 Community Rules completed.
Copying new config and map files...
Updating rules configuration for: WAN ...
The Rules update has finished.  Time: 2018-05-02 07:56:26

Starting rules update...  Time: 2018-05-02 10:08:45
Downloading Snort Subscriber rules md5 file snortrules-snapshot-29111.tar.gz.md5...
Checking Snort Subscriber rules md5 file...
There is a new set of Snort Subscriber rules posted.
Downloading file 'snortrules-snapshot-29111.tar.gz'...
Done downloading rules file.
Downloading Snort GPLv2 Community Rules md5 file community-rules.tar.gz.md5...
Checking Snort GPLv2 Community Rules md5 file...
There is a new set of Snort GPLv2 Community Rules posted.
Downloading file 'community-rules.tar.gz'...
Done downloading rules file.
Extracting and installing Snort Subscriber Ruleset...
Using Snort Subscriber precompiled SO rules for FreeBSD-10-0 ...
Installation of Snort Subscriber rules completed.
Extracting and installing Snort GPLv2 Community Rules...
Installation of Snort GPLv2 Community Rules completed.
Copying new config and map files...
Updating rules configuration for: WAN ...
The Rules update has finished.  Time: 2018-05-02 10:09:13

Thanks

I still don't really understand what you want as an end game here.  Your last rule is simply going to pass everything on any port that is sourced from $MY_NETWORK to anywhere so long as the SYN and ACK flags are set on the TCP packet.  PASS rules have priority in the processing chain, and once a PASS rule matches for a packet no other examination takes place against any additional rules.  The packet is passed.

Why don't you just filter by specific IP addresses (and maybe ports if possible) within the firewall itself and leave the IDS out of it?  Suricata and Snort rules typically are used to find malicious content, so they are designed to trigger when certain byte sequences are detected within the payload.  It seems like you are wanting to use to pass only selected content.  That is going to be a bit harder.

Bill

The only issue I have had is the netmap_grab_packets and the only adjustment I have done is the potential solution that you have read which has been running smoothly except for the one encounter mentioned. Of course, mine wasn't a VM. I will update my thread later this week. I would not mess with dev.netmap.admode nor try to "tune" the NIC…I have found that the tuning made things only worst. Be also sure to disable the items recommended in System > Advanced > Networking.

Hey there, I was searching on the forums and the web to see which network adapters support and work with inline mode - netmap.

I've found these and not sure if they're fixed in the current version.

Inline mode doesn't permanently block an IP, only legacy mode does that.

Inline mode breaks traffic shape, legacy mode doesn't

Inline mode breaks VLANs, legacy mode doesn't

Inline mode prevents packet leakage, legacy mode doesn't

Apparently there are only a sub-section of hardware that fully supports Netmap…
Netmap / FreeBSD has issues with Intel i340, i350/v2, i210, i211, i217 ,i219, PRO/1000, 82575/82576/82579/82580 and Realtek RTL8168B NIC's.

@bmeeks:

Netmap compatibility must exist at the software layer where the NIC driver meets the operating system…
There have been (and probably still are) some issues/bugs in both the FreeBSD implementation of Netmap and in Suricata's use of Netmap.

I have a Dell 0HM9JY Intel 82576 Gigabit ET quad port NIC (Intel PRO/1000 ET) and have the same error messages:

549.863394 [1071] netmap_grab_packets bad pkt at 91 len 2164 549.864619 [1071] netmap_grab_packets bad pkt at 95 len 2163 550.034152 [1071] netmap_grab_packets bad pkt at 197 len 2164 550.035448 [1071] netmap_grab_packets bad pkt at 199 len 2164

I have also turned off hardware-based checksums, TCP segmentation offloading and LRO (Large Receive Offloading), then reboot pfsense. Error still persists and doesn't seem to work properly or as intended.