FIREWALL Implementation with DMZ and two inside ZONES

CISCO ASA Firewall DMZ/2_inside ZONES configuration

With Cisco ASA firewalls, you can integrate multiple enterprise-class, next-generation network security services without sacrificing performance. Cisco ASA combines the most deployed stateful inspection firewall in the industry with next-generation firewall capabilities.

I have a lab with a small scenario using the ASA Firewall, that I will demonstrate. In this scenario I will introduce a Security Firewall with four security zones and the config scripts. Two internal zones will be implemented on one interface with vlans and subinterface connection to the switch. The routers inside those zone have routing disabled, so they are acting as hosts. The DMZ zone will host a web server, again a router with ip routing disabled that will simulate a WEB server. We will focus only on the ASA configuration. There will be some restrictions for the inside zones. One zone will be denied some traffic and the other will have full access to all the outside traffic. 

Now, let us take a look at the diagram of this small scenario.

First we should define the interfaces and then other NAT/PAT configurations on the ASA firewall.

interface GigabitEthernet0/0 

description CONNECTION TO OUTSIDE INTERNET 

speed 100 

duplex full 

nameif outside 

security-level 0 

ip address 100.1.1.1 255.255.255.0

!

interface GigabitEthernet0/1 >> this interface will be used to subinterfaces for VLANs 10,20

no nameif 

no security-level 

no ip address 

! 

interface GigabitEthernet0/1.10 

description CONNECTION TO INSIDE 1 

vlan 10 

nameif 

inside1 security-level 80 

ip address 192.168.1.1 255.255.255.0 

! 

interface GigabitEthernet0/1.20 

description CONNECTION TO INSIDE 2 

vlan 20 

nameif inside2 

security-level 90 

ip address 192.168.2.1 255.255.255.0

!

interface GigabitEthernet0/2 

description CONNECTION TO DMZ 

nameif DMZ 

security-level 50 

ip address 10.0.0.1 255.255.255.0

Let us now define a object group for the interesanting ports.

object-group service WEB-PORTS tcp port-object eq 80 port-object eq 443

Now we should define the traffic to be NAT-ed and filtered. We use the access lists.

access-list OUTSIDE_IN extended permit tcp any host 100.1.1.2 object-group WEB-PORTS  << Internet->webserver.

access-list INSIDE1_IN extended permit tcp 192.168.1.0 255.255.255.0 any eq http  << Zone1 access to web and email

access-list INSIDE1_IN extended permit tcp 192.168.1.0 255.255.255.0 any eq https 

access-list INSIDE1_IN extended permit tcp 192.168.1.0 255.255.255.0 any eq smtp 

access-list INSIDE1_IN extended permit tcp 192.168.1.0 255.255.255.0 any eq pop3 

access-list INSIDE1_IN extended permit udp 192.168.1.0 255.255.255.0 any eq dns

access-list INSIDE2_IN extended permit ip 192.168.2.0 255.255.255.0 any   << allow all access ZONE2

As we have the traffic defined we can configur the Port Translation.

global (outside) 1 interface 

global (DMZ) 1 interface 

nat (inside1) 1 192.168.1.0 255.255.255.0 

nat (inside2) 1 192.168.2.0 255.255.255.0

As we have the outside access to the DMZ servers, we should create a static NAT entries for them.

static (DMZ,outside) 100.1.1.2 10.0.0.2 netmask 255.255.255.255

Next thing is to apply the access lists to aproppriate interfaces inside the firewall.

access-group OUTSIDE_IN in interface outside 

access-group INSIDE1_IN in interface inside1 

access-group INSIDE2_IN in interface inside2

For the clients to have a understating for the global networks we must setup a default route.

route outside 0.0.0.0 0.0.0.0 100.1.1.10 1

The last config script we should implement on ASA is to enable managament from one of the zones.

ssh 192.168.1.0 255.255.255.0 inside1 

ssh timeout 20 

ssh version 2

That is all to it for now.

Feel free to comment.

Introduction to Storage Area Networks

Storage Area Networking

A storage area network (SAN) is any high-performance network whose primary purpose is to enable storage devices to communicate with computer systems and with each other. We can also define the SAN network, as the network behind the servers. 

Even though this difference in protocols might seem trivial, it actually hints at the very essence of a SAN. Networks that depend on TCP/IP and SMB are primarily designed to access file system data. In other words, these types of networks are ideally suited for reading and writing files that are stored on file servers, Web servers, etc.
In contrast, Fibre Channel doesn’t work at the file level, but rather at the storage block level. As such, you wouldn’t use Fibre Channel to read a file that is stored on a file share. Instead, Fibre Channel reads and writes individual storage blocks.

A SAN can be used to bypass traditional network bottlenecks. It facilitates direct, high-speed data transfers between servers and storage devices, potentially in any of the following three ways:

1. Server to storage: This is the traditional model of interaction with storage devices. The advantage is that the same storage device might be accessed serially or concurrently by multiple servers.
2.   Server to server: A SAN might be used for high-speed, high-volume communications between servers.

3. Storage to storage: This outboard data movement capability enables data to be moved without server intervention, therefore freeing up server processor cycles for other activities like application processing. Examples include a disk device that backs up its data to a tape device without server intervention, or a remote device mirroring across the SAN.

Here is a small block diagram of SAN components that are building blocks of the SAN Fabric.

