Port Squatting | Hacker News Reader

Port Squatting

queue.acm.org

54 pointssciurus23 comments

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.

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.

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.

> Really? I didn’t realize there was a client-side problem there.

You'd need some new API for resolving a given host:service combination in a single request, which to the best of my knowledge does not exist today. With current APIs, you'd make one request to resolve the name and a separate request to resolve the service.

> I guess there’s still a security problem, though, if the SRV record points to a hostname that nameserver may not be authoritative for.

That seems like the same kind of issue that can occur today if you make a hostname you control point to an IP you don't. Both seem like similar problems with similar solutions.

Hostport combinations are in use in many tools. Hadoop represents all it's servers as a hostport.

The proper name is "netloc".

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.

If the nameserver you're connecting to is doing things like that, this is a problem for all your traffic, not just traffic that relies on SRV records.

This is not necessarily the nameserver local to you; this may be the nameserver that’s authoritative for the SRV record you’re trying to look up. Maybe you’re trying to talk to a machine in North Korea.

Is there any reason browsers couldn’t start supporting this for websites? Seems like it would be significantly simpler than today's Host header-based proxying.

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.

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.

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!

The article claims 90% of the space is still available.

Because nobody actually registers their ports. It's a multi-month process with little benefit to anyone.

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.

Not quiet. The last 25%, i.e. ports 49152-65535, are by design excluded from registration. See RFC 6335 §6.

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.

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.

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.

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.

Yes, because if nothing else, it almost eliminates failed login log messages (talking specifically about ssh here).

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).

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.

Reply on news.ycombinator.com