A look at classic RIPv1 & v2 differences

Here's a quick review of the differences in RIPv1 and RIPv2. RIP ( Routed IP ) has been a dynamic routing protocol going back to the beginning of the internet.

At one time, it was also the most common dynamic routing protocol before OSPF and EIGRP came of use. Almost all unix systems supported, it as daemon known as;  in.routed or routed.

Rip had serious drawbacks and here's some of the cons;

1: convergence was slow, when compared to  OSPF or EIGRP
2: it's limited to 16 hops ( it's a distance vector protocol )
3: updates are constant regardless of changes in the network topology ( very chatting )
4: packet size limits the total numbers of routes that could be installed in a update


The  RIPv1  updates  sends only  class ( A B C ) only  network in the updates. So networks are summarize into a Class Boundary based on the network number ;


Ken-Felixs-MacBook:~ root# tcpdump -nvv -i en0 port 520         
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
23:17:48.561285 IP (tos 0x0, ttl 64, id 1609, offset 0, flags [none], proto UDP (17), length 132)
    192.168.1.99.520 > 192.168.1.255.520: [udp sum ok]
    RIPv1, Response, length: 104, routes: 5
      3.0.0.0, metric: 16
      4.0.0.0, metric: 16
      99.99.99.1, metric: 1
      99.99.99.2, metric: 1
      192.168.1.0, metric: 16
    0x0000:  0201 0000 0002 0000 0300 0000 0000 0000
    0x0010:  0000 0000 0000 0010 0002 0000 0400 0000
    0x0020:  0000 0000 0000 0000 0000 0010 0002 0000
    0x0030:  6363 6301 0000 0000 0000 0000 0000 0001
    0x0040:  0002 0000 6363 6302 0000 0000 0000 0000
    0x0050:  0000 0001 0002 0000 c0a8 0100 0000 0000
    0x0060:  0000 0000 0000 0010





23:18:19.558392 IP (tos 0x0, ttl 64, id 1610, offset 0, flags [none], proto UDP (17), length 132)
    192.168.1.99.520 > 192.168.1.255.520: [udp sum ok]
    RIPv1, Response, length: 104, routes: 5
      3.0.0.0, metric: 16
      4.0.0.0, metric: 16
      99.99.99.1, metric: 1
      99.99.99.2, metric: 1
      192.168.1.0, metric: 16
    0x0000:  0201 0000 0002 0000 0300 0000 0000 0000
    0x0010:  0000 0000 0000 0010 0002 0000 0400 0000
    0x0020:  0000 0000 0000 0000 0000 0010 0002 0000
    0x0030:  6363 6301 0000 0000 0000 0000 0000 0001
    0x0040:  0002 0000 6363 6302 0000 0000 0000 0000
    0x0050:  0000 0001 0002 0000 c0a8 0100 0000 0000
    0x0060:  0000 0000 0000 0010
^C
2 packets captured
10 packets received by filter




Where as  RIPv2 supports classlesss mask information in the updates.



23:13:47.572172 IP (tos 0x0, ttl 1, id 34644, offset 0, flags [none], proto UDP (17), length 192)
    192.168.1.99.520 > 224.0.0.9.520: [udp sum ok]
    RIPv2, Response, length: 164, routes: 8
      Unknown (3) Authentication data:
      0x0000:  0090 0114 3844 7105 0000 0000 0000 0000
      AFI IPv4,         0.0.0.0/0 , tag 0x0000, metric: 16, next-hop: 192.168.1.1
      AFI IPv4,         3.3.3.0/24, tag 0x0000, metric: 16, next-hop: 192.168.1.1
      AFI IPv4,        4.4.44.0/24, tag 0x0000, metric: 16, next-hop: self
      AFI IPv4,      99.99.99.1/32, tag 0x0000, metric: 1, next-hop: self
      AFI IPv4,      99.99.99.2/32, tag 0x0000, metric: 1, next-hop: self
      AFI IPv4,     192.168.1.0/24, tag 0x0000, metric: 16, next-hop: self
      Unknown (1) Authentication data:
      0x0000:  6cc3 7237 64c9 518b b627 429f 27eb f8e2
    0x0000:  0202 0000 ffff 0003 0090 0114 3844 7105
    0x0010:  0000 0000 0000 0000 0002 0000 0000 0000
    0x0020:  0000 0000 c0a8 0101 0000 0010 0002 0000
    0x0030:  0303 0300 ffff ff00 c0a8 0101 0000 0010
    0x0040:  0002 0000 0404 2c00 ffff ff00 0000 0000
    0x0050:  0000 0010 0002 0000 6363 6301 ffff ffff
    0x0060:  0000 0000 0000 0001 0002 0000 6363 6302
    0x0070:  ffff ffff 0000 0000 0000 0001 0002 0000
    0x0080:  c0a8 0100 ffff ff00 0000 0000 0000 0010
    0x0090:  ffff 0001 6cc3 7237 64c9 518b b627 429f
    0x00a0:  27eb f8e2
^C
24 packets captured
2893 packets received by filter
0 packets dropped by kernel


See the differences? This can become a issues if used in various designs and no consideration for summarization.

RIPv1 sends no CIDR-prefix information in it's update. Both  version sends to udp.port 520, but RIPv2 uses multicast ( 224.0.0.9)  and RIPv1 uses broadcast.Multicast is far superior to broadcasting a packet that's handle by all hosts in the broadcast domain.

One other key thing, RIPv2 supports  text or md5 based authentication in all of it updates. The above update shows md5 but here's a simple text-authentication.

