2 ms·

At the risk of becoming a real bore, I'll spell out why I think this is a really, really dumb thing: If you have anything to do with fire fighting (and we all

At the risk of becoming a real bore, I'll spell out why I think this is a really, really dumb thing: If you have anything to do with fire fighting (and we all do in a way) you soon learn that there are three things required for a fire: * Something to burn * Air (strictly speaking: Oxygen) * Something to start the fire (source of ignition) Fire prevention is based around avoiding having all three things together at any point in time. So, putting out a fire often involves removing oxygen or removing the burning thing. Prevention can be as simple as making a rule at home that no one puts dish cloths on the hob to dry. That last phrase may need some translating! So, you put your webby app or VM out on the internets for all to see and play with. Unlike your home front door, every Tom, Dick and Harry in the world can go and take a playful kick at it. So you need to take some care with it. There is no simple set of three factors that you can protect against as there is for fire prevention. Instead you need to follow some good practice and hope for the best. One good (not best - there is no such thing) practice is to avoid giving away information unnecessarily. Linking IP to MAC is such a thing. Do it at home if you must but don't do it in public.

tovej 5y ago
The automatic host numbering feature in the IPV6 standard (modified EUI-64,RFC 4291) was a big mistake. But I thought that worked the other way? that the MAC was part of the IP, not the IP part of the MAC.
- gerdesj 5y ago
  "that the MAC was part of the IP, not the IP part of the MAC." The IPv6 link local address is derived from the MAC address. I can't be arsed to look up the current RFCs so let's take a look at my laptop, that I'm using now (yes, I have changed a few digits but only for global addresses): 2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e4:70:b8:f1:6b:5c brd ff:ff:ff:ff:ff:ff inet 10.200.201.164/24 brd 10.200.200.255 scope global dynamic noprefixroute wlp2s0 valid_lft 73049sec preferred_lft 73049sec inet6 2001:3d49:ad52:ddc8:6ba8:e800:8e96:143b/64 scope global temporary dynamic valid_lft 86387sec preferred_lft 14387sec inet6 2001:3d49:ad52:ddc8:5203:e5fe:5ed0:c173/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 86387sec preferred_lft 14387sec inet6 fe80::506d:9c2f:8b7b:1d7e/64 scope link noprefixroute valid_lft forever preferred_lft forever My link local address is fe80::506d:9c2f:8b7b:1d7e and my MAC address for that interface is e4:70:b8:f1:6b:5c <sound-effect>scratched-record</sound-effect> It seems that times have changed. This is a laptop that uses Network Manager on Arch Linux. If I had to guess I suspect that the bloke who does NM has fixed that flaw or he's following a newer standard/RFC than I've (bothered to have) heard of. All this stuff points out a strange dichotomy: you want to be seen ("Hello look at my website") and yet you don't want to be seen by the baddies. You want to draw attention to your wares but not have a bunch of state sponsored folk poking at your unmentionables and nicking your cash. As of fairly recently, we are seeing quite a lot of remediation (for want of a better word) by additional state sponsored actors than is considered normal. These are not the usual lot who piss on your prized Begonias. This lot seem to know when to widdle effectively.
  - tovej 5y ago
    Yeah, automatic host discovery puts the MAC address (almost) verbatim at the end of an interface IP, but it's an optional feature. In the vuln report, it turns out automatic host discovery is used after all, but the IPv4 is also based on this, which confused me. The MAC address was: 42:01:0a:80:00:02 The IPv6 address was: fe80::4001:aff:fe80:2 It's not just the last four bytes, it's the whole MAC address, but 0xFFFE is crammed in the middle of the MAC address, and the first byte's second to last bit is flipped. We can see that this is exacly the scheme that was used. Now the confusing part is that the IPv4 address is apparently also the MAC address: MAC 42:01:0a: 80:00:02 IPv6 fe80::40 01:0a ff:fe 80:00 02 ^ ^^ ^^ flipped bit inserted IPv4(hex) 0a. 80. 0. 2 (dec) 10. 128. 0. 2 Now the confusing part is that the IPv4 address is apparently also based on the MAC address, which means the IPv4, and MAC addresses can both be derived from the IPv6 address, and the IPv4 address can be derived from the MAC address. (The entire host section of the IPv6 address is based on the MAC iirc, so the network section is the only part you need to guess there.)

tovej 5y ago

The automatic host numbering feature in the IPV6 standard (modified EUI-64,RFC 4291) was a big mistake. But I thought that worked the other way? that the MAC was part of the IP, not the IP part of the MAC.

gerdesj 5y ago
"that the MAC was part of the IP, not the IP part of the MAC." The IPv6 link local address is derived from the MAC address. I can't be arsed to look up the current RFCs so let's take a look at my laptop, that I'm using now (yes, I have changed a few digits but only for global addresses): 2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e4:70:b8:f1:6b:5c brd ff:ff:ff:ff:ff:ff inet 10.200.201.164/24 brd 10.200.200.255 scope global dynamic noprefixroute wlp2s0 valid_lft 73049sec preferred_lft 73049sec inet6 2001:3d49:ad52:ddc8:6ba8:e800:8e96:143b/64 scope global temporary dynamic valid_lft 86387sec preferred_lft 14387sec inet6 2001:3d49:ad52:ddc8:5203:e5fe:5ed0:c173/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 86387sec preferred_lft 14387sec inet6 fe80::506d:9c2f:8b7b:1d7e/64 scope link noprefixroute valid_lft forever preferred_lft forever My link local address is fe80::506d:9c2f:8b7b:1d7e and my MAC address for that interface is e4:70:b8:f1:6b:5c <sound-effect>scratched-record</sound-effect> It seems that times have changed. This is a laptop that uses Network Manager on Arch Linux. If I had to guess I suspect that the bloke who does NM has fixed that flaw or he's following a newer standard/RFC than I've (bothered to have) heard of. All this stuff points out a strange dichotomy: you want to be seen ("Hello look at my website") and yet you don't want to be seen by the baddies. You want to draw attention to your wares but not have a bunch of state sponsored folk poking at your unmentionables and nicking your cash. As of fairly recently, we are seeing quite a lot of remediation (for want of a better word) by additional state sponsored actors than is considered normal. These are not the usual lot who piss on your prized Begonias. This lot seem to know when to widdle effectively.
- tovej 5y ago
  Yeah, automatic host discovery puts the MAC address (almost) verbatim at the end of an interface IP, but it's an optional feature. In the vuln report, it turns out automatic host discovery is used after all, but the IPv4 is also based on this, which confused me. The MAC address was: 42:01:0a:80:00:02 The IPv6 address was: fe80::4001:aff:fe80:2 It's not just the last four bytes, it's the whole MAC address, but 0xFFFE is crammed in the middle of the MAC address, and the first byte's second to last bit is flipped. We can see that this is exacly the scheme that was used. Now the confusing part is that the IPv4 address is apparently also the MAC address: MAC 42:01:0a: 80:00:02 IPv6 fe80::40 01:0a ff:fe 80:00 02 ^ ^^ ^^ flipped bit inserted IPv4(hex) 0a. 80. 0. 2 (dec) 10. 128. 0. 2 Now the confusing part is that the IPv4 address is apparently also based on the MAC address, which means the IPv4, and MAC addresses can both be derived from the IPv6 address, and the IPv4 address can be derived from the MAC address. (The entire host section of the IPv6 address is based on the MAC iirc, so the network section is the only part you need to guess there.)