-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 25 Sep 2003, Steve Brorens wrote:
> David said: > > A common example of this folly is to limit people to say 80/443, > > which prevents people from doing anything they like. It does > > _no_ _such_ _thing_, it's trivial to set up a tunnel over 443 or 80 > > and get any access you want. It does require some knowledge, but it's > > easy to implement... > > Agreed. So, we take one step further along this restrictive path... > > As Nick said: "...why let any machine other than the mailserver > get out on port 25?...") - but it's also possible to extend this logic > and restrict outward 80/433 to a proxy server - and set various > policies etc on that. > > With this in place, and access to the proxy server restricted then > the cute tricks with 'nc'and similar shouldn't work. Doesn't help. The point I was making was that you are allowing, by some means, data to flow between the Internet and internal machines. That proxies are involved does not help in any way. Let's say you wish to allow your users access to HTTP over SSL services. This can be proxied, as you've noted, but how the proxy implements this is by providing a simple TCP relay, using an HTTP method called "CONNECT". CONNECT will, unless configured explicitly or filtered, you to connect to any arbitrary port. It has to implement it this way because the SSL exchange must terminate in the browser, so the proxy cannot do anything other than relay the connection. So, we've restricted what port it can connect to, but none the less if you have a willing external endpoint, you can still connect without any interference from the proxy to 443. So you build a tunnel over that, a simple tool to have a listening port on your local machine, and connections to it result in a connection to the proxy, a CONNECT request, and then just relay the traffic back and forth. It's even simpler than that if you're only looking for SSH. Add "Port 443" to your sshd_config and grab yourself a copy of Putty for win32. Tick the proxy options for HTTP proxies, and you're away laughing. Alright, you say, I'll just set up application-level inspection to ensure you're not hijacking 443 for other purposes. Such inspection will look for an SSL exchange, but beyond that it can't do anything else since the payload will all be encrypted. No problem, run stunnel, which does tunneling over SSL for arbitrary ports. Security is _always_ a balance, between effort/cost and actual improvement in security. Simple things, like just reducing how many ports Joe Random PC can talk on is simple and works well against most of people wanting to do something they shouldn't. But, you suffer very serious diminishing returns for expending more and more effort, and you _still_ won't be "perfect". You can go pretty far in this stuff, locked down PCs, 802.1x, and it's not cheap. But someone will work a way around it. It just takes time. - -- David Zanetti | (__) #include <geek/unix.h> | ( oo Mooooooo http://hairy.geek.nz/ | /(_O ./ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE/cjm0T21+qRy4P+QRAt1nAJ4rgigbvON1DAd1+evhfeiDgxOGBQCfWE2/ ZxsyrinSldemBdYbm+AMMI4= =CQxG -----END PGP SIGNATURE-----
