myITmicroblog

In my last post I tested some features of ZBFP and how traffic is processed by the firewall and some interfaces are not part of ZBFP configuration. Today I’d like to test ‘self-zone’ because it works a bit different. I’m going to work on a configuration from my last post. As you remember I created policy for traffic from R2 to R3. I also tested connection from R2 to R4 and it didn’t work (R4 is not a member of any zone) but traffic from R5 to R4 is allowed (both are not members of any zone). With 'self-zone’ is works a bit different. Let’s do one test: R2->R1:   R2 #ping 2.2.2.1 Type escape sequence to abort . Sending 5 , 100 - byte ICMP Echos to 2.2 . 2.1 , timeout is 2 seconds : !!!!! Success rate is 100 percent ( 5 / 5 ), round - trip min / avg / max = 64 / 95 / 128 ms R2 # R5->R1:   R5 #ping 5.5.5.1 Type escape sequence to abort . Sending 5 , 100 - byte ICMP Echos to 5.5 . 5.1 , timeout is 2 seconds : !!!!! Success...

ZBFP is a successor of CBAC and it is the most flexible firewall implementation available on IOS. The main idea is to think about zones, not physical interfaces. With CBAC you couldn’t build policy based on flow or direction. For example a policy applied on OUTSIDE interface works the same for traffic to DMZ and to LAN. ZBFP can easily separate these flows and you can have two different rules depending on out interface. Let’s test one scenario: I’m going to add a policy for traffic from R2 to R3. Only telnet and icmp should be allowed. First I create a class and policy map:   ! class - map type inspect match - any CM - ICMP - TCP match protocol icmp match protocol tcp ! policy - map type inspect PM - ICMP - TCP class type inspect CM - ICMP - TCP inspect class class - default ! and then zones and a service policy:   ! zone security INSIDE zone security OUTSIDE ! zone - pair security INS -> OUT source INSIDE destination OUTSIDE service - policy...

I would like to talk about defeating DDOS and scenarios how we can actually use it. Let’s get started ! I’m going to talk about two methods: 1) before you forward any packet, check if you know the return path. If you know, forward the packet, if you don’t – drop it. There are two ways of implementation: strict and loose. First one accepts packets only when the return path is through the interface which is the ingress one. The second one accept any packet if the router has the return path via any interface. As you can see you can’t use this solution for transit or multihomed networks. It should be rather singlehomed, stub network. During DDOS attackers spoof a source IP and the solution will work (packets will be dropped) only for those with invalid source IP addresses. If the source IP is a valid, the packet will be forwarded. 2) edge router checks if the source IP is the one, which is allocated for particular ISP client – this is the best, easiest for single homed ...