23:03:51.052452 IP (tos 0x0, ttl 1, id 34595, offset 0, flags [none], proto UDP (17), length 92)
    192.168.1.99.520 > 224.0.0.9.520: [udp sum ok]
    RIPv2, Response, length: 64, routes: 3
      Simple Text Authentication data: myrip
      AFI IPv4,      99.99.99.1/32, tag 0x0000, metric: 1, next-hop: self
      AFI IPv4,     192.168.1.0/24, tag 0x0000, metric: 16, next-hop: self
    0x0000:  0202 0000 ffff 0002 6d79 7269 7000 0000
    0x0010:  0000 0000 0000 0000 0002 0000 6363 6301
    0x0020:  ffff ffff 0000 0000 0000 0001 0002 0000
    0x0030:  c0a8 0100 ffff ff00 0000 0000 0000 0010

The authentication string is a simple word of myrip. I hope this helps & with understanding the differences between RIPv1 and v2.

And the last noticeable difference, RIPv2 supports AFI ( address family indicators ).


Ken Felix
Freelance Network and Security Engineer
kfelix " at  hyperfeed.com

ipv6 ready and supported firewalls

Here's a quick list of some known firewalls that support ipv6. I'm sure their others, but these are just a list that I'm aware of.


  Fortigate ( linux based )
  pfsense ( bsd based )
  Halon SR ( bsd based )
  linux  iptables with ipv6  ( kernel 2.6.x )
  cisco ASA ( linux based )
  Juniper ( bsd based )
  PaloAlto  ( ????? based )
  Cyberoam   ( linux based )
  Checkpoint ( linux based )

( note: I've have worked on all of the above  platforms  ( bold )  with regards to ipv6   and they don't always support dynamic routing for IPv6, and might lack  RIP-ng or OSPFv3 , they also might be very restrictive , base on  software  such as support for DHCPv6 server )

With the big push for IPv6 ready gear and IPv6 migrations, the vendors are slowly catching up and moving forward.

Ken Felix
Freelance Security and Network Engineer
kfelix "at_symbol"hyperfeed  dot  com

Rant:IPV6 authentication or lack of it in my favorite firewall

I'm currently  running ipv6  at 2 unique setups. One setup has  a 2 edge-routers and 2 Fortigates in a A-P cluster and running opsfv3. I wanted to enable OPSFv3 w/authenticate,  since I just enable a ASA that sits on that same OSPFv3 area 0 bkbone.

What I found out was a big surprise. Fortinet dropped the ball with OPSFv3 security features & with being  support in their firewalls. I was honesty shocked upon finding out this limitation.

Here's a direct quote from Fortinet-TAC after they spent 4 days investigating;

   {
I just received an answer from our specialist. Fortigate does not accept OSPFv3 authentication via ipsec+AH. So far, we cannot tell you when this feature will be available.

Please let us know if you need more information or if there is anything else we can help you with.
If this solves your issue, please update the ticket with the information so that we may close this ticket. Thank you.


Regards,
Maximira Correa
Fortinet TAC Engineer, Americas
Monday - Friday, 8:00am-5:00pm (Pacific)
https://support.fortinet.com
Tech Support: 1-866-648-4638
   }

Is this okay ?  Nope, not really;

Fortinet has had ipv6 functions and routing in their firewalls for some quite time. As a matter of fact, I've been using IPV6 ( static routed ) since  MR6 Patch 6 & in a FWF60 model.

So I find it funny, that  Fortigate has been IPv6 aware since the late version 3 code. And then again Ipv6 OSPFv3 routing support for some time.  But some how they missed this basic security feature?

For what it's worth,  Juniper , Cisco, H3C, and cisco's own ASA has OSPFv3 authentication support, but when compared to the simple and highly respected  Fortigate Security Gateway, this is not doable.

  
:(
 
Ken Felix
Freelance Network and Security Engineer
kfelix" at " hyperfeed.com

 

IPv6 OSPFv3 authentication ISR routers ( AH proto 51 )

We are going to look at the ipv6 ospf authentication per interface. To enable OPSFv3 authentication we need to realize that we are using AH ( proto51) and with using  the ipv6 authentication capabilities.

Over all it's quite simple to configure. 1st we need to enable ipv6 on the interface(s) that we are expecting OSPFv3 authentication on ( in my lab this was already done  earlier, so I'm skipping setting up OSPFv3 routing ).

Next,  we need to create a SPI  index number plus the selection of the md5/sha hash method and then finally the hex-data-string. The latter would be comparative to our key-strings in cisco ios keys. These items must match within  the router(s) and interfaces that are to be OPSFv3-authen enabled.



interface FastEthernet0/1
 description VRF custA to 3560#1 port gi 0/1
 ip address dhcp
 ip nat outside
 ip virtual-reassembly
 duplex auto
 speed auto
 ipv6 address 2002:100::2/64
 ipv6 enable
 ipv6 ospf cost 1000
 ipv6 ospf 10 area 0
 ipv6 ospf authentication ipsec spi 256 md5 AABBCCDDEEFFAABBCCDDEEFFAABBCCDD
 
Once we enable AH on our interfaces, we can now monitor via packet captures, and since this is  Cryptology, we can use the show crypto ipsec  cmds


And here's a dump of the  AH header via tshark & tcpdump . Notice the SPI and AH-ICV fields?


    Authentication Header
        Next Header: OSPF IGP (0x59)
        Length: 24
        AH SPI: 0x00000100
        AH Sequence: 43
        AH ICV: 01394B4859CB743CF6252970
