In some email I received from Marcus J. Ranum, sie wrote: > > >Youre example is not using a proxy based firewall, you are using the > >transparent DNS port. If you force the DNS through a proxy proces as it > >should on a proxy based firewall (hidden DNS o.i.d) (No transparent > >connection at all) then this trick will not work. > > > Back when I was writing the firewall toolkit I hacked together a > version of a /dev/tun driver and had it piping its output into a > script that uuencoded packets, then emailed them to an alias on > a remote machine which uudecoded them and shoved them into /dev/tun. > It worked; ping round trip times were in the order of seconds, > which made running NFS difficult without adjusting timeouts. I > was able to mount filesystems after a bit of fiddling, and could > get a very slow telnet session connected. > > Tunnelling over DNS would be silly, anyhow; most firewalls > have this huge gaping hole called SSL... The only context I can think of this making any sense is when you have an inside agent program that makes an SSL connection to an external host for the express purpose of providing access to systems on the inside (sort of like dial-back). The `solutions' are not pretty: disable any protocol using encryption because the firewall cannot validate the message's integrity or force everything to be decrypted and re-encrypted as required to allow the message to be checked that it matches the right protocol. Darren
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:00:01 PDT