14.1. Security Fundamentals

14.1. Security Fundamentals

Before continuing further study of Linux, you should learn some general security principles. Some aspects that will be considered are only applicable to Linux, and others can be applied to any operating system and computer or server.

There are certain rules applicable to whatever operating system or service/daemon is being protected. These rules are considered in this chapter and are referenced in other chapters.

In this chapter, I intend to destroy some of the myths concerning security and will supply numerous examples from my personal experience as a network administrator.

Why is it necessary for you to take additional steps for protecting your system? Aren't operating systems and server software supposed to be inherently protected? Unfortunately, they are not; on the contrary, they are more vulnerable than secure. Again, God helps those who help themselves .

What is a vulnerability as related to computers? A vulnerability is an error (a.k.a.a bug) in a program that can be used to obtain unauthorized access to the system's files or capabilities.

All software has bugs because it is written by people and people have a propensity to making mistakes. Even the most protected software will have bugs; it's only a matter of time before they are found. Ask any hacker about which Linux kernel is the most secure, and you will be told that the latest kernel version is excellence itself without any bugs . Ask the same question a month later and you will find out that the kernel praised a month ago is buggy and it is recommended that you patch it before continuing working with it.

With every new Windows version, the Microsoft people tell us how reliable and secure it is, but a month later the same people tell us what a great service pack they've created for us to patch the holes and get rid of the bugs in this so-called secure and reliable operating system. Throw Internet Explorer and Microsoft Office applications into the mix and you get a good idea of the extent of the problem. Software bugs are as inevitable as death and taxes, and you have to accept this. Accepting does not mean resigning, so be ready to update regularly and religiously .

Most vulnerabilities cannot be called errors, because they have no negative effects on the program's operation; it's just that, to achieve their own goals, hackers use certain pieces of code in ways the developers never intended them to be used. To envision how every twisted mind may decide to use a program is more difficult than to ensure that it works as intended; the only thing developers can do is circumscribe the program's capabilities to the minimum necessary to perform its main function so as to minimize the number of unintended uses it can be put to.

14.1.1. Responsibility

The first step in securing the system is establishing who is to be responsible for system security. In most organizations, this task is entrusted to the system administrator, which is a mistake. The administrator who configures the system may not have the necessary security training and simply will not see his or her mistakes in this respect.

Administrators often fall victim to classical optical illusions. I have written quite a few books and constantly run into the classical problem of any author: When you read your own text, you tend to see it the way it is supposed to be and not the way it actually is. To give a simplest example, you can write "their" instead of "they're" because it sounds the same. Even though you know that it's wrong, you simply overlooked the spelling going by the vocalization only.

A spelling mistake of even one letter in a configuration file may have grievous consequences. Going through voluminous configuration files, you may fail to see it because to speed up the check you tuned your perception more to the sounds of words and not to their spelling. Besides, when checking their own work most people, no matter what they may think consciously, subconsciously think that they did everything right and do only a perfunctory check. It takes a special training to view one's own work as someone else's. But someone who sees the text for the first time and not in its primary context will notice the error right away. It is preferable that this someone be a security specialist.

The administrator should configure and service the system from the performance standpoint, and the security specialist should check the configuration from the security standpoint and test it for vulnerabilities. These two specialists have to interact and cooperate with each other, because a perfectly secure system may not necessarily be one that can deliver any meaningful performance, and vice versa. They can even substitute for each other when necessary, but no single person should be responsible for both areas, especially in large companies, meaning large networks.

Highly skilled security professionals demand a high price for their services, but you should not scrimp on security. It is better to spend a few extra dollars for a security specialist's salary than a few thousand dollars to recover from a hacker attack.

14.1.2. One Man's Trash is Another Man's Treasure

Many security specialists recommend protecting only active work areas. Indeed, you may think: What's the use of protecting the wastebasket if the information in it was discarded as unnecessary? The first thing that comes to mind in this respect is the movie Hackers , whose characters did quite a bit of dumpster diving. What were they looking for in there? For various bits and pieces of papers their owners thought were no longer valuable and discarded into trash cans without a second thought about what will happen to them. Quite often, users write passwords on pieces of paper or are given access information written on paper slips. After they write the information onto more permanent information storage media, such as notepads or notebooks , the bits of paper, and the information they contain, usually go into the trash can.

