From owner-freebsd-questions Thu Jan 10 5:18:54 2002 Delivered-To: freebsd-questions@freebsd.org Received: from mail.27in.tv (roc-66-24-112-7.rochester.rr.com [66.24.112.7]) by hub.freebsd.org (Postfix) with ESMTP id 70BAF37B405 for ; Thu, 10 Jan 2002 05:18:42 -0800 (PST) Received: (from root@localhost) by mail.27in.tv (8.11.6/8.11.6) id g0ADIeY05414; Thu, 10 Jan 2002 08:18:40 -0500 (EST) (envelope-from cjm2@27in.tv) Received: from 27in.tv (roc-66-24-112-7.rochester.rr.com [66.24.112.7]) by mail.27in.tv (8.11.6/8.11.6av) with SMTP id g0ADIcL05391; Thu, 10 Jan 2002 08:18:38 -0500 (EST) (envelope-from cjm2@27in.tv) From: cjm2@27in.tv Received: from 216.153.201.172 (SquirrelMail authenticated user cjm2) by www.27in.tv with HTTP; Thu, 10 Jan 2002 08:18:39 -0500 (EST) Message-ID: <1239.216.153.201.172.1010668719.squirrel@www.27in.tv> Date: Thu, 10 Jan 2002 08:18:39 -0500 (EST) Subject: Re: weird problems with ipfw rule not applying itself... To: In-Reply-To: <20020109233526.R26608-100000@BLAST> References: <20020109233526.R26608-100000@BLAST> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: , X-Mailer: SquirrelMail (version 1.2.3 [cvs]) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bernie, Honestly, reject was probably the wrong term to use. I did a little more research and it looks like in this case an port unreachable (unreach 3) would be sent. --Chris > On Wed, 9 Jan 2002 cjm2@27in.tv wrote: > >> Joe, >> >> This is simply because TCP packets must be acknowledged in some form, >> even if it's just to reject the packet. When a port is open and has a >> listening service, an acknowledging packet is sent back to the client. >> When a port is open but has nothing listening to it, it is actively >> rejected. But, when you use ipfw to deny a packet it's simply >> dropped, nothing is ever sent to the requesting client. This is how >> nmap can tell the difference between the three different states >> open/closed/filtered. >> >> UDP packets are _not_ acknowledged by the receiving machine. So >> whether a packet is sent to an open port (with a listening service) or >> it is dropped by the firewall, it looks exactly the same to the >> requesting client. >> >> I do believe a reject is sent back to the client when the port isn't >> filtered but also has no listening service. Giving you the >> distinction between open/closed udp ports. >> >> Hope this helps. >> --Chris > is this what the 'reject' rule was about? > > > reject (Deprecated). Discard packets that match this rule, and > try to send an ICMP host unreachable notice. The > search > terminates. > > well, man says deprecated anyway, but that's what you mean isn't it? > > Regards > > Bernie > >> >> >> > I have a 4.4-RELEASE acting as a gateway. When I start out, my >> > ruleset >> > looks like this: >> > >> > gateway# ipfw show >> > 00100 43866683 26545107129 allow ip from any to any >> > 65535 0 0 deny ip from any to any >> > >> > Simple. Let everything through, and it works great. So then I >> > decided to completely block UDP port 514 (syslogd), so I issued >> > this command: >> > >> > ipfw add 00050 deny udp from any to any 514 >> > >> > So now my ruleset looks like this: >> > >> > gateway# ipfw show >> > 00050 0 0 deny udp from any to any 514 >> > 00100 43866913 26545121843 allow ip from any to any >> > 65535 0 0 deny ip from any to any >> > >> > >> > So far, so good. The problem is, then I run `nmap` from an off >> > network >> > site, and nmap tells me that UDP 514 is _open_ (!) How can this be >> > ? >> > >> > So I go back to the firewall and 'ipfw show' again, and I get: >> > >> > gateway# ipfw show >> > 00050 5 140 deny udp from any to any 514 >> > 00100 43866913 26545121843 allow ip from any to any >> > 65535 0 0 deny ip from any to any >> > >> > >> > So as you can see, the counters for the UDP 514 rule were >> > incremented and everything! So how come nmap still shows UDP 514 >> > as "open" ? >> > >> > As a test, I closed some tcp ports with the exact same command (but >> > with tcp, and port 443 this time) and nmap said those ports are >> > filtered...so that works...and I also tried with udp port 161, but >> > again, the rule is in, the rule counters even get incremented, but >> > nmap still says the port is OPEN. >> > >> > How can this be ? >> > >> > any help appreciated - thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message