Suricata Suricata - IDS on AsusWRT Merlin

[crkpot]

Found it, missing a character. Please try again.

Success!! Small error on very last output line, but suricata is running. Thanks!

EDIT: Disreagard small error, it's on my end. All good.

##
##Suricata Log
## by @juched - Process logs into SQLite3 for stats generation - v1.0

suricata_log.sh
Logfile used is /opt/var/log/suricata/fast.log
Date used is 2020-08-16 (30 days ago is 2020-07-17)
Creating threat_log table if needed...
Deleting old threat_log records older than 30 days...
All done!
Calculating Threats data...
Outputting Threats ...
16/8/2020 -- 17:56:15 - <Info> - Running suricata under test mode
Warning: Output_interface not supplied by user.  Falling back on default_output_interface "Console"
16/8/2020 -- 17:56:15 - <Notice> - This is Suricata version 4.1.8 RELEASE
16/8/2020 -- 17:56:15 - <Info> - CPUs/cores online: 3
16/8/2020 -- 17:56:15 - <Info> - fast output device (regular) initialized: fast.log
16/8/2020 -- 17:56:15 - <Warning> - [ERRCODE: SC_WARN_NO_STATS_LOGGERS(261)] - stats are enabled but no loggers are active
16/8/2020 -- 17:56:16 - <Info> - 20 rule files processed. 3122 rules successfully loaded, 0 rules failed
16/8/2020 -- 17:56:16 - <Info> - Threshold config parsed: 0 rule(s) found
16/8/2020 -- 17:56:16 - <Info> - 3122 signatures processed. 225 are IP-only rules, 567 are inspecting packet payload, 2469 inspect application layer, 0 are decoder event only
16/8/2020 -- 17:56:19 - <Notice> - Configuration provided was successfully loaded. Exiting.
16/8/2020 -- 17:56:19 - <Info> - cleaning up signature grouping structure... complete
Starting suricata...              done.
-sh: getcwd: No such file or directory

 

[rgnldo]

Any Idea how to change MTU of br0 to 1464?

default-packet-size: 1464

 

[joe scian]

default-packet-size: 1464

Thank you rgnldo- however on an RT-AC5300 with the following configured I get
"ERRCODE: SC_ERR_INVALID_VALUE(130)] - Should have an Ethernet header" filling up the log.
Any idea why ? The error messages with regard to different MTU sizes for the two interfaces are no longer there.

# Runmode the engine should use.
runmode: workers

# If set to auto, the variable is internally switched to 'router' in IPS
# mode and 'sniffer-only' in IDS mode.
host-mode: auto
# Linux high speed capture support
af-packet:
  - interface: ppp0
    threads: 1
    defrag: no
    cluster-type: cluster_flow
    cluster-id: 99
    copy-mode: ips
    copy-iface: br0
    buffer-size: 64535
    use-mmap: yes
    tpacket-v2: yes
    tpacket-v3: no
    ring-size: 3072
   
  - interface: br0
    threads: 1
    cluster-id: 98
    defrag: no
    cluster-type: cluster_flow
    copy-mode: ips
    copy-iface: ppp0
    buffer-size: 64535
    use-mmap: yes
    tpacket-v2: yes
    tpacket-v3: no
    ring-size: 3072

