4.17. Límites y control de los sistemas de archivos
Tener una buena política de quotas es importante, esto abstiene a los usuarios de llenar el disco duro.
Usted puede usar dos sistemas diferentes de quotas: quota de usuario y quota de grupo. Como usted provablemente dedujo, la quota del usuario límita la cantidad de espacio del que un usuario puede disponer, la quota del grupo hace lo equivalente para los grupos. Tenga en cuenta ésto cuando esté organizando el tamaño de quotas.
Hay algunos puntos importantes para considerar acerca de la configuración del sistema de quotas:
Mantener las quotas suficientemente pequeñas, para que los usuarios no ocupen el espacio de su disco.
Mantener las quotas lo suficientemente grandes, para que los usuarios no se quejen o su quota de correo les impida aceptar un correo por un periodo de tiempo largo.
Use las quotas para todas las áreas en las que los usuarios puedan escribir, en /home como también en /tmp.
Every partition or directory to which users have full write access should be quota enabled. Calculate and assign a workable quota size for those partitions and directories which combines usability and security.
Ahora que usted quiere usar quotas. Primero que todo usted necesita revisar que habilito el uso de quotas en el kernel. Si no, usted necesitará recompilarla. Después de ésto dése cuenta que el paquete 'quota' esté instalado. Si no está usted necesitará este.
Habilitar la quota para los respectivos sistemas de archivos es tan fácil como modificar la configuración
inicial ajustándola a
defaults,usrquota en su archivo
/etc/fstab . Si usted necesita un quota para grupos, sustituya
usrquota por
grpquota. Puede usar ambos. Luego cree unos archivos quota.user y quota.group vacios en la raíz de los sistemas de archivos en los que usted quiera usar quotas (Ej. con
touch /home/quota.user /home/quota.group para el sistema de archivos
/home).
touch
/home/quota.user /home/quota.group
for a
/home file system).
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 can be done by
edquota -u <user>
. Group quotas can be modified with
edquota -g <group>
. Then set the soft and hard quota and/or inode quotas as needed.
Para más información acerca de las quotas, lea el manual de páginas sobre las quotas, y el mini-howto (/usr/share/doc/HOWTO/en-html/mini/Quota.html).
4.17.2. The ext2 filesystem specific attributes (chattr/lsattr)
In addition to the usual Unix permissions, the ext2 and ext3 filesystems offer a set of specific attributes that give you more control over the files on your system. Unlike the basic permissions, these attributes are not displayed by the usual ls -l command or changed using chmod, and you need two other utilities, lsattr and chattr (in package e2fsprogs) to manage them. Note that this means that these attributes will usually not be saved when you backup your system, so if you change any of them, it may be worth saving the successive chattr commands in a script so that you can set them again later if you have to restore a backup.
Among all available attributes, the two that are most important for increasing security are referenced by the letters 'i' and 'a', and they can only be set (or removed) by the superuser:
The 'i' attribute ('immutable'): a file with this attribute can neither be modified nor deleted or renamed and no link can be created to it, even by the superuser.
The 'a' attribute ('append'): this attribute has the same effect that the immutable attribute, except that you can still open the file in append mode. This means that you can still add more content to it but it is impossible to modify previous content. This attribute is especially useful for the log files stored in /var/log/, though you should consider that they get moved sometimes due to the log rotation scripts.
These attributes can also be set for directories, in which case everyone is denied the right to modify the contents of a directory list (e.g. rename or remove a file, ...). When applied to a directory, the append attribute only allows file creation.
It is easy to see how the 'a' attribute improves security, by giving to programs that are not running as the superuser the ability to add data to a file without modifying its previous content. On the other hand, the 'i' attribute seems less interesting: after all, the superuser can already use the basic Unix permissions to restrict access to a file, and an intruder that would get access to the superuser account could always use the chattr program to remove the attribute. Such an intruder may first be confused when noticing not being able to remove a file, but you should not assume blindness - after all, the intruder got into your system! Some manuals (including a previous version of this document) suggest to simply remove the chattr and lsattr programs from the system to increase security, but this kind of strategy, also known as "security by obscurity", is to be absolutely avoided, since it provides a false sense of security.
A secure way to solve this problem is to use the capabilities of the Linux kernel, as described in
Sección 10.4.2.1, “Defensa proactiva.”. The capability of interest here is called
CAP_LINUX_IMMUTABLE: if you remove it from the capabilities bounding set (using for example the command
lcap CAP_LINUX_IMMUTABLE) it won't be possible to change any 'a' or 'i' attribute on your system anymore, even by the superuser ! A complete strategy could be as follows:
Set the attributes 'a' and 'i' on any file you want;
Set the 'i' attribute on this script and other startup files, as well as on the lcap binary itself;
Execute the above command manually (or reboot your system to make sure everything works as planned).
Now that the capability has been removed from the system, an intruder cannot change any attribute on the protected files, and thus cannot change or remove the files. If the machine is forced to reboot (which is the only way to restore the capabilities bounding set), it will easily be detected, and the capability will be removed again as soon as the system restarts anyway. The only way to change a protected file would be to boot the system in single-user mode or using another bootdisk, two operations that require physical access to the machine !
4.17.3. Integridad de su sistema de archivos
¿Está usted seguro de que el /bin/login en su disco duro es todavía el binario que instaló allí hace unos meses? ¿Qué pasaría si es una versión hackeada, que guarda la contraseña introducida en un archivo oculto o la envía por un correo claro pro todoel internet?
El único método para tener alguna protección es comprobar sus archivos cada día/hora/mes (yo prefiero cada día) comparando la vieja md5sum y la actual. Dos archivos no pueden tener la misma md5sum, de modo que anda sobre seguro aquí, excepto alquien que hackeó el algoroitmo para crear md5sums un la máquina. Esto es bueno, extremadamente difícil y muy improbable. Realmente usted debería considerar que auditar sus binarios es muy importante, ya que es un modo fácil para reconocer los cambios en sus binarios. Las herramientas que comúnmente se uaan para ésto son sXid, AIDE (Ambientación Avanzada de Detección de Intrusos), TripWire (no es libre; la nueva versió será GPL), integrit y samhain.
Common tools used for this are
sxid,
aide (Advanced Intrusion Detection Environment),
tripwire,
integrit and
samhain. Installing
debsums will also help you to check the file system integrity, by comparing the md5sums of every file against the md5sums used in the Debian package archive. But beware: those files can easily be changed by an attacker and not all packages provide md5sums listings for the binaries they provided. For more information please read
Sección 10.2, “Do periodic integrity checks” and
Sección 4.19, “Taking a snapshot of the system”.
You might want to use locate to index the whole filesystem, if so, consider the implications of that. The Debian findutils package contains locate which runs as user nobody, and so it only indexes files which are visible to everybody. However, if you change it's behaviour you will make all file locations visible to all users. If you want to index all the filesystem (not the bits that the user nobody can see) you can replace locate with the package slocate. slocate is labeled as a security enhanced version of GNU locate, but it actually provides additional file-locating functionality. When using slocate, the user only sees the actually accessible files and you can exclude any files or directories on the system. The slocate package runs its update process with higher privledges than locate, and indexes every file. Users are then able to quickly search for every file which they are able to see. slocate doesn't let them see new files; it filters the output based on your UID.
You might want to use bsign or elfsign. elfsign provides an utility to add a digital signature to an ELF binary and a second utility to verify that signature. The current implementation uses PKI to sign the checksum of the binary. The benefits of doing this are that it enables one to determine if a binary has been modified and who created it. bsign uses GPG, elfsign uses PKI (X.509) certificates (OpenSSL).
4.17.4. Configuración de revisión de setuid
The Debian
checksecurity package provides a
cron job that runs daily in
/etc/cron.daily/checksecurity. This
cron job will run the
/usr/sbin/checksecurity script that will store information of this changes.
El comportamiento por defecto no manda la información al superusuario, pero en cambio guarda diariamente copias de los cambios dentro de /var/log/setuid.changes. Usted debe colocar el CHECKSECURITY_EMAIL (dentro de /etc/checksecurity.conf) a 'root'. Mire checksecurity(8) para mas información de configuración.
