Posted by: Richard @ Configureterminal.com | April 30, 2008

Internetwork Expert Brainteaser #1

Now that April 30th has arrived I thought I would share my solutions to the Internetwork Expert Brainteaser….

 

A quick overview of the task set by Internetwork Expert can be found below:


“A host is connected to the Internet as per the diagram and configuration

snippet above. Your task is to provide an access-control solution to block

certain TCP sessions from the Internet. Specifically, TCP sessions from

the outside to the server IP address 155.1.34.3 and ports 8080,3128 should

be silently discarded. A restriction is that you are not allowed to

configure any access-list on the router. The use of static routes is

permitted to accomplish this task. Implement your solution using the

minimum number of configuration lines.”


I came up with four solutions, my
favourite being the first example of the use of FPM (not the shortest number of lines but FPM was designed for situations such as this):

Solution 1:
!
class-map type access-control match-all inetexpert-class1
 match start l3-start offset 9 size 1 eq 6
 match start l3-start offset 16 size 4 eq 2600542723
!
class-map type access-control match-any inetexpert-class2
 match start l3-start offset 22 size 2 eq 8080
 match start l3-start offset 22 size 2 eq 3128
!
policy-map type access-control inetexpert-parent
 class inetexpert-class1
  service-policy inetexpert-child
!
policy-map type access-control inetexpert-child
 class inetexpert-class2
  drop
!
interface Ethernet0/1
 service-policy type access-control input inetexpert-parent
!

Explanation
à This solution makes use of nested class-maps referencing FPM statements without local .phdf files loaded.  The task is looking for a fixed destination IP address and an OR of TCP port 8080 and 3128 (that’s why nested class-maps are required).  The first line of “inetexpert-class1” matches IP protocol number 6 – i.e. TCP, the second line matches the IP address 155.1.34.3 in full decimal format.  “inetexpert-class2” matches either 8080 or 3128 in a 2-byte field 22 bytes after the beginning of the layer 3 header – i.e. TCP Header à ‘Destination Port’ (Wireshark was used to confirm this).

 

Solution 2:
!
load protocol flash:ip.phdf
load protocol flash:tcp.phdf
!
class-map type access-control match-all inetexpert-class1
 match field ip dest-addr eq 155.1.34.3
 match field ip protocol eq 0x6 next tcp
!
class-map type access-control match-any inetexpert-class2
 match field tcp dest-port eq 8080
 match field tcp dest-port eq 3128
!
policy-map type access-control inetexpert-child
 class inetexpert-class2
  drop
!
policy-map type access-control inetexpert-parent
 class inetexpert-class1
  service-policy inetexpert-child
!
interface Ethernet0/1
 service-policy type access-control input inetexpert-parent
!

Explanation
à This solution makes use of nested class-maps referencing FPM statements with local .phdf files loaded.  The configuration is a lot easier to understand/read but the .phdf files need to be local to be loaded and then referenced by FPM.

 

Solution 3:
!
ip nbar custom inetexpert destination tcp 8080 3128
!
class-map match-all inetexpert-class
 [match input-interface Ethernet0/1]
ß Not actually required in this example
 match destination-address mac ‘the mac address of the server’
 match protocol inetexpert
!
policy-map inetexpert-policy
 class inetexpert-class
  drop
!
interface Ethernet0/1
 service-policy input inetexpert-policy
!

Explanation
à I don’t like this solution, it relies on the MAC address of the server never changing (at no point is the destination IP address referenced), but it is a solution with a small number of lines.  The general idea is that we match on the port numbers using NBAR, we then use ARP to find out the MAC address of the server and put it all together in a policy-map that drops the traffic.

 

Solution 4:
!
ip nbar custom inetexpert destination tcp 8080 3128
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
class-map match-all inetexpert-class
 match protocol inetexpert
 match input-interface Loopback0
!
policy-map inetexpert-policy
 class inetexpert-class
   drop
!
interface Ethernet0/0
 service-policy output inetexpert-policy
!
ip prefix-list inetexpert-server seq 5 permit 155.1.34.3/32
!
route-map inetexpert-pbr permit 10
 match ip next-hop prefix-list inetexpert-server
 set interface Loopback0
!
route-map inetexpert permit 999
!
interface Ethernet0/1
 ip policy route-map inetexpert-pbr

!
Explanation
à Internetwork Expert themselves gave me the idea for this solution.  PBR doesn’t give us all the options we need to specify all of the properties of the traffic, but by forcing the traffic to be routed via a loopback interface first the source-interface changes and therefore MQC can reference this – no MAC addresses required J (hefty configuration however)

 

I’m convinced someone will come along and make me look like a fool by fulfilling what the task asked for in a few simple lines of configuration but I had fun thinking (or overthinking) this through.

Anyway, I’m on leave to study multicast, not to post to my blog….

Advertisements

Responses

  1. […] Richard Bannister has proposed 4 solutions to the Internetwork Expert Brainteaser. They are great examples, especially on how to match certain fields of a Layer3 packet using Cisco Flexible Packet Matching (FPM). […]

  2. Quote from an e-mail received from Internetwork Expert:
    “Here is this months brainteaser solution:
    !
    ! This could be any decoy IP address
    !
    ip route 127.127.1.1 255.255.255.255 Null0
    !
    ! Redirect the mentioned ports to Null0
    !
    ip nat inside source static tcp 127.127.1.1 3128 155.1.34.3 3128
    extendable no-alias
    ip nat inside source static tcp 127.127.1.1 8080 155.1.34.3 8080
    extendable no-alias
    !
    ! Don’t send any unreachables for the dropped packets
    !
    interface Null 0
    no ip unreachables
    !
    ! Enable NAT
    !
    interface Ethernet 0/0
    ip nat inside
    !
    interface Ethernet 0/1
    ip nat outside
    !
    total lines *added* to the configuration: 6”

  3. Congratulations to Wyatt Sullivan who came up with the solution.

    Funny enough, on the way home in the car tonight I thought “NAT!” but I couldn’t think of an exact configuration that would work. I need to double check that “extendable” and “no-alias” are in my notes….

    When I read that the use of static routes was permitted I tried to think of a solution using a static route –> “track” came to mind initially but “no, that can’t do it”, in the end I came to the conclusion that Internetwork Expert wouldn’t have given you such a big clue – “It’s too obvious” –> how wrong was I! 🙂

  4. These were my 2 solutions:

    1st solution
    !=======================================================
    !Please note that RST packets are sent back to the source
    !
    interface Ethernet 0/1
    ip nat outside
    !
    ip nat inside source static tcp 192.10.1.4 9998 155.1.34.3 3123 no-alias
    ip nat inside source static tcp 192.10.1.4 9999 155.1.34.3 8080 no-alias
    !=======================================================

    2nd solution
    !=======================================================
    !
    ip cef ! not needed if default
    !
    ip nbar port-map custom-01 tcp 8080 3128
    !
    class-map match-all CUSTOM-CLASS
    match protocol custom-01
    !
    policy-map DROP-CUSTOM-POLICY
    class CUSTOM-CLASS
    drop
    !
    route-map LOOPBACK-TO-SERVER 10
    set interface E0/0
    ! or you can use the following in order to avoid arping on a broadcast medium
    ! set ip next-hop 155.1.34.3
    !
    interface Loopback9
    ip address 9.9.9.9 255.255.255.255
    ip policy route-map LOOPBACK-TO-SERVER
    service-policy input DROP-CUSTOM-POLICY
    !
    ip route 155.1.34.3 255.255.255.255 Loopback9
    !
    !=======================================================
    !The following is needed for the local generated packets
    !=======================================================
    !
    ip prefix-list SERVER seq 5 permit 155.1.34.3/32
    !
    route-map LOCAL-TO-SERVER permit 10
    match ip address prefix-list SERVER
    set interface E0/0
    !
    ip local policy route-map LOCAL-TO-SERVER
    !
    !=======================================================

    Quite strangely the 1st one didn’t win.

  5. […] Richard Bannister has proposed 4 solutions to the Internetwork Expert Brainteaser. They are great examples, especially on how to match certain fields of a Layer3 packet using Cisco Flexible Packet Matching (FPM).   […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: