3 ms·

This is well worth reading. It describes how, through a series of well meaning steps, you shoot yourself in the face. It all starts with: "Note that the last

This is well worth reading. It describes how, through a series of well meaning steps, you shoot yourself in the face. It all starts with: "Note that the last 4 bytes (0a:80:00:02) of the MAC address (42:01:0a:80:00:02) are actually the same as the internal IP address of the box (10.128.0.2). This means, 1 of the 3 components is effectively public."

markus_zhang 5y ago
As someone who knows nothing about networking, can you plz explain why they set up the config as this? Does that mean the third byte from top must be 0a? BTW I just checked my corporate intranet setup and MAC has nothing to do with the ip address.
- champtar 5y ago
  In most (all?) public cloud you don't have real layer2, having the MAC computed from the IP allow to make a stateless ARP responder I guess
  - markus_zhang 5y ago
    Thanks! I don't understand the technical details but (combining multiple responds) I think I understand a bit now. I also remember that back when I was in the university we used sort of university intranet (every personal computer connected has to go through it to the Internet, but it's free anyway) and there was a lot of ARP attack then, and I learned to use arp -a and arp -v (maybe wrong).
- gerdesj 5y ago
  Quite. MAC addresses don't need to line up with IP addresses or vice versa. They are completely different things. However in IPv6 there is a standard for link local addresses that does have a correlation between IP and MAC but there you go. It's designed to avoid clashes and is not the finest design decision ever made! That last will probably creep into a CVE one day just like this chain of events. The config as designed probably looked like a good idea at the time. When you are worrying about millions of things in an address space like IPv4 and MAC, then having them tie up in some way may be useful for lookups in a very large database or two. However, giving information away about something that was never designed from the outset to do so is not a good idea. If you follow the chain of reasoning in the github post you can see that you can break the chain at multiple points by not "being clever". If you start by not making your IP addresses follow the MAC address you kill this problem off before it starts.
  - gerdesj 5y ago
    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.

markus_zhang 5y ago

As someone who knows nothing about networking, can you plz explain why they set up the config as this? Does that mean the third byte from top must be 0a? BTW I just checked my corporate intranet setup and MAC has nothing to do with the ip address.

champtar 5y ago
In most (all?) public cloud you don't have real layer2, having the MAC computed from the IP allow to make a stateless ARP responder I guess
- markus_zhang 5y ago
  Thanks! I don't understand the technical details but (combining multiple responds) I think I understand a bit now. I also remember that back when I was in the university we used sort of university intranet (every personal computer connected has to go through it to the Internet, but it's free anyway) and there was a lot of ARP attack then, and I learned to use arp -a and arp -v (maybe wrong).
gerdesj 5y ago
Quite. MAC addresses don't need to line up with IP addresses or vice versa. They are completely different things. However in IPv6 there is a standard for link local addresses that does have a correlation between IP and MAC but there you go. It's designed to avoid clashes and is not the finest design decision ever made! That last will probably creep into a CVE one day just like this chain of events. The config as designed probably looked like a good idea at the time. When you are worrying about millions of things in an address space like IPv4 and MAC, then having them tie up in some way may be useful for lookups in a very large database or two. However, giving information away about something that was never designed from the outset to do so is not a good idea. If you follow the chain of reasoning in the github post you can see that you can break the chain at multiple points by not "being clever". If you start by not making your IP addresses follow the MAC address you kill this problem off before it starts.
- gerdesj 5y ago
  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.