All Entries in the "Security" Category
Cisco: Small escape leading to non-functional NAT
I have seen that a lot of people is using search engines to look after terms like “NAT: failed to allocate address for…” or “NAT: address not stolen for…” asking for help in regard to a non-functional NAT. Of course I skipped the cases when the solution was obvious and clear like wrong NAT configuration, NAT pool or missing the access-list.
One not so clear case you have in the example below:
ip access-list standard nat_acl
permit 192.168.0.0 0.0.0.255route-map to_nat permit 10
match ip address nat_aclip nat pool test_pool 172.31.0.8 172.31.0.8 prefix-length 30
ip nat inside source route-map to_nat pool test_pool overload
Maybe I should have seen the mistake at first look, but I didn’t. But I can assure you that I’m not the only one 
Quick looking and a little careless made me said that the NAT configuration looks fine. Looks fine, but not working.
Debugging with “debug ip nat” command gave me the following output:
NAT: address not stolen for 192.168.0.10, proto 1 port 10
NAT: failed to allocate address for 192.168.0.10, list/map to_nat
Not too much information here either. So I’ve started to have a look closer to the NAT configuration, when I saw this:
ip nat pool test_pool 172.31.0.8 172.31.0.8 prefix-length 30
Oh boy, how can I miss that: 172.31.0.8/30 being the network address. You cannot use the network address to translate.Often this is not seen and the configuration is taken as being OK.
The solution would be in this case (if we want to keep the prefix-length 30) to change the ip to 172.31.0.9 or 172.31.0.10.No, you cannot use 172.31.0.11 as that’s the broadcast address and would result in faulty NAT.
Another solution would be to change the prefix-length to 24 giving you 254 addresses for translation. I would recommend changin the prefix-length if you are beginning now to deploy NAT and you want a scalable solution. If you prefer to stay with prefix-length of 30, you should take in consideration that at every 4 IP addresses you will lose 2 (network address and broadcast), which is not to fair if you are using public ranges.
Popularity: 4% [?]
Cisco: DoS protection using TCP Intercept
Every now and then, all network engineers have to deal with some kind of network attack. Usually, the attack does not target the network devices, but the machines that provide services (e.g. www, database hosting…), because it’s more easy to find on the Internet a script that is probing port 80 for example, which by the way any kiddie can use, than to corrupt BGP in order to act as man-in-the-middle. Anyway, in front on the machine being attacked, there is a network device and even if the network component is not the target it can be affected (e.g. high traffic encounter during a denial-of-service attack). So, beside the fact that we have to protect the network components, we have the duty (at least moral) to help the team that is managing the servers to mitigate the attack.
For those of you who are not familiar I will explain shortly what is a Denial-of-Service (DoS) attack. A denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a computer resource unavailable to its intended users. DoS attacks typically target sites or services hosted on high-profile web servers such as banks, credit card payment gateways, web hosting and so on. One common method of attack involves saturating the target machine with external communications requests, such that it cannot respond to legitimate traffic, or responds so slowly as to be rendered effectively unavailable. This extreme external communications requests can be achieved using ICMP flood, peer-to-peer attack, teardrop attack, nuke, application level floor and many other (too many…) methods and the purpose of this is the consuming of resources on the target machine so that it can no longer provide its intended service or obstructing the communication media between the intended users and the victim so that they can no longer communicate adequately.
On method to prevent DoS attacks is to limit on the network device ( network router) the amount of connection which is allowed to pass to a server by using TCP Intercept. The TCP intercept feature helps prevent SYN-flooding attacks by intercepting and validating TCP connection requests. In intercept mode, the TCP intercept software intercepts TCP synchronization (SYN) packets from clients to servers that match an extended access list. The software establishes a connection with the client on behalf of the destination server, and if successful, establishes the connection with the server on behalf of the client and knits the two half-connections together transparently. Thus, connection attempts from unreachable hosts will never reach the server. The software continues to intercept and forward packets throughout the duration of the connection.
The main steps to enable TCP Intercept are:
1. Define an IP extended access list
2. Enable TCP intercept
3. Fine tune TCP intercept parameter
The TCP intercept can operate in either active intercept mode or passive watch mode. The default is intercept mode.
In intercept mode, the software actively intercepts each incoming connection request (SYN) and responds on behalf of the server with an ACK and SYN, then waits for an ACK of the SYN from the client. When that ACK is received, the original SYN is set to the server and the software performs a three-way handshake with the server. When this is complete, the two half-connections are joined.
In watch mode, connection requests are allowed to pass through the router to the server but are watched until they become established. If they fail to become established within a definite interval, the software sends a Reset to the server to clear up its state.
In the following topology we have the Server (10.10.10.100) and the possible Attacker (10.10.20.100). In the middle we have the router called R1 which is reponsible to mitigate the attack to port 80 on the Server. For this I would chose to apply the following configuration:
access-list 101 permit tcp any host 10.10.10.100 eq 80
ip tcp intercept mode intercept
ip tcp intercept list 101
ip tcp intercept max-incomplete high 150
ip tcp intercept max-incomplete low 100
ip tcp intercept drop-mode oldest
Some explanation for the line above. We create an access-list matching the traffic from anywhere to the Server. We set the TCP intercept mode to intercept (this is not need actually, because it’s the default mode; I put it here just for the sanity of the example). When the connections are over 150 (…max-incomplete high 600) the router will start to drop connections starting with the oldest ones (..drop-mode oldest). As soon as the connection will be under 100, the router will cease to drop the connections. This are just values used for this example.
To check the TCP intercept you can use the following commands on the Cisco router:
show tcp intercept connections
show tcp intercept statistics
To check a live example of what you should see if your TCP Intercept configuration is working properly please click on the image below. The test is done in Dynamips environment with 2 VMware machines (client and server) using Ubuntu and a Cisco 3640 series router.
Popularity: 7% [?]
Cisco: How to use reflexive access-list and why they are useful
Reflexive access-list are one of the method that help us achive firewall functionality with a router hardware. The other methods that serve to the same purpose are Context-Based Access Control (CBAC) and TCP Intercept. For an introduction to CBAC with example please check my older post Cisco: Use CBAC to achieve firewall functionality on router device . For TCP Intercept check my blog in the next weeks.
Today, I will present Reflexive access-list and how can take advantage of their specific behavior. Reflexive access list commands are used to configure IP session filtering. IP session filtering provides the ability to filter IP packets based on upper-layer protocol “session” information. They are generally used to allow outbound traffic and to limit inbound traffic in response to sessions that originate inside the router. E.g. you want to allow a TCP connection from outside only is the initall packet was send from the inside. Take FTP active mode session on data port TCP 20. If you are doing FTP from inside the LAN port 20 will be allowed outbound and also inbound. But if somebody from outside try to reach one device on your LAN on port 20, the session will be dropped due to Access-list implemenation.
Reflexive ACLs can be defined only with extended named IP ACLs. They cannot be defined with numbered or standard named IP ACLs, or with other protocol ACLs. Reflexive ACLs can be used in conjunction with other standard and static extended ACLs. As a syntax Reflexive access-list are presented exactly like any normal ACL, with the implementation of two parameters “reflect” and “evaluate”.
Let have a look to this example topology. R2 will be the router where the Reflexive ACL has to be implemented. The implementation is quite simple. You configure an outbound access-list which permit tcp sessions from any subnet to any subnet. The difference from this outbound ACL and a normal one, will be the “reflect” parameter at the end on the permit line. The “reflect” parameter will have the name OUT (it can be any name you want).
After the outbound list is completed configured, then we will configure an inbound access-list with a “permit tcp any any” statement followed by the parameter “evaluate OUT”. Below it’s a simple example how to configure this Reflexive ACL on the topology presented above, to permit UDP and TCP inside only if the session was initiated from inside:
ip access-list extended OUTBOUND
permit tcp any any reflect TO_REFLECT
permit udp any any reflect TO_REFLECT
ip access-list extended INBOUND
evaluate TO_REFLECT
interface Serial1/0
ip access-group OUTBOUND out
ip access-group INBOUND in
So, the INBOUND ACL will evaluate OUTBOUND ACL to permit or deny TCP packet from outside. Remember that by default, packets generated by the router itself will not be
reflected. This is why if you have a routing protocol running towards outside, on your router you have to permit static those packets. Let’t take the example of the BGP routing protocol. Assume that you have a BGP peering between R2 and R3. On R2 you will have to permit static the BGP packets from outside, like in the example below:
ip access-list extended OUTBOUND
permit tcp any any reflect TO_REFLECT
permit udp any any reflect TO_REFLECT
ip access-list extended INBOUND
permit tcp any any eq bgp
permit tcp any eq bgp any
evaluate TO_REFLECT
interface Serial1/0
ip access-group OUTBOUND out
ip access-group INBOUND in
In this way the BGP packets local generated on the router, will be allowed IN and OUT on the WAN interface. You will proceed in the same way for other packets that are generated on the router and you want to allow them to pass through WAN interface.
For a live example please see the video presentation below. If you did not had a look to the example topology, now it would be a good time to do it. Already I have preconfigured BGP AS 300 on router R3 and BGP AS100 on R2 and R1, so the conectivity from R1 to R3 is not a problem. Also R1 and R3 have a Loopback interface which is advertised into BGP. After implementing the Reflexive ACL on R2 I will be allow to telnet from R1 to R3, but not viceversa. Also the BGP packets between R2 and R3 will be static permited in ACL.
I hope that I could helped you to understand the importance on the Reflexive ACL. Sometime simple ACL would do the job and then I would suggest not to complicate things. But if you have something tricky to solve regarding access in your LAN, or you prepare for some exam like CCIE, then Reflexive ACL are quite useful and important.
Popularity: 18% [?]
Cisco: How to configure privileges for local users
I believe that all of you are familiar with privilege levels (0-15) on Cisco IOS. The most useful for network engineers is level 15 and the highest one as it will allow you full access to all IOS features, but in most networks only a few persons have this privilege level. In my opinion is normal to be like this, as with this limitation in, the risk that somebody will login and configure something that will lead to a system failure is minimized. Also true is that this will limit the troubleshooting on the network in case of an issue.
Let’s take the following scenario:
- you are the network engineer and you have privilege level 15 access;
- somewhere in your remote network there is a device that has a failure and you need somebody on site to tell you some informations about the device;|
- the local administrator does not have access (e.g to read running-config) on that Cisco device as you don’t want him to break something by some misconfiguration that she / he applies;
In this scenario you are either stuck with the problem and you have to travel to remote location to fix the problem or to give user access. I will chose from this a middle path. Give a user limited access just to read information that might be useful for you like IP address assigned on interfaces, access-lists or routing table (of course you have to do this before you have a problem on some remote device and possible a connection lost).
In the example below I will show you how you can configure an user with limited access just to read the running-config and in this file just the following information: hostname, interfaces (and here only IP addresses assigned to the interfaces) and routing protocols (with networks advertised into specific network protocol). This is just a basic example, but the privilege levels can be customized as you need.
Please check the presentation below:
Popularity: 10% [?]
