3 ms·

Helpful! That would sure narrow down the number of possible vulnerabilities that had to be tried and would help a script kiddie breeze through the probing much

Helpful! That would sure narrow down the number of possible vulnerabilities that had to be tried and would help a script kiddie breeze through the probing much faster.

derefr 8y ago
I’m thinking in IPv6 terms here, where each separate “service” is exposed on a separate IP, and the only time you get multiple ports open on a single IP is when it’s one daemon that is holding multiple ports open in order to allow clients to speak one of several protocols to it (i.e. using TCP/UDP ports for their original purpose of layer-4 negotiation of the layer-{5,6} protocol stack you’ll be speaking the same layer-7 protocol over.) In such cases, you can probably recognize the server just from the set of ports that are open (e.g. a Slack server instance: HTTPS, XMPP, IRC.) So the server pointing out that you’re speaking to the wrong one of its ports with your message, in the way a client can understand, won’t really impact your attack surface. Of course, if the world really did adopt “the IPv6 port usage paradigm”, and did away with NATs and other things that map ports to other ports, there’d be little need for this: a destination port would be a 1:1 identifier for a protocol, and you could know you were speaking “the wrong protocol” to a port simply by looking at what port it is! Network client libraries could get away with simply not letting you specify both the port and the protocol, instead only leaving one configurable and deriving the other one from it. But we’re a long way off from that, and I would think that for now, being able to “permanent fail” HTTP clients off of infinitely retrying some internal service port exposed on your k8s-mesh load balancer, would be useful.
- sirsuki 8y ago
  > I’m thinking in IPv6 terms here You do realize that the utopian future you dream of will never happen! There is too much money to be had hording and selling IPv4 addresses.

Helpful! That would sure narrow down the number of possible vulnerabilities that had to be tried and would help a script kiddie breeze through the probing much faster.

derefr 8y ago

I’m thinking in IPv6 terms here, where each separate “service” is exposed on a separate IP, and the only time you get multiple ports open on a single IP is when it’s one daemon that is holding multiple ports open in order to allow clients to speak one of several protocols to it (i.e. using TCP/UDP ports for their original purpose of layer-4 negotiation of the layer-{5,6} protocol stack you’ll be speaking the same layer-7 protocol over.) In such cases, you can probably recognize the server just from the set of ports that are open (e.g. a Slack server instance: HTTPS, XMPP, IRC.) So the server pointing out that you’re speaking to the wrong one of its ports with your message, in the way a client can understand, won’t really impact your attack surface. Of course, if the world really did adopt “the IPv6 port usage paradigm”, and did away with NATs and other things that map ports to other ports, there’d be little need for this: a destination port would be a 1:1 identifier for a protocol, and you could know you were speaking “the wrong protocol” to a port simply by looking at what port it is! Network client libraries could get away with simply not letting you specify both the port and the protocol, instead only leaving one configurable and deriving the other one from it. But we’re a long way off from that, and I would think that for now, being able to “permanent fail” HTTP clients off of infinitely retrying some internal service port exposed on your k8s-mesh load balancer, would be useful.

sirsuki 8y ago
> I’m thinking in IPv6 terms here You do realize that the utopian future you dream of will never happen! There is too much money to be had hording and selling IPv4 addresses.