Michael McNamara

technology, networking, virtualization and IP telephony

Are you doing your part to thwart DDoS attacks?

by

I was recently talking with some colleagues about the increasing threat of DDoS attacks using spoofed IP addressing and we ended up deep in discussion concerning BCP 38 / RFC 2827. The Best Current Practice and Request For Comments document is an outline for Internet Service Providers to perform ingress filtering on the edge for their networks for valid source IP prefixes. While ISPs have a responsibility I would argue that large and small enterprises have an equal responsibility to filter their egress traffic to ensure that they don’t source any traffic onto the Internet that doesn’t have valid source IP information. I personally like to do this extra level of filtering on my Internet facing router, this also helps prevent any private IP address leakage due to a poor NAT configuration on the border firewall.

A few years ago I had to work with an ISP that couldn’t understand how my Internet link was being flooded by packets that were being sourced from 127.0.0.1 egressing their network. I had to send them multiple packet traces and tediously explain to them what IP spoofing was and how to block it on ingress into their network backbone.

On Cisco IOS routers we only need to create an extended access-list to identify those packets which don’t have valid source IP addresses. We want to permit any packet which has a valid source IP address from our public IANA IP address block but we want to deny/block any IP packet which has a spoofed source IP address from leaving our network. In the example below I’m using the three TEST networks that are designated by the IETF/IANA for use in documentation. You should substitute the three IP address blocks below with your own public ARIN/APNIC/RIPE IP address assignment.

ip access-list extended bcp38_out
 permit ip 203.0.113.0 0.0.0.255 any 
 permit ip 198.51.100.0 0.0.0.255 any
 permit ip 192.0.2.0 0.0.0.255 any
 deny any any log

Now that we have our access-list we need to apply it to outbound traffic leaving our Internet facing interface.

interface fa0/1
 ...
 ip access-group bcp38_out out
 ...

And that’s it, pretty easy and painless yet too many folks miss this simple step.

Cheers!

EIGRP Dynamic Routing or Summary Static Routes

by

I was approached recently by a client that asked me to assist them in deploying EIGRP to provide dynamic routing across their network. This client had an assorted collection of Cisco routers including some Cisco 1841, 2921, 2951s and a 3725.. This task wasn’t very difficult or complicated but the client wanted to minimize any interruption to their network and wanted me to help guarantee their success. They also wanted me to train their staff how to configure and troubleshoot EIGRP.

This material has been covered hundreds if not thousands of times on the Internet by engineers and writers much more skilled than myself. However, I’m getting desperate for content here fellas and I’m running out of life stories.

I had explained to the client that unless they had multiple paths (routes) between their geographically located facilities they probably didn’t need a dynamic routing protocol. The client explained that every time they added a VLAN to any of their sites they had to go around to all their routers and update the static routes. I asked them if they had tried using summarized static routes. I explained to them that if they had laid out their IP address space appropriately they could utilize summary static routes as opposed to creating a route for every individual network or VLAN.

topology-ip-summary

In the example above I have three physical locations. If I keep the IP addressing at each site within the Class B network then I can use a summary static route which will cover all future networks that I might want to route for in the future. A summary static route of 10.100.0.0/16 would cover any network that had started with 10.101.x.x. In the end it turned out that they had deployed their IP addressing in a rather haphazard fashion that wasn’t going to allow the use of summary static routes. In order to help their staff understand how dynamic routing worked I built a simple GNS3 lab with a simple hub and spoke topology simulating a single central site with two remote sites. I kept it super simple, and explained the difference between dynamic and static routing and how EIGRP built the routing table around it’s discovery of neighboring routers and networks.

topology-1024x437

The use of GNS3 allowed the staff members to interact with the test environment without fear of blowing something up in production and allowed them to build their confidence as we played around with various configurations, intentionally and occasionally accidentally breaking things to see their effect on routing.

In the end we only need a few commands to enable EIGRP;

router eigrp 1
passive-interface FastEthernet0/0
network 10.0.0.0
no auto-summary

With that configuration applied to all three routers we had dynamic routing up and running in our GNS3 lab configuration. When it came time for the actual deployment into the production network we ran into a small problem with their guest wireless network. They had used the same IP address space at each facility and it was routable via the local router so we had to exclude the IP network from participating in EIGRP by changing the inverse netmask of the network command. Here’s an example for the topology above;

network 10.100.0.0 0.0.255.255
network 10.150.0.0 0.0.255.255
network 10.200.0.0 0.0.255.255

We also added a few ACLs to help prevent the guest wireless network from accessing the internal corporate network.

With that tweak complete we had everything up and running and we proceeded to remove the static routes from all the configurations. If you’re interested you can download the sample GNS3 (v0.87) topology from this link, gns3-test.

I advise clients to think carefully how they layout their IP addressing schema. It can be painful and expense to change IP addresses after you’ve deployed your network.

Cheers!

Note: This is a series of posts made under the Network Engineer in Retail 30 Days of Peak, this is post number 22 of 30. All the posts can be viewed from the 30in30 tag.

IP Security Cameras

by

