Can we move INPUT_direct and FORWARD_direct to the top of INPUT/FORWARD about firewalld HOT 8 CLOSED

There is another issue with the conntrack entry before any other chain:

I cannot block intruders while they are holding a connection! For example a drop entry in IN_public_deny will only take effect once the hacker starts a new connection.

This looks like a major security problem to me.

from firewalld.

I thought about addition something similar as the prefiter flag also some time ago. But this would require to change the D-Bus interface of the direct interface in firewalld. Which would break existing services using it.

There is a solution without the need to change the interface: Use a passthrough rule to add a rule in the first line of the INPUT, .. chain. In this rule you can also jump into chains you have created with the --add-chain option in the same ipv and table.

from firewalld.

I have to admit I don't enough about the D-Bus interface, but I'm guessing that rules out option 1. However is there any reason we can't do 2 - i.e. create a standard chain that runs first up before any conntrack.

I understand that you can use --passthrough - that is essentially what I say in the second paragraph above. The issue is that this would be hard to do in any sort of automatic install - for example in an init script. The --passthrough option only works if use --permanent (if you don't, your changes will be lost when you do a --reload), it is also hard to do a remove (essentially you have to do it by rule number - hoping that it is still number 1 in the INPUT chain).

It would be better to do it as a standard chain with a known (pre-defined) name. What happens if there are multiple kernel modules that wan't to get ahead of conntrack?

from firewalld.

@t-woerner any news on this?

from firewalld.

Ping?

from firewalld.

We're currently working on an nftables backend, which would be a good time to make a change like this. That being said, I don't think it's likely to happen with the iptables backend for the reasons @t-woerner mentions above. The passthrough solution is a bit hacky, but it's the best option right now.

from firewalld.

FWIW, here's one way to (manually) fulfill the description of this ticket. It effectively "moves" INPUT_direct & FORWARD_direct to the top of their respective chains.

# firewall-cmd --direct --passthrough ipv4 -D INPUT -j INPUT_direct                                                          
# firewall-cmd --direct --passthrough ipv6 -D INPUT -j INPUT_direct                                                          
# firewall-cmd --direct --passthrough ipv4 -D FORWARD -j FORWARD_direct                                                          # firewall-cmd --direct --passthrough ipv6 -D FORWARD -j FORWARD_direct                                                          
# firewall-cmd --direct --passthrough ipv4 -I INPUT 1 -j INPUT_direct
# firewall-cmd --direct --passthrough ipv6 -I INPUT 1 -j INPUT_direct
# firewall-cmd --direct --passthrough ipv4 -I FORWARD 1 -j FORWARD_direct
# firewall-cmd --direct --passthrough ipv6 -I FORWARD 1 -j FORWARD_direct

Making the above --permanent produces the following direct.xml, which works, with the caveat that firewalld does not actually execute the -D arguments. As it is, it's an imperfect workaround.

<?xml version="1.0" encoding="utf-8"?>
<direct>
  <passthrough ipv="ipv4">-D INPUT -j INPUT_direct</passthrough>
  <passthrough ipv="ipv6">-D INPUT -j INPUT_direct</passthrough>
  <passthrough ipv="ipv4">-D FORWARD -j FORWARD_direct</passthrough>
  <passthrough ipv="ipv6">-D FORWARD -j FORWARD_direct</passthrough>
  <passthrough ipv="ipv4">-I INPUT 1 -j INPUT_direct</passthrough>
  <passthrough ipv="ipv6">-I INPUT 1 -j INPUT_direct</passthrough>
  <passthrough ipv="ipv4">-I FORWARD 1 -j FORWARD_direct</passthrough>
  <passthrough ipv="ipv6">-I FORWARD 1 -j FORWARD_direct</passthrough>
</direct>

Without hacking, the result is 'permanent' INPUT & FORWARD chains with duplicate rules. The direct.xml INPUT_direct & FORWARD_direct jumps are successfully reinserted at the top of each chain, but the originals still exist further down in the rule set too.

It would be very helpful if direct passthrough does what it implies. It's misleading and took a bit of spelunking to figure out that I was being saved from myself. My expectation was that firewalld would pass through ALL direct arguments. But, I was wrong.

firewalld[3301]: WARNING: INVALID_PASSTHROUGH: arg '-D' is not allowed

IMHO, passthrough should at least support "-D", "--delete". Making that happen takes minimal effort and could effectively resolve many issues for many users. The fact that direct.xml gets processed last allows for workarounds like this to function as expected & allows for fine tuning.

I tested this change, with the above XML, and it works as expected.

The same logic works for the other chains too, e.g. OUTPUT

HTH

from firewalld.

This was addressed with the new nftables backend (v0.6.0). Direct rules have higher precedence and occur before any other firewalld rules. For more info please read the blog post: https://firewalld.org/2018/07/nftables-backend

from firewalld.