[linux-l] Security (Firewalls, etc.)

Günther Frick gfrick at gmx.net
Do Jan 16 12:27:49 CET 2003



Oliver Bandel wrote:
> 
> Hi,
> 
> wenn man sein Wissen bezüglich Rechner-/Netz-Sicherheit
> verbessern will, z.B. Systemadministration unter
> Sicherheitsaspekten, Firewalls aufbauen, Attacken
> abwehren und so weiter, wo fängt man da am besten an?
> 
> Gibt's da bestimmte empfehlenswerte Anlaufstellen,
> Papers, FAQs, oder Bücher, die man da empfehlen
> kann? Vermutlich ja - und welche?
> 
> TIA,
>    Oliver


Im Anhang sind zwei Teile von einem Artikel aus dem Linuxjournal
über die sichere Installation von Linux.
-------------- nächster Teil --------------
 Securing Linux, Part 1
Elementary security for your Linux box
May 28, 1999

    Summary
    Are strange people accessing the data on your Linux box? Are they using your machine to attack others? Unless you have a good grasp of basic Linux security, they could well be doing this -- if not today, then in the near future. If you didn't already know that every one of the major Linux distributions does a poor job of ensuring security in its default installation, read this two-part series on Linux security. In this first installment, Michael H. Warfield gets you started with elementary Linux security. (5,500 words) 



By Michael H. Warfield
Page 1 of 6
Advertisement

I'll say at the outset that I feel that the title "Securing Linux" is somewhat misleading. It implies that one can somehow go through a series of steps and emerge at the end with a secure Linux system or network. That isn't true. The real intent of this two-part series is to help you improve the security of your system and to get you to think securely. One without the other is unlikely to succeed.

Security is a state of mind
Ultimately, security isn't something that is achieved as an end goal; it isn't a state. Rather, it's a way of setting up, maintaining, and running an operating system, network, or environment. Security is a process and a mind-set as well as a condition. It depends on the day-to-day actions of the system or network's users and system administrators. It also depends on the system security not being so intrusive that it encourages users and administrators alike to work around it.

But you have to start somewhere, and that somewhere is to improve the security of your system as much as possible while still meeting your operational needs. A system that isn't connected to any network or phone lines and is kept in a locked room is reasonably secure -- but it will meet few of your needs. From there we embark on a series of compromises between the best possible security and the least inconvenience and difficulty that will serve our purposes.

Some of these tips are specific to Linux systems, but many are very general principles that apply to all systems and networks -- not just to Unix (or Unix-like) OSs.

Less is more
Applying the Principle of least privilege and the Principle of minimum access ensures that you open up your system to the least amount of risk. Users are allowed only enough privilege and access to do their work, and no more.

Principle of least privilege
Users, applications, and even systems should be granted the least amount of privilege required to accomplish their respective tasks. This approach reduces the opportunity for accidental compromise of the system. Ideally, security should not be a burden on your users. It should not get in the way of their ability to accomplish their tasks. Unfortunately, this isn't always the case. You must strike the right balance in terms of who is allowed to do what, and when.

Principle of minimum access

"That which is not explicitly permitted is denied."

This is one of the basic mantras of firewall design. It applies equally well to security in general. In a secure system, you grant access by intent and deny everything else by default. Permission takes place by will or by action. This is a simple fail-safe principle. If you "fail" to take action, you end up failing into a "safe" state (access denied).

Set up your basic security mechanisms to deny everything unless you explicitly configure it to be allowed. Set the /etc/hosts.allow file to allow localhost only, and set the /etc/hosts.deny file to deny everything else. With that as a starting point, you can decide who and what will be granted which access, and everything else will be blocked. The default should always be "No!"

Do the same thing with your firewall rules, whether you're using a standalone box or a networked system. Firewall code is a useful feature, even if you aren't routing traffic between systems. The Linux kernel has firewall code built in. It just needs to be enabled and configured -- which is well worth the effort. 

 Planning
Plan ahead and plan to distribute services. Even before you begin an installation (and, ideally, before you purchase system software solutions), make a detailed plan of your intended security defenses. On paper.

Some basic steps along the road
Before you decide how to secure your systems, you must first decide how you intend for them to be used. Decide what services each box will use on the network and what services each box you administer will offer to the network. This helps form a security policy. That policy or plan can be simple for simple systems, or it can be a large book for large sites and networks. In either case, it helps to decide what you want to do before you do it. The creation of this policy is also the most frequently overlooked step in developing a secure system.

Network layout and design considerations
If your site or networks permit it, compartmentalize functions. While this may be impractical for the home user with a single box, one should put different functions on different systems whenever possible. Your DNS, FTP, Web, mail, and firewall should not all be on the same system. If they are, and one service is compromised, they all will be compromised. Placing functions on separate systems limits the damage potential of a successful attack.

If you have a limited number of systems and must therefore combine functionality, your security issues are more complicated. You will have to depend on your authentication and authorization systems to provide the isolation that could have been provided by separate boxes.

Installation
A secure system starts with a secure install.

This is one area where the various Linux distributions fail to do an adequate job. All of the distributions are guilty of making it too easy to set up insecure or misconfigured installations. Many of them enable services that the new user is unlikely to be aware of, or enable services before they are fully configured.

Some vendors and consultants are now complaining that Linux is much too easy to install, because it allows users to unknowingly install poorly configured servers and shoot themselves in the foot. They are correct.

Security starts with the installation
Until the Linux distribution vendors wise up and start out with a secure configuration, it's up to the user to turn a basic installation into one with a reasonable shot at being secure.

When you're installing your system, never install software unless you intend to use it! Resist the temptation to "just install everything." Some of the things you so casually install could come back to haunt you during a system attack.

If your distribution permits it -- and not all do -- hold off on enabling services until you're familiar with them and have configured them. Some distributions assume that if you're installing a service, it should be enabled. If you aren't sure, don't install it!

