I guess what I am trying to say is that it should be consistent, if the Stack
has missing information.... the stack class map should not have matches...
Here:
Class-map: TCP_STACK (match-all) 29 packets, 1817 bytes 5 minute
offered rate 0 bps
Match: field ETHER type eq 0x800 next TCP
Why if the packets come incorrectly (based on what we mounted) why would it
have matches then?
I tried the same example using telnet, doing it with the GRE tunnel I build
yesterday and it didnt work either, now it is more interesting, why yesterday,
it saw the codes in ICMP Header, but it wont see anything on the TCP header
itself...
I will give it a few more hours and try to find the bottom of this.....
Mike
From: [email protected]
To: [email protected]
Date: Thu, 21 Jun 2012 01:14:22 -0600
CC: [email protected]
Subject: Re: [OSL | CCIE_Security] CCIE_Security Digest, Vol 72, Issue 75
No I mean, if the packet is not mounted correclty, why would it have matches?
Saying, Ok it sees the Layer 2 header, fine, looks for the ethertype... 0x800
thats correct, but then.. then the IP header is missing... why would the stack
match.. if the IP header is missing?
Mike
Date: Thu, 21 Jun 2012 00:09:36 -0700
Subject: Re: CCIE_Security Digest, Vol 72, Issue 75
From: [email protected]
To: [email protected]
CC: [email protected]
Not sure if I understand you right but the stack it is supposed to match the
traffic.
On Wed, Jun 20, 2012 at 11:59 PM, Mike Rojas <[email protected]> wrote:
Something funny is happening to your class maps...... The stack does have a
match.. why would it match?
Mike
Date: Wed, 20 Jun 2012 23:51:40 -0700
Subject: Re: CCIE_Security Digest, Vol 72, Issue 75
From: [email protected]
To: [email protected]
CC: [email protected]
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_STACKstack-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_STACK2stack-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 _______________________________________________
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
