From owner-freebsd-pf@FreeBSD.ORG Wed Oct 7 14:10:29 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B2D410656C0 for ; Wed, 7 Oct 2009 14:10:29 +0000 (UTC) (envelope-from nico@elico-it.be) Received: from zimbra-mx1.xenco.net (zimbra-mx1.xenco.net [79.132.229.23]) by mx1.freebsd.org (Postfix) with ESMTP id B7A978FC16 for ; Wed, 7 Oct 2009 14:10:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra-mx1.xenco.net (Postfix) with ESMTP id CBCAB4780E0 for ; Wed, 7 Oct 2009 16:10:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at xenco.net Received: from zimbra-mx1.xenco.net ([127.0.0.1]) by localhost (zimbra-mx1.xenco.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOZOitQyB2Nt for ; Wed, 7 Oct 2009 16:10:20 +0200 (CEST) Received: from zimbra-store.xenco.net (unknown [172.28.70.27]) by zimbra-mx1.xenco.net (Postfix) with ESMTP id 96D41478097 for ; Wed, 7 Oct 2009 16:10:20 +0200 (CEST) Date: Wed, 7 Oct 2009 16:10:19 +0200 (CEST) From: Nico De Dobbeleer To: freebsd-pf@freebsd.org Message-ID: <23087185.63661254924619867.JavaMail.root@zimbra-store> In-Reply-To: <24402806.63641254924566875.JavaMail.root@zimbra-store> MIME-Version: 1.0 X-Originating-IP: [213.118.152.199] X-Mailer: Zimbra 6.0.0_GA_1802.DEBIAN5 (ZimbraWebClient - FF3.0 (Win)/6.0.0_GA_1802.DEBIAN5) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: freebsd-pf Digest, Vol 263, Issue 3 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 14:10:29 -0000 From: "Nico De Dobbeleer" =20 > I just finished installing FreeBSD 7.x with pf in transparant bridging=20 > mode as the servers behind the firewall need to have an public=20 > ipaddress. Now is everything working fine and the FW is doing his job as= =20 > it should be. When I nmap the FW I see the open ports and closed ports.= =20 > Is there a way the get the FW running in stealth mode so that isn't=20 > possible anymore with nmap or any other scanning tool to see the open or= =20 > closed ports?=20 There is no "stealth". If a service responds to a request the port is=20 "open". If not it's closed.=20 Helmut=20 ------------------------------=20 Message: 3=20 Date: Tue, 6 Oct 2009 18:22:41 +0200=20 From: " ?? " =20 Subject: Re: freebsd-pf Stealth Modus=20 To: "Helmut Schneider" =20 Cc: Nico De Dobbeleer , freebsd-pf@freebsd.org=20 Message-ID: <20091006182241.79d16c8c@centaur.5550h.net>=20 Content-Type: text/plain; charset=3DUS-ASCII=20 On Tue, 6 Oct 2009 17:23:09 +0200=20 "Helmut Schneider" wrote:=20 > From: "Nico De Dobbeleer" =20 > > I just finished installing FreeBSD 7.x with pf in transparant=20 > > bridging mode as the servers behind the firewall need to have an=20 > > public ipaddress. Now is everything working fine and the FW is=20 > > doing his job as it should be. When I nmap the FW I see the open=20 > > ports and closed ports. Is there a way the get the FW running in=20 > > stealth mode so that isn't possible anymore with nmap or any other=20 > > scanning tool to see the open or closed ports?=20 >=20 > There is no "stealth". If a service responds to a request the port is=20 > "open". If not it's closed.=20 >=20 > Helmut=20 There is: just use "block drop" in your pf config or "set block-policy=20 drop" (see man 5 pf.conf). This effectively stops sending TCP RST or=20 UDP unreach packets.=20 ------------------------------=20 Message: 4=20 Date: Tue, 6 Oct 2009 20:28:33 +0200=20 From: "Helmut Schneider" =20 Subject: Re: freebsd-pf Stealth Modus=20 To: freebsd-pf@freebsd.org=20 Message-ID: =20 Content-Type: text/plain; format=3Dflowed; charset=3D"UTF-8";=20 reply-type=3Doriginal=20 =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD wrote:=20 > On Tue, 6 Oct 2009 17:23:09 +0200=20 > "Helmut Schneider" wrote:=20 >=20 >> From: "Nico De Dobbeleer" =20 >>> I just finished installing FreeBSD 7.x with pf in transparant=20 >>> bridging mode as the servers behind the firewall need to have an=20 >>> public ipaddress. Now is everything working fine and the FW is=20 >>> doing his job as it should be. When I nmap the FW I see the open=20 >>> ports and closed ports. Is there a way the get the FW running in=20 >>> stealth mode so that isn't possible anymore with nmap or any other=20 >>> scanning tool to see the open or closed ports?=20 >>=20 >> There is no "stealth". If a service responds to a request the port is=20 >> "open". If not it's closed.=20 >=20 > There is: just use "block drop" in your pf config or "set block-policy=20 > drop" (see man 5 pf.conf). This effectively stops sending TCP RST or=20 > UDP unreach packets.=20 Consider a webserver where you pass HTTP and "block drop" SSH. 1 port is=20 open -> host not "stealth".=20 But even if you "block drop" all incoming traffic to a host, if a host is= =20 really down (and therefore stealth) the hosts' gateway would send an ICMP= =20 type 3 packet (until you didn't cripple ICMP as well).=20 While sometimes it might be useful to "block drop" it has nothing to do wit= h=20 being "stealth".=20 Helmut=20 ------------------------------=20 Message: 5=20 Date: Tue, 6 Oct 2009 21:09:12 +0200=20 From: " ?? " =20 Subject: Re: freebsd-pf Stealth Modus=20 To: "Helmut Schneider" =20 Cc: freebsd-pf@freebsd.org=20 Message-ID: <20091006210912.379434eb@centaur.5550h.net>=20 Content-Type: text/plain; charset=3DUTF-8=20 On Tue, 6 Oct 2009 20:28:33 +0200=20 "Helmut Schneider" wrote:=20 > =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD wrote:=20 > > On Tue, 6 Oct 2009 17:23:09 +0200=20 > > "Helmut Schneider" wrote:=20 > >=20 > >> From: "Nico De Dobbeleer" =20 > >>> I just finished installing FreeBSD 7.x with pf in transparant=20 > >>> bridging mode as the servers behind the firewall need to have an=20 > >>> public ipaddress. Now is everything working fine and the FW is=20 > >>> doing his job as it should be. When I nmap the FW I see the open=20 > >>> ports and closed ports. Is there a way the get the FW running in=20 > >>> stealth mode so that isn't possible anymore with nmap or any other=20 > >>> scanning tool to see the open or closed ports?=20 > >>=20 > >> There is no "stealth". If a service responds to a request the port=20 > >> is "open". If not it's closed.=20 > >=20 > > There is: just use "block drop" in your pf config or "set=20 > > block-policy drop" (see man 5 pf.conf). This effectively stops=20 > > sending TCP RST or UDP unreach packets.=20 >=20 > Consider a webserver where you pass HTTP and "block drop" SSH. 1 port=20 > is open -> host not "stealth".=20 >=20 > But even if you "block drop" all incoming traffic to a host, if a=20 > host is really down (and therefore stealth) the hosts' gateway would=20 > send an ICMP type 3 packet (until you didn't cripple ICMP as well).=20 >=20 > While sometimes it might be useful to "block drop" it has nothing to=20 > do with being "stealth".=20 >=20 > Helmut=20 Not replying to a probe in the mentioned way is exactly what is=20 commonly referred to as "stealth mode" by consumer firewalls. Just try=20 a simple google search for "stealth firewall" and you will see.=20 Besides, if only a few (uncommon) ports are open, a limited scan is=20 unlikely to find them, thus calling it "stealth" (aka "low=20 observability" according to wikipedia) is appropriate imho. There is a=20 difference between stealth and invisibility.=20 ------------------------------=20 Message: 6=20 Date: Wed, 7 Oct 2009 11:40:36 +0200=20 From: "Helmut Schneider" =20 Subject: Re: freebsd-pf Stealth Modus=20 To: freebsd-pf@freebsd.org=20 Message-ID: =20 Content-Type: text/plain; format=3Dflowed; charset=3D"UTF-8";=20 reply-type=3Doriginal=20 =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD wrote:=20 > On Tue, 6 Oct 2009 20:28:33 +0200=20 > "Helmut Schneider" wrote:=20 >=20 >> =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD wrote:=20 >>> On Tue, 6 Oct 2009 17:23:09 +0200=20 >>> "Helmut Schneider" wrote:=20 >>>=20 >>>> From: "Nico De Dobbeleer" =20 >>>>> I just finished installing FreeBSD 7.x with pf in transparant=20 >>>>> bridging mode as the servers behind the firewall need to have an=20 >>>>> public ipaddress. Now is everything working fine and the FW is=20 >>>>> doing his job as it should be. When I nmap the FW I see the open=20 >>>>> ports and closed ports. Is there a way the get the FW running in=20 >>>>> stealth mode so that isn't possible anymore with nmap or any other=20 >>>>> scanning tool to see the open or closed ports?=20 >>>>=20 >>>> There is no "stealth". If a service responds to a request the port=20 >>>> is "open". If not it's closed.=20 >>>=20 >>> There is: just use "block drop" in your pf config or "set=20 >>> block-policy drop" (see man 5 pf.conf). This effectively stops=20 >>> sending TCP RST or UDP unreach packets.=20 >>=20 >> Consider a webserver where you pass HTTP and "block drop" SSH. 1 port=20 >> is open -> host not "stealth".=20 >>=20 >> But even if you "block drop" all incoming traffic to a host, if a=20 >> host is really down (and therefore stealth) the hosts' gateway would=20 >> send an ICMP type 3 packet (until you didn't cripple ICMP as well).=20 >>=20 >> While sometimes it might be useful to "block drop" it has nothing to=20 >> do with being "stealth".=20 >=20 > Not replying to a probe in the mentioned way is exactly what is=20 > commonly referred to as "stealth mode" by consumer firewalls. Just try=20 > a simple google search for "stealth firewall" and you will see.=20 I know the term "stealth firewall" very well. It's a worthless marketing=20 buzzword. It suggests users that it could prevent an attack or even the sca= n=20 itself. Neither is correct. This is what I wanted to point out and I was=20 encouraged by the fact that the OP was talking about "stealthing" open=20 ports.=20 -------------------=20 Already many thanks for the info. I'v added already the "set block-policy d= rop".=20 I'v done an nmap and it's apparently able to find out the setting below of = my pf FW:=20 MAC Address: 00:0E:2E:xx:xx:xx (Edimax Technology Co.)=20 Warning: OSScan results may be unreliable because we could not find at leas= t 1 open and 1 closed port=20 Device type: general purpose=20 Running: FreeBSD 7.X=20 OS details: FreeBSD 7.1-PRERELEASE=20 Uptime guess: 0.000 days (since Wed Oct 07 16:02:00 2009)=20 Network Distance: 1 hop=20 TCP Sequence Prediction: Difficulty=3D260 (Good luck!)=20 IP ID Sequence Generation: Incremental=20 Service Info: OS: FreeBSD=20 Is there a way to block this info?=20