Tor and IPS conflict --SURICATA Rulset where does it come from?

Hi again,
I know I can be a pain in the ass, but I’m starting to get all the bugs fixed that have crept in lately.
So please be patient with me soon everything runs and you have again your peace from me :smiley:

As I’ve noted here before, my Tor Relay suddenly had problems with the IPS and a deactivation of a certain ruleset initially helped, but a short time later the relay was frozen again, because all traffic is blocked at some point.
Meanwhile I am of the opinion that a ruleset is responsible for it, which I have not selected at all and namely that of SURICATA itself, but for this I find no rules where I can deactivate rule. Where does this ruleset come from, can I deactivate it manually so that only the rules that can be easily edited are used? Why are these rules not displayed? Or what is SURICATA that shows up in the IPS log and disconnects on port 9001? Can someone please enlighten me, I for one understood that if ET shows up in the log it can be found in the Emergingthreats.net ruleset and so on.

Thanks a lot in advance

Perhaps this will shed some light on the subject.

This seems to be a similar phenomenon as with me, rules that appear, although they are not in the ruleset. This came with the last update, was also in the change log what was changed in IPS system.
Only with me these are not only unwanted log entries, with me since the update also the Tor relay is disturbed.
I am currently testing which provider of the ruleset is responsible for this.

The rule set is the built in Suricata rule set. You can actually turn off all rule sets for for IPS, and yes it will complain about no rule sets being selected; however it will still log events based upon the built in rule set.

I am still unclear as to whether the priority 3 rule sets are just logged or are blocked. The Suricata documentation just says the priority dictates the order in which rules are processed.

I have other issues with the built in rule sets that I am attempting to figure out so I can report them in a coherent manner.

PZ

I can definitely say that priority 3 means a block because

Date: 07/13 19:17:40 Name: ET INFO Observed Discord Domain (discordapp .com in TLS SNI)
Priority: 3 Type: Misc activity
IP info: 192.168.1.48:38322 → 162.159.130.233:443
References: nothing found SID: 2035464

and the other 3 ET INFO Discord rules prevented my access to Discord, after I disabled the rules it worked. Something has definitely changed, I never had such problems with the IPS system before, also I didn’t have 70K messages a day in the IPS log. But my Tor relay is running better then before, thats a nice news :smiley:

Hi,

@stevee, may I ask you, being the IPS guru around here, to take over this thread? :slight_smile:

Thanks, and best regards,
Peter Müller

Too bad, would have been too easy.
The standard rules that flood the protocol with priority 3 are definitely not blocked in my case.

image

I am still not convinced. Looking at the IPS log, most of the entries appear to be some sort of issue with potential packet loss. That is
image
image
So if your internet connection is not the best, this could cause many of logging events which would be blocked, but eventually synchronize and pass through. Which would only slow down your effective internet speed. I have other issues, with IPS running on the green, I can no longer log into one of my banks. Turn if off and all is aok. Problem is it is not logged in the IPS WUI page, so will be researching it over the next few days.

PZ

Peter,

By the way, I would point out that both this thread and Disable default suricata rules? - #23 by hvacguy are likely related, so perhaps merge or something else that is above my level of no how.
PZ

I cannot even say that all priority 3 messages are blocking, but this 4 rules from the Emergingthreats ruleset had me prevented to access my Discord.100%

Where is this file to comment out this standard ruleset from Suricata?

Yeah, I have also a very strange behavior on green, but i didn’t check if it is related to IPS, i can reach all my devices in the network trough VPN except one, my cam, if I am connected with WIFI it works. I changed also my smartphone last days so it can be another issue, but before it works with my old device trough VPN.

File suricata-used-rulesfiles.yaml in /var/ipfire/suricata/

However, the file is regenerated when new rules are added or changed. So you have to do it after every change.

Good evening,

the “default” suricata rules are only alert rules, so they do not inherit (block or drop) any traffic.

They are used to generate log events in case suricata detects something generic (for example wrong packet checksums, etc) while decoding the network packets.

After they have passed suricata those packets almost will be dropped by the firewall engine, the network stack or finally the desired application because they are invalid.

So in case you got a plenty of such entries in your IPS log file, you should check your network setup, cables, ISP settings etc.

Best regards,

-Stefan

4 Likes

Thank you Stefan. That was most helpful.

Have a nice weekend.

PZ

Hi,
i get a lot of this entrys -->>

