quarta-feira, janeiro 05, 2005

sobre como "escapar" de um proxy eca ntlm (ms proxy)

Tunneling Out of Proxy Prison (Internet)

By Milo Minderbender
Wed May 19th, 2004 at 11:18:58 PM EST

Since I started my new job a few months ago, I've been trapped in proxy prison, unable to ssh to my home machine or any internet servers. My main goal was to use downtime at my day job to do web development work for a small company that I set up a few years ago (more on the morality of this later). I've finally broken free of the proxy prison, and here's how I did it. It wasn't easy...


Rules of the Game
Damn Microsoft HTTP proxy server uses proprietary NTLM (NT Lan Manager) protocol that only MS products know how to use. This is slowly changing with Mozilla and a few other applications now able to use the protocol.
For some idiotic reason you can only leave the NTLM proxy server on the other side if you are destined for port 80 or 443. I'm not sure how Windows Media Player gets around this... I sure haven't been able to avoid it.

Luckily a similarly imprisoned python geek has written an app called aps098 that converts from normal HTTP proxy traffic to NTLM proxy traffic. Although I could have written my own NTLM authentication, my end result would have been equivalent to this program, so why bother?

I was also able to find a program called desproxy that converts normal socket traffic to HTTP proxy traffic. I saw how to do this, but I decided to just use this prebuilt app. So now I can get ssh sockets out the other end of the NTLM proxy. But then what? I still was only able leave the NTLM proxy if my destination port was 80 or 443. I had to find a way to get to the ssh port (22) on the destination server. To do this, I needed a helping hand on the other side of the NTLM proxy server.

Well, I managed to whip up a tiny web application to run on my home computer that allows me to spawn a java threaded proxy server (something I wrote a few months earlier for something else) routing from whatever local port to whatever destination server and port. So if I put in local port 443, and destination of my server, port 22, it will listen on 443 and forward whatever sockets it gets on to my server at the ssh port. This web app has to run at port 80, of course, and I can use a regular web browser to see it. After it's all set up, I just type "ssh localhost" on my machine at work, and [tada!], I get the server's login prompt!


diagram (any admin wanna insert this image?)


What a bloody nightmare. Even with 4 middlemen between me and my server, the connection speed is still bordering on usable. I was able to do a full checkout of the code from CVS with no problem. Unfortunately, actually doing work would require too many switches of where the java proxy is sending me. To ssh on my home computer for scp'ing the files there, then restarting the server, then switching to my app server's port to view the application, while not being able to watch the log files (via an ssh session). It's not really gonna work. For some small self-contained problems, it could work fairly well.

On Morality and Risk

My boss and the rest of my team have specifically told me to work as slowly as possible and to always appear as if I am working. Our team has nothing to do at the moment and we actually fight over who gets to work on the bug reports as they are raised. As usual, one or two levels up the ladder, they haven't got a clue. Ahh, the corporate life: do nothing all day, get paid a lot. Own your own business: work your ass off all day and all night for pennies an hour. I'd honestly take the latter over the ladder any day.

There's absolutely no risk of getting caught. The tech services team have been around a few times to (attempt to) install upgrades and whatnot. Their incompetence was appalling! I try not to think of what they are getting paid.

Since I originally set this up, another layer of job protection has been added. The aps098 application has been moved to another unused machine using the username of an ex-employee so that other team members can run their instant messaging apps through the NTLM proxy, so the traffic is now neither coming from my ip nor using my user name.


Nenhum comentário: