My never ending story of Tor and suricata

Security Intrusion Prevention
1

Hi,

In the past, I’ve gotten some help with flooding my log with level 3 alerts from Suricata Standard Rules, as in this thread. Many thanks to @stevee for his good work…
But this change didn’t last long and my IPS log was flooded with false positive alerts again, I think. Up to 9K per day, more than my daily firewall hits. Completely insane. So I thought I’d take a look, sit down and read the Suricata docs.

At the beginning I tried to add more exceptions as @steeve had already done, but since each time a different rule appeared in place of the eleminated rule, I thought to myself, the Tor relay network traffic probably looks strange/suspicious in every way for an IDS system, because such programs are written by “stupid” binary developers (very exaggeratedly formulated, but just fits into the current situation) and there is no “maybe” but only a “guilty” or “innocent”.

I can already see them all setting fire to my house because of these words :smiley: so please forgive me, no developer is stupid here.

This applies at least to a first sorting out, where a distinction is made between 4 levels of threats based on various parameters and also scanning procedures with the help of other rules and the iptables. Of which level 3 and 4 are only warnings and 1 and 2 lead to the drop or rejection of the packet.
All messages were level 3 no matter how often an IP appeared but it was very often.
But I can’t find a way even with

pass ip $HOME_NET [$TOR_RELAY_PORT] <> any any (msg: “pass all traffic from/to TOR_RELAY”;flowbits:noalert; sid:1;)

the logging of packets does not stop.
Even whitelisting in the group filter does not improve the situation.
And deactivating every single rule doesn’t help either.
I suspect that the data stream of the Tor network will constantly be intercepted by the IDS with other rules, so that in the end deactivation would be the result.

Is there no way to exclude this particular data stream and how can I configure this with Suricata?

2

Who deleted my file? Where can I get a new one?

~]# /etc/init.d/suricata reload
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec … or kill -l [sigspec]
~]# /etc/init.d/suricata start
Starting Intrusion Detection System… [ FAIL ]
chmod: cannot access ‘/var/run/suricata.pid’: No such file or directory
~]#

3

Apparently my changes to the /etc/suricata/suricata.yaml file stopped the process from starting, but I have now found another way to get rid of the default level 3 log entries.
in /etc/suricata/suricata.yaml we found this section

Ruleset specific options.

default-rule-path: /var/lib/suricata
rule-files:
# Include enabled ruleset files from external file.
include: /var/ipfire/suricata/suricata-used-rulesfiles.yaml

This file which is referred to here is generated automatically and the changes will be overwritten after each update, well I thought to myself, then I will copy this file and rename it to

/var/ipfire/suricata/suricata-used-rulesfileswodefault.yaml

and put this path in /etc/suricata/suricata.yaml

I can change this new file without having to overwrite it, I hope. So far it seems to work.

4

Hello Mum Pitz,

Thanks for the reminder, a lot of time has passed and this feature totally slipped out of my mind.

I’ve updated the testing tarball (003) to work again with newer core updates.

It can be grabbed at the usual place and also the install instructions have not changed.

Please phone back if everything works again or there are still some issues.
Hopefully this time we can go straight forward and get this feature merged into main.

Thanks in advance,

-Stefan

5

Hi @stevee,
thx for your update but this did not change anything in my situation, I also found no changes in the file /etc/suricata/suricata.yaml.
You did changes in /var/ipfire/ids-functions.pl, but here I have no change to read out was the difference are and “tor” or “relay” were not found in this file.

my fast.log is full of

SURICATA STREAM 3way handshake excessive different SYNs Priority: 3 Type: Generic Protocol Command Decode
IP info: XX.XX.XX.XX:45674 → 92.117.23.204:9001

Edit: The Problem of the stream rules is, that the port is often not the “standard” port 9001, it can be all from 80,433,9000-10000,45999-60000 straight all ports, but when I check the IPs they are always tor relays…
so I disabled the stream rules again as mentioned above.

And now it seems to change in different rule sets and quite clearer as before

SURICATA Applayer Mismatch protocol both directions Priority: 3 Type: Generic Protocol Command Decode IP info: XX.XX.XX.XX:9001 ->185.244.145.170:34360

SURICATA Applayer Wrong direction first Data Priority: 3 Type: Generic Protocol Command Decode IP info: XX.XX.XX.XX:9001 → 185.244.145.170:50368

both above Applayer rules every time from my tor_relay_port 9001.

SURICATA Applayer Detect protocol only one direction Priority: 3 IP info: 192.168.1.1:9060 → 192.168.1.13:63641
my green network tor proxy also tor_relay_port