Fibre Channel connectivity is a bit more interesting. Hosts connect to a Fibre Channel SAN by using a host bus adapter. A host bus adapter is similar to a network card in that it gets installed into a slot within the server and provides connectivity to the SAN. The primary difference between host bus adapters and Ethernet adapters is that host bus adapters are designed to work with fiber optic cables rather than Ethernet cables. Another difference is that unlike Ethernet, Fibre Channel does not use the TCP/IP protocol or carry Ethernet packets.

Although network throughput does play a role in the overall speed of the connection, the main reason why Fibre Channel is so much faster than TCP/IP is because Fibre Channel is a more efficient protocol with less overhead. Having less overhead allows Fibre Channel to move data more quickly.

Here we can take a look of Cisco diagram that will show us the simplicity of the SAN frame.

 

The Fibre Channel Protocol (FCP) is the interface protocol of SCSI on Fibre Channel (FC). It is a gigabit speed network technology that is primarily used for storage networking. Fibre Channel is standardized in the T11 Technical Committee of the InterNational Committee of Information Technology Standards (INCITS), an ANSI accredited standards committee. It started for use primarily in the supercomputer field, but is now the standard connection type for SANs in enterprise storage. Despite its name, Fibre Channel signaling can run on both twisted-pair copper wire and fiber optic cables.

Fibre Channel Protocol (FCP) is a transport protocol (similar to TCP used in IP networks) that predominantly transports SCSI commands over Fibre Channel networks.

Fibre Channel Variants

NAME	Line-rate (GBaud)	Throughput (full duplex; MB/s)*	Availability
1GFC	1.0625	200	1997
2GFC	2.125	400	2001
4GFC	4.25	800	2004
8GFC	8.5	1,600	2005
10GFC	10.52	2,550	2008
16GFC	14.025	3,200	2011
32GFC	28.05	6,400	2014 (announced)

Switched fabric is probably the most widely used Fibre Channel topology today. It is by far the most flexible of the three topologies, but it is also the most expensive to implement. When it comes to SANs however, you usually get what you pay for.

I hope that I have shed some light on how SANs work. There is more to come.

Feel free to comment.

Layer 2 attack simulation on a Cisco router

Flooding CDP packets to a router

The Cisco Discovery Protocol (CDP) is a proprietary Data Link Layer protocol developed by Cisco Systems. It is used to share information about other directly connected Cisco equipment, such as the operating system version and IP address. CDP can also be used for On-Demand Routing, which is a method of including routing information in CDP announcements so that dynamic routing protocols do not need to be used in simple networks.

I will use a simple router vs linux scenario to perform a simple attack on a router with flooding the interfaces with CDP advertisements. A simple GNS3 lab is used to perform this attack.

A simple IP dhcp pool is configured on the Router R1 and the virtualized BackTrack 5 is used to perform and attack on the router. By default Cisco Discovery protocol is turned on every interface. Let us verify that we do not have any CDP neighbors and that there are no packets traversing trough the interface.

As we assumed no traffic is passing trough the router. To simulate an attack I will use the Yersinia tool.

Yersinia is a network tool designed to take advantage of some weakeness in different network protocols. It pretends to be a solid framework for analyzing and testing the deployed networks and systems. I will use the GUI under the BT 5 menu.

The next important thing, after starting the tool is to choose the type of the attack.

And the packets are starting to send via the eth0 interface. These fabricated packets are used to simulate CDP v2 adtertisements to the Router. We can verify that we are sending a large amount of packets in a small amount of time.

The final result can be seen on the Router R1. I have stopped the attack after couple of second. This prevented the denial on the routers memory resources so we can see the verify output.

We can see that we have 12000 CDP packets received on the Router in just a few seconds. To see what resulted in the CDP table is shown in the next graphic.

Router R1 has filled up the CDP table with bogus Device IDs and the list just goes on. This could very easilly in a manner of minutes flood the CDP table and took all of the router resources. 

The demonstration has taught us a one important thing. That is to disable the CDP advertisements on the Customer facing edge/WAN links. This way we are preventing the router to receive and send CDP advertisements. 

That is all for now.

Fell free to comment!

Configuring Apache server from source on Ubuntu server

How to build Apache server from source on Ubuntu

The Apache HTTP Server Project is an effort to develop and maintain an open-source HTTP server for modern operating systems including UNIX and Windows NT. The goal of this project is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards.
Apache httpd has been the most popular web server on the Internet since April 1996, and celebrated its 17th birthday as a project this February.

On a freshly installed Ubuntu 12.04 server we are going build the source file for the Apache web server. First thing we should do is to get the build-essential packet.

root@ubuntu-2:/# sudo apt-get install build-essential

Next thing is to get the source files. I prefer to keep the source file on the other location that is different that the home directory. So we will create a new folder. Under the root folder create a src folder.

root@ubuntu-2:/# mkdir src
root@ubuntu-2:/# cd src

Some browser support web page compression so we should install the Zlib. This is an opensource compression library.

root@ubuntu-2:/src# wget http://www.zlib.net/zlib-1.2.8.tar.gz

tar xvfz zlib-1.2.8.tar.gz
cd zlib-1.2.8/
./configure --prefix=/usr/local
make
sudo make install

Now we can download the Apache web  server source files.

cd..

wget http://download.nextag.com/apache//httpd/httpd-2.4.6.tar.gz

Extract the sources and enter the folder where they are located.

tar xvfz httpd-2.4.6.tar.gz
cd httpd-2.4.6