The same principle applies to the file system. A directory containing seemingly trashy information may turn out to be a mother lode of information for hackers. Once I conducted a security check of a system that had only one directory open , which contained only text files with song lyrics of group Dune. Seemingly an innocent thing, because what can be done using text files with this type of information?

I started a password-cracking program to pick the root password by the dictionary method and specified these text files as the dictionary to use. Imagine my surprise when within seconds the program informed me that the root password was the name of the group Dune!

Administrators often keep information related to their personal interests in open folders. If they also create their passwords based on their interests, this information may greatly facilitate picking of the password.

Once hackers obtain any sort of access to the system, they can raise their privileges. This can be done using various exploits, which can be found on the Internet in droves. Every day, new ones are created. If hackers have no access to the system, it will be much more difficult for them to break into it.

Currently, there aren't that many ways to break into a computer remotely, but with local access hackers' chances of raising their access privileges increase manyfold. It is easier to protect against break-ins perpetrated over the network; the main defense method here is using a firewall. But if hackers obtain some sort of access, what they can do depends only on the access-rights allocation policy. If it is not well thought out, hackers can even obtain administrator privileges.

The main targets attacked by hackers after accessing a system are the following:

  • Vulnerable operating system utilities. If you look at security reports , you will see that vulnerabilities in various utilities crop up almost weekly and programmers and administrators have a hard time keeping up with patches.

  • Third-party software. The developers of distributions go to great lengths to test all application-software packages included with their distribution. But third-party developers usually test their software only with their own distribution; thus, there is no guarantee that such a program will work reliably and securely under all Linux versions. Moreover, the professionalism of some third-party software developers and, thus, the quality of their software leaves a lot to be desired, as was explained in Section 1.3 .

  • Scripts and programs written by the system administrator or company programmers. To expand the functionality of the operating system, administrators often write their own scripts (mostly using the Perl interpreter), and quite frequently hackers break into the system through holes in such scripts. Only a professional programmer possessing a good knowledge of security principles and secure coding techniques can create a secure script or program. Beginning programmers and regular administrators do not give proper attention to checking arguments and parameters, which results in low-quality code.

To summarize, there should be "important" and "unimportant" areas where security is concerned . Although more important data should be allowed better protection, up to being encrypted, the whole system should be protected as well.

You can fortify the server containing restricted information and open another one for public use. In this case, however, there should be no trust relationship between these two servers, and user names and passwords must be different. But humans , being such a lazy bunch, typically make the root passwords for all servers the same or, if they differ , make them similar enough that they will be easy to remember. If you can discipline yourself to follow all pertinent security rules, assigning different physical servers for different tasks is a correct approach to securing your network.

You can start by strictly following the rule that the root user password should be different for each server.

14.1.3. All Users Are Created Equal

Being a network administrator in a large company with many departments is the most difficult chore psychologically.

Most administrators direct their security measures toward protecting the network from outside attacks. But statistically, most and the worst break-ins are perpetrated from inside by company workers, their friends and acquaintances , and the like. It is much easier to perpetrate an internal break-in, because administrators often cannot resist pressure from friends and coworkers to give them some password or access to a certain resource. You should not yield to any entreaties or demands of this type. A friend given expanded privileges may repay the kindness in the form of a break-in. It may be purely accidental or intended as an innocent prank, but cleaning up the consequences may be as difficult as after a real break-in.

Security means not only hardening your system against break-ins but also making it impervious to improper user actions. The simplest example is what I call the boss effect. Many administrators consider that their direct boss or the company director should have the right to view any information in the system. There may be a legitimate need for this, but once a boss is given rights to view information, he or she usually starts demanding the write rights also. This is much more likely to create problems, especially if the boss is a klutz with computers. And it is usually bosses of this type who ask for the maximum rights. If you yield to someone pulling rank, there is a good chance that their use of these rights will result in serious data loss. Guess who will be left holding the bag?

Another problem stemming from giving extra privileges to friends and bosses is that it is impossible to protect their passwords. If there is only one maximum-privileges user in the system, the root, it is relatively easy to protect his or her password. But keeping track of the passwords of ten high-privileged users is a more difficult task. Any of these users can select an easy password or simply write a strong password on paper. In either case, the password will become vulnerable with the corresponding consequences stemming from it being compromised.

