There are 3 ways to configure NAT on a Cisco Router
1/ Static NAT
2/ Dynamic NAT
3/ NAT overload (PAT – Port Address translation)

Static NAT is a one-to-one mapping. This is usually only required when you have a server inside your network (ie: Webserver, FTP, E-mail) that needs to be accessed from the internet. Users on the internet will access a public IP address that you have statically and permanently linked to your servers internal IP address. Of course any time your internal server sends packet to the internet, it’s source IP address will be translated into a public IP address configured with static NAT.

Dynamic NAT is used for many-to-many mapping. This will allow all your internal computers to be translated into a pool of public IP addresses, however if you only have 10 public IP addresses available in the NAT pool, only 10 computers will be able to access the public network at a time. Each computer will consume one public address at a time which makes this very limited for public internet access. The main purpose for dynamic NAT is to fix overlap IP addresses often experienced after a merger or acquisition. Since all companies use RFC 1918 for internal addresses, it’s not uncommon for 2 companies to be using the exact same internal IP addresses. When a merger or acquisition takes place there are issues with the IP addresses conflicting. Dynamic NAT allows us to translate the internal IP addresses from company ‘A’ into something unique that company ‘B’ does not use, and similarly translate all the internal IP addresses in company ‘B’ into something unique that company ‘A’ does not use. In most cases the ‘public’ address that the two companies will be translated into, will be part of RFC 1918 and will be used purely to resolve IP address overlaps, and NOT internet access.

NAT overload, or otherwise known as PAT (Port Address Translation), allows us to create a many-to-one mapping. Every computer in your network will be translated into a single Public IP address. This allows us to save on public addresses but still allows each computer in our organisation to access the internet at the same time. PAT identifies each session based on the source port number used in the communication flow. Since each session uses a random source port number, each session in theory should have a different number which allows PAT to associate a session with the single public IP addresses been shared. In the occurrence of two computers randomly choosing the same source port number, PAT will translate the port number and keep a record of the original as well as the new translated port to maintain the session. PAT will not allow internet users to access your internal servers as there is no mapping from outside to inside. The maximum theoretical limit for sharing a single IP address is 64,513 however the practical limit is dependent on the router or firewall doing the PAT and is usually limited to no more than 4,000 sessions to a single IP address.

Related posts:

1. Useable IP addresses in private networks
2. IP Address Spoofing Mitigation with Access Control Lists (ACL)
3. Port Security on a Cisco Switch

Ether Channels can be created as Layer 2 or Layer3. The obvious difference between the 2 is that a Layer 3 link will have a IP address associated and hence traffic can be routed between the 2 switches. A layer 2 ether channel will not have IP addresses attached and all traffic will be switched between the 2 devices.

There is a misconception about how the ‘load balancing’ works over a ether channel, so firstly lets clear that up.

An ether channel allows us to group multiple interfaces together so they act as one. This means that if I have 5 x 1 Gigabit Ethernet interfaces that I bind together I will in theory have a 5 Gigabit Ethernet interface. This is partly true but let’s dig deeper into how the switch will send traffic over the new link.

By Default, most Cisco switches are configured with a load balancing option of ‘source to destination IP’, what this means is that when the first session is created between machine A and machine B their traffic will use the same physical interface from the ether channel bundle. The packets will not be load balanced between all the ports. However when machine C sends traffic to machine D they would use a different physical interface compared to machine A and B. What we can derive from this, is that the load-balancing is session orientated and each session will be limited to 1 physical interface. So although the total throughput of data between the 2 switches is 5 Gigabit, the maximum throughput between 2 machines is the total of 1 physical interface of the ether channel.

The load-balancing technique can be changed from its default using the port-channel load-balance command, as seen below.

port-channel load-balance {src-mac | dst-mac | src-dst-mac | src-ip | dst-ip | src-dst-ip | src-port | dst-port | src-dst-port}

