AOIP - Anything Over IP » Access-Lists

Static NAT overloaded???

Jay — Wed, 27 Jul 2011 05:24:51 +0000

So we have already looked at all 3 possible NAT configurations, however there is one more trick that is always useful to know. How to overload a Static NAT.

Let’s assume the following for this example

We have 2 public IP addresses (192.168.1.1 & 192.168.1.2)
The IP address on the outside interface has been configured to use PAT for all internal IP addresses for Internet access (192.168.1.1)
I have a DMZ with 3 servers, FTP, E-mail, and Web Server (10.0.1.1, 10.0.1.2 & 10.0.1.3 respectively)
I need my 3 DMZ servers to be reachable from the Internet.

The above scenario poses a slight problem. If I have already used one of my public addresses for PAT to allow all internal hosts to access the Internet, I only have one IP address left but I require 3 static NAT entries to be created. In my post on Static NAT we saw that we configure NAT to map on a one-to-one basis, so in this scenario I would require 3 IP addresses, one for each of my DMZ servers.

The nice thing about the above scenario, is that each of the three servers is hosting a totally different service and therefore each requires different ports to be accessible from the Internet. This allows me to create static NAT’s that specify the ports, a type of overload function.

FTP would require ports 20,21 to be allowed
E-mail would require port 25 to be opened, and possibly 143 and 110 if you are using IMAP or POP
Web Server will require port 80, and possibly 443 if there is any SSL been used (https).

The above can be configured in the following way (interfaces would need to be configured as inside and outside as well, as seen here)

AOIP.ORG (config) # ip nat inside source static tcp 10.0.1.1 192.168.1.2 20
AOIP.ORG (config) # ip nat inside source static tcp 10.0.1.1 192.168.1.2 21

AOIP.ORG (config) # ip nat inside source static tcp 10.0.1.2 192.168.1.2 25
AOIP.ORG (config) # ip nat inside source static tcp 10.0.1.2 192.168.1.2 143
AOIP.ORG (config) # ip nat inside source static tcp 10.0.1.2 192.168.1.2 110

AOIP.ORG (config) # ip nat inside source static tcp 10.0.1.3 192.168.1.2 80
AOIP.ORG (config) # ip nat inside source static tcp 10.0.1.3 192.168.1.2 443

Configuring PAT on Cisco Routers (NAT Overload)

Jay — Wed, 20 Jul 2011 14:06:58 +0000

PAT (Port Address Translation) is by far the most common implementation of NAT, and if you have an ADSL router at home there is a 100% chance you are using it.

PAT or otherwise known as NAT overload, allows you to translate IP addresses in a many-to-one method.
In my previous post on Configuring Dynamic NAT we saw that we can NAT many-to-many but this was limited by the amount of public addresses that you have available. In cases such as home ADSL, your ISP will only issue you with a single public IP address but you might have 2 or more devices that need to access the Internet at any given time. This is where PAT takes over and makes this all possible.

As with any NAT configuration we need to first define our inside and outside interfaces. In this example I’ll use FastEthernet 0/0 as my inside, and Serial 0 as my outside.

AOIP.ORG (config) # interface FastEthernet 0/0
AOIP.ORG (config-if) # ip nat inside
AOIP.ORG (config-if) # interface Serial 0
AOIP.ORG (config-if) # ip nat outside

The next step is to define which addresses in my inside network I want to allow to be translated. Let’s assume my inside IP address range is 10.0.1.0 /24

AOIP.ORG (config) # access-list 1 permit 10.0.1.0 0.0.0.255 (Using a standard access-list is the easiest way to achieve this)

Then I need to configure the address that will be used by my internal IP addresses for accessing the outside interface. This can be done in 2 ways.

Option 1:
If I only have 1 public IP address, which is the case with home ADSL, the router will already have that IP address allocated to it by your ISP. The only thing I can do is tell the router to share that address with my internal hosts.

AOIP.ORG (config) # ip nat inside source list 1 Serial 0 overload (This defines my access-list 1 as the source addresses, and tell them to be translated into the same IP address that is configured on Serial 0. The overload command tells the router that it needs to keep track of all the source and destination ports so the IP address can be used multiple times, overloaded)

Option 2:
If I have a second public IP address that I would like to use for Internet browsing, I can configure PAT for that IP address.

AOIP.ORG (config) # ip nat inside source list 1 192.168.1.1 overload (Same as the above command, but I’ve specifically told the router which IP address to translate my internal hosts into)

This option is fantastic if you have multiple public addresses and you want to segment your Internet browsing based on departments or geographic locations. For example
Marketing – 10.1.0.0 /24
Sales – 10.2.0.0 /24
Technical – 10.3.0.0 /24