Open Shortest Path First
    OSPF Header
        OSPF Version: 3
        Message Type: Hello Packet (1)
        Packet Length: 40
        Source OSPF Router: 2.2.2.2 (2.2.2.2)
        Area ID: 0.0.0.0 (Backbone)
        Packet Checksum: 0x1140 [correct]
        Instance ID: 0
        Reserved: 0
    OSPF Hello Packet
        Interface ID: 4
        Router Priority: 1
        Options: 0x000013 (R, E, V6)
            .... .... .... .... ..0. .... = DC: DC is NOT set
            .... .... .... .... ...1 .... = R: R is SET
            .... .... .... .... .... 0... = N: N is NOT set
            .... .... .... .... .... .0.. = MC: MC is NOT set
            .... .... .... .... .... ..1. = E: E is SET
            .... .... .... .... .... ...1 = V6: V6 is SET
        Hello Interval: 10 seconds
        Router Dead Interval: 40 seconds
        Designated Router: 2.2.2.2
        Backup Designated Router: 172.16.1.254
        Active Neighbor: 172.16.1.254     Source: fe80::214:6aff:fec4:28ad (fe80::214:6aff:fec4:28ad)
    Destination: ff02::5 (ff02::5)
    Authentication Header
        Next Header: OSPF IGP (0x59)
        Length: 24
        AH SPI: 0x00000100
        AH Sequence: 44
        AH ICV: 80FA486B184EC2721FEDA05E
Open Shortest Path First
    OSPF Header
        OSPF Version: 3
        Message Type: Hello Packet (1)
        Packet Length: 40
        Source OSPF Router: 172.16.1.254 (172.16.1.254)
        Area ID: 0.0.0.0 (Backbone)
        Packet Checksum: 0x04d9 [correct]
        Instance ID: 0
        Reserved: 0
    OSPF Hello Packet
        Interface ID: 4
        Router Priority: 1
        Options: 0x000013 (R, E, V6)
            .... .... .... .... ..0. .... = DC: DC is NOT set
            .... .... .... .... ...1 .... = R: R is SET
            .... .... .... .... .... 0... = N: N is NOT set
            .... .... .... .... .... .0.. = MC: MC is NOT set
            .... .... .... .... .... ..1. = E: E is SET
            .... .... .... .... .... ...1 = V6: V6 is SET
        Hello Interval: 10 seconds
        Router Dead Interval: 40 seconds
        Designated Router: 2.2.2.2
        Backup Designated Router: 172.16.1.254
        Active Neighbor: 2.2.2.2

tcpdump 

18:10:20.552021 IP6 (flowlabel 0x0000e, hlim 1, next-header OSPF (89) payload length: 36) fe80::21f:caff:fef3:2111 > ff02::5: OSPFv3, Hello, length 36
        Router-ID 192.168.110.254, Backbone Area
        Options [V6, External, Router]
          Hello Timer 10s, Dead Timer 40s, Interface-ID 0.0.0.14, Priority 1
          Designated Router 192.168.110.254
          Neighbor List:

18:10:22.084776 IP6 (class 0xe0, hlim 1, next-header AH (51) payload length: 64) fe80::219:55ff:fe78:318d > ff02::5: AH(spi=0x00000100,sumlen=16,seq=0x20): OSPFv3, Hello, length 40
        Router-ID 2.2.2.2, Backbone Area
        Options [V6, External, Router]
          Hello Timer 10s, Dead Timer 40s, Interface-ID 0.0.0.4, Priority 1
          Designated Router 2.2.2.2, Backup Designated Router 172.16.1.254
          Neighbor List:
            172.16.1.254

As you can see with the 2 dumps, the details of the neighbors, timers, area,etc.... are in the clear. The AH provides no security or restrict the  exposures to the ospf data. It just ensure integrity of the players and for authentication of any OSPFv3 speakers.

Next, let explore the show crypto ipsec sa  cmd

ccie01#show crypto ipsec sa ipv6 int fas 0/1

interface: FastEthernet0/1
    Crypto map tag: (none), local addr FE80::214:6AFF:FEC4:28AD    IPsecv6 policy name: OSPFv3-10-256
   IPsecv6-created ACL name: FastEthernet0/1-ipsecv6-ACL    protected vrf: (none)
   local  ident (addr/mask/prot/port): (FE80::/10/89/0)
   remote ident (addr/mask/prot/port): (::/0/89/0)
   current_peer :: port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 97, #pkts encrypt: 0, #pkts digest: 97
    #pkts decaps: 90, #pkts decrypt: 0, #pkts verify: 90
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0      local crypto endpt.: FE80::214:6AFF:FEC4:28AD, remote crypto endpt.: ::
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/1
     current outbound spi: 0x100(256)
         
     inbound esp sas:
         
     inbound ah sas:
      spi: 0x100(256)
        transform: ah-md5-hmac ,
        in use settings ={Transport, }
        conn id: 2001, flow_id: SW:1, crypto map: (none)
        no sa timing
        replay detection support: N
        Status: ACTIVE
         
     inbound pcp sas:
         
     outbound esp sas:
         
     outbound ah sas:
      spi: 0x100(256)
        transform: ah-md5-hmac ,
        in use settings ={Transport, }
        conn id: 2002, flow_id: SW:2, crypto map: (none)
        no sa timing
        replay detection support: N
        Status: ACTIVE
         
     outbound pcp sas:

Looks farmilar to a regular  show crypto ipsec  sa  cmds that we use in  VPN :)

Things to watch out for;

• the SPI# must match
• the hash type must match
• the hex-data string must match
• and finally just like in ipv4, the timers must match

note: you must have a ios-codeset that supports crypto. The above where done on two cisco 1841 ISR with the following codeset;

ccie01#sh version | i oft
Cisco IOS Software, 1841 Software (C1841-ADVIPSERVICESK9-M), Version 12.4(25f), RELEASE SOFTWARE (fc2)
ccie01#

But here's a ipv6 aware cisco 6500 that does support cryptology features;

LA1R01CR#show ver | i oftwa
Cisco Internetwork Operating System Software
IOS (tm) s72033_rp Software (s72033_rp-IPSERVICESK9_WAN-M), Version 12.2(18)SXF11, RELEASE SOFTWARE (fc1)
BOOTLDR: s72033_rp Software (s72033_rp-IPSERVICESK9_WAN-M), Version 12.2(18)SXF11, RELEASE SOFTWARE (fc1)
SuperLAT software (copyright 1990 by Meridian Technology Corp).
X.25 software, Version 3.0.0.
Bridging software.
TN3270 Emulation software.