17/8/2020 -- 10:55:16 - <Notice> - Stats for 'br0':  pkts: 46761, drop: 1393 (2.98%), invalid chksum: 0
17/8/2020 -- 11:03:55 - <Notice> - This is Suricata version 4.1.8 RELEASE
17/8/2020 -- 11:03:55 - <Info> - CPUs/cores online: 2
17/8/2020 -- 11:03:55 - <Info> - Found an MTU of 1464 for 'ppp0'
17/8/2020 -- 11:03:55 - <Info> - Found an MTU of 1464 for 'ppp0'
17/8/2020 -- 11:03:55 - <Info> - Found an MTU of 1464 for 'br0'
17/8/2020 -- 11:03:55 - <Info> - Found an MTU of 1464 for 'br0'
17/8/2020 -- 11:03:55 - <Info> - AF_PACKET: Setting IPS mode
17/8/2020 -- 11:03:55 - <Info> - fast output device (regular) initialized: fast.log
17/8/2020 -- 11:03:55 - <Info> - stats output device (regular) initialized: stats.log
17/8/2020 -- 11:03:55 - <Info> - Syslog output initialized
17/8/2020 -- 11:03:55 - <Info> - drop output device (regular) initialized: drop.log
17/8/2020 -- 11:03:56 - <Info> - 18 rule files processed. 3108 rules successfully loaded, 0 rules failed
17/8/2020 -- 11:03:56 - <Info> - Threshold config parsed: 0 rule(s) found
17/8/2020 -- 11:03:56 - <Info> - 3108 signatures processed. 225 are IP-only rules, 553 are inspecting packet payload, 2469 inspect application layer, 0 are decoder event only
17/8/2020 -- 11:03:59 - <Info> - AF_PACKET IPS mode activated ppp0->br0
17/8/2020 -- 11:03:59 - <Info> - Going to use 1 thread(s)
17/8/2020 -- 11:03:59 - <Info> - AF_PACKET IPS mode activated br0->ppp0
17/8/2020 -- 11:03:59 - <Info> - Going to use 1 thread(s)
17/8/2020 -- 11:03:59 - <Info> - Found an MTU of 1464 for 'br0'
17/8/2020 -- 11:03:59 - <Info> - Found an MTU of 1464 for 'ppp0'
17/8/2020 -- 11:03:59 - <Notice> - all 2 packet processing threads, 2 management threads initialized, engine started.
17/8/2020 -- 11:04:00 - <Info> - All AFP capture threads are running.
17/8/2020 -- 11:04:00 - <Warning> - [ERRCODE: SC_ERR_INVALID_VALUE(130)] - Should have an Ethernet header
17/8/2020 -- 11:04:00 - <Warning> - [ERRCODE: SC_ERR_INVALID_VALUE(130)] - Should have an Ethernet header
17/8/2020 -- 11:04:00 - <Warning> - [ERRCODE: SC_ERR_INVALID_VALUE(130)] - Should have an Ethernet header
17/8/2020 -- 11:04:00 - <Warning> - [ERRCODE: SC_ERR_INVALID_VALUE(130)] - Should have an Ethernet header
17/8/2020 -- 11:04:00 - <Warning> - [ERRCODE: SC_ERR_INVALID_VALUE(130)] - Should have an Ethernet header
17/8/2020 -- 11:04:00 - <Warning> - [ERRCODE: SC_ERR_INVALID_VALUE(130)] - Should have an Ethernet header
17/8/2020 -- 11:04:00 - <Warning> - [ERRCODE: SC_ERR_INVALID_VALUE(130)] - Should have an Ethernet header
17/8/2020 -- 11:04:00 - <Warning> - [ERRCODE: SC_ERR_INVALID_VALUE(130)] - Should have an Ethernet header
17/8/2020 -- 11:04:00 - <Warning> - [ERRCODE: SC_ERR_INVALID_VALUE(130)] - Should have an Ethernet header

 

[faux123]

Quick update. I was having all sorts of issues with my connection with the following option set:

tpacket-v2: yes

I recommend switching back to:

tpacket-v3: yes

if you encounter websites not loading correctly and such... Now it's all good again.. this 1 setting was causing me headaches for 2 days.

 

[rgnldo]

Quick update. I was having all sorts of issues with my connection with the following option set:

tpacket-v2: yes

I recommend switching back to:

tpacket-v3: yes

if you encounter websites not loading correctly and such... Now it's all good again.. this 1 setting was causing me headaches for 2 days.

I'm on github issues. We are going to problematize there.

 

[juched]

Quick update. I was having all sorts of issues with my connection with the following option set:

tpacket-v2: yes

I recommend switching back to:

tpacket-v3: yes

if you encounter websites not loading correctly and such... Now it's all good again.. this 1 setting was causing me headaches for 2 days.

Is this in IPS mode?

 

[faux123]

Is this in IPS mode?

yes, for IPS mode

 

[MoonPie2000]

Couple of observations with new install script...
> With original manger install script could run 'suricata_manager' from any directory now must be in .../addons/suricata to run manager './suricata_manager.sh'

> After running 'suricata_manager test' nothing shows up in UI addons suricata tab however it does show an entry in the fast.log

I also appreciate all the hard work that all the volunteers are providing and understand that any issue resolution is done on a 'when time allows' bases. I only list this observations as potential help.

 

[heysoundude]

Any Idea how to change MTU of br0 to 1464?

I believe it's the router GUI/WAN page

 

[Mutzli]

Today I was locked out from accessing the routers UI or SSH into it from my desktop that is connected by LAN. Turning off Suricata fixed the problem and I can get back into the router. How did I end up blocking my own desktop in Suricata? Here is my .yaml config. Anything that might look like it is miss configured?

%YAML 1.1
---