NOTE: not all switches support all options of load-balancing!

So now that we have seen the concept of Ether Channels and how their load-balancing works, here is the configuration for configuring a Layer 2 Ether Channel.

AOIP.ORG-Switch(config)# interface range f0/4 – 5

The interface range command allow me to configure multiple interfaces at the same time, in this case FastEthernet 0/4 and 0/5

AOIP.ORG-Switch(config-if-range)# channel-group 1 mode desirable

This associates the interfaces to a new logical interface and tells the interface to actively negotiate a trunk.

AOIP.ORG-Switch(config-if-range)# no shut

AOIP.ORG-Switch(config-if-range)# exit

AOIP.ORG-Switch(config)# exit

In order to configure a Layer 2 Ether Channel, the following configuration can be used.

AOIP.ORG-Switch(config)# interface port-channel 10

This enters the logical interface used for the Ether Channel, I have given it a ‘name’ of 10

AOIP.ORG-Switch(config-if)# no switchport

Forces the port to act as a routed port and not a switchport

AOIP.ORG-Switch(config-if)# ip address 10.0.100.1 255.255.255.0

Assigns the IP address to the interface

AOIP.ORG-Switch(config-if)# no shut

AOIP.ORG-Switch(config-if)# exit

AOIP.ORG-Switch(config)# interface range f0/4 -5

Same as above, I’m configuring 2 interfaces to belong to the Ether Channel

AOIP.ORG-Switch(config-if-range)# no switchport

Forcing the physical ports in Routed ports

AOIP.ORG-Switch(config-if-range)# no ip address

Removing any IP addresses that may be configured on the physical interfaces. They may not have an IP address as it will be associated to the logical interface (port-channel 10)

AOIP.ORG-Switch(config-if-range)# channel-group 10 mode desirable

Binds the physical interfaces to the logical interface

AOIP.ORG-Switch(config-if-range)# no shut

AOIP.ORG-Switch(config-if-range)# exit

AOIP.ORG-Switch(config)# exit

Related posts:

1. Inter-VLAN Routing (Router on a Stick)
2. ISDN and Multilink with load-threshold
3. Configuring SPAN on a Cisco Switch

ISDN BRI (Basic Rate Interface) interfaces have 2 B-channels. By default when you create a connection using ISDN only one of these channels will dial. In order for us to use the additional B-channel we need to insert an additional command under our BRI interface (PPP Multilink)

Similarly ISDN PRI (Primary Rate Interface) interfaces have (23 B-Channels on T1, 30 B-Channels on E1) each of the channels on a PRI line run at 64kb/s and often we would like to use more than just one channel for our backup.

Although we can have all channels connect immediately when the ISDN becomes active; this results in all lines been billed by the PSTN. Instead we would rather have additional lines been brought up one at a time when the traffic demands it. We can achieve this by defining a load threshold that the line must be under before bringing up additional channels.

The load-threshold command is on a scale from 1 to 255 where 255 is equal to 100% utilisation.

AOIP.ORG(config)# interface bri 2/0
AOIP.ORG(config-if)# ppp multilink
AOIP.ORG(config-if)# dialer load-threshold 128 either

In the above example, I have set a threshold of 128 (50%) and this is based on traffic either inbound or outbound. In order to only monitor traffic inbound, replace ‘either’ with inbound. The same applied to outbound traffic.

NOTE: In order to use PPP multilink, both sides of the link need to be configured for its use.

Related posts:

1. ISDN Switch-type
2. Configuring Basic ISDN with Interesting Traffic
3. Creating Layer 2 and Layer 3 Ether Channels

Using floating static routing as a backup solution works on the following principle.

-          A dynamic routing protocol is running over your primary line

-          When the link fails, the routing updates will fail and the routing table will flush

-          A static route that uses the dial-up interface will become the best route

-          The backup interface will dial and traffic will continue to flow

