Suricata Suricata - IDS on AsusWRT Merlin

[Mutzli]

And with the new suricata.yaml "attack_response.rules" loaded it's working as well:

suricata -T
28/7/2020 -- 08:55:38 - <Info> - Running suricata under test mode
28/7/2020 -- 08:55:38 - <Info> - Configuration node 'legacy' redefined.
28/7/2020 -- 08:55:38 - <Notice> - This is Suricata version 4.1.8 RELEASE
28/7/2020 -- 08:55:38 - <Info> - CPUs/cores online: 4
28/7/2020 -- 08:55:38 - <Info> - fast output device (regular) initialized: fast.log
28/7/2020 -- 08:55:38 - <Info> - stats output device (regular) initialized: stats.log
28/7/2020 -- 08:55:38 - <Info> - 20 rule files processed. 3110 rules successfully loaded, 0 rules failed
28/7/2020 -- 08:55:38 - <Info> - Threshold config parsed: 0 rule(s) found
28/7/2020 -- 08:55:38 - <Info> - 3110 signatures processed. 224 are IP-only rules, 567 are inspecting packet payload, 2458 inspect application layer, 0 are decoder event only
28/7/2020 -- 08:55:42 - <Notice> - Configuration provided was successfully loaded. Exiting.
28/7/2020 -- 08:55:42 - <Info> - cleaning up signature grouping structure... complete

I still don't know why my initial setup got screwed up when updating to the latest .yaml configuration.

 

[jata]

I have suricata working fine for the last month and have just updated to the latest yaml - restarted and all working great. Big thanks to everyone involved in this project.

Latest yaml enables br0 and eth0 (and br0 is new for my config). Now seeing fast log entries for dropbox and a few other things that I am not concerned about ( so noise or 'false positives' for my setup). Is it possible to edit the rules to stop these from logging? If so, how?

thanks again.

 

[Smokey613]

This is a snippet from my /opt/etc/suricata/threshold.config file. I added the last line to suppress a Govee sensor. Change the sig_id and IP address to match your device. It would need a static assigned IP either in DHCP or on the device itself.


Avoid to alert on f-secure update
# Example taken from https://blog.inliniac.net/2012/03/07/f-secure-av-updates-and-suricata-ips/
#suppress gen_id 1, sig_id 2009557, track by_src, ip 217.110.97.128/25
#suppress gen_id 1, sig_id 2012086, track by_src, ip 217.110.97.128/25
#suppress gen_id 1, sig_id 2003614, track by_src, ip 217.110.97.128/25
suppress gen_id 1, sig_id 2013028, track by_src, ip 192.168.2.158/25

 

[jata]

This is a snippet from my /opt/etc/suricata/threshold.config file. I added the last line to suppress a Govee sensor. Change the sig_id and IP address to match your device. It would need a static assigned IP either in DHCP or on the device itself.


Avoid to alert on f-secure update
# Example taken from https://blog.inliniac.net/2012/03/07/f-secure-av-updates-and-suricata-ips/
#suppress gen_id 1, sig_id 2009557, track by_src, ip 217.110.97.128/25
#suppress gen_id 1, sig_id 2012086, track by_src, ip 217.110.97.128/25
#suppress gen_id 1, sig_id 2003614, track by_src, ip 217.110.97.128/25
suppress gen_id 1, sig_id 2013028, track by_src, ip 192.168.2.158/25

perfect. thanks. something else to play around with!

 

[XIII]

I have also been experimenting with thresholds this week.

Can we also use domain names instead of IP's for track by_src/by_dst? If so, how?

 

[Smokey613]

This is a snippet from my /opt/etc/suricata/threshold.config file. I added the last line to suppress a Govee sensor. Change the sig_id and IP address to match your device. It would need a static assigned IP either in DHCP or on the device itself.


