#2... sorry typing error Re: port stealth mode?

[Jeremy Chadwick]

On Wed, Aug 20, 2008 at 07:16:11PM +0200, Leslie Jensen wrote:
> Jeremy Chadwick skrev:
>> On Wed, Aug 20, 2008 at 04:13:01PM +0200, Leslie Jensen wrote:
>>> I've done some testing with Steve Gibsons "Shields up"
>>> https://www.grc.com/x/ne.dll?bh0bkyd2
>>>
>>> These tests lists the ports as closed but visible.
>>>
>>> Instead the site suggest that one uses stealth so that the ports are 
>>> not  visible from the Internet.
>>>
>>> Is there a way to achieve this with PF?
>>
>> The "block" directive, along with "set block-policy drop" should suffice
>> for accomplishing this in pf.
>>
>
> Thank you Jeremy.
>
> I had "return" instead of "drop".
>
> Now when I do the test the ports 0, 1 and 53 are closed, not dropped.
>
> I do not have any rules to allow these ports.
>
> Any suggestions on what might be the reason for this?

Based on my own attempts using Gibson's utility (grudgingly I might
add), I have to assume he's talking about TCP ports and not UDP, and
that there's only three result states returned: open, closed, or
stealth.  I assume the following:

"Open" probably means a TCP connection was successfully made against the
specific port -- meaning, the standard TCP connection handshake was
successful (meaning a firewall is passing/allowing the TCP port, **and**
there is a program listening on that TCP port).

"Closed" probably means that a TCP connection failed against the
specific port, but received either a TCP RST in response or an ICMP
port unreachable message.

"Stealth" probably means that a TCP connection failed against the
specific port, and did not receive a TCP RST or ICMP port unreachable
message.

I can assure you that if you use pf's "block" directive, and ensure your
block-policy is set to "drop", the FreeBSD box *will not* send back a
TCP RST or an ICMP port unreachable when something attempts to connect
to said port.  Here's evidence:

72.20.106.125 attempts to connect to TCP port 89 on 72.20.106.126.
72.20.106.126 uses pf to block all incoming packets and only allow
certain ports through -- TCP port 89 of which is NOT passed:

14:39:55.188088 IP 72.20.106.125.59153 > 72.20.106.126.89: S 3525520536:3525520536(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp 1523753340 0,sackOK,eol>
14:39:58.186955 IP 72.20.106.125.59153 > 72.20.106.126.89: S 3525520536:3525520536(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp 1523756340 0,sackOK,eol>
14:40:01.386830 IP 72.20.106.125.59153 > 72.20.106.126.89: S 3525520536:3525520536(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp 1523759540 0,sackOK,eol>
14:40:04.586707 IP 72.20.106.125.59153 > 72.20.106.126.89: S 3525520536:3525520536(0) win 65535 <mss 1460,sackOK,eol>
14:40:07.786585 IP 72.20.106.125.59153 > 72.20.106.126.89: S 3525520536:3525520536(0) win 65535 <mss 1460,sackOK,eol>

As you can see, there's no sign of TCP RST being emit by 72.20.106.126
in response to the connection, and there's also no ICMP port
unreachable.

If you're not using pf at all, you can use the sysctls described in
the blackhole(4) manpage to achieve similar results -- but see the
WARNING part of the manpage.

Keep in mind that NAT port redirection can cause extra headaches, but it
doesn't sound like you're testing against an IP that redirects ports
via NAT.  If you do use NAT, and have certain TCP redirected via a
FreeBSD router to a machine on your local network, then there are
further complications which need to be discussed.

Again -- this is all speculative, because Gibson provides no technical
data regarding how his utility works or what he's basing the results on.
That is a serious problem, IMHO, and one reason why I tend to stay away
from his utilities.

Thirdly, regarding "ports 0 and 1" -- silly.  Look at /etc/services;
chances are you aren't using TCP or UDP port 1, and applications cannot
bind to TCP or UDP port 0 (doing so, AFAIK, results in an application
binding to an arbitrary/random port number), so I really have no idea
what he's testing there.  His own documentation even described this
fact.

Fourthly, you didn't state what FreeBSD version you're testing this
against, or what your pf rules look like.

Most importantly: you shouldn't base network/firewall security on the
results of Gibson's utility.  Meaning, if your goal is to make "Shields
Up!" return a non-failure result, then you're probably wasting your
time.

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |