CCIE or Null!

My journey to CCIE!

Archive for the ‘Cisco Security’ Category

You don’t have to block ICMP completely.

with 3 comments

This is something that I typically see all over the place, security administrators blocking the ICMP (Ping) protocol completely. Normally I am ok with that, after all ping is a troubleshooting tool and in some cases not the best troubleshooting tool to rely on. However, it’s when people think their network is more secure when they have blocked ICMP. The truth is you can actually allow the ICMP types that are required for troubleshooting purposes without compromising security. So let’s first consider what ICMP messages we typically use for troubleshooting:

  1. Echo Request – ICMP Type 8 Code 0
  2. Echo Replies – ICMP Type 0 Code 0
  3. Time Exceeded – ICMP Type 11 Code 0
  4. Fragment needed but DF bit set – ICMP Type 3 Code 4

Now we all know the echo request is the icmp packet from the host to the target, and the echo reply is response from target back to the host. The time exceeded packet is returned to the host  when performing a traceroute. The fragment needed but DF bit set packet is used for path MTU discovery and can used to troubleshoot MTU issues, it basically replies back telling you the packet was dropped because it needed to be fragment but the DF (Do not fragment) bit was set on the packet so it could not be fragmented.

One ICMP parameter that should be blocked are ICMP fragments, fragmented ICMP packets can be used to cause DoS attacks. Remember ICMP packets typically send 64 bytes of data, so you should only see larger ICMP packets or expect fragments when testing MTU. (Other then that I can’t think of any other legit reason to see large ICMP packets). RFC 1858 goes pretty in depth concerning the danger of IP Fragments, it’s definitely worth a read.

Now here is a configuration snippet that accomplishes everything I discussed here:

Now if you want to learn about ICMP in greater detail check out RFC 792.

Written by Stephen J. Occhiogrosso

February 13, 2012 at 6:52 AM

Working with Cisco Access Control Lists / ACLs.

with one comment

I know ACLs, how complicated can they be and how hard is it to work with ACLs? Not a very tough concept right, well what happens when you want to add ACEs (Access Control Entry) into an ACL before other entries? Remember an ACL will match from the top down. I’ve seen people completely rip out an ACL just to put it back in with one addition entry. Let’s take a look at an ACL and what we can do to change this around.

Now here we got a simple ACL:

First thing we see on the left is the sequence number for each specific ACE, remember all ACEs are given a sequence number, and by default the first ACE starts at sequence number 10, and any subsequent ACEs are given a sequence number 10 digits up. This is why the sequence numbers are incrementing by 10.

Now, let’s say the 192.168.2.0 /24 network was recently subnetted and we need to deny FTP traffic from the 192.168.2.0 /25 subnet, well we need to add the new entries before sequence number 20. So let’s jump into ACL Configuration mode and see what we can do.

So from global configuration mode we enter ip access-list extended OutBoundAccess, make note you can also change standard ACLs like this. So this is not just limited to extended ACLs. Notice the configuration mode has changed, now we are in R1(config-ext-nacl)# allowing us to continue configuring this OutBoundAccess ACL. So let’s go ahead and continue with our configuration, first we want to start with a sequence number lower then 20 and we want to deny FTP traffic from the 192.168.2.0 /25 subnet.

Once we add the command we can issue the show command to verify the new ACE is in the correct location, and indeed it is.

Now let’s go a step further, let’s say we ran out of sequence numbers between 10 to 20 and we need get a few more ACEs in there.

Sure, we could add them before sequence number 10 but for the sake of this example let’s see we can’t. What we need to do is re-sequence the ACL.

We entered the command ip access-list resequence OutBoundAccess 10 10 resequencing the OutBoundACL starting with sequence number 10, in increments of 10. Look at the sequence numbers now. This allows us to keep adding entries where we need to. This definitely makes it easier to add entries and move entries around an ACL with minimal effort.

Written by Stephen J. Occhiogrosso

January 9, 2012 at 7:09 AM

Securing BGP.

leave a comment »

BGP like other routing protocols need to be protected. Remember BGP runs off of TCP port 179 and because of this it is susceptible to the typical vulnerabilities of TCP, but we do have a few options that can be configured to provide some addition security.

1. MD5 Authentication

This should go without explanation like other routing protocols, neighbors will be authenticated using an MD5 key, this key must match on a per neighbor basis.

Configuring BGP Neighbor Authentication

Neighbor with a bad MD5 password

2. bgp maxas-limit