Avoid to alert on f-secure update
# Example taken from https://blog.inliniac.net/2012/03/07/f-secure-av-updates-and-suricata-ips/
#suppress gen_id 1, sig_id 2009557, track by_src, ip 217.110.97.128/25
#suppress gen_id 1, sig_id 2012086, track by_src, ip 217.110.97.128/25
#suppress gen_id 1, sig_id 2003614, track by_src, ip 217.110.97.128/25
suppress gen_id 1, sig_id 2013028, track by_src, ip 192.168.2.158/25

The subnet should be a /32 not a /25 to block a single IP. I should have caught that earlier.

 

[alekos]

Just had a quick question. I ran the new installation script (my setup is just Diversion/Skynet/Pixelserv, no AIProtection) everything else default settings, and the script automatically filled in these settings:
HOME_NET: "[192.168.50.0/24]"
DNS_SERVERS: "[127.0.0.1]"
af-packet:
- interface: eth0
- interface: br0
Should I change the CID to /16 and DNS to 192.168.50.1, and remove the "-interface: br0" since my wan ip on ifconfig shows it as eth0?

It looks like everything is working, I get this output with the -T command:
30/7/2020 -- 02:33:00 - <Info> - Running suricata under test mode
30/7/2020 -- 02:33:00 - <Info> - Configuration node 'legacy' redefined.
Warning: Output_interface not supplied by user. Falling back on default_output_interface "Console"
30/7/2020 -- 02:33:00 - <Notice> - This is Suricata version 4.1.8 RELEASE
30/7/2020 -- 02:33:00 - <Info> - CPUs/cores online: 2
30/7/2020 -- 02:33:00 - <Info> - fast output device (regular) initialized: fast.log
30/7/2020 -- 02:33:00 - <Info> - stats output device (regular) initialized: stats.log
30/7/2020 -- 02:33:00 - <Info> - 20 rule files processed. 3110 rules successfully loaded, 0 rules failed
30/7/2020 -- 02:33:00 - <Info> - Threshold config parsed: 0 rule(s) found
30/7/2020 -- 02:33:00 - <Info> - 3110 signatures processed. 224 are IP-only rules, 567 are inspecting packet payload, 24y
30/7/2020 -- 02:33:04 - <Notice> - Configuration provided was successfully loaded. Exiting.
30/7/2020 -- 02:33:04 - <Info> - cleaning up signature grouping structure... complete

 

[jata]

Just had a quick question. I ran the new installation script (my setup is just Diversion/Skynet/Pixelserv, no AIProtection) everything else default settings, and the script automatically filled in these settings:
HOME_NET: "[192.168.50.0/24]"
DNS_SERVERS: "[127.0.0.1]"
af-packet:
- interface: eth0
- interface: br0
Should I change the CID to /16 and DNS to 192.168.50.1, and remove the "-interface: br0" since my wan ip on ifconfig shows it as eth0?

It looks like everything is working, I get this output with the -T command:
30/7/2020 -- 02:33:00 - <Info> - Running suricata under test mode
30/7/2020 -- 02:33:00 - <Info> - Configuration node 'legacy' redefined.
Warning: Output_interface not supplied by user. Falling back on default_output_interface "Console"
30/7/2020 -- 02:33:00 - <Notice> - This is Suricata version 4.1.8 RELEASE
30/7/2020 -- 02:33:00 - <Info> - CPUs/cores online: 2
30/7/2020 -- 02:33:00 - <Info> - fast output device (regular) initialized: fast.log
30/7/2020 -- 02:33:00 - <Info> - stats output device (regular) initialized: stats.log
30/7/2020 -- 02:33:00 - <Info> - 20 rule files processed. 3110 rules successfully loaded, 0 rules failed
30/7/2020 -- 02:33:00 - <Info> - Threshold config parsed: 0 rule(s) found
30/7/2020 -- 02:33:00 - <Info> - 3110 signatures processed. 224 are IP-only rules, 567 are inspecting packet payload, 24y
30/7/2020 -- 02:33:04 - <Notice> - Configuration provided was successfully loaded. Exiting.
30/7/2020 -- 02:33:04 - <Info> - cleaning up signature grouping structure... complete

