I have all the interfaces selected on my system and if I disable it and then re-enable it the time in the IPS system logs for it to complete its startup is around 50 seconds, certainly nothing like 10 minutes which definitely does not sound right.
Is it from the system logs that you get the 10 minutes time period or where?
Here is my system log for the IPS showing from rule reload starting to rule reload complete which takes the 50 seconds
22:45:07 suricata: rule reload starting
22:45:07 suricata: Including configuration file /var/ipfire/suricata/suricata-homenet.yaml.
22:45:07 suricata: Multipline "include" fields at the same level are deprecated and will not work in Suricata 8, please move to an array of include files: line: 14
22:45:07 suricata: Including configuration file /var/ipfire/suricata/suricata-dns-servers.yaml.
22:45:07 suricata: Including configuration file /var/ipfire/suricata/suricata-http-ports.yaml.
22:45:07 suricata: Including configuration file /var/ipfire/suricata/suricata-used-rulesfiles.yaml.
22:45:50 suricata: 14 rule files processed. 33709 rules successfully loaded, 0 rules failed, 0
22:45:50 suricata: Threshold config parsed: 0 rule(s) found
22:45:51 suricata: 33709 signatures processed. 0 are IP-only rules, 2681 are inspecting packet payload, 31003 inspect application layer, 0 are decoder event only
22:45:51 suricata: flowbit 'ET.000webhostpost' is checked but not set. Checked in 2052143 and 0 other sigs
22:45:51 suricata: flowbit 'is_proto_irc' is checked but not set. Checked in 2002029 and 4 other sigs
22:45:51 suricata: flowbit 'ET.http.javaclient.vulnerable' is checked but not set. Checked in 2013036 and 0 other sigs
22:45:51 suricata: flowbit 'ET.ELFDownload' is checked but not set. Checked in 2019896 and 0 other sigs
22:45:51 suricata: flowbit 'et.DocVBAProject' is checked but not set. Checked in 2020170 and 0 other sigs
22:45:51 suricata: flowbit 'ET.MSSQL' is checked but not set. Checked in 2020569 and 0 other sigs
22:45:51 suricata: flowbit 'ET.wininet.UA' is checked but not set. Checked in 2021312 and 0 other sigs
22:45:51 suricata: flowbit 'et.MS.XMLHTTP.ip.request' is checked but not set. Checked in 2022050 and 1 other sigs
22:45:51 suricata: flowbit 'et.MS.XMLHTTP.no.exe.request' is checked but not set. Checked in 2022053 and 0 other sigs
22:45:51 suricata: flowbit 'et.MCOFF' is checked but not set. Checked in 2022303 and 0 other sigs
22:45:51 suricata: flowbit 'et.MS.WinHttpRequest.no.exe.request' is checked but not set. Checked in 2022653 and 0 other sigs
22:45:51 suricata: flowbit 'ET.http.binary' is checked but not set. Checked in 2019421 and 5 other sigs
22:45:51 suricata: flowbit 'ET.armwget' is checked but not set. Checked in 2024242 and 0 other sigs
22:45:51 suricata: flowbit 'et.IE7.NoRef.NoCookie' is checked but not set. Checked in 2023671 and 9 other sigs
22:45:51 suricata: flowbit 'ET.smb.binary' is checked but not set. Checked in 2027402 and 4 other sigs
22:45:51 suricata: flowbit 'ET.Socks5.OnionReq' is checked but not set. Checked in 2027704 and 0 other sigs
22:45:51 suricata: flowbit 'ET.http.javaclient' is checked but not set. Checked in 2017181 and 5 other sigs
22:45:51 suricata: flowbit 'ET.autoit.ua' is checked but not set. Checked in 2019165 and 0 other sigs
22:45:51 suricata: flowbit 'min.gethttp' is checked but not set. Checked in 2023711 and 0 other sigs
22:45:51 suricata: flowbit 'ET.generictelegram' is checked but not set. Checked in 2045614 and 0 other sigs
22:45:51 suricata: flowbit 'et.WinHttpRequest' is checked but not set. Checked in 2019823 and 0 other sigs
22:45:51 suricata: flowbit 'HTTP.UncompressedFlash' is checked but not set. Checked in 2023313 and 0 other sigs
22:45:51 suricata: flowbit 'ET.pdf.in.http' is checked but not set. Checked in 2017150 and 3 other sigs
22:45:51 suricata: flowbit 'exe.no.referer' is checked but not set. Checked in 2020500 and 0 other sigs
22:45:51 suricata: flowbit 'ET.gocd.auth' is checked but not set. Checked in 2034333 and 0 other sigs
22:45:51 suricata: flowbit 'dcerpc.rpcnetlogon' is checked but not set. Checked in 2030870 and 6 other sigs
22:45:51 suricata: flowbit 'ET.JS.Obfus.Func' is checked but not set. Checked in 2017247 and 0 other sigs
22:45:57 suricata: rule reload complete
Just repeated it and this time it took a bit longer but still completed in 2 mins 24 secs.
I just have Abuse.ch and Emerging Threats providers and for Emerging Threats I have 12 of the rules selected.
Edit:
Tried a third time and this time it gave 2 mins 26 secs. So around 2.5 minutes seems to be the more usual time for rule reload to complete.
I just brought my supermicro ipfire machine build online and installed 190 iso downloaded from the web site.
The behaviour of the firewall is different, as it is not allowing traffic from orange network to green network and green network to orange network rules. The only firewall rules that works that I used before was orange network to red network-> deny and red network to orange network->drop.
What I had to do this time is make an orange network/host group for my devices that I named ādevicesā, then add the firewall rules: devices Network/Host Groups to green network-> accept and green network to devices Network/Host Groups->accept.
I know, I meant that I donāt known how suricata effectively drops traffic as I donāt see rules added to iptables by suricata.
I have been testing a bit more with this and I found that firewall reload does not do anything to the problem. But firewall restart makes both HTTPS from blue to orange and IMAP from orange to green work again. For now it has still to stop working again. But my eye catched āLast Updatedā field next to the rulesets in the webUI. These refresh daily, on different timestamps. So there are at least 4 reloads of the rulesets by suricata on a daily base. So Iām now suspecting that that is probably the cause for the behavior of it no longer working somewhere after minutes to hours.
With this information I went on and did a diff of the firewall before and the firewall after a suricata rules reload
(I used iptables-save | sed -e 's/\[[0-9:]*\]/[0,0]/' -e '/^#/d' for getting a deterministic firewall state I could compare)
And this is what it came up with:
> -A IPS -m comment --comment BYPASSED -m mark --mark 0x20000000/0x20000000 -j RETURN
> -A IPS -m mark --mark 0x40000000/0x40000000 -j CONNMARK --set-xmark 0x20000000/0x20000000
> -A IPS -m mark --mark 0x80000000/0x80000000 -j RETURN
> -A IPS -m mark ! --mark 0x10000000/0x10000000 -j RETURN
> -A IPS -m comment --comment WHITELISTED -m mark --mark 0x8000000/0x8000000 -j RETURN
> -A IPS -m comment --comment SCANNED -j NFQUEUE --queue-balance 0:3 --queue-bypass --queue-cpu-fanout
> -A IPS_CLEAR -j MARK --set-xmark 0x0/0xf0000000
> -A IPS_SCAN_IN -m mark --mark 0x80000000/0x80000000 -j RETURN
> -A IPS_SCAN_IN -i red0 -m policy --dir in --pol ipsec -j RETURN
> -A IPS_SCAN_IN -i red0 -j MARK --set-xmark 0x10000000/0x10000000
> -A IPS_SCAN_IN -i orange0 -j MARK --set-xmark 0x10000000/0x10000000
> -A IPS_SCAN_IN -i blue0 -j MARK --set-xmark 0x10000000/0x10000000
> -A IPS_SCAN_OUT -m mark --mark 0x80000000/0x80000000 -j RETURN
> -A IPS_SCAN_OUT -o red0 -m policy --dir out --pol ipsec -j RETURN
> -A IPS_SCAN_OUT -o red0 -j MARK --set-xmark 0x10000000/0x10000000
> -A IPS_SCAN_OUT -o orange0 -j MARK --set-xmark 0x10000000/0x10000000
> -A IPS_SCAN_OUT -o blue0 -j MARK --set-xmark 0x10000000/0x10000000
So these firewall rules are added by suricata on a rules reload so somehow one of these block my traffic. But I donāt see which one it could beā¦ Iām not familiar enough with iptables to know what happens here.
It was actually from looking at top and timing how long suricata takes up a full CPU before calming down again. I didnāt even think about checking logs during reload
I did a few reloads again, now checking the logs. The first 2 times I tried it only took 2-3 minutes now. A third time went to 8 min. A next try was 11 min. But then once again it finished back in 3 min. All this without me changing anything to the selected rulesets. So it seems to fluctuate a lot; possibly depending on other work the appliance has to do (firewalling, tor, vpn)
Those rules are actually just setting a mark on the traffic packet as with some flows the traffic comes back round a second time and if that occurs then the mark indicates that it has already been scanned and suricata does not scan it again and again and againā¦
Some are marked at 0x80000000 and others at 0x10000000 but I donāt know what the different marks mean. I was helping with some testing of some work on suricata 3 or 4 months ago and I saw these MARK values being set so I know what they are required for generally in principle but not specifically for an individual rule.
I will try and find some time tomorrow or the day after to try the top or htop approach. i looked at my cpu chart after I had done the reload but the percentage never went higher that about 10% to 15%, if I remember correctly. Of course the graph does not show very short lived percentage issues but also that 10% to 15% level only typically lasted between 10 and 45 seconds.
Will be interesting to see what top/htop shows in comparison.
You seem to have more variation than me but then my system is very under-loaded. There is only me, there is no streaming, gaming, video conferencing etc.
I donāt use tor and vpn (via OpenVPN) is only being used when I am away from home, so not so often.
So our respective loading profiles might be quite different and suricata can be quite resource intensive.
That is exactly why I want it enabled on Blue and Orange. It is disabled on Green and openVPN (edge case).
For Blue, that is the wireless network and I live in a city center with many wifiās around me. So if someone would gain unauthorized access to my blue network, I would like to have some intrusion protection in place to my other networks.
Orange is my DMZ, containing internet-facing servers. So if any server in my network would get hacked, that would be in the Orange network. So again, protecting my other networks against malicious actors on one of the Orange hosts, seems appropriate.
OpenVPN is an edge case. I think the chance that someone would gain unauthorized access to my VPN is much smaller than on Blue or Orange.
Another thing I noticed. When I whitelist the problem-host in orange, everything works and these rules are added to the firewall:
> -A IPS -s 192.168.2.2/32 -j MARK --set-xmark 0x8000000/0x8000000
> -A IPS -d 192.168.2.2/32 -j MARK --set-xmark 0x8000000/0x8000000
However when I then remove the host from the whitelist again, those 2 rules are removed immediately from iptables upon suricata rules reload, but everything still keeps on working until suricata is completely done with reloading. Then the traffic is blocked againā¦ So it must effectively be suricata itself blocking the traffic. Only not logging about it and with any one of the rulesets enabled.
In coming days I will try to get some more logging and/or stats out of suricata, hoping that I bump onto something.
If someone hacks the four way handshake and get in its not going to stop them and mac filtering became a useless item when others can clone mac addresses for the past couple of decades or so.
With the info you have on the MARK rules and the blocking, i think that you have enough info to raise a bug on it, or at the very least raise the question on the dev mailing list.
yes, but I was trying to duplicate the problem with logging into my printer on orange from my phone on blue via wifi.
I loose my printerās website printer.sdak about 15 minutes after reboot. but if I put in the orange ip address in my phone I connect to the printer.
I ran out of time this morning and have to go off to work, but I will try to add a dns server onto blue by using a raspberry pi plugged into the blue network switch.
Blue indeed should always have access to DNS (on IPFire) unless you added a rule to forbid it. Orange has no access to DNS; there I work with lP addresses and/or hosts files.
Hosts on Orange do have a DNS entry in IPFire here (Network > Edit hosts) and are resolvable as such from Green, Blue and OpenVPN.
I did have a similar issue a few times on previous CU, where suddenly a few hosts where no longer resolvable, while they definitely where defined in IPFire. But then a restart of the unbound service fixed it.
I only encountered this three times (in CU 189) and did not encounter it yet in CU 190. So Iām not sure why or how this happened, and it was not related with a (re)boot.
But you could also try to execute /etc/init.d/unbound restart to see if that (temporarily?) solves your DNS resolving problem?
EDIT: I checked to be sure, but in my case the DNS resolving still works, it really seems to be the HTTPS and IMAP traffic itself that gets blocked.
Hacking a WiFi is still a completely different matter than hacking a Firewall and/or an IPS. So someone competent enough to hack into the Wifi may or may not have the skillset to hack through the firewall. So I want to at least exclude those who donāt have the skillset and make sure that those who have, will have a difficult time hopefully making it not worth the time and effort of their attempt, so that they would give upā¦
Then another thread are my wife and children. Mainly the children. They operate the only Windows PCās I have in our house, (for gaming purposes) and I have little control over what they install on their machine. (I have already encountered and removed sketchy VPN software and a as mini-game disguised crypto miner, etcā¦ on their PC in the past)
Therefore, they are on Blue with restricted access to Green and IPS in between.
Iām not sure why you mention mac filtering? This is indeed easily spoofed, that is exactly why a system as IPS suricata is important to have next to a firewall. An IPS not only looks at which IP or MAC tries to access which port on which host but also looks at the traffic flows an tries to recognize and act upon suspicious behavior of otherwise normal traffic.
I tried restart, adding a dns to the mix as just a name server 1st, then tried using it as a secondary and primary with fowarders. No luck.
But what I do find interesting a wired computer plugged into the access pointās switch on blue can access it by ip or by printer,sdak but all wireless devices on blue can only access the printer by ip address.
I donāt have any wireless computers, but when I get a laptop, I guess I will have to add a wifi access point to green and use blue as guest wifi and devices like the TV, stereo, phones, roku, etc.