-          When the primary line comes back up the dynamic routing protocol will fill the routing table, overwriting the floating static.

NOTE: Any type of dial-up interface may be used (modem / ISDN / 3G etc)

Based on the above it’s important to understand a few things about routing.

-          A router will look for a route with the longest match (most specific route wins).

-          If more than one identical route exists, the route with the LOWEST administration distance will be inserted into the routing table

So in order for us to configure floating static routes, we need 2 things configured.

-          A dynamic routing protocol MUST be configured for this solution

-          An identical static route must be created with an administrative distance higher than our routing protocol.

Example:

If I am running EIGRP as my routing protocol and it has learnt a route to network 192.168.1.0 /24 with an admin distance of 90 ( EIGRP has an administrative distance of 90 by default). I must create a static route for the network 192.168.1.0 /24 with a next hop of my remote routers dial-up interface. A static route however has a default administrative distance of 1, which at this point would mean it would overwrite my dynamically learnt route and all my traffic would be sent over my dial-up interface leaving me with a rather large phone bill. So when I create my static route it’s imperative that I change the default administrative distance to something higher than that of my routing protocol – I suggest a value of 250.

My static route would look like this:

AOIP.ORG(config)# ip route 192.168.1.0 255.255.255.0 10.0.1.1 200

Destination network : 192.168.1.0

Subnetmask for destination : 255.255.255.0

Next hop address of the remote routers dial-up interface: 10.0.1.1

Administrative Distance : 200

Related posts:

1. Static Routing
2. ISDN and Multilink with load-threshold
3. Cisco Administrative Distance

For example: If I define an access-list that allows telnet and denies everything else, then telnet is the only traffic that will cause my ISDN interface to dial the remote router. Once the line has connected, ANY traffic may flow over the ISDN line. The router is looking purely for ‘interesting traffic’ so if no telnet traffic is sent over the line for the idle-timeout value, the line will drop.

This type of installation of ISDN is fantastic for very small branch offices that do not need to be connected to HQ permanently and you only need the link to be established for short periods of time. This however is not a good link backup solution.

In the below configuration we have created an access-list that will allow telnet traffic to cause the link to be established.

AOIP.ORG(config)# access-list 102 permit tcp any any eq telnet

Create the Access-list to be used to specify interesting traffic

AOIP.ORG(config)# dialer-list 2 protocol ip list 102    

The dialer-list defines what traffic is interesting, in this case – Access list 102

AOIP.ORG(config)# isdn switch-type basic-net3

Define the switch-type needed for ISDN, This is the settings for BRI interfaces in Europe and Africa

AOIP.ORG(config)# int bri 2/0

Enter the BRI interface you wish to configure

AOIP.ORG(config-if)# ip address 10.0.1.1

Set an IP address on the ISDN interface

AOIP.ORG(config-if)# encapsulation ppp

Define PPP as the encapsulation method

AOIP.ORG(config-if)# ppp authentication chap

Authentication for PPP has been set to CHAP

AOIP.ORG(config-if)# dialer-group 2

This tells our ISDN interface to use Dialer-list 2, you will notice the numbers for ‘dialer-group’ and ‘dialer-list’ match

AOIP.ORG(config-if)# dialer idle-timeout 180

If no interesting traffic is sent for 180 seconds, the line will drop

AOIP.ORG(config-if)# dialer map ip 10.0.1.2 name Router2 5551234  

If you need to connect to the IP address 10.0.1.2 (The remote routers ISDN interface), The remote router is name “Router2” and the telephone number to dial is “5551234”

AOIP.ORG(config-if)# no shut

AOIP.ORG(config)# ip route 192.168.2.0 255.255.255.0 10.0.1.2

Create a static route for the remote subnet with a next hop of Router2’s ISDN interface.

AOIP.ORG(config)# username Router2 password aoip

The remote routers hostname and a password that will be used for PPP authentication

Related posts:

