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

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

Thank you for the explanation, I did now that a gz.tar file is a container, simalar to zip, they are often used in Linux Systems as paket installer, i never used them, because in ubuntu you have a dpkg system and that is the only linux distri I ever used on PC. That’s why I didn’t know what exactly a tar file does. But now i am smart :grin:
Does it also create .bak files or are the original files completely gone?

The only reason for me to put a Tor Exit Relay on a blocklist would be if the node was run by a secret service or some other organization trying to expose Tor users.
But unfortunately that won’t be one of the criteria for this blocklist, more likely if someone reports a Tor Relay because he supposedly gets SPAM.
Can I remove Tor Relays from this blocklist?
Or just turn off the whole system?

No, “xyz.tar.gz” files are simple (gzip) compressed archives, very similar to the well known zip or rar archives on windows.

So may existing files completely will be overwritten during extraction, because the “-f” flag in the given command is set. This is used to “force” the extraction and overwrite the file instead of asking the user.

This is the desired behavior here, because it makes installing and testing those release builds a lot easier.

I really don’t know the criteria when an address or network get part of such a blocklist. Massive spamming could be a good reason, or perfoming network attacks through the onion network etc.

Sadly it is not possible to remove any exit nodes from those list, because for good reasons there is no complete exit nodes list available in public. Also if you edit the list manually and remove the known or blocked one, those changes will be gone after the next list update.

So the only way to avoid blocking any exit nodes would be to disable the DROP_HOSTILE feature entirely.

-Stefan

So there is no way back if something goes wrong?
How can I see which files will be overwritten, to save the files beforehand? I will test it but i would like to have the chance to go back to the stock files.

This is not quite correct every guard, middle node and exit relay are public, there are even lists in the internet that are updated several times a day. Some network admin use such lists to block the complete Tor network, which of course makes no sense, because nothing bad will ever come from a guard or middle node. My IP is also in the list, but since I am never in the net with my real IP, I have not noticed such measures.
Only the bridge nodes are not available, for a very good reason, yes.

Theoretically it would be possible to update the freely available Tor node list several times a day, compare it with the block list after each update and delete or comment out the Tor nodes if they match.
I can’t write scripts, but something like this should be easy possible. And already Tor has a free ride.
I also don’t understand why a node of the network is blocked at all? What can the network do for that it is abused by a few? And what is the point of blocking? The next time it will be any other exit node. Such measures are completely pointless and bring the Tor network more and more into disrepute. But that is only my little opinion from a guy who is a little bit cracy and who loves his privacy…