Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
i have a slackware box running dansguardian and squid... everything's fine, but i'm having doubts about whether people are bypassing dansguardian by using anonymous SSL proxy servers on the Internet... i mean, i have a transparent proxy setup, and all HTTP (TCP port 80) packets go through dansguardian, but all HTTPS (TCP port 443) traffic gets NATed by the iptables firewall...
so my question is: what steps can i take in order to minimize the possibility of someone bypassing DansGuardian using an HTTPS proxy connection??
i'm thinking maybe i could use a list of known proxy IPs or something like that and then just filter them using iptables but i'm not sure where to get such a list and i'm also not sure if that's the right approach...
any ideas would be greatly appreciated... thanks in advance...
I don't know the answer to your question, but DansGuardian implies that you're running a Smoothwall box, no? If so, you might have better luck getting an answer in the Smoothwall forums.
IIRC, squid can do proxying of HTTPS as well. Why not just block outbound direct HTTPS with the firewall and require LAN users to go through the proxy?
Originally posted by jcliburn I don't know the answer to your question, but DansGuardian implies that you're running a Smoothwall box, no? If so, you might have better luck getting an answer in the Smoothwall forums.
the OP clearly states it's a Slackware gnu/linux box... dansguardian will run on any distro...
Quote:
Originally posted by Capt_Caveman IIRC, squid can do proxying of HTTPS as well. Why not just block outbound direct HTTPS with the firewall and require LAN users to go through the proxy?
yeah, i could remove the FORWARD rule for 443/tcp, etc., but how would i block the access to the HTTPS proxies then?? by using squid ACLs?? also, if i do it that way, can the HTTPS be transparently proxied like HTTP?? or would i need to manually configure every box on the LAN to use the proxy for HTTPS??
well, i'm doing some experiments on my slackware PC (not the server in question) and it looks like i am able to do this using the squid ACLs with something like this example:
Code:
acl SSL_ports port 443
acl CONNECT method CONNECT
acl sucky-proxy dstdomain .someproxysite.com
http_access deny sucky-proxy SSL_ports all
right?? in that example AFAICT the users will be denied access to https://www.someproxysite.com while at the same time access to the non-https site (http://www.someproxysite.com) would be allowed (with the other ACLs - if not filtered by dansguardian)...
okay so now i know it can be done like this, but i still have two questions:
1 - can squid handle HTTPS tansparently?? or must the clients specify the proxy address??
2 - is there anywhere i could get a well maintained list of HTTPS Proxy sites i should deny??
so it looks like the PCs on the LAN will have to specify the proxy address for HTTPS if i am to start proxying HTTPS...
so now i'd like to find-out if there's some way that i can send this information (the https proxy address) to the clients with the DHCP server so that the PCs don't need to be manually reconfigured...
i'm gonna google it of course but if anyone knows please do tell...
EDIT: okay i googled it and it looks like this is what i need to do:
How did this go? I know this thread it 2 years old, but I'm just curious if you discovered anything better than wpad.
Well, for this I ended-up using Squid ACLs to help prevent the HTTPS bypassing. IIRC they were a mixture of url_regex and dstdomain. The domains I used on the dstdomain ACLs were the result of manually googling for proxy sites and indexes. So essentially, I stopped doing SNAT for HTTPS, and I used wpad to give the Windows boxes the HTTPS proxy address.
Considering this was two years ago, there are probably much more comprehensive proxy URL lists available on the Web today. You might even find decent IP address lists which you can then blacklist with iptables if you wanna stick with SNAT. The bottom line is that without doing whitelisting there really isn't any sure-fire way to prevent the truly determined from bypassing DG like this. So if you can't whitelist, you pretty much just do whatever you can. In my case, the guy I set this up for was happy enough with the ACLs.
I'm working on a similar issue and looked at dansguardian as well as the Corporate Guardian commercial product. I do not see an easy way to analyze SSL traffic in either product.
Forcing All web traffic through the proxy is the easy part. Making sure it's not unwanted traffic is a different story.
A commercial product I am looking at is BlueCoat. BlueCoat will essentially do an automatic man-in-the-middle attack on all SSL connections (unless you have defined them as sites to leave alone in your config) so that the traffic going through the SSL tunnel can be examined to ensure it is within the bounds of the corporate policy. Basically you are grabbing the SSL certs as they pass through and use them to decrypt the traffic so you can examine it. I need to issue a cert of my own and install it on all the client work stations here so this process would be seamless to the end user.
This can be used to inspect the content of webmail to ensure users are not sending corporate secrets etc..
This method is also used by rogue wireless access points in public areas such as airports etc.. to be able to gather login and password info for 'secure sites'. One reason I have disabled Wi-fi on all corporate laptops and got them evdo cards.
Let me know if this can be pulled off with or in conjunction to Dansguardian..
I've never done it, but I believe Squid can be made to work as an HTTPS man-in-the-middle by use of the https_port option. Not sure how one would plug DansGuardian into the mix, though. I too would be interested in learning how to do it.
That said, this issue-your-own-cert thing is a pretty nasty practice IMHO. I know that sometimes it might be necessary for surveillance reasons, though. I would just make sure employees fully understand that once this is done, none of their would-be HTTPS connections are secure anymore - no matter what their browser says. Failure to make sure they understand this would IMHO be a textbook case of unethical behavior.
Well, I know this is a really old post, but It was useful to me, so I'll just complete some information that can be useful to others.
I do not use a transparent proxy, and the info still is valid for me.
As win32sux stated, the problem is that secure pages (port 443) are sent from squid directlly to de gateway without passing through dansguardian. I tried to force than without solutions.
Finally did just the block in squid with ACL.
The problem win32sux had was to input all the proxy sites manually, so I made use of dansguardian blacklists.
I replace win32sux solution:
acl SSL_ports port 443
acl CONNECT method CONNECT
acl sucky-proxy dstdomain .someproxysite.com
http_access deny sucky-proxy SSL_ports all
for this one:
acl CONNECT method CONNECT
acl sucky-proxy dstdomain "/etc/dansguardian/blacklists/proxy/domain"
http_access deny sucky-proxy
That file contains lots of proxy sites.
As you can note, I remove (in the last line) SSL_ports all, because it doing that, it blocks all 443 ports, and I dont want that.
I've never done it, but I believe Squid can be made to work as an HTTPS man-in-the-middle by use of the https_port option. Not sure how one would plug DansGuardian into the mix, though. I too would be interested in learning how to do it.
That said, this issue-your-own-cert thing is a pretty nasty practice IMHO. I know that sometimes it might be necessary for surveillance reasons, though. I would just make sure employees fully understand that once this is done, none of their would-be HTTPS connections are secure anymore - no matter what their browser says. Failure to make sure they understand this would IMHO be a textbook case of unethical behavior.
Definitely unethical. I can't imagine any instance where this would be justified. Sounds like an NSA illegal wiretap scheme to me.
I'm all for detecting an inappropriate session, but decrypting and reading goes too far. It's like reading people's corporate email. Even though it's possible to read employee's email, it doesn't make it right.
I still like the idea of the L7 detection, mentioned in the other thread, not for blocking, because of false positives, but for detecting, to take appropriate administrative actions.
I've never done it, but I believe Squid can be made to work as an HTTPS man-in-the-middle by use of the https_port option.
ISA proxy from micro$oft does this
And this is lovely when this kind of machines get compromised.
Which makes it IMO, a very bad idea.. Would be better to tell people to not use https anymore then.
If you're scared of people sending secrets, I hope you also monitor usb sticks, cd writer, external disks, every printed page, PC covers are locked so that harddisk can't be removed,... brainwashing pills at the door,..
Thank god there is gpg for end to end user privacy..
Ironport S-series proxy, secure computing Webwasher, Barracuda web proxy, and bluecoat SG's will all do transparent https proxy but you have to a layer 4 router to be able to redirect 80 and 443 transparently over to the proxy. Cisco, and foundry are the 2 companies that i know off the top of my head that do transparent layer 4 redirects. I have another post on here somewhere that has alot of info on proxy servers. I will dig up the post and link it here.
Definitely unethical. I can't imagine any instance where this would be justified. Sounds like an NSA illegal wiretap scheme to me.
I'm all for detecting an inappropriate session, but decrypting and reading goes too far. It's like reading people's corporate email. Even though it's possible to read employee's email, it doesn't make it right.
I still like the idea of the L7 detection, mentioned in the other thread, not for blocking, because of false positives, but for detecting, to take appropriate administrative actions.
My company justifies it and rightly so. They explicitly tell you that they monitor all actions performed on the computer they let you use, including the corporate email accounts they hand out and all webpages you access. All internet is filtered through a proxy. It is a DoD contractor, so I suppose that's reason enough. Even this post I am typing will be filtered, along with this website and the forum I am on and the text that goes along with it.
IMHO, too much is filtered but that comes with the job.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.