10

While there is usually no need for more than the 64k available ports, I am interested in the PoC that having a port number on 64 bits would mitigate the regular attacks on the access ports (ssh, vpn...). Having a 64b port makes it almost impossible to randomly attack a service, targeting either DoS or a login. Like

 ssh -p 141592653589793238 my.site.com
  • Is it possible to configure Linux to use 64 bit ports? (of course both client and server should be configured)

and practically

  • Would that disturb the Internet equipment? ('transport' is OSI layer 4, above IP, thus the routing itself should not be impacted, but some devices go up to the upper layers for analysis / malware detection... ; a 64 bit ports Linux box would act as home router)
Improve this question
11
  • 39
    tcp/udp protocol doesnt support this
    – 炸鱼薯条德里克
    May 15, 2021 at 4:49
  • 19
    You will get much better security (for SSH specifically) by enforcing mandatory ssh key authentication rather than running ssh on an alternative port...
    – Josh
    May 15, 2021 at 15:07
  • 14
    The port number you selected is not secure at all, it is the first 18 decimal digits of π. :)
    – user000001
    May 15, 2021 at 17:48
  • 4
    Hmmm, why not expand the IP address width instead, and choose a random IP among 2^64 addresses (obviously, no DNS registration then, so forget your my.site.com)? But, wait... , hallelujah, this already exists!!!!
    – xhienne
    May 16, 2021 at 0:33
  • 3
    Since you're preparing for specific settings all over your group of systems and routers, there's a way cheaper method: use (a) tunnel(s) for all this traffic. For example WireGuard is designed as to never reply to unauthenticated packets, so will remain stealthy to scans: problem sidestepped.
    – A.B
    May 16, 2021 at 9:16

6 Answers 6

Reset to default
27

Is it possible to configure Linux to use 64 bit ports?

You cannot change a parameter to use 64bit ports in TCP/UDP.

You could create similar protocols, but you would only be able to communicate with your modified hosts and it would not be TCP / UDP, but a new set of protocols, let's say TCP64 / UDP64.

