Archive for December 2012
When does the Cisco ASA IPS module inspect traffic?
Sure we can put an IPS module inside an Cisco ASA firewall but the first you may ask or will be asked is at what point does that traffic get inspected by the IPS Module? Which might not seem like a tough question but it can make you think if you got VPNs terminating on your ASA, does it inspect the traffic before encryption, after encryption, or is encrypted traffic bypassed? I did a post about the packet flow through a Cisco ASA some time ago and it did mention the IPS is involved after NATs, application inspection, and even ACLs however there was no mention of how encrypted VPN traffic.
Well, as it turns out the traffic is redirected to the IPS module after it enters the ASA on the ingress interface, the VPN traffic is decrypted, and the firewall inspection policies have been applied. Now for outgoing VPN traffic the IPS inspects that traffic and then it is encrypted and sent through the IPSec connection. Makes perfect sense.
Here is a quick visual from Cisco.com:
You’ll notice once the traffic enters from the outside interface, if it is VPN traffic it is then decrypted sent though the firewall policies and is then diverted to the IPS module. Once the IPS module has had a chance to inspect the traffic it is then sent back to the ASA to be sent out the inside interface.
Something I want to point out the IPS Modules work in 2 different modes, inline mode which is shown above where the traffic is sent through the IPS module and back into the ASA this mode may degrade throughput depending on the model of the module and the amount of traffic being inspected. We also have Promiscuous mode where the traffic is not sent directly though the IPS Module but the IPS module instead receives a copy of the traffic to inspect. The upside of promiscuous mode is the fact throughput is not effected however it is less secure than inline mode since the traffic sent to its destination at the same time it sent to the IPS module, the IPS module however can sent a RST packet ending connection or ‘shun’ the offensive IP address. When an address is ‘shunned’ any traffic from that source is dropped.
Here is a quick visual of promiscuous mode:
You can read more about the IPS ASA module inspection process here.
Checking out IPv6 addressing.
IPv6 definitely a subject that is being pushed more and more as time passes, with good reason it’s the way the internet is moving. I’m not going to cover the history of IPv6 and why we are going to start seeing IPv6 becoming more and more prevalent as time goes on, but we will take a quick high level view of some of the major differences of IPv6 addressing for example:
The address format, as we are well aware of IPv4 address are 32-bits long broken up into 4 octets that are 8-bits long. This format has been accepted so everyone is comfortable writing, memorizing, and understands this format.
IPv6 addresses on the other hand are 128-bits in length making it near impossible to continue the decimal format we all know and love in IPv4. That’s why the IPv6 address are represented as 32 Hex characters (compared to 128 decimal characters). This 32 character hex IPv6 address is then broken down into 8 sections of 4 hex characters separated by colons. So if we take a closer look at this break down each of those 8 sections represent 16-bits, and 16*8=128, so each individual character within the IPv6 address represents 4-bits and 32*4=128, so hopefully this paragraph clarifies the reasoning of why IPv6 address has been formatted this way. 32 character hex addresses will be easier to work with than a 128 character address. (Granted shifting gears from decimal to hex formatting will be tricky enough in itself).
So with this new address format, the next question you must have is how do we subnet with IPv6 addresses. Luckily for us subnetting (along with route summarizing) is done just like it is done with IPv4, granted with IPv6 we will be summarized in hex and not just decimal numbers. I’ll cover summarizing IPv6 in a future post.
Lets also touch quickly of the different type of addresses, perhaps the biggest change here is the fact that IPv6 has done away with the broadcast any IPv6 communication will be one of the below:
Link Local: The link local address is designated as FE80::/10 and will exist on every IPv6 interface the important thing to remember about the link local address is the fact it well never be used to communicate with hosts outside that local subnet, the link local address is only used for communication on its local subnet. This link local address is also used by OSPFv3 and EIGRP to establish neighbor adjacency and will be used as the next hop address.
Anycast: A new type of address, in which the same address is assigned to multiple nodes, when a packet is destined to this anycast address it will routed to nearest member of the anycast group.
Multicast: Treated similar to how it was treated in IPv4, and One-to-Many communication. (Multicast functionality has been improved upon since its implementation in IPv4). The key difference between Anycast and Multicast is the fact that the packet will be delivered to every device in the multicast group, where-as the Anycast packet is only delivered to the nearest device with the Anycast address assigned to it and not to every device with the Anycast addressed.
Even though these IPv6 are 32 hex characters we do have a few ways to cut down on the size of the actual IPv6 address to make it a little easier:
1. Leading zero’s can be removed so 2001:0db8:85a3:0042:0000:0000:0370:7334 could be typed as 2001:db8:85a3:42:0:0:370:7334 which helps by cutting out a few numbers but there is still another way we can make this address a bit more manageable.
2. Consecutive zero’s can excluded so 2001:db8:85a3:42:0000:0000:370:7334 could further be summarized to 2001:db8:85a3:42::370:7334, however this rule can only be used once so you can exclude one set of consecutive zero’s
CCIE or Null! 