System security is like the weather; lots of people worry, but no one actually does anything about it. The January Computers & Networks column “Media network design” introduced network architectures that not only support the unique characteristic of media networks, but enhance security as well. The February column, “Media network hardware,” emphasized that having the correct media network hardware in place increases security. This month's column will talk specifically about changes that will greatly increase the security of your servers.
A not so secure situation
Let us start with an insecure configuration. Assume you are the administrator of a server used by news people in your station. This server is accessed by employees both internally and also while they are on the road. Users always interact with this system through a Web browser, and as an administrator, you have root log-in privileges (enabling full access to the server from wherever you are).
The server needs to be accessible to users inside the company and on the Internet, so it's dual homed, meaning there are two network interface cards (NICs) — one connected to the internal network and one connected to a port on a switch going directly to the Internet. A local IP address is assigned to the local NIC and a public IP address to the Internet NIC. Firewall software is installed on the server, and because the computer will be on the Internet, you move the Web service from Port 80, the well-known port number for Web traffic, to an obscure port, such as Port 3332. Then, you are off and running.
Unfortunately, hackers are off and running as well. Within minutes of installing the computer, the logs show that the server is being scanned by bad guys on the Internet. Shortly thereafter, port 3332 is being hammered, and hundreds of aborted log-in messages on Port 23 (Telnet) say that user Admin failed, user Fred failed, user George failed, etc. The Apache security logs show the same thing — hundreds of aborted log-in attempts.
The next day you are amazed to see more than 20,000 aborted log-in attempts. You also notice a few strange entries in the system logs. Given the situation, you realize there is a serious security issue, and the new server may have already been compromised. But what can you do? Users have to utilize this system, and they must have access over the Internet. There has to be a solution.
Specific recommendations
- Do not rely on obscure ports to hide a serverThis is called security through obscurity. It is also called lame by both security experts and hackers. A great tool for showing just how poorly this works is Network Mapper (NMAP). NMAP can test thousands of ports on thousands of IP addresses in a very short time. Hackers run these tools constantly. No doubt this is why, in just a few minutes, hackers were pounding away at port 3332.
- Get rid of the dual-homed situationRemove the NIC card with the public Internet address. Figure out how to configure port address translation (PAT) and network address translation (NAT) on the Internet router. This way any requests coming from the public Internet will be directed to the server without exposing the server directly to the Internet.
- Consider putting the server in a demilitarized zone (DMZ)Conceptually, this means that you grant access to the server by internal users but that the server sits in a separate area with tighter security. Users can still access it, but if someone compromises the server, they cannot then use it to launch attacks on other computers on your internal network.Both of the latter two actions are intended to put a router/firewall between the server and the Internet, as well as protect the internal network from a server that might become compromised.
- Have users access the server through HyperText Transfer Protocol - Secure (HTTPS) rather than HTTPVirtually all Web servers support HTTPS. HTTPS encrypts communications between the user and the server, making it difficult to sniff communications between the two. Why is this a good idea? Password crackers such as Cane and Abel can sniff hundreds of thousands of packets per hour looking for username/password combinations. They are specifically configured to recognize and record these combinations for use by hackers later.If you are a network guru, you might point out that these sniffers are useless because on network switches, traffic is basically routed point-to-point. In other words, if a user and a server are connected on two separate ports of a switch and a hacker connects a sniffer to a third point, he will never see traffic going between the user and the server. This is correct in normal situations.However, there are a number of tactics such as man-in-the-middle (MIM) attacks, which the hacker can use to redirect traffic through his computer for sniffing. Programs such as Cane and Abel come with built-in MIM utilities (how convenient). Using a protocol such as HTTPS means that, even if the hacker is able to reroute traffic through his computer, everything flowing through will be encrypted. Nothing is perfect, and encrypted traffic can be decrypted, but not without employing massive computing power.Once you have moved users to HTTPS, do not forget to turn off HTTP on the server. If you leave it on, hackers can still perform successful brute-force attacks on the server through HTTP.
- Stop using Telnet for system administration immediately!Telnet is 100- percent insecure. Every command is sent in the clear over the Internet. Using Telnet for system administration means that every time you log in, your user name and password are sent in the clear. This is a bad idea. Instead, use Secure Shell (SSH) or a Windows remote desktop connection. Both transmit username and password information as encrypted data. Disable Telnet on the server; in other words, turn off the Telnet daemon so that hackers who attempt to log-in to the server using Telnet get absolutely no response.
- Stop using plain File Transfer Protocol (FTP) for public Internet transfers. Similar to Telnet, FTP sends everything in the clearFTP servers have some well-known vulnerabilities, so once an attacker identifies that FTP is running on the server, he can tailor attacks to the particular FTP server being used. Use Secure File Transfer Protocol (SFTP) or HTTPS for file transfers.
- As an alternative to PAT and NAT, deploy virtual private network (VPN) technology for remote access to the serverDisable all direct access to servers from the Internet. Once VPNs are in place, hackers trying to compromise a machine will be unable to access it on any port at any IP address. Users located remotely will have to first connect to the VPN. Once this connection is made, users are assigned to a secure network segment, and only certain types of traffic are permitted to traverse from the VPN network segment to the server in question. Once the VPN comes up, all traffic between the user and the server is encrypted.These steps are all intended to keep users and administrators from transmitting usernames and passwords over the Internet in the clear.
- Stop using username/password combinations for securityTools such as THC Hydra perform brute-force password cracking. Watching these tools work is akin to watching old footage of an atomic explosion. They are beautiful and horrific at the same time. When pointed at a target, these programs launch multiple threads (think of tens of simultaneous programs, all executed at the same time), attempting to break in to a system by using huge dictionaries of popular username/password combinations, trying them on as many open protocols as they can find (e.g. Telnet, FTP, HTTP, HTTPS, etc.).Remember that the first day you saw more than 100 break-in attempts, but that on the second day you saw more than 20,000?! Hackers found your system and launched several Hydras, attempting to try as many username/password combinations as possible to find one that works. Now you know why almost all instructions that come with a computer device say to should change the default username/password combination. That combination is most assuredly already in a brute-force database.Instead of using username/password combinations, consider using public-key encryption or Microsoft Windows Authentication. These systems allow for user authentication without transmitting username/password information over the network.
Conclusion
To implement any of these suggestions, you will have to do some digging. Space prevents me from going into any more detail. That said, the digging will be worth the work.
Brad Gilmer is president of Gilmer & Associates, a management and technology consulting company.
Send questions and comments to: brad.gilmer@penton.com
