6 ms·

TCP Stealth

65 points by adulau 12y ago

jws 12y ago
Lots of HN criticism on the draft. Hopefully the authors find it for the next iteration. 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 … this means no changes to your servers, of which you may not have control, and you can apply it to forwarded connections for machines hiding behind your firewall. 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.
dimman 12y ago
Neat. Although it's getting more and more complicated when things have different meanings depending on state.
ckozlowski 12y ago
If I'm reading this correctly, this requires a shared secret on /every/ system that will be establishing a TCP connection with a peer. 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.
- dtech 12y ago
  Yes, after you've got the shared key from whatever source you can port scan. 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.
  - mnw21cam 12y ago
    For most use cases, if you want to hide your connectivity behind a reasonable cryptographic layer, a better (and stronger) option is to firewall everything except incoming ssh, and then do ssh port forwarding. 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.
    - calgoo 12y ago
      I was thinking that this could be used similar to a session key in an application. So if you made a web server, you could allow all traffic to say: /login that then recieves the key after authentication. This could then be used to reach the secure area of your application, and anyone without the secure key cant even detect that part of the app.
cpach 12y ago
Cool to see Microsoft working together with the Tor project. I'm a bit surprised.
peterwwillis 12y ago
"Security through obscurity"
- BugsBunnySan 12y ago
  Repeating magic phrases doesn't accomplishes much without understanding. 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.
  - peterwwillis 12y ago
    The phrase "security through obscurity" actually means more than just the idea that relying on obscurity is a bad idea (which it is). It also points out the problem inherent to security models that aren't holistic. Often these kinds of half-measures give a false sense of security, which can be worse than no security at all. Consider that "security" is not a magical number that you compute from adding up all the various countermeasures you place in front of your endpoint. 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.
orf 12y ago
Neat idea, verging on "security through obscurity", but that's not necessarily a bad thing when you just wish to obscure services from view. As long as people don't rely on it for authentication (which will undoubtedly happen).
sp332 12y ago
More info on HACIENDA, the Five Eyes program to port scan entire countries: http://www.heise.de/ct/artikel/NSA-GCHQ-The-HACIENDA-Program-for-Internet-Colonization-2292681.html http://www.heise.de/ct/artikel/NSA-GCHQ-The-HACIENDA-Program...
zokier 12y ago
Wouldn't you get most of the benefits by just running IPsec and dropping all non-IPsec traffic? Authentication would prevent port-scanning and optionally encryption would prevent detecting services by observing the traffic.
bcoates 12y ago
Please don't use or implement this "work in progress", it is terrible. 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. They think reducing the visible footprint results in a reduction of the attack surface, that is, they think concealment is cover. 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. This is a quote from a proposal that does not work at all to conceal traffic from passive listeners, let alone man-in-the middle attackers. You still know exactly what services are running if you can listen in, you don't need to port scan! Furthermore, if you can see selective response to a sufficient (smallish) number of these ISN tokens, you can start trying to guess the secret. No advice on appropriate shared secret selection or necessary secret length to mitigate this is given -- they claim the secret is 1024 bits, but give a test vector much shorter than that. PS: I'm pretty sure this breaks if you use DNAT
amluto 12y ago
The draft uses the MD5 compression function (not even real MD5), and it "hashes" more data and than fits in one invocation by arbitrarily xoring pieces together. 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.
- jws 12y ago
  Be sure to pick a fast enough hash function to keep up with a DoS attack when I flood you with connections attempts. 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.
based2 12y ago
http://www.reddit.com/r/programming/comments/2dmqc0/tcp_stealth_handshakes_to_hide_from_port_scans/ http://www.reddit.com/r/programming/comments/2dmqc0/tcp_stea...
mooism2 12y ago
What's the advantage of this over hiding your service behind spiped?
- shawnz 12y ago
  Spiped solves a different problem than this does. Spiped will allow you to obscure the existence of a certain service, as well as prevent unauthorized access to that service. But it will not allow you to hide an entire host. Tunnelling a service over spiped will simply mean that spiped appears in your portscan instead of that service. 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.