14.1.4. Protecting Workstations

Protecting workstations is no less important than protecting the operating system and its services. When I worked as a programmer for a major company, I was responsible for developing industrial equipment data-collection software, configuring workstations, installing workstations with the software into the shops , and doing operational maintenance. For each computer I devised an individual strong password.

Seemingly, I took good care to make the workstations secure, but when one day I came to one of the shops to service one of the computers I saw the password written with a permanent marker on the monitor case. So, all my efforts at creating strong passwords were nullified by one lazy computer operator, who made the password available for any company worker or even a stranger to see.

Beginning computer users do not like to remember strong passwords, so they write them on the monitor, the keyboard, or Post-It notes, which are then stuck on the same monitor or keyboard. It is unnecessary to say what this turns the administrator's best efforts to secure the system into.

Thus, you should pay the same attention to securing workstations as to securing the network. Based on my experience, I can say that most break-ins have their roots in the lackadaisical attitude of users.

You can protect workstations by following these recommendations:

  • Never write down passwords on paper and, even more so, never leave these near monitors or keyboards. Take a little time to memorize the main passwords.

  • Leaving the computer, block the keyboard (e.g., using the vlock or xlock utility) or log out of the system, so that no one can use the computer while you are away.

  • Changing the password takes just a few seconds, so never rely on a screensaver because someone can take advantage of your momentary absence and change the password. Thus, you can lose control over your account. I disable the screensaver on my computers so as not to be tempted to rely on it; instead, I have developed a habit of always blocking the keyboard when leaving the computer even for a short time.

  • If you work in the graphical mode, never place any shortcuts other than the default ones on the desktop. For example, a shortcut to another computer provides a wealth of information for hackers.

  • Put a password on BIOS. If hackers obtain physical access to the computer, they will be able to reboot it in the single-user mode and proceed to break the root password.

  • Use a boot loader password to protect against unauthorized booting (see Section 3.2 ).

  • Disable the <Ctrl>+<Alt>+<Del> key combination by deleting the corresponding entry in the /etc/inittab file to prevent accidental or unauthorized boots.

14.1.5. Security Documentation

Many administrators consider documentation the domain of bureaucrats, and categorically refuse to issue any documented instructions. There was time when I was like that myself and preferred to keep everything in my head and issue only oral instructions. This continued until the system grew too large and complex to be managed this way and was eventually hacked.

Consider a simple example of using documentation to make your system more secure. Suppose hackers broke into your system and obtained root privileges. You close the hole and change the root password, but the hackers return in almost no time. How could they manage this? It is possible that the hackers stole the password file and decrypted the passwords in it. To prevent this type of situation, all user passwords should be changed after a break-in. This can be done in one of the following two ways:

  • Generate new passwords yourself and distribute them to the users. This approach is convenient for a large network to ensure that all passwords are changed. However, there could be problems distributing passwords.

  • Prepare a security memo instructing all users to change their passwords when instructed by the administrator. All users should be familiarized with this memo.

In practice, however, it would be preferable to use a combination of these two methods . That is, users are instructed to change their passwords themselves, but if they don't do this within a certain period (for example, 3 hours) after having been instructed to, you change the passwords. This solves the distribution problem: The users will come to you to discover their new password.

The security memo should also instruct users to create strong passwords of a certain minimal length. Most importantly, you should ensure that users use strong passwords.

Documentation can also be used to make various department heads help you maintain system security. For example, network administrators usually don't know when a worker's employment is terminated . A former employee can give his or her login information to another person, who may not even be a company employee and who then can use this information for an illegitimate purpose.

Also, a fired worker may decide to get even with the administration for the firing and use his or her login parameters to do some unscheduled creative maintenance on the system. There are numerous examples of this happening. I witnessed one such case when the network administrator was fired but the new administrator did not change the passwords. Two days later he wished that he had not had so much faith in human decency: The server's hard disk was wiped clean. At the time I worked as a programmer at that company and had my share of overtime restoring the destroyed data.

14.1.6. Passwords

All passwords must be periodically changed. I change passwords monthly for my Web site; the same goes for the servers, with the important ones having their passwords changed weekly.