VPIP-D136X-OIs that security camera or video surveillance system connected to your network?

Well if it is you had better start doing your some engineering before you end up with potential bandwidth and power problems.

Video surveillance is becoming more and more common place in large enterprises and there’s no doubt that IP based surveillance systems and digital video recorders (DVRs) have revolutionized the security industry. Their introduction onto enterprise networks though is starting to raise some eyebrows as the shear number of IP cameras balloons and the bandwidth and power hungry devices start putting a serious pinch on existing network infrastructures.

There are obviously a lot of factors that affect how much bandwidth and power a specific IP camera will consume. The bandwidth consumption can be relative to the resolution (QVGA/HD), the frame rate, compression, video codec (H.264), type of camera (fixed or PTZ) and the complexity of the actual picture. I typically see bandwidth utilization of 1.5Mbps – 5Mbps per camera depending on the conditions outlined above. The power consumption will usually depend on the camera make and model but 720P fixed cameras will generally consume 11W (802.3af) while higher end point to zoom cameras can consume a full 30W (802.3at).

1Gbps Uplink1Last year we installed around 139 security cameras into a new parking garage at one of our facilities. Each of those IP cameras is streaming to a digital video recorder (DVR) located in the local security office. You can only image how many DVRs there are in the security office. As you can guess the bandwidth utilization across the uplinks to the edge/closet switch that feeds the security office is significant. The yearly average for each of the uplinks is around ~ 75Mbps, totaling 150Mbps in all. That’s a pretty significant bit stream even compared to traditional bandwidth hungry applications such as PACS (Picture Archival and Communications Systems).

Like the rest of the enterprise the same security office utilizes IP phones for voice communications so engineers and architects need to be mindful of the role that QoS (Quality of Service) plays in guaranteeing available bandwidth and buffers for critical real-time application traffic flows.

I know a number of organizations that have decided to build a completely separate network just for their video surveillance and access control systems. The intention being to reduce any impact on the production network and to maintain those critical security systems if the production network should ever fail. There are obvious pros and cons to this approach, the most obvious being you now have 2 networks to support and maintain 24×7.

My Thoughts

I usually advocate utilizing a single network with adequate capacity and redundancy to meet the design requirements of all the application traffic the network will be supporting. If you’re going to be supporting video surveillance traffic make sure you allow adequate bandwidth and if possible that you locate the DVRs as close to your core as possible. Some video surveillance solutions support Multicast to help reduce the amount of traffic so if you are streaming to multiple devices such as a viewing station and DVR simultaneously you might want to look into whether the manufacturer supports Multicast. Just don’t be surprised when you install 100+ security cameras and find that’s your top traffic generator.

Cheers!

DHCP Snooping ARP Inspection IP Source Guard

by

890258_17394208Here are three features that are often not implemented in most networks but could help to really address security shortcomings and potential operational issues.

I’ve recently started implementing DHCP Snooping, Dynamic ARP Inspection and IP Source Guard in my networks so I thought I’d take the time to strike up a conversation around those features and hear what everyone else is doing.

These features are all intended to provide a more stable network environment and help protect against intentional and unintentional events that can interfere with the proper operation of the network. Before we can implement any of these features we need to understand how they work and what changes (if any) will be needed to support them.

Hopefully most people have Spanning Tree, FastStart, BPDU filtering (guard) and Broadcast/Multicast rate limiting enabled by now but if you don’t you should certainly look at enabling and configuring those features before you start to try any of the ones I’m about to discuss.

The sample configuration code provided below is applicable for Avaya Ethernet Routing Switches.

DHCP Snooping

Dynamic Host Configuration Protocol (DHCP) snooping provides security to the network by preventing DHCP spoofing. DHCP spoofing refers to an attacker’s ability to respond to DHCP requests with false IP information. DHCP snooping acts like a firewall between untrusted hosts and the DHCP servers, so that DHCP spoofing cannot occur. There are 2 types of ports in DHCP snooping, trusted and untrusted. The network will only allow DHCP responses from trusted ports – usually uplinks as opposed to allowing DHCP responses from untrusted ports – usually edge switch ports.

Example, if someone brings a Linksys router into the office and connects the LAN side to your network the Linksys router will start handing out 192.168.1.x IP DHCP addresses which will likely cause some chaos. DHCP Snooping will prevent those DHCP responses from poisoning your network. I’m happy to admit that this is happened to me on more than one occasion, usually at our remote finance office where auditors think their second job could be in Information Technology.

DHCP Option 82 – With DHCP Option 82 the switch will append additional information to the DHCP request which can be stored in your IPAM (IP Address Management) solution to help identify the switch and port from which the request was initiated. This can provide diagnostic and troubleshooting information which can all be stored directly in your IPAM if it supports DHCP Option 82. Infoblox supports DHCP Option 82.

The latest software releases support the ability to copy the DHCP binding table up to a TFTP server. This prevents the switch from throwing away all the previously learned DHCP transactions between reboots or restarts of the switch.

In this example our uplinks are 1/24 and 2/24, all interfaces are untrusted by default.

ip dhcp-snooping vlan 10
ip dhcp-snooping vlan 11
ip dhcp-snooping enable

interface fa 1/24,2/24
 ip dhcp-snooping trusted
exit

If you want to enable DHCP Option 82 support;

ip dhcp-relay option82
interface vlan 10
 ip dhcp-relay option82
interface vlan 11
 ip dhcp-relay option82

You can also edit the text string the switch will append per port with the following;

interface FastEthernet 1
 ip dhcp-relay option82-subscriber-id <string 1..255>

Issues with DHCP Snooping

While you need to properly identify trusted and untrusted ports there are very few draw backs to utilizing DHCP snooping. It only prevents DHCP replies from untrusted ports essentially preventing DHCP spoofing in the network. DHCP Snooping can be enabled in most networks with a few configuration changes and very little danger (impact).

Dynamic ARP Inspection

Dynamic Address Resolution Protocol (Dynamic ARP) inspection is a security feature that validates ARP packets in the network.

Without dynamic ARP inspection, a malicious user can attack hosts, switches, and routers connected to the Layer 2 network by poisoning the ARP caches of systems connected to the subnet and by intercepting traffic intended for other hosts on the subnet. Dynamic ARP inspection prevents this type of attack. It intercepts, logs, and discards ARP packets with invalid IP-to-MAC address bindings.

The address binding table is dynamically built from information gathered in the DHCP request and reply when DHCP snooping is enabled. The MAC address from the DHCP request is paired with the IP address from the DHCP reply to create an entry in the DHCP binding table.

When you enable Dynamic ARP inspection, ARP packets on untrusted ports are filtered based on the source MAC and IP addresses stored in the DHCP snooping table. The switch forwards an ARP packet when the source MAC and IP address matches an entry in the DHCP snooping table. Otherwise, the ARP packet is dropped.

For dynamic ARP inspection to function, DHCP snooping must be globally enabled. Dynamic ARP inspection is configured on a VLAN to VLAN basis.

Let’s enable Dynamic ARP Inspection on VLANs 10, 11 and set our uplinks as trusted;

ip arp-inspection vlan 10
ip arp-inspection vlan 11
ip arp-inspection enable

interface fa 1/24,2/24
 ip arp-inspection trusted
exit
interface fa 1/1-23,2/1-23
 ip arp-inspection untrusted
exit

Issues with Dynamic ARP Inspection

Dynamic ARP Inspection relies on the information stored in the DHCP binding table (from DHCP Snooping) to validate the ARP packets it receives on untrusted ports. Any device whether it be statically configured or dynamically configured would need to appear in the DHCP binding table.

If you have a statically configured device you’ll need to manually populate the DHCP snooping table. If someone changed out a statically configured device the MAC address would most likely need to be updated in the DHCP binding table. If the DHCP binding table was accidentally cleared the switch would block IP traffic until the DHCP binding table was re-built either manually or from DHCP transactions.

This is another great reason to use manual or reserved DHCP assignments where possible if the device requires a persistent IP address.

This feature will likely create some significant administrative overhead based on the number of devices configured with a static IP address over the number of DHCP configured devices.

IP Source Guard

IP Source Guard provides security to the network by filtering clients with invalid or spoofed IP addresses. IP Source Guard is a Layer 2 (L2), port-to-port feature that works closely with information in the Dynamic Host Control Protocol (DHCP) snooping binding table. When you enable IP Source Guard on an untrusted port with DHCP snooping enabled, an IP filter entry is created or deleted for that port automatically, based on IP information stored in the corresponding DHCP binding table entry. When a connecting client receives a valid IP address from the DHCP server, a filter is installed on the port to allow traffic only from the assigned IP address. A maximum of 10 IP addresses are allowed on each IP Source Guard-enabled port. When this number is reached, no more filters are set up and traffic is dropped.

While Dynamic ARP Inspection blocks only ARP packets, IP Source Guard blocks all IP packets.

interface fa 1/1-23,2/1-23
 ip verify source
exit

Issues with IP Source Guard

IP Source Guard utilizes the information stored in the DHCP binding table (from DHCP Snooping) to validate the IP traffic. Any device whether it be statically configured or dynamically configured would need to appear in the DHCP binding table. Statically configured devices would need to be manually placed in the DHCP binding table. If someone changed out a device the MAC address would most likely need to be updated in the DHCP binding table. If the DHCP binding table was accidentally cleared the switch would block IP traffic until the DHCP binding table was re-built either manually or from DHCP transactions.

This feature will likely create some significant administrative overhead based on the number of devices configured with a static IP address over the number of DHCP configured devices.

My Thoughts

I’m taking a split approach right now, let me explain. I’ll be utilizing DHCP snooping and DHCP Option 82 throughout my network. Unfortunately due to the administrative overhead required to leverage Dynamic ARP Inspection and IP Source Guard I’m only planning on implementing those features at my smaller remote offices – the ones I usually have issues with from a security perspective. Since those remote offices are much smaller and usually don’t make too many changes it offers me the opportunity to evaluate the new features without over taxing my network administrators and engineers.

Cheers!

Recent Posts

Categories

SUBSCRIBE BY EMAIL