Security Administration with Debian GNU/Linux
Debian has a package manager (DPKG) that resolves dependency problems automatically. It help us to automatically keep up to date programs looking for new versions on the internet, resolving and completing the files and libraries dependencies which a package requires, making system administration easy and keeping us up to date with the new security changes. It also shows some important and substantial security features: it doesn’t have commercial goals, also doesn’t obey mercantile urgencies, It has a good pursuit of errors, problems are fixed in less than 48 hours and it’s priority is to develop a complete and reliable operating system.
From a security and reliability standpoint, it’s better to have separate hard disk partitions for directories that are large, and especially to separate those which are frequently-changing (/tmp and /var) from those that can be mounted read-only except when installing software (/usr). Some people also make separate partitions for /home and /usr/local. Separate partitions mean that if one gets corrupted, the others won’t be affected. It also means you can mount some partitions (especially /usr and /boot) read-only except when doing system administration: this decreases the likelihood of corruption or mistakes dramatically. Don’t do the distribution default, which is usually to put everything in one partition. Of course, you can go overboard if you use too many partitions, and if you don’t anticipate your sizes correctly you may end up with wasted space in some partitions and not enough space in others. In that case you’ll either have to back up the files and repartition, or use symbolic links to steal space from another partition. Both strategies are undesirable, so think beforehand about how many partitions are appropriate for this machine, which directories contain irreplaceable data, and leave some extra space for unexpected additions later.
The Debian installation, text mode, consists of two phases. The first one consists of installing the base system and the second one allows us to configure several details and the installation of additional packages. It is also necessary to identify those services that the system will offer. It doesn’t make sense to install packages that could open ports and offer unnecessary services, so we will begin installing just the base system and after that the services our system will offer.
There are some software tools to perform vulnerability verification or security auditing in our servers; these tools are intended to detect well-known security problems and also to offer detailed information in how to solve almost any problem you find. This kind of analysis is also called “ethical hacking” because we can check the way our servers can be penetrated as an intruder would do it. Nessus audits insecurity. Its main advantage is that it is totally modernized with the latest attacks, with the possibility to include them in plug-ins form. It is available for any UNIX flavor from its Web site: www.nessus.org It is composed of two programs:
The server performs the exploration. It should be started with root privileges and uses the ports 1241 and 3001 to listen to nessus client’s requests. To install it is necessary to type the following command:
# apt-get install nessusd
It only runs in UNIX and the client should be authenticated by means of a login and a password that has to be activated in the system with the different options offered by nessus-adduser command.
It is the client who communicates with nessusd. This program has its own graphical front end for administrative purposes. It’s not just for UNIX but for Windows too. Also one of its tasks is report generation at the end of the exploration, showing the vulnerabilities found and their possible solutions. To install it we have to type:
# apt-get install nessus
Nessus uses a couple of keys stored in the .nessus.keys directory located in user’s HOME. They are used to communicate with nessusd.
I do not want to repeat the HOWTO and manuals information so I will focus on specific points and situations not considered frequently, the use of limits and files attributes.
Permissions and Attributes
The Linux permissions and attributes system allows us to restrict file access to non authorized users. The basic permissions are read (r), writ (w) and execute (x).
To visualize a directory permission structure we type
The permission column has 10 characters divided in 4 groups:
- rw- rw- r--
The first part indicates the file type:
The other characters indicate if the owner, the owner group and all others have permission to read, write or execute the file. The chmod command is used to change permission with – + = operators to remove, add or to assign permissions. For example:
$ chmod +x foo
Assigns to foo execution attributes. To remove execution permission to the group members we type:
$ chmod g-r foo
Another way to change the permission schema is by the octal system where each number represents a place-dependant permission for owner, group or all others.
For example, if we type:
$ chmod 751 foo
We assign read, write and execute permission to the file owner (7), the group can read it and to execute it (5) and can be executed by everybody else (1).
We can also modify file attributes with chattr and list them with lsattr, this allows us to increase file and directory security. Attributes can be assigned in this way:
An example to assign “immutability”, so the file can not be modified, erased, linked or renamed would be:
If any user has writing permission on a certain directory, he will be able to erase any file contained in that directory although he is neither the owner nor has privileges. To assign permissions to a directory so that no user can erase another user’s files we assign the sticky bit with chmod:
When we create files or directories they have predetermined permissions, commonly 664 for files and 775 for directory This is done by the umask value. To assign more restrictive permissions as 666 for files and 777 for directory, it is advisable to establish the umask value at 077 inside each user’s profile in
Quotas and Limits
Since Linux is a multi-user operating system, it is possible that several users could be filling the hard disk or wasting the disk’s resources, so a quota disk can be a good choice. To make this, it is enough to modify the /etc/fstab file adding usrquota, then create two files for the partition: quota.user and quota.grup:
Then restart the system and the assigned quota can be modified with edquota. It is also possible to limit users, i.e. to limit CPU’s time usage, the number of open files, data segment size, etc. For this we use the ulimit command, the commands must be placed in /etc/profile and every time a user obtains a shell those commands are executed. The options are:
The user’s command record is stored in the ~/.bash_history file. The user could consult it with the history command, using the direction keys (up and down). However there are several ways to avoid this, for example history-c command erases the current record. Replacing the contents of the environment variable HISTFILE to null is another way. Yet another way is to kill the session with
kill -9 or
kill -9 0.
In order to record users behavior there is a tool called snoopy which logs this activity, however it could be considered a privacy issue, so if you implement it would be wise to create policies and let users know that all their activities are registered. It can be installed with
apt-get install snoopy. At this moment the last version is 1.3-3.
A way to identify the processes using user’s files is by the fuser command; this is very useful in order to know what users have open files that disallow umounting a certain file system. Another useful command to know the open files and sockets list is lsof. To identify what process is using a certain socket we can type for example:
lsoft -i -n -P | grep 80| grep LISTEN
Logs and Services
The faillog and lastlog files are inside /var/log which register the last successful and failed connections, they will be analyzed in the intruders’ detection section, but they are accessible to everybody and it is convenient to limit their access with:
chmod 660 /var/log/faillog
chmod 660 /var/log/lastlog
The lilo.conf file is also accessible to all. It has the Linux loader configuration and by this is why it is advisable to limit its access with:
chmod 600 /etc/lilo.conf
The setuid is when a program makes a system call to assign itself a UID to identify a process. Programs recorded with setuid can be executed by the owner or by a process that reaches the appropriate privileges, being able to adopt the program’s owner UID. To determine what files are setuid and setgid we can carry out a search with:
$ find / -perm -4000 -print
When installed, every UNIX opens many services but many of them are not necessary, depending on the kind of server built. For example in my linux box I have the following services:
$ netstat -pn -l -A inet
This shows information such as the protocol type, address and port as well as the state it is in. With
lsof we can obtain more precise and summarized information
This shows us the service, port, proprietor and protocol used. To list the demons that have inet.d we can revise their configuration file in
And to stop and disable a service, in this case we will disable the time, we have the command:
$ update-inetd -disable time
and the file
inetd.conf is modified like this:
To restart the daemon inetd we can use the command:
$ /etc/init.d/inetd restart
To disable unnecessary services, I made the following shell script, remembering that you can adapt it for your purposes.
Well, for all this I use the
man pages of the programs, I hope this can help people get interested a little bit more in Linux security, and specifically with Debian.
This article originally appeared at LinuxGazette.com
Currently I’m an active member of the Puebla Linux User Group (GULP) in Mxico. I frequently participate in events to promove the use of Free Software and Linux mainly. I accept any questions, comments or suggestions by email.