Next step is to configure the apache source files.

./configure --prefix=/usr/local/apache2 --enable-mods-shared=all
--enable-deflate --enable-proxy --enable-proxy-balancer --enable-proxy-http

If you ran on a problem with missing libraries, one can install them once more.

sudo apt-get install libapr1-dev libaprutil1-dev

The final step is to start the apache service:

sudo /usr/local/apache2/bin/apachectl start

Open up a browser and type in the external IP of the server. You should get this message:

It works!

The next step is to stop the apache we server and make an init script to run automatically.

sudo /usr/local/apache2/bin/apachectl stop
sudo cp /usr/local/apache2/bin/apachectl /etc/init.d/apachectl
sudo chmod +x /etc/init.d/apachectl
sudo /usr/sbin/update-rc.d apachectl defaults 


To test the startup scripts you should restart the server and then try to browse a page. If it does not work, you should check the logs folder inside the apache folder.

That is all for now.

Feel free to comment.

CheckPoint Firewall Virtualization and Installation

Step-by-step installation of CheckPoint Virtual Machine

VPN-1 is a stateful firewall which also filters traffic by inspecting the application layer. It was the first commercially available software firewall to use stateful inspection. Later (1997), Check Point registered U.S. Patent # 5,606,668 on their security technology that, among other features, included stateful inspection. VPN-1 functionality is currently bundled within all the Check Point's perimeter security products. The product, previously known as FireWall-1, is now sold as an integrated firewall and VPN solution.VPN-1 is one of the few firewall products that is still owned by its creators (Check Point Software Technologies). 

In this short, pictured guide I have installed and configured a Virtual Machine using the ESXi hypervisor to be used as the test scenario base ground. Let us now walk trough the screenshot guide of creating the machine and installing the actual firewall. First we should define the Machine Version, the newest version is preffered.

The next thing is to choose the Other Linux predefined Virtual machine template.

We can choose then as much CPU a virtualized setup has, I have choosen 1. The VM should have minimum 512 MB ram. I am installing R65 Version of the VPN-1 Firewall. Next step is to assign the network connected to the VM. In initial setup I have configured one NIC for administration, and later on one can use as many networks as needed.

I have allocated 12 GB of free space on the hypervisor subsystem storage. In real producation scenarios this should be a lot more.

The important final step is to assign the boot image of the downloaded R65 Firewall ISO image. 

After the machine boots, the automatic extraction of the ISO image is started. The initial setup of the CheckPoint r65 VPN-1 has started.

After the welcome screen , we press any key and the extraction of setup files begin.

If everything goes well during this setup, the SecurPlatform installation should then format the partitions it needs to boot the Firewall.

After the formating setups needs to restart and we should get the login screen. On first logon the Secure platform needs to have a new password and the user. The IP address assigned by the internal NIC of the R65 should be used as the one for the HTTP GUI administration.

So finally we are done with the console setup and we can type in the administration address in out Browser. The Google Chrome is not supported so I am ussing the Internet Explorer.

Now the last thing one needs to do is to type in the username and the password and the CheckPoint journey can begin. More to come on configs and scenarios simulations.

Feel free to comment.

IPV6 OSPF simple configuration

Simple IPV6 OSPF configuration

Open Shortest Path First (OSPF) is a routing protocol for IP. It is a link-state protocol, as opposed to a distance-vector protocol. A link-state protocol makes routing decisions based on the states of the links that connect source and destination machines. The state of a link is a description of that interface and the relationship to its neighboring networking devices. The interface information includes the IPv6 prefix of the interface, the network mask, the type of network it is connected to, the routers connected to that network, and so forth. This information is propagated in various type of link-state advertisements (LSAs)

Configuring OSPF under IPV6 has small, but simplified implementation techniques. Here are some important differences:

• Router-ID is still in a 32 bit format (example 1.1.1.1)
• Area configuration is done on the interface level
• We can have multiple processes under one interface either logic or physical

Here we have a simple scenario in with two Area OSPF configuration using the IPV6 protocol with sample global prefix IP addresses. 

So , next to examine the config files on all the routers. Router 4 is configured in Area 1 and all of the others are configured under the area 0. Before implementing any command scripts we must type in the following to enable proper IPV6 routing:

• ipv6 unicast-routing
• ipv6 cef

This is done on the global connfiguration mode. Let us see the rest of the important configuration on the routers.

R1

interface Loopback0

 ip address 1.1.1.1 255.255.255.255

 ipv6 address 3000::1/128

 ipv6 ospf 1 area 0

!

interface FastEthernet0/0

 no ip address

 duplex auto

 speed auto

 ipv6 address 3500::1/96

 ipv6 ospf 1 area 0

!

interface FastEthernet1/0

 no ip address

 duplex auto

 speed auto

 ipv6 address 2001::1/64

 ipv6 enable

 ipv6 ospf 1 area 1

!

ipv6 router ospf 1

 router-id 1.1.1.1

 log-adjacency-changes

R2

interface Loopback0

 ip address 2.2.2.2 255.255.255.255

 ipv6 address 3000::2/128

 ipv6 enable

 ipv6 ospf 1 area 0

!

interface FastEthernet0/0

 no ip address

 duplex auto

 speed auto

 ipv6 address 3500::2/96

 ipv6 ospf 1 area 0

!

ipv6 router ospf 1

 router-id 2.2.2.2

 log-adjacency-changes