Maxas-limit doesn’t initially appear to apply any real security like the MD5 authentication, but the maxas-limit will prevent your BGP router from accepting routes with an AS-Path longer then the maxas-limit. This can help manage resources and prevent also prevent someone from pre-pending and AS-Path 20 AS’s long, which does not scale very well.

Sidebar history lesson: this feature came about after Cisco supported 4 octet AS numbers in the BGP packet (RFC 4893) because of a DoS vulnerability which has been fixed, but it still good practice to control the resources on your router.

Configuring maxas globally in config-router mode

maxas violation

3. TTL Security

TTL Security allows you to specify the packet TTL to eBGP neighbors, the reason this provides security is because it allows to specify how far away your peer is going to be. This will make it hard for someone to spoof a BGP neighbor that is further away then the configured TTL.

BGP TTL Security Configuration

4. Control Plane Policing – CoPP

Another option is to configure a service policy applied to the control plane so BGP updates are only processes from specific neighbors and not just anyone.

BGP Control Plane Policy

5. Limit the number prefixes you can learn from a neighbor.

This one you have to be careful with because when the prefix limit is reached the neighbor relationship is reset and re-established, obviously this will be production impacting. It can be configured to send a syslog warning message when the maximum prefix limit is reached, however it almost contradicts the purpose of configuring the maximum prefix.

Setting the maximum amount of prefixes BGP can learn from a neighbor

Now those are just a few ways you secure BGP in your network you can also filter BGP prefixes through a prefix-list, filter by ASPATH using regular-expressions, as well as using good old fashioned ACL’s. This Cisco page covers those addition BGP security configurations, and covers the ones I mentioned here.

Written by Stephen J. Occhiogrosso

October 5, 2011 at 7:14 AM

Secure Cisco Device Management.

leave a comment »

One thing that should be standard in your setup, is secure management. Being a network engineer requires you to secure your management interfaces, whether the management interface is a web page or remote CLI session, it should be encrypted and authenticated. After all configuring port security and firewalls are useless if your administrative credentials are sniffed off the network in clear text, or worst case your entire configuration.

First thing you want to do is activate the secure protocols and disable the weak protocols. So we would issue the following commands:

As you can see we first disabled the HTTP protocol, and then enabled HTTPS (Note: the first time you enable HTTPS a certificate may be generated), then configured the vty lines to accept only SSH, and not telnet connections.

Note: Prior to disabling telnet and enabling SSH, you want to configure the aaa new-model parameters along with any local users DB entries. See this Cisco guide for configuring SSH in more detail. Last thing you want to do is lose remote access to your device.

Now this device can only be managed via HTTPS or SSH, telnet and HTTP access have been disabled. This will prevent the administrative credentials of your network devices from being sniffed off the network in clear text, only encrypted cipher text will be found.

Just to push the point home some more, here is a TCP stream where I telnetted into a lab switch and issued the sh run command. First off you see the password I entered to access the switch and secondly the entire output of the sh run command is right there in clear text!

Now, I did a second capture where I accessed the switch via SSH and issued the same commands.

Very different output, as you can see, in the beginning you see I used Putty after that the encryption algorithm exchange and the rest is cipher text.

You can also verify this by using NMAP to perform a port scan on the device to see what ports the device is listening on.

Here is a NMAP Scan with all four protocols enabled (Telnet, SSH, HTTP, and HTTPS)

Here you can see, the lab switch is listening on all four ports, so individuals can connect to this device in an insecure manner. (The option should not even be out there)

Now a second NMAP scan after the commands shown above were entered.

Now the device is only listening on 22 and 443. This device can only be managed in a secure way.

I’ll end this on a final note… The tools I used here are all free to download NMAP, WireShark, and Putty. So it doesn’t take much for some barely knowledgeable (and bored) user on your network to start sniffing packets on your network.

Protecting Cisco Switches: Port Security

with 5 comments

I figure I would tackle some Cisco switch security, which oddly enough is typically overlooked, it seems most people primarily focus on their firewalls protecting layer 3 and above meanwhile you can plug right into a layer 2 switch and your in. So it just seems to me that layer 2 security is occasionally overlooked, but we shall cover a few good commands within Cisco switches to protect layer 2. Please keep in mind that security is a broad enough subject as it is, so this post itself will cover parts of port security here, and the discussion will be continued in another post.

I’ll start off by pointing out the most common kind of  attack port security protects against, and that would be MAC Flooding in this type of attack an attacker sends multitudes of spoofed MAC addresses to the switch so the switch stores all the address in the CAM table, and at some point the CAM table overflows and the MAC addresses of legitimate clients are flushed out, at which point the switch forgets how to get data to the legitimately attached clients, so when any legitimate data is sent it gets flooded out all ports. This could have multiple effects one, the attacker can sniff the data off the network and, two any other attached network devices/workstations/servers will get flooded with the data as well so it will simulate a DoS attacks well. This can also protect against a MAC spoofing attacks, where an attacker will change their MAC address so the switch thinks the attacker is a different device like a router, at which point all data leaving the subnet is sent to the attacker so the attacker in essence performs a Man-In-The-Middle attack, where they can do whatever they want with the data they receive.

I would also like to include this will protect against DHCP attacks, after all DHCP leases are given to the MAC address so MAC flooding attacks could also be used to fill up your DHCP scopes (Another type of DoS attack), and when you sit back and think how important DHCP really is and how dependent most networks are of it, imagine losing it for a little while. As stated above however I will cover DHCP Snooping and Dynamic ARP inspection in the future, I just wanted to include this little tidbit.

You can protect against these types of attacks by implementing port security. Keep in mind when you implement port security you can either configure it to be really restrictive or just to protect against the mentioned attacks. The syntax to configure port security is below:

See quite simple really.

The first command simply activates port security on the switch port, but you still have a few more parameters to set. The next command sets the maximum number of MAC addresses the switch port can learn before a violation occurs, which is what is configured in the third line. The default is shutdown, which as you can guess shuts the switch port down, requiring IT to intervene to see what is happening. Their are two other violation modes you can configure instead of shutdown one of which is protect which will allow the computer with the configured MAC address(es) to communicate with the network while dropping the frames of any other computer with a different MAC address after the violation occurs, however the switch will not increase the violation count so their will be no indication at all that anything is happening until a legitimate user complains, so this will happen without your knowledge. The other violation parameter is restrict which acts very similar to protect but restrict will increase the violation count and sends an SNMP trap so at least their is an indication something is happening. I’ve honestly only used the shutdown parameter, since I really do not see the point behind the restrict/protect since an attack could be attempted without your knowledge, where as shutdown will stop any attempt in it’s tracks, and if your smart and this happens enough you will investigate. Now the mac-address sticky command, simple takes the first mac address the port learns and adds it to the running config, so if the device on other side of the switch port needs to be changed it requires administrator intervention.

Now when I said this could be configured to be really restrictive or just to prevent L2 attacks. A switch can hold a very large amount of MAC address, so you can simply set the maximum number of MAC address to 100 per port and forget about it for a while, or you can be really restrictive and set the number of MAC address to 1 or 2. Just keep in mind how often your users get new PC’s or if they move between offices with laptops. You’ll need to decide how restrictive you want to depending on your environment.

Another thing you want to plan for is how are you going to manage port security, just think when a user at a remote site calls up and says “I can’t connect” and you know it’s because of the port security and you have 3+ switches at that site, it doesn’t make much sense to go in their and clear every port security violation now does it or to connect to all 3 switches blindly issuing show port-security hunting for violations? I’ve got my switches sending port security and err-disable traps to a syslog server of mine where I can filter by those specific traps where I see the switch, the port, and the time it went down, from there is just takes a few questions to the user and it’s easier to figure out. (Thank you SolarWinds NPM!) Then simply issuing a shut no shut on the interface will clear it, now if you have issued the mac-address sticky command you will want to clear the original mac address or else the port will simply go back into and err-disable state, to clear the sticky mac address issue the clear port-security sticky int <specify single interface> from global config mode, then proceed to shut no shut the interface.

 

Written by Stephen J. Occhiogrosso

October 21, 2010 at 12:36 PM

Let’s Look at: 1 Step Router Lock down.

with one comment

In my CCNA: Security studies one thing they go over is the 1 Step Lockdown. So I loaded up a spare router started up the SDM and ran through the 1 Step Lockdown.

 

Launch Scree of the Cisco SDM

Cisco SDM loading.

 

Now every time I use the SDM I always enable the option to see the IOS commands before they are delivered to the router. I do this for a few reasons, One to go over the commands and make sure they will not interfere with anything already running on my network, and Two it leads to some good learning. Below you find the IOS commands used by 1 Step Router Lockdown:

Read the rest of this entry »

Written by Stephen J. Occhiogrosso

September 29, 2010 at 1:20 AM

%d bloggers like this: