| Summary: | If suricata crashes, the firewall accepts all packets | ||
|---|---|---|---|
| Product: | IPFire | Reporter: | Michael Tremer <michael.tremer> |
| Component: | --- | Assignee: | Stefan Schantl <stefan.schantl> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | Security | ||
| Priority: | - Unknown - | CC: | adolf.belka, arne.fitzenreiter, peter.mueller |
| Version: | 2 | ||
| Hardware: | unspecified | ||
| OS: | Unspecified | ||
| Attachments: | Proposed fix | ||
Created attachment 1511 [details]
Proposed fix
So this seems to be a "feature" where the queue, if Suricata fails, automatically accepts all packets. Great!
Could someone please test and confirm that this isn't going to break anything? I would like to include this patch in the update for c185.
I took a clone of my CU184 vm and updated it to CU185. I then stopped the IPS, made the change to the suricata.yaml file and restarted the IPS. The restart went without any problems. I will leave it running for the rest of the day and report back what I find. Thank you for your feedback.
There is maybe a think to look out for: So this change causes that if Suricata cannot process packets any more, they will just be accepted. That can happen in two cases:
a) Suricata crashes - which is the most extreme option. Then we have what was originally causing this bug report, or there is...
b) When Suricata cannot keep up. In the Kernel code this is here:
> https://git.ipfire.org/?p=thirdparty/kernel/linux.git;a=blob;f=net/netfilter/nfnetlink_queue.c;hb=c85af715cac0a951eea97393378e84bb49384734#l854
Formerly, the firewall then just accepted those packets which might have allowed connections through that otherwise would not have been accepted. And it would have caused that Suricata doesn't see the entire connection if it wanted to.
Now, we should log a message: nf_queue: full at N entries, dropping packets(s)
In a classic TCP connection, this won't hurt too much if there is only a short time when a couple of packets are being dropped, but with any UDP-based streams we might cause service degradation.
I didn't notice any issues with suricata running on my vm. However the vm network is setup on my green network at home and so all internet traffic is already filtered by suricata on my running IPFire physical system. So I can't easily test out the fix with a large amount of traffic. I also don't know how to make suricata crash, rather than just be stopped, and even if I did I don't know how to figure out if everything is working as planned. I think the testing of this needs to be done by other devs, more experienced than me. Thank you for confirming. I tried to do a couple of speed tests and didn't see any problems. So fingers crossed we are good to go.
I will make this bug public now as the patch has been pushed into master.
> https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=69031f7674295d6d95219a97063c718beecc1052
|
Hello, this is a problem that has been brought to my attention by Vodafone at home in Germany. Simply, the firewall opened all self-hosted services to the entire internet. I received emails about DNS and Portmapper being exposed to the Internet which seems to be something that even Vodafone does not like. I could confirm this and noticed that there was no misconfiguration on my side (for example a firewall rule that allowed more than it should have done). Actually the setup is really easy and simple in that location. So there was no apparent reason to accept any packets. Using iptables' TRACE, I found out, that packets were accepted in the IPS_INPUT chain which looks as follows: > Chain IPS_INPUT (1 references) > pkts bytes target prot opt in out source destination > 23604 2520K NFQUEUE 0 -- red0 * 0.0.0.0/0 0.0.0.0/0 NFQUEUE balance 0:3 bypass cpu-fanout > 199 26750 NFQUEUE 0 -- green0 * 0.0.0.0/0 0.0.0.0/0 NFQUEUE balance 0:3 bypass cpu-fanout Suricata for some reason was supposed to run but didn't and would even let me start it. I did not check why this is a problem, but that should be somewhat irrelevant for the scope of this bug. I flushed the chain and now the firewall behaves the correct way again and processes all packets properly. This firewall is running c183 and 6.6.15. I consider this a huge security problem that needs to be investigated as soon as possible. Either, there is a kernel bug, or we have misconfigured something. For the time being, I won't make this ticket public as this could be used as an easy attack vector by crashing Suricata and then receiving an open firewall.