R3

interface Loopback0

 ip address 2.2.2.2 255.255.255.255

 ipv6 address 3000::2/128

 ipv6 enable

 ipv6 ospf 1 area 0

!

interface FastEthernet0/0

 no ip address

 duplex auto

 speed auto

 ipv6 address 3500::2/96

 ipv6 ospf 1 area 0

!

ipv6 router ospf 1

 router-id 2.2.2.2

 log-adjacency-changes

R4

interface Loopback0

 ip address 4.4.4.4 255.255.255.255

 ipv6 address 2002::1/128

 ipv6 enable

 ipv6 ospf 1 area 1

!

interface FastEthernet0/0

 no ip address

 duplex auto

 speed auto

 ipv6 address 2001::2/64

 ipv6 enable

 ipv6 ospf 1 area 1

!

ipv6 router ospf 1

 router-id 4.4.4.4

 log-adjacency-changes

To further examine and verify we see the new changes that are not used under the IPV4 configuration. The area is configured under the interface level  ipv6 ospf 1 area 1. And we have kept the 32 bit format of the router-id address under the global router ospf proccess  router-id 4.4.4.4.

To verify we can see that we have advertised the loopbacks and the wan links. The DR/BDR election is done in similar way like in IPV4. The router-id are our loopback addresses.

R1#sh ipv6 ospf neighbor

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface

2.2.2.2           1   FULL/DROTHER    00:00:39    4               FastEthernet0/0

3.3.3.3           1   FULL/DR         00:00:38    4               FastEthernet0/0

4.4.4.4           1   FULL/DR         00:00:37    4               FastEthernet1/0

Now let us look at the routing table of the R1 as it is playing the role of the ABR router in this scenario.

R1#sh ipv6 route

IPv6 Routing Table - 10 entries

Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP

       U - Per-user Static route

       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary

       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2

       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2

C   2001::/64 [0/0]

     via ::, FastEthernet1/0

L   2001::1/128 [0/0]

     via ::, FastEthernet1/0

O   2002::1/128 [110/1]    <<< router R1 will propagate this route as InterArea

     via FE80::CE06:FF:FEFC:0, FastEthernet1/0

LC  3000::1/128 [0/0]

     via ::, Loopback0

O   3000::2/128 [110/1]

     via FE80::CE01:FF:FEFC:0, FastEthernet0/0

O   3000::3/128 [110/1]

     via FE80::CE02:FF:FEFC:0, FastEthernet0/0

C   3500::/96 [0/0]

     via ::, FastEthernet0/0

L   3500::1/128 [0/0]

     via ::, FastEthernet0/0

L   FE80::/10 [0/0]

     via ::, Null0

L   FF00::/8 [0/0]

     via ::, Null0

To verify the InterArea connectivity and the routing exchange we will ping the loopback address of the R4 from the R2 router using the loopback as the source address.

R2#ping 2002::1 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2002::1, timeout is 2 seconds:

Packet sent with a source address of 3000::2

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 20/45/72 ms

And we have a success. The routing OSPF domain has fully converged. Simple enough. More to come !!!

Feel free to comment.

OSPF Designated Router Election

OSPF force DR election

A designated router (DR) is the router interface elected among all routers on a particular multiaccess network segment, generally assumed to be broadcast multiaccess. The basic neighbor discovery process (Hello), flooding (224.0.0.6), DR election (priority, RID). Special techniques, often vendor-dependent, may be needed to support the DR function on nonbroadcast multiaccess (NBMA) media. It is usually wise to configure the individual virtual circuits of a NBMA subnet as individual point-to-point lines; the techniques used are implementation-dependent.

Do not confuse the DR with an OSPF router type. A given physical router can have some interfaces that are designated (DR), others that are backup designated (BDR), and others that are non-designated. If no router is DR or BDR on a given subnet, the BDR is first elected, and then a second election is held for the DR.

I have created a small Backbone area with three OSPF speaking routers. We can use this small scenario to see the election finished for the DR and the BDR. And also we can force our DR selection process. 

The configs are very simple. Every router has a Loopback IP, that is used as a ROUTER-ID in the OSPF domain. All the routers belong to the AREA 0 and have their connected networks associated to the area.

R1

interface Loopback0

 ip address 1.1.1.1 255.255.255.255

!

interface FastEthernet0/0

 ip address 172.16.1.1 255.255.255.0

 duplex auto

 speed auto

!

router ospf 1

 router-id 1.1.1.1

 log-adjacency-changes

 network 1.1.1.1 0.0.0.0 area 0

 network 172.16.1.0 0.0.0.255 area 0

R2

interface Loopback0

 ip address 2.2.2.2 255.255.255.255

!

interface FastEthernet0/0

 ip address 172.16.1.2 255.255.255.0

 duplex auto

 speed auto

!

router ospf 1

 router-id 2.2.2.2

 log-adjacency-changes

 network 2.2.2.2 0.0.0.0 area 0

 network 172.16.1.0 0.0.0.255 area 0

R3

interface Loopback0

 ip address 3.3.3.3 255.255.255.255

!

interface FastEthernet0/0

 ip address 172.16.1.3 255.255.255.0

 duplex auto

 speed auto

!

router ospf 1

 router-id 3.3.3.3

 log-adjacency-changes

 network 3.3.3.3 0.0.0.0 area 0

 network 172.16.1.0 0.0.0.255 area 0

