Suricata Suricata - IDS on AsusWRT Merlin

[rgnldo]

playing nicely together?

Yes. I use the PF firewall, but without blocking IP's. I use only Suricata. Impressive what the SCAN and Policy rules do with my macOS applications. My SSH client is considered to be SSH scan and brute force. Do not open. I have to use the native macOS terminal. Suricata is a fortress.

 

[Smokey613]

I use my iPad to ssh into my routers and so far it plays nice with suricata.

 

[Torson]

@rgnldo - wouldn't that suricata.yaml update mix better with the v 5.0 classification-config and the emerging rules tar? They are somewhat different form v 4.0 - mostly the classification-config using the new classifications in v 5.0.

 

[Smokey613]

Sorry. Fixed.

duplicade

- emerging-scan.rules

Yes, that corrected the issue. Thanks!

 

[XIII]

I still don't understand what I should see on the test site.

The line that @rgnldo posted, or nothing at all?

 

[Torson]

I still don't understand what I should see on the test site.

The line that @rgnldo posted, or nothing at all?

Here is an excerpt from the alerting write-up regarding the IDS functionality mentioned above:
"To test the IDS functionality of Suricata it’s best to test with a signature. The signature with ID 2100498 from the ET Open ruleset is written specific for such test cases.

2100498:

alert ip any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; classtype:bad-unknown; sid:2100498; rev:7; metadata:created_at 2010_09_23, updated_at 2010_09_23

The syntax and logic behind those signatures is covered in other chapters. This will alert on any IP traffic that has the content within its payload. This rule can be triggered quite easy. Before we trigger it, we will tail on the fast.log so we see the result.

Ruletrigger:

sudo tail -f /var/log/suricata/fast.log
curl http://testmyids.com/

The following output should now be seen in the log:

