Expected pf behavior for TCP:SYN requests with block drop all

Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Expected pf behavior for TCP:SYN requests with block drop all

Dominique Fuchs
Hi everyone,

I‘m running OpenBSD 6.5 (release) on a server with a public IP but very limiting pf rules. I ran a nmap -sn on the corresponding address from another host to verify that it isn‘t detectable with a simple ICMP scan (please don‘t start a discussion how important this is - I do not say this is a real security benefit, I just like it on top of other security considerations). 

However, nmap unexpectedly returned ‚Host is up‘. Debugging output shows that the server responded with a TCP RA flag. This stumped me, because IMHO ‚block all‘ (which I really tested in the end as single rule with a seperate pf.config) results in ‚block drop all‘ by default, confirmed via pfctl -s rules.

Can someone point out me what I misunderstood here? My assumption was pf would really silently drop, including the absence of a TCP response. 

Thanks,
Dominique
Reply | Threaded
Open this post in threaded view
|

Re: Expected pf behavior for TCP:SYN requests with block drop all

Alexandr Nedvedicky
Hello,
On Tue, Aug 13, 2019 at 10:23:54PM +0200, Dominique Fuchs wrote:

> Hi everyone,
>
> I‘m running OpenBSD 6.5 (release) on a server with a public IP but very
> limiting pf rules. I ran a nmap -sn on the corresponding address from another
> host to verify that it isn‘t detectable with a simple ICMP scan (please don‘t
> start a discussion how important this is - I do not say this is a real
> security benefit, I just like it on top of other security considerations).
>
> However, nmap unexpectedly returned ‚Host is up‘. Debugging output shows that
> the server responded with a TCP RA flag. This stumped me, because IMHO ‚block
> all‘ (which I really tested in the end as single rule with a seperate
> pf.config) results in ‚block drop all‘ by default, confirmed via pfctl -s
> rules.
>
> Can someone point out me what I misunderstood here? My assumption was pf
> would really silently drop, including the absence of a TCP response.
>

    make sure the SYN packet, which triggered RST+ACK response is also
    blocked by 'block all' rule. If SYN (e.g. to port 22) is allowed
    by PF (e.g. there is a 'pass' rule), then RST+ACK is expected, when
    there is no sshd listening to on port 22.

regards
sasha