To verify the DR and the BDR election , we can see the neighbor relationship on the R3. 

R3#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

1.1.1.1           1   FULL/DR         00:00:36    172.16.1.1      FastEthernet0/0

2.2.2.2           1   FULL/BDR        00:00:32    172.16.1.2      FastEthernet0/0

As we can see , the default election OSPF mechanism used the lowest IP address to elect the DR in the broadcast domain we have created. We can also check the status of the OSPF interface and see the priority for the OSPF election process. 

R1#sh ip ospf interface fastEthernet 0/0

FastEthernet0/0 is up, line protocol is up

  Internet Address 172.16.1.1/24, Area 0

  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1

  Transmit Delay is 1 sec, State DR, Priority 1

  Designated Router (ID) 1.1.1.1, Interface address 172.16.1.1

  Backup Designated router (ID) 2.2.2.2, Interface address 172.16.1.2

  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

    oob-resync timeout 40

    Hello due in 00:00:02

  Supports Link-local Signaling (LLS)

  Index 2/2, flood queue length 0

  Next 0x0(0)/0x0(0)

  Last flood scan length is 1, maximum is 1

  Last flood scan time is 0 msec, maximum is 0 msec

  Neighbor Count is 2, Adjacent neighbor count is 2

    Adjacent with neighbor 2.2.2.2  (Backup Designated Router)

    Adjacent with neighbor 3.3.3.3

  Suppress hello for 0 neighbor(s)

We can see a lot from this output. By default the OSPF uses the Highest Priority number for the DR election, and if every router in the BROADCAST network has the same, the the tie breaker is the lowest router-id.

Now we should change the topology. Say the the R3 has higher CPU resoruces and NVRAM capabalities, we will for the OSPF protocol to elect the R3 to become the Designated router for our broadcast network. This is done via a simple command on the interfaces that are responsible for the OSPF Hello packet sending, in our case the F0/0.

R1

R1(config)#interface fastEthernet 0/0

R1(config-if)#ip ospf priority 0

!

R1#clear ip ospf process

Reset ALL OSPF processes? [no]: y

R2

R2(config)#interface fastEthernet 0/0

R2(config-if)#ip ospf priority 0

!

R2#clear ip ospf process

Reset ALL OSPF processes? [no]: y

We have disabled the possibility for the R1 and R2 to become the DR router. After a couple of second we will setup the new , higher priority on the routers, that will force the R3 to become the DR, inspite of the highest router-id.

R1

R1(config)#interface fastEthernet 0/0

R1(config-if)#ip ospf priority 254

!

R1#clear ip ospf process

Reset ALL OSPF processes? [no]: y

R2

R2(config)#interface fastEthernet 0/0

R2(config-if)#ip ospf priority 255

!

R2#clear ip ospf process

Reset ALL OSPF processes? [no]: y

Now to verify the final output. 

R1#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

2.2.2.2         255   FULL/BDR        00:00:33    172.16.1.2      FastEthernet0/0

3.3.3.3           1   FULL/DR         00:00:37    172.16.1.3      FastEthernet0/0

We can now see that the R3 is the Designated router for the 172.16.1.0/24 subnet and the R2 has been relected as the Backup Designated router.

This is all to it.

Feel free to comment.

OSPF MD5 Authentification

Configure OSPF MD5 authentification

OSPF protocol relies on  the SPF algorhythm to calculate the changes in the LSA database, propagate LSA packets end form neighbor communication (as many other functions). OSPF is a great IGP in many scenarios, but the packets between the routers and firewalls can be intercepted and spoofed. This can be easily done , to mitigate a DDOS attack on a OSPF speaking router. 

I have configured two OSPF speaking routers to use the MD5 authentification in their backbone area. 

The basic configs to form the AREA 0 connectivity follows:

R1

interface Loopback0

 ip address 1.1.1.1 255.255.255.0

!

interface FastEthernet0/0

 ip address 192.168.1.1 255.255.255.252

 duplex auto

 speed auto

!

router ospf 1

 log-adjacency-changes

 network 0.0.0.0 255.255.255.255 area 0

R2

interface Loopback0

 ip address 2.2.2.2 255.255.255.255

!

interface FastEthernet0/0

 ip address 192.168.1.2 255.255.255.252

 duplex auto

 speed auto

!

router ospf 1

 log-adjacency-changes

 network 0.0.0.0 255.255.255.255 area 0

Now let us configure the MD5 Authentification on the Backbone Area. Notice that every router must use the MD5 encryption. If not that router cannot be apart of the Area 0.

R1

R1(config-router)#area 0 authentication message-digest

R1(config)#interface fastEthernet 0/0

R1(config-if)#ip ospf message-digest-key 1 md5 cisco

R2

R2(config-router)#area 0 authentication message-digest

R2(config)#interface fastEthernet 0/0

R2(config-if)#ip ospf message-digest-key 1 md5 cisco

After entering the auth scripts the neighbors form a relationship once more.

%OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on FastEthernet0/0 from LOADING to FULL, Loading

The last thing that is left is to verify that the OSPF Hello and Update packets are authentificated trough the proper interfaces. This can be done on both routers. 

R1#sh ip ospf interface fastEthernet 0/0