you can leave both interfaces in suricata.yaml as this will enable monitoring on the wan (eth0) and lan (br0) - but be aware there will be lots of log entries generated with br0 included.

I have my DNS set to router IP - so 192.168.50.1 on your config but it 'might' work fine using 127.0.0.1

Output from the -T command looks good so suggest you start the service and check the log...

 

[juched]

I took the plunge and setup suricata on my RT-AX88U. I did it manually, not hard, Thanks @rgnldo.

Changed the setup to log only to syslog and no stats currently. When using top, I see the memory usage at 772m (WOW!). But things are running and free command shows that buffers/cache still has 250MB, so not too tight.

One thing I did notice though, if I tail -f /opt/var/log/suricata/fast.log or if I vi /opt/etc/suricata/suricata.yaml, the running service immediately shutdown with this message:

<Notice> - Signal Received.  Stopping engine.

Could this be a self protection? Anyone see this?

Nothing else edited in the YAML other than DNS_IP and adding eth0 to af file.

 

[alekos]

you can leave both interfaces in suricata.yaml as this will enable monitoring on the wan (eth0) and lan (br0) - but be aware there will be lots of log entries generated with br0 included.

I have my DNS set to router IP - so 192.168.50.1 on your config but it 'might' work fine using 127.0.0.1

Output from the -T command looks good so suggest you start the service and check the log...

thanks jata, I appreciate your response. I had one more question, if I add another 'interface' line for my vpn server, (tun21) would it scan the vpn connection also?

edit>> more importantly, the service stops after a few minutes. Would anyone know why the service would be stopping? I have a fresh install of suricata.

 

[juched]

Been playing around with suricata.

The mode in the YAML file is just IDS, it will detect and write to the logs, but cannot drop any packets. This is because it is getting a copy via af_packet mode (the only mode compiled into our copy of suricata).

You can enabled IPS so it can drop packets as well. It works by using af_packet mode to "copy" the packet from one interface to another, acting as a bridge or filter. If you use "tap" copy mode it is a bridge, and doesn't do any dropping of packets, and if you use "ips" copy mode then it can drop packets.

You can play with this mode by using the following config:

af-packet:         
  - interface: eth0                               
    threads: 1
    defrag: no               
    cluster-type: cluster_flow                                       
    cluster-id: 98
    copy-mode: ips             
    copy-iface: br0   
    buffer-size: 64535         
    use-mmap: yes           
    tpacket-v3: no           
  - interface: br0         
    threads: 1                 
    cluster-id: 97         
    defrag: no               
    cluster-type: cluster_flow
    copy-mode: ips           
    copy-iface: eth0       
    buffer-size: 64535     
    use-mmap: yes           
    tpacket-v3: no

What this is configuring is a copy of all packets from 1 interface (eth0 - WAN) to another (br0 - main LAN and main WIFI).

What I did find though was that in this mode it breaks all guest wifi since they do not go through br0 (at last when using YazFi).

Will keep playing with it.

Can still reproduce the "signal detected. stopping engine" issue if I do something like "tail -f /opt/var/log/suricata.log". So odd, no clue why. If it is restarted via the nightly 3AM update, it doesn't seem to get the signal, so something about how init.d starts it from the command line I guess.

 

[Mutzli]

Been playing around with suricata.

The mode in the YAML file is just IDS, it will detect and write to the logs, but cannot drop any packets. This is because it is getting a copy via af_packet mode (the only mode compiled into our copy of suricata).

You can enabled IPS so it can drop packets as well. It works by using af_packet mode to "copy" the packet from one interface to another, acting as a bridge or filter. If you use "tap" copy mode it is a bridge, and doesn't do any dropping of packets, and if you use "ips" copy mode then it can drop packets.

