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...

Today I’m going to present how to implement a high availability for ZBPF. Below you can see the scenario I work on: As you see I have two routers (R1 and R2) which now operates separately. From R4 we can reach R5 via R1 and R2:   R4 #sh ip route Codes : L - local , C - connected , S - static , R - RIP , M - mobile , B - BGP D - EIGRP , EX - EIGRP external , O - OSPF , IA - OSPF inter area N1 - OSPF NSSA external type 1 , N2 - OSPF NSSA external type 2 E1 - OSPF external type 1 , E2 - OSPF external type 2 i - IS - IS , su - IS - IS summary , L1 - IS - IS level - 1 , L2 - IS - IS level - 2 ia - IS - IS inter area , * - candidate default , U - per - user static route o - ODR , P - periodic downloaded static route , H - NHRP , l - LISP + - replicated route , % - next hop override Gateway of last resort is not set 4.0 . 0.0 / 8 is variably subnetted , 2 subn...

Today I would like to smash your confidence about the security of your organization. You spent hundreds of dollars or euros on your security devices and you think you are safe. I believe there are many organizations like yours that think the same thing. Once they become victims, they realize they are not as safe as they had thought. Let’s talk about DOS/DDOS attacks. I think most people have some knowledge about them. Today we should not talk only about DOS attacks because the risk of being seriously impacted is very low. Most network devices can easily mitigate such attacks because they come from one source IP address. The situation is different when we receive illegitimate traffic from many IP addresses. There are two possibilities here: we can be flooded by traffic from a real, existing source IP address or addresses; or there is one real source IP, but the packets contain random source IPs, which means you are not able to block them easily. We can distinguish the fol...