Mad shout out to my good friends blog
Hi Guys
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/
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/
Cisco WAAS Directed mode, bypass any firewall Including Watchguard, Checkpoint or ASA
Hi Guys
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:
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. "
Source: http://docwiki.cisco.com/wiki/Cisco_WAAS_Troubleshooting_Guide_for_Release_4.1.3_and_Later_--_Understanding_the_WAAS_Architecture_and_Traffic_Flow
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:
inspect waas
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!
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v411/configuration/guide/network.html#Configuring_Directed_Mode
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. "
Source: http://docwiki.cisco.com/wiki/Cisco_WAAS_Troubleshooting_Guide_for_Release_4.1.3_and_Later_--_Understanding_the_WAAS_Architecture_and_Traffic_Flow
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:
inspect waas
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:
directed-mode enable
Great stuff!
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v411/configuration/guide/network.html#Configuring_Directed_Mode
The new video conferencing in CUCM 8.6
Hi Guys
As some of you may know from my previous blog post, the new version of CUCM 8.6 now supports Video Conferencing using just the PVDM3 DSP modules you have in your ISR G2 router! No need for an expensive MCU anymore, obviously there are some limitations but all in all it looks pretty nice.
When you go to add a new Conference Bridge, you will see some new options you might not have seen before! Here is details as to what they actually do:
As some of you may know from my previous blog post, the new version of CUCM 8.6 now supports Video Conferencing using just the PVDM3 DSP modules you have in your ISR G2 router! No need for an expensive MCU anymore, obviously there are some limitations but all in all it looks pretty nice.
When you go to add a new Conference Bridge, you will see some new options you might not have seen before! Here is details as to what they actually do:
Conferencing with Cisco Integrated Services Routers Generation 2
Cisco Integrated Services Routers Generation 2 (ISR G2) can be enabled to act as an IOS-based conference bridge that supports ad hoc and meet-me audio and video conferencing. DSP modules must be installed on the router to enable the router as a conference bridge.
Within Cisco Unified Communications Manger, the ISR G2 can be configured as one of three Conference Bridge Types:
•
•
•
(Source; http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/rel_notes/8_6_1/delta/delta.html#wp1601391)
Cheers!
Peter Revill, Dual CCIE #18371 Routing and Switching, Voice
http://ccierants.blogspot.com
Just a quick update on a previous post
Hey Guys
you may have seen my previous post, how to copy a image to an IOS router without having to actually have FTP access found here:
http://ccierants.blogspot.com/2011/06/great-way-to-copy-files-on-cisco.html
Just a super quick follow up, to enable this same feature to work on the ASA you just need this command here:
ssh scopy enable
Happy copying!
Peter Revill
Dual CCIE #18371 Routing and Switching, Voice
you may have seen my previous post, how to copy a image to an IOS router without having to actually have FTP access found here:
http://ccierants.blogspot.com/2011/06/great-way-to-copy-files-on-cisco.html
Just a super quick follow up, to enable this same feature to work on the ASA you just need this command here:
ssh scopy enable
Happy copying!
Peter Revill
Dual CCIE #18371 Routing and Switching, Voice
Subscribe to:
Posts (Atom)