SSH through the AS12880 / DCI Iranian government-run firewall?
June 22, 2009 8:54 PM Subscribe
Iranian firewallfilter: How to make SSH traffic not resemble SSH traffic, when examined by a deep packet inspection device (Ellacoya, Narus, etc)? Other advice on specific types of VPN from within Iran also welcome.
I've been following the news about Iranian Internet censorship for a few years now, but obviously started paying more attention in the last couple of weeks. There's two interesting papers examining AS12880 (DCI)'s Internet transit from Arbor Networks:
Iranian Traffic Engineering
Deeper Look at the Iranian Firewall
Misc:
Robtex page examining AS12880's uplinks to the world
Rense page, strange changes in Iranian Internet transit
What I'm wondering specifically is methods which can be taken to make SSH traffic look -less- like SSH traffic. Assume that a person inside Iran has root on a European-colocated FreeBSD or Linux system (or root on a VPS/Virtual Machine) running the latest OpenSSH. The sshd would of course be listening for incoming connections on a nonstandard port, it could be any port, or multiple different ports. If I remember right OpenSSH now defaults to SSH2/AES but can also use Blowfish. Are there any methods that can be used to disguise the initial SSH handshake and packet headers? Any special tricks from the client software end, assuming that the client (OSX or Linux) can run any ssh client that will compile on it?
Is VPN traffic (Cisco, or Juniper-Netscreen SSL-VPN) less likely to trigger flags or get blocked than SSH?
Does anyone have firsthand or secondhand experience of Windows Remote Desktop / RDP 5.1 being blocked from within Iran?
I've been following the news about Iranian Internet censorship for a few years now, but obviously started paying more attention in the last couple of weeks. There's two interesting papers examining AS12880 (DCI)'s Internet transit from Arbor Networks:
Iranian Traffic Engineering
Deeper Look at the Iranian Firewall
Misc:
Robtex page examining AS12880's uplinks to the world
Rense page, strange changes in Iranian Internet transit
What I'm wondering specifically is methods which can be taken to make SSH traffic look -less- like SSH traffic. Assume that a person inside Iran has root on a European-colocated FreeBSD or Linux system (or root on a VPS/Virtual Machine) running the latest OpenSSH. The sshd would of course be listening for incoming connections on a nonstandard port, it could be any port, or multiple different ports. If I remember right OpenSSH now defaults to SSH2/AES but can also use Blowfish. Are there any methods that can be used to disguise the initial SSH handshake and packet headers? Any special tricks from the client software end, assuming that the client (OSX or Linux) can run any ssh client that will compile on it?
Is VPN traffic (Cisco, or Juniper-Netscreen SSL-VPN) less likely to trigger flags or get blocked than SSH?
Does anyone have firsthand or secondhand experience of Windows Remote Desktop / RDP 5.1 being blocked from within Iran?
you could theoretically tunnel through DNS, but its iffy and experimental (though probably good in a pinch). there is also freenet.
the best way not to be noticed is not to hide per-say, but to blend in with the crowd. by that, i mean use the MOST used protocol to do your dealings. its a lot harder to sift through a ton of legit traffic looking for data that is slightly different from legit traffic, than it is to find outliers that look nothing like normal traffic patterns. this is probably why proxies are working so well. set them up on port 80, and your traffic is with the rest of all the other chumps on the internet, gigs and gigs of data that would have to be sorted through.
posted by Mach5 at 9:39 PM on June 22, 2009
the best way not to be noticed is not to hide per-say, but to blend in with the crowd. by that, i mean use the MOST used protocol to do your dealings. its a lot harder to sift through a ton of legit traffic looking for data that is slightly different from legit traffic, than it is to find outliers that look nothing like normal traffic patterns. this is probably why proxies are working so well. set them up on port 80, and your traffic is with the rest of all the other chumps on the internet, gigs and gigs of data that would have to be sorted through.
posted by Mach5 at 9:39 PM on June 22, 2009
Freenet, Tor and/or other forms of transport stenography are the best way to do this. the UDP/53 tunneling is difficult and kind of spotty. If you don't want it to look like SSH specifically, you're going to want to try GRE, IPSEC or PPTP, but encrypted traffic is encrypted traffic and short of hiding it in other legitimate packet types you're going to be found out if anyone is really watching. Tor and Freenet are attractive because they can obscure the source (you) and ultimate destination (your shell).
posted by iamabot at 10:08 PM on June 22, 2009
posted by iamabot at 10:08 PM on June 22, 2009
httptunnel - forward a TCP connection (say a full-featured SSH link) encapsulated inside HTTP request/response pairs.
I dunno how good their DPI is, but this may break up the SSH protocol stream enough to evade filtering/detection.
posted by russm at 10:15 PM on June 22, 2009
I dunno how good their DPI is, but this may break up the SSH protocol stream enough to evade filtering/detection.
posted by russm at 10:15 PM on June 22, 2009
Important tail to my note above, GRE, PPTP, L2TP do not provide encryption, you'd need to layer on something on top of that.
posted by iamabot at 10:16 PM on June 22, 2009
posted by iamabot at 10:16 PM on June 22, 2009
iamabot - Tor helps hide your identity from detection at the far end ("who is connecting to my server?") but doesn't attempt to hide the fact that you're running Tor from your own network operator. The new-ish "UseBridges" options can help with this, but I believe your node will still be seen making DNS requests for the directory authorities (moria.mit.edu, etc).
posted by russm at 10:19 PM on June 22, 2009
posted by russm at 10:19 PM on June 22, 2009
Based on how the questions was phrased I believe that Tor will satisfy part of the posters question, which is obscuring ssh connections to the server in Europe. Tor encrypts hops through the onion network until the network is exited and directed to the non onion network node.
posted by iamabot at 10:28 PM on June 22, 2009
posted by iamabot at 10:28 PM on June 22, 2009
I guess there's 2 questions here - how to get traffic past a blocking system, and how to do that in a way that won't lead to a 4am knock on the door in a month or 2 when the situation has stabilised and they're backtracking through logged connection data to see who was doing prohibited things.
Evading blockage is easy, in a standard arms-race (switch tunneling tool, wait for it to be blocked, switch tunneling tool, etc, etc). Doing this in a way that won't leave obvious footprints is the hard bit.
posted by russm at 10:40 PM on June 22, 2009
Evading blockage is easy, in a standard arms-race (switch tunneling tool, wait for it to be blocked, switch tunneling tool, etc, etc). Doing this in a way that won't leave obvious footprints is the hard bit.
posted by russm at 10:40 PM on June 22, 2009
Response by poster: russm has a good point re #2. As far as I know the DSL connections in Iran use fairly common PPP authentication for the modem, and regular DSLAMs from the likes of ZTE and Zyxel. This means that even if the dhcpd assigning addresses to the modems doesn't have a long logging period, by going through the PPP logs they can definitely track specific IP addresses to phone bills and addresses.
The most optimal solution is to run your own uplink to the Internet by satellite, which has cost issues and other problems in Iran. At minimum you'd need to have a 1.2 meter size dish, about a 4W transmitter and a LNB. This looks different on a rooftop from a tv receive only dish. If you have a premises with high walls (Iranians and Afghans love to have 10' walls around their house!) there's ways you could put a dish in a garden without it being observable from the street. The other problem is getting the dish and equipment into Iran...
This is why embassies and missions like the UN in countries with questionable political systems operate their links to the outside world by satellite.
posted by thewalrus at 10:51 PM on June 22, 2009
The most optimal solution is to run your own uplink to the Internet by satellite, which has cost issues and other problems in Iran. At minimum you'd need to have a 1.2 meter size dish, about a 4W transmitter and a LNB. This looks different on a rooftop from a tv receive only dish. If you have a premises with high walls (Iranians and Afghans love to have 10' walls around their house!) there's ways you could put a dish in a garden without it being observable from the street. The other problem is getting the dish and equipment into Iran...
This is why embassies and missions like the UN in countries with questionable political systems operate their links to the outside world by satellite.
posted by thewalrus at 10:51 PM on June 22, 2009
Response by poster: From the client end, how easy is tor traffic to identify as 'tor traffic'? Example, say the traffic from an aggregation switch's uplink port (100Mbps / 1000Mbps) is mirrored to a port plugged into a decently capable x86 box and run it through basic tools like tcpdump or ethereal. Nevermind ellacoya, narus and other deep packet inspection devices, just basic analysis with free tools.
posted by thewalrus at 10:55 PM on June 22, 2009
posted by thewalrus at 10:55 PM on June 22, 2009
Have you looked into httptunnel already? It seems to do what you're looking for — encapsulate SSH in HTTP — but I don't know if the DPI vendors have already programmed their boxes to see through it. I've played with it in the past but just because a technique works in one place doesn't mean it'll work in another; it all depends how the DPI machines are set up.
posted by Kadin2048 at 11:24 PM on June 22, 2009
posted by Kadin2048 at 11:24 PM on June 22, 2009
as I understand it (grain of salt, etc) tor tries to look like plain https traffic as far as possible - some of it actually is plain https (directory updates?) and data circuits look like particularly long-lived https connections with a suspicious amount of bi-directional data in 'em. I've never pointed a packet sniffer at a tor node, but I believe that some identifiable traffic (DNS requests for the directory authorities in order to bootstrap) will be visible.
it's a while since I've looked at any of this, but the bridge relay stuff appears to be aimed at making the detection of tor traffic much harder when your adversary is your ISP.
posted by russm at 11:36 PM on June 22, 2009
it's a while since I've looked at any of this, but the bridge relay stuff appears to be aimed at making the detection of tor traffic much harder when your adversary is your ISP.
posted by russm at 11:36 PM on June 22, 2009
Oh, russm beat me to it. Should have previewed. (I left the page open and came back to it much later. Mea culpa.)
Firepass also looks like it might be worth trying; it uses a slightly more complex tunneling method. Actually they have several proof-of-concept tools for different tunneling schemes; I don't know if any of them are really production quality, but they might serve as starting points.
Also just in terms of trying the easy solutions before creating a more difficult one, have you tried using a SSL VPN? They might "look" more like normal traffic then IPSEC does. (IPSEC is pretty obvious even on casual inspection of the packets; SSL VPN packets might look more like HTTPS. If they let HTTPS through, OpenVPN might work.)
Cisco has an SSL VPN product that doesn't require a VPN client on the remote machine — it pushes the VPN client software out via an ActiveX component — but to my knowledge there's nothing like this for OpenVPN. That's unfortunate because it strikes me as a nice feature to be able to fire up the VPN from any old kiosk machine rather than have to use one with potentially incriminating software installed.
If there's an off-the-shelf package (like OpenVPN or one of Cisco's boxes) that works right now, you might as well use it and in the meantime develop the next phase. As others have said it's going to be a cat-and-mouse game; you might as well drag it out by escalating slowly. Make them plug up all the big holes first, then exploit the small ones or force them to start doing detailed behavioral analysis when other approaches fail.
posted by Kadin2048 at 11:40 PM on June 22, 2009
Firepass also looks like it might be worth trying; it uses a slightly more complex tunneling method. Actually they have several proof-of-concept tools for different tunneling schemes; I don't know if any of them are really production quality, but they might serve as starting points.
Also just in terms of trying the easy solutions before creating a more difficult one, have you tried using a SSL VPN? They might "look" more like normal traffic then IPSEC does. (IPSEC is pretty obvious even on casual inspection of the packets; SSL VPN packets might look more like HTTPS. If they let HTTPS through, OpenVPN might work.)
Cisco has an SSL VPN product that doesn't require a VPN client on the remote machine — it pushes the VPN client software out via an ActiveX component — but to my knowledge there's nothing like this for OpenVPN. That's unfortunate because it strikes me as a nice feature to be able to fire up the VPN from any old kiosk machine rather than have to use one with potentially incriminating software installed.
If there's an off-the-shelf package (like OpenVPN or one of Cisco's boxes) that works right now, you might as well use it and in the meantime develop the next phase. As others have said it's going to be a cat-and-mouse game; you might as well drag it out by escalating slowly. Make them plug up all the big holes first, then exploit the small ones or force them to start doing detailed behavioral analysis when other approaches fail.
posted by Kadin2048 at 11:40 PM on June 22, 2009
Re: tor's traffic - it is entirely SSL (and uses DNS sometimes), plain and simple. Many people run their tor nodes on port 443 to allow access from sites that block everything besides "HTTPS". I'm not a tracking expert and assume you could still get pretty good heuristic detection of tor vs real HTTPS by looking at the timing of the data flow, but running stuff like this on a giant central firewall seems too complex and false-positive-prone to me.
posted by themel at 2:09 AM on June 23, 2009
posted by themel at 2:09 AM on June 23, 2009
Re: your original question - you probably want to piggyback on the "mask as HTTPS" strategy - run an SSL listener on port 443 that redirects to your internal SSH port, then run SSH over SSL (you want socat to do the plumbing on server/client side, probably.
For a billion points, use the fact that HTTP is a "client goes first" protocol while SSH is a "server goes first" protocol to make a fancy listener that waits for a second before redirecting. When it gets a HTTP request within that second, it forwards to a HTTP server instead of the SSH. Looks like HTTPS to a browser, looks like SSH to an SSH client. Neat.
posted by themel at 2:15 AM on June 23, 2009 [1 favorite]
For a billion points, use the fact that HTTP is a "client goes first" protocol while SSH is a "server goes first" protocol to make a fancy listener that waits for a second before redirecting. When it gets a HTTP request within that second, it forwards to a HTTP server instead of the SSH. Looks like HTTPS to a browser, looks like SSH to an SSH client. Neat.
posted by themel at 2:15 AM on June 23, 2009 [1 favorite]
Blog post with a proof-of-concept implementation of the "billion points idea" above.
posted by themel at 6:37 AM on June 23, 2009
posted by themel at 6:37 AM on June 23, 2009
« Older How do I return a Netflix film if my red return... | Please help me find a contemporary photographer... Newer »
This thread is closed to new comments.
I would suggest looking into carrying the encrypted payload as stenographic HTTP posts
like this, but even this is obvious to any system that does user-level behavioral analysis
There is not really a good way. Even stenographic approaches will be screamingly obvious as atypical behavior if you have a single source. Some sort of distributed network of proxies [on both sides] to distribute the activity might work.. but might not.
posted by rr at 9:08 PM on June 22, 2009