Sunday, April 19, 2009

Convert Cisco dumps into Wireshark's pcap format

Lately i've been experimenting a lot with the hidden "dump" option of "debug ip packet", trying to decode various protocols. Yesterday i wrote a post about decoding the tacacs communication, something that required a little bit of awkward text editing.

Tonight i created the following perl program in order to make the whole process easier.


#!/opt/perl/bin/perl

# ciscodump2text v0.1
#
# Convert Cisco hex dump format (captured through the "debug ip packet dump" command)
# to a special text format that can then be fed into text2pcap
# so a pcap file for Wireshark can be created at the end
#
# Copyright (C) 2009 Tassos (http://ccie-in-3-months.blogspot.com)
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.

@packets = ();
$junk_line = 1;
$i = 0;

while (<>) {
$line = $_;

if ( $line =~ /^[0-9A-F]{8}: / ) {

$hex_part = substr($line, 10, 36);
$hex_part =~ s/\s//g;

if ( $junk_line ) {
$i++;
$packets[$i] = "";
$junk_line = 0;
};

$packets[$i] .= $hex_part;
} else {
$junk_line = 1;
}
}

for ($i = 1; $i <= @packets; $i++) {

if ( exists $packets[$i] ) {

for ( $j = 0; $j < length($packets[$i]); $j += 2 ) {
if ( $j == 0 ) {
printf "# Packet $i\n%08X", $j/2;
} elsif ( $j % 32 == 0 ) {
printf " #\n%08X", $j/2;
}
print " ".substr($packets[$i], $j, 2);
}

print " #\n";
}
}

print "\n";


