Hi again,
I know I can be a pain in the ass, but I’m starting to get all the bugs fixed that have crept in lately.
So please be patient with me soon everything runs and you have again your peace from me
As I’ve noted here before, my Tor Relay suddenly had problems with the IPS and a deactivation of a certain ruleset initially helped, but a short time later the relay was frozen again, because all traffic is blocked at some point.
Meanwhile I am of the opinion that a ruleset is responsible for it, which I have not selected at all and namely that of SURICATA itself, but for this I find no rules where I can deactivate rule. Where does this ruleset come from, can I deactivate it manually so that only the rules that can be easily edited are used? Why are these rules not displayed? Or what is SURICATA that shows up in the IPS log and disconnects on port 9001? Can someone please enlighten me, I for one understood that if ET shows up in the log it can be found in the Emergingthreats.net ruleset and so on.
This seems to be a similar phenomenon as with me, rules that appear, although they are not in the ruleset. This came with the last update, was also in the change log what was changed in IPS system.
Only with me these are not only unwanted log entries, with me since the update also the Tor relay is disturbed.
I am currently testing which provider of the ruleset is responsible for this.
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.
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
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
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.
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.
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.
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.
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.
