Expected pf behavior for TCP:SYN requests with block drop all
Dominique Fuchs <[email protected]> Tue, 13 Aug 2019 22:23:54 +0200
| Newsgroups | gmane.os.openbsd.pf |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail-542FC453-8B6C-4113-BA04-2586E6246F51 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone, I=E2=80=98m running OpenBSD 6.5 (release) on a server with a public IP but v= ery limiting pf rules. I ran a nmap -sn on the corresponding address from an= other host to verify that it isn=E2=80=98t detectable with a simple ICMP sca= n (please don=E2=80=98t start a discussion how important this is - I do not s= ay this is a real security benefit, I just like it on top of other security c= onsiderations).=20 However, nmap unexpectedly returned =E2=80=9AHost is up=E2=80=98. Debugging o= utput shows that the server responded with a TCP RA flag. This stumped me, b= ecause IMHO =E2=80=9Ablock all=E2=80=98 (which I really tested in the end as= single rule with a seperate pf.config) results in =E2=80=9Ablock drop all=E2= =80=98 by default, confirmed via pfctl -s rules. Can someone point out me what I misunderstood here? My assumption was pf wou= ld really silently drop, including the absence of a TCP response.=20 Thanks, Dominique= --Apple-Mail-542FC453-8B6C-4113-BA04-2586E6246F51 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><span></span></div><div di= r=3D"ltr"><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8">Hi everyone,<div dir=3D"ltr"></div><div><br></div><div>I=E2=80=98m ru= nning OpenBSD 6.5 (release) on a server with a public IP but very limiting p= f rules. I ran a <i>nmap -sn</i> on the corresponding address from another h= ost to verify that it isn=E2=80=98t detectable with a simple ICMP scan (plea= se don=E2=80=98t start a discussion how important this is - I do not say thi= s is a real security benefit, I just like it on top of other security consid= erations). </div><div><br></div><div>However, nmap unexpectedly returne= d =E2=80=9AHost is up=E2=80=98. Debugging output shows that the server respo= nded with a TCP RA flag. This stumped me, because IMHO =E2=80=9A<b>block all= </b>=E2=80=98 (which I really tested in the end as single rule with a sepera= te pf.config) results in =E2=80=9A<i>block <b>drop</b> all</i>=E2=80=98 by d= efault, confirmed via <i>pfctl -s rules</i>.</div><div><br></div><div>Can so= meone point out me what I misunderstood here? My assumption was pf would rea= lly silently drop, including the absence of a TCP response. </div><div>= <br></div><div>Thanks,</div><div>Dominique</div></div></body></html>= --Apple-Mail-542FC453-8B6C-4113-BA04-2586E6246F51--