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. Cisco Administrative Distance
3. ISDN and Multilink with load-threshold

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

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

Most, but not all, of the spoofing attacks that take place start with someone on the outside of your network spoofing their IP address to make it look like they are part of the inside of your network. Since all private networks worldwide follow the standards of RFC 1918, knowing what IP addresses a company is using inside their network is not complex.

RFC 1918 defines that the following IP addresses are usable inside private networks.

10.0.0.0 – 10.255.255.255

172.16.0.0 – 172.31.255.255

192.168.0.0 – 192.168.255.255

Based on the above, the most obvious first step is to deny traffic that has a source IP address inside the RFC 1918 block that is coming into your network from the outside interface. The outside interface should have outside (public) IP addresses as their source. There would be no valid reason for an IP address on the outside of your network falling within that range.

Further to the RFC 1918 block of addresses, we also need to block any source coming from the following:

local loopback (127.0.0.1)

network address (0.0.0.0)

broadcast address (255.255.255.255)

Private multicast range (224.0.0.0 /4 )

Here is the configuration breakdown for the above scenario

AOIP.ORG(config)# access-list 100 deny ip 10.0.0.0 0.255.255.255 any log

AOIP.ORG(config)# access-list 100 deny ip 172.16.0.0 0.15.255.255 any log

AOIP.ORG(config)# access-list 100 deny ip 192.168.0.0 0.0.255.255 any log

The above are the RFC 1918 Unicast IP addresses

AOIP.ORG(config)# access-list 100 deny ip 127.0.0.0 0.255.255.255 any log

Local loopback restriction

AOIP.ORG(config)# access-list 100 deny ip 0.0.0.0 0.255.255.255 any log

Network address restriction

AOIP.ORG(config)# access-list 100 deny ip 224.0.0.0 15.255.255.255 any log

Private multicast range restriction

AOIP.ORG(config)# access-list 100 deny ip host 255.255.255.255 any log

Broadcast source address restriction

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

There is an implicit deny any at the bottom of every access list, so without a permit statement, NO traffic would be allowed. In the above entry I have allowed any traffic to go to the destination address 192.168.1.0 /24 (My internal network)

AOIP.ORG(config)# interface fa0/0

For example purposes FastEthernet 0/0 is my outside interface

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

I have applied this ACL inbound, which will also protect the router from been attacked.

AOIP.ORG(config-if)# exit

AOIP.ORG(config)#

Not only do we want to prevent people from the outside of our network ‘pretending’ they are inside our network, we also want to prevent our inside people from spoofing to a different IP address as well. The above configuration had a focus on traffic INBOUND to our network, the below configuration is focused on preventing OUTBOUND traffic from spoofing.

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

The only range that is allowed to transmit is my internal network, in this case 192.168.1.0 /24

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

Although there is an implicit ‘deny any’ at the end of all ACL’s, I have included this with the log statement so I can see how many attempts have been made by internal machines to spoof their address before leaving the network

AOIP.ORG(config)# interface fa0/1

For example purposes, interface FastEthernet 0/1 is my inside interface

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

I have applied this ACL inbound, which will also protect the router from been attacked.

AOIP.ORG(config-if)# exit

AOIP.ORG(config)#

Related posts:

1. Mitigating Smurf DoS Attacks
2. DoS TCP SYN Attack Mitigation
3. Mitigating SubSeven attacks

Syslog messages allow us to track system error messages, exceptions, and other information, such as device configuration changes.

It allows for historical reporting, depending on the application keeping the logs, as well as help in fault finding.

Cisco devices support 8 levels of logging information from Facility level 0 through 7

To enable Syslog 2 things are required

                1/ Configuration on the device to send Syslog messages

                2/ An application that will receive the messages and store them in a database.

In the below live demo, you will see my putty screen with my telnet session into my router, and behind it you will see my Syslog application. There are many of these products on the market, each with its own pro’s and con’s, so use whatever you prefer. In my Live demo I am using an application called  ‘Syslog Watcher Personal Edition’, it’s a very easy to use application and is freeware. You will notice after I configured logging on the router, the log messages appear in my application.

The command breakdown for the live demo is as follows

AOIP.ORG# conf t

AOIP.ORG(config)# logging 192.168.1.1

This instructs the router to send Syslog messages to my application hosted on a machine with the IP 192.168.1.1

AOIP.ORG(config)# logging trap info

I have chosen to have level 6 messages sent to my application.

Additionally you could have used the ‘service timestamps log datetime localtime’ command to force the time on the logs.

If you still do not see any log messages after using the above commands, make sure that logging has not been disabled on the device. To force logging on a Cisco device use the ‘logging on’ command.

Related posts:

1. Cisco Router Login Lockdown
2. Configuring PAT on Cisco Routers (NAT Overload)
3. Configuring the Console port on a Cisco Device

AOIP.ORG# conf t

AOIP.ORG(config)# security passwords min-length 10
Defines a minimum password length for all passwords on the device.

AOIP.ORG(config)# enable password aoip
% Password too short – must be at least 10 characters. Password configuration failed

When I tried to create a password under 10 characters in length, I received an error.

AOIP.ORG(config)# security authentication failure rate 10 log
This command will allow 10 login failures before implementing a 15 second delay (default), it will also send a syslog message to a pre-configured syslog server

AOIP.ORG(config)# login block-for 100 attempts 2 within 100
This enforces a quiet period where login attempts will not be accepted for 100 seconds, if 2 failed attempts occur within 100 seconds<

AOIP.ORG(config)# login quiet-mode access-class 1
To prevent certain key administrators from been locked out of the router due to the previous command, we can include them in an access-list for exclusion from the quiet-mode period.

AOIP.ORG(config)# login on-success log
Use this command if you wish to log all SUCCESSFULL login attempts to a syslog server for historical and audit purposes.

AOIP.ORG(config)# login on-failure log
Use this command if you wish to log all UNSUCCESSFULL login attempts to a syslog server for historical and audit purposes. An example can be seen in the live demo below.

AOIP.ORG(config)# login delay 10
This configures a delay between successive login attempts on the device which help mitigate dictionary and brute force attacks. An example can be seen in the live demo below.

AOIP.ORG(config)# exit
AOIP.ORG# exit

Related posts:

1. ‘Login local’ on a Cisco Router
2. Setting the enable password and secret on a Cisco device
3. Configuring Syslog on Cisco Routers