Secure services
Internet and network services are among the most vulnerable parts of your system. Whether you're planning a new installation or reviewing security on an existing system, your file servers, e-mail services, Web servers, FTP, and other network services should be among the first things you check for security holes.

Some services will obey the /etc/hosts.accept and /etc/hosts.deny configurations if they've been compiled with the TCP Wrapper library, but not all will. Use the firewall code along with the TCP Wrapper configurations to secure your services.

Secure file serving
If you're exporting any filesystems via NFS, SMB, Samba, or anything else, make sure your access permissions are carefully checked.

Never run NFS, SMB, or NIS over the Internet. The risk is just too great. (NIS is jokingly referred to as "network intruder service" and some have referred to NFS as "no file security.") NFS in particular uses UDP and depends on peer addresses for authentication and authorization. But peer addresses are trivial to spoof for UDP!

E-mail security
If you're running POP or IMAP for remote downloading of e-mail, switch to an SSL-encrypted version. You can use stunnel or edssl to set up SSL-enabled mail servers. Several e-mail clients support SSL POP and/or SSL IMAP, including Netscape and Microsoft Outlook. SSL-enabled fetchmail is available from the North American Cryptographic Archives.

If you aren't intending to run POP or IMAP, make sure you really aren't running them. Some distributions enable these by default. Some of the "bad guys" out on the Net are now engaged in massive parallel-port scanning for IMAP servers. If you leave the backdoor open for one of them to get your number, the next time a major root compromise is discovered in IMAP (for example) he or she could promptly come knocking. If you don't know you're running IMAP, you'll have no reason to know when security patches or updates to it become available. Without these upgrades, an intruder could be root on your system before you know what hit you.

Secure Web services
If you're running a Web server, check and recheck your CGI scripts. Do not allow other users to install arbitrary CGI scripts. Do not use unrestricted server-side includes (SSIs).

IRC is one common example of a chat system -- many other chat systems also work with Web servers. If you have any kind of chat server running on your system, make sure common users can't insert arbitrary HTML (hostile JavaScript anyone?) into pages where your Web server can serve them up.

Securing FTP
If you're operating an anonymous FTP service, watch your permissions closely! Don't allow any directories to be both readable and writable by anonymous users. If you want to permit anonymous uploads to your system, provide a write-only directory and prohibit directory creation underneath it. If you permit a location to be both readable and writable, you not only allow your system to be a "warez" (pirateware) repository, but you also open up your system to being used for "FTP bounce" attacks against other systems.

If you're not running anonymous FTP -- make sure you're not. A lot of distributions enable anonymous FTP by default.

Disable telnet and finger
If you're running telnet, rlogin, or rsh to access your system remotely -- Why?!?!? These are seriously insecure and allow passwords and userids to be "sniffed."

For remote access, use secure shell (ssh) connections and disable all nonencrypted remote access to the server. The ssh package can be downloaded and installed very easily. ssh isn't available on any Linux distribution originating in the United States due to US export restrictions on cryptography. Some distributions from outside of the US do include cryptography modules and applications such as ssh and PGP in the base distributions and installations.

finger is often configured and available on default installations. Unless you have a specific need for this service, disable it or restrict network access to it. finger provides far too much information about your users to would-be intruders. It is also instrumental in certain advanced forms of denial-of-service attacks such as "nisnuke" on large networks. 

 Up and running
Once your system is set up, be sure to keep track of the services you're running. Keep a close eye on services and applications by monitoring your UDP and TCP ports.

Tracking down services
Go through your system and make sure you're not running any services you don't intend to run, haven't configured, aren't using, or don't understand. I helped a Web site clean out an intruder who broke in using innd, even though the site wasn't running a news system. Installing services that users don't need or understand is a major strike against every Linux distribution -- and most other OSs -- out there.

If you run it, they will come
Examine /etc/inetd.conf and disable any service you don't want to be running or don't understand. If you do this simply by commenting out the services you don't want, you can easily reenable a service at a later date. But very few of us need echo, chargen, or discard. If you don't need a service, don't use it. And if you don't know what it is, don't run it until you find out. With a typical workstation configuration, it may be possible to turn off all services. For instance, if your machine isn't running any inetd services, you don't need to run the inetd at all.

Find out who's listening to what
Run nstat -a and look for any unusual ports or services. If you see a TCP port in the state of LISTEN and you can't identify the local port or service, track it down and decide if it's something you really want to be running.

Do the same for any UDP ports you find.

If it isn't something you specifically want, shut it down. If it's something you want locally but don't want outsiders to access, use the Linux firewall code to block outside access to it.

If you have trouble determining what application is listening on a TCP port or opening a UDP port, use the lsof package to track it down.

Keep up with the times
Keep all software and distributions current with any updates released by the distributor. If the distributor doesn't have a mechanism in place for announcing updates or alerts, consider finding a different distributor. Install updates as soon as they become available. Far too many systems have been broken into because of out-of-date imapd servers, even when updates had been available for months.

Password and authentication security
Passwords can be the most underestimated security feature you have. Make sure that neither you nor your users are using transparent (easily guessed) passwords, and make sure that your passwords are safe from unauthorized intruders.

Good passwords
It is frankly stupefying to discover how lax some administrators are about secure passwords. Passwords should be at least five characters long, should mix letters with numbers or other atypical characters, and should be changed several times a year, at the least. Your users should know that password sharing isn't allowed, and former users should be deleted from systems after a reasonable amount of time has passed (i.e., former users should be allowed time to alert all correspondents of their new e-mail address). Ex-user accounts can usually be password-disabled immediately upon the employee's departure. Be aware that more attacks come from disgruntled employees than from any other source. If users are in the habit of sharing passwords, a disgruntled attacker could have access to your system even if you have disabled his or her account.

Proceed with caution before implementing this next bit of advice:

