Home | Articles | About | Contact | Forum |
Wednesday, July 30, 2014



Lunarpages.com Web Hosting

Mailing List

E-mail:
By Joining the mailing list you will be notified of site updates.


Show Your Support For
This Site By Donating:











Audience: System Admins
Last Updated: 5/28/2005 6:39:01 PM
Original Creation Date: 5/28/2005 6:39:01 PM
**All times are EST**




Physical Network Security

By Erik Rodriguez

This article describes, in some detail, a physical security audit. Physical security is often over-looked and should be a main focus by organizations and I.T. professionals.



Introduction

You can find many articles on this site and others about network security. Most of these articles contain information about securing your network and keeping people out. In other words, focusing on remote security and protecting your private network. However, it's physical security that is often over-looked by many. This article will describe, in some detail, a physical security audit I performed on a university campus.

Physical Threats

What are the main threats in regard to physical security? When you think about physical security, most people think locks, cameras, and maybe even guards. However, the infrastructure of a building should be carefully considered before deploying a network or any type of information technology. The 3 most common threats are:
  • Theft of Property/Data
  • Theft of Identity
  • Destruction of Property/Data
Depending on the physical location, some of these threats may rank higher on the list than others. For instance, a high-level production or service company may have heavy competition from other companies. It is not uncommon for companies to hire hackers to steal or erase data from competing companies' networks. On the other hand, public places such as libraries really aren't a target for data theft. The main concern of a public place is theft of property. Other places such as high schools may be targeted by angry students for destruction of property. It's sad that we live in a world like this, but things are the way they are. The only thing you can do to counter this problem is by planning and executing the proper security measures.

The Details

I conducted this audit twice during one day. First, I checked nearly every server room/wiring closet I could find to see the doors were locked. For the most part they were. However, one building had an un-locked server room, and also an open wiring closet that exposed the phone system. The first time I observed the open doors was approximately 11 AM. Keep in mind that this is a public university which means any citizen/non-citizen can freely enter/occupy the buildings. There are no I.D. badges required anywhere except the actually data center which is not open to non-employees. Other things taken into account during this audit were physical location of equipment rooms, floor plans, types of locks, and Surveillance.

As I mentioned above, I was able to located one server room that was unlocked. Upon inspection, the lock on the door was a fairly secure pin and tumbler lock. The door didn't have a window (it really shouldn't) and the room did not contain any type of Surveillance equipment. From the research I conducted, the lock used is fairly expensive and contains 7 pins. Most standard residential locks contain 5 pin. 6 pins if it's a good lock. 7 pin locks are not easy to pick, but an experienced lock picker could accomplish the task in no time.

The room contained a server rack with 29U worth of equipment. Of the equipment mounted in that rack, there were 6 servers. They ranged from standard 2U dell servers, to a 6U HP Netserver. There was a very large de-commissioned alpha server sitting on the floor. There were also 3 racks containing various patch panels (fiber/copper) and switches. All equipment appeared to be securely mounted. The server rack was locked. However, the back of the rack was open, and the lock on the front of the rack wasn't at all high-end. Someone creative may be able to find a way to open the front door from the back, or simply pick the front lock. Here are some pictures:



Above, you can see the lock used. Fairly strong, but should contain a "latch guard."



Here, you can see the fiber patch panel. Destruction of property in this case could include cutting a section from the fiber. Fiber itself is VERY difficult to splice and repair. This may mean that a completely new piece of fiber would need to be run.



A look at the switch racks.



Notice the servers inside the rack. The 2U dell servers have the drive trays exposed. These servers should have the front panel locked on the front as you see the 5U silver dell server does.

It Gets Worse

As I mentioned before, I performed 2 visits during this audit. The first at approximately 11 AM. The 2nd visit was approximately 9 PM. I did this for two reasons. First, I wanted to give the I.T. staff a second chance. Perhaps I had caught the door unlocked for reason. Maybe they were in and out of the room all day? The second reason, to see if the building itself was locked. The cleaning staff (if they have one) should be done by 9 PM. The results, both doors were un-locked! All 3 entrances to the building were unlocked and the server room was still unlocked. This means I could have shut myself in the server room for literally the entire night and had access to all the equipment. Given this situation, here is a list of possible outcomes:
  • The lock protecting the servers could be picked or broken.
  • The hard drives of all the servers are easily removable and could be stolen. CPU's and RAM could also be easily removed if the servers have the side rails installed. These servers could actually be stolen fully intact during the night before anyone realized they were down.
  • Given the amount of time, practically any server could be hacked from the console.
  • Physical access to Cisco switches allows you to reset the passwords.
  • Use of a laptop inside could facilitate a MiM attack, local DoS attack, or other malicious activity.
  • The entire room could be re-wired and relabeled causing weeks of confusion for the I.T. staff. (What a mean trick!)
