6 ms·

Port Squatting

54 points by sciurus 12y ago

exabrial 12y ago
Port numbers as the next ipv4 "problem", oooh I like it. No amount of garbage collection for careful allocation will solve it. Expect another heavy-handed, non-memorizable, rear-ward-looking solution from the IETF that involves reimplementing the whole Internet. Oh, SRV records, right that's what I was going to post about. Yes, once again, SRV records would have solved this problem in quite an elegant and simple way. And it's backwards compatible until we hit an actual port number crisis... cool!
- jsprogrammer 12y ago
  The article claims 90% of the space is still available.
  - wongarsu 12y ago
    Because nobody actually registers their ports. It's a multi-month process with little benefit to anyone.
    - vacri 12y ago
      And even then, it doesn't matter because it's still simply convention. The internet won't break for anyone if I serve something other than mysql on port 3306. There's only a few port numbers where the public edifice around them is so huge that they really can't be that mobile - web (two ports), mail (six or so), dns (one port) and so forth.
  - bmn_ 12y ago
    Not quiet. The last 25%, i.e. ports 49152-65535, are by design excluded from registration. See RFC 6335 §6.
- wongarsu 12y ago
  Most software doesn't really need fixed port numbers. A few older systems like the DNS system are in practice limited to a fixed port, but most newer systems are port-agnostic. My postgres server is conflicting with some other service using port 5432? Who cares, I will just start it on some other random port. All that changes is that I have to type 5 more characters when connecting to it. SRV records are quite nice for user facing addresses because it's less stuff to remember, but for the majority of protocols it's not needed. Until people start to offer tens of thousands of services per IP, we won't hit any port shortage. And in the hypothetical future where that happens we hopefully moved to IPv6 and can just use another IP address.
  - inopinatus 12y ago
    Two points; firstly, SRV records offer other advantages over A records beyond simply port diversity. Most notably: the ability to exist at the apex of a domain, resolving to both IPv4 and IPv6 addresses simultaneously, and weighted-round-robin and fallback support. The overload of the address record to discover service endpoints is ultimately a murky throwback to when servers were named like pets, not disposable commodities. Secondly, in this age of containerized deployment it is already common to have many HTTP-substrate services bound to a single address, disambiguated by port. Leveraging the SRV record in DNS means not having to invent yet another endpoint discovery mechanism just to know what port number to connect to. The reference to "typing an extra 5 characters" invokes a world of manual, static configuration that many of us are happy to have replaced with services that find each other through discovery protocols.
ams6110 12y ago
Unlike IP addresses, port numbers are only conventions, they are not technically required to be unique. If I want to run an ssh server on port 80 (HTTP) then I can, and it will work just fine, and it won't bother anyone else.
- wise_young_man 12y ago
  In addition, you might want to run a process on a non standard port for security through obscurity such as not running SSH on port 22.
  - notfoss 12y ago
    Yes, because if nothing else, it almost eliminates failed login log messages (talking specifically about ssh here).
    - tracker1 12y ago
      true enough... the fail2ban messages are bad enough without running SSH on port 22... on the flip side, it sucks in other ways if you want to use SSH for something that isn't complete host access (terminal based BBS for instance).
- GauntletWizard 12y ago
  I used to run a SSH server on port 443. Why? Most firewalls in stupid places like schools are configured to permit traffic on 443, and not to inspect it. SSH is your gateway to everything else; Most SSH clients implement a SOCKS server to allow tunneling by your web browser.