To ensure that you're not using transparent passwords, you can run the program crack on your own password system. Running crack on your personal system or any system on which you're the administrator is fine. But do not run this program on a system for which you do not have administrative privileges without the consent of the system's management!

Warning! Some companies and ISPs take offense at users having "cracker tools" such as crack, or any of a variety of sniffing and scanning tools (described in the section called "Eternal Vigilance") on their systems. If you aren't an administrator on a system, make sure you have permission to possess these items and that the administrator is aware of them. Some people consider the possession of lockpicks to be no different than the possession of burglar tools. If you have tools for cracking passwords or breaking into systems, you may be setting yourself up to answer some very intense questions. Some ISPs don't even ask questions first. Providers have been known to cancel accounts merely for the possession of cracking tools. Don't take the chance. Don't even download these tools if you don't have your administrator's permission!

Password handling
Not only should you never share passwords or give your passwords out to anyone, you should never leave passwords written down where they can be read. Intruders known as dumpster divers periodically go through the trash looking for scraps of paper with passwords on them. Destroy all security information before discarding.

Additional password security
If you aren't running a distribution that supports PAM (Pluggable Authentication Modules), then get one. PAM makes it relatively simple to enable advanced password checking, encryption, and longer passwords. When you have it, enable it and use it.

If you aren't in a network requiring single sign-on authentication (NIS, NIS+, Kerberos, etc.), enable shadow passwords and MD5 (Message Digest algorithm) hashing. This enables long passwords and makes them much tougher to crack with brute force, and much tougher to steal if you aren't the superuser. 

 Security and the privileged user
LIST_SUMMARY:

Never perform routine operations as root! Do your routine work as a nonprivileged user and step up to root only when needed. This is a common mistake of most newbies to Linux (and Unix in general). When you (or a user or a program) must run as root, take the proper security precautions.

Don't run as root
A couple of years ago we had a Linux "virus" running around. Actually, while some were sure "Bliss" was a virus, others thought it was merely a worm or a trojan. In hindsight, it's probably safe to say that it was something of a hybrid -- mixing a little bit of each. But the important thing is that it only propagated because people were running as root, allowing it to modify system binaries. This is very bad practice. This rule can't possibly be understated! If you routinely run as the root user, you might as well be running DOS -- you have just about that much security!

By not running routinely as root, you also reduce the likelihood of "accidents." My son discovered that, if he was running as root, any changes he saved to his desktop were saved to the systemwide configurations. He found out what a bad idea this can be when he got part of the configuration wrong and was then unable to get any account to work right! This kind of accident could lead to unforeseen side-effects and security compromises.

Never use a browser or chat program when running as root! While the chance of a hostile applet --- written in Java, ActiveX, or some other language -- is remote, it isn't worth the risk. The destructive capability of such applets is magnified manyfold if you're running as root.

What you can do with sudo
The program sudo is a useful tool to allow trusted users to perform certain functions as though they were root -- while at the same time limiting their ability to really function as the superuser. It also provides convenient access to those utilities that require root permission to run. By using sudo you avoid the overuse of suid.

As with any security tool, sudo should be used with caution. While running a command under sudo, the user's permissions are elevated to root. This makes any potential bugs or security holes in the command or program you're running under sudo more serious than they would be if you were running them as a normal user. For instance, a shell escape out of a sudo-run command is a potential root backdoor.

Even some programs that expect to be run only as root can become a security hole under sudo. If the program assumes that only root can run it, and if that program then permits the execution of external commands, there is the potential for the user calling sudo to execute arbitrary commands as root. For this reason, sudo should only be used by trusted users, and with great caution.

Beware of software bearing trojans
Watch out for trojans! There is a reason why root shouldn't normally have single dots (.) anywhere in his or her path. This helps avoid the danger of having a trojan program like ls sitting in a directory waiting for the superuser to come looking to see what's there. Some distributions still allow single dots in the superuser path. Some distributions have different paths for when you log in as root and when you su to superuser. If a single dot is in the path for either root login or for su to superuser, it should be removed. While its removal isn't a foolproof preventative against trojans, it does help reduce that danger.

Trojans are also a serious concern for normal users when it comes to any application that prompts for a password, such as su (since ordinary users can su to any other username to which they have access). Programs that prompt for a password should only be executed as an absolute path to the binary. One way to encourage this is to insert alias su /bin/su into the files /etc/profile and /etc/bashrc so that bash users will automatically use the absolute path.

Use the groups, Luke
Often, jobs that need root access could be done just as well and more securely through the proper use of group ownerships and secondary group membership. It takes more time to set this up properly, but once it's done right, it more effectively protects system security while granting the access required by normal users.

It's very easy and convenient when there are only one or two users on a system to simply perform all maintenance tasks by stepping up to root. But once you have a lot of users and wish to delegate the authority for various tasks to different users, it becomes impractical and dangerous to allow superuser access to everyone performing maintenance. It's well worth the effort to implement an effective group membership configuration when the system is simple, before you really need it -- or before it's too late. 

 Cryptography and security
Cryptography is a good thing. It can protect our files, our e-mail, and our communications. Widespread use of cryptography will improve and change the security landscape. Take advantage of cryptography wherever its use is appropriate.

With any cryptographic system, the key is the key. The security of your cryptography depends on the security of your key. That can be a private key stored on a system, or a password, or a smart card key. If you decide on a crypto system to guard your security, your problems aren't solved, they've merely changed. Now, instead of guarding your front door, you must guard the keys to the lock on the door.

Encrypted communications
SSL began its career securing Web servers for e-commerce, and has since been applied to FTP and telnet, as well as to POP and IMAP e-mail services. In addition to simple remote shells and secure copying, ssh is capable of forwarding many services and even tunneling PPP to provide a form of VPN service. Several remote services, such as cvs, rsync, and rdist, can take advantage of ssh to secure their underlying communications.

