Console access is the next best thing to being there. You can do things on a console that you can't do by normal remote management. For example, you can't normally see the status of the boot RAM check remotely, and if a server is rebooted and a floppy disk is in the drive, the computer's operating system might not load. The network card might go bad, or the server could become unplugged from the network. No matter how good the operating system is, you will need to access the console at some time. But console access is beyond just servers. Routers, switches, VPN devices and other network equipment may require console access to manage or upgrade. If the network crashes at 2 a.m., do you want to go to the office to fix a router? Fortunately, there are several techniques to secure and connect a device physically.
Many network devices come with RS-232 serial ports for console connections. Some firewalls, for example, need to be configured with a serial cable. The most common way of doing this is to connect the firewall to a desktop's or laptop's serial ports and use HyperTerminal. Most serial cables are about six feet long, so though you can buy longer ones, this isn't a very versatile solution. It's much more convenient to access the console port remotely so you don't need to enter the machine room to configure a router.
Securing the Site
Before you deal with ensuring secure remote access to the console, make sure the console is secure on-site. Part of this depends partly on the operating system (it should have a login screen, prevent brute-force password guessing and/or not allow a reboot from the keyboard--that is, by pressing ctrl-alt-delete). Make sure console passwords are in place; you'd be surprised how many routers don't have passwords set. Don't use the defaults, and try to make them hard to guess. This is standard security stuff.
It is also important to remember that someone with physical access can "hack" your system down by pressing the power button.
Some computer systems have a special lock mode that locks the power reset, keyboard and mouse from any input. These systems are useful in that you lock the computer with a physical key, just as you would your car or house. The only catch is that you have to carry yet another set of keys. Many BIOS will let you change the boot volume order. A common factory default order is floppy drive, CD-ROM, hard disks. On a server, you will want to change that to hard disk first (and change it back to floppy or CD only if the operating system needs repair). Place a password on entering the BIOS to prevent anyone else from changing this setup.
Whether you are using a server or network device, the best bet is to have the unit protected in a locked room or controlled area, accessible only to the people you trust. If you have some extra money, put in trip wires and motion sensors in the air ducts, plenum ceiling space and raised flooring. Include a time-stamping capability; it'll help later if something does go wrong.
Restrict access to your machine room (or machine closet) by making sure to tell building security who is authorized to enter the room (especially important should you forget your keys one day). Other good ideas include putting a list on the door with the names of those allowed in and never opening the door for anyone except yourself.
Of course, some people can get past the security department easily. I've seen an expired temporary employee ID, one year out of date, used to get into a site where the security department simply performed a visual flash check. And at one of my previous jobs, I once accidentally flashed my Blockbuster card instead of my employee ID badge and got into one of the campus buildings I rarely entered.
Remote Connections
Your remote console server can be bought or homemade. Remote console servers have multiple RS-232 ports, into which you plug various network equipment and then you SSH (Secure Shell) into the console server. This server looks and works like a remotely accessible KVM (keyboard, video, mouse): It plugs into the network, and you access it via IP.
If you have multiple console devices scattered about a room or among multiple floors, buying several console servers may be expensive. Instead, you can build your own with old hardware for little money.
Roll Your Own
Building your own console server is easy. All you need is an old PC and some additional serial cards (most PCs come with only two ports). Multiport serial boards, such as those from Digi International, that install under Linux are available. RS-232 connections are limited to 25 feet, so remember to consider distance issues.
Because console connections use such low overhead and bandwidth, even aging 386s and 486s can be used. Linux makes an excellent and inexpensive remote console server. Just SSH into the box and access the serial ports from there. This is especially useful for dial-up connections. Keep in mind you don't need to use Linux here--we're just using it for our example. Other Unix and Unix-like operating systems, such as OpenBSD, would work fine. Just note that the naming convention of serial ports under different versions of Unix may vary slightly.
First, install Linux. Make Linux recognize all your serial ports. You may need to install custom drivers, depending on your serial port chipset (and if you installed extra serial cards). There is a how-to about configuring and installing serial ports at www.linuxdoc.org/HOWTO/Serial-HOWTO.html. The serial ports should appear in the file system as device drivers /dev/ttyS0, /dev/ ttyS1 and so on.
Next, install a program that can communicate with the serial ports. C-Kermit is available for free at www.columbia.edu/kermit. Normally, you have to be root to access the serial ports. Information about letting nonprivileged users employ Kermit is available at ftp://kermit.columbia.edu/kermit/f/ckuins.txt. This documentation should help with any configuration issues.
Now that everything is working, execute Kermit. Type set line /dev/ttyS0 to communicate with the device on the first serial port. Next type connect, and you're connected. If the device doesn't present a carrier detect signal, you'll need to type set carrier-watch off before connecting. Kermit will inform you of this. To disconnect, type ctrl-\ followed by c.
There is also a way to make the device names friendlier by using symbolic links. For example, type ln ęs /dev/ttyS1 /dev/ HP_Switch. This is much less expensive than buying specialized remote-console devices. However, when dealing with many devices (20 or 30 consoles, for example), the specialized hardware devices may perform more reliably, especially if you're using x86 hardware. One problem with this setup is that if the network goes down, you won't be able to access the Linux box. That could be especially problematic if you need to reset your Internet router.
REPORTS
ANALYTICS
Follow 