You just give it the cisco dump as input (only lines starting with an 8-char hex number are processed, so you don't have to worry about other lines) and it produces a text file that can be fed into text2pcap. Then you give text2pcap the new text file as input and it produces a pcap file as output, which can be opened with Wireshark.

i.e. we want to convert the following log produced by "debug ip packet dump" to a text file compatible with the "text2pcap" program.

*Apr 18 18:19:51.887: FIBipv4-packet-proc: route packet from (local) src 10.10.10.9 dst 10.10.10.10
*Apr 18 18:19:51.887: FIBipv4-packet-proc: packet routing succeeded
*Apr 18 18:19:51.887: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 80, sending
*Apr 18 18:19:51.887: TCP src=20596, dst=49, seq=1187787226, ack=3815757335, win=4128 ACK
082D17D0: 45000050 678B0000 E..Pg...
082D17E0: FF062BF6 0A0A0A09 0A0A0A0A 50740031 ..+v........Pt.1
082D17F0: 46CC31DA E36FD617 50101020 9F960000 FL1ZcoV.P.. ....
082D1800: C0010100 99648E6A 0000001C B8145EC8 @....d.j....8.^H
082D1810: A8B3C2B9 3EC12A1F AA40DE66 D7429C89 (3B9>A*.*@^fWB..
082D1820: 0BF911F3 C7249F5F .y.sG$._
*Apr 18 18:19:51.887: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 80, sending full packet
*Apr 18 18:19:51.887: TCP src=20596, dst=49, seq=1187787226, ack=3815757335, win=4128 ACK
082D17C0: 0200 4C4F4F50 ..LOOP
082D17D0: CA000CB8 00060800 45000050 678B0000 J..8....E..Pg...
082D17E0: FF062BF6 0A0A0A09 0A0A0A0A 50740031 ..+v........Pt.1
082D17F0: 46CC31DA E36FD617 50101020 9F960000 FL1ZcoV.P.. ....
082D1800: C0010100 99648E6A 0000001C B8145EC8 @....d.j....8.^H
082D1810: A8B3C2B9 3EC12A1F AA40DE66 D7429C89 (3B9>A*.*@^fWB..
082D1820: 0BF911F3 C7249F5F .y.sG$._
*Apr 18 18:19:52.103: FIBipv4-packet-proc: route packet from (local) src 10.10.10.9 dst 10.10.10.10
*Apr 18 18:19:52.107: FIBipv4-packet-proc: packet routing succeeded
*Apr 18 18:19:52.107: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 40, sending
*Apr 18 18:19:52.111: TCP src=20596, dst=49, seq=1187787266, ack=3815757363, win=4100 ACK
080014D0: 45000028 678C0000 E..(g...
080014E0: FF062C1D 0A0A0A09 0A0A0A0A 50740031 ..,.........Pt.1
080014F0: 46CC3202 E36FD633 50101004 F4920000 FL2.coV3P...t...
08001500:
*Apr 18 18:19:52.127: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 40, sending full packet
*Apr 18 18:19:52.131: TCP src=20596, dst=49, seq=1187787266, ack=3815757363, win=4100 ACK
080014C0: 0200 4C4F4F50 ..LOOP
080014D0: CA000CB8 00060800 45000028 678C0000 J..8....E..(g...
080014E0: FF062C1D 0A0A0A09 0A0A0A0A 50740031 ..,.........Pt.1
080014F0: 46CC3202 E36FD633 50101004 F4920000 FL2.coV3P...t...
08001500:


First we save it in a ascii/text file (i.e. "test.dump") and we give it as input to the "ciscodump2text" program.

tassos$ ciscodump2text test.dump > test.text

The created "test.text" file contains the following :

# Packet 1
00000000 45 00 00 50 67 8B 00 00 FF 06 2B F6 0A 0A 0A 09 #
00000010 0A 0A 0A 0A 50 74 00 31 46 CC 31 DA E3 6F D6 17 #
00000020 50 10 10 20 9F 96 00 00 C0 01 01 00 99 64 8E 6A #
00000030 00 00 00 1C B8 14 5E C8 A8 B3 C2 B9 3E C1 2A 1F #
00000040 AA 40 DE 66 D7 42 9C 89 0B F9 11 F3 C7 24 9F 5F #
# Packet 2
00000000 02 00 4C 4F 4F 50 CA 00 0C B8 00 06 08 00 45 00 #
00000010 00 50 67 8B 00 00 FF 06 2B F6 0A 0A 0A 09 0A 0A #
00000020 0A 0A 50 74 00 31 46 CC 31 DA E3 6F D6 17 50 10 #
00000030 10 20 9F 96 00 00 C0 01 01 00 99 64 8E 6A 00 00 #
00000040 00 1C B8 14 5E C8 A8 B3 C2 B9 3E C1 2A 1F AA 40 #
00000050 DE 66 D7 42 9C 89 0B F9 11 F3 C7 24 9F 5F #
# Packet 3
00000000 45 00 00 28 67 8C 00 00 FF 06 2C 1D 0A 0A 0A 09 #
00000010 0A 0A 0A 0A 50 74 00 31 46 CC 32 02 E3 6F D6 33 #
00000020 50 10 10 04 F4 92 00 00 #
# Packet 4
00000000 02 00 4C 4F 4F 50 CA 00 0C B8 00 06 08 00 45 00 #
00000010 00 28 67 8C 00 00 FF 06 2C 1D 0A 0A 0A 09 0A 0A #
00000020 0A 0A 50 74 00 31 46 CC 32 02 E3 6F D6 33 50 10 #
00000030 10 04 F4 92 00 00 #


Then, we convert this new text file into a pcap file by using the "text2pcap" program, which is included with Wireshark.

tassos$ text2pcap.exe" -d test.text test.pcap
Input from: test.text
Output to: test.pcap
Start new packet
Start new packet
Wrote packet of 80 bytes at 0
Start new packet
Wrote packet of 94 bytes at 80
Start new packet
Wrote packet of 40 bytes at 174
Wrote packet of 54 bytes at 214

-------------------------
Read 4 potential packets, wrote 4 packets


The resulting pcap file "test.pcap" can be opened for further processing with Wireshark.

That way you can very easily create pcap files of almost everything happening on your router.

Notes : The "dump" option is supported since 12.0 IOS. Latest IOS includes EPC, which makes the whole capture & convert-to-pcap process much easier.

PS : I'm not a very good perl programmer (although i have written a lot of custom perl scripts for my job), so someone playing with perl for years will probably produce a more compact "perlish" code. I just tried to interpret my logic into perl code.

Saturday, April 18, 2009

Decoding login credentials regardless of access method

In a previous post of mine i had described how easy it is to find the login credentials of any user, as long as you have enable access on the router where the user is trying to login and the user is using telnet.

You all know that ssh is a better, far more secure, access method since the whole communication is encrypted.

You also know that usually an external aaa server is used in order to allow privileged access in routers. As an aaa server you can use a tacacs+ or a radius server, with tacacs+ being the preferred choice because it also provides authorization as a different operation and encryption of the full payload.

What would you say if you could capture the aaa server's traffic from inside the router itself, decode it using the tacacs/radius key stored in the router's configuration and find the credentials of everyone logging into the router, regardless of the user's access method? You don't even need any sniffing (on the wire) to take place.

Here is how...

Let's suppose we have a router which is using tacacs+ for its login authentication and we're trying to find the login credentials of someone logging into it using ssh (the access method is irrelevant!).

First you create an acl matching the packets you want to capture :


access-list 199 permit tcp any host 10.10.10.10 eq tacacs

10.10.10.10 is the tacacs+ server you're trying to monitor and tacacs (tcp/49) is the port the server is listening to.

If you don't want to look for it into the config (with "sh run"), the following will give you the details.

R1#sh tacacs | i Server
Tacacs+ Server : 10.10.10.10/49

Then you enable the hidden "dump" option of the "debug ip packet" command and you wait for someone to login.

R1#debug ip packet detail 199 dump
IP packet debugging is on (detailed) (dump) for access list 199

Keep in mind that if you use tacacs for many kinds of authentication/authorization/accounting you'll get a lot of output, so try to capture as much as possible (generally try to have a large buffer).

You're interested in lines containing "C001", with C0 defining the TACACS+ version and 01 defining "Authentication". According to the tacacs+ draft rfc :
TAC_PLUS_MAJOR_VER=0xC
TAC_PLUS_MINOR_VER_DEFAULT=0x0
TAC_PLUS_AUTHEN=0x01


R1#sh log | i C001
082D1800: C0010100 99648E6A 0000001C B8145EC8 @....d.j....8.^H
082D1800: C0010100 99648E6A 0000001C B8145EC8 @....d.j....8.^H
082D1120: C0010300 99648E6A 00000012 0EF88E37 @....d.j.....x.7
082D1120: C0010300 99648E6A 00000012 0EF88E37 @....d.j.....x.7

So you got 4 packets with tacacs authentication data, with the first 2 being the same and the last 2 being again the same.

Now do a "sh log", trying to locate the packets with the above found hex offsets (hex offset is the very first hex number at the left of each line).


R1#sh log
Syslog logging: enabled (0 messages dropped, 0 messages rate-limited,
0 flushes, 0 overruns, xml disabled, filtering disabled)

No Active Message Discriminator.



No Inactive Message Discriminator.


Console logging: level debugging, 7110 messages logged, xml disabled,
filtering disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 781 messages logged, xml disabled,
filtering disabled
Logging Exception size (8192 bytes)
Count and timestamp logging messages: disabled
Persistent logging: disabled

No active filter modules.

ESM: 0 messages dropped

Trap logging: level informational, 57 message lines logged

Log Buffer (512000 bytes):

*Apr 18 18:19:51.779: FIBipv4-packet-proc: route packet from (local) src 10.10.10.9 dst 10.10.10.10
*Apr 18 18:19:51.783: FIBipv4-packet-proc: packet routing succeeded
*Apr 18 18:19:51.783: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 44, sending
*Apr 18 18:19:51.787: TCP src=20596, dst=49, seq=1187787225, ack=0, win=4128 SYN
080019D0: 4500002C 67890000 E..,g...
080019E0: FF062C1C 0A0A0A09 0A0A0A0A 50740031 ..,.........Pt.1
080019F0: 46CC31D9 00000000 60021020 96950000 FL1Y....`.. ....
08001A00: 020405B4 ...4
*Apr 18 18:19:51.803: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 44, sending full packet
*Apr 18 18:19:51.807: TCP src=20596, dst=49, seq=1187787225, ack=0, win=4128 SYN
080019C0: 0200 4C4F4F50 ..LOOP
080019D0: CA000CB8 00060800 4500002C 67890000 J..8....E..,g...
080019E0: FF062C1C 0A0A0A09 0A0A0A0A 50740031 ..,.........Pt.1
080019F0: 46CC31D9 00000000 60021020 96950000 FL1Y....`.. ....
08001A00: 020405B4 ...4
*Apr 18 18:19:51.847: FIBipv4-packet-proc: route packet from (local) src 10.10.10.9 dst 10.10.10.10
*Apr 18 18:19:51.847: FIBipv4-packet-proc: packet routing succeeded
*Apr 18 18:19:51.851: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 40, sending
*Apr 18 18:19:51.855: TCP src=20596, dst=49, seq=1187787226, ack=3815757335, win=4128 ACK
08001250: 45000028 678A0000 E..(g...
08001260: FF062C1F 0A0A0A09 0A0A0A0A 50740031 ..,.........Pt.1
08001270: 46CC31DA E36FD617 50101020 F4BA0000 FL1ZcoV.P.. t:..
08001280:
*Apr 18 18:19:51.871: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 40, sending full packet
*Apr 18 18:19:51.875: TCP src=20596, dst=49, seq=1187787226, ack=3815757335, win=4128 ACK
08001240: 0200 4C4F4F50 ..LOOP
08001250: CA000CB8 00060800 45000028 678A0000 J..8....E..(g...
08001260: FF062C1F 0A0A0A09 0A0A0A0A 50740031 ..,.........Pt.1
08001270: 46CC31DA E36FD617 50101020 F4BA0000 FL1ZcoV.P.. t:..
08001280:
*Apr 18 18:19:51.887: FIBipv4-packet-proc: route packet from (local) src 10.10.10.9 dst 10.10.10.10
*Apr 18 18:19:51.887: FIBipv4-packet-proc: packet routing succeeded
*Apr 18 18:19:51.887: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 80, sending
*Apr 18 18:19:51.887: TCP src=20596, dst=49, seq=1187787226, ack=3815757335, win=4128 ACK
082D17D0: 45000050 678B0000 E..Pg...
082D17E0: FF062BF6 0A0A0A09 0A0A0A0A 50740031 ..+v........Pt.1
082D17F0: 46CC31DA E36FD617 50101020 9F960000 FL1ZcoV.P.. ....
082D1800: C0010100 99648E6A 0000001C B8145EC8 @....d.j....8.^H
082D1810: A8B3C2B9 3EC12A1F AA40DE66 D7429C89 (3B9>A*.*@^fWB..
082D1820: 0BF911F3 C7249F5F .y.sG$._

*Apr 18 18:19:51.887: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 80, sending full packet
*Apr 18 18:19:51.887: TCP src=20596, dst=49, seq=1187787226, ack=3815757335, win=4128 ACK
082D17C0: 0200 4C4F4F50 ..LOOP
082D17D0: CA000CB8 00060800 45000050 678B0000 J..8....E..Pg...
082D17E0: FF062BF6 0A0A0A09 0A0A0A0A 50740031 ..+v........Pt.1
082D17F0: 46CC31DA E36FD617 50101020 9F960000 FL1ZcoV.P.. ....
082D1800: C0010100 99648E6A 0000001C B8145EC8 @....d.j....8.^H
082D1810: A8B3C2B9 3EC12A1F AA40DE66 D7429C89 (3B9>A*.*@^fWB..
082D1820: 0BF911F3 C7249F5F .y.sG$._

*Apr 18 18:19:52.103: FIBipv4-packet-proc: route packet from (local) src 10.10.10.9 dst 10.10.10.10
*Apr 18 18:19:52.107: FIBipv4-packet-proc: packet routing succeeded
*Apr 18 18:19:52.107: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 40, sending
*Apr 18 18:19:52.111: TCP src=20596, dst=49, seq=1187787266, ack=3815757363, win=4100 ACK
080014D0: 45000028 678C0000 E..(g...
080014E0: FF062C1D 0A0A0A09 0A0A0A0A 50740031 ..,.........Pt.1
080014F0: 46CC3202 E36FD633 50101004 F4920000 FL2.coV3P...t...
08001500:
*Apr 18 18:19:52.127: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 40, sending full packet
*Apr 18 18:19:52.131: TCP src=20596, dst=49, seq=1187787266, ack=3815757363, win=4100 ACK
080014C0: 0200 4C4F4F50 ..LOOP
080014D0: CA000CB8 00060800 45000028 678C0000 J..8....E..(g...
080014E0: FF062C1D 0A0A0A09 0A0A0A0A 50740031 ..,.........Pt.1
080014F0: 46CC3202 E36FD633 50101004 F4920000 FL2.coV3P...t...
08001500:
*Apr 18 18:20:17.535: FIBipv4-packet-proc: route packet from (local) src 10.10.10.9 dst 10.10.10.10
*Apr 18 18:20:17.535: FIBipv4-packet-proc: packet routing succeeded
*Apr 18 18:20:17.539: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 70, sending
*Apr 18 18:20:17.543: TCP src=20596, dst=49, seq=1187787266, ack=3815757363, win=4100 ACK
082D10F0: 45000046 678D0000 E..Fg...
082D1100: FF062BFE 0A0A0A09 0A0A0A0A 50740031 ..+~........Pt.1
082D1110: 46CC3202 E36FD633 50101004 FF710000 FL2.coV3P....q..
082D1120: C0010300 99648E6A 00000012 0EF88E37 @....d.j.....x.7
082D1130: 3042C304 0358A011 C3A3FD82 1519 0BC..X .C#}...

*Apr 18 18:20:17.563: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 70, sending full packet
*Apr 18 18:20:17.567: TCP src=20596, dst=49, seq=1187787266, ack=3815757363, win=4100 ACK
082D10E0: 0200 4C4F4F50 ..LOOP
082D10F0: CA000CB8 00060800 45000046 678D0000 J..8....E..Fg...
082D1100: FF062BFE 0A0A0A09 0A0A0A0A 50740031 ..+~........Pt.1
082D1110: 46CC3202 E36FD633 50101004 FF710000 FL2.coV3P....q..
082D1120: C0010300 99648E6A 00000012 0EF88E37 @....d.j.....x.7
082D1130: 3042C304 0358A011 C3A3FD82 1519 0BC..X .C#}...

*Apr 18 18:20:17.607: FIBipv4-packet-proc: route packet from (local) src 10.10.10.9 dst 10.10.10.10
*Apr 18 18:20:17.611: FIBipv4-packet-proc: packet routing succeeded
*Apr 18 18:20:17.615: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 40, sending
*Apr 18 18:20:17.619: TCP src=20596, dst=49, seq=1187787296, ack=3815757382, win=4082 ACK
08001C50: 45000028 678E0000 E..(g...
08001C60: FF062C1B 0A0A0A09 0A0A0A0A 50740031 ..,.........Pt.1
08001C70: 46CC3220 E36FD646 50100FF2 F4730000 FL2 coVFP..rts..
08001C80:
*Apr 18 18:20:17.623: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 40, sending full packet
*Apr 18 18:20:17.627: TCP src=20596, dst=49, seq=1187787296, ack=3815757382, win=4082 ACK
08001C40: 0200 4C4F4F50 ..LOOP
08001C50: CA000CB8 00060800 45000028 678E0000 J..8....E..(g...
08001C60: FF062C1B 0A0A0A09 0A0A0A0A 50740031 ..,.........Pt.1
08001C70: 46CC3220 E36FD646 50100FF2 F4730000 FL2 coVFP..rts..
08001C80:
*Apr 18 18:20:17.643: FIBipv4-packet-proc: route packet from (local) src 10.10.10.9 dst 10.10.10.10
*Apr 18 18:20:17.647: FIBipv4-packet-proc: packet routing succeeded
*Apr 18 18:20:17.647: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 40, sending
*Apr 18 18:20:17.651: TCP src=20596, dst=49, seq=1187787296, ack=3815757382, win=4082 ACK PSH FIN
082D2590: 45000028 678F0000 E..(g...
082D25A0: FF062C1A 0A0A0A09 0A0A0A0A 50740031 ..,.........Pt.1
082D25B0: 46CC3220 E36FD646 50190FF2 F46A0000 FL2 coVFP..rtj..
082D25C0:
*Apr 18 18:20:17.655: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 40, sending full packet
*Apr 18 18:20:17.655: TCP src=20596, dst=49, seq=1187787296, ack=3815757382, win=4082 ACK PSH FIN
082D2580: 0200 4C4F4F50 ..LOOP
082D2590: CA000CB8 00060800 45000028 678F0000 J..8....E..(g...
082D25A0: FF062C1A 0A0A0A09 0A0A0A0A 50740031 ..,.........Pt.1
082D25B0: 46CC3220 E36FD646 50190FF2 F46A0000 FL2 coVFP..rtj..
082D25C0:


copy these 4 packets into a text file

082D17D0: 45000050 678B0000 E..Pg...
082D17E0: FF062BF6 0A0A0A09 0A0A0A0A 50740031 ..+v........Pt.1
082D17F0: 46CC31DA E36FD617 50101020 9F960000 FL1ZcoV.P.. ....
082D1800: C0010100 99648E6A 0000001C B8145EC8 @....d.j....8.^H
082D1810: A8B3C2B9 3EC12A1F AA40DE66 D7429C89 (3B9>A*.*@^fWB..
082D1820: 0BF911F3 C7249F5F .y.sG$._

082D17C0: 0200 4C4F4F50 ..LOOP
082D17D0: CA000CB8 00060800 45000050 678B0000 J..8....E..Pg...
082D17E0: FF062BF6 0A0A0A09 0A0A0A0A 50740031 ..+v........Pt.1
082D17F0: 46CC31DA E36FD617 50101020 9F960000 FL1ZcoV.P.. ....
082D1800: C0010100 99648E6A 0000001C B8145EC8 @....d.j....8.^H
082D1810: A8B3C2B9 3EC12A1F AA40DE66 D7429C89 (3B9>A*.*@^fWB..
082D1820: 0BF911F3 C7249F5F .y.sG$._

082D10F0: 45000046 678D0000 E..Fg...
082D1100: FF062BFE 0A0A0A09 0A0A0A0A 50740031 ..+~........Pt.1
082D1110: 46CC3202 E36FD633 50101004 FF710000 FL2.coV3P....q..
082D1120: C0010300 99648E6A 00000012 0EF88E37 @....d.j.....x.7
082D1130: 3042C304 0358A011 C3A3FD82 1519 0BC..X .C#}...

082D10E0: 0200 4C4F4F50 ..LOOP
082D10F0: CA000CB8 00060800 45000046 678D0000 J..8....E..Fg...
082D1100: FF062BFE 0A0A0A09 0A0A0A0A 50740031 ..+~........Pt.1
082D1110: 46CC3202 E36FD633 50101004 FF710000 FL2.coV3P....q..
082D1120: C0010300 99648E6A 00000012 0EF88E37 @....d.j.....x.7
082D1130: 3042C304 0358A011 C3A3FD82 1519 0BC..X .C#}...

If you have a detailed look at the above packet offsets/contents, you'll notice that

Packet 1 is a sub-packet of Packet 2 (offsets 082D17E0 - 082D1820 are common)
Packet 3 is a sub-packet of Packet 4 (offsets 082D1100 - 082D1130 are common)

Their difference is that Packet 1 and Packet 3 do not contain the L2 header. The debug output shows these packets as "sending" vs "sending full packet" which are the full packets.

Since it's better to have the full packet, erase the sub-packets (packets that do not contain the L2 header = packets with the least data).

So you end up with the following 2 full packets:


082D17C0: 0200 4C4F4F50 ..LOOP
082D17D0: CA000CB8 00060800 45000050 678B0000 J..8....E..Pg...
082D17E0: FF062BF6 0A0A0A09 0A0A0A0A 50740031 ..+v........Pt.1
082D17F0: 46CC31DA E36FD617 50101020 9F960000 FL1ZcoV.P.. ....
082D1800: C0010100 99648E6A 0000001C B8145EC8 @....d.j....8.^H
082D1810: A8B3C2B9 3EC12A1F AA40DE66 D7429C89 (3B9>A*.*@^fWB..
082D1820: 0BF911F3 C7249F5F .y.sG$._

082D10E0: 0200 4C4F4F50 ..LOOP
082D10F0: CA000CB8 00060800 45000046 678D0000 J..8....E..Fg...
082D1100: FF062BFE 0A0A0A09 0A0A0A0A 50740031 ..+~........Pt.1
082D1110: 46CC3202 E36FD633 50101004 FF710000 FL2.coV3P....q..
082D1120: C0010300 99648E6A 00000012 0EF88E37 @....d.j.....x.7
082D1130: 3042C304 0358A011 C3A3FD82 1519 0BC..X .C#}...


Now, you have to convert the above 2 packets into a format that Wireshark can understand. There is an extra program you'll find in your Wireshark folder, called "text2pcap" that can help you in that. But it requires a specific input format.

First, put a space between every pair of hex numbers :


082D17C0: 02 00 4C 4F 4F 50 ..LOOP
082D17D0: CA 00 0C B8 00 06 08 00 45 00 00 50 67 8B 00 00 J..8....E..Pg...
082D17E0: FF 06 2B F6 0A 0A 0A 09 0A 0A 0A 0A 50 74 00 31 ..+v........Pt.1
082D17F0: 46 CC 31 DA E3 6F D6 17 50 10 10 20 9F 96 00 00 FL1ZcoV.P.. ....
082D1800: C0 01 01 00 99 64 8E 6A 00 00 00 1C B8 14 5E C8 @....d.j....8.^H
082D1810: A8 B3 C2 B9 3E C1 2A 1F AA 40 DE 66 D7 42 9C 89 (3B9>A*.*@^fWB..
082D1820: 0B F9 11 F3 C7 24 9F 5F .y.sG$._

082D10E0: 02 00 4C 4F 4F 50 ..LOOP
082D10F0: CA 00 0C B8 00 06 08 00 45 00 00 46 67 8D 00 00 J..8....E..Fg...
082D1100: FF 06 2B FE 0A 0A 0A 09 0A 0A 0A 0A 50 74 00 31 ..+~........Pt.1
082D1110: 46 CC 32 02 E3 6F D6 33 50 10 10 04 FF 71 00 00 FL2.coV3P....q..
082D1120: C0 01 03 00 99 64 8E 6A 00 00 00 12 0E F8 8E 37 @....d.j.....x.7
082D1130: 30 42 C3 04 03 58 A0 11 C3 A3 FD 82 15 19 0BC..X .C#}...

Then remove the ":" from the hex offset and recalculate each packet's offsets starting from 00000000. Every row is 10 (hex) bytes, so it gets easier after you find the offset for the 2nd row.

00000000 02 00 4C 4F 4F 50 ..LOOP
00000006 CA 00 0C B8 00 06 08 00 45 00 00 50 67 8B 00 00 J..8....E..Pg...
00000016 FF 06 2B F6 0A 0A 0A 09 0A 0A 0A 0A 50 74 00 31 ..+v........Pt.1
00000026 46 CC 31 DA E3 6F D6 17 50 10 10 20 9F 96 00 00 FL1ZcoV.P.. ....
00000036 C0 01 01 00 99 64 8E 6A 00 00 00 1C B8 14 5E C8 @....d.j....8.^H
00000046 A8 B3 C2 B9 3E C1 2A 1F AA 40 DE 66 D7 42 9C 89 (3B9>A*.*@^fWB..
00000056 0B F9 11 F3 C7 24 9F 5F .y.sG$._

00000000 02 00 4C 4F 4F 50 ..LOOP
00000006 CA 00 0C B8 00 06 08 00 45 00 00 46 67 8D 00 00 J..8....E..Fg...
00000016 FF 06 2B FE 0A 0A 0A 09 0A 0A 0A 0A 50 74 00 31 ..+~........Pt.1
00000026 46 CC 32 02 E3 6F D6 33 50 10 10 04 FF 71 00 00 FL2.coV3P....q..
00000036 C0 01 03 00 99 64 8E 6A 00 00 00 12 0E F8 8E 37 @....d.j.....x.7
00000046 30 42 C3 04 03 58 A0 11 C3 A3 FD 82 15 19 0BC..X .C#}...

Pass the above file as input to the text2pcap program and save the output to a pcap file. If everything went fine, you should see the following:

C:\Program Files\Wireshark>text2pcap -d tacacs-packets.txt tacacs-packets.pcap
Input from: tacacs-packets.txt
Output to: tacacs-packets.pcap
Start new packet
Start new packet
Wrote packet of 94 bytes at 0
Wrote packet of 84 bytes at 94

-------------------------
Read 2 potential packets, wrote 2 packets

Now, open the "tacacs-packets.pcap" in Wireshark and check the output:


You need the encryption key used by the tacacs in order to decrypt the tacacs part.


tacacs-server key 7 023224582B051C121F4D1B4A113C4112

If the tacacs key is encrypted in the configuration (like the above), then you can decrypt it by configuring it under a dummy key-chain (something that most of you should know already).

key chain test
key 1
key-string 7 023224582B051C121F4D1B4A113C4112


R1#sh key chain test
Key-chain test:
key 1 -- text "T@c@csS3cr3tK3y"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]

Open Edit->Preferences in Wireshark and move to Protocol->Tacacs.
Fill in the tacacs key you found and voila! Next to the "User:" field you'll find what you're looking for.





The sequence numbers will help you identify which one is the username and which one is the password (normally the username comes first).

Notes :
You can use the above procedure in order to convert any Cisco "debug ip packet dump" output into the pcap format.

Update 19-Apr-2009 : If you don't want to mess with manual text editing, i have created a perl script which converts the dump output into a text2pcap compatible format.

Friday, April 3, 2009

What is a PER (Product Enhancement Request)?

According to your votes in the recent poll, i ended up having some interesting results.



1) only 1 person has been successful in his/her PER (i would really like to know the company he/she works for and what the PER was about)
2) 8 people have submitted a PER, but it wasn't implemented (i'm one of them)
4) 83% do not know what a PER is

While some other companies have PER open for public with online forms, Cisco likes to keep it internal. Even worse, you cannot watch its progress, unless you manage to persuade TAC to open a bug (as enhancement) and then tell your account team to attach a PER to this bug.

So, what is it about?

Your Cisco account team has access to the Product Enhancement Request (PER) tool. With this tool, the Cisco account team can submit a PER on your behalf, always with a "good" business case behind it. Generally, Product Enhancement Requests are things that you'd like to have on your devices, but are not happening, because there isn't any need for them (due to various reasons).

According to Cisco procedures, your Sales/Account Team needs to open and follow up on the PER request. It then goes to the Business Unit (BU) and gets reviewed and if approved it is prioritized to be implemented.

Judging from my experience and your votes to the poll, you'd better have a very good business case if you want to see you request being implemented. i.e. if you work for NTT, DT, BT, AT&T, then this is by default a very good business case. Otherwise you'll have to try very hard to convince the BU to accept your request. Also, if you have (or intend to buy) hundreds or thousands of cisco boxes, then this is also a very good business case. If you don't belong to one of the above categories, then the BU might say that your request is a corner case; don't believe them. They usually mean that your business is a corner business.

To be honest, i have to somehow agree with the above concept. Companies that bring a lot of money to Cisco, should have their requests prioritized. After all, they are the most important customers.

BUT

I think there are some things that should be considered too instead of relaying solely on business needs brought onto surface by big customers. I don't know how many of the following cases refer to others too, but this is my just-before-opening-a-PER experience until now:

1) Redistribution of FHRP (First Hop Redundancy Protocol) IPs into routing protocols does not take into account the state of active/standby interfaces. That means you cannot (easily) influence the downstream direction of packets.

2) Although there have been at least 3 years since ethernet has replaced ATM in the broadband edge, Cisco's MIBs do not support counting of PPPoE sessions per ethernet subinterface.

3) There aren't any cvpdnTunnelBytes* 64bit counters (used in VPDN tunnels). When gigabit and tengigabit interfaces are becoming common in all broadband platforms, some counters insist on 32bit.

4) The PPP idle timer feature ("ip idle-group") which is supposed to be an enhancement made specifically for LAC/LNS scenarios, was working fine in 12.3x, but got removed in the broadband 12.2SB release (on 7200 & c10k platforms). Even the new broadband platform (ASR1000) doesn't have it.

5) There is a hardcoded limit (for no apparent reason) of 8 UNI ports that can use community vlans on the ME-3400G-12CS. If you need more, you have to turn them into NNI.

6) If you're using an aaa server for system accounting, then in case of a problem on your aaa server, you'll have to wait for 2-3 mins to login into your routers, regardless of the aaa method used for your login.

7) "Configuration Change Notification and Logging" keeps a record of all per-user configurations applied through radius (i.e. ACLs) under a subscriber vtemplate.

All of the above cases got pwned by Cisco with the excuse "a PER must be submitted in order to be implemented". Of course, on some of them this is true, because they are new things and a lot of work needs to be done. Some others seem more like a misbehavior that needs to be fixed. According to Cisco, everything that adheres to the documentation cannot be considered a bug. So, keep that in mind.

I understand that my current needs are different from many others, but the possibility of someone else having the same needs can't always be zero.

I would like very much to see all submitted PERs in a poll by Cisco, so other customers could choose what they would like too. I'm sure that there are many good and simple ideas submitted as PERs that can be useful to everyone, but they are hidden somewhere away from the public.


PS: Since i don't have any actual internal info, a lot of my talk about the PER process might not be accurate. Please feel free to correct me.

 
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Greece License.