65 points by adulau 12y ago

jws 12y ago

Lots of HN criticism on the draft. Hopefully the authors find it for the next iteration. 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 … this means no changes to your servers, of which you may not have control, and you can apply it to forwarded connections for machines hiding behind your firewall. 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.

dimman 12y ago

Neat. Although it's getting more and more complicated when things have different meanings depending on state.

ckozlowski 12y ago

If I'm reading this correctly, this requires a shared secret on /every/ system that will be establishing a TCP connection with a peer. 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.

dtech 12y ago
Yes, after you've got the shared key from whatever source you can port scan. 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.
- mnw21cam 12y ago
  For most use cases, if you want to hide your connectivity behind a reasonable cryptographic layer, a better (and stronger) option is to firewall everything except incoming ssh, and then do ssh port forwarding. 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.
  - calgoo 12y ago
    I was thinking that this could be used similar to a session key in an application. So if you made a web server, you could allow all traffic to say: /login that then recieves the key after authentication. This could then be used to reach the secure area of your application, and anyone without the secure key cant even detect that part of the app.

cpach 12y ago

Cool to see Microsoft working together with the Tor project. I'm a bit surprised.

peterwwillis 12y ago

"Security through obscurity"

BugsBunnySan 12y ago
Repeating magic phrases doesn't accomplishes much without understanding. 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.
- peterwwillis 12y ago
  The phrase "security through obscurity" actually means more than just the idea that relying on obscurity is a bad idea (which it is). It also points out the problem inherent to security models that aren't holistic. Often these kinds of half-measures give a false sense of security, which can be worse than no security at all. Consider that "security" is not a magical number that you compute from adding up all the various countermeasures you place in front of your endpoint. 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.

orf 12y ago

Neat idea, verging on "security through obscurity", but that's not necessarily a bad thing when you just wish to obscure services from view. As long as people don't rely on it for authentication (which will undoubtedly happen).

sp332 12y ago

More info on HACIENDA, the Five Eyes program to port scan entire countries: http://www.heise.de/ct/artikel/NSA-GCHQ-The-HACIENDA-Program-for-Internet-Colonization-2292681.html http://www.heise.de/ct/artikel/NSA-GCHQ-The-HACIENDA-Program...

zokier 12y ago

Wouldn't you get most of the benefits by just running IPsec and dropping all non-IPsec traffic? Authentication would prevent port-scanning and optionally encryption would prevent detecting services by observing the traffic.

bcoates 12y ago

Please don't use or implement this "work in progress", it is terrible. 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. They think reducing the visible footprint results in a reduction of the attack surface, that is, they think concealment is cover. 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. This is a quote from a proposal that does not work at all to conceal traffic from passive listeners, let alone man-in-the middle attackers. You still know exactly what services are running if you can listen in, you don't need to port scan! Furthermore, if you can see selective response to a sufficient (smallish) number of these ISN tokens, you can start trying to guess the secret. No advice on appropriate shared secret selection or necessary secret length to mitigate this is given -- they claim the secret is 1024 bits, but give a test vector much shorter than that. PS: I'm pretty sure this breaks if you use DNAT

amluto 12y ago

The draft uses the MD5 compression function (not even real MD5), and it "hashes" more data and than fits in one invocation by arbitrarily xoring pieces together. 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.

jws 12y ago
Be sure to pick a fast enough hash function to keep up with a DoS attack when I flood you with connections attempts. 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.

based2 12y ago

http://www.reddit.com/r/programming/comments/2dmqc0/tcp_stealth_handshakes_to_hide_from_port_scans/ http://www.reddit.com/r/programming/comments/2dmqc0/tcp_stea...

mooism2 12y ago

What's the advantage of this over hiding your service behind spiped?

shawnz 12y ago
Spiped solves a different problem than this does. Spiped will allow you to obscure the existence of a certain service, as well as prevent unauthorized access to that service. But it will not allow you to hide an entire host. Tunnelling a service over spiped will simply mean that spiped appears in your portscan instead of that service. 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.