Archive for February 2012
You don’t have to block ICMP completely.
This is something that I typically see all over the place, security administrators blocking the ICMP (Ping) protocol completely. Normally I am ok with that, after all ping is a troubleshooting tool and in some cases not the best troubleshooting tool to rely on. However, it’s when people think their network is more secure when they have blocked ICMP. The truth is you can actually allow the ICMP types that are required for troubleshooting purposes without compromising security. So let’s first consider what ICMP messages we typically use for troubleshooting:
- Echo Request – ICMP Type 8 Code 0
- Echo Replies – ICMP Type 0 Code 0
- Time Exceeded – ICMP Type 11 Code 0
- Fragment needed but DF bit set – ICMP Type 3 Code 4
Now we all know the echo request is the icmp packet from the host to the target, and the echo reply is response from target back to the host. The time exceeded packet is returned to the host when performing a traceroute. The fragment needed but DF bit set packet is used for path MTU discovery and can used to troubleshoot MTU issues, it basically replies back telling you the packet was dropped because it needed to be fragment but the DF (Do not fragment) bit was set on the packet so it could not be fragmented.
One ICMP parameter that should be blocked are ICMP fragments, fragmented ICMP packets can be used to cause DoS attacks. Remember ICMP packets typically send 64 bytes of data, so you should only see larger ICMP packets or expect fragments when testing MTU. (Other then that I can’t think of any other legit reason to see large ICMP packets). RFC 1858 goes pretty in depth concerning the danger of IP Fragments, it’s definitely worth a read.
Now here is a configuration snippet that accomplishes everything I discussed here:
Now if you want to learn about ICMP in greater detail check out RFC 792.
Let’s look at Generic Routing Encapsulation (GRE)
Generic Routing Encapsulation, not much to say about it, its generic right? Well, it’s pretty tough to find a network that does not utilize GRE tunnels in one way, shape, or form. Whether they are Encrypted GRE tunnels or GRE tunnels riding over IPSec tunnels for branch connectivity chances are GRE is being used somewhere in your network. After all GRE provides us with various features that traditional IPSec tunnels do not offer us. Such as allowing multicast traffic to traverse the tunnel providing us scalability with the use of a routing protocol. It provides us these features because of how it interacts with the IP packet, some people refer to GRE as a layer 3.5 protocol because of how it encapsulates the existing layer 3 IP packet.
Below we can see how GRE interacts with the IP packet:
Notice you can see two sets of IP address in that packet, the first set of IP addresses (10.0.0.1 & 10.0.0.2) are the tunnel addresses, the second set of addresses under the GRE header is the real data that was sent through the tunnel, and it’s simple ICMP echo request from 1.1.1.1 to 2.2.2.2.
And for a closer at the fields within the GRE encapsulation.
Also notice the protocol type at the bottom, GRE can be used to encapsulate more than just IP Packets SNA, IPX, Appletalk and quite a few others can also be encapsulated with GRE.
More information can be in RFC 2784 which explains the IP Packet fields in greater detail then I covered here.
Now, as far as how the configuration goes for a normal GRE tunnel goes it is fairly minimal:
However, there are a few things that can be a little rough to get the hang of at first. The first thing unlike physical interface you can declare tunnel interfaces from configuration mode and you can start at any number. Now like any other interface you will want to assign your tunnel its own IP address since these GRE tunnels operate around layer 3 they will need IP addresses on the same subnet so both tunnel interfaces can communicate. The only other requirements for configuring a GRE tunnel is specifying the tunnel source and the tunnel destination. The tunnel source can be a physical interface or an IP address just keep in mind the tunnel source needs to be local on the router. The tunnel destination is going to the address of the remote router you are terminating the tunnel to. You will want to make sure the tunnel source and tunnel destination configured have connectivity to each other since it is between these addresses the GRE tunnel will run over.
There you go, GRE in a nutshell!
CCIE or Null! 