Re: DROP policy, serious vulnerability?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux