DROP policy, serious vulnerability?

DROP policy, serious vulnerability?

[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

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!

Re: DROP policy, serious vulnerability?

[Neal Murphy]

On Thursday, March 19, 2015 01:51:44 AM dE wrote:
> 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.

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.

Re: DROP policy, serious vulnerability?

[dE]

On 03/19/15 12:13, Neal Murphy wrote:
> On Thursday, March 19, 2015 01:51:44 AM dE wrote:
>> 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.
> 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.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ok, thanks everyone for the quick response!

Hope this help others too.

RE: DROP policy, serious vulnerability?

[André Paulsberg-Csibi]

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: netfilter-owner@vger.kernel.org [mailto:netfilter-owner@vger.kernel.org] On Behalf Of dE
Sent: 19. mars 2015 06:52
To: netfilter@vger.kernel.org
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.

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

Re: DROP policy, serious vulnerability?

[Noel Kuntze]

-----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:
> 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: netfilter-owner@vger.kernel.org [mailto:netfilter-owner@vger.kernel.org] On Behalf Of dE
> Sent: 19. mars 2015 06:52
> To: netfilter@vger.kernel.org
> 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.
>
> Thanks for any help!
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> N�����r��y���b�X��ǧv�^�)޺{.n�+���z��׫�{ay�\x1dʇڙ�,j\a��f���h���z�\x1e�w���\f���j:+v���w�j�m����\a����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-----