Re: Blocking ping scan
On 18/06/2022 12:15, Cristian Danila wrote: 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 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. I would appreciate if someone could provide me a technical answer on this, even recommend me a book to read or docs regarding it. Kind regards, Claudiu Apparently you are on the same network, that's why the arp(4) reply. If you're not (and 192.168.121.1 is your gateway) then maybe want to add block drop or set block-policy drop your pf rule blocks icmp and rest of ip(4) traffic ping 192.168.121.131 to verify.
Re: Blocking ping scan
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 wrote: > > Den lör 18 juni 2022 kl 11:17 skrev Cristian Danila : > > 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.
Re: Blocking ping scan
On 2022-06-18, Janne Johansson wrote: > Den lör 18 juni 2022 kl 11:17 skrev Cristian Danila : >> 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. Additionally if you disallow ARP, IP won't work at all. You may be able to restrict ARP by using a bridge interface and MAC address filters but it won't be pretty.
Re: Blocking ping scan
Den lör 18 juni 2022 kl 11:17 skrev Cristian Danila : > 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.
Blocking ping scan
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 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. I would appreciate if someone could provide me a technical answer on this, even recommend me a book to read or docs regarding it. Kind regards, Claudiu