But it does not offer OPSFv3 authentication;

LA1R01CR(config-if)#ipv6 ospf ?
  <1-65535>            Process ID
  cost                 Interface cost
  database-filter      Filter OSPF LSA during synchronization and flooding
  dead-interval        Interval after which a neighbor is declared dead
  demand-circuit       OSPF demand circuit
  flood-reduction      OSPF Flood Reduction
  hello-interval       Time between HELLO packets
  mtu-ignore           Ignores the MTU in DBD packets
  neighbor             OSPF neighbor
  network              Network type
  priority             Router priority
  retransmit-interval  Time between retransmitting lost link state advertisements
  transmit-delay       Link state transmit delay

Nor does it support authentication globally




LA1R01CR(config-rtr)#?
  area                   OSPF area parameters
  auto-cost              Calculate OSPF interface cost according to bandwidth
  default                Set a command to its defaults
  default-information    Distribution of default information
  default-metric         Set metric of redistributed routes
  discard-route          Enable or disable discard-route installation
  distance               Administrative distance
  distribute-list        Filter networks in routing updates
  exit                   Exit from IPv6 routing protocol configuration mode
  ignore                 Do not complain about specific event
  log-adjacency-changes  Log changes in adjacency state
  maximum-paths          Forward packets over multiple paths
  no                     Negate a command or set its defaults
  passive-interface      Suppress routing updates on an interface
  process-min-time       Percentage of quantum to be used before releasing CPU
  redistribute           Redistribute IPv6 prefixes from another routing protocol
  router-id              router-id for this OSPF process
  summary-prefix         Configure IPv6 summary prefix
  timers                 Adjust routing timers

So keep that  thought in mind when designing your OSPFv3 topologies and before you enable IPv6 on your speakers. I've been burned numerous times, when deploying OPSFv3 +authentication into cisco core backbones.


Ken Felix
Your Freelance Network Security Engineer
kfelix " a t " hyperfeed.com

exploring ipv6 ospf routing on the cisco ASA

We will look at IPv6 routing known as OSPFv3 on the cisco ASA.


As of version 9

asaken# sh version | i Soft
Cisco Adaptive Security Appliance Software Version 9.0(1)
asaken#

I'm going to strike out some comments I made eariler, since I had to go to  the ASDM to figure out these features where present and slightly different than a  cisco ISR for example. What I notice is the ASDM provides simple OSPFv3 configuration items per-interface or globally.

I've taken some screenshot of this process;

Will cisco has done it again, they introduce features but do not fully enable everything that we can should expect. Take for example ipv6 ospf routing in our  cisco ASA.

We've found out ipv6 dynamic routing is support but ospf does not provide the following;

1: the ability to adjust ipv6 cost per interface or globally

2: the lack of OSPFv3 authentication 

The first could hamper our ability if we had multiple interfaces and need to adjust ospf cost towards metrics and preference of one path over the next. The latter is bad from a security concern and risk.


Okay so how do we enable ospf. Will it's quite easy and similar to the  cisco ios routers.

1st we enable globally the ospfv3 process;

ipv6 router ospf 10
 router-id 192.168.110.254
 default-information originate always metric 1000
 passive-interface default
 no passive-interface inside
 log-adjacency-changes


note: We need a operative l3 ipv4 interface and need to set a router-id

Next and just like with a cisco ios router, you need to craft the opsf instance on the interface;


interface Vlan1
 nameif inside
 security-level 100
 ip address 192.168.110.1 255.255.255.0
 ipv6 address 2002:100::1/64
 ipv6 nd reachable-time 3000
 ipv6 nd ns-interval 1200
 ipv6 nd dad attempts 2
 ospf cost 100
 ipv6 ospf 10 area 0


Okay, so that was simple? Notice how I played with  router default-origination  and inject this default ipv6 route regardless if I had a default route to begin with?

Also the same types of ipv4 show commands applies for ipv6

show ipv6 ospf interface

show ipv6 ospf neighbor

show ipv6 ospf database

So I hope this post is useful with the basic ipv6 ospf routing and on a cisco ASA 9.x code


Ken Felix
Freelance Network/Security Engineer
kfelix " a@t" hyperfeed dot com

ASA 9.0.1 and IPV6 ospf routing

In this post, we will explain the very basics of ipv6  ospfv3 routing & enabling for the ASA 9.X code. If you have any  farmilarity with ipv6 and the cisco  ASA firewalls, you will recall they did not  supported ipv6-ospf, in the 8.X codeset

Now with version 9 of the ASA code set , we get the dynamic routing protocol OSPF. RIPnG is not in version 9.0.1 btw and it's unclear if cisco has this on the milestone or a TBD, with regards to supporting RIP.

1st let's look at my simple lab ASA5505 device;


asaken# show ipv6 interface  br
Ethernet0/0 [up/up]
    unassigned
Ethernet0/1 [down/down]
    unassigned
Ethernet0/2 [down/down]
    unassigned
Ethernet0/3 [down/down]
    unassigned
Ethernet0/4 [up/up]
    unassigned
Ethernet0/5 [down/down]
    unassigned
Ethernet0/6 [down/down]
    unassigned
Ethernet0/7 [down/down]
    unassigned
inside [up/up]
    fe80::21f:caff:fef3:2111
    2002:100::1
outside [up/up]
    fe80::21f:caff:fef3:2111

And here's the interfaces current configurations;

!
interface Vlan1
 nameif inside
 security-level 100
 ip address 192.168.110.1 255.255.255.0
 ipv6 address 2002:100::1/64
 ipv6 nd reachable-time 3000
 ipv6 nd ns-interval 1200
 ipv6 nd dad attempts 2
 ospf cost 10


