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: mike_c...@hotmail.com To: oszk...@gmail.com Date: Thu, 21 Jun 2012 01:14:22 -0600 CC: ccie_security@onlinestudylist.com 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: oszk...@gmail.com To: mike_c...@hotmail.com CC: ccie_security@onlinestudylist.com 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 <mike_c...@hotmail.com> 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: oszk...@gmail.com To: mike_c...@hotmail.com CC: ccie_security@onlinestudylist.com 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 <mike_c...@hotmail.com> 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: oszk...@gmail.com To: mike_c...@hotmail.com CC: ccie_security@onlinestudylist.com 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 <mike_c...@hotmail.com> 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: oszk...@gmail.com To: mike_c...@hotmail.com CC: ccie_security@onlinestudylist.com 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 <mike_c...@hotmail.com> 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: oszk...@gmail.com To: ccie_security@onlinestudylist.com CC: mike_c...@hotmail.com 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