# Holds variables that would be used by the engine.
vars:

  # Holds the address group vars that would be passed in a Signature.
  address-groups:
    HOME_NET: "[192.168.0.0/16]" ## set your CID IP LAN
    EXTERNAL_NET: "any"
    DNS_SERVERS: "[192.168.1.1]"
    SMTP_SERVERS: "$HOME_NET"
    HTTP_SERVERS: "$HOME_NET"
    SQL_SERVERS: "$HOME_NET"
    TELNET_SERVERS: "$HOME_NET"
    DNP3_SERVER: "$HOME_NET"
    DNP3_CLIENT: "$HOME_NET"
    MODBUS_SERVER: "$HOME_NET"
    MODBUS_CLIENT: "$HOME_NET"
    ENIP_SERVER: "$HOME_NET"
    ENIP_CLIENT: "$HOME_NET"
    FTP_SERVERS: "$HOME_NET"
    SSH_SERVERS: "$HOME_NET"
    
 # Holds the port group vars that would be passed in a Signature.
  port-groups:
    FTP_PORTS: "21"
    HTTP_PORTS: "80"
    ORACLE_PORTS: "1521"
    SSH_PORTS: "22"
    SHELLCODE_PORTS: "!80"
    DNP3_PORTS: "20000"
    FILE_DATA_PORTS: "$HTTP_PORTS,110,143"   
 
# Runmode the engine should use.
runmode: workers

# If set to auto, the variable is internally switched to 'router' in IPS
# mode and 'sniffer-only' in IDS mode.
host-mode: auto

# Linux high speed capture support
af-packet:
## set your wan interface
  - interface: eth0
    copy-mode: ips
    copy-iface: br0
    buffer-size: 3072
    cluster-id: 99
    cluster-type: cluster_flow
    use-mmap: yes
    tpacket-v3: yes
    ring-size: 3072
  - interface: br0
    copy-mode: ips
    copy-iface: eth0
    buffer-size: 3072
    cluster-id: 98
    cluster-type: cluster_flow
    use-mmap: yes
    tpacket-v3: yes
    ring-size: 3072

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

legacy:
  uricontent: enabled

max-pending-packets: 1024

When I turn on Suricata it takes about 5-10min and I'm locked out again.

 

[ugandy]

Today I was locked out from accessing the routers UI or SSH into it from my desktop that is connected by LAN. Turning off Suricata fixed the problem and I can get back into the router. How did I end up blocking my own desktop in Suricata? Here is my .yaml config. Anything that might look like it is miss configured?

%YAML 1.1
---

# Holds variables that would be used by the engine.
vars:

  # Holds the address group vars that would be passed in a Signature.
  address-groups:
    HOME_NET: "[192.168.0.0/16]" ## set your CID IP LAN
    EXTERNAL_NET: "any"
    DNS_SERVERS: "[192.168.1.1]"
    SMTP_SERVERS: "$HOME_NET"
    HTTP_SERVERS: "$HOME_NET"
    SQL_SERVERS: "$HOME_NET"
    TELNET_SERVERS: "$HOME_NET"
    DNP3_SERVER: "$HOME_NET"
    DNP3_CLIENT: "$HOME_NET"
    MODBUS_SERVER: "$HOME_NET"
    MODBUS_CLIENT: "$HOME_NET"
    ENIP_SERVER: "$HOME_NET"
    ENIP_CLIENT: "$HOME_NET"
    FTP_SERVERS: "$HOME_NET"
    SSH_SERVERS: "$HOME_NET"
  
# Holds the port group vars that would be passed in a Signature.
  port-groups:
    FTP_PORTS: "21"
    HTTP_PORTS: "80"
    ORACLE_PORTS: "1521"
    SSH_PORTS: "22"
    SHELLCODE_PORTS: "!80"
    DNP3_PORTS: "20000"
    FILE_DATA_PORTS: "$HTTP_PORTS,110,143" 

# Runmode the engine should use.
runmode: workers

# If set to auto, the variable is internally switched to 'router' in IPS
# mode and 'sniffer-only' in IDS mode.
host-mode: auto

# Linux high speed capture support
af-packet:
## set your wan interface
  - interface: eth0
    copy-mode: ips
    copy-iface: br0
    buffer-size: 3072
    cluster-id: 99
    cluster-type: cluster_flow
    use-mmap: yes
    tpacket-v3: yes
    ring-size: 3072
  - interface: br0
    copy-mode: ips
    copy-iface: eth0
    buffer-size: 3072
    cluster-id: 98
    cluster-type: cluster_flow
    use-mmap: yes
    tpacket-v3: yes
    ring-size: 3072

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

legacy:
  uricontent: enabled

max-pending-packets: 1024

When I turn on Suricata it takes about 5-10min and I'm locked out again.

if suricata blocked you, you should see it on fast.log, which would tell you why

 

[juched]

if suricata blocked you, you should see it on fast.log, which would tell you why

Good point, what does that log show?

If you are blocked, then it seems IPS mode works to drop packets

 

[Mutzli]

if suricata blocked you, you should see it on fast.log, which would tell you why

The last log entry shows "pontentially bad traffic". But doesn't tell me anything else:

