Rendered at 21:41:54 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
sargun 18 hours ago [-]
I accidentally took down our corporate network multiple times ~20 years ago, because I was setting up virtual networks with Linux machines acting as l2 bridges, and with proxy_arp to on. The DHCP server only checked for an arp reply, and I caused our server to run out of IPs. It had a cache and nobody knew how to clear it, so we just had to wait it out.
kevin_nisbet 16 hours ago [-]
Good ol proxy arp, also ~20 years ago I took out all cellular internet access in Canada. Luckily it was in the maintenance window and I acted pretty quick, so hopefully no one noticed the couple minutes of outage at 2AM.
cwillu 14 hours ago [-]
2am in Ontario or 2am somewhere more westward?
DANmode 18 hours ago [-]
> nobody knew how to clear it
That…ever get resolved?
no_carrier 15 hours ago [-]
I'm more interested to know about the endpoint that was responding to all IPs.
Also, minor nitpick:
> Without that we would have been reduced to tracing through switch ARP tables (for switches smart enough to report that)
You'd only need your switch to have a viewable mac address table rather than an ARP table.
JasuM 13 hours ago [-]
Doesn't this mean that the broken device also answered to every ARP request? And wouldn't that break the network by itself, regardless of DHCP behavior?
Chu4eeno 7 hours ago [-]
Yes, I'm assuming it must be implemented on purpose unless it broke everything, and monitored for unused addresses.
Could be some funnyman trying to reimplement ettercap.
drdexebtjl 18 hours ago [-]
Isn’t that a DoS vulnerability?
toast0 17 hours ago [-]
If somebody is arping for all the addresses on your broadcast domain, it will cause a denial of service, yes.
It will make your dhcp server mad, too.
Not much to do about that if you're not using managed switches. With managed switches, maybe you can spend an unreasonable amount of effort to try to prevent it, or you can just deal with it if it happens. Probably the 'right' way is to give each port its own broadcast domain and subnet, then it's pretty hard to mess up the other clients.
drdexebtjl 16 hours ago [-]
What would go wrong with the DHCP server if it simply did not check if someone’s responding to pings at that address before handing out the lease?
thyristan 16 hours ago [-]
Nothing with the DHCP server. But as per the article, many clients won't accept such an address. And even if they would accept it, duplicate IP assignments are yet another exciting and hard to debug network problem.
On the dhcp server, nothing really? But the address isn't usable if this host is arping for it.
nubinetwork 14 hours ago [-]
I believe some clients (dhcpcd, networkd) also do the check on their side, so it's possible that they reject the lease and ask for a new one if it's in use.
ram_rattle 17 hours ago [-]
lol, nice read.
damian260 14 hours ago [-]
[dead]
pixl97 20 hours ago [-]
Oh wow, that's a fun one. It sounds like the network card was in promiscuous mode.
>As promiscuous mode can be used in a malicious way to capture private data in transit on a network, computer security professionals might be interested in detecting network devices that are in promiscuous mode. In promiscuous mode, some software might send responses to frames even though they were addressed to another machine.
deadlyllama 19 hours ago [-]
Whatever it is, it's not that. A ping to a unicast IPv4 address in the local subnet won't be transmitted at the Ethernet layer until the IP has been resolved to an Ethernet MAC address via ARP. The troublesome host must have been responding to the broadcast ARP requests with ARP responses, too. Promiscuous mode makes no difference here as those ARP requests are broadcasts and you'll receive them with or without promiscuous mode.
wjholden 20 hours ago [-]
I did a small research project years ago (like 16 years ago) where I tried to detect hosts in promiscuous mode. The entire effort wasn't super relevant even in 2010 because switched networks had already largely replaced old hubs but it was interesting stuff.
The most interesting thing I remember looking at was a tool called Neped. I can't find the source but it might be here: https://www.apostols.org/projects. As I recall, Neped would do things exactly like this article says — send an ping packet to the right IP address but wrong MAC address and see if it responds. I probably have the details wrong but that's the idea. It was some really clever stuff. I always wonder what old vulnerabilities like this we would rediscover if we put new computers on old networks (especially hubs).
That…ever get resolved?
Also, minor nitpick:
> Without that we would have been reduced to tracing through switch ARP tables (for switches smart enough to report that)
You'd only need your switch to have a viewable mac address table rather than an ARP table.
Could be some funnyman trying to reimplement ettercap.
It will make your dhcp server mad, too.
Not much to do about that if you're not using managed switches. With managed switches, maybe you can spend an unreasonable amount of effort to try to prevent it, or you can just deal with it if it happens. Probably the 'right' way is to give each port its own broadcast domain and subnet, then it's pretty hard to mess up the other clients.
The wikipedia page even has a bit about this.
https://en.wikipedia.org/wiki/Promiscuous_mode
>As promiscuous mode can be used in a malicious way to capture private data in transit on a network, computer security professionals might be interested in detecting network devices that are in promiscuous mode. In promiscuous mode, some software might send responses to frames even though they were addressed to another machine.
The most interesting thing I remember looking at was a tool called Neped. I can't find the source but it might be here: https://www.apostols.org/projects. As I recall, Neped would do things exactly like this article says — send an ping packet to the right IP address but wrong MAC address and see if it responds. I probably have the details wrong but that's the idea. It was some really clever stuff. I always wonder what old vulnerabilities like this we would rediscover if we put new computers on old networks (especially hubs).