Basic Security
Fortunately, Linux has a lot of built in security that it inherits from its Unix forebears. User accounts are clearly separate from each other. It's easy to configure a Linux system so that normal users have zero rights outside their own user space. The administrator or 'root' account is virtually untouchable if one doesn't have physical access to the machine and proper password and login policies are in place.
User Account Security
Root is the number one user on the system. Fortunately, root's privileges can only be shared explicitly through the use of programs like 'sudo'. Other than that, there's no way a normal user under normal circumstances can do what root can. But user accounts can also be a source of compromise and they need to be made secure. We can start by making sure that user directories are accessible only to the owner of the account. To do this, directories should be created with read, write and execute permissions only for the user:
In the event that somebody was able to get a password for a user account, this would make it extremely difficult to browse other users' files for possible information like passwords. It will also keep legitimate users from poking around in other people's directories. Of course, one user account may be all that's needed in order to gain root privileges. This can be done by exploiting known bugs. Remember, we're trying to make it more difficult, but 100% secure is never possible.
If It Isn't Permitted, It's Prohibited
Running a Linux system should never be compared with a democracy. The root user is the dictator. What he or she permits, is allowed. What isn't allowed doesn't come up for debate. It's prohibited. If you're the root user and you've just set up a system, the first thing you should do is go over to /etc and open up the hosts.deny file. Place the following line in it, if it isn't in there already. This should probably be the only line in the file, apart from comments:
This establishes from the outset that nobody can do anything. That is, we're denying ALL to ALL. Now we can start to give access to certain hosts and users via hosts.allow
Giving access to services in hosts.allow can be service based, host/ip based or both. For example, if you wanted to permit logins to pickup mail via IMAP, you could add this to your hosts.allow:
Since you may have roaming users, it would be impossible to know where they might be at any given moment. They may be getting their connection from a hotel or an public wireless point at an airport, for example. This would let anybody from anywhere login (or at least try to login) to the IMAP daemon. Since mail passwords are often sent in the clear, this is potentially a security breach if your users had the same password for mail pickup as they do for their accounts. Their password could be sniffed and an attacker could gain a foothold in the system via a user account. This, of course, doesn't have to happen. We could, for example, set up a mail system that uses virtual accounts instead of real ones, keeping the user accounts and the mail accounts separate. Virtual mail accounts would also keep you from having to give user accounts on the system altogether. A mail system with virtual accounts can be very useful and is something we'll deal with in a separate section of this advanced course.
There are also measures that we can take in the hosts.allow file itself that would slow at attacker down. We could limit access by hostname or IP to other services by adding the following lines to your hosts.allow.
I always find it a good idea to add little comments about who belongs to these IPs and hosts. If you ended up up, say, ending your contract with Dave, the outside consultant, you don't really want him having access to the machine anymore. With these comments you can more easily keep track of what people should be accessing and who should be removed. Sure, it's a little bit more work, but security is only as good as the work you put into it. Believe me, attackers have more time on their hands than you, so any extra work is worth the trouble.
We've secured our machine as best we can with the default tools and files available, but it still isn't good enough. What we can do now, other than un-plugging our machine when we're not using it, is to set up a top-notch firewall.
Fortunately, Linux has a lot of built in security that it inherits from its Unix forebears. User accounts are clearly separate from each other. It's easy to configure a Linux system so that normal users have zero rights outside their own user space. The administrator or 'root' account is virtually untouchable if one doesn't have physical access to the machine and proper password and login policies are in place.
User Account Security
Root is the number one user on the system. Fortunately, root's privileges can only be shared explicitly through the use of programs like 'sudo'. Other than that, there's no way a normal user under normal circumstances can do what root can. But user accounts can also be a source of compromise and they need to be made secure. We can start by making sure that user directories are accessible only to the owner of the account. To do this, directories should be created with read, write and execute permissions only for the user:
Code:
drwx------ 101 bsmith bsmith 8192 Nov 9 17:53 bsmithIn the event that somebody was able to get a password for a user account, this would make it extremely difficult to browse other users' files for possible information like passwords. It will also keep legitimate users from poking around in other people's directories. Of course, one user account may be all that's needed in order to gain root privileges. This can be done by exploiting known bugs. Remember, we're trying to make it more difficult, but 100% secure is never possible.
If It Isn't Permitted, It's Prohibited
Running a Linux system should never be compared with a democracy. The root user is the dictator. What he or she permits, is allowed. What isn't allowed doesn't come up for debate. It's prohibited. If you're the root user and you've just set up a system, the first thing you should do is go over to /etc and open up the hosts.deny file. Place the following line in it, if it isn't in there already. This should probably be the only line in the file, apart from comments:
Code:
ALL : ALLThis establishes from the outset that nobody can do anything. That is, we're denying ALL to ALL. Now we can start to give access to certain hosts and users via hosts.allow
Giving access to services in hosts.allow can be service based, host/ip based or both. For example, if you wanted to permit logins to pickup mail via IMAP, you could add this to your hosts.allow:
Code:
imapd: ALLSince you may have roaming users, it would be impossible to know where they might be at any given moment. They may be getting their connection from a hotel or an public wireless point at an airport, for example. This would let anybody from anywhere login (or at least try to login) to the IMAP daemon. Since mail passwords are often sent in the clear, this is potentially a security breach if your users had the same password for mail pickup as they do for their accounts. Their password could be sniffed and an attacker could gain a foothold in the system via a user account. This, of course, doesn't have to happen. We could, for example, set up a mail system that uses virtual accounts instead of real ones, keeping the user accounts and the mail accounts separate. Virtual mail accounts would also keep you from having to give user accounts on the system altogether. A mail system with virtual accounts can be very useful and is something we'll deal with in a separate section of this advanced course.
There are also measures that we can take in the hosts.allow file itself that would slow at attacker down. We could limit access by hostname or IP to other services by adding the following lines to your hosts.allow.
Code:
# acmeisp.com = Bob's ISP
# 333.444.555.666 = Janet's home IP
# 987.654.321.001 = Dave the outside consultant
ALL : 192.168., .acmeisp.com, 333.444.555.666, 987.654.321.001I always find it a good idea to add little comments about who belongs to these IPs and hosts. If you ended up up, say, ending your contract with Dave, the outside consultant, you don't really want him having access to the machine anymore. With these comments you can more easily keep track of what people should be accessing and who should be removed. Sure, it's a little bit more work, but security is only as good as the work you put into it. Believe me, attackers have more time on their hands than you, so any extra work is worth the trouble.
We've secured our machine as best we can with the default tools and files available, but it still isn't good enough. What we can do now, other than un-plugging our machine when we're not using it, is to set up a top-notch firewall.
