Hmm...if we follow that logic then the following example should work as
well right?
We say first to match all the Ethernet packets with ethertype IP then jump
to TCP header. Something like this:
class-map type stack match-all TCP_STACK
stack-start l2-start
match field ETHER type eq 0x800 next TCP
class-map type access-control match-all TELNET
match field TCP dest-port eq 0x17
policy-map type access-control TELNET_DROP
class TELNET
drop
policy-map type access-control FPM2
class TCP_STACK
service-policy TELNET_DROP
But in this case Telnet traffic is not matched:
R5#sh policy-map type access-control interface
FastEthernet0/0
Service-policy access-control input: FPM2
Class-map: TCP_STACK (match-all)
29 packets, 1817 bytes
5 minute offered rate 0 bps
Match: field ETHER type eq 0x800 next TCP
Service-policy access-control : TELNET_DROP
Class-map: TELNET (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: field TCP dest-port eq 0x17
drop
Class-map: class-default (match-any)
29 packets, 1817 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
If I define/match all the protocols/headers in order, as they come, telnet
traffic is matched and dropped as expected:
class-map type stack match-all TCP_STACK2
stack-start l2-start
match field ETHER type eq 0x800 next IP
match field IP protocol eq 0x6 next TCP
class-map type access-control match-all TELNET
match field TCP dest-port eq 0x17
policy-map type access-control TELNET_DROP
class TELNET
drop
policy-map type access-control FPM3
class TCP_STACK2
service-policy TELNET_DROP
R5#sh policy-map type access-control interface
FastEthernet0/0
Service-policy access-control input: FPM3
Class-map: TCP_STACK2 (match-all)
2 packets, 120 bytes
5 minute offered rate 0 bps
Match: field ETHER type eq 0x800 next IP
Match: field IP protocol eq 0x6 next TCP
Service-policy access-control : TELNET_DROP
Class-map: TELNET (match-all)
2 packets, 120 bytes
5 minute offered rate 0 bps
Match: field TCP dest-port eq 0x17
drop
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Class-map: class-default (match-any)
8 packets, 852 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
On Wed, Jun 20, 2012 at 8:07 PM, Mike Rojas <[email protected]> wrote:
> Hey,
>
> Basically, If we want to be really specific into the protocol, we we will
> need to create our own PHDF for GRE.. There are 16 bits for protocol type
> we would mostlikely specify the next IP header (0x800) in order to match
> the stack on the exact order.
>
> On our stack we are saying, look in the first IP header that the protocol
> number is 0x2f, which is GRE and then jump off to ICMP header.
>
> So, it would be check
> _________________
> | |
> protocol 0x2f Next look for ICMP header.
> OUTER_IP | GRE | INNER_IP | ICMP.
>
> We are not doing anything with the "in-between" headers.
>
> Based on experience, that "next" doesnt mean expect the next protocol to
> be x, it means, jump off to the following header... and if you find the
> header there, it will be consider a match.
>
> “First I want you to look at the IP header for this, then we go look at
> the TCP header for this.” It doesnt mean you have to match each and every
> header on a packet.
>
> http://blog.ipexpert.com/2010/05/12/introduction-to-fpm/
>
> Mike
>
>
> ------------------------------
> Date: Wed, 20 Jun 2012 19:37:28 -0700
>
> Subject: Re: CCIE_Security Digest, Vol 72, Issue 75
> From: [email protected]
> To: [email protected]
> CC: [email protected]
>
> Hi Mike,
>
> I still don't understand how can we jump from GRE to the ICMP without
> matching the inner IP header first.
> In GRE we have OUTER_IP | GRE | INNER_IP | ICMP.
>
> Class Map type stack match-all STACK-GRE (id 1)
> Match field IP protocol eq 0x2F next ICMP
>
> In your stack class-map you are matching the OUTER_IP which is followed
> by GRE then the next protocol should be ICMP but what happens with the
> INNER_IP? Actually this is why I have started to play with this.
>
>
> Please comment!
>
>
>
>
>
>
> On Wed, Jun 20, 2012 at 7:10 PM, Mike Rojas <[email protected]> wrote:
>
> Hey,
>
> Yeah, weird isnt it? Most people think that is mandatory to have a "next
> GRE" when mounting the stack, if you are not going to match anything on
> that specific header, why would you mount it?
> I dont know... I ended up liking it a lot, of course it can get really
> nasty.
>
> Mike
>
> ------------------------------
> Date: Wed, 20 Jun 2012 15:52:05 -0700
>
> Subject: Re: CCIE_Security Digest, Vol 72, Issue 75
> From: [email protected]
> To: [email protected]
> CC: [email protected]
>
>
> Hi Mike,
>
> Code 0 means no code, and majority of the ICMP types have code 0. As a
> result you will drop much more than echo/echo reply.
> And you are right, for some reason matching types for ICMP is not working
> in this case.
>
> On Wed, Jun 20, 2012 at 3:37 PM, Mike Rojas <[email protected]> wrote:
>
> Oszkar,
>
> You are right. I sent a clarification on this exercise it will drop any
> ICMP message within GRE that has a code 0 on them. Seems that there is a
> problem with FPM because it cannot match types correctly. If I match code
> 0 it will drop both ICMP echo and echo reply because they both have code 0
> on them.
>
> Mike
>
>
> ------------------------------
> Date: Wed, 20 Jun 2012 13:40:32 -0700
> Subject: Re: CCIE_Security Digest, Vol 72, Issue 75
> From: [email protected]
> To: [email protected]
> CC: [email protected]
>
>
> Hi Mike,
>
> Why did you choose to look for code 0? Code 0 means different thing for
> each ICMP type.
> I think for echo messages you should look for icmp type 8 .
> Now the interesting part is that if you try to match icmp type 8 instead
> of code 8 your solution won't work.
>
>
> Oszkar
>
>
>
> Annnnnnnd Bingo,
>
> I was right, since it is encapsulated and not Encrypted, we can match
> whatever it is inside on the GRE packet... we are matching, not crafting....
>
> Here is the example of dropping ICMP echo messages encapsulated on GRE...
>
> Class Map type access-control match-all ICMP (id 2)
> Match field ICMP code eq 0 mask 0x1
>
> Class Map type stack match-all STACK-GRE (id 1)
> Match field IP protocol eq 0x2F next ICMP
>
>
> Policy Map type access-control STACK-GRE
> Class STACK-GRE
> service-policy ICMP-DROP-GRE
>
> Policy Map type access-control ICMP-DROP-GRE
> Class ICMP
> drop
>
>
>
>
> Router1#sh policy-map type access-control interface fa 0/1
> FastEthernet0/1
>
> Service-policy access-control input: STACK-GRE
>
> Class-map: STACK-GRE (match-all)
> 5 packets, 690 bytes
> 5 minute offered rate 0 bps
> Match: field IP protocol eq 0x2F next ICMP
>
> Service-policy access-control : ICMP-DROP-GRE
>
> Class-map: ICMP (match-all)
> 5 packets, 690 bytes
> 5 minute offered rate 0 bps
> Match: field ICMP code eq 0 mask 0x1
> drop
>
> Class-map: class-default (match-any)
> 0 packets, 0 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: any
>
> Class-map: class-default (match-any)
> 2 packets, 1236 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: any
>
>
>
>
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
Are you a CCNP or CCIE and looking for a job? Check out
www.PlatinumPlacement.com
