TacAck – My security journey!

Starting where we left off, the commands for the configuration of ICMP INSPECTION were listed. Now we need to test it and have a look at the “show” and “debug” commands output.

We have 3 test-cases :

TEST CASE 1 :Ping from R0 to fa0/0 interface of R2 ( Inside router to Outside router )

R0#ping 11.1.1.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 11.1.1.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 12/42/100 ms

As we see here, the ping is successful. This is because a session was created, and the echo-reply packets which were arriving on the outside interface of R1 were matched against the state table and they were permitted in.  To verify if the state Entry is created or not, as soon as we ping we use the

#show ip inspect sessions detail

This gives the details of the ICMP session created. The output is as follows.

R1#sh ip inspect sessions detail

Established Sessions

Session 6591161C (10.1.1.1:8)=>(11.1.1.2:0) icmp SIS_OPEN

Created 00:00:05, Last heard 00:00:05

ECHO request

Bytes sent (initiator:responder) [360:360]

In  SID 11.1.1.2[0:0]=>10.1.1.1[0:0] on ACL 101  (5 matches)

In  SID 0.0.0.0[0:0]=>10.1.1.1[3:3] on ACL 101

In  SID 0.0.0.0[0:0]=>10.1.1.1[11:11] on ACL 101

6591161C : The session ID .

Source : 10.1.1.1

Destination 11.1.1.2

Created 00:00:05, Last heard 00:00:05 : Means that 5 seconds have been elapsed since the last ping, therefore for this session to timeout it has only 5 more seconds remaining (10 sec timeout by default )

It shows the bytes sent, and also the matches on the ACL ( That’s the deny any any ACL placed on the outside interface of R1 , to block all stateless traffic from the outside to the inside ) . 5 matches because, 5 echo-requests go out for every ping statement by default.

Now to see the alerts and debug messages as and when they happen we use

#debug ip inspect icmp

R1#debug ip inspect icmp

INSPECT ICMP Inspection debugging is on

R1#

R1#*Mar  1 00:26:27.279: FIREWALL: ICMP Echo pkt 10.1.1.1 => 11.1.1.2

*Mar  1 00:26:27.283: FIREWALL: ICMP Echo pkt 10.1.1.1 => 11.1.1.2

*Mar  1 00:26:27.287: %FW-6-SESS_AUDIT_TRAIL_START: Start icmp session: initiato

r (10.1.1.1:8) — responder (11.1.1.2:0)

*Mar  1 00:26:27.363: FIREWALL: ICMP Echo Reply pkt 11.1.1.2 => 10.1.1.1

*Mar  1 00:26:27.411: FIREWALL: ICMP Echo pkt 10.1.1.1 => 11.1.1.2

*Mar  1 00:26:27.443: FIREWALL: ICMP Echo Reply pkt 11.1.1.2 => 10.1.1.1

*Mar  1 00:26:27.455: FIREWALL: ICMP Echo pkt 10.1.1.1 => 11.1.1.2

*Mar  1 00:26:27.467: FIREWALL: ICMP Echo Reply pkt 11.1.1.2 => 10.1.1.1

*Mar  1 00:26:27.475: FIREWALL: ICMP Echo pkt 10.1.1.1 => 11.1.1.2

*Mar  1 00:26:27.483: FIREWALL: ICMP Echo Reply pkt 11.1.1.2 => 10.1.1.1

*Mar  1 00:26:27.487: FIREWALL: ICMP Echo pkt 10.1.1.1 => 11.1.1.2

*Mar  1 00:26:27.495: FIREWALL: ICMP Echo Reply pkt 11.1.1.2 => 10.1.1.1

*Mar  1 00:26:37.487: %FW-6-SESS_AUDIT_TRAIL: Stop icmp session: initiator (10.1

.1.1:8) sent 360 bytes — responder (11.1.1.2:0) sent 360 bytes

As we see here , there are detailed debug messages for every ICMP packet which flows. Notice the last line of the debug. There’s an Audit Trail message which says “Stop icmp session”. This message indicates that the IOS is now closing the ICMP session that opened 10 seconds back along with the first echo-request. This duration is dictated by the session-timeout ( default : 10 s | can be forced to take another value in the  “#ip inspect name” command )

TEST CASE 2 : Ping from R2 to fa0/0 interface of R0

R2#ping 10.1.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:

U.U.U

Success rate is 0 percent (0/5)

We see that the Firewall sends an Unreachable message to R2. This is because there is no state matching the packets flowing into the firewall through the outside interface.

TEST CASE 3 : Traceroute

Alright, my bad. Cisco says that ICMP INSPECT supports not only echo-request and echo-reply, but also unreachable and time-exceeded ICMP messages. Therefore theoretically, traceroute from R0 to the fa0/0 address of R2 should work. However it only displays the first HOP ( the inside interface of R1 -> 10.1.1.12 ) and after that it’s all unreachable.

In fact we are able to see that R2 is returning the time-exceeded messages to R0, but R1 is blocking it. I honestly don’t know why this happening. If anyone does know, Please feel free to explain it in the comments section.

This is the traceroute output from R0

R0#traceroute 11.1.1.2

Type escape sequence to abort.

Tracing the route to 11.1.1.2

1 10.1.1.12 52 msec 40 msec 48 msec

2  *  *  *

3  *  *  *

4  *  *  *

5  *  *  *

Hope this is of atleast little help to you. Cheers!