Snort 3.2.9.9_1 configuration problem
-
Hello, I'm very new of pfsense, and I'm experiencing a problem with snort configuration: I have a uplink modem (10.0.10.254/24) going to pfsense WAN interface (10.0.10.250/24) with LAN (10.0.40.1/24) and WLAN interface (10.0.60.1/24). Configured snort 3.2 (on WAN, LAN, WLAN) with register rule set, ET, GPLv2 and OpenAppID and experienced a blocked connection at sposts on LAN and WLAN. I suspect there is a rule that put on block list the pfsense WAN interface. Is it safe (or it's possible) to put it on whitelist? I'm strunggling with this from days, please help me solve this. Thanks
-
Something about your setup has misconfiguration especially if you're blocking LAN/Wlan. It helps us to better diagnose and guide you when you also post screen shots of your Snort config.
-
This is my configuration:
here have selected all categories
Thanks for your help
-
-
Also have these settings on all interfaces:
-
You state you are a new pfSense user. Have you ever used an IDS/IPS package before? If not, you should never, ever enable blocking out of the gate. You should first enable the IDS in non-blocking mode and then run that way with your configured rules for at least a week, and preferrably longer, if you are very new to an IDS. Examine the alerts you receive and then research each one to determine if it is a false positive in your network environment. If you determine a given rule false positives in your setup, then disable that rule or suppress it.
The ALERTS tab will show you every alert received for a configured Snort interface. There is a drop-down selector on that tab to let you choose which interface to display the alerts for.
Installing the IDS/IPS package and then immediately enabling blocking mode when you are new to administering an IDS/IPS results in exactly what is happening to you -- namely false positives and nuisance blocks.
Turn off blocking mode, go to the BLOCKED tab and clear all existing blocks, then run that way for two weeks and examine the received alerts at least once per day and determine which rules you do not need.
Configuring and adminstering an IDS/IPS requires a specific skill set. And even then a willingness on the part of the admin to spend a lot of time researching things on Google and other resources. You can't just install the Snort package, take a default setup, and get a happy result. An IDS/IPS package such as Snort or Suricata is way more complicated than installing say an anti-virus client and enabling the download of virus signatures.
-
Thank you for the tips, I will run on non blocking mode and supress rules I dont need. Does option "Block private networks and loopback addresses" create me problems if I recive uplink from 10.0.10.254/24 and other interfaces are on class 10.40.x.x/24 ?
-
@v0id said in Snort 3.2.9.9_1 configuration problem:
Thank you for the tips, I will run on non blocking mode and supress rules I dont need. Does option "Block private networks and loopback addresses" create me problems if I recive uplink from 10.0.10.254/24 and other interfaces are on class 10.40.x.x/24 ?
Yes, blocking those private address spaces would be an issue for you based on the way you described your setup. The problem will exist only on your WAN interface, though. Having private addresses on the other firewall interfaces is OK (and even, generally, expected).
-
Also want to add pfblocker, is it better to setup snort firstand then pfblocker with DNSBL?
-
@v0id said in Snort 3.2.9.9_1 configuration problem:
Also want to add pfblocker, is it better to setup snort firstand then pfblocker with DNSBL?
No, there is really no relation between those two packages in terms of when to install one or the other. They perform somewhat different tasks. pfBlocker works from lists of IP addresses and creates firewall rules using those lists to populate the SRC and/or DST IP address fields. DNSBL is primarily for ad filtering.
An IDS/IPS such as Snort actually examines the payload in packets as they traverse the firewall and detects threats that way. It does not just look only at the IP addresses, although you can create IP-only type rules using Snort.
To contrast the two packages, pfBlocker might have a given web host in one of its blocklists and would thus block all traffic from that host no matter if the traffic was actually benign or not. Snort would instead examine each packet and look for actual threats in the packet payloads and make a block decision based on its findings. In that manner, non-malicious traffic from the web host would be passed (at least up until the point that a malicious payload from the host was detected; at that point all further traffic from that host would be blocked).
-
Thanks, I have ideas clearer now :)
Last question: Is it better snort or suricata? Before tryied suricata also, and didn't have much problems in configurations, found it working good and easy to configurate. Read suricata works on multi thread, but doesn't support all snort VRT rules. Ever heard good reviews about snort, but still working on single thread. Also read Cisco is working on Snort++ that will be multi thread. What should I use for keep a very good level of security?
-
@v0id said in Snort 3.2.9.9_1 configuration problem:
Thanks, I have ideas clearer now :)
Last question: Is it better snort or suricata? Before tryied suricata also, and didn't have much problems in configurations, found it working good and easy to configurate. Read suricata works on multi thread, but doesn't support all snort VRT rules. Ever heard good reviews about snort, but still working on single thread. Also read Cisco is working on Snort++ that will be multi thread. What should I use for keep a very good level of security?
There is zero difference between the two in terms of security. And the multithreaded thing is sort of not really all that important unless you are pushing like 10 gigabits/sec of traffic. There have been several tests in the past at more typical user Internet speeds (1 gigabit/sec and under) where Snort and Suricata tested out as more or less equals in packets per second performance under real world conditions.
It is true that some Snort rules have keywords that Suricata does not recognize, but there is a Suricata-optimized set of Emerging Threats rules that can sort of make up for that. The downside is that those more current ET rules require you to purchase a very expensive ET-Pro subscription. Otherwise, the free ET-Open rules are at least 30 days old and do not contain all of the threat detections contained in the ET-Pro rules.
In the end it simply comes down to what you like. Suricata is multithreaded if that is important to you, and it offers built-in EVE JSON logging and does, in general, offer better logging options than Snort. However, Snort offers the Layer 7 DPI feature called OpenAppID which Suricata lacks.
