group with dst creates backwards rules
Brought to you by:
ktsaou,
philwhineray
Menu
▾
▴
#33 group with dst creates backwards rules
With "group with dst" in the config file, it generates rules such as:
-A in_public -d $ip -j in_group1
-A out_public -s $ip -j out_group2
This makes it check only the source IP for outgoing and the destination for incoming, but using the IP of the requested destination. The result is that no packets may go through for this case.
A patch to fix this is attached.
check "group with" direction
Logged In: YES
user_id=582393
Originator: NO
Hi,
The destination IP of incoming packets *IS* the source IP of outgoing packets.
Your IP is the destination IP for incoming packets and the source IP of outgoing packets.
I don' see any issues with that.
Costa
Logged In: NO
The issue is that it does not allow the traffic it was told to allow. It checks for the destination IP on the incoming chain, where it will see the IP in question as the source, and vice versa. Essentially, it generates impossible rules. This is clearly visible if you use firehol to generate rules with "group with dst" and view the resultant rules with "iptables -L".
Logged In: YES
user_id=582393
Originator: NO
Hi,
I think you have misunderstood how firehol works.
FireHOL rules given in the configuration file match the requests (FireHOL automatically matches the replies for you).
When the statement is a 'server', 'dst' matches the destination of the requests, i.e. the destination of *incoming* requests in 'interfaces', i.e. your host.
When the statement is a 'client' firehol automatically reverses src/dst by multiplexing the rules in the iptables chains and therefore 'dst' becomes 'src' automatically.
So:
group with dst 1.1.1.1
server smtp accept
group end
correctly matches 1.1.1.1 as 'dst' of the server requests (i.e. dst = the smtp server).
while:
group with dst 1.1.1.1
client smtp accept
group end
correctly matches 1.1.1.1 as 'src' of the client requests (i.e. src = the smtp client).
Follow the REQUEST and keep in mind that 'client' automatically reverses all rules indirectly applied to it.
Another way to think of it: 'dst' in groups has the same use as 'dst' in 'interface' statements.
Costa
Logged In: NO
I believe I see my mistake, then. I had expected "src" and "dst" to always correspond to the source and destination, respectively, in the generated rule. Therefore, something like:
group with dst "${REMOTE}"
client smtp accept
group end
would indicate to me that it should allow outgoing smtp addresses to the IP's in $REMOTE. Is it correct, then, that to allow outgoing connections to a dst, I need to use the server statement? It's been a while since I originally tried this, but I recall that 'client smtp accept dst "${REMOTE}"' worked as I expected, which is opposite how "group by" works. If this is the case, I will simply avoid using "group by dst" to avoid confusion (mine and anyone else who has to read the config file).
Logged In: YES
user_id=582393
Originator: NO
Look,
client smtp accept dst 1.1.1.1
correctly matches 1.1.1.1 as the destination of the client request.
But this 'dst' is *directly* applied to 'client' and 'client' is smart enough to understand that you are talking about a 'client' *request* that goes to the server at 1.1.1.1.
Check this:
group with dst 1.1.1.1
server smtp accept
client smtp accept dst 2.2.2.2
group end
The 'server' statement will attempt to match dst = 1.1.1.1, as expected.
But the 'client' will reverse 1.1.1.1 to 'src' (*indirectly* applied) of the client request and at the same time match 'dst' 2.2.2.2 (*directly* applied).
I hope it is clear now.
Costa
Logged In: NO
So, to put it simply, "client" within a "group with" reverses src and dst? So to allow connections from the local machine to machine foo, you would have to say:
group with src foo
service smtp accept
service http accept
end group
Do I have it right now?
I see now that trying to think about it in terms of the machine that firehol is running on will only serve to confuse.