Slashdot Mirror
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."
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.
Learning HOW to think is more important than learning WHAT to think.
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.
a rchitectureanddesign/ipsec/default.mspx
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/
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.
"Speaking the Truth in times of universal deceit is a revolutionary act." -- George Orwell
Netdisco is an open source switch management solution. Shows you MAC, IP and NetBIOS information per port, draws graphs and allows you to change VLANs and enable/disable ports with logging.
http://www.netdisco.org/
With big jobs you have no choice but to use some highly specialized tools. It sounds like the Testum Network Management Tool would be useful.
It'll help you figure things out a lot easier. It also does a lot of other nifty things that could become useful when you need to expand the network.
... and in the DRM, bind them.
Well, first thing you want to have are good site network layouts in a CAD program, preferably done in scale. Do not worry about every single wire (it is nice though at least for the pulls from the floor to the closet's patch panels) but get the major items, devices, and closet feeds.
As for what connects where, well, that needs to be part of your asset management system to be really effective. Some type of database which contains records for each class of object (like computers, servers, switches, routers, etc., which also has fields for location and network port connectivity. Obviously you would want a relational style database, with one to many relationships for network connectivity since you may have multiple network interfaces on different devices. Now the hard part, actually making this part of your processes. You need to have this updated, and really the best way is to make sure that people have to go through the process in order to get on the network. What this means is that you absolutely must use something like "port security". If regular people can move a system from one location to another and just disconnect one device and connect this one and it works, you will never be able to keep any tracking/management system up-to-date. It will be up-to-date for a whole 5 minutes after you do an inventory of that cube/office/location before someone somewhere decides that they are taking over the room down the hall because it is closer to the window, or is next to the exit...
I can't state that enough, you need to FORCE EVERYONE TO USE THE SYSTEM. If one person doesn't use it, then everything he/she does will be under the radar and not detected which makes having such a system pointless because it doesn't contain valid data, and you might as well have done "/dev/random > my_network_layout".
We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
1) Visually inspect one known-good piece of equipment. At my organization, for reasons which are beyond me, they're printed on every laptop (along with my username and static IP address). They're also frequently printed on the physical network card. So if a computer is in a physically non-secure location (guest-accessible computer, laptop stolen, laptop taken in for repairs by Geek Squad instead of IT, laptop taken home, etc etc) thats a vulnerability.
2) Socially engineer a wireless mac address. Go to any location frequented by the workers at your target institution -- say, the cafe across the street during lunch hour. Open a wireless hotspot with a name like "Roadkill Cafe Wirless Network" and don't require any sort of authenticiation. Take mac addresses off the logs, then return to the target institution and try until you find one that works. (Hopefully they don't have their wireless addresses and their wired addresses be the same... but I've seen it done before, by lazy IT types).
3) Call and ask somebody. "*ring ring* Hiya, Suzy, this is Bob in IT. We're having some problem with the router covering your workgroup. Have you noticed any problems? No? Thats great. We put through some fixes on our end and I need to be sure that they took. Could you please hit your windows key and R at the same time? Type in command, hit enter. See a big black box? Type in "getmac". Yeah, I know, its funny to say Get Mac on a windows machine, those quirky programmers, what can I say. OK, could you read me the group of numbers and letters with the dashes in them that you see on the first line? OK, thats what I'm showing on this end too. Thanks Suzy, you're all set. If you have any problems you know who to call."
4) Sniff it out of the air (again with the wireless vulnerabilities).
5) If you can compromise any machine on the network "arp -a " gets you the MAC address of anybody you can see. I'm fairly certain you can accomplish this via ActiveX control (a quick Google found one), and also fairly certain you can not do it by Java applet.
Obviously, these are intended to tell you what you need to look out for securing your network, not for breaking into someone else's. Now if you'll excuse me I have to explain to a boss on why the whole "mac address printed on the laptop" is unwise.
Help poke pirates in the eyepatch, arr.
You might want to check out ONA - Open Network Administrator from Bruce Campbell at U of Waterloo. And his paper from the LISA 2005 conference.
http://ona.uwaterloo.ca/
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