FastEthernet0/0 is up, line protocol is up

  Internet Address 192.168.1.1/30, Area 0

  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10

  Transmit Delay is 1 sec, State BDR, Priority 1

  Designated Router (ID) 2.2.2.2, Interface address 192.168.1.2

  Backup Designated router (ID) 1.1.1.1, Interface address 192.168.1.1

  Flush timer for old DR LSA due in 00:01:02

  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

    oob-resync timeout 40

    Hello due in 00:00:05

  Supports Link-local Signaling (LLS)

  Cisco NSF helper support enabled

  IETF NSF helper support enabled

  Index 1/1, flood queue length 0

  Next 0x0(0)/0x0(0)

  Last flood scan length is 1, maximum is 1

  Last flood scan time is 0 msec, maximum is 0 msec

  Neighbor Count is 1, Adjacent neighbor count is 1

    Adjacent with neighbor 2.2.2.2  (Designated Router)

  Suppress hello for 0 neighbor(s)

  Message digest authentication enabled

    Youngest key id is 1

We can see that we have succesfull key exchange now. We can further debug the adjancacies between the routers using the debug ip ospf adj. This is very helpful to see if the OSPF speaking routers will not form the neighbor relationship again.

Fell free to comment.

Implement DHCP Snooping - rogue prevention

Why we need to secure an Enterprise DHCP server ?

DHCP snooping is a security feature that acts like a firewall between untrusted hosts and trusted DHCP servers. The fundamental use case for DHCP snooping is to prevent unauthorized (rogue) DHCP servers offering IP addresses to DHCP clients. Rogue DHCP servers are often used in man in the middle or denial of service attacks for malicious purposes. However, the most common DoS scenario is that of an end-user plugging in a consumer-grade router at their desk, ignorant that the device they plugged in is a DHCP server by default.

DHCP snooping will drop DHCP messages from a DHCP server that is not trusted. Trusted DHCP servers are identified by configuring a switchport’s DHCP snooping trust state. DHCP server messages can flow through switchports that have a DHCP snooping trusted state. DHCP server messages will be dropped if attempting to flow through a switchport that is not trusted.

Now let us look at a small diagram I have created with a snooping switch and a DHCP L3 switch, with a rogue DHCP server inside the network.

First we should configure the snooping option on the global config via the Snooper switch CLI.

SNOOPER(config)#ip dhcp snooping

I have created a VLAN 100 , so we must enable DHCP packet snooping for this VLAN.

SNOOPER(config)#ip dhcp snooping vlan 100

Then we must setup trusted interface between the SNOOPER and the DHCP Server. This is a trunk interface configured to traverse all VLANs.

SNOOPER(config)#int fa0/11

SNOOPER(config-if)#ip dhcp snooping trust

This is all on can do for a simple DHCP SNOOPING option. This will prevent the ROGUE DHCP server to traverse DHCP packets to the VLAN100 and confuse the client PC.

More options one can set, in a more complex scenario can be bound found at this link.

Thanks.

DDOS attack mitigation via remote black hole

How to black hole (stop) an attacker inside your network

Remote triggered Black Hole filtering and preventing of spoofed, DDOS active subnets is a great way to save router resources and prevent the attacker from damaging your network. 

A common DoS attack directed against a customer of a service provider involves generating a greater volume of attack traffic destined for the target than will fit down the links from the service provider(s) to the victim (customer). This traffic "starves out" legitimate traffic and often results in collateral damage or negative effects to other customers or the network infrastructure as well.  Rather than having all destinations on their network be affected by the attack, the customer may ask their service provider to filter traffic destined to the target destination IP address(es), or the service provider may determine that this is necessary themselves, in order to preserve network availability.

However, with destination-based RTBH filtering, the impact of the attack on the target is complete.  That is, destination-based RTBH filtering injects a discard route into the forwarding table for the target prefix.  All packets towards that destination, attack traffic AND legitimate traffic, are then dropped by the participating routers, thereby taking the target completely offline.  The benefit is  that collateral damage to other systems or network availability at the customer location or in the ISP network is limited, but the negative impact to the target itself is arguably increased.

In this small scenario I will use a eBGP speaking router that will advertise the "spoofed DDOS subnet" of 99.99.99.0/24. All of the iBGP routers inside the AS100 domain will have this prefix installed in the BGP table. 

The iBGP router CX2 is used as a trigger device, that has a simple task, to advertise the DDOS prefix inside the AS100, 

and put those packets inside the Black Hole. Let us use the configuration of the Trigger router.

CX2

interface Loopback1
 ip address 192.0.2.1 255.255.255.255

!

route-map BLACK-HOLE permit 10
 match tag 999
 set local-preference 200
 set origin igp
 set community no-export
 set ip next-hop 192.0.2.1
!
route-map BLACK-HOLE deny 20

!

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 5.5.5.5 mask 255.255.255.255
 redistribute static route-map BLACK-HOLE
 neighbor 16.2.1.1 remote-as 100
 neighbor 18.1.1.2 remote-as 100
 no auto-summary

We have created a simple route map that will tagg the static route of our given prefix and set the next hop towards the 192.0.2.1 interface. 

This address belongs to the discard address space. Every other iBGP router must have a 

static route for the 192.0.2.1 address that points those packets to the NULL0 interface.

CX1#ip route 192.0.2.1 255.255.255.255 Null0

Customer#ip route 192.0.2.1 255.255.255.255 Null0



Now let us take a look at the BGP table of the CX1 router. We can see the 99.99.99.0 prefix is being advertised 

into the table and we have connectivity with the SPOOFED address.


