myITmicroblog

Some time ago I sent question to EU about DOS/DDOS protection because I believe ISPs could do a bit more to protect us: Dear Sirs, I found you are responsible of creating safe, reliable Internet. As you know most of EU companies already had or they will have problems with hackers. One of the attacks is commonly known as Denial of Service Attack or Distributed Denial of Service Attack (DOS, DDOS). 15 years ago one document was published, knows as Best Current Practice 38 (BCP 38 or RFC 2267). I don't know why it has not been widely implemented by ISPs during last 15 years. They complained it is very time consuming and difficult to manage. Let me explain how it works: - every company or home user has IP address or range of IP addresses allocated by ISP (for example 7.7.7.7) - every edge router is managed by the same ISP who allocates these IP addresses - BCP 38/RFC 2267 says: block any traffic from network (company or home) where source IP is different fro

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 rat

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 type ins

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