

TCP Stealth - adulau
http://datatracker.ietf.org/doc/draft-kirsch-ietf-tcp-stealth/

======
bcoates
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
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
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.

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

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

------
orf
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
More info on HACIENDA, the Five Eyes program to port scan entire countries:
[http://www.heise.de/ct/artikel/NSA-GCHQ-The-HACIENDA-
Program...](http://www.heise.de/ct/artikel/NSA-GCHQ-The-HACIENDA-Program-for-
Internet-Colonization-2292681.html)

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

------
based2
[http://www.reddit.com/r/programming/comments/2dmqc0/tcp_stea...](http://www.reddit.com/r/programming/comments/2dmqc0/tcp_stealth_handshakes_to_hide_from_port_scans/)

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

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

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

~~~
shawnz
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.

------
peterwwillis
"Security through obscurity"

~~~
BugsBunnySan
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
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.

