Sunday, April 3, 2011

Bypassing Firewalls

                                             Bypassing Firewalls

                                                          fortigate-200A Antivirus Firewall

This tut highlights a very important problem with network perimeter firewalls.
The threat discussed is not exactly new, but neither is it widely recognised—
even amongst network security professionals.
Most commercial firewalls claim to be application layer devices, but they derive
very little useful information about the context of the application traffic that
passes through them. Malicious applications can misuse even the simplest protocols
in a way that totally bypasses the firewall’s controls. This tut describes
the methods of simple protocol tunnels, and shows how they can be applied. It
also considers ways to counter this threat, and suggests that architectures based on
military security principles and IPSec can improve security dramatically.

 INTRODUCTION
 
Firewalls are regarded as the primary defence mechanisms when connecting private
networks to the Internet. There are various types, but firewalls essentially control access
at the application and transport layers, often using application layer information
to make access control decisions. A firewall is there to stop unwanted traffic from the
Internet entering the protected network. In a similar way, it can also control traffic
flowing out on to Internet.
A firewall is a perimeter security mechanism. It has no control over what occurs on
the internal network. It simply screens any connections made between the inside and
the outside. The only information the firewall has about a particular connection, are the
source and destination addresses and port numbers. This is not enough to reason about
the information that is being communicated. Indeed, it is very easy to fool a firewall 
 into allowing a protocol that it is supposed to be blocking—either by changing the port
numbers associated with that protocol, or by using a protocol tunnel.
The remainder of this tutorial introduces protocol tunnelling and shows how easily
it can be used to bypass a firewall. It then goes on to consider how this threat can be
countered. The reader will notice that this discussion does not suggestways of strengthening
the firewall. It focuses instead on in-depth mechanisms, which complement the
perimeter firewall. These mechanisms are based on a combination of military-style
trusted systems, and on IPSec network security.

 *Protocol Tunnelling
A protocol tunnel encapsulates one protocol inside another. Tunnelling is a general
technique which can be used to carry a protocol across a foreign network. It is often
used to join two isolated networks with a private bridge across a public network,
forming a VPN (Virtual Private Network). Most commonly, IP traffic is encrypted and
encapsulated in a TCP stream, which is carried across the public Internet between two
remote sites.
Any protocol can be exploited for tunnelling. The only requirement is that the
protocol is permitted by any firewall that sits between the tunnel end points. Protocols
like SMTP and HTTP generally satisfy this requirement.Others, like ICMP-ECHO
(the “ping” protocol), are also allowed by most configurations.

*Bypassing Firewalls
 A protocol tunnel can turn an application layer protocol (such as HTTP, or SMTP) into
a transport layer protocol. This can make it very hard for the firewall to reason about
the traffic passing through it.
One tool designed to exploit this fact is GNU httptunnel, which is available under
GNU Public License. This tool creates a point-to-point HTTP tunnel, but it can be used
in conjunction with other software (such as SSH and Telnet) to provide unrestricted
access through a firewall. Users at sites with restrictive firewall policies can enable
protocols that are blocked by tunnelling them through HTTP.
The obvious problem caused by tools such as this is that the firewall policy no
longer dictates the overall security policy. Although users must take a conscious decision
to invoke applications like htc and hts1, it is ultimately the users who can decide
which particular protocols will cross the firewall.

*Simple Tunnel

The Simple Tunnel2 is another general purpose tunnel developed independently
to GNU httptunnel, but at about the same time. It was built as part of a
demonstrator, designed to highlight the threat that tunnelling poses to network security
Like GNU httptunnel, the Simple Tunnel also uses HTTP as a transport, although it
could easily be extended to almost any client-server protocol. However, it is packaged
as a library and not as an application—it is designed to be built in to other applications.
This library, called libtunnel, provides a channel for passing arbitrary messages
between the tunnel endpoints. This messaging system can be used in higher level libraries
and applications, for communicating with a remote host
The operation of the Simple Tunnel is illustrated in fig a. The client and server
queue messages at each end of the tunnel. The client makes periodic connections to
the server.
 The algorithm used by the client is as follows;
1. If the client has messages to send, it makes an HTTP POST request to the server.
The messages are encoded and sent in the body of the request(The client could instead use HTTP GET and encode the messages in the URL of the request)
2. if the client has no messages to send, it makes an HTTP GET request to the
server.
3. If the server has any messages to send, they are encoded and returned in the body
of the response.
The client can be configured to use a proxy, which allows it to work across an
application-layer gateway. In addition, the server can manage tunnels to multiple
clients simultaneously. The applications at each end of a tunnel use a simple API
o read and write messages, and also to control some of the tunnel characteristics.
The Simple Tunnel library has been used in some example applications. One of
these is a remote socket library, called librsocket. It uses the messaging provided by
libtunnel to tunnel system calls to the network stack of the client. The librsocket APIis 
very much like the standard socket APIIt was chosen because it is fairly
simple, very useful, and implemented on a wide range on platforms. But almost any
API on any machine can be tunnelled in the same way. The technique gives the attacker
full access to the resources of a remote host.
While protocol tunnelling is a very powerful tool to use against firewalls, an attacker
from outside must install client software on a machine behind the firewall. It is
fortunate for the attacker that there are a great many ways this could be done, either by
exploiting software vulnerabilities, or by social-engineering attacks. Some examples
might be


Remote exploit. A remotely exploitable bug in a program, which lets the attacker execute
arbitrary code, may be used to bootstrap installation of a tunnel client.
Trojan execution. A user might be tricked into running a tunnel client, thinking it was
something else.
Viral infection. A virus which can infect executable programs may contain a tunnel
client. Even a macro virus might be made to carry a tunnel client, if the macro
has access to networking functions.

To demonstrate a Trojan Horse attack, librsocket was used to build a special version
of the Mozilla browser. In the Macintosh version of this Trojan, this change required
the addition of a single line of code to theMozilla source, and relinking with librsocket.
The resulting browser behaved in every way like a normal web client, except that it
also made regular connections to the tunnel server. Whenever a user ran the Trojan
browser, they unwittingly opened up the network stack of their machine for use by the
“attacker”.



 
 *  Towards Defence in Depth
 It has been said6 that, the total security of a system is worse than the security of the
weakest component in the system. This implies that the weak component in isolation
is less of a problem than when it is integrated as part of a system, which depends upon
the security of the weak component. It follows that, perimeter controls go only part
way to providing security for a private network connecting to the Internet. A firewall
can be bypassed if a host on the inside can be compromised.
As has been shown, a network of insecure systems can not have its security policy
enforced by a firewall alone. But the problem is not the ability of the firewall, it is the
security of the systems behind the firewall. A strategy of “defence in depth” is critical
to preventing attacks such as the one just described. This term has gained popularity
recently and it often used to refer to host-based detection of viruses or intrusions. But
true in-depth defences should protect against these attacks too.


A LIST OF NEW PROXIES WILL BE LISTED SOON ..............
 


0 comments:

Post a Comment

Breaking News
Loading...
Quick Message
Press Esc to close
Copyright © 2013 Crack o Hack & tweak STORE All Right Reserved