protocols - ISGMLUG

Proxy Protocol Verification

Any circuit level tunneling through a proxy server such as SOCKS or SSL, will allow most protocols to be passed through a standard proxy gateway. Whenever you see a statement like this, you should remember that it implies that the protocol is not actually understood but merely transparently transmits it. For instance, the popular tunneling protocol SSL is able to tunnel virtually any TCP based protocol without problem, it’s often used to add some protection for weak protocols like FTP and Telnet.

But it can create a little bit of a headache for a proxy administrator. Not only can all sorts of protocols be allowed access to a network but often the administrator has no knowledge of the contents due to encryption. There are some short terms solutions which will provide a limited amount of protection - for example blocking access based on port numbers. That is only allow specific ports to be tunneled such as 443 for HTTPS, 636 for secure LDAP. This can work well but remember some advanced security programs like Identity Cloaker allow the configuration of the port, allowing protocols and applications to be tunneled on non standard ports -a bit like a proxy unblocker . It is therefore not an ideal solution and one that cannot be relied upon in the longer terms to keep a network and proxy secure.

The obvious solution of course is to utilise a proxy server that can verify the protocol that is being transmitted. This requires an awful lot more intelligence built into the proxies but it is possible. It does require a bigger overhead, it does make the proxy server more expensive and perhaps more complicated and trickier to manage. However without this sort of intelligence or something similar you will get the possibility of an FTP session being set up through an SSL tunnel for example.

In some ways proxies already do some of this, and protocols that are proxied rather than tunneled at the application level cannot be exploited like this. Examples include HTTP, FTP and even Gophur cannot be used to trick entry, simply because there is no ‘dumb’, direct tunnel the proxy understands and will only relay legitimate responses.

How Does ICAP Work?

In brief, the protocol functions as follows. An HTTP message is passed by an ICAP client to the ICAP server. The server processes the message and sends a reply back to the customer. An ICAP client can be both a Web proxy server or even a Web client. An ICAP server can support services that are expressly requested by customers.

As an instance of the protocol’s use, envision the following situation. An ICAP server implements an access control service : two services, and an antivirus service. Hosts inside a network have access to the Internet via a Web proxy server.

Based on the above situation, the access control service supplied by the ICAP server checks whether a Web client can connect to a Website requested by the client. More particularly, the Web client sends an HTTP request to the proxy server. The access control service of the ICAP server checks if the customer can see or not the site. Eventually, the ICAP server either enables the proxy server to continue with the petition or otherwise, reacts with an informative HTTP message, which is redirected to the Web client by the proxy server.

The service, on the flip side, checks whether information passed through the proxy server are impacted with a virus. The ICAP server scans the incoming information for viruses. The ICAP server responds with a Web page telling the user about the difficulty, if a virus is detected. In order to improve the checks it’s best to send the test virus from a variety of sources. So for example you could buy a US IP and generate the test virus from an American server, in order to protect the perimeter. Many IT Security professionals routinely buy proxy services and VPNs in order to test the integrity of both their internal and external security.

The ICAP protocol is easily extended so that it could control other kinds of info rather than just HTTP requests and answers. For instance, it might be expanded to manage email messages. The format of an e-mail message is just like the format of an HTTP reply. In general, every object or piece of data can be called an HTTP object. For instance, a simple file can be enclosed into an item that contains the real content of the file in addition to file descriptors (Content - Length, Content - Type ) in the and Day, Content Language, kind of HTTP headers.

Border Gateway Protocol - BGP

The BGP protocol is one used by gateways and routers based in different systems. It’s predecessor was called EGP, this protocol actually was used on the ARPANET - the earliest seed of today’s internet. If you’re interested in this, you can find EGP defined in Border Gateway Protocol - RFC 1267.

Any system that runs BGP will supply and receive information from other systems running the protocol. The information as befits a routing protocol is all about networks and how to reach them. The data exchanged will include full paths of autonomous systems and how to reach them, all BGP systems will retransmit any new network information that they receive.

An IP datagram will contain the following information that BGP will use to classify any systems detailed.

A Stub System has only a single connection to another system. As such this will only carry local network traffic.
A multihomed system has connections to many other systems. It won’t however carry any transit traffic.
A Transit system has multiple connections to many other systems. It will allow both local and transit traffic to be distributed.

In fact this is a good way to describe the underlying infrastructure of the internet itself. The topology consists of thousands of these systems with arbitrary connections to one another - some stubs, some multi-homed and transit systems. All these are often described as AS (autonomous systems) connect with each other and exchange routing information using protocols like BGP or EGP for older ones.

The protocol doesn’t include a policy for routing however they can implement policy based routing set up by the administrator. These are set up in configuration files stored on the router - these are used to make routing decisions particularly when multiple routes are available. Unlike other routing protocols which are wildely used like RIP and OSPF - BGP uses TCP as it’s transport protocol. It’s fairly straight forward normally but in complicated networks can add some delay, perhaps routing through a VPN or a French proxy before entering a DMZ in your Zurich based office for example.

When two BGP systems communicate they will first establish a TCP connection prior to transferring the entire BGP routing tables which exists on each router. This exchange only happens on the initial connection (or if the router is reset) afterwards only incremental changes are transferred.

BGP is a distance vector protocol which has been known to have some problems. These vector based protocols have been known to cause networking issues on the internet. If you’ve ever had difficulties accessing resources across the internet that you know are up and working - perhaps getting repeated - this video is not available messages, then there is a chance that a distance vector protocol was too blame. To be fair though BGP enumerates the route to each individual destination which is at the heart of the distance vector protocol issues.