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

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…

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?

Info in the wiki
https://wiki.ipfire.org/devel/mailing-lists

2 Likes

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 dont 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 :frowning:

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

IPSlog.zip (1.8 KB)

I have a few more, the log starts at the bottom with the 24minute pause after I hit save, so far, complete not just TLS.

When looking on your attached log, all entries can be nailed down to 4 or 5 different alerts.

I’ll adjust the rules again and call back after.

-Stefan

I’ve updated the rules file and uploaded it to my people folder.

https://people.ipfire.org/~stevee/ids-services/ipfire-tor.rules

You directly can grab the rules file and overwrite the existing one

/usr/share/suricata/rules/ipfire-tor.rules

on your IPFire system. Then please trigger a suricata rule reload by using the WUI or the following command:

/etc/init.d/suricata reload

Since todays morning I did not found any tor related alerts in my IDS logs anymore.

Best regards,

-Stefan

Since 12 o’clock no more SURICATA TLS messages and only one message tor related with SURICATA TCPv4 invalid checksum, so for now it is working, what did you do? Great work!
Can we make something like this with the Drop_hostile messages?
I have searched in the spamhouse blocklists but the blocked IP are not in there, where can I look in ipfire the lists and edit the file?

Thanks for the feedback that everything works fine now.

The file which holds the exported addresses and networks with the “DROP_HOSTILE” flag is located here:

/var/lib/location/ipset/XDv4.ipset

This file is autogenerated and will be overwritten each time the location database gets updated. This happens once a day.

-Stefan

yeah, but what have you done? One thing I noticed now, again I had 10 messages concerning Tor, this time it was →
SURICATA STREAM 3way handshake wrong seq wrong ack
BUT
that i read in the file ipfire-tor.rules →
msg: “LOCAL No alerts for 3way handshake with ack in wrong dir”
so it is in there but not effective, what do i have to change to make it work for this message?

I will have a look thank you!

Edit: Ok, I found the list and commented out the 9 IPs that just seemed to be cluttering up my log. I also saved the 9 affected IPs in a file in the same directory.
Now the question to the people who know, I need a script that every 24h after the XDv4.ipset file is updated, compares the two files and comments out or deletes every IP that is in my Tor node list from the new list.
If someone could take pity on me that would be cool.
Eternities ago I did something similar with the hosts file once, unfortunately I have this script what I have searched for it together no longer, since different lists were downloaded and put together and at the end still duplicate entries deleted.

Now that my log is clearer, I have a question about DROP_CTINVALID, what does it mean? Because here also from time to time Tor is present.
The two entries are new since this location blocklist update, but because I had tens of thousands of entries, I have first run so.
For an explanation I would be very grateful.

Thank you very much so far!

That is a completely different alert. I’ve adjusted the ipfire-tor.rules file and uploaded it again.

Please let me know if those messages are gone now.

Thanks in advance,

-Stefan

Are these changes stopping the logging of the results from these rules or are they stopping the actual use of the rules.

Are these changes only applying if you are using tor or in general usage as well.

How sure are we that all of these are false positives and that we are not hiding real issues that should be resolved. If they are real false positives then are these also being flagged up as bugs to suricata.