08/17/2020-11:25:02.474038  [**] [1:2027758:3] ET DNS Query for .cc TLD [**] [Classification: Potentially Bad Traffic] [Priority: 2] {UDP} 192.168.1.153:51796 -> 192.168.1.1:53

192.168.1.153 is my desktop. I'm not familiar with the priority codes. Does 2 mean it's blocking that request? Most log entries are Priority 1.

 

[ugandy]

The last log entry doesn't shows "pontentially bad traffic". But doesn't tell me anything else:

08/17/2020-11:25:02.474038  [**] [1:2027758:3] ET DNS Query for .cc TLD [**] [Classification: Potentially Bad Traffic] [Priority: 2] {UDP} 192.168.1.153:51796 -> 192.168.1.1:53

192.168.1.153 is my desktop. I'm not familiar with the priority codes. Does 2 mean it's blocking that request? Most are Priority 1.

that;s your desktop querying the router DNS server, i think. it's not a ssh/http connection. not sure why marked as bad traffic anyway. maybe you have too many draconian rules enabled? no other entries for 192.168.1.153? did you just upgrade to 384.19? some people have reported same problem and mentioned that waiting 30 minutes after the upgrade solved the problem (i did factory reset so no problems). hey, if you can't ssh/http to the router, how did you get the fast.log?

 

[Mutzli]

that;s your desktop querying the router DNS. it's not a ssh/http connection. not sure why marked as bad traffic anyway. maybe you have too many draconian rules enabled? no other entries for 192.168.1.153? did you just upgrade to 384.19? some people have reported same problem and mentioned that waiting 30 mina after the upgrade solved the problem. hey, if you can't sshhttp to the router, how did you get the fast.log?

I can log into the ssh from by mobile phone app JuiceSSH and turn off suricata. After it's turned off, I can get back into the router from my desktop.
I update the router on Friday and it worked since. Earlier today I tried to open a SSH session and was denied. Here are the only two log lines mentioning my IP address:

08/17/2020-11:25:02.474038 [**] [1:2027758:3] ET DNS Query for .cc TLD [**] [Classification: Potentially Bad Traffic] [Priority: 2] {UDP} 192.168.1.153:51796 -> 192.168.1.1:53
08/17/2020-11:25:02.474103 [**] [1:2027758:3] ET DNS Query for .cc TLD [**] [Classification: Potentially Bad Traffic] [Priority: 2] {UDP} 192.168.1.153:54799 -> 192.168.1.1:53

 

[Mutzli]

What I don't understand is why would Suricata lock access to my SSH port and web UI port? everything else is still working like accessing the server and browsing the internet from this desktop.

btw. the rules I use are the ones defined here: https://rules.emergingthreats.net/open/suricata-4.0/emerging.rules.tar.gz no other rules loaded.

 

[XIII]

Since we can't have IPS unless we run a fork of Merlin's firmware: would it make sense to manually ban IP's from the Suricata logging in Skynet? (or even better: have a script that does this?)

 

[faux123]

What I don't understand is why would Suricata lock access to my SSH port and web UI port? everything else is still working like accessing the server and browsing the internet from this desktop.

btw. the rules I use are the ones defined here: https://rules.emergingthreats.net/open/suricata-4.0/emerging.rules.tar.gz no other rules loaded.

under rules, I recommend you comment out the rules for DNS (I know I know this is less protection but at this moment, we are all investigating in getting Suricata adapted for small router use). I have mine commented out to reduce issues with DNS as well.

 

[XIII]

On the subject of DNS: what value(s) should be use for "DNS_SERVERS"?

Only your local (router) IP address? Or a list that also includes the IP addresses of the external DNS servers you use? (like those of NextDNS)

 

[Mutzli]

under rules, I recommend you comment out the rules for DNS (I know I know this is less protection but at this moment, we are all investigating in getting Suricata adapted for small router use). I have mine commented out to reduce issues with DNS as well.

I'll try this:

rule-files:
   - botcc.rules
   - botcc.portgrouped.rules
   - compromised.rules
   - drop.rules
   - dshield.rules
   - emerging-malware.rules
   - emerging-mobile_malware.rules
   - emerging-worm.rules
   - emerging-dos.rules
   # - emerging-dns.rules
   - ciarmy.rules
   - emerging-misc.rules
   - emerging-scan.rules
   - emerging-icmp_info.rules
   - emerging-icmp.rules
   - emerging-user_agents.rules
   - emerging-policy.rules
   - emerging-attack_response.rules
   - emerging-ftp.rules
   - emerging-games.rules

Earlier I also entered a country block for .cc into Skynet to see if that log message calling bad traffic on the .cc DNS request could be the problem. It seemed to work for the interim. I'll reverse that change to track it now with the dns.rules disabled.