IPS alerts - where are the alerts logged?

Security Intrusion Prevention
1

Good morning Sirs,

today night there was a Snort-Rules Update on the iPFire. My son played on Steam yesterday, and today Steam stopped working online, so I assumed the problem regarded to the Snort rules updated at night. Reupdating manually via fcron script resulted in a functioning Steam Gaming Environment again.

So I assumed something like a false positive alert and tried to find that in the logs, but I wasn’t very successful with that. If you’d do me a favour: could you please tell where those alerts are usually logged; even if they’re false positive, there must be some entries anywhere?

Thank you!

2

Hi,
you should be able to see it via web UI under ‘Logs --> IPS Logs’ or via console/SSH under /var/log/suricata .
As an information for you, IPFire do not use Snort anymore but Suricata --> https://blog.ipfire.org/post/introducing-ipfire-s-new-intrusion-prevention-system .

Best,

Erik

1 Like
3

Good morning Erich,

thank you for your answers. Indeed, I’ve found them logs, but there are no alerts logged currently.

Regarding your statement upon Snort - I’ve booked a subscription for the snort rules updates which work together with the Suricata IPS. So, using this unique Oinkcode lets my iPFire receive the commercial rule updates.

I presume it might have been a “false positive” in my activated exploit-kit.rules set, 'cause deactivating the os-windows.rules at first set did not lead to the acclaimed solution here.

1. Talos VRT-ruleset with subscription (RED)
2. Suricata ruleset auto update Sunday night
3. Steam client on my son's workstation stopped working (couldn't login)
4. Not any alert thrown in IPS logs
5. Deactivate os-windows.rules
6. Steam not working, either. No alerts, either.
7. Manual Suricata ruleset update
8. Steam working again on my son's workstation

I just wonder what this was, really. It might be there has had been another coincidence and it perhaps regarded to Steam but not to iPFire, but after re-downloading the ruleset Steam worked again quite immediately.

I know these rulesets havve nothing to do with iPFire, but I’d definitly wonder why there seems to be no logging when Suricata seems block a client.

Gott zum Gruße!

4

Hi Martin,
are you sure that Suricata dropped the connection ?
Regarding the logging/functionality, it might be an idea to enable some scanning rules and check it out with an nmap scan ? To start first by checking the functionality of Suricata in general…

Best,

Erik

5

Good afternoon Erik,

not sure, clearly. I 'll be giving response soon. Thank you!

6

Erik - I am curious. Can you add more details of how this is done? I never knew this could be tested with anything but trial (try) & error.

7

Good morning, gentlemen!

I’ve now tested the Suricata rules with the following settings:

[x] Intrusion detection activated [x] Check only

Talos-VRT-Ruleset with subscription

Ruleset (2020-07-27 12:24:42)

ping 192.168.xx.x
Datum: 07/29 12:24:42 Name: PROTOCOL-ICMP PING
Priorität: 3 Typ: Misc activity
IP-Info: 192.168.xx.xxx:8 -> 192.168.xx.x:0
Referenzen: nichts gefunden SID: 384

So, from my opinion, that works! At Zeus, I don’t understand why these rules are sometimes kickin’ some Windows apps from our family’s workstations and no logs do appear?

8

Hello again!

Did a check on my sons workstation with c’t desinfec’t 2020 after havin’ had some nice nudges from my eldest one; nothing found neither, though there was a backuped file on his external HDD with some false positives shown on Virustotal, anyway, the general “odeur” of that machine seems to be quite okay so far.

In general, I think it’s the rules which stink sometimes and disrupt continuity of operations. I’ll be putting a free eye on that, or maybe two, or so. However, not any logs aren’t good anyway.

I’d just like to transmit that to you in a decent manner.

Sincerely!

9

Hi all,

Hi Jon,
a possible example can be:

  • Emergingthreats.net Community Rules
  • Enabled emerging-scan.rules by clicking in you can see also the nmap commands.
  • Fast and simple test with Nmap
nmap -T4 -v -A {green0 or red0 IP}

Results here in a

07/30/2020-11:58:59.587968  [Drop] [**] [1:2010937:3] ET SCAN Suspicious inbound to mySQL port 3306 [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 192.168.200.33:60129 -> 192.168.222.2:3306
07/30/2020-11:58:59.690313  [Drop] [**] [1:2010937:3] ET SCAN Suspicious inbound to mySQL port 3306 [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 192.168.200.33:60130 -> 192.168.222.2:3306

Hi Martin,
possibly the Snort rules does some problems with the Suricata logging ? But this also only a look into the “Glasskugel”.

Best,

Erik

1 Like
10

Good morning. An update, FYI.

I discovered today that my Synology DSM has suddenly thrown out an error regarding crontab entries which should not have existed. I checked it and found out that crontab was okay, but NTP hasn’t had synced with the iPFire configured since, well, 27.07.2020.

That’s the day when I started this thread. So, maybe the problem regarded to the NTP service of the iPFire?

I found out that some services hadn’t been active at all (e.g. Update Accelerator), though checked to be enabled, when re-installing iPFire as per 20.07.2020 and reloading the configuration by using a backup.

Usually I do re-clicks, saves and restarts to get it all up and running.

11

Hi,
Currently all rules in that file are disabled (all lines starts with #)
Is there a way to keep them active “forever”? I removed the hash, but at next download the new file arrived with all rules disabled (again).
Actually I am not sure if file was downloaded like that or one of the oinkmaster functions disables those…
Thanks!