Wednesday, October 26, 2011
A very good friend of mine has started a Web Hack Blog detailing common (and not so common) exploits that people are using to hack websites and most importantly how to protect yourself from them. Be sure to check it out and let him know that Peter from CCIE Rants sent you :p
The address is: http://www.webhackblog.com/
Tuesday, October 11, 2011
So I am a huge fan of the Cisco WAAS, I think that as a WAN accelerator it works extremely well and I especially like that you can get it as:
- A Module in the router
- Software-only solution on the router
- WAE Appliance
- WAE Server
So, a Cisco WAAS works by peering with another Cisco WAAS and doing very funky things to the TCP packets, including messing with the sequence numbers and the Syn/Syn-Ack headers, here's more detail straight from the Cisco Documentation:
"WAE devices automatically discover one another during the TCP three-way-handshake that occurs when two nodes establish a TCP connection. This discovery is accomplished by adding a small amount of data to the TCP options field (0x21) in the SYN, SYN/ACK, and ACK messages. This TCP option allows WAE devices to understand which WAE is on the other end of the link and allows the two to describe which optimization policies they would like to employ for the flow. If intermediate WAEs exist in the network path, they simply pass through flows that are being optimized by other WAEs. At the end of the auto-discovery process, the WAEs shift the sequence numbers in the TCP packets between the participating WAEs by increasing them to more than 2 billion, to mark the optimized segment of the connection. "
So what does this mean? It means that many firewalls such as checkpoint, ASA, Watchguard etc. etc. see these very strange TCP Packets and sequence numbers and think "this must be malicious so i should block the traffic" this can lead to major problems including the traffic simply not flowing.
Now, the solution on a cisco ASA Is to simply add:
to your global service policy, but the Watchguard, has no such option as far as I can tell (Do you know that it does? Leave a comment below!) The checkpoint apparently has a similiar way of avoiding this problem but it is a bit more complicated than the single line of config required for the ASA
So at this Point I am stuck.
I mention all of this to my friend Paul Tursan who points out that he seems to recall the cisco WAAS has a mode of operation where it encapsulates the traffic so you don't have to worry about these header modifications.
After some digging I discovered the mode is called Directed mode, and it works GREAT! Here is the details straight from the Cisco Documentation:
By default, WAAS transparently sets up new TCP connections to peer WAEs, which can cause firewall traversal issues when a WAAS device tries to optimize the traffic. If a WAE device is behind a firewall that prevents traffic optimization, you can use the directed mode of communicating to a peer WAE. In directed mode, all TCP traffic that is sent to a peer WAE is encapsulated in UDP, which allows a firewall to either bypass the traffic or inspect the traffic (by adding a UDP inspection rule).
The great thing about directed mode too is it is one of those protocols that as long as both ends support it only one end needs it enabled!
If a WAE at either end of a peer WAE connection specifies directed mode, and both WAEs support directed mode, then both WAEs use directed mode, even if one is not explicitly configured for directed mode. If a peer WAE does not support directed mode, then the peers pass through traffic unoptimized and each WAE creates a transaction log entry that notes the failed directed mode attempt.
Brilliant, Totally brilliant, now we can use our WAAS behind any firewall including ones we don't have direct control over as long as they allow through a certain UDP port that we specify
To configure directed mode, you can use the GUI (boo!) or login to the CLI and issue the following command: