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.
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…
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.
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.
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
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
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.
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
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?
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.
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.
