Matching Strings with Flexible Packet Matching

Last night I had the opportunity to experiment a bit with Cisco’s Flexible Packet matching.  What really happened was I was going through IPExpert’s Security Workbook 7a and found a task that I thought would fit the bill for something that was posted on Group Study a couple of weeks ago.  I took an hour or so messing around with the two scenarios and it really helped me understand how Cisco’s new and very special “class and policy type access-control” works. I really think getting sidetracked helped me understand this flexible way of parsing traffic.  This post, while admittedly crude, will show how easy it is to match on strings inside a packet.

The challenge from Group study was to filter SSH Version 2 from a switch, without any type of IPS, and permitting all other traffic.  The solution below can be put together however an individual chooses.  Additionally, I’m sure there are better ways to accomplish this by loading protocols.  However, this is good information and helps understand the thought process of the “access-control” policy-maps and class-maps.

I will start out by telling the good, the bad and the ugly.

The good–I have been able to do this with policy-map type of access-control and it is quite simple.

The bad–I had some inconsistencies when making changes.  I found the best result to be when I rebuild the policy map with any changes, and reapply to the interface.  Also, I can never seem to get it to match 0x0a that immediately follows the SSH Server identification string.  This would even further reduce the chance of incorrectly matching a packet.

The ugly–I’m running 12.4(22)T and it crashed my router multiple times.  Now I was using the same RTR to terminate the SSH and do the filtering, so I’m not sure which caused the reboot.  Hopefully it is the SSH server process and not the filtering process.  If it is the filtering process, Cisco may have a serious issue, (it needs to be fixed either way).

Your mileage may vary.  Look at it in wireshark and go from there, but here’s what I did.  Let me say that again, it is important to compare what you are doing in FPM with what you see in Wireshark or another packet sniffer.  I used the beginning of the packet as the starting point for counting the offsets.  This is the “l3-start” option in the match criteria.

I looked at the packet after the tcp handshake that comes from the server to the client.  Below are the classes that I created and tested, along with comments.  I tested each of these individually, but ultimately, only ssh2 was required for the Group Study question.

class-map type access-control match-all ssh15
//make sure it is tcp step 9 octets from l3
//start and match 1 byte 06 is tcp
match start l3-start offset 9 size 1 eq 06
//make sure it is sourced from port 22
//step 20 octets from l3 start and read 2 bytes
match start l3-start offset 20 size 2 eq 22
//look for the string indicating the server version
match start l3-start offset 40 size 18 string “SSH-1.5-Cisco-1.25”

class-map type access-control match-all ssh2
match start l3-start offset 9 size 1 eq 06
match start l3-start offset 20 size 2 eq 22
match start l3-start offset 40 size 18 string “SSH-2.0-Cisco-1.25”

class-map type access-control match-all ssh199
match start l3-start offset 9 size 1 eq 06
match start l3-start offset 20 size 2 eq 22
//note–this one is one byte longer for the
//extra digit in the version
match start l3-start offset 40 size 19 string “SSH-1.99-Cisco-1.25”

Then I created a policy map–and specified what I wanted to filter.

policy-map type access-control filterssh
//pick your class
class ssh2

drop

Then I applied it to the interface in an outbound fashion back toward the client.

interface fa0/0
service-policy type access-control out filterssh

All in all, this was a good exercise for me, but I wouldn’t anyone putting this into production until they test it with their code.  I’m just not sure where my flakiness came from, the SSH component or the access-control policy map.  In any case, this is a powerful and flexible tool.

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To. Bookmark the permalink.