At least, enable signature logging in Snort. Then, you'll see what blocking signatures (if any) are being blocked and could ignore/suppress those.

@siil-it
So the Snort SO rules are the only ones that don't survive the SAVE operation? Do you have the latest Snort package version? That would be 3.2.9.7_2 if my memory serves me correctly.

Might be a bug in the GUI code. Several changes have had to be made to the GUI source code in order to accomodate the move to PHP 7.2 in pfSense.

@teamits is correct. The ALERTS tab will list SRC and DST addresses for detected alerts. He is also correct on which IP will show depending on the chosen interface on which to run Snort. I recommend running Snort on the LAN interface. That way you can see internal addresses before NAT rules are applied (in the case of outbound traffic) and after NAT rules are removed (in the case of inbound traffic from the Internet). On the WAN, all local IP addresses behind NAT will just show up as having your public WAN IP. That's not useful for tracking down which internal host has a problem.

You should pretty much always let Snort block both SRC and DST IP addresses to be confident the bad traffic is stopped. Anti-virus software has no bearing on this. It detects different things and misses other things. For example, anti-virus software won't detect buffer overflows in your web browser or services. Basic anti-virus software examines executables as they run (or right before), but it does not examine network flows/streams like a true IDS/IPS such as Snort or Suricata.

Thank you, Bill.

@bmeeks Thank you for your candid answer bmeeks. Duly noted and will not be attempted.

Have you made a pass list yet?

Thanks for the responses!

It is interesting as I just installed the Snort package the other day so I THOUGHT it would be the most up to date. If the problem was with the OINK code, then it makes sense that the error would be different also.

The 505 code makes it seem like the client cannot speak with the server properly to get the ruleset.
Perhaps it was the time of day - something wrong on the server end with retrieving the file. I'll have to try again later.

@stalemartyr said in Snort newbie : LAN Interface Destination IP setup:

Good day, I recently configured a pfsense in our office and enabled snort package. I configured LAN interface and noticed that all the alerts traffic is from local network to internet i.e. 192.168.1.105 => [external ip address], can I configure it so that it will also show suspicious traffic from router to lan network? [external ip address/pfsense] => 192.168.1.105. Thanks!

It should already be doing that if such traffic exists. Remember that by default the WAN on pfSense is configured to block all unsolicited inbound traffic. That means your LAN interface will never see something unsolicited from the Internet (say a connection attempt to SSH or something unless you have port forwarding enabled, and enabling port forwards is generally not a secure practice -- use VPNs instead for external connections to your LAN).

You get the alert because ntopng checks for updates from ntopng's own website and not the pfSense package.

Ignore the alert. When it's updated, you'll see a package update in pfSense, not inside ntopng.

@kwicky said in Manual installation of Snort:

@bmeeks
@jimp

Just viewed the Snort logs and seems everything went wonky donky when storm Hector hit the UK on June 14th.

It's possible a power disturbance caused disk corruption on your firewall. Is your firewall on a UPS (uninterruptable power supply)? If not, you might want to consider adding one as that will protect you from power surges and brownouts/blackouts like those caused by storms.

Those messages are somewhat common. The AppId values will vary. The messages mean a rule is referencing an AppID code that is not defined. I've been seeing these messages ever since Snort released AppID to the public domain. They won't stop Snort from running.

Be aware that AppID is extremely noisy and will overwhelm your logs on a busy network. It will bury other traffic in a lot of useless noise. AppID might have its place in a tap monitor setup, but I would never enable it on a firewall with Snort configured for blocking. Doing so will basically immediately kill your network. The only exception would be if you only enabled a very tiny handful of OpenAppID rules.

@aminbaik said in snort file:

Hello,
which snort file I have to use with suricata ?
snortrules-snapshot-29111.tar.gz
snortrules-snapshot-29110.tar.gz
snortrules-snapshot-2983.tar.gz
snortrules-snapshot-2990.tar.gz
snortrules-snapshot-3000.tar.gz
and what the deferent between them ?
thanks.

You can use any of the Snort 2.x files, but you can't use the Snort 3.x file. You would want to use the latest Snort 2.x file which is the snortrules-snapshot-29111.tar.gz file. It is for the 2.9.11.1 version of Snort.

While it is technically possible, I do not recommend it. You can't run both in blocking mode as they will step on each other at times. Pick one and stick with it. If you want to use OpenAppID, then choose Snort.

@trumee, please report this on the Redmine bug reporting site at https://redmine.pfsense.org/. This is a warning message from the new PHP 7 interpreter. It is harmless for now, but if you report it on the Redmine site it will get logged and corrected.

Thanks,
Bill

@rogg said in snort blocking dns servers:

its other trouble - snort blocking dns ip address which is whitelisted in snort configuration.

When Snort blocks on a triggered alert, it can block either the Source IP, Destination IP or Both depending on a setting on the Interface Configuration tab. As @NogBadTheBad stated, check the Alerts tab to see which rule or rules are being triggered and blocking. You can filter on the tab by IP address to help in locating rules with your DNS server IP in either the SRC or DST columns.

Thank you Nog, that's done the trick.