You can play with this mode by using the following config:

af-packet:       
  - interface: eth0                             
    threads: 1
    defrag: no             
    cluster-type: cluster_flow                                     
    cluster-id: 98
    copy-mode: ips           
    copy-iface: br0 
    buffer-size: 64535       
    use-mmap: yes         
    tpacket-v3: no         
  - interface: br0       
    threads: 1               
    cluster-id: 97       
    defrag: no             
    cluster-type: cluster_flow
    copy-mode: ips         
    copy-iface: eth0     
    buffer-size: 64535   
    use-mmap: yes         
    tpacket-v3: no

What this is configuring is a copy of all packets from 1 interface (eth0 - WAN) to another (br0 - main LAN and main WIFI).

What I did find though was that in this mode it breaks all guest wifi since they do not go through br0 (at last when using YazFi).

Will keep playing with it.

Can still reproduce the "signal detected. stopping engine" issue if I do something like "tail -f /opt/var/log/suricata.log". So odd, no clue why. If it is restarted via the nightly 3AM update, it doesn't seem to get the signal, so something about how init.d starts it from the command line I guess.

That's very interesting, I have to try this out. What did you use to test it to proof if this works as intended? So far I simply copy the IP address from fast.log over to Skynet firewall to have the filtered IP addresses blocked.

Edit: I tried your settings and the first thing I noticed was Suricata closed my SSH session because the port was blocked. I fixed that by entering the correct SSH_PORTS: in the Suricata.yaml under port-groups:

 

[juched]

Trying to figure out from the documentation examples which items are needed. Removing some items and this seems to enabled IPS in the logs at least. Not sure yet how to test.

af-packet:                                         
  - interface: eth0           
    copy-mode: ips       
    copy-iface: br0                 
    use-mmap: yes           
    tpacket-v3: no           
  - interface: br0           
    copy-mode: ips   
    copy-iface: eth0                                           
    use-mmap: yes     
    tpacket-v3: no

Currently running and my guest wifi networks have the regular regulated internet access. unsure why those other settings for flow or threads mattered... Will test to see, but this should enable dropping of bad traffic, not just alerting.

Edit: I was wrong. guest wifi stopped working again. I think it is related to the fact that all packets are now copied from eth0 to br0 and vise versa, and now the IP tables for the guest network are messed up. my iptables knowledge is light

 

[rgnldo]

copy-mode: ips
use-mmap: yes
tpacket-v3: no

Do not use these options. Possible incompatibility with NIC driver´s

These options are enough

# IPS Mode Configuration
pcap:
  - interface: auto
    checksum-checks: auto
    promisc: yes

 

[rgnldo]

The NETGEAR custon rom guys got interested in Suricata.
Netgear FW entware

 

[distilled]

The NETGEAR custon rom guys got interested in Suricata.
Netgear FW entware

"Imitation is the sincerest form of flattery"

 

[KW.]

rgnldo said ---
# IPS Mode Configuration
pcap:
  - interface: auto
    checksum-checks: auto
    promisc: yes

Well well, out of my dark Netgear chamber again to copy another line of code in to it.

 

[juched]

Do not use these options. Possible incompatibility with NIC driver´s

These options are enough

# IPS Mode Configuration
pcap:
  - interface: auto
    checksum-checks: auto
    promisc: yes

These settings are enabled in the default yaml and I didn't remove them, but they do not support IPS. If you want suricata to drop bad packets, you need to use an IDS mode, and with our build it is only with AF_PACKET.

