[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nanog
Subject:    Re: [nsp] known networks for broadcast ping attacks
From:       Systems Engineer <snash () lightning ! net>
Date:       1997-07-30 22:03:25
[Download RAW message or body]

Well to allow ICMP is good for just basic pinging of you or a
traceroute.  I really dont care if other people can traceroute or ping
me so i just deny those lines i mentioned before,  and all ICMP as a
whole.
Until the bug passes and/or gets fixed somehow, I am going to keep those
lines.


root@gannett.com wrote:

> On Wed, 30 Jul 1997, Systems Engineer wrote:
>
> > Well ever since this but was introduced to the outside world,  I
> have
> > since modified my present Firewall (ipfwadm v2.3.0) to accomodate.
> >
> > type  prot source               destination          ports
> > deny  icmp 0.0.0.0              0.0.0.255            any
> > deny  icmp 0.0.0.255            0.0.0.0              any
> >
>
> My rule is:
>
> deny icmp   0.0.0.0 0.0.0.0 any
>
> With perhaps specific permits above that for devices that I find have
> a legitimate need for ICMP (be it unreachables, or echo/echo reply).
>
> I was wondering more if there were a good reason, other than for
> dial-up
> users who may need connectivity checks, to allow any ICMP in, or ICMP
> to
> say anything more than a terminal server's address range and certain
> hosts.
>
> Hence my prior discussion on ping-mapping netblocks, and its lack of
> applicability to the number of hosts on my network.
>
> Paul
> ----
> --------------------------------------------------------------------
> Paul D. Robertson
> gatekeeper@gannett.com



--
---     ---     ---     ---     ---     ---     ---     ---     ---
Steven Nash                             ph:  (516)248-8400ext25
Systems Engineer / Network Security    fax:  (516)248-8897
Lightning Internet Services LLC      email:  snash@lightning.net
http://www.lightning.net
---     ---     ---     ---     ---     ---     ---     ---     ---

[prev in list] [next in list] [prev in thread] [next in thread]