coderrr

June 28, 2008

Detecting SSH tunnels

Filed under: network, security, slashdotted — Tags: , , — coderrr @ 6:35 pm

Shameless Plug: Use a VPN Tunnel to secure and encrypt your P2P traffic.

Italian researchers have published a paper on the Detection of Encrypted Tunnels across Network Boundaries. I came across it in a google search because I’ve been thinking of writing a program which does something similar. It doesn’t seem like anyone else has picked up on this research yet so I thought I should mention it. Here is a link to the actual paper: pdf or scribd.

They claim their technique can differentiate between “normal” ssh or scp sessions and ssh sessions which are being used to tunnel traffic (through ssh’s port forwarding mechanism). This is accomplished through a naive Bayes classifier, which they first trained with “normal” ssh sessions. The two variables used to classify a session are the size of the packets and the difference in arrival time of two consecutive packets. With just these, they can classify with 99% accuracy whether an ssh session is a tunnel. They were also able to classify the actual protocol (P2P, POP, SMTP, HTTP) of the tunneled connection with close to 90% accuracy.

Although their research is quite interesting there are a few things which limit its practicality. They can only detect tunnels going through ssh servers which they control. This is because their detection mechanism can only handle a single authentication type whereas an ssh server can (and usually does) allow multiple (e.g. public-key or password). This requires admins of the server to limit the allowed authentication options to a single consistent choice. They also require the ssh server _and_ client to disable compression. Their technique will also falsely classify a second login attempt (after a failed login) as a tunnel and drop the connection. In their words: “However, this should not be a major problem: simply, if the user is entitled to connect, they will try again.”

So it seems the use of a tool like this would be limited to an extremely controlled environment where users are limited to a white-list set of network protocols (so that they can’t use a different tunneling mechanism, stunnel for example) and only allowed to ssh to servers under the control of the censoring party. In which case you would wonder why the admin wouldn’t just set the ssh servers’ AllowTcpForwarding option to false.

It sounds like this is just preliminary work so maybe their future research will solve all these problems. If perfected this technology could be used by ISPs to block or throttle even encrypted P2P traffic.

I’d also like to note that it would probably be easy to create a tunneling mechanism which thwarts their detection attempts. Knowing that they use packet size and inter packet intervals you could easily manipulate these to match whatever protocol type you wanted.
Update: This actually might not be that easy with P2P traffic since you’d need to mimic another protocol where there is a large amount of uploading going on at the same time as downloading. This is pretty hard to speculate on without actually trying it out. But if you could limit a bit torrent connection’s upload to 5% of the download and still get reasonable speed you might be able to mimic a tunneled HTTP connection.

While looking around one of the researchers web pages (Franceso Gringoli) I found a pretty cool Linux/OSX utility called sshgate. It allows you to transparently tunnel all your connections over ssh. This is great for programs which do not give you the option to use a socks server and which do not play nice with socksification. I haven’t tested it out so I’m not sure if it actually works.


Bookmark and Share

