Protecting Against Session Hijacking

Session hijacking is tricky business, and IDS monitoring is only a calculated guess based on assumptions of traffic patterns. The Cisco IDS did a good job of monitoring T-Sight session hijacking, but in several cases, alarms were missed and a few attacks went completely unnoticed. For example, if the original client never communicated during the hijacking or if a client connection was reset before ACK storms occurred, the 3250 signature would never be triggered, and the attack would go through unnoticed. This is not the fault of IDS; it is just that not enough suspicious traffic is sent to provide a reliable detection. Prevention is the only true protection, and IDS or a super-human watching Ethereal packet sniffing traffic like the Matrix screen saver are too unreliable for all possibilities.

Preventing session hijacking is quite difficult because of the nature of TCP and how easy it is to take over Layer 4 communication. However, by implementing encryption or signing protocols, you can affectively increase the difficultly level you need to accomplish successful hijacking. Table 6-2 shows several different solutions that you can use to help prevent or assist you in making hijacking more difficult.

Table 6-2. Preventative Solutions to Session Hijacking

Issue	Solution	Notes
Telnet, rlogin	OpenSSH or ssh (Secure Shell)	Use SSH to send encrypted data. If the session is hijacked, the attacker will have difficulty sending the correctly encrypted data.
FTP	sFTP	Using secure FTP can help minimize successful hijacking.
HTTP	SSL (Secure Socket Layer)	Using SSL can help minimize successful hijacking.
IP	IPSec	IPSec is an effective way to prevent hijacking. You should use it on an internal LAN whenever possible.
Any remote connection	VPN (encrypted)	Using PPTP, L2TP, or IPSec will always help dramatically and should always be used for remote connections.
SMB (Server Message Block)	SMB signing	The Microsoft-based system can enable signing of traffic, which can help minimize successful hijacking and should be turned on whenever possible.
Hub networks	Use switches	This provides only mild protection because attackers can employ ARP spoofing. Therefore, you should use port security in addition to switches, which maps your ports to specific MAC addresses and mitigates the risk of ARP spoofing.

Even implementing all the precautions in Table 6-2, a best practice is to limit the remote access and number of connections to your servers or clients whenever possible. Go by the rule of thumb, "If you don't think you need it, turn it off until someone screams." Basically, if you are locking down a system or firewall, open and provide permission to open only what you specifically need and from specific hosts. Do not allow all traffic from just any host. That does not prevent hijacking, but it lowers the likelihood.

Note

IPSec encryption has been around for quite some time, and Microsoft Windows 2000 and later fully support IPSec connections, which limits most hijacking attempts. However, people who are new to IPSec usually feel that its implementation is too cumbersome or difficult to roll out to all clients, thus leaving their underlying networks completely insecure, and a dream for hackers.