DROP policy, serious vulnerability?

DISCUSSION dE 4 participants 5 messages Mar 19, 2015

lore

Share & tools

lore

dE

author

2015-03-19 05:51 UTC #0 lore raw

Hi!

I'm using the drop policy for iptables using the following --

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp -j ACCEPT
iptables -A INPUT -p udp -j ACCEPT
iptables -A INPUT -p tcp ! -i lo -m multiport --dports 0:79,81:65535 -m state --state NEW -j DROP

Unfortunately, in this configuration, none of the ports get blocks.

This implies that after an ACCEPT, further rules are not matched. Is this a bug or intended by design?

If this is by design, how am I supposed to use modules like connlimit with DROP policy.

Thanks for any help!

Neal Murphy

2015-03-19 06:43 UTC #1 lore raw

Quoted 12 lines · dE

Hi!
I'm using the drop policy for iptables using the following --
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp -j ACCEPT
iptables -A INPUT -p udp -j ACCEPT
iptables -A INPUT -p tcp ! -i lo -m multiport --dports 0:79,81:65535 -m state --state NEW -j DROP

Quoted 7 lines

Unfortunately, in this configuration, none of the ports get blocks.
This implies that after an ACCEPT, further rules are not matched. Is this a bug or intended by design?
If this is by design, how am I supposed to use modules like connlimit with DROP policy.

By design. Once a packet is accepted, no more rules are processed. To do otherwise would be akin to continuing to execute a program after an exit() statement.

In a mathmetical sense, netfilter rules are not commutative. Nor are they sorted into a most-specific to most-general order.

Rules are processed in the order in which they are added. Because you added a rule that ACCEPTS all TCP packets before the rule that REJECTs certain TCP packets, the prior rule always fires on TCP packets and the latter rule never fires.

If you want to affect specific packets, you must add such rules before you add the broader-reaching rules. Or you must insert such rules ahead of the broader rules.

dE

author

2015-03-19 07:21 UTC #2 lore raw

Quoted 32 lines · Neal Murphy

Quoted 12 lines · dE
Hi!
I'm using the drop policy for iptables using the following --
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp -j ACCEPT
iptables -A INPUT -p udp -j ACCEPT
iptables -A INPUT -p tcp ! -i lo -m multiport --dports 0:79,81:65535 -m state --state NEW -j DROP
Quoted 7 lines
Unfortunately, in this configuration, none of the ports get blocks.
This implies that after an ACCEPT, further rules are not matched. Is this a bug or intended by design?
If this is by design, how am I supposed to use modules like connlimit with DROP policy.
By design. Once a packet is accepted, no more rules are processed. To do otherwise would be akin to continuing to execute a program after an exit() statement.
In a mathmetical sense, netfilter rules are not commutative. Nor are they sorted into a most-specific to most-general order.
Rules are processed in the order in which they are added. Because you added a rule that ACCEPTS all TCP packets before the rule that REJECTs certain TCP packets, the prior rule always fires on TCP packets and the latter rule never fires.

Quoted 7 lines

If you want to affect specific packets, you must add such rules before you add the broader-reaching rules. Or you must insert such rules ahead of the broader rules.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Ok, thanks everyone for the quick response!

Hope this help others too.

André Paulsberg-Csibi

2015-03-19 11:25 UTC #3 lore raw

In reply to dE

I know you already have your answer (from Neal Murphy) , but I feel I need to mention that your RULE makes no sense in a pratical manner !

Now your rules are not working because the order is incorrect for your *plans* ,
but this even if you change the order , your setup makes less sense than do things the "normal" way .

To make the current set work you would not only have to change the order ,
But making new openings would require you to change one single rule with removing some ports from your DROP rule .

iptables -A INPUT -p tcp ! -i lo -m multiport --dports 0:79,81:65535 -m state --state NEW -j DROP iptables -A INPUT -p tcp -j ACCEPT
iptables -A INPUT -p udp -j ACCEPT

next time you would make a more complex multiport rule ...

iptables -A INPUT -p tcp ! -i lo -m multiport --dports 0:21,23:79,81:65535 -m state --state NEW -j DROP iptables -A INPUT -p tcp -j ACCEPT
iptables -A INPUT -p udp -j ACCEPT

next time you would make a even more complex multiport rule ...

iptables -A INPUT -p tcp ! -i lo -m multiport --dports 0:21,23:79,81:442,444:65535 -m state --state NEW -j DROP iptables -A INPUT -p tcp -j ACCEPT
iptables -A INPUT -p udp -j ACCEPT

This makes very little sense when you can just make ONE accept for all , and drop the rest !

iptables -A INPUT -p tcp -i lo -m multiport --dports 22,80,443 -j ACCEPT iptables -A INPUT -j DROP

I will mention I also removed your "iptables -A INPUT -p udp -j ACCEPT" ,
and I would have replaced that with one that gives the ports you want opened before the DROP rule .

Kind Regards André

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of dE
Sent: 19. mars 2015 06:52
To: [email protected]
Subject: DROP policy, serious vulnerability?

Hi!

I'm using the drop policy for iptables using the following --