1. ISDN and Multilink with load-threshold
2. ISDN Switch-type
3. Floating Static Routes

The switch-type is very much country dependant so it’s also important to memorize the switch-type that applies to where you do most of your installations.

If Layer-1 is showing ‘Deactivated’ when using the show isdn status command, only 3 things can be the source of the problem.

1/ isdn switch-type has not been set, or has not been set correctly (The most common problem)

2/ There is a problem with the PSTN (call your telephony service provider)

3/ Cable problems

4/ Physical port failure on the Router.

In order to configure the switch-type you can enter the command

Isdn switch-type {switch-type}

This can be done either in global configuration mode, or on the interface depending on the router and IOS version.

Below are all the switch-type options available 

Related posts:

1. Configuring Basic ISDN with Interesting Traffic
2. ISDN and Multilink with load-threshold
3. Floating Static Routes

The main aim of a TCP SYN flood is to send a TCP SYN packet to a host inside your network from a spoofed IP address. The TCP SYN ACK is then sent to a machine that is not expecting one, or a machine that doesn’t exist. This causes a ‘half-opened’ connection (Embryonic Connection) to exist since the 3-way handshake has not completed with a ACK.

A Cisco router is only capable of having a certain amount of connections open to it (This is different depending on the router model) so if an attacker was to send thousands of spoofed TCP SYN packets the router would reach maximum allowed connections, even though the connections are not complete. This would prevent the router from allowing legitimate connections been created.

In order to completely fix this problem, a firewall that supports dynamic embryonic connections would need to be installed, however a router can prevent the flood of TCP SYN packets by disallowing connections from the outside coming into your network.

This means that only connections that were created from inside your network would work and all connections from the outside would be denied.

Here is the configuration breakdown. (FastEthernet 0/0 is the outside network)

AOIP.ORG(config)# access-list 101 permit tcp any 192.168.1.0 0.0.0.255 established

AOIP.ORG(config)# access-list 101 deny ip any any log

AOIP.ORG(config)# interface fa0/0

AOIP.ORG(config-if)# ip access-group 101 in

AOIP.ORG(config-if)# exit

AOIP.ORG(config)#

Related posts:

1. IP Address Spoofing Mitigation with Access Control Lists (ACL)
2. Mitigating SubSeven attacks
3. Mitigating Smurf DoS Attacks

The name SubSeven was derived by reversing the word Netbus (also a famous backdoor program) and replacing with the world ‘ten’ with ‘seven’

netbus = subten = subseven

In order to mitigate this application from attacking your network the following Access-list can be configured on your routers interfaces. Most Anti-Virus programs will also prevent it from attacking your machine.

AOIP.ORG(config)# access-list 100 deny tcp any any eq 1243 log

AOIP.ORG(config)# access-list 100 deny tcp any any eq 2773 log

AOIP.ORG(config)# access-list 100 deny tcp any any range 6711 6713 log

AOIP.ORG(config)# access-list 100 deny tcp any any eq 6776 log

AOIP.ORG(config)# access-list 100 deny tcp any any eq 7000 log

AOIP.ORG(config)# access-list 100 deny tcp any any eq 7215 log

AOIP.ORG(config)# access-list 100 deny tcp any any eq 27374 log

AOIP.ORG(config)# access-list 100 deny tcp any any eq 27573 log

AOIP.ORG(config)# access-list 100 deny tcp any any eq 54283 log

AOIP.ORG(config)# access-list 100 permit ip any any

AOIP.ORG(config)# interface fa0/0

AOIP.ORG(config-if)# ip access-group 100 in

AOIP.ORG(config-if)# exit

AOIP.ORG(config)# interface fa0/1

AOIP.ORG(config-if)# ip access-group 100 in

AOIP.ORG(config-if)# exit

AOIP.ORG(config)#

Related posts:

1. Mitigating Smurf DoS Attacks
2. IP Address Spoofing Mitigation with Access Control Lists (ACL)
3. DoS TCP SYN Attack Mitigation