asaken# show  run int vlan 2
!
interface Vlan2
 description outside interface external
 nameif outside
 security-level 0
 ip address dhcp setroute
 ospf cost 1

As you can see, we have an basic  2 interface model, using a simple inside/outside security interfaces. We are going to enable ipv6 routing on my existing ipv6 enable interface.

1st you need to build a  ipv6  router process. Just like with ipv4, this process is configured globally, but the router-id has to be a ipv4 address in a x.x.x.x format. You have to define this router-id for this to properly work.


!
ipv6 router ospf 10
 router-id 192.168.110.254
 passive-interface default
 no passive-interface outside
 log-adjacency-changes
!

note: I also set  passive globally for all interfaces to be disable. We need to enable ipv6  ospf routing per-interfaces.



asaken# show ip add
System IP Addresses:
Interface                Name                   IP address      Subnet mask     Method
Vlan1                    inside                 192.168.110.1   255.255.255.0   CONFIG
Vlan2                    outside                72.xx.x.105     255.255.255.0   DHCP 
Current IP Addresses:
Interface                Name                   IP address      Subnet mask     Method
Vlan1                    inside                 192.168.110.1   255.255.255.0   CONFIG
Vlan2                    outside                72.xx.x.105     255.255.255.0   DHCP 
asaken#


So vlan 1 is going to have some simple ospf-routing command issued. This configuration step is similar if not 100% identical to a cisco ISR/ASR router.


config t
 
 
asaken(config-if)# int vlan 1        
asaken(config-if)# ipv6 ospf 10 area 0
asaken(config-if)#
asaken# sh run int vlan 1
!
interface Vlan1
 nameif inside
 security-level 100
 ip address 192.168.110.1 255.255.255.0
 ipv6 address 2002:100::1/64
 ipv6 nd reachable-time 3000
 ipv6 nd ns-interval 1200
 ipv6 nd dad attempts 2
 ospf cost 10
 ipv6 ospf 10 area 0
asaken#

note: if you enable a ipv6 router process on a interface with no ipv6 enabled, you will get a friendly reminder;

INFO: IPV6 not enabled on this interface. Router process not started.

To validate the  interface is setup for OSPFv3, we can deploy the following show command


asaken# show ipv6 ospf int

outside is up, line protocol is up  
  Link Local Address fe80::21f:caff:fef3:2111, Interface ID 15
  Area 0, Process ID 10, Instance ID 0, Router ID 192.168.110.254
  Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State WAITING, Priority 1
  No designated router on this network
  No backup designated router on this network
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 0:00:08
    Wait time before Designated router selection 0:00:29
  Graceful restart helper support disabled
  Index 1/1/1, flood queue length 0
  Next 0x0(0)/0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 0
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 0, Adjacent neighbor count is 0 
  Suppress hello for 0 neighbor(s)


I hope you find this post helpful. I will next explore  OPSFv3 authentication support on cisco NX-OS routers. Please stay tuned ;)

Ken Felix
your freelance Network and Security Engineer
kfelix "a@t" hyperfeed.com

Fortigate Firewall cfg script to speed up the configuration

I had a challenge with quickly producing a range of  fwpolicies/addess/ippools. So I want to share my  script generator tool that I used.

Let's say for an example, you needed to provide the following range of host a public nat-range.

