TCP Stealth
datatracker.ietf.org
datatracker.ietf.org
For starters, the fundamental idea is backwards. People don't evade port enumeration to hide from attackers, they evade it to hide from auditors. Thinking that makes you safer is equivalent to assuming the world goes away when you close your eyes. The defenders need to find every hole, the attackers need to find one. If you want a secure (and functional!) network, you want to make network service discovery easier, not harder.
They even admit it themselves:
Thus, it is increasingly important to minimize the visible footprint
of services on Internet hosts, thereby reducing the attack surface.
Secondly, the non-technical portions are extremely misleading, for example:
[A]dversaries may be able to observe all traffic of an Internet host
and perform man-in-the-middle attacks on traffic originating from
specific clients.
PS: I'm pretty sure this breaks if you use DNAT
This wrong for so many reasons. Here's how to do this sanely:
Pack all the input into a fixed size. Hash it with a decent hash function. Truncate the output.
MD5 is not a decent hash function.
The weak hash function may not be significant. If I snoop a connection I get all the information to reconstruct the IV and I get the XOR crush of the MD5 result. If I try to brute force this I can find a shared secret that will make a collision on the 32 bit number in about 2^32 trials, but that won't help me when I try to make my own connection with a different IV. There are probably something like 2^96 secrets that will make the collision so the odds me me guessing the right one are hopeless.
If there is an analytic reversal of the hash function that yields some constraints on the secret, and I collect enough SYN packets to eliminate all but one secret, then I can connect to your port.
Given that large key distribution and management undertaking, it seems that if one were going to go through with the trouble, there are better mutual protection mechanisms available, and with much larger key sizes than 32bits.
This really gets to be challenging where the public internet is involved, and to be frank, I'm not sure how you'd handle that for public services. Let's say you distributed the shared key with your application. Could I then launch a port scan now that I've obtained the key?
I hate to say it, but I wonder if I'm just not getting this, or this is a bit tongue-in-cheek like the "evil bit" of days past.
However, getting that shared key is not do-able if you really keep it secret (e.g. as an additional security measure for SSH) or really hard to do automatically (e.g. crawling the web or app store)
It's far from perfect, but it probably is the best you can do without breaking TCP (the new "stealth" SYN's are still valid SYN's under current TCP)
However for most use-cases, I don't know if it is a better solution than using a non-standard port.
I can see people using this, but it should not be relied upon as a security measure - rather it is a mechanism for reducing log file clutter for the multitudes of random probes that an internet-connected machine receives.
Sure, the servers in question would have to be internet connected for this to be useful. But that doesn't mean they are open-access. If they were, of course it wouldn't make sense to use this.
But consider, for example, that you are setting up a server at your organization to provide employees with remote access. Nobody but your employees need to have access, but it still must be internet visible.
Wouldn't that be a good use case for this?
This isn't an alternative to VPNs. In fact, as far as I'm concerned, this proposal is only useful when combined with a VPN!
Look at solutions like Unisys Stealth. Mostly used in government today, this sort of technology allows for organizations with lots of multi-tenant compliance issues to take weeks off the process of building IT systems.
For a company like Microsoft (one of the co-authors was from there), they have strategic service offerings where solving this problem is a huge benefit (ie. Azure) and have infrastructures that addresses things like key distribution (Active Directory).
Given that I have two systems, on a network in which I know an adversary wishes to deduce the ports I am advertising (as illustrated by the paper's concern over a MitM attack), how do I distribute my shared secret in such a way that my adversary does not deduce it, and does not require a secure channel that would invalidate the need for this mechanism in the first place?
I'm no cryptography expert, but from the portions I do know, the challenge is in key distribution. I feel like that is completely missing from the paper, and without it, it limits this mechanism's feasibility enormously.
On the positive side, I would use something like this when I have one of:
• A service that is resource intensive to start and reject a connection. Reduce the impact of brute forcers.
• A service I do not trust. Sometimes politics or expediency will place a service on a public port which may or may not have catastrophic security flaws of which you are not aware but the vendor is committed to addressing in "6 months".
• Brute force attacking results in noisy logs or some other annoyance and there isn't an easy option to address it.
If I have one of those cases AND the service is only accessed from a limited number of remote hosts I would adjust the firewall to only allow the proper hosts to connect.
TCP Stealth would let me move that authentication from the firewall administrator to a set of trusted people to whom I give the shared secret. This lets those people address the case where the client's IP changes or they need to come in from a different machine.
Think of it as a portable hole through the firewall.
For the server, I think it might best be implemented as a rule in the firewall, say on Linux…
iptables -A INPUT -p tcp --dport 7 -m stealth --stealth-secret fi9…6g -j ACCEPT
You could also have a socket option the server sets and handle it in the TCP stack.
Client side implementation is murkier to me. There could be a socket option the client sets, but then you need to remake all the clients, and some of them will be your web browser. You could do something at the TCP stack level to map certain hosts and ports to secrets. That seems strange too. I'm not sure a firewall rule works for the client, it would have to communicate a sequence number back to the TCP stack or forever be translating them.
This proposal, on the other hand, will allow you to prevent a service from being visible altogether to those without the key. Combined with spiped or a similar tunnelling scheme, this would allow you to have no visible ports on your portscan. Thus, those without the key would not even know that the host exists.
If you make something really secure and then you hide it really well, that's better than just making it really secure.
Just don't replace making it really secure by hiding it, is what that phrase says.
It's like moving an sshd away from port 22; doesn't make your sshd implementation magically more secure, but it immediatly gets rid of a mass of autmated naive ssh port scans. So you need a solid implementation still, but the obscuring part certainly helps.
Security is more like a hydra. Each head needs to stand on its own and provide real difficulty against attacks, otherwise they'll just be lopped off one by one until the beast is dead. With regard to obscurity, it's like as if one of the heads of the hydra was shriveled and weak. It doesn't even put up a fight. It'll be tossed aside by any attacker that puts any effort in, so it's really not even worth doing. Those naive ssh port scans you mention are the equivalent of kids kicking dirt; nothing a hydra should be worried about.