CX1#sh ip bgp 99.99.99.0
BGP routing table entry for 99.99.99.0/24, version 18
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  200 65535
    16.1.1.2 from 16.1.1.2 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best




We can test the route by pinging the spoofed address. 


CX1#ping 99.99.99.1 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 99.99.99.1, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/74/96 ms








Now to deny this traffic trough the AS100 we must redistribute and create a static route on the 

trigger router 

that will be distributed inside the AS100. I will let a long ping period from the CX1 router to 

demonstrate how the traffic stops inside the AS100 as soon as I create the static route for the 99.99.99.0/24 subnet.









As soon as I typed in the static route the PING has stopped. And if we look at the BGP table of 

the CX1 router now, we can se that the route is being advertised from the TRIGGER router

, and the next-hop is set to the 192.0.2.1 , the discard IP address.

CX1#sh ip route 99.99.99.0
Routing entry for 99.99.99.0/24
  Known via "bgp 100", distance 200, metric 0, type internal
  Last update from 192.0.2.1 00:02:23 ago
  Routing Descriptor Blocks:
  * 192.0.2.1, from 16.2.1.2, 00:02:23 ago
      Route metric is 0, traffic share count is 1
      AS Hops 0

This very simple DDOS mechanism can be used in more complex scenarios, with redundant Route Reflectors inside a large BGP domain. 

One can stop an attacker in a very short time 

period. There are more explanations on the RFC5635 document.

Feel free to comment.

BGP Communities - routes reside inside the local AS

Setting the NO-EXPORT BGP community 

BGP communities are attributes that maybe added to every prefix we choose. This is very interesting if one wants to logically separate incoming and outgoing traffic. With communities we have more granular control over the data plane inside our Autonomus system. 

The communities attribute is a way to group destinations into communities and apply routing decisions based on the communities. This method simplifies the configuration of a BGP speaker that controls distribution of routing information.

The communities attribute is an optional, transitive, global attribute in the numerical range from 1 to 4,294,967,200. Along with Internet community, there are a few predefined, well-known communities, as follows:

• internet—Advertise this route to the Internet community. All routers belong to it.
• no-export—Do not advertise this route to eBGP peers.
• no-advertise—Do not advertise this route to any peer (internal or external).
• local-as—Do not advertise this route to peers outside the local autonomous system. This route will not be advertised to other autonomous systems or sub-autonomous systems when confederations are configured.

In this small case scenario we have a customer AS 100 that does not want some prefixes to be advertised outside his own AS. Maybe the prefixes are malicious, or they have no agreement with the ISP companies or within any other reason this can be done with using the BGP default community NO-EXPORT. Let us take a look into the diagram.

In our small example we will be looking at the CX1 router and some of the ISP routing tables. First let us take a look at the BGP configs of the CX1 router, and the BGP table of the ISP2 router.

We can see that the ISP2 router has the two prefixes inside the RIB table. Those the prefixes we do not want to advertise outside the AS100. This is achieved via a simple route-map and an ACL that is associated with the desired traffic.

CX1#sh ip access-lists

Standard IP access list 1

    10 permit 44.44.44.0, wildcard bits 0.0.1.255 (2 matches)

CX1#sh route-map

route-map NO-EXPORT, permit, sequence 10

  Match clauses:

    ip address (access-lists): 1

  Set clauses:

    community no-export

  Policy routing matches: 0 packets, 0 bytes

CX1

neighbor 16.1.1.2 send-community both

 neighbor 16.1.1.2 route-map NO-EXPORT out

We have an ACL that is used to capture source of loopback address advertised with the prefixes 44.44.44.0/24 and 44.44.45.0/24. After that I have created an route-map called NO-EXPORT that uses the acl 1 and sets the community no-export on those prefixes. Then we have applied this route map to the neighbor inside the AS100.

Now let us see the RIB table of the ISP2 router.

And it is working fine, we do not see the prefixes we stopped to advertise. We can verify this further on the edge router of the AS100. 

CUSTOMER#sh ip bgp neighbors 172.16.1.2 advertised-routes

BGP table version is 11, local router ID is 1.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 1.1.1.1/32       0.0.0.0                  0         32768 i

*> 2.2.2.2/32       192.168.1.2              0             0 200 i

*> 3.3.3.3/32       172.16.1.2               0             0 300 i

*>i5.5.5.5/32       17.1.1.2                 0    100      0 i

We can see that the prefixes are not being advertised to the eBGP neighbor as we intended. Down following we can see the BGP table of the AS100 edge router.

Total number of prefixes 4

CUSTOMER#sh ip bgp 44.44.44.0

BGP routing table entry for 44.44.44.0/24, version 10

Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)

  Not advertised to any peer

  Local

    16.1.1.1 from 16.1.1.1 (4.4.4.4)

      Origin IGP, metric 0, localpref 100, valid, internal, best

      Community: no-export

The prefix 44.44.44.0 is in the routing table but it has the no-export community attached to the route. Thus the prefix is not being exported to the eBGP neighbors. Very simple and clean.

Feel free to comment.

Influence routing with BGP AS-Path prepend

Inbound traffic control with BGP prepending

Border Gateway Protocol has a rich set of attributes and combines them with built in algorithm to detect and install the best path to a certain NLRI. I will explain in further blogs how BGP uses the Best Path Selection algorithm to install the best path into to the table. In this particular scenario the tiebraker is the shortest AS Path. When a router sees a route with two BGP AS paths it will install the route with the shortest one in the table. This BGP feature can be used to influence how traffic flows into the Autonomous system. 