{10.1.10.0/24    10-90 //  209.23.XXX/XXX/24  10-90 }

Will doing this one line by one line , could take for ever. :(

So a script can be use that crafts the range. In these examples, I 1st made an "fw-ippool  item"

configure firewall ippool

#!/bin/bash
for ((a=100; a <= 149 ; a++))
do

    echo  "edit XOpool-209.23.xxx.$a"
    echo  "set endip 209.23.xxx.$a"
    echo  "set startip 209.23.xxx.$a"
    echo  "next"

done

Next, I  add address entries for my inside hosts range 10.1.10.10-90;

#!/bin/bash
  for (( b=10; b <= 90 ; b++))
  do
    echo edit internal-server-01-$b
    echo    "set subnet 10.1.101.$b 255.255.255.255"
    echo   "next"
done

And lastly, I generate my fwpolicies;

#!/bin/bash
for ((a=100; a <= 149 ; a++))
do
echo "edit 0"
echo        "set srcintf WEBNETWORK-DMZ"
echo        "set dstintf EXTERNAT-OUTSIDE"
echo          "set srcaddr internal-server-01-$a"            
echo         "set dstaddr all"            
echo        "set action accept"
echo        "set schedule always"
echo           "set service ANY"            
echo        "set comments 1n1 SNAT something with starting address 10:10"
echo        "set nat enable"
echo        "set XOpool-209.23.xxx.$a enable"
echo        "set poolname 192.204.1.$a"            
echo   "next"
done

Now we build the cfgs and copy them into the firewall or use the batch cfg upload. This script can be used for a host of other profiles, and/or applications. So hack around with it, but it's start if  you need multiple repetive range of  the exact same item.

Ken Felix

DDoS protection via tcp intercept ( CISCO )

In my daytime  job, I work for a major cloud based DDoS mitigation provider. Here we have the luxury of cloud based mitigation  services for the major financial and market  dot coms types.

Cloud based mitigation is the ONLY way to fully mitigate  DDoS/DoS  attacks imho. It's smart, correct and superb when compared to legacy mitigation methods and devices ( ACL, IPS,FW-attach thresholds, FW DOS-anomaly engines,etc......)

Attempts at doing this mitigation locally ( at the customer edge )  is doomed to fail in most cases due to any of the following;

•  hardware resources are over taxed
•  even if your local router/firewall/ips blocks the attack traffic, your link is still over utilized and wasted bandwidth
•  more man-power from your IT staff is required ( during the duration of the attack)
•  your ISP links  have no way to distribute the attack traffic 
•  your ISP can only contribute very little to no-Support  in their effort to help you
• and it takes time for your ISP to place filters or policy rate limits
•  you have no way to fully determine if the attack has really subsided until you lift the lid to peek " so-to-speak"

Okay so what's this tcp intercept thing?

Will if you are stuck on a a cisco and have no cloud DDoS mitigation  provider, you have a limited  means to  protect against  TCP- SYN-FLOODS ( aka half-opens )

The router is not the best approach for this,  due to it's limited  cpu/memory and in a hugh sustained attacked, your router could become it's own denial-of-service :). But for low volume or amateurish tcp-SYN floods, you can deploy the tcp intercept feature as provided in most all cisco router codes  starting from  ios12.3 and onwards.

In order to understand the tcp-intercept, we need to re-educated one's self on the 3-way tcp-hand-shake. This hand shakes happens every time & for all tcp-sessions, when a validate tcp-session is being requested.

The  attacker community & underground, uses this knowledge to  launch  half-opens attacks,  by not  completing  the third step of the 3way hand-shake.

Here's the tcp-handshake 3 steps;

1: client  sends a  SYN -------->  to  Server  ( this is the 1st packet for tcp and holds the client  SPORT, server DPORT, MSS value, and any tcp-options )

2: Server  sends a SYN/ACK to the --------------> client  ( server sends his tcp MSS, tcp-options in this port back and startng seq# )

3: client   acks the  SYN/ACK with a ack to ---------> the server ( the final steps before we can start sending data )

Step #3 is what  DOES NOT happen when a syn-flood  attack takes place. As a matter of fact, the  sender is probably using a spoof'd & random  addres.

So in this attack, you try to exhaust a server  tcp-session table, which directly impacts memory consumption.  As more and more half-open sessions are being handle, the server can ultimately come to it's knees, drop valid sessions, or worst of all CRASH and Burn :)

Okay so how do we mitigate this on a cisco router?

We use  the tcp intercept feature. Here's the steps;

1: we craft a ACL. It's highly suggestive to always  build a acl to protect just the server(s) and service(s) that you want  DDoS mitigation for.  A  open  "ANY ANY" or all, would cause intercept to take place for ALL tcp-sessions, which can drive the  device  CPU high, during the inspection process.

It's also ideal to place the trusted internal networks into a deny statement,  before the final permits. For example, let's say you have a classic internal/dmz/external interfaces;

internal 172.18.0.0/24
dmz       172.19.0.0/24
external 7.7.7.0/30

You might want to or not want to  inspect traffic from dmz to internal or internal to dmz. So a ACL could be drafted like this;

!
ip access-list extend DDOS-protect
 remark ignore  lan to dmz
 deny tcp  172.18.0.0 0.0.0.255 172.19.0.0 0.0.0.255
 remark ignore dmz to internal lan
 deny tcp  172.19.0.0 0.0.0.255 172.18.0.0 0.0.0.255
 remark  okay now let's protect our servers in the DMZ
 permit tcp any host 172.19.0.10 eq 80
 permit tcp any host 172.19.0.11 eq 80
 permit tcp any host 172.19.0.12 eq 80
 permit tcp any host 172.19.0.13 eq 80
 permit tcp any host 172.19.0.14 eq 80
 permit tcp any host 172.19.0.15 eq 80
 permit tcp any host 172.19.0.16 eq 25
!
!

Okay now on to step #2

Here we need to determine if we want intercept or watch mode.

The latter only watches for the step #3  of the  tcp 3-way handshake,  and if not completed, it jumps in and send a RST ( reset ) to the server by spoof'ing the source address of the attacker that send the invalid SYN to begin with.

tcp intercept mode  intercept | watch 

With intercept mode, the  router is always in the middle and send a SYN/ACK back on behalf of the client  while watching for the final ACK in t he 3rd step of the tcp 3-way handshake. If the client is validate, the  router will allow the sessions to complete. The  Intercept mode, is more proccess intensive on the router/firewall/mitigation gear.

And finally we  monitor the  tcp intercept connection and statistic tables. Here's a snippet of those tables;

ccie01#show tcp intercept connections
Incomplete:
Client                Server                State    Create   Timeout  Mode
212.145.60.80:2262    8.8.8.2:22            SYNRCVD  00:00:10 00:00:04 I
244.215.180.20:2257   8.8.8.2:22            SYNRCVD  00:00:11 00:00:03 I
25.101.177.222:2229   8.8.8.2:22            SYNRCVD  00:00:14 00:00:00 I
252.125.104.173:2266  8.8.8.2:22            SYNRCVD  00:00:10 00:00:04 I
228.17.28.163:2233    8.8.8.2:22            SYNRCVD  00:00:13 00:00:01 I
192.209.96.45:2251    8.8.8.2:22            SYNRCVD  00:00:11 00:00:03 I
205.165.88.134:2323   8.8.8.2:22            SYNRCVD  00:00:03 00:00:03 I
234.143.146.118:2261  8.8.8.2:22            SYNRCVD  00:00:10 00:00:04 I
205.180.125.38:2236   8.8.8.2:22            SYNRCVD  00:00:13 00:00:01 I
17.116.9.244:2269     8.8.8.2:22            SYNRCVD  00:00:09 00:00:05 I
37.36.172.101:2331    8.8.8.2:22            SYNRCVD  00:00:02 00:00:00 I
148.50.177.94:2336    8.8.8.2:22            SYNRCVD  00:00:02 00:00:00 I
163.156.87.76:2206    8.8.8.2:22            SYNRCVD  00:00:16 00:00:14 I
139.219.70.132:2320   8.8.8.2:22            SYNRCVD  00:00:04 00:00:02 I
98.252.142.24:2223    8.8.8.2:22            SYNRCVD  00:00:14 00:00:00 I
148.53.60.231:2199    8.8.8.2:22            SYNRCVD  00:00:17 00:00:13 I
142.30.63.115:2348    8.8.8.2:22            SYNRCVD  00:00:01 00:00:01 I
125.229.73.124:2274   8.8.8.2:22            SYNRCVD  00:00:09 00:00:05 I
224.86.164.142:2211   8.8.8.2:22            SYNRCVD  00:00:16 00:00:14 I
10.233.170.98:2300    8.8.8.2:22            SYNRCVD  00:00:06 00:00:00 I
164.143.165.192:2342  8.8.8.2:22            SYNRCVD  00:00:01 00:00:01 I
19.36.6.77:2307       8.8.8.2:22            SYNRCVD  00:00:05 00:00:01 I
27.143.231.45:2249    8.8.8.2:22            SYNRCVD  00:00:11 00:00:03 I
196.25.239.187:1993   8.8.8.2:22            SYNRCVD  00:00:27 00:00:03 I
48.164.49.213:2325    8.8.8.2:22            SYNRCVD  00:00:03 00:00:03 I
177.164.197.252:2246  8.8.8.2:22            SYNRCVD  00:00:12 00:00:02 I
195.94.219.45:2281    8.8.8.2:22            SYNRCVD  00:00:08 00:00:06 I
200.162.177.58:2317   8.8.8.2:22            SYNRCVD  00:00:04 00:00:02 I
247.19.102.167:2339   8.8.8.2:22            SYNRCVD  00:00:02 00:00:00 I
4.96.45.248:2313      8.8.8.2:22            SYNRCVD  00:00:04 00:00:02 I
252.249.176.142:2278  8.8.8.2:22            SYNRCVD  00:00:08 00:00:06 I
10.164.115.63:2330    8.8.8.2:22            SYNRCVD  00:00:03 00:00:03 I
102.60.7.145:2350     8.8.8.2:22            SYNRCVD  00:00:00 00:00:00 I
211.127.67.63:2243    8.8.8.2:22            SYNRCVD  00:00:12 00:00:02 I
249.147.125.213:2297  8.8.8.2:22            SYNRCVD  00:00:06 00:00:00 I
10.239.19.75:2332     8.8.8.2:22            SYNRCVD  00:00:02 00:00:00 I
152.10.124.67:2288    8.8.8.2:22            SYNRCVD  00:00:07 00:00:07 I
156.223.156.199:2227  8.8.8.2:22            SYNRCVD  00:00:14 00:00:00 I
58.136.190.247:2264   8.8.8.2:22            SYNRCVD  00:00:10 00:00:04 I
12.17.9.234:2343      8.8.8.2:22            SYNRCVD  00:00:01 00:00:01 I
229.63.9.68:2215      8.8.8.2:22            SYNRCVD  00:00:15 00:00:15 I
231.136.194.117:2353  8.8.8.2:22            SYNRCVD  00:00:00 00:00:00 I
         
and



ccie01#show tcp intercept statistics 
Intercepting new connections using access-list DDOS-protect
205 incomplete, 0 established connections (total 205)
141 connection requests per minute










Notice the  counters named  incomplete? That will increase for every sessions that has been mitigated by the router.

Things to keep in mind;

1: the router can only handle so much traffic  ( half-opens ) and could fail-open  if the number of sessions exceed it's hardware limit

2: this is best effort only , and with a high PEAKs based attack and 500K plus  random sources, the router CPU could climb & cause other issues

3: cisco provides very limited tweaking in regards to this imho , once again best-effort


Okay you want to see how easy it is to  launch a tcp syn-flood using 2 of my  favorite attack tools :)

(hping)
hping -S --rand_source -p 80 -p 10255 "victims ip_address or hostname here "

(mausezahn)

mz vic0 -c 0 -d=100msec -A rand -B "victims ip_address|hostname here" -c 0 -t tcp "sp=1233,dp=80, flags=syn"

I hope you found this post useful

Ken Felix
Your Freelance Network and Security Engineer
kfelix "at/@" hyperfeed.com

Packet forging with sendip

 


Sendip is a great tool that allows for you too just about craft any packet type that commonly used. Unlike  hping, scapy,etc....... The tool use modules that you specify at the cli with the -p switch. 

It's probably less complex overall  in execution,  than scapy btw. The modules and functions allows what you can executed & the features within those protocols.

The supported  modules as of today are the following;

ipv4 ipv6 icmp tcp udp bgp rip ntp

So what this mean to me and you. We can have fun with the above protocols :)