The enable password by default is saved in clear text so when looking at the running-configuration of the router you will be able to read the password. It is possible to encrypt this password using the service password-encryption command.

The service password-encryption command will also encrypt all other clear text passwords on your router including the VTY, AUX, Console and User passwords. Although the service password-encryption command encrypts your passwords so you can no longer read them in the running-configuration, the encryption algorithm is not very secure.

If we look at the running-configuration of my router in the article Setting the enable password and secret on a Cisco device , you will see that after the service password-encryption command was issued the password was stored in the running-configuration as

Enable password 7  12180A1E02

The number ‘7’ tells me the type of password, the rest of the number is the password in its encrypted format.

Copy and paste with password without the ‘7′ into the below form, and see just how easy it is to decrypt the enable password.

NOTE: Please only use the below form for password recovery and demonstration purposes!

Related posts:

1. Setting the enable password and secret on a Cisco device
2. Hashing, What is it and how does it work?
3. How encryption works

A Smurf works on a weakness of IP and ICMP by sending an ICMP packet to the broadcast address of a network. For example, I could send an ICMP (Ping packet) to every computer on the network 192.168.1.0 /24

I would do this by sending an ICMP packet to the address 192.168.1.255. This would result in every computer in that network (possibly 254 machines) sending me an echo-reply message. So far, this is not the end of the world, however Smurf adds ip spoofing to the equation…

When someone does a Smurf attack, the first thing that they do is an IP Spoof to make the their IP address look like an internal address. For example, I would spoof my address to have a source IP address of 192.168.1.10. Let’s assume that the IP address 192.168.1.10 was the Domain Controller, or perhaps the E-mail or Web server of that network. If I was to now send multiple echo packets to the destination address 192.168.1.255, every machine on that network would now send a echo-reply to the source IP of 192.168.1.10 (The internal server). This means I have just caused every machine on the target network to attack the internal target machine with echo-replies. Of course this is not the end of the world if this happens once or twice, but what if I did this a few thousand, or a few hundred thousand times? What if the target network was larger and had more than 254 machines? On a larger scale this could cause the target machine to be so over loaded with echo-replies that its network card becomes saturated to a point where its prevented from doing its job… denying it from doing it’s service… “Denial of Service” (DoS). Since this attack is not coming from me directly, and I’m forcing multiple machines to attack a single host, this now becomes a “Distributed Denial of Service” (DDos) attack.

So in order for us to prevent Smurf attacks happening on our networks, we need to make sure we block directed broadcast traffic coming into our network.

Below is the configuration required to stop Smurf Attacks. Use the diagram as a reference for the ACL’s

AOIP.ORG(config)# access-list 101 deny ip any host 192.168.1.255 log

Deny the directed broadcast

AOIP.ORG(config)# access-list 101 permit ip any 192.168.1.0 0.0.0.255 log

Allow unicast traffic

AOIP.ORG(config)# interface fa0/0

AOIP.ORG(config-if)# ip access-group 101 in

Attach the ACL to the interface for inbound traffic

AOIP.ORG(config-if)# exit

Now for the other direction……

AOIP.ORG(config)# access-list 102 deny ip any host 10.0.1.255 log

Deny the directed broadcast

AOIP.ORG(config)# access-list 102 permit ip any 10.0.1.0 0.0.0.255 log

Allow unicast traffic

AOIP.ORG(config)# interface fa0/1

AOIP.ORG(config-if)# ip access-group 102 in

Attach the ACL to the interface for inbound traffic

AOIP.ORG(config-if)# exit

AOIP.ORG(config)#

In the above configuration we have now mitigated Smurf attacks from either network segments in either direction.

Related posts:

1. Mitigating SubSeven attacks
2. IP Address Spoofing Mitigation with Access Control Lists (ACL)
3. DoS TCP SYN Attack Mitigation