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. 
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 
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…
You are right, in this case there is no way back.
To list all the files which are part of an archive use the following command:
tar -tvf ids-services-001.tar.gz
The current test version would overwrite the following files on the system:
- /var/ipfire/ids-functions.pl
- /srv/web/ipfire/cgi-bin/ids.cgi
- /srv/web/ipfire/cgi-bin/tor.cgi
- /etc/suricata/suricata.yaml
Then I mixed these two modes up - thanks for clarification!
Yes it would be possible to do something, in case you want to work on something and need help please mail our development mailing list.
Most blocklists are auto-generated, based on firewall hits, experience, filtering algorithms, test machines, honeypots etc. If you compare those a lot of the same addresses are part of each list.
-Stefan
Thank you very much, now i can save the files und do the test in the next days, I will try to send my experience through the mailing list, I hadn’t ever done this before.
The only I can do is to ask if somebody write the script what i mentioned, because I am not an IT expert I am normal user of software and coding is an other world.
I would say if you all were fine with a solution then you could implement a little checkbox which activated und disabled the script, because it makes no sence to block tor relays if you are hosting an own relay. My log is full of this Drop_Hostile messages on port 9001.
And if you promot a tor realy on ipfire it would be very nice to have this option. Off course I will try to be lucky and will ask the devs.
This could be because they copy from each other, and the Tor Exit Relays with bad reputation will always change together. Why should an attacker always choose the same exit relay?
If someone is afraid of Tor and wants his servers to be inaccessible to Tor, for example, he should simply block all Tor exit relays. This would help him better.
How do I so? How does it work? Do I need to sign in or register somewhere?
I still do not understand the principle, no idea whether I should / must register there now or whether I can just send a mail, I’m probably too stupid for, but what I do not understand I do not do first.
To the test file briefly summarized:
It worked for a short time, but could not reconstruct it and now all runs as usual, hundreds of messages in my IPS log.
What did I do:
I uploaded the file, executed the tar command and pressed save on IPS in the Web Gui,
And lo and behold, no more log entries, but only for a few minutes, I activated another list and saved again, and since then the log entries come back. the new list again deactivated the tar command again executed and saved. No change.
I don’t know if I did something wrong but it does not really work.
Edit keine Ahnung was die software hier gemacht hat ich wollte antworten und nicht editieren
Yes, you must register otherwise any mail sent will just be rejected. 4th line down in the wiki.
Go to this link
http://lists.ipfire.org/mailman/listinfo/development
and register. It just needs an email address and a password and then press submit.
You will receive a welcome email sent to the address you provided and you can then send to the dev mailing list.
The address is development@lists.ipfire.org
If you want to see the development mailing list archives then go to this link
http://lists.ipfire.org/pipermail/development/
2 Likes
Sorry for the very long delay, I was lacking some spare time in the past days 
Thanks for the very short feedback. I had a look on the code found the issue and fixed it properly.
(git.ipfire.org Git - people/stevee/ipfire-2.x.git/commit)
I also had a look on my IDS logs and adjusted the additional rules a bit to reduce the noise a bit more.
All of this efforts have been put into a new testing tarball (ids-services-002), which can be found in the same location as the first release.
The installation is the same, you also did not backup any additional files, because only files which are part of the first release have been touched.
Best regards,
-Stefan
1 Like
Absolutely no problem, private life has ever the preference.
It works for 24 minutes , but then SURICATA TLS come back again and with 25 messages, as if they were all held up and then all jump out at once.
This time I only do the tar command, press save on IPS page and nothing else
Please post those TLS messages.
Here tor is running for 4 hours now with only 4 generated alerts - none of them was TLS related.
-Stefan