I have created a small scenario with 3 eBGP speaking routers. The customer is multi-homing two links towards the ISP cloud, and we will manipulate how the inbound traffic will flow (which links will be used).

Every eBGP router will be configured to advertise the loopback IP address via BGP. After the initial configs we will look at the BGP table of the ISPs and the Customer router.

CUSTOMER

interface Loopback0

 ip address 1.1.1.1 255.255.255.255

!

interface Serial0/0

 ip address 192.168.1.1 255.255.255.252

 serial restart-delay 0

!

interface Ethernet1/0

 ip address 172.16.1.1 255.255.255.252

 half-duplex

!

router bgp 100

 no synchronization

 bgp router-id 1.1.1.1

 bgp log-neighbor-changes

 network 1.1.1.1 mask 255.255.255.255

 neighbor 172.16.1.2 remote-as 300

 neighbor 192.168.1.2 remote-as 200

 no auto-summary

ISP1

interface Loopback0

 ip address 2.2.2.2 255.255.255.255

!

interface Serial0/0

 ip address 192.168.1.2 255.255.255.252

 serial restart-delay 0

!

interface Ethernet1/0

 ip address 10.0.0.1 255.255.255.252

 half-duplex

!

router bgp 200

 no synchronization

 bgp router-id 2.2.2.2

 bgp log-neighbor-changes

 network 2.2.2.2 mask 255.255.255.255

 neighbor 10.0.0.2 remote-as 300

 neighbor 192.168.1.1 remote-as 100

 no auto-summary

ISP2

interface Loopback0

 ip address 3.3.3.3 255.255.255.255

!

interface Ethernet0/0

 ip address 10.0.0.2 255.255.255.252

 half-duplex

!

interface Ethernet0/1

 ip address 172.16.1.2 255.255.255.252

 half-duplex

!

router bgp 300

 no synchronization

 bgp router-id 3.3.3.3

 bgp log-neighbor-changes

 network 3.3.3.3 mask 255.255.255.255

 neighbor 10.0.0.1 remote-as 200

 neighbor 172.16.1.1 remote-as 100

 no auto-summary

We can inspect now the RIB of the ISP1 router. To reach the 1.1.1.1 prefix to the customer router it will use the shortest path via the Serial WAN link.

ISP1#sh ip bgp 1.1.1.1

BGP routing table entry for 1.1.1.1/32, version 3

Paths: (2 available, best #2, table Default-IP-Routing-Table)

  Advertised to update-groups:

     1

  300 100

    10.0.0.2 from 10.0.0.2 (3.3.3.3)

      Origin IGP, localpref 100, valid, external

  100

    192.168.1.1 from 192.168.1.1 (1.1.1.1)

      Origin IGP, metric 0, localpref 100, valid, external, best

As we can see the shortest AS path with only on AS Hop (100) is used to get to the prefix 1.1.1.1/32. As this is the best path the traceroute from the ISP1 router to the CUSTOMER networks will also follow the Serial WAN link. 

ISP1#traceroute 1.1.1.1 source loopback 0

Type escape sequence to abort.

Tracing the route to 1.1.1.1

  1 192.168.1.2 44 msec 20 msec 16 msec

If one should prefer the faster Ethernet WAN link via the ISP2 router we should create a ROUTE-MAP that will prepend our AS 100 several time, so after that the Serial WAN link should not be considered best after that.

CUSTOMER#sh route-map

route-map PREPEND, permit, sequence 10

  Match clauses:

  Set clauses:

    as-path prepend 100 100 100 100

  Policy routing matches: 0 packets, 0 bytes

The traffic that is going to be prepended with several AS100 paths in the vector is going to be filtered via the neighbor statement under the BGP Process.

CUSTOMER(config-router)#neighbor 192.168.1.2 route-map PREPEND out

To take effect we should use the Route Refresh BGP feature.

CUSTOMER#clear ip bgp 192.168.1.2 soft

Now we can see a change in the BGP RIB of the ISP1 router. The Serial WAN link is no more preffered as the best path for the 1.1.1.1 prefix. So now ISP1 reaches the Customer router via the ISP2 link. 

ISP1#sh ip bgp 1.1.1.1

BGP routing table entry for 1.1.1.1/32, version 6

Paths: (2 available, best #1, table Default-IP-Routing-Table)

Flag: 0x820

  Advertised to update-groups:

     1

  300 100

    10.0.0.2 from 10.0.0.2 (3.3.3.3)

      Origin IGP, localpref 100, valid, external, best

  100 100 100 100 100

    192.168.1.1 from 192.168.1.1 (1.1.1.1)

      Origin IGP, metric 0, localpref 100, valid, external

If we do another traceroute , we will see that the preffered path to reach the CUSTOMER subnets, is via the Ethernet WAN link , towards the ISP2. All of the inbound traffic towards the CUSTOMER is now rerouted to this link. 

ISP1#traceroute 1.1.1.1 source loopback 0

Type escape sequence to abort.

Tracing the route to 1.1.1.1

  1 10.0.0.2 44 msec 20 msec 16 msec

  2 172.16.1.1 60 msec *  28 msec

We have achieved also a small redundancy here, because we can still reach some subnets from the ISP1 via the Serial Link, but all of the inbound traffic is now utilizied over the Ethernet Link, that is faster.

Feel free to comment.