Blockquote
||Datum:|07/16 18:02:00|Name:|SURICATA TLS invalid handshake message|
| — | — | — | — | — |
| — | — | — | — |
|Priorität:|3|Typ:|Generic Protocol Command Decode|
|IP-Info:|135.181.110.168:58120 → XX.XX.XX.Xx:9001|
|Referenzen:|nichts gefunden|SID:|2230003||
||Datum:|07/16 18:02:00|Name:|SURICATA TLS invalid record/traffic|
| — | — | — | — |
|Priorität:|3|Typ:|Generic Protocol Command Decode|
|IP-Info:|XX.XX.XX.Xx:9001 → 135.181.110.168:58120|
|Referenzen:|nichts gefunden|SID:|2230010||
|Datum:|07/16 17:11:33|Name:|SURICATA TLS invalid record/traffic|
| — | — | — | — |
|Priorität:|3|Typ:|Generic Protocol Command Decode|
|IP-Info:|XX.XX.XX.Xx:9001 → 3.134.236.233:37102|
|Referenzen:|nichts gefunden|SID:|2230010|

whats does that men? The entrys are Tor Relay related.

I also noticed that with the new Spamhouse location blocklist some Tor nodes are blocked. Also very unpleasant.

Edit:

Just by the way, my problem with the VPN and the webcam has disappeared into thin air without my intervention. Apparently a good workround for ipfire errors is just wait a few days, then it suddenly works again. :smiley:

In a private home network that might be true. In a more complex client-server company network the rules log massive amounts of entries that are correct connections.

I setup a test tor node (relay only) and will have a look if I’m able to reproduce those suricata messages.

Currently when looking into the IPS logs, I got the following new entries:

Datum: 07/17 16:49:20 Name: SURICATA HTTP gzip decompression failed
Priorität: 3 Typ: Generic Protocol Command Decode
IP-Info: 193.23.244.244:80 → 94.16.xxx.xxx:42608
Referenzen: nichts gefunden SID: 2221001
Datum: 07/17 16:49:13 Name: SURICATA HTTP gzip decompression failed
Priorität: 3 Typ: Generic Protocol Command Decode
IP-Info: 193.23.244.244:80 → 94.16.xxx.xxx:56084
Referenzen: nichts gefunden SID: 2221001
Datum: 07/17 16:48:41 Name: SURICATA HTTP gzip decompression failed
Priorität: 3 Typ: Generic Protocol Command Decode
IP-Info: 128.31.0.34:9131 → 94.16.xxx.xxx:43524
Referenzen: nichts gefunden SID: 2221001
Datum: 07/17 16:48:40 Name: SURICATA HTTP gzip decompression failed
Priorität: 3 Typ: Generic Protocol Command Decode
IP-Info: 128.31.0.34:9131 → 94.16.xxx.xxx:43430
Referenzen: nichts gefunden SID: 2221001

Best regards,

-Stefan

1 Like

Short update, after running Tor and the IDS together for some time, I exactly get the same TLS related messages in my log file.

Currently I’m working on something rule-based to avoid those alerts - I’ll report after I have some more details.

-Stefan

4 Likes

As promised I want to share the effort with you.

I developed a mechanism which loads additional service related rules to silence some IDS alerts and prevents the flooding of the log file.

As usual for development processes, I posted all details to our development mailing list, which can be found here:

https://lists.ipfire.org/pipermail/development/2022-July/013936.html

In case you join testing do not post your feedback here, please do this on the mailing list.

-Stefan

4 Likes

First of all, thank you for addressing the issue and promptly conjuring up a result.
Does it matter where I unpack the tar file on the ipfire? Or in which directory does it belong? Sorry for this noob question, but I just do not know and it is not in the README file.

Other question: (or should I create a new thread for this?)
Does this also have something to do with the Drop_Hostile entries in the firewall log, because there are also 22K entries which come to 30% from the own IP on port 9001. Or are these really dangerous exit nodes with which there is constantly communicated?

No problem, it is part of the “tar instruction” in the README file and a bit hard to read/understand if somebody is not familiar with the tar command.

As described there simply put the tarball on your IPFire system and execute the following command in the folder the tarball has been stored.

tar -xvf ids-services-001.tar.gz -C /

This will extract the containing files and extract them directly into “/” the system’s root, replacing any existing files. In general this is nothing you should do on any of your systems, because it would be very easy to deploy any kind of malware with this method. In the current case you have to trust me that it would not harm your system…

No the DROP_HOSTILE is a blocklist, which contains a lot of “evil” hosts and/or networks. In most cases there are good reasons why they are part of such blocklists.

-Stefan

1 Like