If you want to protect your e-mail, your open source choices are PGP and S/MIME (there are, additionally, several proprietary schemes). Both PGP and S/MIME have advantages and disadvantages, and both have interoperability problems and usability problems. When was the last time you checked the validity of a PGP signature? The "web of trust" model of PGP distributes well, but transitive trust (I trust Sue and Sue trusts Adam but do I trust Adam?) doesn't scale well. The "authority" model of S/MIME has its own scaling problems. Additionally, S/MIME has an annoying infrastructure (and some would say, tax) associated with it.

Encrypted files
If you want to protect the files on your system, there are several cryptographic filesystems available for Linux, including Matt Blaze's CFS (Crytographic File System). These help secure your files. But on a multiuser system, you still must watch out for trojan password traps and sniffers. Your filesystem encryption is only as secure as the passwords you use to access it.

FreeS/WAN
The FreeS/WAN project is developing IPSec for Linux. This is now available for both 2.0 kernels and 2.2 kernels, and it interoperates with many other IPSec implementations. For encrypting VPNs and private connections, this is the way to go. To connect gateways between two or more widely dispersed networks, this is the tool to use. Running host to host, however, it is very cumbersome and it will not operate over IP masquerading firewalls or gateways. Further, it isn't trivial to install, and you must guard your keys religiously.

Don't be lulled into a false sense of (encrypted) security
The tools mentioned here enhance the security of communications, but may or may not improve overall system security. If someone cracks a password by brute force, they're just as free to use the secure channels of access as are authorized users. A recently well-publicized break-in at RootShell was done through ssh. The problem wasn't a vulnerability of ssh -- the attackers had obtained the root password through other means and had simply connected in as if they belonged there.

For these reasons, even IPSec isn't the end-all, be-all of security on the Internet. It may eliminate spoofing or certain types of passive sniffing attacks, but it won't stop brute force attacks or protocol attacks. Your e-mail may not be sniffable any longer, but it can still be read if someone compromises and gains access to your system. Your credit card number won't necessarily be sniffed while it's traveling along the wire on its way to an insecure Web server -- but most credit card theft is the result of intruder access to the insecure server itself, not sniffing. 

 Eternal vigilance
Once you've secured your installation and checked your basic security and services, your work isn't over. In fact, the job of keeping your system secure is never over. Even if with eternal vigilance, someone, sometime, is likely to get in. With or without the help of any one of a number of monitoring programs, you must keep a watchful eye on what is going on in your system.

If you can't block 'em, catch 'em!
Enable the firewalling code, even on single systems, and block everything that you don't understand or specifically want on your system. This can put a serious crimp in some rootkit backdoors.

Watch out for unusual suid programs. find can be used to locate all of the suid binaries, which can then be tracked for changes or additions.

