The occassional trials and tribulations of a jack of all tr ades sysadmin in a startup in Silicon Valley
For the best possible security, servers should be on a seperate network from any machines that connect to them and the traffic to and from the servers should be restricted by a firewall with active intrusion detection monitoring.
That type of firewall is complex to manage and likely to be quite expensive (in general, throughput is a major factor in the cost of a firewall). The benefits of such a setup are unlikely to surpass the limitations and expenses encurred. The opposite end of the spectrum is to plop your servers onto the same network as all of your machins and do everything on that one network.
A good in-between setup is to place your servers on two separate networks and move all services that you can from the network shared with the workstations to the server only network (effectively setting up an out-of-band network).
Each of my servers has at least two network interfaces (mostly dual port Intel Pro 1000/MT Server Adapters). One of those interfaces is connected at 100 megabit to the general network shared with all of the workstations. The other uses a private ip addressThis setup has provided performance improvements and increased security. The performance is only real noticed when performing backups, although it has given me the bandwidth needed to experiment with the idea of moving my VMWare images to a NAS like device.
For the security improvements, I needed to move services from the public network to the private one. I was able to relatively easily move my snmp queries, backup process, and ssh access to be accessible to only the private network. Now if only I could work out how to only enable Windows Remote Desktop on just one interface.
[2006/05/18 | /networks | permanent link]
The only access I have to do network configuration for ports under my control is via a custom campus written web application. For each port I can configure things like rate, duplex setting, and what vlan it is on. This system has been in place for nearly two years, and just last month they finally made it possible to lock specific jacks to specific MAC addresses.
Tangent: MAC address filtering is not secure in and of itself. Spoofing the MAC address a card responds to is possible with pretty much every network card and OS I have used in the past several years; it can even be done in the bios on some motherboards. It is however quite an effective deterrant against casual attempts to hook non-sanctioned equipment.
Now this new feature only allows you to lock a single port to a single MAC address. This is a useful thing for most systems administrators on campus. Being able to limit which computers professors plug into the network jack in their office will most definitely improve the overall well being of campus networks. I had hoped however for a system where I could setup lists of addresses and I could specify that a port should be restricted to one of the lists (the simplest form of course being a single address being locked to a single port). My hopes however were dashed with the last section of the introductory document announcing the MAC address locking feature.
It seems the campus-wide network architecure team feels there are political and logistical reasons (which they choose not to share) not to provide list based locking. The only explanation they provide is that it is better network design to provide each device with its own jack (this is a concept I do generally agree with).
Clearly the campus-wide network architecture team needs some more creative thinkers on it. I can think of a few situations where it would be useful.
I am annoyed at this mostly because of what should be possible, and not by what I actually need now. I have much bigger fish to fry before I get around to MAC address locking at the switch.
[2006/01/17 | /networks | permanent link]