[1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 217.160.0.187:80 -> 10.0.0.23:41618

This should include the timestamp and the IP of your system." - quote from suricata v5.0 Quickstart guide @ https://suricata.readthedocs.io/en/suricata-5.0.3/quickstart.html.
Note that the Entware package is still v.4.

 

[rgnldo]

Here is an excerpt from the alerting write-up regarding the IDS functionality mentioned above:

Very good. I don't have time to organize texts like that. appreciate

 

[XIII]

Updated again. No more duplicates and "GPL ATTACK RESPONSE" is logged.

Nice, this is actually the test I suggested long time ago (post #47), but did not work on my setup. It does now!

 

[rgnldo]

@rgnldo - wouldn't that suricata.yaml update mix better with the v 5.0 classification-config and the emerging rules tar? They are somewhat different form v 4.0 - mostly the classification-config using the new classifications in v 5.0.

Yes, different in desities. I use the Talos VRT rules.

Talos - Author of the Official Snort Rule Sets

Update your systems with the latest Snort 3 release to manage network intrusion detections and preventions.

www.snort.org

The attack_response rules resolves for the test.

 

[rgnldo]

Nice, this is actually the test I suggested long time ago

Sorry. Suricata has little documentation for testing. I had to seek knowledge.

 

[JJohnson1988]

My log is now being spammed by my Amazon Fire Stick, full of entries like this:

Jul 24 18:05:14 AC86U suricata[13472]: [1:2100366:8] GPL ICMP_INFO PING *NIX [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.50.49:8 -> 192.168.50.1:0
Jul 24 18:05:14 AC86U suricata[13472]: [1:2100368:7] GPL ICMP_INFO PING BSDtype [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.50.49:8 -> 192.168.50.1:0

I'm sure I could just remove the ICMP_Info ruleset altogether, but is there a better way to solve this? I'll have a look through the device's settings again, but I doubt it will help.

 

[rgnldo]

My log is now being spammed by my Amazon Fire Stick, full of entries like this:

Jul 24 18:05:14 AC86U suricata[13472]: [1:2100366:8] GPL ICMP_INFO PING *NIX [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.50.49:8 -> 192.168.50.1:0
Jul 24 18:05:14 AC86U suricata[13472]: [1:2100368:7] GPL ICMP_INFO PING BSDtype [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.50.49:8 -> 192.168.50.1:0

I'm sure I could just remove the ICMP_Info ruleset altogether, but is there a better way to solve this? I'll have a look through the device's settings again, but I doubt it will help.

Is the device working? If so, it is just alerts. Adding allowed IP is for non-functioning situations.

 

[JJohnson1988]

Is the device working? If so, it is just alerts. Adding allowed IP is for non-functioning situations.

As far as I know the device is still working properly, it's just a matter of log spam. I'm currently using scribe so I'll likely just figure out how to filter it out. Going to double check the device later to verify functionality.

 

[Smokey613]

I have a Govee temp/hygrometer unit that spams the fast.log but it still works so I just ignore the spam. It would be great if someone could add support for unbound, cake and suricata in scribe. In the meantime, I do not let suricata log to the syslog for alert reporting.

 

[mike37]

My log is now being spammed by my Amazon Fire Stick, full of entries like this:

Jul 24 18:05:14 AC86U suricata[13472]: [1:2100366:8] GPL ICMP_INFO PING *NIX [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.50.49:8 -> 192.168.50.1:0
Jul 24 18:05:14 AC86U suricata[13472]: [1:2100368:7] GPL ICMP_INFO PING BSDtype [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.50.49:8 -> 192.168.50.1:0

I'm sure I could just remove the ICMP_Info ruleset altogether, but is there a better way to solve this? I'll have a look through the device's settings again, but I doubt it will help.

One approach is to EXPECT these and other "info" rules to pop up - a necessary function of teaching suricata about your setup - and keep them but to edit it/them to allow the ICMP from known devices. That way you won't get the "alerts" from a known, trusted device but will get an alert if something changes - e.g. the device is hacked, or a new device appears.

You could then move that rule to a new file of customized rules that will need to be carried forward when rules are broadly updated - "evolving" the rules to your particular setup.

(FWIW, when I get a chance to play again I need to add an IOT device to a guest network and create rules restricting it to specific wan and lan addresses using specific protocols, and with a warning and "drop" disposition if it strays (suggesting it was hacked).)

 

[mike37]

I have a Govee temp/hygrometer unit that spams the fast.log but it still works so I just ignore the spam. It would be great if someone could add support for unbound, cake and suricata in scribe. In the meantime, I do not let suricata log to the syslog for alert reporting.

Perhaps edit the rules so that suricata allows "good" communications. ISTM never ignore alert logging - especially if you're going to move to dropping malicious communications.

 

[Torson]

My log is now being spammed by my Amazon Fire Stick, full of entries like this:

Jul 24 18:05:14 AC86U suricata[13472]: [1:2100366:8] GPL ICMP_INFO PING *NIX [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.50.49:8 -> 192.168.50.1:0
Jul 24 18:05:14 AC86U suricata[13472]: [1:2100368:7] GPL ICMP_INFO PING BSDtype [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.50.49:8 -> 192.168.50.1:0

I'm sure I could just remove the ICMP_Info ruleset altogether, but is there a better way to solve this? I'll have a look through the device's settings again, but I doubt it will help.

You can suppress them (and any similar known noisy alerts) in /opt/etc/suricata/threshold.config by adding commands like (in your case):

suppress gen_id 1, sig_id 2100366
suppress gen_id 1, sig_id 2100368

You may need to stop and start suricata for those to take effect. To check that the threshold configuration is correctly parsed run

suricata -T

 

[Smokey613]

Perhaps edit the rules so that suricata allows "good" communications. ISTM never ignore alert logging - especially if you're going to move to dropping malicious communications.

That brings up a good point. The dropping malicious communications part. Does suricata in it’s default asus configuration, do any dropping or does it simply alert?

 

[Smokey613]

You can suppress them (and any similar known noisy alerts) in /opt/etc/suricata/threshold.config by adding commands like (in your case):

suppress gen_id 1, sig_id 2100366
suppress gen_id 1, sig_id 2100368

You may need to stop and start suricata for those to take effect. To check that the threshold configuration is correctly parsed run

suricata -T

Thanks! That corrected my “spam” issues with my Govee unit. I re-enabled logging to the syslog.

 

[mike37]

You can suppress them (and any similar known noisy alerts) in /opt/etc/suricata/threshold.config by adding commands like (in your case):

suppress gen_id 1, sig_id 2100366
suppress gen_id 1, sig_id 2100368

You may need to stop and start suricata for those to take effect. To check that the threshold configuration is correctly parsed run

suricata -T

Yes!

IIUC one could create suppress actions for noisy rules when they connect with appropriate addresses - and which would not be suppressed if some other contact occurs. A custom file of ongoing suppressions would be easier to maintain than moving modified rules about.