[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <921768889.20050511220508@soltysiak.com>
Date: Wed, 11 May 2005 22:05:08 +0200
From: Maciej Soltysiak <maciej@...tysiak.com>
To: bugtraq@...urityfocus.com
Cc: Alok Menghrajani - Ilion Security SA <alok@...onsecurity.ch>
Subject: Re: TCP/IP implementations do not adequately validate ICMP error messages
Hello Alok,
Tuesday, May 10, 2005, 4:51:25 PM, you wrote:
> when I add the following rule to iptables, the linux server (Kernel
> 2.4.29-grsec) is no longer vulnerable to the DOS:
> iptables -I INPUT 1 -p icmp -j DROP
Um. Other way round:
1) setup a default drop policy
# iptables -P INPUT DROP
2) accept only what you want
# related and established traffic
# iptables -A INPUT -m state --state ESTABLISHED, RELATED -j ACCEPT
# allow only type: echo request, code: 0 (proper rfc ping)
# iptables -A INPUT -p icmp --icmp-type 8/0 -j ACCEPT
# other rules
> I am interested in knowing if this work around makes any sense. Please
> keep me informed about this vulnerability.
Unless you are accepting stateful RELATED ICMP traffic, you are propably fine,
but are just missing rules to allow PING, which is a RFC MUST AFAIR.
If not, you are doing a very bad thing. ICMP is really required for
error reporting. You really, really do not want to miss out on these,
as it may get you to problems like:
- being unable to detect a need for fragmentation
- being unable to receive dest.unreach. icmps which will cause delays
and timeouts.
Blocking all icmp by ISPs is called being criminally brain-dead
in a help message of the TCPMSS module for iptables in the kernel source :-)
--
Best regards,
Maciej
Powered by blists - more mailing lists