SURICATA HTTP gzip decompression failed Priority: 3 Type: Generic Protocol Command Decode IP info: 128.31.0.39:9231 → XX.XX.XX.XX:38828

Also tor related but don’t know how to separate

And the first matches from non tor relay servers, this I call a success :smiley:

SURICATA TCPv4 invalid checksum Priority: 3 Type: Generic Protocol Command Decode IP info: 139.203.190.84:18117 → XX.XX.XX.XX80

So I added again my rule from my first post here in the /usr/share/suricata/rules/ipfire-tor.rules

pass ip $HOME_NET [$TOR_RELAY_PORT] <> any any (msg: “pass all traffic from/to TOR_RELAY”;flowbits:noalert; sid:1;)

This should eliminate the Applayer Rules and now let’s see what happens.

6

Hello Mum Pitz,

as you mentioned the main changes are in the ids-functions and ids cgi file.

I’ve extracted the tarball on a fresh system and pressed save in the tor.cgi and ids.cgi. The file “/var/ipfire/suricata/suricata-service-ports.yaml” has been created with the configured tor releay, sock and dirport details.

This file also should be included by the main suricata configuration file (“/etc/suricata/suricata.yaml”.

In case the “/usr/share/suricata/rules/ipfire-tor.rules” file is present it should be loaded by suricata and reduce the noise in the alert file.

I had a look on the stream rules in that file and found a pass definition for your loudest alert. (git.ipfire.org Git - people/stevee/ipfire-2.x.git/blob - config/tor/ipfire-tor.rules)

I only can beg you to check again, if everything is updated and loaded correctly.

Thanks in advance,

-Stefan

7

Hi,

Yes, I fully agree, but the /usr/share/suricata/rules/ipfire-tor.rules
where does it come from? In the tar ball there is a list of 5 rules and the second linked one already has 9 rules, this has not been adjusted automatically.

I added to the 9 lines one more

pass tcp $HOME_NET any → $EXTERNAL_NET $TOR_RELAY_PORT (msg:“LOCAL NO alerts for 3way handshake excessive different SYNs”; flowbits:noalert; stream-event:3whs_syn_flood; classtype:protocol-command-decode; sid:1200009; rev:1;)

So I get rid of a part of this alarms.

However, the ports were already correctly listed in the file and everything was correctly entered in /etc/suricata/suricata.yaml above.

Despite all of this, the STREAM rules continue to issue permanent alarms, always the same:

SURICATA STREAM 3way handshake excessive different SYNs

Something like

$HOME_NET $any → $TOR_NODE $ANY

would certainly help, but you would have to install a complete TOR_NODE list, update it at regular intervals and then insert it under /var/ipfire/suricata/suricatatornet.yaml, for example, then create the variable TOR_NODE plus new adress-group in /etc/suricata/suricata.yaml and add the Tor node addresses to it.

Unfortunately, not all of them only use a specific port (9001) or port range, so that a rule cannot be excluded via a port when sending data to another node, only the IP address remains for this.

Otherwise there is nothing left to do but to turn off the STREAM rules because, as you can see, they are masking other alarms that are unlikely to be false/positive.

8

@stevee I have good news.
So first, I have done a giant step forward in understanding how to use the firewall rules of ipfire (at least that’s what I hope :smiley: )

I’ve been using ipfire for over a decade now, I think, and apart from my really rocky early days, I haven’t touched the default behavior of the firewall again because I haven’t found the time or energy to read up on it. But since two days I have finally changed it again.
allowblock

What exactly this has to do with the topic, I have not yet fully understood, but somehow it is related, but before I had the opportunity to poke a supporter of the Tor network with my questions, whether a connection between IDS, Tor and extremely bad ping times is known and whether there are adjusting screws there.
And lo and behold, I was understood, it was explained to me that you can limit the maximum number of connections from one IP with the variable = DoSConnectionMaxConcurrentCount, which has a default value of 50, but can be lowered to 15 without the users experiencing any disadvantages.

Wouldn’t that be something that could be built into the Tor configuration? As it takes the load off the ipfire by dropping connections earlier, which mostly consist of dropped connections instead of continuing to monitor them?

These two changes have melted my IPS log to around 200 entries, which are manageable. Hopefully this is the end of my search for a solution. The only question that remains is why the firewall setting I made two days after changing the relay configuration also brought an improvement?

The Tor expert also commented on a strange message in the IPS log, where port 0 is listed with the message “SURICATA TCP header length too small”, meaning that the header could not be read completely. These messages appear up to 20 times in a row in the log from time to time.