Here are just some of the things you'd have to add for these protocols to work, just to start, before even considering memory impact and a ton of other issues:

  • a definition of the the TCP64 (a modification of the current TCP segment)
  • a new family AF_INET capable of holding the extended ports, along with the kernel code to handle it (if you're thinking about copy/paste, note that you have to change, at the very least, a list the structure definitions, type definitions and calls to htons() or ntohs() for example
  • code to all userspace programs meant to use the new stacks, including those at the edges of the network, such as firewalls if you plan to filter the traffic.

Since it will be a different set of protocols, with their own IP numbers, they would not disturb the routing nodes, though they could be dropped by them along the route, because the IP protocol number would not be known.

As for mitigation: software like fail2ban and custom service ports (in the 16-bit range) are usual techniques, though not the only ones.

Improve this answer
6
  • Thanks. I know and use fail2ban. A great little software, well made and easily configurable. Was just a PoC and it seems there are a lot of things to rewrite. So, if the Internet drops some packets, it goes to analyze up to L4 (otherwise I could use an existing IP number).
    – Déjà vu
    May 15, 2021 at 5:42
  • 1
    I know it was a PoC. An interesing one!
    – Eduardo Trápani
    May 15, 2021 at 5:43
  • 4
    @Breakingnotsobad Your POC requires you to invent your own protocol and create your own world-wide network. Since your protocol wouldn't be Internet Protocol (IP) your network wouldn't really be the "internet". You could probably call it Breaking Not So Bad Protocol or BP so your network could be called Breakingnet. This is actually very doable on a LAN. I remember writing network protocols both for work and for fun. You'll have much tougher luck convincing ISPs and Telcos to use your protocol instead of IP
    – slebetman
    May 15, 2021 at 13:31
  • 6
    But it would still sit on top of IP, you could route it anywhere, where you have nodes that understand it. Google did that with QUIC (no need to ask), creating a transport one layer above UDP (that changes addressing for example). Granted, you probably don't own so many clients (Chrome) and servers ;). But you could still test something like that between your nodes: you try your protocol and if it doesn't work, the alternative, a happy eyeballs approach (also what Chrome does with QUIC).
    – Eduardo Trápani
    May 15, 2021 at 16:02
  • 10
    You would need to adjust some of the network infrastructure. Not just because some routers may drop unknown protocols, but for example because a client behind a NAT wouldn't work, and what client isn't behind a NAT these days? The NAT would have to not support TCP64 as well. @Breakingnotsobad
    – Gilles 'SO- stop being evil'
    May 15, 2021 at 18:27
16

Having a 64b port makes it almost impossible to randomly attack a service, targeting either DoS or a login. Like

ssh -p 141592653589793238 my.site.com

And how would the client know about 141592653589793238? If this is available from some kind of directory or query service, then the attacker will obtain the port number from that service and there is no benefit. If 141592653589793238 is a secret then this limits the usefulness of the protocol to scenarios where clients only connect to well-known servers from which they have previously received secret information. Very few services meet this description. SSH is one of a few that can fit, but even so, it's an additional hurdle.

Furthermore an attacker who can observe packets in transit can see the port number. So the secret wouldn't stay secret for very long.

As for the benefit, it's pretty much non-existent. It doesn't matter if an attacker can open a connection to a service, apart from some denial of service attacks. What matters is that the service doesn't have a vulnerability to exploit. Hiding one specific service (SSH) behind an additional secret that is a lot weaker than the security of a typical SSH server doesn't really gain you any security.

Is it possible to configure Linux to use 64 bit ports? (of course both client and server should be configured)

No. The number of bits in a port number is not a property of one system. It's a protocol (an aspect of TCP) that everyone agrees on. If different systems used different port number sizes, they wouldn't be able to talk to each other.

It would of course be possible to implement a protocol that is similar to TCP but has 64-bit port numbers. But it's not just a matter of changing a configuration item, it's a whole new piece of code, and a whole new protocol.

Would that disturb the Internet equipment?

Yes. Almost every TCP/IP client is behind a NAT. A NAT identifies connections through port numbers. The NAT would need to support the new protocol too.

Improve this answer
5
  • Not part of the question, but using ssh to connect to my server(s) is not for everyone! It's not http(s).... Would be a couple people, one or two, and the port number would stay, in this fantasy system, private. And no NAT involved either. A Linux box doing the "home router" role (as mentioned in the question). Public IPs only.
    – Déjà vu
    May 15, 2021 at 18:45
  • 3
    @Breakingnotsobad Depending on where you live, your ISP may be doing NAT too. You can already put SSH on a nonstandard port even with 16-bit port numbers. This does drastically remove the number of automated attempts at exploiting known vulnerabilities and default accounts. It doesn't help against targeted attacks against you, because 16 bits can be enumerated, but a targeted attacker would likely be able to find the 64-bit port number anyway, by managing to MitM or by exploiting a protocol weakness or by attacking some other part of the client or server.
    – Gilles 'SO- stop being evil'
    May 15, 2021 at 18:49
  • TbH, "my" servers have random ssh ports above 10k, and still, many attacks occur... It's from scripts running 24/7 from all over the world, they scan public IPs and try many ports, it's not really "targeted". A 64b port would likely stop most if not all of that. The ssh service itself is well protected (+fail2ban), but again, in this case, the probability to find such a port is much much less compared to the one of a weakness or a bug in ssh.
    – Déjà vu
    May 15, 2021 at 18:56
  • 3
    @Breakingnotsobad: Since 64-bit ports aren't a practical option, you can't stop everything. It may help to also have sshd listening on port 22 set up to only allow public-key auth. Some password brute-forcing attempts will get sucked into there, not noticing that's there's another sshd that allows password auth listening on a high port.
    – Peter Cordes
    May 16, 2021 at 18:15
  • @PeterCordes Thanks Peter, positiveness, as usual. The question could be more lengthy and present a concrete case of security, but is actually a mere PoC, since the 63b ports are only fantasy, currently. It was assuming that, behind the scene, all other components are secure, like the ssh configuration.
    – Déjà vu
    May 17, 2021 at 10:13
7

As others have mentioned, it is not possible as both TCP and UDP use 16 bits for port designation. So you'd have to have all the hosts on the internet change the TCP protocol to something else, which is highly unlikely to happen.

Luckily, we do have IPv6 deployed nowadays in many places, so instead of having attacker guess what is your port, you can have different services on a host listen on different IPv6 addresses, thus making the attacker having to guess IP address - accomplishing the same thing by having them search larger space. IPv6 address has 128 bits, and even one computer can always use at least 64bits for itself (or more if allowed), so is even harder by attacker to guess than your 64-bit port idea.

Of course, same as with you idea with hidden port, you must be careful not to make your hidden IPv6 address easily obtainable by attacker.

(Of course, both the source and destination computers must have IPv6 connectivity. If they do not, lobby your ISP to provide it natively, and use some IPv6 tunnel like tunnelbroker.net until they do)

Improve this answer
5
  • That's indeed a good point, but IPv6 doesn't route everywhere in the world, yet.
    – Déjà vu
    May 16, 2021 at 1:45
  • 8
    Although IPv6 penetration is much wider than TCP64 penetration.
    – user4556274
    May 16, 2021 at 13:02
  • 1
    @Breakingnotsobad yes, as I mentioned in last paragraph. All the more reason to lobby with your ISP to provide you with IPv6. In business setting, I flat out refuse to even consider ISP not offering working IPv6, as in 2021 they are clearly incompetent if they do not have it correctly implemented by now (and that includes working IPv6 peering - I'm looking at you, Cogent!). You can use a tunnel like tunnelbroker.net until your ISP implements IPv6 natively.
    – Matija Nalis
    May 17, 2021 at 13:30
  • @user4556274 Sure! Difference being that this "tcp/udp 64" would be proprietary used by a couple servers.
    – Déjà vu
    May 19, 2021 at 9:21
  • @Breakingnotsobad if you're willing to do proprietary setup on all involved servers/clients, then you can simply block ssh port from internet entirely, and use VPN solution of choice (wireguard / IPsec / OpenVPN / ...) to gain access to ssh port (and get extra data encryption / authentication for free)
    – Matija Nalis
    May 20, 2021 at 10:28
4

You cannot use 64-bit ports without changing the TCP/UDP protocols, and if you do that you will not be able to talk to the rest of the world.

But you can do something else: Use a Tor hidden service.

If you set up a Tor hidden service, you will get a hostname like:

p53lf57qovyuvwsc6xnrppyply3vtqm7l6pcobkm​yqsiofyeznfu5uqd.onion

And that is not easy to guess.

Another advantage is that you can only access this through Tor - not the normal internet; but the server can be behind NAT, no need to mess with port-forwarding etc.

The latency is higher (around 500 ms), but you can easily get 10 Mbit/s bandwidth, so it is fine for SSH and video streaming, but not usable for video conferencing.

Improve this answer
1
  • Nice addition. Using Tor, you look like some dark web hacker, but, hey, why not :)
    – Déjà vu
    May 17, 2021 at 16:13
2

I don't think modifying TCP stack is viable because even if you do it on the serverside, you'd have to patch the client as well and the soft running on it.

As a mitigation, I'd suggest using CrowdSec. It's a kind of modern fail2ban (so find behaviors in logs and blocks them), but IPV6 compliant, faster and decoupled. On top of that, you benefit from IPs blocklist of all other users protecting their SSH port that identified aggressive IPs targeting those.

Disclaimer: I'm part of the CrowdSec team.

Improve this answer
1
  • Cool :) Thanks for the tip, will have a look.
    – Déjà vu
    May 20, 2021 at 10:51
