How Do You Handle Ethernet Port Management?

MTL-Stalker asks: "I am currently investigating the best way to handle Ethernet port management for an organization with over 75,000 Ethernet ports spread out over 700+ sites. I was wondering how members of the Slashdot community are handling this issue in their organizations? Obviously this is as much a business process issue as a technological solution. In today's threat-filled networks, it seems like asking for trouble to rely on a simple switch based 'port enabled/port disabled' methodology. Do you think Cisco-style port security (tying a MAC address to a particular port) or PACLs (port access control lists) are worth the effort? Are products like Cisco Campus Manager or HP OpenView worth the cost and deployment headaches? Do they address your security concerns? How many of you are using homegrown scripting and/or SNMP solutions? How many ports can you effectively manage with these solutions? I would also be interested in knowing what industries these solutions are being implemented in."

Comments

Guest-Intruder VLAN

[chill]

I've always had good luck with not necessarily tying a MAC to a port, but rather a list of approved MACs. MAC not approved gets automatically shunted to an isolated VLAN. If they bring up a browser all they see is a "welcome guest, call IT" screen. Both Cisco and HP switches can do this.

Re:What about 802.1x security ?

[Philip K Dickhead]

VLANs can be a headache too - especially with 802.1x, which requires replacing your existing access layer switches with 802.1x capable ones. You DO get the benefit of integrating your wireless access infrastructure with the copper stuff.

Are yu all/mostly Windows (2000+)?

Look closely at Windows Domain and Server Isolation. It is an IPsec based infrastructure security solution, all managed with existing infrastructure. The IPsec policy agent is on the OS, and policy is easily managed centrally by Active Directory and Group Policy. It really is great - and can interop with other IPsec stacks like Linux and Solaris. The default auth mechanism is Kerberos - but x.509 can be used in parallel for interop. Kerb is dead easy.

If this is even only an 80% solution, it should be explored. There are no hardware costs in most cases, it can be phased in without field visits, and you probably already own it.

http://www.microsoft.com/technet/security/topics/a rchitectureanddesign/ipsec/default.mspx

I wish that one of the big Linux vendors would do something like this with IPsec and OpenLDAP. We have spent years matching the desktop, when developing advanced infrastructure management is where the winning game has moved.

Migration path: manual-scripted-RADIUS-802.1x

[kalvyn]

I just recently stopped working for a government agency and I was responsible for managing port security on about 6000 ports. Our current end-game solution is to use 802.1x, however due to certain regulations, our agency couldn't operate a CA, so we couldn't feasibly request a new certificate for each host everytime one completes an accreditation process. But we were implementing everything else until we could get there.

Our short term solution is to standup a RADIUS server and use it for port-security. This isn't quite as good as 802.1x, but provides the same level of scalability without going as much in-depth. You bascially have your switches (assuming they have this ability) check the radius server for allowed MACs. This works the same as the MAC ACLs, but is centrally managed. We haven't gotten that far yet either, as we didn't have a RADIUS server. (more stupid regulations that make that a headache)

So, the current process is to manually change the MAC address on each port on each switch. We initially turn on port-security on the switches, and for the newer ones (Cisco 3550/3560/3750) once we determine that all the users are on that need to be on, we drop all other ports into a dead-end VLAN that has no access. The remaining ports we drop into our data vlan (we also have dedicated vlans for voice, wireless, video, and infrastructure management). Once we've established that, we secure the MACs to the ports. All port security violations are logged to a syslog server and the switches are set to restrict access. This prevents useless work of re-opening ports when some user decides to plug-in their home machine to download the latest Linux ISOs or torrents. For further changes (i.e. when a new machine gets put on the network), a call is made to the helpdesk which routes the ticket to the networking team (that's me) and I unlock the port. We then have to notify the security team, which scans the machine for vulnerabilities and applies patches as needed. After that, it is managed by WSUS and SMS.

Now this sounds very tedious, but it isn't that difficult to manage. For the last 2 months, I managed all port security by myself, as well as down network links, some remote office firewalls, and new switch installs. Port security helpdesk tickets were typically closed within 2 hours of the request (assuming the helpdesk tells me about them). As a bonus, and because I'm lazy, I wrote some scripts for WSH that will connect to a switch, get a listing of all port-security information, compare it to DHCP leases on Windows servers, and output a table that shows which host is on which port. I also expanded this for use on WAN links where it will recursively access all switches at a site, stopping when it reaches a router and display the same information on a per-switch basis. A pretty handy report. Useful for telling you which hosts aren't using DHCP (so you can ensure they belong there). The only real requirements for this to work are that the switches use CDP on infrastructure links and they support ssh. You also have to have a CLI ssh client that supports putting the password on the command line (or certificate based auth if you can set that up, I don't think Cisco devices support it, although I think kerberos works :)