Remember that this was a public university. Meaning, the data located on these servers could contain confidential research, student grades, social security or student ID numbers, and best of all TESTS... An entire night of console access could give a determined hacker access to nearly anything he/she wanted. Remember that while Windows and Linux servers are (or should be) very secure remotely, console access makes it much easier for a hacker to bypass or reset system passwords. In many cases, these servers can be used to connect to other machines within the campus and require no authentication. Also, physical access could also allow a hacker to add accounts to the server. Those accounts could be used to access the server remotely and launch a DoS attack. Remember that most hacks aren't noticed right away. They are usually found weeks after, or when the system takes place in a DoS or DDoS attack. Universities also have some of the fastest connections on the planet making them attractive targets for DoS hosts. This is assuming that the console machines are not already actively logged on as a super user. If they are, the hacker gets an early Christmas present.

Lock It Up

So, after evaluating the situation and possible outcomes, there are several things that can be done to prevent this:
  • LOCK THE DAMN DOOR!
  • Add hallway cameras
  • Add a latch guard
  • Use some visual/audible deterrents
Locking the door goes without saying. Server rooms should never be unlocked! While it may be in-convenient for I.T. staff, adding a combination lock or magnetic badge system is an easy solution. Latch guards should be installed to prevent prying the door open with a crow bar. Hallway cameras are also a good idea. Remember that not all cameras you see in public places are real. It is very hard to tell the difference between real and decoy cameras. Adding several decoy cameras in the ends of the hallways are good deterrents for un-wanted visitors. However, when it comes to cameras avoid using wireless ones. If you must use a wireless camera, make sure it performs encryption. Un-encrypted wireless video/audio signals can be intercepted and viewed by intruders. Last, at least one visual threat should be present in the server room. This could be as simple as an audible alarm the sounds when the door is opened. A motion detector, even when not hooked to an alarm system will flash when movement is detected. An actively responding motion detector is sure to make any visitor nervous. Signs may or may not be useful. Remember that not many people read the fine print.



The image above shows a simple magnetic badge scanner that is a quick and easy way to access a secure area.



The image above shows a standard latch guard. These are used to prevent people from prying the door open.



The image above is a hallway camera. I'm assuming it's real because you can see DC power wires screwed into the green harness. This suggests they are connected to a DC power source that will function in event of a power outage. If this is a fake camera, it's a damn good one! Notice that it's not wireless.

Conclusion

In conclusion, you should see the physical security is AS or MORE important than remote security. As mentioned before, physical security is often over-looked and/or poorly planned. Another important note worth mentioning, DO NOT DO THIS! While the door should have been locked, that didn't give me a free pass to be in there. If caught, it is possible I could have faced charges for trespassing among other things. Tampering, stealing, or destroying other people's property is a crime punishable by jail time! Skullbox.Net does not promote un-authorized access to restricted areas. The author takes no responsibility for actions resulting from this information.


TCP vs. UDP
Extreme Networks: Downloading new software image
Juniper SRX save config to USB drive
Juniper SRX logout sessions
Extreme Networks Syslog Configuration
Command line drive mapping
Neoscale vs. Decru
Data Security vs. Data Protection
Juniper SRX Cluster Configuration
HOWTO - Create VLAN on Extreme Switch
Using a Non-local Colocation Facility
Linux Server Administration
IT Chop Shops
Flow Viewers: SFLOW, NetFLOW, and JFLOW
Exchange 2007 Back Pressure
IPtables open port for specific IP
Politics in IT Departments
HOWTO - Block Dropbox
Cisco IOS Cheat Sheet
Subnet Cheat Sheet
Design a DMZ Network
How DNS works
Firewall Configuration
Juniper SSG Firewalls
Server Management
Configuring VLANs
Runlevels in Linux
Server Clustering
SONET Networks
The Red Hat Network
Server Colocation
Complicated Linux Servers
Dark Fiber
Data Center Network Design
Firewall Types
Colocation Bandwidth




Copyright © 2002-2014 Skullbox.Net All Rights Reserved.
A division of Orlando Tech Works, LLC
By using this site you agree to its Terms and Conditions.
Contact Erik Rodriguez