From owner-freebsd-security Tue Jun 27 15:11:58 2000 Delivered-To: freebsd-security@freebsd.org Received: from relay1.inwind.it (relay1.inwind.it [212.141.53.67]) by hub.freebsd.org (Postfix) with ESMTP id 728AB37BB50 for ; Tue, 27 Jun 2000 15:11:42 -0700 (PDT) (envelope-from bartequi@inwind.it) Received: from bartequi.ottodomain.org (212.141.79.66) by relay1.inwind.it; 28 Jun 2000 00:11:26 +0200 From: Salvo Bartolotta Date: Tue, 27 Jun 2000 23:13:29 GMT Message-ID: <20000627.23132900@bartequi.ottodomain.org> Subject: Re: icmp type 3 code 4: a couple of questions To: Paul Hart Cc: freebsd-security@FreeBSD.ORG In-Reply-To: References: X-Mailer: SuperCalifragilis X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 6/27/00, 6:07:00 PM, Paul Hart wrote regarding Re:= =20 icmp type 3 code 4: a couple of questions: > On Tue, 27 Jun 2000, Salvo Bartolotta wrote: > > Well, actually, my homebox will behave, as it were, like a Klingon > > spaceship: for example, it will normally deny **all** icmptypes exce= pt > > type 3 code 4 (DF). When I need to ping, traceroute, etc., I will > > *temporarily* remove some restrictions. > If you are using IP Filter, why not let it do the work for you? > It is very easy to set up a "cloaked" firewall machine like you=20 describe > with IP Filter. In this situation, you can easily block all incoming > ICMP/UDP/TCP packets as a general rule and rely entirely on IP Filter > setting state rules for connections, traceroutes, or pings that were > initiated from behind the firewall. That will let traceroute and ping= > automatically work from behind the firewall out to hosts outside the > firewall, but you are otherwise 100% invisible to any other host on=20 the > Internet. > Paul Hart Dear Paul Hart, in replying to your message, I wish to thank also all the other=20 responders very much. Actually, I have been using ipfw so far, and I've come to discover an=20 apparent (maybe immaterial) limitation which concerns icmp filtering;=20 which has made me investigate ipfilter as a viable alternative (as the=20 saying goes, there's more than one way to do it). The main difference between ipfw and ipfilter seems to be mostly ..=20 teological; yet the ipfilter docs gave me the impression it is=20 slightly more flexible (~ fine-tunable, if I may say so) than ipfw. I am running ipfw with natd right now. My current understanding is: 1) ipfw + natd can do the desired job: if I allow icmptypes 3 and=20 block all outward bound icmp packets, I make my machine invisible=20 (Firewalk & the like won't see it). 2) ipfilter (& ipnat) can do the same job: in this case, I can allow=20 only icmp type 3 code 4 (DF); as to outgoing packets, rules analogous=20 with those applied with ipfw hold. As far as the final results are concerned, both methods should achieve=20 the same goal; ipfilter seems to offer a little more control over the=20 packets to be filtered, though. Stateful rules are available with both=20 of them. Is all this correct ? Am I missing anything else ? Needless to say, a packet filter is yet another protection layer. On=20 my homebox, most services are disabled. When I play the Klingon=20 spaceship, only few restrictions are removed; forgetting to restore=20 the dark cloak will only make me visible :-) Best regards, Salvo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message