Hi all,

I'm running squid/dansguardian on our corporate firewall, and am now researching the SSH tunneling tools available. We currently only use basic authentication, getting ready to switch to NTLM authentication.

Is there a way to prevent users from tunneling through my squid proxy server? If I can't block it with squid, can I do it with something like snort, fwsnort, etc.?

Thanks

I don't think you can tunnel ssh through squid. squid is used to proxy http, https and ftp protocols.

You can google, and find hundreds of sites that explain how to use SSH through a proxy. Here are some of them:

http://www.your-freedom.net/index.php?id=4
http://polishlinux.org/apps/ssh-tunn...ate-firewalls/
http://weyland.be/wrdprss/index.php/...ia-ssh-tunnel/

You can also google, and find NO sites that explain how to prevent them!!! It's driving me nuts.

Extra Info:

Defending against brute force ssh attacks
http://www.astalavista.com/index.php...ws&cmd=details

SSH Proxy
http://ha.ckers.org/ssh_proxy.html

Note: edit sshd_conf AllowTcpForwarding no

I have port knocking, so there are NO ports open to the WAN. Thanks though

I'm not sure how setting the AllowTcpForwarding to NO on the ssh server on the firewall is going to have any effect, but I will look into it. The user doesn't even have access to the ssh server. My understanding is the user client goes right through the squid proxy, pretending to be a browser. ALL ports are closed to the LAN as well. I'll experiment with that tomorrow (I'm at home right now, gotta get a life heh).

I documented my firewall, here's my how-to:
www.abazaba.org/debian/firewall.html

Don't waste your time, it has nothing to do with your problem. I believe he just misunderstood your question or something when he suggested that. A fool-proof solution to your problem is to simply whitelist the websites using Squid ACLs, but I assume you already knew that and it's not feasible, right? Even if you manage to install software which can distinguish between real HTTPS and tunnel/SSH/whatever you're still left with the fact that a user could simply use a real HTTPS site to bypass you.

I've seen one recommendation, where the HTTPS is throttled way down, very slow, to discourage use of SSH tunneling, Skype, etc. However, I hate that idea. It punishes the innocent to intimidate the guilty.

There's got to be a way. Somebody has already solved this, I'm sure. I'll have to fire up wireshark, run some tests from ssh, corkscrew, proxytunnel, etc., capture the packets, and look for something in common, then create a shorewall/iptables filter to drop it, and log it. If I can do that, I can take it a step further and add a rule to snort or fwsnort, to tear down the session, and ban access to the remote site, and anything else I want.

I fear the solution is a guarded secret, to prevent abusers from finding out how to exploit it. That would be my luck...

I don't have a clever answer, but to help identify offenders, you could process your access_log files and review the results at regular intervals. There are lots of logfile analysis utilities. (I use calamaris.)

There may be some red flags that you learn to watch for over time, e.g.: Regular access to a single host from a single client IP, access to a host whose reverse lookup turns out to be an ISP dhcp address, etc.

Application layer filtering, as you mentioned, may be another solution.

Thanks, I'll check out Calamaris, sounds interesting. I forget the log utility I used to use, lately just checking log files manually. Time for a new log checker

I've never tried it myself, but the L7-filter iptables module says it supports detection of ssh vs ssl (se here). It'd be worth a try before you try and implement your own packet fingerprints.
But as pointed out, if a user is sophisticated enough to tunnel through the https ports, then they'll just send stuff through proper https instead anyway.

Good luck.

Plus the only way for it to work is if everyone is denied any usable bandwidth.

Nothing at the network layer will help you here. You will need to do this either at the application layer (for example, have your proxy be a man-in-the-middle and then do deep packet inspection), or at the human resources level (AUP, etc). Most likely you will need to use a synergistic combination of techniques, as there is no single one which would provide any reasonably decent level of effectiveness AFAIK (aside from whitelisting).

Fascinating, wasn't aware of that one. Still studying it, very interesting indeed.

I hate to say it, but it seems easier to just prevent HTTPS from the lowest level access group in our organization, mainly temps brought in for data entry, but they still need general Internet access, mainly to google for research purposes, etc. There are way too many subjects researched to utilize white listing. Instead, we're depending on Dansguardian. I have already tweaked Dansguardian to block naughty/non-work related sites, and it is working great. I think this could be an acceptable solution. A trial run blocking HTTPS for the temps might be in order.

I'm thinking if a temp needs HTTPS to pay their electric bill online, or some other need for HTTPS, they can come to me and do it from my desk (or their manager), or better yet, just do that stuff off-hours at home or elsewhere.

For regular employees and above, I guess we'll have to depend on the Acceptable Use Policy, and of course, keep an eye on the log files for abuse. Regular employees will be more concerned about getting reprimanded, so this might have to suffice.

For anyone reading this thread, no I'm not some pig-headed IT jerk trying to play GOD and over-control my position. We have limited bandwidth, and unfortunately too many employees that if allowed, will sit there and chat on myspace, watch youtube, and do all other kinds of non-work activities. Our managers are far too busy to minute manage, and watch what people do. We shouldn't have to. Unfortunately, people are spread out, and our environment is very relaxed, so people tend to goof off when not busy, especially the night shift crowd. Before I implemented Dansguardian, I can't tell you how many times I'd notice people minimizing browsers when they saw me walking by, to hide their goofing off. Many of our employees are young adults that just don't see a problem with it. Our owner expects me to automate the defenses as much as possible. He feels (and I agree) if they can't goof off in the first place, that alone would solve this problem.

I'm going to continue researching the L7 filters, and give feedback here. I think it's worth looking into.

I'm open to your thoughts and suggestions on this. I'd be grateful for any other ideas that could help with this problem.

Thank you all for your feedback