- X Marks the Hole
- Law of the Jungle—Physical Security
- Physical Actions
- Selected Short Subjects
- Terminal Device Attacks
- Disk Sniffing
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.2 Law of the Jungle—Physical Security
DANGER LEVEL 
While I consider an important part of civilization to be reducing the need for the law of the jungle in one's daily life, sadly it still must be considered. The despicable and cowardly acts of a small group of people on September 11, 2001 in murdering nearly 4,000 innocent people reminds us that all security and civilization ultimately depend on physical security and force. Without it, there is no security or civilization. Some people suggested that the U.S. response should have been the detonation of a nuclear weapon in Afghanistan, regardless of the consequence. This indicates that excess security can cause more harm than good.
In this case, the harm would be millions of deaths and the likely start of world war. There is ongoing debate over whether the U.S. intelligence services should have assassinated Osama bin Laden after the first time his terrorists attacked the World Trade Center some years ago. As we all know, the best solution is not always obvious nor will there be universal acceptance of any solution.
Two of my clients were relieved of their laptop computers at gunpoint, one with his only backup, on CD-RW, still in the system. A third client suffered because a student, who was unhappy with his restricted network privileges that came as a result of the student's violation of security policy, broke into the SysAdmin's office for revenge.
Gone are the days of ivory-tower mainframes (although the mainframe still is very much alive) where you had to know a secret incantation and handshake to get into the server room. As computing has become less expensive and smaller, it has become more distributed. This allows workgroup servers to be physically located closer to those who use them. This advantage also has a downside. The value of the data located on these distributed servers has increased, and is easier to obtain. A skilled intruder can remove a hard drive from a tower system in five minutes and from most laptops in one minute.
The physical console of the Linux server almost universally is considered a privileged console where root can log in. Linux also considers the keyboard directly attached to the system more than just an input device. The dreaded three-finger salute (Ctrl-Alt-Del) will reboot a Linux box (unless specifically disabled), and the power switch and reset button will still be working. See "Physical Actions" on page 125 to learn other things that crackers do when they get physical access to systems.
To prevent problems of access to these privileged devices (i.e., power switch, reset button, and keyboard), access to your Linux-based server should be controlled through physical means. If this requires you to keep it in a locked room, closet, or cabinet, consider this investment in physically securing the machine to be money well spent. Consider for a moment a tape drive attached to the server. Most modern tape drives can store from 2 GB to 200 GB. By not physically securing the system,4 a well-placed bribe to a janitor, an excuse about forgotten keys, or a disgruntled employee very quickly could result in the removal of the completed backup tape. The intruder then would have all of your financial, customer, inventory, and other critical data. This information could wind up in the hands of a competitor or on the Internet. The trend toward network backups makes the likelihood much greater of storing all this data on that one tape.
Remember, it is not really the hardware you are protecting. Hardware is cheap. Your data, however, is not. It represents your business. You bill clients and make decisions based on it. By not taking adequate steps to protect it, you leave yourself open to theft, modification, or loss.
In many organizations physical security and computer security are two separate departments with no dialog between them. Worse, "turf wars" can cause managers to determine who and what is located where, rather than what will provide the best security. At one company where I did a security audit, a set of consultants who clearly were not trusted had been given offices right next to SysAdmins. The SysAdmins left root shells accessible. Nearby, programmers were creating their next generation of software. In the same hallway, in the open, were servers with confidential data.
The following are some suggestions for improved physical security. Not all are appropriate for all environments.
Make frequent backups and relocate them off-site. My general rule is that the likelihood of simultaneous damage to the main site and the off-site backup locations should be remote. Theft, fire, and equipment failure are the most likely events to guard against. Do not forget that with a fire you can expect anything not waterproof to be destroyed by sprinklers or fire hoses.
Home users can store backups in bank safety deposit boxes, the office, or at a trusted friend's. Storage in an automobile during the summer will result in melted plastic. Off-site backups can be as easy as e-mailing or copying recent critical work to another site, typically one's home or office account or system. Confidential data should be encrypted before mailing, copying, or storing on a less than very secure site. See "Protecting User Sessions with SSH" on page 409 and "Using GPG to Encrypt Files the Easy Way" on page 431.
Have and enforce a policy requiring employees to challenge any unknown persons for proof they belong (or to contact Security or Management).
Do not locate Ethernet jacks in public areas where nonemployees can plug in Laptops, unless the Ethernet segment is separated from internal networks by a firewall.
Make needed changes to physical construction to enforce security. Areas that visitors, clients, vendors, and others frequent should be securely separated from areas where confidential data might be. This includes Engineering, Human Resources, anywhere customer lists are kept, and any executive's offices. Even at small companies, I have seen strangers wandering about such areas unchallenged.
Use cardkey-controlled doors (with secure logging of accesses) and ensure that doors propped open for more than 30 seconds generate an alarm. Use guards and TV cameras when appropriate.
Test security periodically by having someone unknown to the guards (but with prior written approval by management) test security. Then fire the guard or security company if your plant gets in. Require that any contract with the guard service allow this. Recent FBI tests of security showed that most guards are all too eager to accommodate strangers and allow unauthorized access.
Do not trust fingerprint readers, as many of the current ones can be defeated by gelatin molds made from latent prints (as in from fingerprints left on a glass at the local bar) for about $50.5 This technique worked 80 percent of the time against 11 commercial readers, works even if the guard is watching, and the evidence can be eaten afterwards.6 If you have the original finger itself then it can be done for $10 in one step. Other techniques such as retinal scanning and measuring finger geometry also have been discovered to be far less reliable than claimed.
A study in May of 2002 where face recognition software was tested at the West Palm Beach, Florida, airport showed a shocking failure rate of 50 percent. The U.S. Defense Department found that eye iris recognition systems were successful on only 94 percent of subjects.
rant_mode = on
In early 2000, in response to another wave of vulnerabilities having been discovered in Windows, Bill Gates said that he would solve the security problems with biometrics (i.e., support for fingerprint readers, retinal scanners, and the like). At the time, I believed this to be fear, uncertainty, and doubt (FUD) to distract from the real problem of software design flaws and bugs that biometrics would not fix anyway. So where is this Windows security that was promised?
In early 2002, in response to yet another wave of vulnerabilities having been discovered in Windows, Bill Gates said that he would solve the security problem by emphasizing better security and telling developers to spend a whole month on just security (to fix 20 years of insecure code and design problems). So where is this Windows security that was promised?
Plan on laptops being stolen or destroyed by accident. Recognize that an executive, salesman, or engineer will be keeping confidential data on it, so set them up with an encrypted file system that requires a password to be entered on bootup or when resuming work.
Configure each system to lock its keyboard after 10 minutes or so of inactivity and ensure that the lock program cannot be broken. Better still, use tcsh and configure it to do auto logout. This can be done by assigning the number of minutes of idle time before logging out to the autologout variable. For 20 minutes of idle time, issue the command
Do not rely on X-based screen-locking programs. They can be broken merely by doing Ctrl-Alt-F2 to switch to a different virtual console, Ctrl-Alt-F1 to switch back to the original console where the user already is logged in, and then Control-C to kill X. If you left root or any other user logged in on a different virtual console then they will get a bonus. Disabling virtual consoles may prevent this avenue of attack but there may be other avenues. If high security is required, X should not be on the system anyway.
In some environments it may be appropriate to remove CD-ROM/DVD burners, tape and floppy drives, and USB and parallel port access from most systems to prevent a rogue from making and removing backups. On PCs, disabling these in the CMOS and applying a CMOS password will limit activity from less-knowledgeable would-be thieves. This also prevents the making of legitimate backups and may not be worth any hostility, so it must be considered carefully. Simply purchasing new equipment without these features may be a politically more acceptable solution.
set autologout=20
There used to be support for auto logout in bash, but it appears to have been removed.
You can disable most virtual consoles by editing the /etc/inittab and removing the lines that read:
2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5
However, this will not prevent a user from starting X in background mode with startx&, thus leaving the first virtual console completely open and ready for mischief.