Even though this adds certain inconveniences when remember the new passwords, the security this provides is worth it.

The only password I don't change is the Windows password on my notebook, because I am the only one who uses it.

Once they obtain access to the system, many hackers do not engage into any malevolent activities. They simply explore the system to figure out its organizations and ways for staying undetected. Only those hackers intent on destroying data will move fast, because they don't intend to hang around long. Fortunately, there aren't that many break-ins of this type.

So it is possible for you not to notice a hacker lurking in your system. But if you change passwords every month, after a regular password change the trespasser will lose his or her rights and will have to break the password again.

Changing passwords regularly makes cracking them more difficult. Here is how. Many automated security systems can easily detect an attempt at password cracking by several unsuccessful authorization attempts in a row, usually three. To circumvent such protection, hackers insert some delay before trying the next password. This makes the break-in process longer, but unless the password is difficult and changed periodically, the attack will ultimately succeed. If the password is periodically changed, the possibility to pick it before the next change becomes very low.

For example, suppose that the password contains only digits. Further, suppose that the password is 7000000. By a brute-force search, the hacker tried combinations from 0 to 6000000, at which point the password was changed to 5000000. Further combination picking can go on indefinitely without any results, because the range, in which the new password is located, has already been passed.

Another advantage offered by regular password changes is that it may take the hacker so long to pick a strong password that by the time he or she succeeds the password will be changed, throwing the hacker back to stage one.

How can you make users change passwords periodically? You can make use of the chage utility, executing it as follows :

 chage parameter user 

The parameter value can be one of the following:

  • -m N Sets N as the minimum number of days between password changes. Setting this value to a few days smaller than the maximum value, you can protect against unauthorized password changes, meaning that if hackers take over an account, they will not be able to change its password. They can get around this by executing the chage command themselves, but they will need root privileges for this. A difference of 3 to 4 days between the maximum and the minimum number of days before a password change should give the user enough time to change the old password. The difference ought not to be less than 3 days to account for weekends. The default value is -1 , meaning the user can change the password any time before it expires .

  • -M N Sets N as the maximum number of days, during which the password remains valid. The default value of N is 99999, meaning that the password never becomes invalid.

  • -d N Sets the date the password was last changed. The N parameter is the number of days from January 1, 1970. The date can also be expressed in the YYYY-MM-DD format.

  • -E date Sets the date, on which the user's account will no longer be accessible.

  • -IN Blocks the account if it has not been used for N days. I recommend setting the N value to no fewer than 3 days but no more than 4 days to block the account while the owner is on vacation or sick leave.

  • -WN Displays a warning that the password is about to expire, starting N days before the password expiration date. This should be set to no less than 3 days for the user to be able to change the password if the expiration falls on weekend .

  • -l user With this parameter, the command can be executed by any user but only to find out when his or her password expires. For example, executing chage -l root displays the expiration date of the root password and other pertinent information. The execution results look similar to the following:

     Minimum:      -1 Maximum:      99999 Warning:     -1 Inactive:    -1 Last Change:        Feb 04, 2004 Password Expires:   Never Password Inactive:  Never Account Expires:    Never 

The meanings of the entries in the preceding listing are as follows:

  • Minimum The minimum number of days between password changes

  • Maximum The maximum number of days before the password change

  • Warning The number of days before the password expiration that a warning message starts to be issued

  • Inactive The number of days the account remains inactive before it is blocked

  • Last Change The date the password was last changed

  • Password Expires The password expiration date

  • Password Inactive The date the password became inactive

  • Account Expires The account expiration date

Changing a password too often results in users simply not being able to remember or get used to them. Consequently, they start writing strong passwords down or simply change the new passwords to the old. To prevent this development, users should not be made to change passwords too often. A period of 60 to 90 days between password changes is considered acceptable.

But how can you make sure that users select strong passwords or that they do not simply reuse the old passwords? This can be achieved with the help of the pam_cracklib.so module. This module performs basic password checking for stronger passwords. For example, the module will not allow the user to specify the old password or a password containing too many characters from the old password.

The pam_cracklib.so module is enabled by adding the following entry to the /etc/pam.d/passwd file:

 password required pam_cracklib.so retry=5 minlength=8 

