Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Jan 2002 08:18:39 -0500 (EST)
From:      cjm2@27in.tv
To:        <Bernie_X@myrealbox.com>
Cc:        <pleaseworky@hotmail.com>, <freebsd-questions@freebsd.org>
Subject:   Re: weird problems with ipfw rule not applying itself...
Message-ID:  <1239.216.153.201.172.1010668719.squirrel@www.27in.tv>
In-Reply-To: <20020109233526.R26608-100000@BLAST>
References:  <20020109233526.R26608-100000@BLAST>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1239.216.153.201.172.1010668719.squirrel>