Section 8.3 Linux and UNIX Systems Within Your Control

   


8.3 Linux and UNIX Systems Within Your Control

graphics/threedangerlevel.gif

These can be made extremely secure by following the advice in this book. Although intended for Linux, most of this book's ideas are applicable to UNIX as well. The non-Linux specific security resources cover UNIX security problems too, and the major vendors seem to offer fixes quickly. Certainly, many of the same hardening issues that exist for Linux exist for UNIX as well, such as booting rogue floppies. Some UNIX systems may not allow disabling of booting from floppies as Linux does. This is because the vendor assumes that they will be kept in secure computer rooms. Thus, you would be obligated to do so.

Some UNIX vendors' systems are more secure than others "out of the box." Those that cater more to the business market tend to be more secure. All are capable of being made very secure. This usually involves changing file permission bits and sometimes disabling insecure set-UID programs. Again, the security lists and customer support are a boon here. Even Linux and UNIX systems need to be divided up into subsystems that you will maintain carefully, apply the many security enhancements suggested in the book, and upgrade with the latest security fixes in an ongoing matter. This applies to your other systems as well.

The others will be the desktop systems maintained by individual users, most of whom will not have security as a top priority. These systems will need your protection. Systems used by engineering usually fall into this category. Many of these, especially QA and "crash and burn" systems, should be isolated on a separate network that cannot be reached from the Internet or, for large organizations, from most of the organization's network.

Placing an intracompany firewall between this network and the corporate network is an excellent idea. The only people who normally would need to access these systems would be those engineers working on them so the firewall should only allow services (such as ftp and telnet or SSH) from those engineers' systems. ("Intracompany Firewalls to Contain Fires" on page 84 is recommended reading.) Most incoming services to them should be blocked by the firewall. This absolutely should include FTP, telnet, NFS, and portmap. There have been too many break-ins using these. Keeping a system upgraded and properly configured for these simply is not done by most users.

The only incoming services that the firewall should allow are SSH and possibly mail. It may be an ego boost for someone to give out e-mail addresses to her friends of her personal box. However, there have been plenty of vulnerabilities in sendmail in the past and there may be more. It is far better for the firewall to allow e-mail in from the Internet with a destination of the mail server and allow it to forward e-mail to the Linux and UNIX systems (and other systems) that speak SMTP. Even if the mail server is compromised, the intruder will only get e-mail not already pulled down by the POP clients. Many of these will poll every 5 to 30 minutes, so even this would only be a small vulnerability.

Certainly, outbound FTP, telnet, http and https, mail, SSH, and DNS from these Linux and UNIX desktop systems should be unrestricted.


       
    Top


    Real World Linux Security Prentice Hall Ptr Open Source Technology Series
    Real World Linux Security Prentice Hall Ptr Open Source Technology Series
    ISBN: N/A
    EAN: N/A
    Year: 2002
    Pages: 260

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net