Protocol Verification for Proxies | ISGMLUG

Welcome to our SGML and XML Resource site

Protocol Verification for Proxies

It’s not always essential for a proxy to understand what protocol is being tunneled for it to function correctly.  For example circuit level tunnelling such as SSL (or SOCKS) enables any protocol to be transported through a configured proxy gateway.  The reason is that the proxy doesn’t need to understand the protocol simply because it has no need to verify what is being transported.  SSL Tunneling protocols are usually capable of transporting any TCP-based protocol like FTP or Telnet perfectly easily.

Although this makes the proxy very efficient and adaptable because it can merely act as a gateway to channel information, there is an obvious issue of security.  If a proxy will happily tunnel whatever is sent to it, there can be issues with the proxy being used to relay attacks or malware.  Such proxies are an obvious target for hackers who wish to infiltrate an internal network or computer.

There are various solutions to this of varying complexity, however a common one is to limit only well known ports to be tunnelled.  There for the proxy would only allow 443 for HTTPS, 23 for Telnet, 563 for SNEWS – simply using the ports to allow only specific protocols through.  Unfortunately this is open to abuse as the specified port is only a recommendation and there is nothing to stop someone using a different port in order to hide the protocol.  Indeed many security programs allow the port to be specifically configured in order to bypass firewalls and proxy configurations.

For example you may only allow 443 on your UK proxy server in order to restrict traffic to secure connections.  Without any intelligence built into the server, then any one could merely note that 443 is open and tunnel whatever traffic they need through that open port.   These servers though have generally been decommissioned over the years due to these security concerns.  Most of the modern day proxies have the ability to verify the protocol they are transporting. This means that attempts to use an open port to transport a different protocol can be blocked.

Obviously there will be a requirement to leave some ports open, and there will always be some risks of applications using non-standard ports.  It still makes sense to block ports that you definitely don’t want transported through your proxy.  For instance it is usually advisable to block mail ports 25 plus those reserved for things like telnet 23.

The proxy server is an important component of most modern networks which is why the simple, dumb servers of a decade ago needed a severe upgrade.  Even a badly configured proxy however offers some protection, compared to networks which are left completely open to the internet.  At the very least the proxy offers a single point of contact where traffic can be blocked, scanned or protected when needed.

 


Post a Comment

Your email address will not be published. Required fields are marked *

  • Recent Posts