kragen 12y ago
SRV records, used in DNS-SD and notably in Zeroconf, provide you the port numbers dynamically. Assigning port numbers to internet services globally across the entire internet was a mistake, and one that we can avoid for newly defined services. It creates two problems: 1. The one mentioned in this article: the namespace is finite and small, leading to conflicts over the administration of its allocation; 2. virtual hosting — you can only have one instance of a service per IP address, unless you kludge into the higher-layer protocol (every higher-layer protocol) some way of telling the server which instance of the service you were trying to connect to. And even then, all your “virtual hosts” have to be running on the same software — you can’t run some of them on Courier IMAP and others on Dovecot, say. By contrast, if you just bind them to different ports and publish those port numbers in DNS SRV records, these problems go away. TCPMUX on port 1 was the first attempt to solve this problem, but it didn't catch on. DNS-SD/Zeroconf/Bonjour/Rendezvous/SRV records seem like a viable and highly usable alternative, as long as we don’t get lost in the alphabet soup.
- JoshTriplett 12y ago
  I agree entirely. You'd still have a string namespace, but that string namespace is more easily subdivided. One key downside, though: for a conversation with any service not in your cache, you need to resolve the service before connecting, rather than knowing in advance. So there's still an advantage to any service that can use a well-known port. That advantage partly goes away if you can resolve a hostname in the same DNS request as a service on that host, but that would require improving the current level of integration between clients and system resolvers.
  - kragen 12y ago
    Really? I didn’t realize there was a client-side problem there. I guess there’s still a security problem, though, if the SRV record points to a hostname that nameserver may not be authoritative for. Edited to be more specific: I mean, if you want to cut the time to resolve a service name to an IP:port pair from two round-trip times down to one, then you need to get the A or AAAA record from the same nameserver as the SRV record. Getting the nameserver to include that record in the “additional” section, like a glue record for NS delegations, isn’t hard; but if it’s in another gTLD, how does the client know that nameserver is authoritative for that domain? It could be sending you a false A record. You wouldn’t want to cache that; it could enable a MITM attack! Better check with the gTLD servers. But that means another round-trip-time delay.
jacquesm 12y ago
One absolutely excellent reason for not tying services to port numbers is that it instantly undoes a large amount of strangling currently done to the peer-to-peer nature of the net. If you could run a web server with a url sans :port/ combo on any port that you wanted to then ISPs would have no easy way of blocking access to your self-hosted service without doing deep packet inspection. It's totally ridiculous that with 100 Mbps 'down' and 20 Mbps 'up' you still need a hosting account for a small web server.
- viraptor 12y ago
  On the other hand, for home users mapping services to ports statically makes it easier to apply QoS at the router. But when ports are randomised, or shared, it's hard to do anything about it. For example on a rather high-end netgear home router I can apply QoS by port, but that means Crashplan, Web and Skype use the same port. Even though I'd like them to be low, medium and high priority respectively.

54 points by sciurus 12y ago

Port numbers as the next ipv4 "problem", oooh I like it. No amount of garbage collection for careful allocation will solve it. Expect another heavy-handed, non-memorizable, rear-ward-looking solution from the IETF that involves reimplementing the whole Internet. Oh, SRV records, right that's what I was going to post about. Yes, once again, SRV records would have solved this problem in quite an elegant and simple way. And it's backwards compatible until we hit an actual port number crisis... cool!

jsprogrammer 12y ago
The article claims 90% of the space is still available.
- wongarsu 12y ago
  Because nobody actually registers their ports. It's a multi-month process with little benefit to anyone.
  - vacri 12y ago
    And even then, it doesn't matter because it's still simply convention. The internet won't break for anyone if I serve something other than mysql on port 3306. There's only a few port numbers where the public edifice around them is so huge that they really can't be that mobile - web (two ports), mail (six or so), dns (one port) and so forth.
- bmn_ 12y ago
  Not quiet. The last 25%, i.e. ports 49152-65535, are by design excluded from registration. See RFC 6335 §6.
wongarsu 12y ago
Most software doesn't really need fixed port numbers. A few older systems like the DNS system are in practice limited to a fixed port, but most newer systems are port-agnostic. My postgres server is conflicting with some other service using port 5432? Who cares, I will just start it on some other random port. All that changes is that I have to type 5 more characters when connecting to it. SRV records are quite nice for user facing addresses because it's less stuff to remember, but for the majority of protocols it's not needed. Until people start to offer tens of thousands of services per IP, we won't hit any port shortage. And in the hypothetical future where that happens we hopefully moved to IPv6 and can just use another IP address.
- inopinatus 12y ago
  Two points; firstly, SRV records offer other advantages over A records beyond simply port diversity. Most notably: the ability to exist at the apex of a domain, resolving to both IPv4 and IPv6 addresses simultaneously, and weighted-round-robin and fallback support. The overload of the address record to discover service endpoints is ultimately a murky throwback to when servers were named like pets, not disposable commodities. Secondly, in this age of containerized deployment it is already common to have many HTTP-substrate services bound to a single address, disambiguated by port. Leveraging the SRV record in DNS means not having to invent yet another endpoint discovery mechanism just to know what port number to connect to. The reference to "typing an extra 5 characters" invokes a world of manual, static configuration that many of us are happy to have replaced with services that find each other through discovery protocols.

