Dealing with Encrypted Traffic and IPv6
The last-but-not-least important problem of
traffic capture is the spread of various traffic encryption mechanisms. Use of
virtual private networks (VPNs), either IPSec-based or otherwise, HTTPS Web
servers, and Secure Shell (SSH) became a common issue. From the point of view of
parties that participate in the encrypted interchange, traffic sniffing is
exactly what they try to avoid by using the encryption. And most of the
encryption protocols in use are very good in achieving data confidentiality, so
IDS is not able to look inside the encrypted interchange.
On the other hand, consider the following situation: you have a
Web server, which is used for e-commerce. Web clients talk to the server over
HTTPS connections, thus customer data is not exposed. But when an attacker
connects to your server over SSL (using an HTTPS connection), he is able to do
what he likes without any IDS noticing it, because all information exchange
between a Web browser on an attacker's computer and a Web server (an Apache
process, for example) is encrypted. IDS therefore becomes useless in a case like
this.
A similar situation arises when SSH is used for logging into hosts
on the network. SSH does what it is meant to do—protects traffic, including
passwords, from sniffing, disabling IDS capabilities from detecting any
wrongdoing. The same goes for VPNs—all encapsulated traffic is usually encrypted
between the client and a gateway or destination host.
Unfortunately, the situation cannot be helped much. There are two
workarounds for this, though.
-
SSH Nothing can be done to capture the
contents of an SSH session. You can have signatures that will be triggered upon
SSH-specific attacks (which use the SSH vulnerabilities, not the local
interactive exploits), but you cannot see, for example, somebody running a su command in an interactive session.
-
Site-to site VPN This case is a little
easier to handle. All you need to do is capture traffic behind your VPN gateway, after it has been received and
decrypted. Figure 9-12 illustrates this idea. If the VPN is of the host-to-host
type, where encryption and decryption occurs only on connection endpoints, then
we find ourselves in the same situation as with SSH and sniffing is not
possible.
Figure 9.12: Capturing Unencrypted Traffic Behind
a VPN Gateway
SSL connections also cannot be sniffed
directly. You can put an SSL accelerator device before the Web server, terminate
all incoming SSL connections on this device and let it interact with the server
over plain HTTP. The traffic passing on this unencrypted link can then be
redirected to the IDS . This setup is shown in Figure 9.13.
Finally, the increasing use of IP version 6 poses even more
problems for IDS. In their current state, almost no IDS can look inside an IPv6
packet going through, and just a few of them can detect basic information such
as source and destination IP addresses. One hopes, though, that once the use of
IPv6 becomes really widespread, its detection and monitoring will be
incorporated into the Cisco IDS solution.
Sections
Comments (0 posted)
Syndication