This implies that after an ACCEPT, further rules are not matched. Is this a bug or intended by design?

If this is by design, how am I supposed to use modules like connlimit with DROP policy.

Thanks for any help!
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Noel Kuntze

2015-03-19 11:34 UTC #4 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

Additionally, you will never be able to communicate this host, because the policy in OUTPUT is DROP:

"iptables -P OUTPUT DROP"

Please read these docs on iptables rules and design to fix your setup:
http://inai.de/links/iptables/
https://github.com/QueuingKoala/netfilter-samples
http://sfvlug.editthis.info/wiki/Things_You_Should_Know_About_Netfilter
http://inai.de/images/nf-packet-flow.png

You do a lot of things wrong in your rule set. Please find out what these are and fix them yourself using the documents I referenced.

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 19.03.2015 um 12:25 schrieb André Paulsberg-Csibi:

Quoted 61 lines

I know you already have your answer (from Neal Murphy) , but I feel I need to mention that your RULE makes no sense in a pratical manner !
Now your rules are not working because the order is incorrect for your *plans* ,
but this even if you change the order , your setup makes less sense than do things the "normal" way .
To make the current set work you would not only have to change the order ,
But making new openings would require you to change one single rule with removing some ports from your DROP rule .
iptables -A INPUT -p tcp ! -i lo -m multiport --dports 0:79,81:65535 -m state --state NEW -j DROP iptables -A INPUT -p tcp -j ACCEPT
iptables -A INPUT -p udp -j ACCEPT
next time you would make a more complex multiport rule ...
iptables -A INPUT -p tcp ! -i lo -m multiport --dports 0:21,23:79,81:65535 -m state --state NEW -j DROP iptables -A INPUT -p tcp -j ACCEPT
iptables -A INPUT -p udp -j ACCEPT
next time you would make a even more complex multiport rule ...
iptables -A INPUT -p tcp ! -i lo -m multiport --dports 0:21,23:79,81:442,444:65535 -m state --state NEW -j DROP iptables -A INPUT -p tcp -j ACCEPT
iptables -A INPUT -p udp -j ACCEPT
This makes very little sense when you can just make ONE accept for all , and drop the rest !
iptables -A INPUT -p tcp -i lo -m multiport --dports 22,80,443 -j ACCEPT iptables -A INPUT -j DROP
I will mention I also removed your "iptables -A INPUT -p udp -j ACCEPT" ,
and I would have replaced that with one that gives the ports you want opened before the DROP rule .
Kind Regards André
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of dE
Sent: 19. mars 2015 06:52
To: [email protected]
Subject: DROP policy, serious vulnerability?
Hi!
I'm using the drop policy for iptables using the following --
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp -j ACCEPT
iptables -A INPUT -p udp -j ACCEPT
iptables -A INPUT -p tcp ! -i lo -m multiport --dports 0:79,81:65535 -m state --state NEW -j DROP
Unfortunately, in this configuration, none of the ports get blocks.
This implies that after an ACCEPT, further rules are not matched. Is this a bug or intended by design?
If this is by design, how am I supposed to use modules like connlimit with DROP policy.

Quoted 6 lines

Thanks for any help!
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
N��r��y��b�X��ǧv�^�)޺{.n�+��z��׫�{ay�ʇڙ�,j��f��h��z��w��j:+v��w�j�m��zZ+��ݢj"��!tml=

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVCrRSAAoJEDg5KY9j7GZYgnQP/jaMJbcnPRpROwVk5s49ozPc 0urtcfmNkMLvAS1wwWm67P4r0SEkU8nN6+6Zr/2Lr5M+TjVsqfleIjdxi/eK2Ph6 oz9AX+b/PMwEBbNDOTB5zQ1NzOSAF6ChmTfFmVQiAWKRl/wjxLBP5YjKp7cSEV6H EOXlFeY7SETxcw/OuOgGD1FsJ0W4z3DcvYTpns5waVXVfon/t+3S6FfGIaFxONuo RBiJiEAtqRnUD4jpEnnOraUQ4U/lXXSfzchwASVwe1+BMdPozCJVGMFaofOtMxjA GPHkr2TDBrLNt0VpC6HQCNNXKBVuktEgZ7oAQVXjwBev1GtZm32DsEPuGDXsvsSJ q1/Yb9uq1hNoqiJmaT0Pa/BTaWSJMTYXucwL1qTKbbid6SuIrd5fWcgE2DLm7Igw 8Z4V7XXuzetdqhyo3znv/qp0pzt46vQRfcvsBr0l1LLRQhAg++Obm9CFKHIWnh1U O4B754e4Lx2LhpMdOrsjVrA04dHq7IK7CDxtahRUcn8Ml66fhCWAR8D9rWNjoKBp NJ2f/3W+ohYD/Jj0e+CG2hA80gy7vfuUs+nvxOWSznCK103yA8zuyTCnmgCu3xK3 bdYHf6qkLQq8R/YVrUkAgb7GOxYwjitlVJSvbEhxtDxh8LFHfXm2jdSyXgMdnkNL G/yeZ+p0nFF8GtLwCjUE
=jHen
-----END PGP SIGNATURE-----