I can have each of the above departments using their own public IP address, which will make log files easier to read when tracking Internet use and for troubleshooting connection errors.

access-list 2 permit 10.1.0.0 0.0.0.255
access-list 3 permit 10.2.0.0 0.0.0.255
access-list 4 permit 10.3.0.0 0.0.0.255
ip nat inside source list 2 192.168.1.2 overload
ip nat inside source list 3 192.168.1.3 overload
ip nat inside source list 4 192.168.1.4 overload

Configuring Dynamic NAT on Cisco Routers

Jay — Fri, 15 Jul 2011 04:00:58 +0000

In my last post Configuring Static NAT on Cisco Routers we saw how you can translate 1 IP address into another single IP address. This tutorial will cover how to translate many IP addresses into many IP addresses, otherwise referred to as many-to-many translation.

Dynamic NAT allows us to translate many IP addresses into a pool of many IP addresses. The big thing to realize here is that the pool does not need to contain enough IP addresses to translate all the internal addresses at the same time, as would be the case if we used Static NAT. Dynamic NAT allows internal hosts to be translated into an IP address in the pool when it requires a connection. Once the internal host has finished it’s session the NAT entry is removed from the NAT table allowing another internal host to use the external IP address for it’s session.

Assume we have 50 hosts in our inside network but only have 5 public IP addresses available to use. With Dynamic NAT we can allow all 50 internal addresses to share the 5 public addresses as and when they need them. This of course does impose a limit of only 5 simultaneous connections to the outside world and that is where PAT would come in and solve that problem.

On of the benefits of using Dynamic NAT vs Static NAT, is that Dynamic NAT requires the session to originate from the inside network. No outside connections can be established to the inside network. This is obviously a more secure solution as connections from the outside won’t work; only traffic originating from the inside will be translated. Static NAT is different in the fact that the entry is added to the NAT table on a permanent basis and will allow connections in either direction.

Here are the steps to configure Dynamic NAT on a Cisco Router.

Step 1 : I need to define the IP address range that will be translated (my inside IP addresses). I can do this with a standard access-list

AOIP.ORG (config)# access-list 1 permit 10.0.1.0 0.0.0.255 (don’t forget, access-lists use wildcard masks, not subnet masks)

Step 2 : I need to configure the range of addresses that my internal network will be translated into by using a NAT pool.

AOIP.ORG (config) # ip nat pool MY_POOL 10.50.1.1 10.50.1.5 netmask 255.255.255.0 (There are 5 IP addresses that can be used for translation in this example)

Step3 : Define inside and outside interfaces

AOIP.ORG (config) # interface FastEthernet 0/0
AOIP.ORG (config-if) # ip nat inside
AOIP.ORG (config-if) # interface Serial 0
AOIP.ORG (config-if) # ip nat outside

Step 4 : Configure the translation to take place.

AOIP.ORG (config) # ip nat inside source list 1 pool MY_POOL (List 1 is my access-list that defined my inside IP addresses, MY_POOL defined the IP addresses to be used for the translation)

Configuring Basic ISDN with Interesting Traffic

Jay — Tue, 25 Aug 2009 14:10:17 +0000

When configuring ISDN with interesting traffic, it’s important to first understand how Cisco defines ‘interesting’ and what this means in terms of the connection been formed. Interesting traffic is traffic that we define in the form of an access-list that is allowed to cause the ISDN to dial. This does NOT mean it is the only traffic allowed to use the link but this does tie in directly with the idle-timeout value that we need to set on the ISDN interface.

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

DoS TCP SYN Attack Mitigation

Jay — Fri, 21 Aug 2009 14:22:40 +0000

TCP SYN flooding is often used in conjunction with IP spoofing.

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)#

Mitigating SubSeven attacks

Jay — Thu, 20 Aug 2009 14:10:47 +0000

SubSeven – aka: Sub7 and Sub7Server is a backdoor program, in the form of a Trojan, used mostly for causing trouble on computer networks. It can be used for simple attacks such as hiding the mouse cursor and opening applications, but it can also be used for more serious attacks including retrieving all your personal information stored on your machine and all computer settings.

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)#

Mitigating Smurf DoS Attacks

Jay — Tue, 18 Aug 2009 06:00:41 +0000

Before looking at how to mitigate a Smurf attack, let’s first understand what it is and why it’s such a problem.

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.

IP Address Spoofing Mitigation with Access Control Lists (ACL)

Jay — Mon, 17 Aug 2009 14:06:29 +0000

IP spoofing is the act of camouflaging your IP address to make it look like you are someone else. Although IP spoofing is not an attack by itself, it is the starting point of many of the most common attacks found on today’s networks.

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)#

Restricting access to VTY (Virtual Terminal Lines)

Jay — Fri, 14 Aug 2009 13:50:26 +0000

One of the first and most important things to configure on any Cisco device after allowing telnet or SSH, is to restrict who is allowed to access the device. Of course having a password on the lines is the first step but if telnet is the method of communication, all passwords will be sent over the wire in clear-text. This means that if someone was to sniff the line while you logged onto a router using a telnet session, they would be able to see your password and hence gain access to the device.

As an additional method for securing your Cisco devices, it’s a good idea to bind an ACL (Access Control List) to the VTY’s (Virtual Terminal Lines). This will only allow IP addresses included in the ACL to create a connection to the device in addition to needing the password for the lines.

If we look at the diagram below, I might want to restrict telnet access into R1 so telnet will only be allowed to take place from AOIP.ORG and not from any other device or computer.

In order to achieve the above, the following commands would need to be configured.

R1# conf t

R1(config)# access-list 1 permit host 192.168.1.10 log

Create a standard access-list (only checks the source address) and include the ‘log’ command so I will be able to see how many times the ACL has been matched. I don’t have to include any deny statements since there is always a implicit deny any statement at the end of every ACL

R1(config)# line vty 0 4

Enter the Virtual lines

R1(config-line)# access-class 1 in

Attach the ACL to the virtual lines for traffic inbound to the router.

Below is the live demo.

If you can see this, then you might need a Flash Player upgrade or you need to install Flash Player if it's missing. Get Flash Player from Adobe.

Introduction to ACLs (Access Control List)

Jay — Thu, 13 Aug 2009 12:31:13 +0000

Before looking into the configuration of ACL (Access Control Lists), it’s important to get some of the concepts and understanding of how they work and what they are used for.

Firstly, most people believe that ACL’s are used purely for denying or allowing traffic, although this is certainly one of the functions of a ACL it certainly not the only function. ACL’s can be used for

1/ Permitting or denying packets moving THROUGH the router.

2/ Permitting or denying packet TO or FROM the router.

3/ QOS (Quality of Service)

4/ DDR (Dial-on Demand Routing)

5/ Route filtering

So let’s break down each of the above to see its use.

1/ When you want to restrict traffic from flowing THROUGH a router, you can attach a ACL to an interface of the router. This can be done on a INBOUND or OUTBOUND direction. The direction of the traffic is vitally important and how the router processes the information differs depending on direction of the ACL. If the ACL is bound to an interface INBOUND the ACL will take effect before any processing is done by the router. If the ACL is bound to an interface in a OUTBOUND direction, the router would have already processed the packet entirely before possibly dropping it. This could increase the processing on the router unnecessarily.

2/ Attaching an ACL to an interface however does NOT stop traffic that is going TO or FROM the router. This means that if I’m trying to telnet to the router, the ACL on the interface will NOT APPLY. In order to restrict traffic TO or FROM the router we need to attach the ACL to the Virtual Interfaces of the router (VTY lines).

3/ QOS uses ACL to define traffic that you wish to prioritise. The ACL are not bound to interfaces but are used in modular QOS

4/ When using dial-up interfaces such as modems or ISDN you don’t want to allow any traffic to cause the interfaces to dial. If all traffic was allowed to cause the lines to dial then every time a broadcast message took place the lines would dial. This would result in the lines constantly been connected and result in a large phone bill. With ACL for DDR we define what traffic is allowed to make the modem or ISDN lines dial and create a connection. It is important to understand that when the line is active ALL traffic is allowed to flow through the line. These ACL do not restrict traffic from flowing, they restrict traffic from causing the lines to dial!

5/ Route filtering is used when we wish to re-distribute routes learnt from one routing protocol into another one. This is most commonly seen when you have an EGP (Exterior Gateway Protocol) like BGP and you wish to insert some of the routes learnt from BGP into your IGP (Interior Gateway Protocol) such as OSPF. You cannot re-distribute the entire BGP routing table into OSPF as OSPF cannot handle a routing table of that size, so we can restrict which entries that will be re-distributed using an ACL.

Now that we understand the different uses of Access Control List we now need to see the 3 different types of ACL’s. STANDARD, EXTENDED and NAMED

Standard ACL only check the source address of the packet and can either permit or deny the entire protocol suite. It will have a number between 1-99 and 1300-1999

Extended ACL can check the source and destination addresses, the source and destination port numbers, and specific protocols. It will have a number between 100-199 and 2000-2699

Named ACL can be either standard or extended ACL, however we can associate a name to the ACL instead of using numbers.

Guidelines:

- One ACL per interface, per protocol, per direction

- The order of ACL statements is important. Once match has been made no further testing is done.

- The most restrictive statements go at the top of the list

- The last statement in an ACL is ALWAYS an implicit deny any, so every ACL needs at least one permit statement

- ACL must be configured before applying them to interfaces