|
|
Anybody can easily get a root-shell and change your passwords by entering "<name-of-your-bootimage> init=/bin/sh" at the boot prompt. After changing the passwords and rebooting the system, the person has unlimited root-access and can do anything they want to the system. After this procedure you will not have root access to your system, as you do not know your own root password.
To make sure that this can not happen, you should set a password for the boot loader. You can choose between a global password or a password for a certain image.
For LILO you need to edit the config file /etc/lilo.conf and add a "password" and "restricted" line as in the example below.
image=/boot/2.2.14-vmlinuz
label=Linux
read-only
password=hackme
restricted
When done, rerun lilo. Omitting the "restricted" line, causes lilo to always prompt for a password, regardless of whether LILO was passed parameters. When adding a password make sure that only root can read the lilo config file, i.e. chmod 600 /etc/lilo.conf.
If you use GRUB instead of LILO, edit the file /boot/grub/menu.lst and add the following two lines at the top. This will set a boot-password and also boot the default entry after waiting 3 seconds:
timeout 3
password hackme
The default MBR in Debian before version 2.2 did not act as a usual master boot record and left open a method to easily break into a system:
This behavior can be change by entering:
lilo -b /dev/hda
Now LILO is put into the MBR. This can also be achieved by adding "boot=/dev/hda" to lilo.conf. There is another solution which will disable the MBR prompt completely:
install-mbr -i n
On the other hand, this "backdoor", of which many people are just not aware, may save your skin as well if you run into deep trouble with your installation out of whatever reasons.
INFO: The bootdisks as of Debian 2.2 do NOT install the mbr, but only LILO
When mounting an ext2 partition you have several additional options you apply to the mount call or the /etc/fstab. For instance, this my fstab entry for the /tmp partition:
/dev/hda7 /tmp ext2 defaults,nosuid,noexec,nodev 0 2
You see the difference in the options sections. The option nosuid
ignores the setuid and setgid bits completely, while noexec
forbids execution of any program on that mount point and nodev,
which ignores devices. This sounds great, but it
noexec option prevents binaries from being executed directly,
but is easily circumvented:
alex@joker:/tmp# mount | grep tmp
/dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
alex@joker:/tmp# ./date
bash: ./date: Permission denied
alex@joker:/tmp# /lib/ld-linux.so.2 ./date
Sun Dec 3 17:49:23 CET 2000
However, many script kiddies have exploits which try to create and execute files in /tmp. If they do not have a clue, they will fall into this pit. In other words, if the user does not have a clue, he will not fall into the pit of executing a trojaned binary /tmp, when he incidentally adds /tmp into his PATH.
PAM allows system administrators to choose how applications authenticate users. Note that PAM can do nothing unless an application is compiled with support for PAM. Most of the applications that are shipped with Debian 2.2 have this support built in. Furthermore Debian did not have PAM support before 2.2. For each application there is a configuration file in /etc/pam.d/.
PAM offers you the possibility to go through several authentication steps once, without the user's knowledge. You could authenticate against a Berkeley database and the passwd and the user only logs in if he authenticates correct twice. You can restrict a lot with PAM, as well as you can open your system doors very wide. So be careful. A typical configuration line has a control field as its third element. Generally it should be set to "requisite", which returns a login failure if one module fails.
The first thing to do, is to add MD5 support to PAM applications, since this helps to protect against dictionary cracks. The following two lines should be added to all files in /etc/pam.d/ that grant access to the machine, like 'login' and 'ssh'.
password required pam_cracklib.so retry=3 minlen=12 difok=3
password required pam_unix.so use_authtok nullok md5
So, what does this myth do? The first line loads the cracklib PAM module, which provides password strength-checking, prompts for a new password with a minimum length of 12 characters, a difference of at least 3 characters from the old password, and allows 3 retries. The second line introduces the standard authentication module with md5 passwords and allows a zero length password. The use_authtok directive is necessary to hand over the password from the previous module.
To make sure that the user root can only log into the system from local terminals, the following line should be enabled in /etc/pam.d/login:
auth requisite pam_securetty.so
Then you should add the terminals from which the user root can log into the system into the file /etc/security/access.conf. Last but not least the following line should be enabled if you want to set up user limits.
session required pam_limits.so
This restricts the system resources that users are allowed. For example, you could restrict the number of concurrent logins users may have.
Now edit the file /etc/pam.d/passwd and change the first line. You should add the option "md5" to use md5 passwords, change the minimum length of password from 4 to 6 (or more) and set a maximum length, if you desire. The resulting line will look something like:
password required pam_unix.so nullok obscure min=6 max=11 md5
If we want to protect su, so that only some people can use it to become root on your system, we need to add a new group "wheel" to your system (that is the cleanest way, since no file has such a group permission yet). Add root and the other users that should be able to "su" to the root user to this group. Then add the following line to /etc/pam.d/su:
auth requisite pam_wheel.so group=wheel debug
This makes sure that only people from the group wheel can use to su to become root. Other users will not be able to become root. In fact they will get a denied message if they try to become root.
If you want only certain users to authenticate at a PAM service, this is quite easy to achieve by using files, where the users, which are allowed to login (or not), are stored. Imagine you only want to allow user 'ref' to login via ssh. So you put him into /etc/sshusers-allowed and write the following into /etc/pam.d/ssh
auth required pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail
Last, but not least, create /etc/pam.d/other and enter the following lines:
auth required pam_securetty.so
auth required pam_unix_auth.so
auth required pam_warn.so
auth required pam_deny.so
account required pam_unix_acct.so
account required pam_warn.so
account required pam_deny.so
password required pam_unix_passwd.so
password required pam_warn.so
password required pam_deny.so
session required pam_unix_session.so
session required pam_warn.so
session required pam_deny.so
These lines will provide a good default configuration for all applications that support PAM (access is denied per default).
You should really take a serious look into this file. Here you can define user resource limits. If you use PAM, this file is not valid and you should use /etc/security/limits.conf instead.
FIXME: Get a good limits.conf up here
You should stop all unneeded services on your system, like echo. charges, discard, daytime, time, talk, ntalk and the HIGHLY insecure considered r-services (rsh, rlogin and rcp. Use ssh instead). After disabling those, you should check if you really need the inetd daemon. Many people prefer to use daemons instead of calling services via inetd. Denial of Service possibilities exist against inetd, which can increase the machine's load tremendously. If you still want to run some kind of inetd service, switch to a more configurable inet daemon like xinetd or rlinetd.
The next step is to edit the basic configuration and action upon user login.
FAIL_DELAY 10
This variable should be set to a higher value to make it harder using the terminal to log in using brute force style. If a wrong password is typed in, he has to wait for 10 seconds to get a new login prompt, what is quite time consuming when you test passwords. Pay attention to the fact, that this setting is useless if using a program other than getty, mingetty for example.
FAILLOG_ENAB yes
If you enable this variable, failed logins will be logged. It is important to keep track of them to catch someone who tries a brute force attack.
LOG_UNKFAIL_ENAB yes
If you set the variable "FAILLOG_ENAB" to yes, then you should also set yes to this variable. This will record unknown usernames if the login failed. If you do this, make sure the logs have to the proper permissions (640 for example, with an appropriate group setting such as adm), because users often accidentally enter their password as the username and you do not want others to see it.
SYSLOG_SU_ENAB yes
This one enables logging of su attempts to syslog. Quite important on
serious machines but note that this can create privacy issues as well.
SYSLOG_SG_ENAB yes
The same as SYSLOG_SU_ENAB but applies to the sg call.
MD5_CRYPT_ENAB yes
As stated above, md5 sum passwords greatly reduce the problem of dictionary attacks, because it is very difficult to perform a crack against MD5 hashed passwords. At least it is hard to do successfully. If you are using slink, read the docs about MD5 before enabling this option. Otherwise this is set in PAM.
PASS_MAX_LEN 50
If MD5 passwords are activated in your PAM configuration, then this variable should be set to the same value as used there.
This file contains a list of users who are not allowed to log into the host using ftp. Only use this file if you really want to allow ftp (which is not recommended in general, because it uses cleartext passwords). If your daemon supports PAM, you can also use this allow and deny users for certain services.
TCP wrappers were developed when there were no real packet filters available and access control was needed. The TCP wrappers allow you to allow or deny a service for a host or a domain and define a default allow or deny rule. If you want more informations look into the manpage hosts_access(5).
Now, here comes a small trick and probably the smallest intrusion detection system available. In general you should have a decent firewall policy as a first line and tcp wrappers as the second line of defense. One little trick is to set up a spawn command in /etc/hosts.deny that sends mail to root whenever a denied service triggers wrappers:
ALL: ALL: spawn ( \
echo -e "\n\
TCP Wrappers\: Connection refused\n\
By\: $(uname -n)\n\
Process\: %d (pid %p)\n\
User\: %u\n\
Host\: %c\n\
Date\: $(date)\n\
" | /bin/mail -s "Connection to %d blocked" root)
Beware: The above printed example can easily be DoSed by doing lots of connections in a short period of time. Many emails mean a lot of file I/O by sending only a few packets.
If you really need to become the super user on your system, eg for installing
packages or adding users, you can use the command su to change your
identity. You should try to avoid any login as user root and instead use su.
Actually, the best solution is to remove su and switch to sudo, as it has
more features than su. However, su is more common as it is used on many other
Unixes.
sudo allows the user to execute defined commands under another users identity, even as root. If the user is added to /etc/sudoers and authenticates himself correctly, he is able to run commands which have been defined in /etc/sudoers. Violations, such as incorrect passwords or trying to run a program you don't have permission for, are logged and mailed to root.
chroot is one of the most powerful possibilities to restrict a daemon or a user or another service. Just imagine a jail around your target, where the target cannot escape from (normally, but there are still a lot of conditions that allow one to escape out of such a jail). If you do not trust a user, you can create a change root environment for him. This can use quite a bit of disk space as you need to copy all needed executables, as well as libraries, into the jail. Even if the user does something malicious, the scope of the damage is limited to the jail. A good example for this case is, if you do not authenticate against /etc/passwd but LDAP or MySQL instead. So your ftp-daemon needs a binary and perhaps a few libraries. A chrooted environment would be an excellent security improvement, if a new exploit is known for this ftp-daemon. It is then only possible to exploit the UID of the ftp-daemon-user and nothing else. Of course, many other daemons could benefit from this as well.
As an additional note, the Debian default BIND (the name-service) is not shipped chrooted per default, in fact no daemons come chrooted. I hope this will change in the woody release.
Many features of the kernel can be modified while running by echoing something
into the /proc file system or by using sysctl. By entering sysctl -A
you can see what you can configure and what the options are. Only in rare
cases do you need to edit something here, but you can increase security that
way as well.
net/ipv4/icmp_echo_ignore_broadcasts = 0
This is a 'windows emulator' because it acts like windows on broadcast ping, if this one is set to 1. Otherwise, it just does nothing.
net/ipv4/icmp_echo_ignore_all = 0
If you don't want to block ICMP on your firewall, enable this.
net/ipv4/tcp_syncookies = 1
This options is a double-edged sword. On the one side it protects yourself
against syn flooding, on the other sites it violates RFCs. This option is
quite dump as it floods the other side like it floods you, so the other
side is also busy. If you want to change this option you also can change
it in /etc/network/options by setting syncookies=yes.
/proc/sys/net/ipv4/conf/all/log_martians = 1
Packets with impossible addresses (due to wrong routes) on your network get logged.
SVGAlib is very nice for console lovers like me, but in the past it has been proven several times, that it is very insecure. Exploits against zgv were released, and it was simple to become root. Try to prevent using SVGAlib programs wherever possible.
Copying files in a secure manner from a host to another can be achieved by using 'scp' which is included in the ssh package. It works like rcp but is encrypted completely, so the bad guys cannot even find out WHAT yo..
Having a good quota policy is important, as it keeps users from filling up the hard disk(s). You can use two different quota systems - user quota and group quota. As you probably figured out, user quota limits the amount of space a user can take up, group quota does the equivalent for groups. Keep this in mind when you're working out quota sizes.
There are a few important points to think about in setting up a quota
system:
Every partition/directory users have full write access should be quota enabled. So find out those partitions and directories and calculate a valuable quota size, which concatenates usability and security.
So, now you want to use quotas. First of all you need to check whether you enabled quota support in your kernel. If not, you will need to recompile it. After this, control whether the package 'quota' is installed. If not you will need this one as well.
Enabling quota for the respective filesystems is as easy as modifying the
'defaults' setting to 'defaults,usrquota' in your /etc/fstab file. If you need
group quota, substitute 'usrquota' to 'grpquota'. You can also use them both.
Then create empty quota.user and quota.group files in the roots of the
filesystems you want to use quotas on (e.g. touch /home/quota.user,
touch /home/quota.group for a /home filesystem).
Restart quota by doing /etc/init.d/quota stop;/etc/init.d/quota
start. Now quota should be running, and quota sizes can be set.
Editing quotas for a specific user (say 'ref') can be done by
edquota -u ref. Group quotas can be modified withedquota -g
<group>.
Then set the soft and hard quota and/or inode quotas as needed.
For more information about quotas, read the quota man page, and the quota mini-howto.
Some logfile permissions are not perfect after the installation. First
/var/log/lastlog and /var/log/faillog do not need to be readable by normal
users. In the lastlog file you can see who logged in the lasttime and in
the faillog you see a summary of failed logins. The author recommends
chmod'ing both to 660. Take a brief look over your log files and
decide very carefully which logfiles you make read/writeable for a user with
another UID than 0 and a group other than 'adm' or 'root'.
I want to emphasize that the apache logfile permissions are really screwed due
to the fact that the apache user owns the apache log files. If a user gets a
shell with a back door in apache, they can easily can remove the logfiles.
These two commands are very useful, but they only work for the ext2 filesystem. With 'lsattr' you can list the attributes of a file and with 'chattr' you can change them. Note that attributes are not the same thing as permissions. There are many attributes, but only the most important for increasing security are mentioned here. There are two flags which can only be set by the superuser.
First there is the 'a' flag. If set on a file, this file can only be opened for appending. This attribute is useful for some of the files in /var/log/, though you should consider they get moved sometimes due to the log rotation scripts.
The second flag is the 'i' flag, short for immutable. If set on a file, it can neither be modified, deleted nor renamed and no link can be created to it. If you do not want users to look into your config files you could set this flag and remove readability. Furthermore it can give you a little bit more security against intruders, because the cracker might be confused by not being able to remove a file. Nevertheless, you should never assume that the cracker is blind. After all, he got into your system.
Are you sure /bin/login on your hard drive is still the binary you installed
there some months ago? What if it is a hacked version, which stores the
entered password in a hidden file or mails it in cleartext version all over
the internet?
The only method to have some kind of protection is to check your files every
day/hour/month (I prefer daily) by comparing the actual and the old md5sum of
this file. Two files cannot have the same md5sum, so you're on the secure site
here, except someone hacked the algorithm to create md5sums on that machine,
what is, well, sticky. You really should consider this auditing of your
binaries as very important, since it is an easy way to recognize changes at
your binaries. Common tools used for this are sXid, AIDE (Advanced Intrusion
Detection Environment) and TripWire (non-free, the new version will be GPL).
Installing debsums will help to check the filesystem integrity,
by comparing the MD5sums of everyfile against the MD5sums used in the
debian package archive. But beware, those files can easily be changed.
Furthermore you can exchange your 'locate' package with 'slocate'. slocate is a security enhanced version of GNU locate. When using slocate, the user only sees the files he really has access to and you can exclude any files or directories you want to exclude.