The first part tells the system to use the pam_cracklib.so library. The retry parameter sets the number of attempts to enter the new password to five. The minlength parameter sets the minimum password length.

14.1.7. BugTraq

To tell the truth, there aren't that many real hackers in the world. Most break-ins are perpetrated by teenagers who have nothing better to do and who want to try their skills somewhere. This sort of hackers is not too strong on the theory of programming and mainly uses ready-made techniques designed and perfected by real hackers. This means that you should keep track of new break-in techniques and newly- discovered vulnerabilities. I use the www.securityfocus.com or www.cert.org sites for this purpose. They regularly publish information about new security holes, how to use them, and how to protect against their use.

The discussions concerning the need for sites like www.securityfocus.com have been carried on for a long time. On one hand, they allow administrators to protect their systems by learning about new vulnerabilities, but on the other the hackers can use this information for diametrically opposite purposes. I don't see any problems with such sites and, what is even more, believe they are a good idea. The problem is that most administrators simply do not visit these sites and they learn about the weak spots only when their site, network, or server has been broken into. Even if you consider a security hole discovered in 1990s, computers and servers can still be found on the Internet that have this hole unpatched. If I had my way, I would sack such administrators without thinking twice.

If you think that regularly updating your system can make it impervious to break-ins, you are sadly mistaken. A considerable length of time may pass from the time a new security hole is discovered until an update with a patch for it comes out, during which your computer can be compromised. Any hacker who has learned about the new hole can successfully attack your computer. To keep this from happening, you must learn about the new vulnerability before hackers do and undertake your own security measures to keep your computer secure until the official patch comes out.

Not only services but also the kernel can contain bugs. Bugs in application software can be fixed by installing a fresh version. Fixing kernel bugs is somewhat more complicated. Updating it involves recompiling the kernel source code, which is a rather intricate procedure. But updating using RPM is no more difficult than installing any other program.

14.1.8. Patching the Kernel

In addition to the official kernel updates, there are many patches written by third-party developers (e.g., SELinux, lcap, and LIDS). All of them are intended for securing the system on the kernel level. For example, the kernel can prohibit executing code from the stack, which will make many stack-overflow attacks impossible. There are kernel patches to prohibit viewing files in the /proc directory, monitor system processes, protect against port scanning, and so on.

You may ask why examples of third-party kernel patches weren't considered earlier in the book. The reason is that most of such patches require you to recompile the kernel, do not work with all Linux kernel versions, and require serious effort to install. Although kernel patches enhance system security, they may make the system less stable because they are produced by third-party developers and Red Hat Linux may simply not support all of their requirements.

This is why this subject is not included in the book. However, you should know that such patches exist; you may decide that the security features offered by a certain patch are just what your system needs, and install it. But you should realize that you will be doing this at your own risk. You should also be aware that updating the kernel to a new version may cause problems. Moreover, as with all new software, new kernel versions have bugs that will have to be patched.

14.1.9. Raising the Professional Skill Level

One of the most important components of effective administration is constant improving your professional skill level.

Many computer specialists do not have special education and are self-taught. I have rather extensive experience dealing with administrators and can tell from the contents of administrator's computer the professionalism level of its owner. In a nutshell , if there are games on the administrator's computer, there is a 90% chance that the administrator spends too much time fighting monsters. If the computer has no games and only administrating software, the administrator is a good one or on the way to becoming such.

The computer field is in the state of constant development, and if you spend more time running through dark hallways and machine-gunning monsters, your computer skills will become obsolete faster than rapidly . You have to be constantly raising the level of your professional skill and learning something new every day.

Special education is a good thing, but it only gives the base that you can learn from professional literature in a month or so. Specific knowledge becomes obsolete way before you graduate from college, and unless you constantly refresh your body of knowledge, you stand good chances of becoming a simple advanced user.

All work and no play makes Johnny a dull boy, so shooting a monster now and then is no sin. But you should remember that computer-security specialist responsibilities include not only taking care of present tasks but also raising your qualification level.

The preceding was just a general outline of security concepts. Other sections of the book consider the operating system and its various services from the security standpoint in more detail. But the general rules always apply regardless of the operating system and hardware.



Hacker Linux Uncovered
Hacker Linux Uncovered
ISBN: 1931769508
EAN: 2147483647
Year: 2004
Pages: 141

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