Scan that system!
Run a network security scanner on your system! SATAN is one such scanner. Nessus is an excellent open source scanner, as is Trinux. Trinux is a tiny distribution that can boot from floppy disks and scan your network. Internet Security Systems also produces a commercial security scanner. Internet Scanner is free to download and run against your local host. Even if you don't intend to purchase Internet Scanner, or can't afford it (it can be a bit expensive), I would encourage you to get the local host evaluation copy and run it on your system (it's fully functional).

Burglar alarms
Install an intrusion-detection system. These vary greatly from package to package, and there are commercial and open source versions of most types. Some are host-based systems, monitoring for unauthorized changes to files; others monitor the network or network interfaces for suspicious activities.

Check out Tripwire. Tripwire can alert you to modified binaries and permissions. There are commercial variations of this application, including a commercially marketed and supported version of Tripwire itself. Some of the other systems are more extensive than Tripwire, some are not.

There are log-monitoring packages available from several of the security sites listed in the Resources section at the end of this article. Log monitors trigger on suspicious activity, such as repeated failed login attempts in security logs. The application can send e-mail to the system administrator or even activate a pager to inform the administrator of an attack in progress. Some are capable of performing even more drastic action, as we'll see in Part 2 of this series.

Stay informed
New security holes and bugs are discovered and exploited constantly, and new techniques, patches, and fixes are created to counter the threat they present. The only way to safeguard the system you've worked so hard to secure is to stay on top of new information as it becomes available.

Stay on top of software updates
Subscribe to the mailing lists provided by the Linux distribution vendors to provide announcements of updates or alerts. Monitor the vendor Web sites for errata and updates.

Know thine enemy
Browse through the various "white hat hacker" sites and get a feel for some of the recent danger points. RootShell and L0pht (both listed in the Resources section) are good places to start. There are also some Linux security sites out there.

Warning! Some companies and ISPs take offense at users having "cracker tools" such as crack, or any of a variety of sniffing and scanning tools (available from the various white hat hacker sites, among others) on their systems. These tools can be useful if you run them against your own system to find security holes before a potential intruder does. But f you aren't an administrator on a system, make sure you have permission to possess these items and that the administrator is aware of them. Some people consider the possession of lockpicks to be no different than the possession of burglar tools. If you have tools for cracking passwords or breaking into systems, you may be setting yourself up to answer some very intense questions. Some ISPs don't even ask questions first. Providers have been known to cancel accounts merely for the possession of cracking tools. Don't take the chance. Don't even download these tools if you don't have your administrator's permission!

Additional resources: Where they are, what they're for
Poke around the public databases. Internet Security Systems (where I work) has several, and we also link to outside sites.

Get on some security mailing lists, such as Linux-security or BugTraq.

You can find the addresses and subscription information -- and recommended sites for further reading -- in the Resources section.

The enemy within is ignorance
While advanced security can be difficult to implement, a great deal can be achieved by taking the simple steps of knowing what you're running and disabling services you aren't sure about. Even small sites and single Linux systems can take steps to reduce the risk and harden their security protection.

Not all of these ideas are ideal for all circumstances. You have to understand and balance your security needs, your network design, your functionality needs, and your security policy (if you have one). In any case, knowledge is your best security tool and ignorance is your worst enemy. Use our comprehensive list of Resources for even more information, and to stay abreast of developments. 

About the author
Mike Warfield is a senior security researcher on the Internet Security Systems X-Force. He is also a member of the Samba Development Team, a founding member of the Atlanta Linux Enthusiasts, and a long-standing guru with the Atlanta Unix Users Group. He has been involved in Unix systems for over 15 years and with computer security for over 25 years.

# Resources
Read Michael Warfield's previous On the Ramparts columns in the LinuxWorld archives:
http://linuxworld.com/linuxworld/archive/columnsbydate.html#ramparts
Further reading and security resources
(Most of the sites listed below feature additional security resources and links.)

    * North American Cryptographic Archives:
      http://www.cryptography.org/
    * Trinux:
      http://www.trinux.org/
    * Nessus:
      http://www.nessus.org/
    * Psionic Software / Abacus Sentry:
      http://www.psionic.com/
    * RootShell:
      http://www.rootshell.com/
    * L0pht Heavy Industries:
      http://www.l0pht.com/
    * Deception Toolkit:
      http://all.net/dtk/dtk.html
    * "Securing Your Linux Box," Peter Vertes (Linux Gazette, Issue 34, November 1998):
      http://www.linuxgazette.com/issue34/vertes.html
      Wietse Venema's collected tools and papers: ftp://ftp.porcupine.org/pub/security/index.html
    * Solar Designer's Secure-Linux Patch:
      http://freshmeat.net/appindex/1998/06/14/897822718.html
    * StackGuard:
      http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
    * Internet Security Systems:
      http://www.iss.net/
    * CERT Security Improvement modules:
      http://www.cert.org/security-improvement/
    * CIAC (Computer Incident Advisory Capability):
      http://ciac.llnl.gov/ciac/
      BugTraq: bugtraq at securityfocus.com Linux-Security: linux-security at redhat.com Linux Administrator's Security Guide (LASG): https://www.seifried.org/lasg/ 


Copyright Š 1998-2002 LinuxWorld.com, an IDG Communications company.

-------------- nächster Teil --------------
 Securing Linux, Part 2
Advanced Linux security
Jul 6, 1999

    Summary
    Michael H. Warfield instills in his readers that healthy sense of paranoia which is so necessary for anyone involved in advanced systems security. Read this second half of his two-part series on Linux security, and Warfield will have you checking system integrity against CD-ROM snapshots, nervously checking stacks for buffer overflows, and systematically checking the secure-distros mailing list (and other information sources) during all of your waking hours. (4,700 words) 



By Michael H. Warfield
Page 1 of 5
Advertisement

These advanced tips are mostly for larger systems or networks which have more resources, or which are a more valuable target, or which are run by more experienced system administrators who are available to implement and maintain the installation. They should be implemented in conjunction with the security precautions discussed in Part 1 of this series, "Elementary Linux Security."

Filesystem defenses
Turn your filesystem into a staunch ally by mounting major partitions separately, and by making critical partitions read only. Take advantage of native Linux defenses, like the append-only and immutable attributes for the ext2 filesystem.

Filesystem partitions
There is a reason for the filesystem standard, and it is well worth your while to invest time in taking full advantage of it. The filesystem can be divided into major partitions, and each partition can be configured and mounted differently. I strongly recommend separate /, /usr, /usr/local, /var, and /home partitions, at the very least.

/usr can be mounted read only and can be considered inviolate for purposes of validation. If anything ever changes in /usr, that change should ring an alarm bell -- literally. Of course, if you change something in /usr yourself, you will know that the change is coming.

The same idea applies to /lib, /boot, and /sbin. If you can make them read-only and alarm any attempts to change files, directories, or permissions, then do it.

It isn't possible to mount all of your major partitions as read only. For example, /var, by its very nature, cannot be read only, and for that reason nothing should be allowed to execute out of it. Things like configuration files for X servers should be symbolically linked to files which are kept in places which can be made read only -- and not through variable storage dumps.

Extending ext2
Use of the append-only and immutable attributes on the ext2 file system can provide enhancements to a secure installation. While not perfect in and of themselves, these attributes can be useful in detecting intrusion attempts when an attacker attempts to install rootkits or other backdoors over existing files. To be sure, such measures can be thwarted once they are detected. But by then, you should already have been notified and made aware of the intrusion.

If you have critical filesystems mounted read only and the files are marked as immutable, an intruder must remount the filesystems and remove the immutable bits -- all without getting caught or triggering an alarm. This is no small feat, and an intruder who recognizes this is more likely to go off in search of more vulnerable prey than risk being caught.

The immutable and append-only attributes are just two of the extended attribute flags on the ext2 filesystems. A file which is flagged as immutable cannot be changed, not even by root. A file flagged as append only can be changed, but it can only have material appended to it. Even the root user cannot modify it in any other way.

These attributes are added to a file by the chattr command, and can be listed with the list attribute or lsattr command. For more information on enhanced file protection through ext2 permissions attributes, see man chattr.

While partitions and ext2 attributes seem simple enough on the surface, they are actually bits of arcana -- and little effort or progress has been made in making them user-friendly. Even sophisticated users and administrators have been known to get tripped up on them, and so you should not treat them trivially.

Secure log files
The immutable and append-only attributes are particularly effective when used in combination with log files and log backups. You should set active log files to append only. When the logs are rotated, the backup log file created by the rotation should be set to immutable, while the new active log file becomes append only. This usually requires some manipulation of your log rotation scripts.

 Using backups to validate system security
By making a snapshot of your system upon completion of a successful installation, you can validate system integrity against this backup to see if files have been tampered with. You can also use the backup to return your system to its secure state if it has been compromised.

CD-ROM snapshots
Once you have a secure system, cut a snapshot of it to a CD-ROM. Then, periodically, you can validate system integrity against that CD-ROM. In a case where security is a very high priority, such as a firewall system, you can make the CD-ROM bootable and do the validation as part of the bootup. By booting off the CD-ROM, you can be pretty sure that the media has not been tampered with prior to validation.

If you have created read-only partitions, these can be reloaded periodically from the CD-ROM image (after all, they are not supposed to change). Even if areas like /boot, /lib, and /sbin cannot be mounted read-only (because of /etc), you can still check those areas against the CD-ROM image, or even reload them at boot time from another safe image.

Other backup
While many files in /etc are subject to frequent change, some areas in /etc can still be cut to a CD-ROM and verified. Other files, which are subject to infrequent changes, may be backed up to another system -- they may, for instance, be sent to tape, or be tarred and placed in a read-only directory -- for a second level of validation after critical utilities are validated against the CD-ROM image.

Since most systems now come with a CD-ROM drive, CD-ROM emergency bootdisks or validation disks are practical for any site which is equipped with a CD-ROM burner to create them. The price of CD-ROM blanks is dropping to below the cost of floppies, making this a cheap and effective validation method which is tough for intruders to defeat.

Internal system security enhancements
Several things can be done to enhance the operating system's internal functions and protect against buffer overflow attacks, access control violations, or poorly-coded applications. Some of these enhancements carry a heavy performance, maintenance, and/or learning-curve tax. But for many systems, it's a necessity.

Solar Designer's secure Linux patches
Solar Designer's secure Linux patches for the 2.0 kernels provide a nonexecutable stack to reduce the threat from buffer overflows, as well as patches to deal with some /tmp race conditions.

It is true that buffer overflow conditions are extremely difficult to exploit, because the intruder must identify the presence of a potential buffer overrun as well as its location in memory. But it is also true that your system can never be too secure. These advanced internal safeguards would not exist if it were impossible to abuse buffer overflow conditions.

Despite this, some people -- including Linus Torvalds -- consider the secure Linux patches to be "security through obscurity" and not worth the trouble they can cause. Since they eliminate an entire category of attacks and force the attacker to use other techniques, I disagree with this argument.

But you should be aware that these patches can cause problems with certain programs and libraries which depend on an executable stack. That's why they are an advanced topic, only for those administrators experienced enough to deal with the potential difficulties that come with this kind of patch.

The nonexecutable stack patches have been nominated for the secure distribution wish list now under discussion on several security mailing lists, like the secure-distros list mentioned later in this article. You'll find links for this list -- and the other resources -- listed in the Resources section at the end of this article.

StackGuard
For the really ambitious types, with big powerful boxes, there is StackGuard. You can recompile and relink critical applications with a version of gcc which has been patched with StackGuard.

Compiling with StackGuard adds stack checking in order to prevent stack smashing buffer overflows, but it comes with a performance penalty that most of us would not want to pay on a normal box. For high-security systems in special purpose applications, however, StackGuard is a valuable asset for those with the time to invest.

There are some Linux distributions available that are already StackGuarded. This makes it easier to install a system with StackGuard, but you will still have as much as a 10 to 20 percent performance impact. This solution is also not perfect, but it eliminates an entire subclass of buffer overflow attacks.

Access control lists
The 2.3 kernels are looking toward the implementation of access control lists in the filesystems. These will provide finer-grained control of access permission beyond the old three-category (owner, group, and other) system currently in place.

Capabilities
Still under development in the 2.2 and 2.3 Linux kernels are the introduction of capabilities, which will eventually affect some of the things about the ext2 file attributes which we discussed in Tip 1. Capabilities provide a more precise control over security than the conventional filesystem permissions model with the ext2 extensions and secure level. With this new feature, applications will be granted capabilities to access certain system resources, such as raw sockets, without needing to run as superuser. The secure level functionality of the 2.0 kernels will be implemented as a function of the capabilities set in the 2.2 kernels and beyond.

Rule set based access control
The RSBAC (rule-set based access control) project has a stated goal of meeting the requirement of a B1 security rating for the Linux operating system. RSBAC is based on the generalized framework for access control and extends many of the system calls with security enforcement code. It includes support for a number of different access and authentication methods. This is an area of great promise for extending and hardening the internal and local security of Linux systems.

 Honey pots and traps
Traps are any software designed to trigger an alarm when activated, while the term honey pots refers to deceptively tempting traps which are designed to lure snooping intruders into deliberate alarms.

Your honey pot says 'Yes, yes!' but your system says 'Danger, Will Robinson!'
With simple traps and alarms, normal system activity is armed to trigger an alarm in the event of an intrusion. In large or highly critical networks, entire systems may be dedicated to being a honey pot. This honey pot is deliberately vulnerable and easy to break into -- but immediately triggers an alarm in the event of any activity.

Intruders check in but they don't check out
One way to set up a honey pot would be to configure a system with an IMAP server designed to falsly claim to be one of several vulnerable versions. Intruders performing bulk port scans for IMAP servers would then attempt to break into the honey pot system and trigger an alarm.

Another example of a honey pot trap is based on an old, vulnerable Web cgi-bin script called phf. The original script was designed to look up phone numbers. Unfortunately, it had a security hole which would allow an intruder to use it to retrieve your password file or commit other heinous acts on your system. The fake phf, or honey pot version, acts just like the vulnerable script. But instead of mailing the intruder your password file, it sends out some fake information while at the same time sending an alarm to the system's administrator.

Reactive honey pot
Some honey pots can be set up to immediately deny access to the intruder by shutting down firewalls that block access from the intruder's address. Such access can be denied for a short period of time, or may be cut off permanently. The firewall code in the Linux kernel is well suited to this. If not implemented correctly, however, this can be turned against the user by spoofing legitimate addresses and blocking valid sites. This turns a honey pot into a self-destructive denial of service attack.

The Deception Toolkit (see Resources) provides a variety of tools to set up fake servers, fake vulnerable services, and traps for intruders to fall into when snooping through your system.

Reaction systems and dynamic firewalls
Reaction systems can be as simple as stateful inspection packet filters or as sophisticated as intrusion detection systems and configurable firewalls and alarms.

Abacus Port Sentry
Abacus Port Sentry (aka Abacus Sentry) is an open source package that monitors the network interface and interacts with the firewall code to shut off an attack during an attempted port scan. This is a powerful tool, and it needs to be used with caution.

In the face of an ongoing port scan, Abacus Sentry can rapidly block an intruder before the intruder can get very far. But if it is not configured properly, it can enable a hostile outsider to mount a denial of service attack against your systems.

Enhancing a firewall with Abacus Sentry
While it was not specifically designed with this use in mind, Abacus Port Sentry can be combined with the transparent proxy facilities in Linux to provide a very effective reactive firewall against intruders.

The firewall is set up normally, with or without stateful packet filtering. The last set of rules, or rule chains, redirect unused ports for common services on all IP addresses to the Port Sentry. This gives the Port Sentry a depth of coverage unavailable otherwise, and scans of a single port across multiple addresses can then be detected and cancelled before the intruder progresses deeper into your network.

Abacus Port Sentry will detect slow scans, but it will not detect structured attacks. Both proccesses seek to obscure probe attacks. An attacker does this with a slow scan by spreading out the test over a long period of time. In a structured attack, the attacker tries to make the probe attempts more obscure by scanning or probing from multiple source addresses.

Using this software properly will effectively neutralize massive parallel scans for IMAP services and block all access to such intruders. This use of Abacus Sentry is most effective in combination with the Linux 2.2 kernel's IPChains facility -- which allows a separate redirection chain to feed port scans to Port Sentry -- and a preceding blocking chain which allows Port Sentry to block intruders prior to any other rules.

The Linux 2.0 kernels can be patched to use IPChains, even though the facility is not packaged with this version. Abacus Port Sentry can also work with the earlier ipfwadm facility which is in the 2.0 kernels, and which was replaced by IPChains in version 2.2.

Abacus Port Sentry can be configured to react to UDP scans and, on Linux systems, to various half scans, such as half-open and FIN scans, which try to avoid detection by sending only initial or final packets instead of establishing an actual connection.

Avoiding denial of service attacks
There is a small risk in these configurations, in that they can be spoofed -- and could thereby be exploited for denial of service attacks. While such attacks are extremely difficult to execute, Port Sentry does not have convenient facilities for reenabling blocked addresses. Simple TCP port scanning detection is sufficient in most cases -- particularly in the firewall/transparent proxy configuration.

Some intrusion detection systems, such as Internet Security System's Real Secure, can reconfigure firewalls based on intrusion alarms and attack signatures. Many of these can provide highly sophisticated reaction profiles, but they also need to be configured with care to prevent the abuse of such systems, by knowledgeable attackers, to perpetrate denial of service attacks.

Other types of attacks
You can avoid being the victim of many other types of attacks by following the basic security precautions I laid out in Securing Linux, Part 1 -- specifically, by never enabling services you don't really need or use.

 Counterattacks
While reaction systems counter intrusions by blocking or cancelling the attempts, counterattack systems launch return port scans or other aggressive attacks against the intruding system.

An equal and opposite overreaction
Some security systems, such as Abacus Sentry, include counterattack capability. While it is tempting to think about striking back at an intruder, these systems can cause a great deal of trouble. Some of these counterattack measures can be turned against their owners or be used by attackers to attack others in turn. By configuring these systems to counterattack in the face of a UDP or FIN scan (which can be spoofed), you may actually set yourself up to be used to attack other systems.

One site on a network erected a counterattacker that was triggered by any attempt to telnet to the system. In response to a telnet connection, this system would e-mail a nasty message to the system administrator of the originating system, as well as to the domain and network administrators. Someone then discovered what great fun it would be to include a telnet:// URL in a couple of Web pages and in some HTML-enabled e-mail. The resulting flood of complaints and nasty messages showed just how bad a mistake a poorly thought-out counterattack can be.

My personal advice on counterattack systems is: don't do it! It's not worth it if someone subverts your system to attack someone else -- and you get the blame!

System logs and logging servers
Moving your logging server to a separate, isolated machine adds another level of security to your system; replacing the logging utility with one of its secure counterparts makes for an even better solution.

Secure logging
Use a separate logging server for syslog services. This could be a spare box with sufficient disk space for all of your logging needs. There should be no other services running on this system. This will severely limit an intruder's ability to penetrate the logging system and tamper with the logs. Periodically writing the logs to a write-once media, for those who have such devices, is also useful to thwart attempts to tamper with logs.

Secure syslog
Even with separate log servers, the stock syslog utility is rather insecure. While it is true that prevention is the first line of defense, detection is always the second.

Bruce Schneier has presented ideas for creating a secure log server in which cryptographic signatures would be incorporated into the logs. This would ensure that intrusions cannot go undetected, even if the logs are tampered with.

A secure log server replacement for syslog, called ssyslong, is available from the Core SDI site (see Resources). This daemon implements cryptographic security on the logs and enables remote auditing.

>From the Core SDI page on Secure Syslog:

BLOCKQUOTE: Designed to replace the syslog daemon, ssyslog implements a cryptographic protocol called PEO-1 that allows the remote auditing of system logs. Auditing remains possible even if an intruder gains superuser privileges in the system, [as] the protocol guarantees that the information logged before and during the intrusion process cannot be modified without the auditor (on a remote, trusted host) noticing. :END_BLOCKQUOTE

syslog-ng
Another secure alternative to syslog is syslog-ng, the "next generation syslog," available from BalaBit.

This is a more configurable logging daemon, and it includes cryptographic signatures to detect log tampering. It also allows for directing log traffic based on facility and level, as well as on content and use of regular expressions.

Remote logging servers, in combination with cryptographically secure logging servers and secure remote audit capability, can make log tampering extremely difficult to perform -- and very easy to detect.

 Counterattacks
While reaction systems counter intrusions by blocking or cancelling the attempts, counterattack systems launch return port scans or other aggressive attacks against the intruding system.

An equal and opposite overreaction
Some security systems, such as Abacus Sentry, include counterattack capability. While it is tempting to think about striking back at an intruder, these systems can cause a great deal of trouble. Some of these counterattack measures can be turned against their owners or be used by attackers to attack others in turn. By configuring these systems to counterattack in the face of a UDP or FIN scan (which can be spoofed), you may actually set yourself up to be used to attack other systems.

One site on a network erected a counterattacker that was triggered by any attempt to telnet to the system. In response to a telnet connection, this system would e-mail a nasty message to the system administrator of the originating system, as well as to the domain and network administrators. Someone then discovered what great fun it would be to include a telnet:// URL in a couple of Web pages and in some HTML-enabled e-mail. The resulting flood of complaints and nasty messages showed just how bad a mistake a poorly thought-out counterattack can be.

My personal advice on counterattack systems is: don't do it! It's not worth it if someone subverts your system to attack someone else -- and you get the blame!

System logs and logging servers
Moving your logging server to a separate, isolated machine adds another level of security to your system; replacing the logging utility with one of its secure counterparts makes for an even better solution.

Secure logging
Use a separate logging server for syslog services. This could be a spare box with sufficient disk space for all of your logging needs. There should be no other services running on this system. This will severely limit an intruder's ability to penetrate the logging system and tamper with the logs. Periodically writing the logs to a write-once media, for those who have such devices, is also useful to thwart attempts to tamper with logs.

Secure syslog
Even with separate log servers, the stock syslog utility is rather insecure. While it is true that prevention is the first line of defense, detection is always the second.

Bruce Schneier has presented ideas for creating a secure log server in which cryptographic signatures would be incorporated into the logs. This would ensure that intrusions cannot go undetected, even if the logs are tampered with.

A secure log server replacement for syslog, called ssyslong, is available from the Core SDI site (see Resources). This daemon implements cryptographic security on the logs and enables remote auditing.

>From the Core SDI page on Secure Syslog:

BLOCKQUOTE: Designed to replace the syslog daemon, ssyslog implements a cryptographic protocol called PEO-1 that allows the remote auditing of system logs. Auditing remains possible even if an intruder gains superuser privileges in the system, [as] the protocol guarantees that the information logged before and during the intrusion process cannot be modified without the auditor (on a remote, trusted host) noticing. :END_BLOCKQUOTE

syslog-ng
Another secure alternative to syslog is syslog-ng, the "next generation syslog," available from BalaBit.

This is a more configurable logging daemon, and it includes cryptographic signatures to detect log tampering. It also allows for directing log traffic based on facility and level, as well as on content and use of regular expressions.

Remote logging servers, in combination with cryptographically secure logging servers and secure remote audit capability, can make log tampering extremely difficult to perform -- and very easy to detect.

About the author
Mike Warfield is a senior security researcher on the Internet Security Systems X-Force. He is also a member of the Samba Development Team, a founding member of the Atlanta Linux Enthusiasts, and a long-standing guru with the Atlanta Unix Users Group. He has been involved in Unix systems for over 15 years and with computer security for over 25 years.

Resources
# "Securing Linux, Part 1: Elementary Linux Security," Michael H. Warfield (On the Ramparts, LinuxWorld, May 1999):
http://linuxworld.com/linuxworld/lw-1999-05/lw-05-ramparts.html
# Read Michael Warfield's previous On the Ramparts columns in the LinuxWorld archives:
http://linuxworld.com/linuxworld/archive/columnsbydate.html#ramparts

Further reading and security resources
(Most of the sites listed below feature additional security resources and links.)

Resources mentioned in this article

      Secure Linux Project mailing list:
    * securelinux at reseau.nl Bastille Linux:
      http://www.bastille-linux.org/
      Bastille Linux mailing list:
      bastille-linux at bastille-linux.org
    * Kha0s Linux
      http://www.kha0s.org/
    * Kha0s Linux mailing list:
      kha0s-dev at kha0s.org Common secure Linux distribution mailing list:
      securedistros at nl.linux.org Security auditing common mailing list:
      security-audit at ferret.lmh.ox.ac.uk 

Invaluable security resources

    * North American Cryptographic Archives:
      http://www.cryptography.org/
    * Trinux:
      http://www.trinux.org/
    * Nessus:
      http://www.nessus.org/
    * Psionic Software, makers of Abacus Sentry:
      http://www.psionic.com/
    * RootShell:
      http://www.rootshell.com/
    * L0pht Heavy Industries:
      http://www.l0pht.com/
    * Deception Toolkit:
      http://all.net/dtk/dtk.html
    * "Securing Your Linux Box," Peter Vertes (Linux Gazette, November 1998):
      http://www.linuxgazette.com/issue34/vertes.html
      Wietse Venema's collected tools and papers: ftp://ftp.porcupine.org/pub/security/index.html
    * StackGuard:
      http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
    * Internet Security Systems:
      http://www.iss.net/
    * CERT Security Improvement modules:
      http://www.cert.org/security-improvement/
    * CIAC (Computer Incident Advisory Capability):
      http://ciac.llnl.gov/ciac/
      BugTraq:
      bugtraq at securityfocus.com Linux-Security:
      linux-security at redhat.com The Resources section for "Securing Linux, Part 1: Elementary Security":
      http://linuxworld.com/linuxworld/lw-1999-05/lw-05-ramparts.html
      #resources 


Copyright Š 1998-2002 LinuxWorld.com, an IDG Communications company.


Mehr Informationen über die Mailingliste linux-l