25 Comments »

  1. You can also use a:

    Local SOCKS Proxy for Safari

    http://codesnippets.joyent.com/posts/show/1326

    Comment by tendo — June 30, 2008 @ 10:07 am

  2. “You can also use …”. I assume you’re referring to my reference to sshgate. As I said, it’s great for programs which DO NOT give you the option to use a SOCKS proxy. Safari does give you the option as is shown in your example.

    Comment by coderrr — June 30, 2008 @ 10:24 am

  3. This really is in no way related to encrypted P2P traffic, mind. SSH is a structured protocol with a hidden payload, encrypted P2P wants to look unstructured with a hidden payload.

    Comment by Kriss — June 30, 2008 @ 1:41 pm

  4. Depends how you define encrypted P2P traffic. Tunneling P2P over SSH is one form of encrypted P2P traffic, which they could identify with 88.77% accuracy. Of course there an infinite number of ways to encrypt/tunnel any traffic, this research only relates to one.

    Comment by coderrr — June 30, 2008 @ 1:49 pm

  5. [...] Detecting SSH tunnels « coderrr – more detail here [...]

    Pingback by I saw this… » the billblog — June 30, 2008 @ 4:00 pm

  6. “Knowing that they use packet size and inter packet intervals you could easily manipulate these to match whatever protocol type you wanted.”

    But if you do that, aren’t you just self-throttling the P2P traffic? In which case, the ISPs’ objective will be accomplished, anyway.

    Comment by Mike — June 30, 2008 @ 4:52 pm

  7. @Mike: Depends how you do it. It’s likely that there would be some speed degradation. Obviously you’d want to compare that to what your ISP does. I have a feeling it could be done without coming close to the amount of throttling an ISP will impose on you.

    Comment by coderrr — June 30, 2008 @ 5:11 pm

  8. @coderr: The additional datapoint that the observer has is the packet destination. This problem is fairly well known in the anonymous IP/email research realm: an attacker can treat the entire network as a black-box and match packets to data flows based on timings and sizes. Getting around this problem is costly in terms of bandwidth (you need to send additional “cover traffic”) and latency (you need to delay some comm traffic to create a virtual circuit with fewer peaks and space out your packet sends.)

    You mentioned that there are lots of different ways that p2p traffic could be encrypted and tunneled, but this actually works in the favor of the ISPs. They only need to be able to identify traffic that conforms to expected flow characteristics, everything else gets dumped into the “suspected p2p” bin and is dealt with according to a different policy. Having a tool to identify “legitimate” traffic flows means that p2p which wants to hide must conform to these models; unfortunately, none of the standard protocols are sustained high-bandwidth, multi-connection traffic flows…

    Comment by evgen — June 30, 2008 @ 5:49 pm

  9. @evgen: Thanks a lot for the comment.

    I’m not sure I totally understand what you mean by “The additional datapoint that the observer has is the packet destination.” Maybe I’m misunderstanding you but we’re talking about the ISP looking at only a single connection here (an ssh tunnel). So they only get a single packet destination (which might have 100 tunneled destinations), which shouldn’t help them much.

    But yea I think you’re right that it would be hard to make the connection look like another protocol without greatly reducing the transfer rate. Mainly because you’d need to vastly reduce the amount uploaded.

    Comment by coderrr — June 30, 2008 @ 6:38 pm

  10. Yeah, after re-reading that I can see that I was a little imprecise about the packet destination being a part of the observable set. What I was aiming to point out was that encrypted p2p traffic is not particularly easy to hide given the large number of destinations a host will communicate with. If there are a lot of encrypted flows between your IP address and a varied collection of hosts whose IP addresses are on multiple ASNs then it would raise a flag and merit further examination by such a filter.

    Comment by evgen — June 30, 2008 @ 10:10 pm

  11. [...] Detecting SSH tunnels using a Bayes classifier trained on intra-packet intervals and packet length. nifty! (via /.) (tags: via:slashdot bayes classifiers ssh tunnels vpn networking security crypto papers) [...]

    Pingback by links for 2008-06-30 / taint.org: Justin Mason's Weblog — June 30, 2008 @ 11:40 pm

  12. Cool work.

    Is there anything we can gain from it to make TCP or other protocols more secure against such practices?

    Comment by wingbat — July 1, 2008 @ 1:35 am

  13. [...] Detecting SSH tunnels « coderrr (tags: security crypto networking ssh) [...]

    Pingback by links for 2008-07-01 | Zero / Love — July 1, 2008 @ 5:34 am

  14. [...] They claim their technique can differentiate between “normal” ssh or scp sessions and ssh sessio…. Write a comment [...]

    Pingback by technichristian.net » Blog Archive » Detecting SSH Tunnels — July 1, 2008 @ 7:00 am

  15. I hope this doesn’t catch on. I’m a university student, and I have to tunnel version control protocols like svn and git over SSH because otherwise the connection is consistently killed. (I suspect it’s some anti-P2P measure that misdetects them due to them having a similar traffic profile to P2P).

    If this sort of thing became widespread, I probably wouldn’t be able to check anything out over the svn or git protocols at all.

    Comment by Aidan Thornton — July 1, 2008 @ 9:28 am

  16. [...] turns out that Bayesian techniques disclose the nature of application streams even when they’re encrypted with SSH: They claim their technique can differentiate between “normal” ssh or scp sessions and ssh [...]

    Pingback by Differentiating Sessions inside SSH Tunnels : Emanative — July 1, 2008 @ 9:45 am

  17. @evgen: Thanks for clarification, that’s what I thought you meant. But as I pointed out with an encrypted SSH tunnel there won’t be encrypted flows between a collection of hosts. There will be an encrypted flow to only a single host (your SSH server).

    Comment by coderrr — July 1, 2008 @ 10:37 am

  18. [...] Más info. [...]

    Pingback by El Tráfico Encriptado, ya no es seguro. | 8chapas.com — July 1, 2008 @ 10:45 pm

  19. [...] July, 2008 (20:18) | Geek, Privacy, Security New research could allow ISPs to selectively block or slow down your encrypted traffic even if they cannot snoop on your transmitted data. Italian researchers have found a way to [...]

    Pingback by In Through The Out Door » Encrypted Traffic No Longer Safe From Throttling — July 3, 2008 @ 2:19 am

  20. [...] do potencial desta tecnologia, ela ainda apresenta alguns defeitos. Para além dos investigadores apenas terem conseguido detectar as ligações encriptadas através [...]

    Pingback by Traffic shaping de P2P encriptado via SSH a caminho | Remixtures — July 3, 2008 @ 4:17 pm

  21. Una solucion es que se pague un extra-canon por el acceso a Internet. ¡La propia SGAE lo ha propuesto! Con lo facil que es crear asi un fondo para repartirlo entre los artistas, segun el numero de descargas o el numero de busquedas, etc. Si no se sigue esta solucion es porque los gobiernos, entre dos posibles soluciones, suelen preferir optar por la que les otorga más poder sobre los ciudadanos, y tambien por la que beneficia aun mas a la minoria rica, y con influencia, en perjuicio de la mayoria de la gente.

    Esto tambien ha sido propuesto en Estados Unidos, que los usuarios de Internet paguen un canon de $5 (3 Euros) al mes para descargar todo lo que quieran…

    Otra solución: el Imule (INVISIBLE EMULE). Sí, es el mismo emule o amule, pero sin necesidad de servidores (red Kademlia solo), los archivos son encriptados (no se sabe si lo que se envia es un mp3 o un email), las direcciones IP no son mostradas (no es posible identificar al ordenador), se generan IP virtuales y con enrutamiento anónimo (mixer anonymous tunnel).

    Pagina de imule:

    http://www.imule.i2p.to/index.html

    Yo ya lo estoy probando

    Comment by Anonymous — July 5, 2008 @ 11:15 pm

  22. This detection method is useless, I’m sure they know that themselves, its easy to change the packet size, mtu and other variables, and also control the flow of packets which is sure to break their method. Its even possible to pass packets off as legit https or other connection types, infact I would say tunneling in this fashion is possibly the most secure way to transfer data. Not only can it be strongly encrypted but it can also be spoofed as other data with no reliable way of differentiation.

    Comment by Cormac — August 15, 2008 @ 10:14 pm

  23. [...] an analysis of which I offer from someone with a bit more technical SSH tunnel knowledge than myself: Although their research is quite interesting there are a few things which limit its practicality. [...]

    Pingback by ‘Tunnel Hunter’ Detects Encrypted P2P Traffic With 90% Accuracy (ZP) | Direct2News — September 17, 2008 @ 10:11 pm

  24. [...] – bookmarked by 3 members originally found by xacu on 2008-10-17 Detecting SSH tunnels http://coderrr.wordpress.com/2008/06/28/detecting-ssh-tunnels/ – bookmarked by 3 members [...]

    Pingback by Bookmarks about Ssh — October 29, 2008 @ 3:15 am

  25. i found a tutor on ssh here

    http://techwor.com/how-to-bypass-throttling-isp-with-ssh/

    does anyone tried it b4? does it works?

    Comment by charleston — November 10, 2009 @ 4:58 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Silver is the New Black Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 28 other followers

%d bloggers like this: