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

The post Static NAT overloaded??? appeared first on AO!P.

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)

The post Configuring Dynamic NAT on Cisco Routers appeared first on AO!P.

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.

The post NAT (Network Address Translation) appeared first on AO!P.

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

The post DoS TCP SYN Attack Mitigation appeared first on AO!P.

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

The post Mitigating SubSeven attacks appeared first on AO!P.

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!

The post Decrypting Type 7 Passwords (enable password) appeared first on AO!P.

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.

The post Mitigating Smurf DoS Attacks appeared first on AO!P.

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

The post IP Address Spoofing Mitigation with Access Control Lists (ACL) appeared first on AO!P.

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

Enter global configuration mode

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

This creates a standard access-list and logs the amount of times this access-list is matched. No deny statement is needed as there is always an implicit deny any statement at the end of every access-list

R1(config)# line vty 0 4

Enter the Virtual lines

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

Attach the access-list to the virtual lines for traffic inbound TO the router.

Below is the live demo.

The post Restricting access to Telnet and SSH appeared first on AO!P.

Firstly, most people believe that access-lists are used purely for denying or allowing traffic, although this is certainly one of the functions of an access-list it is not the only function.

Access-lists 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 dive into each of the above points to see how they can be applied and used.

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 to understand when designing Access-lists as the router processes the information differently depending on direction of the access-list. If an access-list is bound to an interface in the INBOUND direction the access-list will take effect before any processing is done by the router. If the access-list is bound to an interface in the OUTBOUND direction, the router would have already processed the packet entirely internally before the packet is checked against this ACL. The end result might be that the access-list drops the packet, unnecessarily wasting the resources of the router.

2/ Attaching an access-list 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 access-list to the Virtual Interfaces of the router (ie: VTY lines).

3/ QOS uses ACL to define traffic that you wish to prioritize. The access-lists 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 access-lists 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 access-lists do not restrict traffic from flowing, they restrict traffic from causing the lines to dial! In order to block traffic, an access-list needs to be applied to the interface (as seen in point 1). This could be the same access-list as used for DDR, although not common.

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 access-list.

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

Standard access-lists 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 or 1300-1999

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

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

Guidelines:

• One access-list per interface, per protocol, per direction
• The order of access-list statements is important. Once a 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 access-list is ALWAYS an implicit deny any, so every access-list needs at least one permit statement
• Access-lists must be configured before applying them to interfaces

The post Cisco Access-lists (ACL’s – Access Control Lists) appeared first on AO!P.