Now, let look at why one would use sendip;

   1: the testing of IPS rules for a signature matches or expression filters
   2: executing testing of firewall state and session tables and it's controls
   3: wrecking havoc against a resource
   4: help with packet matching and signature creation
   5: for unethical activities
   6: to recreate a previous seen packet for analysis in a controlled environment


Okay that's some of the reason one would use sendip. The sendip  utility requires you to specify at least one module and their's dependencies on how you apply the modules. You can't  callout  for tcp.flag ACK and not have module tcp selected. Or icmp and not have ipv4 or ipv6.

For example, if you want to use BGP; you will need the modules ipv4+tcp+bgp. If you wanted to  craft a packet to simulate  SNMPget, you would need ipv4 +udp.

So what this means, from the cli , you would execute a few "-p" switches during your execution. 

Here's an example;  one of my SERT  team members in my dead-end day-job, wrote a threat advisory of an attack that was identified earlier. 

It  used a mss value of zero plus a few other  characteristics in the threat advisory.


I used sendip to craft the packet , so that I could write a signature and actually trigger that signature on my IDS for testing the validity of that threat and detection.

i.e ( using send ip )

sendip -p ipv4 -p tcp -ts 0 -tn 0 -td 80 -tomss 0 -tfs 1


This created the threat via modules ip and tcp, plus  tcp-syn packet with  dst port 80 (web), seq 0, ip.id 2  and mss value of 0.  A tcpdump of the packet will validate this  forged packet ;


