Section 8.5 A Window Is Worth a Thousand Cannons | Real World Linux Security Prentice Hall Ptr Open Source Technology Series

8.5 A Window Is Worth a Thousand Cannons

graphics/threedangerlevel.gif

Some versions of Windows can be made reasonably secure by knowledgeable people. Windows does not seem to have the same degree of separation between ordinary users and system functions that Linux does, nor does the code undergo the review and analysis by large numbers of independent people that Linux code does. NT is included in Windows, even though it is different technology.

Windows systems also suffer from untrained users administering them at many shops. Certainly, it is encouraged that they be maintained by SysAdmins trained to do so. I am impressed by the security improvements introduced in Windows 2000 that allow central administration of boxes and control over security policy. For many organizations with Windows systems, it seems to be a good security arrangement to put these systems on what is usually called a corporate or agency-wide or office-wide network.

They pull down their e-mail from a Linux mail server residing inside the firewall via POP or IMAP. The firewall will let mail (TCP port 25) and SSH into this mail server from the Internet. It also will let pops or imaps (SSL-wrapped POP or IMAP) in so that traveling employees can receive their e-mail. Certainly, pops or imaps from systems inside the organization to the mail server also should be allowed. Thus, laptop users will not have to switch between pops on the road and pop in the office. Further, this allows those who handle sensitive information to prevent sniffing even on the LAN. Actually, encouraging everyone to use the SSL-wrapped e-mail services would be a fine idea.

Employees' outgoing e-mail should go through the same mail server. Large organizations will want all outgoing e-mail to go through their mail servers to avoid being a source of inappropriate e-mail with fake source headers. Similarly, there should be an HTTP proxy server that these Windows boxes will use for browsing. The Web caching program Squid is recommended to reduce your Internet bandwidth requirements, as many employees get the latest news from Yahoo and check out Slashdot and Freshmeat. You might want to disallow Java in the browsers or filter it at the firewall.

You probably will allow outgoing FTP and, perhaps, outgoing telnet. Certainly, incoming FTP and telnet absolutely must be disallowed as must all other incoming services, including mail directly to the Windows systems. The safety of your organization's data requires this. Although some traveling employees will get onto the Internet through arrangements that they have made with ISPs they use for personal business, you probably will want to provide dial-in access. Certainly, Linux is an excellent platform for this.

Offering some 800 toll-free lines would be really nice too. This is likely to save the company money because 800 service is less expensive than the hotel long distance rates that otherwise would be borne by the organization. I found the Rocketport to be an utterly reliable multiport serial card and well supported under Linux. It claims that all lines will operate at maximum bit rates simultaneously and this was my experience. During the 18 months I worked with this Rocketport, it did not need so much as a reset.

As with all other products mentioned in this book, the author and publisher have received no fees nor other incentives to mention the Rocketport. The author merely has found the products mentioned to be of high quality and reliability.

You will want to have this dial-in system in the Demilitarized Zone to separate it both from your corporate network in case someone guesses an access password, and to separate it from the Internet for the same reason. (You do not want a cracker to use it to launch attacks on other Internet sites under your IP either.) See "Firewalls with IP Chains and DMZ" on page 514. You probably will want to offer only PPP connections to this system and have either it or the firewall only allow the few needed services to the PPP interfaces. These would be incoming mail and pops or imaps to your mail server, http and probably https to the Internet so employees can do research while on the road, and DNS. If these are the only services offered, the DNS server used should be the one allowed to outside (Internet) sites to hide your internal systems.

If your POP server is separate from your mail server^[1] that receives e-mail from the Internet and your dial-in box uses the external DNS server, you have two choices: Either that external DNS server will need to know about your POP server (which is not desirable even if firewall rules block Internet access to it), or you will need to hard-wire the entry for the POP server in the /etc/hosts entry in the dial-up box. The latter is the preferable approach.

^[1] In larger installations it would be a good idea to separate these. This would protect the flow of internal mail from DoS attacks from the Internet such as filling up disk with spam or the repeated sending of small messages that tie up port 25 to monopolize sendmail.

You might want to grant dial-in users SSH access to internal systems. The preferred solution in a high-security configuration is to have these systems individually listed in the /etc/hosts file on the dial-in box and in the firewall rules. Thus, even if the dial-in box is compromised, the intruder only has access to a few specific systems via SSH, which will be useless to her. Why all this worry about the dial-in box being compromised? Everyone whose laptop (and whose users' laptops) has the dial-in phone number, account name, and passwords for her PPP server in unencrypted form on the disk, please raise your hand.

Top