Do you actually know of any tests to verify snort is in fact performing IPS? Other than being flooded by Snort info logs, I have yet to see any logs indicating a drop.
You will see a literal [drop] in your log.
02/22-17:29:44.599033 [drop] [**] [1:408:8] "PROTOCOL-ICMP Echo Reply" [**] [Classification: Misc activity] [Priority: 3] {ICMP} xxx.xxx.25.204 -> 10.9.7.181
here is what a good majority of logs look like so far.
Wed Mar 29 14:02:49 2023 auth.info snort: [1:27938:3] "PROTOCOL-DNS IPv6 host name enumeration" [Classification: Attempted Information Leak] [Priority: 2] {UDP} 192.168.1.14:19784 -> 213.196.12.1:53
Wed Mar 29 14:02:49 2023 auth.info snort: [1:27938:3] "PROTOCOL-DNS IPv6 host name enumeration" [Classification: Attempted Information Leak] [Priority: 2] {UDP} 192.168.1.14:37720 -> 213.196.11.1:53
Wed Mar 29 14:02:49 2023 auth.info snort: [1:27938:3] "PROTOCOL-DNS IPv6 host name enumeration" [Classification: Attempted Information Leak] [Priority: 2] {UDP} 192.168.1.14:56574 -> 213.196.12.1:53
Wed Mar 29 14:02:49 2023 auth.info snort: [1:27938:3] "PROTOCOL-DNS IPv6 host name enumeration" [Classification: Attempted Information Leak] [Priority: 2] {UDP} 192.168.1.14:13640 -> 172.64.33.86:53
Wed Mar 29 14:02:49 2023 auth.info snort: [1:27938:3] "PROTOCOL-DNS IPv6 host name enumeration" [Classification: Attempted Information Leak] [Priority: 2] {UDP} 192.168.1.14:13557 -> 173.233.156.1:53
Wed Mar 29 14:02:50 2023 auth.info snort: [116:434:1] "(icmp4) ICMP ping Nmap" [Priority: 3] {ICMP}
Wed Mar 29 14:04:14 2023 auth.info snort: "(ipv4) IPv4 datagram length > captured length"
Wed Mar 29 14:04:14 2023 auth.info snort: "(ipv4) IPv4 datagram length > captured length"
Wed Mar 29 14:04:14 2023 auth.info snort: "(arp_spoof) unicast ARP request"
Wed Mar 29 14:05:51 2023 auth.info snort: [116:58:1] "(tcp) experimental TCP options found" [Priority: 3] {TCP} 77.57.195.6:38956 -> 204.61.216.91:53
Wed Mar 29 14:05:51 2023 auth.info snort: [116:58:1] "(tcp) experimental TCP options found" [Priority: 3] {TCP} 192.168.1.14:38956 -> 204.61.216.91:53
but no indications of anything actually having to be blocked.
do you get frequent periods with nothing being blocked?
I only setup mine instance running on my router with 2x NICs. Is this your configuration? All of the info I used to configure mine is on the wiki page I updated. I suspect you do not have it correctly configured for IPS mode. Did you edit all the files I called out on the wiki page?
Yes i followed all the editing and i switched to using two nics as well.
Not sure, review my configs and diff against yours.
/etc/config/snort
config snort 'snort'
option config_dir '/etc/snort/'
option interface 'eth0:eth1'
/etc/snort/homenet.lua
HOME_NET = [[ 10.9.1.0/24 10.9.2.0/24 10.9.3.0/24 ]]
EXTERNAL_NET = "!$HOME_NET"
/etc/snort/local.lua
-- use ths file to customize any functions defined in /etc/snort/snort.lua
-- switch tap to inline in ips and uncomment the below to run snort in inline mode
snort = {}
snort["-Q"] = true
ips = {
-- mode = tap,
mode = inline,
variables = default_variables,
action_override = 'drop',
-- uncomment and change the below to reflect rules or symlinks to rules on your filesystem
include = RULE_PATH .. '/snort.rules',
}
daq = {
module_dirs = {
'/usr/lib/daq',
},
modules = {
{
name = 'afpacket',
mode = 'inline',
}
}
}
-- To log to a file, uncomment the below and manually create the dir defined in output.logdir
output.logdir = '/mnt/mmcblk0p3'
alert_fast = {
file = true,
packet = false,
}
normalizer = {
tcp = {
ips = true,
}
}
file_policy = {
enable_type = true,
enable_signature = true,
rules = {
use = {
verdict = 'log', enable_file_type = true, enable_file_signature = true
}
}
}
Dropping packages does not work in general, at least not on the stable snort x86 version. I have helped myself by configuring the active plugin to reject but this is only a stopgap solution that initially did not work until after the update to openwrt 22.03.1, before that the inject packages could not be inserted. I strongly suspect that the afpacket DAQ available in Openwrt 22.0.3.x is buggy or incomplete.
You can try with DAQ NFQ in my post Snort 3 + NFQ with IPS mode - Installing and Using OpenWrt - OpenWrt Forum
1 Like
Thanks to you I will try it right away. I am always failed at the queue and my request here in the forum remained unfortunately unanswered.
Not many forum users run snort is my guess. Why not try a snapshot which uses snort3?
I've read that IDS/IPS solutions (snort, suricata) require a lot of cpu, as it has to examine all the wan and/or LAN traffic (depending on what you want) against a set of rules (more rules will also make more load).
The use of cpu is proportional to the traffic passing and to the number of rules.
I also read that to examine all traffic, we need to disable any kind of HW acceleration, so the package can go to the cpu to be examined.
Hyperscan may help as well. Not sure about reduction of CPU load but performance is well documented. Trying here:
1 Like
I have 500/100Mbits fiber and a Dynalink DL-WRX36 snapshot (4 core arm a53@2.2Ghz, 500MB free ram).
Could you give me an idea/expectation of what bandwidth can snort3 process in my router ? Or do I need a x86, something like a intel N5105?
I have 1200 Mbps down and 30 up. RPi4B has plenty of CPU to run snort3 and QoS for bufferbloat.
1 Like
@ sqrwv better forget about Snort on your line, because you need to disable the very network card options that are responsible for network performance in order for Snort to work properly. I guess to fully use your line with Snort you will need more like an 8 core.
1 Like
I'll give it a try when I have some time, that is +- what I was expecting.
I also have a N5105 with 4x2.5Gbit eth (and 16GB ram I had already).
Can only try but really much hope that it works without restrictions I do not make you, because the Nfq method Snort 3 + NFQ with IPS mode at Openwrt is the only method that really works at time, at Afpacket bypasses the FW4 nft firewall snort therefore drop does not work there. I tested the nft method on an Apu 2 (Amd 4 Core) and I always hung with a queue at 75Mbit max with no visible cpulimit. That means if you want to max out your bandwidth you would need at least 8 queues problem is it only makes sense to have one per cpu core/thread.
1 Like
I'll follow the other thread you linked to see how it goes.
Thanks
I haven't been successful at getting snort working on my N5105/2.5GbE box yet, so I'm very interested in your experiences. (NICs seem to lock up, no TX when snort starts...) Works just fine (well, for some wacky definition of "fine") on an x86 VM, so that's where I've been working on it.
We've moved most of the action over to IPS mode of snort3 is not dropping traffic at this point.
1 Like
Hi all
@efahl asked me to add a reply to this post. I recently updated my Mochabin to 23.05 rc2. Previously I was on 22.03.4 and whilst on that I was running snort 3 in IDS mode which I'd configured using the instructions held at Openwrt snort wiki
I think it was running ok, it passed the verification bit at the end and the service started ok. I don't know for sure if it was working because I never found any alerts in the log, and hadn't got around to testing it. The service was showing as running, using about 5% CPU, so I assumed it must be doing something.
Anyways, I then updated to 23.05 rc2 and tried setting up snort 3 using the same wiki page. In short it didn't work, and even though I ran it in IDS mode it still killed my internet connection. I put a post here in the 23.05 rc2 forum which includes a bit more detail.
For info, the Mochabin spec is here , I have the 8GB RAM version, with the Qualcomm wireless chip which I think matches this spec
If it would help for me to run any tests from my end, feel free to tell me what you need doing, but use short sentences and simple words cos I'm nowhere near as tech savvy as some of you guys. I may not reply quick but that's just cos I've got a few dramas occurring at the moment, but will assist when I can.
Thanks all. Happy
1 Like