2012-07-03 09:56:36.044893    127.0.0.1 -> 127.0.0.111  TCP 0 > http
[SYN] Seq=0 Win=65535 Len=0 MSS=0

Also tshark could have been used as an alternative

( tcp.seq == 0 && !(tcp.options.mss_val) && tcp.flags == 0x02 && ip.id == 0x0002  )

A signature could have been written just for this match, but better yet I wrote it just for a match of a mss_value  that equal 0. Since no valid tcp SYN or SYN/ACK packet should ever contain a mss value of zero for the start of a  tcp session, regardless of the  ip.id or sequence number. 

NOTE: This packet would be considered incorrect or  Deceivous,   just from a  mss value of 0.
 
Have a look at the sendip  tool and the capabilities that it allows. You will find strange and unique features within sendip,  that can be used for a host of reasons; both good or bad.




"Happy packet hunting"
 
Ken Felix
Freelance Security & Network  Engineer
kfelix " a t " hyperfeed.com

zone-based firewall cisco IOS from my CCIE/RS studies

ZBFW ( zone based firewalls ) are getting to be common  nowadays.

With cisco  ISR routers, a lot of SMB/Enterprise business are avoiding the expensive security firewalls and are deploying  inspections zones ,  using their l3 routers for these services.

ZBFW replaces the legacy cisco  CBAC  {Context-Based Access Control}  inspection and is much simpler to deploy. Here's some immediate differences;

•  no  inspect ACL list to manage ( optional )
•  creation and naming of zone-names
•  the use of simple inspection policies ( class-maps /policy-map )

Anybody who ever done CBAC should be aware of the issues with ACLs and directionality :) The  ZBFW,  makes this all so  much easier to deploy, review and troubleshoot.

Here's my steps for a simple  ZBFW configuration and design;

1. you really need to think about the protocols and services that you will and should allowed. Yes, this sounds stupid, but a lot of engineers deploy ZBFWs and forget this step.
2. be careful of the zone names and directionality
3. remember the class-default and the default drop within this class-map
4. remember you will need zone members+pairs for all interfaces that you want traffic to transverse , but if you have 2 interfaces that are not part of the ZBFW  pairs, then you DON'T NEED any zone-security pairings for traffic to flow
5. traffic can't flow from a zone member to a non-zone member

Here's my  CCIE/RS lab configurations;

created the zones:

 zone security inside
 description internal-trusted interface gi0/0


!
! my 2nd zone
!
zone security outside
 description external-untrusted interface gi0/1
!

So I now have 2 zones named inside and outside. They could have been called  in or out or number1 or number2.  Name is  not of major concerns, but it might be simple to keep the naming convention simple & to  represent the  directionality or functions or interface function.

Next, 

we create zone-pairs and in this case I went with a  2 zone-pairs setup (in2out and  out2in) , but we will later only configured in2out directionality ;

 
!
!
Zone-pair security in2out source inside destination outside
 description zone pair traffic from inside to external
 service-policy type inspect zp_in2out
!

!
zone-pair security out2in source outside destination inside
 description zone pair traffic from external to inside
!
!

I name mine zonepair  a simple name , and  gave a short description of these zone-pairs.

Now for traffic that we want to allow, I've create some  simple class-maps between these  zone-pairs. In this case, I'm only concerned with  traffic from my inside ( trusted )  networks out to the outside ( untrusted)

!
!
class-map type inspect match-all icmp
 match protocol icmp
class-map type inspect match-all HTTP
 match protocol http
class-map type inspect match-any WEBtraffic
 description match any web traffic on default 80/443 ports
 match protocol http
 match protocol https
class-map type inspect match-any POP
 match protocol pop3
 match protocol pop3s
 match protocol smtp
class-map type inspect match-any management-traffic
 description allow for  traffic to anything that we might manage
 match protocol ssh
 match protocol telnet
 match protocol snmp
class-map type inspect match-all DNS
 match protocol dns
class-map type inspect match-all HTTPend
!
!

Be cautious of the match-all vrs match-any. These can create a havoc when trouble-shooting and will wreck havoc if you have match-all and not all protocols are matched. Take heed of the class-map WEBtraffic  and we can match either HTTP or HTTPs due the match-any statement.


Next we need to  create a  policy-map type inspect for the inspection process. This determine rather we drop/pass/inspect  the traffic and types listed  in the  class-maps.

!
!
policy-map type inspect zp_in2out
 class type inspect icmp
  inspect
 class type inspect HTTP
  inspect
 class type inspect POP
  inspect
 class type inspect management-traffic
  inspect
 class type inspect DNS
  inspect
 class type inspect WEBtraffic
  inspect
 class class-default
  drop
!

!

Notice the class-default and the default action of to drop all traffic if it didn't match any of the other sequences of the "class type inspect".

And lastly, we  apply these zone-members to the L3 interfaces.

!

 interface GigabitEthernet0/0
 ip address 1.1.1.253 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 zone-member security inside
 duplex auto
 speed auto
 media-type rj45
 ipv6 address 2001:470:C021:1::1/64
 ipv6 enable

!
interface GigabitEthernet0/1
 description outside
 ip address dhcp
 ip nat outside
 ip virtual-reassembly in
 zone-member security outside
 duplex auto
 speed auto
 media-type rj45
!

And that will complete the ZBFW  configurations. To  ensure that we have  this properly configured, we can used the following show commands.

show zone security

show zone-pair security

show policy-map type inspect

show class-map type inspect

I hope this post was helpful

Ken Felix
Freelance Security/Network Engineer
kfelix " a t " hyperfeed.com