Many thanks for the explanation. I really appreciate your answer and you gave to me a start point to research more on this subject. I will try to find some books in hope to expand my knowledge on this are.
Kind regards, Cristian On Sat, Jun 18, 2022 at 12:42 PM Janne Johansson <icepic...@gmail.com> wrote: > > Den lör 18 juni 2022 kl 11:17 skrev Cristian Danila <clau...@postmail.ro>: > > Good day! Does anyone know if OpenBSD(7.1) has the capability to be hidden > > against a pingscan(nmap -sn xxx.xxx.xxx.xxx)? > > In PF I have only 2 rules to block everything: > > block in quick all > > block out quick all > > > > This is a fresh OpenBSD7.1 with no other configuration in place. > > The only thing set is the default interface vic0 to allow dhcp > > > > By running a test with nmap -sn 192.168.121.131 I see this: > > Starting Nmap 7.92(https://nmap.org)at 2022-06-18 11:52 GTB Daylight Time > > Nmap scan report for 192.168.121.131 > > Host is up (0.00s latency). > > MAC Address: 00:0C:29:C3:D9:A7 (VMware) > > Nmap done: 1 IP address (1 host up) scanned in 0.46 seconds > > > > On scanned host I see this by running tcpdump -i vic0 > > 09:51:40.913770 arp who-has 192.168.121.131 tell 192.168.121.1 > > 09:51:40.913795 arp reply 192.168.121.131 is-at 00:0c:29:c3:d9:a7 > > arp is done "outside" of pf, that is why you see the arp exchange. > nmap lists this as "I know things about the hosts" and while it calls > it a "ping scan", it really hasn't got much in common with icmp pings, > but rather does an arp request and says that all hosts that respond > are "up". I'm sure a box can be all kinds of broken and still send out > arp replies, so you have to adapt your expectations of what "up" means > here. (first sentence on 'man nmap' on the part where it says what -sn > does is informative I guess?) > So while you can see an ethernet device with a mac and an IP does > exist on the local network, that is all you get. > > Then if you have "block in all" in PF no icmp, no tcp, no udp from any > host will get to the targets ip stack. > > The arp resolution is only visible for boxes on the same network, so > if I was to nmap from remote (assuming your gateway/router/fw allowed > the traffic) then the entity doing arp would be your gateway/router/fw > and not my box. Hence, I would not learn anything at all about your > machine except that it looks down from remote, but your > gateway/router/firewall would "learn" the info shown above in the nmap > output. > > If you REALLY wanted to not be visible even on the local ethernet, > then down the ethernet interface and do not put an ip on it. It would > also not be usable, but this is more or less what your PF config is > saying anyhow. > > > I am thinking(please correct me if I am wrong) that not all the traffic > > passes through pf hence this is why is not blocked. > > Sort of. arp is more like being on a lower level than the later ip > traffic for which pf will block all. > > > I would appreciate if someone could provide me a technical answer on this, > > even recommend me a book to read or docs regarding it. > > https://en.wikipedia.org/wiki/Address_Resolution_Protocol > > -- > May the most significant bit of your life be positive.