0

Thinking that a larger space of possible port numbers will improve security is essentially relying on security by obscurity. It will be much harder to keep the custom port number secret than, say, a password. For instance your router doesn't need to know your SSH password, but you need to tell it the port number if you're using port forwarding. A much better measure from the security point of view would be to disable password-based authentication and use certificates instead.

Having a larger space of possible port numbers will not prevent DoS attack either: there are attacks which don't need to know the port number, and if everyone would somehow switch to random port numbers, such attacks would become predominant.

Improve this answer
8
  • 2
    "Security by obscurity" is used at lot by many who like the easiness of the sentence... but it's not always relevant. When you have a RSA private key, it's obscurity. If someone could guess that PK, they're in. Of course the odds are different, but having a 2^63 ports isn't the only security point, it's just an added feature. Then you have the security linked to ssh. On the one side you have ssh, on the other you have ssh+2^63 ports.
    – Déjà vu
    May 17, 2021 at 10:04
  • 3
    @Breakingnotsobad you confuse "obscurity" with "secret". Both are unknown, but "Security by obscurity" refers to using something unknown but guessable, such as a version number of the webserver, while cryptographic secrets are not guessable under reasonable assumptions (such as wanting to guess it within the lifetime of the solar system)
    – Tom
    May 17, 2021 at 10:08
  • 3
    @Tom The two definitions are debated on other sites, so let's not start a vocabulary trick war. And 2^63 guessable? Provided that you have to do a network request per port? We're not far from the age of the solar system: "guessable" is also debatable here and comparing a version number to a random 2^63 does not make sense. The number would be closer to "secret" than "obscurity". And, again, behind the scene all the current ssh security is also at work... Combining the ssh security and 2^63 makes it quite strong. (at 1000 requests per second, it would take 300 million years to "guess" the port)
    – Déjà vu
    May 17, 2021 at 10:25
  • 1
    @Breakingnotsobad not easily guessable, no. But I object to calling a secret key "security by obscurity". That's not how we generally use that term. Heck, you would be closer to call a password "security by obscurity" and we don't even us it for that.
    – Tom
    May 17, 2021 at 17:31
  • 1
    @DmitryGrigoryev It's still not security by obscurity, as you reduce possible attackers from anyone on the internet to only those attackers beings in the path and able to accomplish passive MitM attack (sniff the traffic / logs). Which is kind of same thing as firewalls do (reduce number of possible attackers). So it's not a holy grail (nothing is!), but it's far from useless.
    – Matija Nalis
    May 20, 2021 at 10:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .