Archive for the ‘networks’ Category

Securing switch ports

Sunday, August 2nd, 2009

One of the projects that I’m currently working on is a large network that is in place strictly as the backbone for a IP based security system. This network is a fairly typical two layer network, with a core in the small datacenter that we are building, and distribution switches out in smaller locations around the perimeter of the secured area.

One of the issues that arose during the selling of the project was securing the network itself (it’s sad that we brought it up, but then again most physical security types have very little understanding of networks, so it’s not that unusual). Within the datacenter I’m not as concerned about the physical security of the networking devices, but at the outside edges I am.

My concern is not so much the switches themselves (though we do a lot of security configuration on them as well), but rather on the lack of security of the cabling and endpoints connected to the switches at each location.

Each of these locations has a number of IP based security cameras, access control devices, access points, relay controllers, etc, plugged into a switch. While the theory is that we’d notice anyone doing something nefarious to these devices, or the cable that connects them to the switch, we wanted to make sure that nothing could get onto the network that shouldn’t be there. Or at least have a higher comfort level that it couldn’t happen unnoticed.

So how do you make sure that nobody swaps a laptop for the camera on the end of the cable, or that someone doesn’t add drop a hub in between the camera and the switch so that they can add their own devices to the network?

In our case, since we are using Cisco switches for the project, instead of the usual junk that security companies put in place for most IP networks, we are able to take advantage of the Cisco Port Security feature.

Basically, what port security does is to keep track of the devices on a switchport, and if something happens that shouldn’t, the port is turned off. Granted, that is a very basic explanation, but you get the point.

There are some limitations as to what kind of port you can apply port security to, but as they don’t apply to the ports that I’m looking at I’m not going to get into those here. Suffice it to say that it’s mostly an issue of SPAN ports and Trunks.

The basic configuration of port security on a switchport is very simple:

Ciscoswitch(config-if)# switchport port-security

That enables port-security on the switchport you are configuring. In it’s default mode, port-security allows 1 MAC address, which is the first connected MAC address, and disables the port if there is a violation of port-security.

In our case, we are being a bit more specific:

Ciscoswitch(config-if)# switchport port-security
Ciscoswitch(config-if)# switchport port-security max 1
Ciscoswitch(config-if)# switchport port-security mac-address 1111.2222.3333

What we have added there is to define that only 1 MAC address can be on that port at a time (prevents hubs and spliced in machines from getting on the network) and that only the device with MAC address 1111.2222.3333 can use that port.

Any violations of that rule will shutdown the port and send an SNMP Trap to the operations center, alerting the staff there to the problem.

So that is how we make sure that no devices are added to or changed on the edge switches of the network.

Well, that’s most of it actually, I’ll be covering the second part of this next.

What’s on your network?

Friday, June 5th, 2009

I think that I’ve mentioned this before, but if I haven’t, here you go:

The team at Voodoo Networks, in addition to doing local office network and consulting work here in the Seattle area, also does a lot of work around the world designing and building out large networks. The reason that we are contacted about those networks isn’t due to our competence with smaller, computer centric networks, rather it has a lot to do with our expertise in building out networks that can handle not only computer data, but other systems as well. And handle them very well.

Now when I explain that to people, I frequently end up repeating a list of that kinds of things that exist on what have traditionally been computer networks up to this point. I’ll start with computer related items then go from there:

  • Computers
  • Servers
  • Printers
  • Network Attached Storage
  • Voice over IP Telephone systems
  • Video over IP Conferencing systemsv
  • Video over IP Television
  • Video on Demand systems
  • Background music systems
  • Overhead paging systems
  • CCTV and camera control systems
  • Streaming Audio Systems
  • Home Entertainment Systems
  • Home Control Systems
  • Heating and Cooling Control systems
  • Power Generation Controllers
  • UPS Controllers
  • Temperature and Humidity sensors (internal)
  • Weather Stations (sensor systems for local weather monitoring)
  • Motion sensors
  • Occupancy Sensors
  • Lighting controls (residential & office)
  • Lighting controls (outdoor & common area)
  • Water control systems (fountains)
  • Water Flow Sensors (residential & commercial)
  • Parking space sensors
  • Parking control systems
  • Vehicle identification systems
  • Access control readers
  • Access control locks and barriers
  • Location Tracking Systems
  • RFID Systems
  • Fire and Life Safety systems (not always as these are heavily regulated)
  • Building automation systems
  • Theater control systems (not home – real auditorium / theaters)
  • Leak sensors
  • Air quality sensors

Off the top of my head, that’s pretty much what I remember right now. I may update it later if any more come to me, but this is a pretty decent list even if it’s not 100% complete.

So what does this have to do with IT consulting? Well, all of these systems are things that are either delivered, monitored, controlled or viewed over what used to be a data network. And they all have very different requirements for bandwidth, latency and redundancy. From a network design perspective, these are some of the things that we think about constantly when working on networks to make sure that we compensate in the network design for anything that may be added to the network at a later date.

Many times the people that we are working with are far more concerned about the end points of these networks – the computers, security cameras, the entertainment systems, etc. But while we understand that (the shiny bits are often the most fun and interesting) we really stress that the design of a network core that can handle the stresses placed upon it now and in the foreseeable future is the key to any successful implementation, and not worrying about exactly which shiny end point we are going be using.

One quick example. Recently we were working on a project in Dubai that was just beginning construction planning. The marketing people, the sales people and the guys that were going to run this huge complex where constantly asking about what TV we were selecting for the different types of units, what handheld controllers we wanted to use and what kinds of technology the eventual residents and tenants would have.

Well, given that we were over 3 years away from actually installing any of those end points, the constant struggle we faced was explaining that we could only give them ideas, but consumer technology in particular changes so quickly that guessing what we’d be deploying in 3+ years was impossible. Last I heard from them, they finally started to realize what we were talking about when Pioneer bowed out of the TV business while they were the leader in the high end market. But no matter what TV (or any other device they eventually select), they can rest assured that the core network design that we worked on for them would have withstood the test of time, because it was designed with the needs of the network in mind, not specific devices.

And that is the moral of the story. Don’t design, or let someone else design, your networks unless you are thinking long term. If you aren’t then you will be spending money again and again to keep your networks up, running and useful over the coming years.