full-disclosure - ICMP (was: daily internet traffic report)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1098052513.3746.16.camel@je.nets.com>
From: hackerwacker at cybermesa.com (James Edwards)
Subject: ICMP (was: daily internet traffic report)

On Sun, 2004-10-17 at 15:46, Cedric Blancher wrote:
> Le dim 17/10/2004 à 22:21, James Edwards a écrit :
> > So, blocking ***all*** ICMP ***types*** is bad but you can block some
> > ***types*** without getting into trouble. Till you understand that all
> > the types do in relation to networking I would leave the alone.
> 
> Nowadays, using a decent stateful firewall allows one to get rid of ICMP
> filtering by associating ICMP errors to existing connections. As an
> example, when filtering using Netfilter, ICMP errors triggered by known
> IP connections are recognized as such (i.e. RELATED state) and thus can
> be filtered in a different way unsollicited ones (i.e. INVALID state)
> are.
> 
> This kind of feature allows one not to block valid ICMP stuff and keep
> away from direct ICMP solicitations you can filter the way you want.
> 
> My 0.02€...


That is great till you want to run a server behind that firewall.
The bigger picture, to me, is you gain little in security by blocking ICMP.

j
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20041017/cb31cf35/attachment.bin