ams6110 12y ago

Unlike IP addresses, port numbers are only conventions, they are not technically required to be unique. If I want to run an ssh server on port 80 (HTTP) then I can, and it will work just fine, and it won't bother anyone else.

wise_young_man 12y ago
In addition, you might want to run a process on a non standard port for security through obscurity such as not running SSH on port 22.
- notfoss 12y ago
  Yes, because if nothing else, it almost eliminates failed login log messages (talking specifically about ssh here).
  - tracker1 12y ago
    true enough... the fail2ban messages are bad enough without running SSH on port 22... on the flip side, it sucks in other ways if you want to use SSH for something that isn't complete host access (terminal based BBS for instance).
GauntletWizard 12y ago
I used to run a SSH server on port 443. Why? Most firewalls in stupid places like schools are configured to permit traffic on 443, and not to inspect it. SSH is your gateway to everything else; Most SSH clients implement a SOCKS server to allow tunneling by your web browser.

kragen 12y ago

SRV records, used in DNS-SD and notably in Zeroconf, provide you the port numbers dynamically. Assigning port numbers to internet services globally across the entire internet was a mistake, and one that we can avoid for newly defined services. It creates two problems: 1. The one mentioned in this article: the namespace is finite and small, leading to conflicts over the administration of its allocation; 2. virtual hosting — you can only have one instance of a service per IP address, unless you kludge into the higher-layer protocol (every higher-layer protocol) some way of telling the server which instance of the service you were trying to connect to. And even then, all your “virtual hosts” have to be running on the same software — you can’t run some of them on Courier IMAP and others on Dovecot, say. By contrast, if you just bind them to different ports and publish those port numbers in DNS SRV records, these problems go away. TCPMUX on port 1 was the first attempt to solve this problem, but it didn't catch on. DNS-SD/Zeroconf/Bonjour/Rendezvous/SRV records seem like a viable and highly usable alternative, as long as we don’t get lost in the alphabet soup.

JoshTriplett 12y ago
I agree entirely. You'd still have a string namespace, but that string namespace is more easily subdivided. One key downside, though: for a conversation with any service not in your cache, you need to resolve the service before connecting, rather than knowing in advance. So there's still an advantage to any service that can use a well-known port. That advantage partly goes away if you can resolve a hostname in the same DNS request as a service on that host, but that would require improving the current level of integration between clients and system resolvers.
- kragen 12y ago
  Really? I didn’t realize there was a client-side problem there. I guess there’s still a security problem, though, if the SRV record points to a hostname that nameserver may not be authoritative for. Edited to be more specific: I mean, if you want to cut the time to resolve a service name to an IP:port pair from two round-trip times down to one, then you need to get the A or AAAA record from the same nameserver as the SRV record. Getting the nameserver to include that record in the “additional” section, like a glue record for NS delegations, isn’t hard; but if it’s in another gTLD, how does the client know that nameserver is authoritative for that domain? It could be sending you a false A record. You wouldn’t want to cache that; it could enable a MITM attack! Better check with the gTLD servers. But that means another round-trip-time delay.

jacquesm 12y ago

One absolutely excellent reason for not tying services to port numbers is that it instantly undoes a large amount of strangling currently done to the peer-to-peer nature of the net. If you could run a web server with a url sans :port/ combo on any port that you wanted to then ISPs would have no easy way of blocking access to your self-hosted service without doing deep packet inspection. It's totally ridiculous that with 100 Mbps 'down' and 20 Mbps 'up' you still need a hosting account for a small web server.

viraptor 12y ago
On the other hand, for home users mapping services to ports statically makes it easier to apply QoS at the router. But when ports are randomised, or shared, it's hard to do anything about it. For example on a rather high-end netgear home router I can apply QoS by port, but that means Crashplan, Web and Skype use the same port. Even though I'd like them to be low, medium and high priority respectively.