But I thought I would try it anyways. For the section of the config file to have effect, you need to change the command line for starting suricta to replace --af-packet for --pcap (just having in the config file doesn't do anything.. you have pick the mode

According to the docs "Checksum offloading can be left enabled on AF_PACKET and PF_RING, but needs to be disabled on PCAP, NETMAP and others.", so it should be no, but it seems to auto detect no, so that is ok.

Aug  3 17:15:16 JucheRouter S82suricata: Starting Suricata IDS/IPS /opt/etc/init.d/S82suricata
Aug  3 17:15:17 JucheRouter suricata[15706]: 3/8/2020 -- 17:15:17 - <Info> - Going to use 1 thread(s)
Aug  3 17:15:17 JucheRouter suricata[15706]: 3/8/2020 -- 17:15:17 - <Info> - using interface eth0
Aug  3 17:15:17 JucheRouter suricata[15706]: 3/8/2020 -- 17:15:17 - <Info> - Running in 'auto' checksum mode. Detection of interface state will require 1000 packets.
Aug  3 17:15:17 JucheRouter suricata[15706]: 3/8/2020 -- 17:15:17 - <Info> - Found an MTU of 1500 for 'eth0'
Aug  3 17:15:17 JucheRouter suricata[15706]: 3/8/2020 -- 17:15:17 - <Info> - Set snaplen to 1524 for 'eth0'
Aug  3 17:15:17 JucheRouter suricata[15706]: 3/8/2020 -- 17:15:17 - <Info> - Going to use 1 thread(s)
Aug  3 17:15:17 JucheRouter suricata[15706]: 3/8/2020 -- 17:15:17 - <Info> - using interface br0
Aug  3 17:15:17 JucheRouter suricata[15706]: 3/8/2020 -- 17:15:17 - <Info> - Running in 'auto' checksum mode. Detection of interface state will require 1000 packets.
Aug  3 17:15:17 JucheRouter suricata[15706]: 3/8/2020 -- 17:15:17 - <Info> - Found an MTU of 1500 for 'br0'
Aug  3 17:15:17 JucheRouter suricata[15706]: 3/8/2020 -- 17:15:17 - <Info> - Set snaplen to 1524 for 'br0'
Aug  3 17:15:17 JucheRouter suricata[15706]: 3/8/2020 -- 17:15:17 - <Info> - RunModeIdsPcapWorkers initialised
Aug  3 17:15:17 JucheRouter suricata[15706]: 3/8/2020 -- 17:15:17 - <Notice> - all 2 packet processing threads, 2 management threads initialized, engine started.
Aug  3 17:15:19 JucheRouter suricata[15706]: 3/8/2020 -- 17:15:19 - <Info> - No packets with invalid checksum, assuming checksum offloading is NOT used
Aug  3 17:15:24 JucheRouter suricata[15706]: 3/8/2020 -- 17:15:24 - <Info> - No packets with invalid checksum, assuming checksum offloading is NOT used
Aug  3 17:18:18 JucheRouter suricata[15706]: [1:2100498:7] GPL ATTACK_RESPONSE id check returned root [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 31.3.245.133:80 -> 99.251.122.29:54493

As can be seen, pcap isn't an IPS mode, so no better than af_packet, which seems to be a mode which can support IPS, so we should probably stick to that.

 

[juched]

From this link :

In legacy mode, the pcap library is used to make a copy (clone if you will) of every packet as it comes in from the NIC on its way to the pf firewall engine. The original packet continues on to the pf firewall engine and is either passed or blocked depending on the current rules in the firewall. Meanwhile, the cloned packet is sent over to Suricata (or Snort if using that package) for inspection against the IDS/IPS rules. Should the cloned packet (or packets, since sometimes Suricata needs to see a group of packets before a decision can be made) be judged as "bad" by the Suricata engine, then a system call is made to insert the offending IP address from the packet into a special table in the pf firewall engine called snort2c. IP addresses in this special table are blocked. However, note that this decision making and subsequent insertion of the IP address into the snort2c table has happened well after the original packet (or packets if a group of packets was required to make a decision) has traversed the pf engine. So that original packet will have already gotten past the IPS mechanism. Packets that subsequently come through from the same IP address will now get blocked, though. Hence I use the term "hybrid IDS/IPS" because a true IPS would never leak a packet. A true IPS would hold up the original packet while it was being inspected, and then either pass it or drop it. Legacy mode does not hold up the original packet. It is allowed to continue on to the firewall while the cloned copy is used to make the decision for blocking future packets from the IP address.

With the new inline IPS mode, Suricata activates and uses the relatively new Netmap mechanism that was added to FreeBSD. Netmap is a way for applications to create a highspeed pipe between the NIC driver layer and the rest of the system. So packets coming and going on a given network interface must pass through the Netmap pipe. Suricata inline-mode controls the "door" in this pipe. Each packet stream coming from the NIC (or going to the NIC) is inspected by Suricata and a "pass" or "drop" decision is made. If a packet is dropped, it is never forwarded on to the pfSense kernel and thus never makes it to the pf engine. Since every single packet must traverse this Netmap pipe, there is no leakage. No copies of the packets are made for examination. Everything occurs with the original packet.

The downside of the new inline mode is that for now only some NIC drivers support working with the Netmap API mechanism. So while legacy mode is pretty much NIC card and driver agnostic (meaning it works with any hardware), the inline mode is highly dependent on your firewall having a NIC driver that supports Netmap. Another problem that currently exists is the Netmap pipe seems to break traffic shaping on the interface. I suspect this is a fixable problem, but no solution is in place yet.

From this paper it seems to me that sticking with af-packet is better.

AF_PACKET is the Linux native network socket. It functions similar to the memory mapped PCAP, but no external libraries are required

from the suricata docs it seems:

If using af-packet (default on Linux) it is recommended that af-packet v3 is used for IDS/NSM deployments. For IPS it is recommended af-packet v2. To make sure af-packet v3 is used it can specifically be enforced it in the af-packet config section of suricata.yaml like so:

af-packet:
- interface: eth0
....
....
....
use-mmap: yes
tpacket-v3: yes

Finally, workers mode is considered the best performance according to the suricata docs.

You can choose a runmode out of several predefined runmodes. The command line option –list-runmodes shows all available runmodes. All runmodes have a name: single, workers, autofp.

Generally, the workers runmode performs the best. In this mode the NIC/driver makes sure packets are properly balanced over Suricata’s processing threads. Each packet processing thread then contains the full packet pipeline.

And it seems that pcap mode needs to be in autofp mode. So, the configuration posted which defaults to worker, isn't the right mode for pcap mode.

 

[juched]

I took the plunge and setup suricata on my RT-AX88U. I did it manually, not hard, Thanks @rgnldo.

Changed the setup to log only to syslog and no stats currently. When using top, I see the memory usage at 772m (WOW!). But things are running and free command shows that buffers/cache still has 250MB, so not too tight.

One thing I did notice though, if I tail -f /opt/var/log/suricata/fast.log or if I vi /opt/etc/suricata/suricata.yaml, the running service immediately shutdown with this message:

<Notice> - Signal Received.  Stopping engine.

Could this be a self protection? Anyone see this?

Nothing else edited in the YAML other than DNS_IP and adding eth0 to af file.

Changed the init.d script, and now I can tail log files and edit the YAML file without it shutting down. Basically added -D to run in daemon mode, and then sleep 1 sec for the sub-process to start. Figured I would share.

#!/bin/sh
logger -t S82suricata "Starting Suricata IDS/IPS $0"
# set environment PATH to system binaries
export PATH=/sbin:/bin:/usr/sbin:/usr/bin:$PATH
export TZ=$(cat /etc/TZ)
ENABLED=yes
PROCS=suricata
PIDFILE=/opt/var/run/suricata.pid
ARGS="-c /opt/etc/suricata/suricata.yaml --af-packet -D"
#ARGS="-c /opt/etc/suricata/suricata.yaml --pcap"
POSTCMD="sleep 1"
PREARGS=""
DESC=$PROCS
PATH=/opt/sbin:/opt/bin:/opt/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

. /opt/etc/init.d/rc.func