Reforzando la instalación de Debian GNU/Linux

ArCERT
Coordinación de Emergencias en Redes Teleinformáticas
www.arcert.gov.ar
versión 2.0

16 de marzo de 2006

Resumen
En este documento describiremos como mejorar la seguridad en una instalación de GNU/Linux. El temario
incluye configuración adecuada del BIOS, particionamiento, instalación minima, deshabilitación de servicios no
utilizados, desinstalación de software no utilizado, revisión de logs, detección de intrusiones, firewall de host,
actualizaciones de seguridad, sincronización de hora, etc. Utilizaremos como base la distribución Debian, versión
Sarge (o stable). Muchos de los conceptos vertidos en esta guı́a podrán ser aplicados a cualquier distribución de
Linux, o sistema operativo tipo Unix (*BSD, Solaris, etc.).
En ningún caso podrá responsabilizarse a ArCERT o a la ONTI en forma institucional, o a sus agentes a tı́tulo
individual y/o personal, de ningún daño puntual ni general, directo o indirecto, consecuencial o incidental, o de
cualesquiera otra categorı́as, derivado de la ejecución de las actividades planteadas para este tutorial.
 Reforzando la instalación de Debian GNU/Linux

Índice
1. Introducción 3

2. Pre-Instalación 3

3. Instalación 3
3.1. Particiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. El usuario normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4. Boot Loader 6

5. Limpieza 8
5.1. Servicios de red innecesarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Otros paquetes no utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Módulos de Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6. Deshabilitando el CTRL-ALT-Del 10

7. Opciones de Montaje 11

8. Usuarios y permisos 11
8.1. Usuarios con shell interactı́vo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. El bit SUID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.3. Permisos de tareas planificadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.4. Sudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

9. Limitación del acceso de root 13

9.1. El grupo wheel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.2. La consola fı́sica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.3. Acceso vı́a SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

10. Administración Remota 14

11. Parámetros del kernel 15

12. Selección de paquetes 15

13. Firewall 16

14. Actualizaciones de seguridad 16

15. Mantenimiento 17
15.1. Sincronización horaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
15.2. Back-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
15.3. Auditorı́as regulares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
15.4. Chequeos de integridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
15.5. Manejo de bitácoras (logs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

16. Herramientas para automatizar el fortalecimiento 20

16.1. Bastille Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
16.2. Paquetes Harden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

17. Otras fuentes de información 21

18. CheckList 21

www.arcert.gov.ar 2 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

1. Introducción
¿Por qué necesitamos reforzar la instalación de un sistema operativo? Salvo raras excepciones1 , los sistemas
operativos en general no dedican un gran esfuerzo en la seguridad al momento de la instalación. ¿Y cuál es el
resultado de este hecho? Con el crecimiento que ha tenido Internet en los últimos años, la ventana de tiempo entre
que un sistema operativo recién instalado (sin parches) se conecta a Internet, y que el mismo sufre una intrusión,
ha bajado de dı́as a mediados de los 90’, a horas en el 2000, y minutos en la actualidad. En este documento nos
ocuparemos de mejorar la seguridad en una instalación de GNU/Linux. Utilizaremos como base la distribución
Debian, versión Sarge (o stable), por ser una de las más usadas en ambientes de servidor, y porque la consideramos
como una de las más adecuadas para esa misma función. Muchos de los conceptos vertidos en esta guı́a podrán ser
aplicados a cualquier distribución de Linux, o sistema operativo tipo Unix (*BSD, Solaris, etc.). Sin embargo, se
deberán tomar los recaudos necesarios para que dicha adaptación no deje puertas abiertas debido a las diferencias
entre las distintas distribuciones.

2. Pre-Instalación
Comenzaremos por considerar dos temas esenciales. Se dice que quien tiene acceso fı́sico a un equipo tendrá ac-
ceso total al mismo. Si bien ésta afirmación no siempre es exacta, y algunas de las tareas que realizaremos tienen
por objetivo contrarrestarla, es absolutamente recomendable que el acceso fı́sico al servidor y su consola esté res-
tringido sólo al personal autorizado. Como segundo recaudo, el equipo no deberá conectarse a la red hasta haber
finalizado con las tareas de aseguramiento. En caso de ser necesario algún tipo de conexión (como ser que el equipo
debe iniciarse mediante netboot), estas tareas deberán realizarse en una red cerrada, asegurada, y preferentemente
aislada. Antes de realizar la instalación del sistema operativo elegido, hay algunas tareas que podemos realizar.
En particular, mediante la configuración del BIOS del equipo en cuestión, podremos restringir algunos puntos de
entrada que no sean necesarios para la operatoria normal del sistema. Entre otros, podemos nombrar los siguientes.
Puertos paralelos

Puertos seriales

Puertos USB

Disqueteras

Lectoras de CD/DVD

En la Figura 1 podemos observar un ejemplo de cómo se deshabilitan algunos puertos innecesarios en el BIOS.
Otra tarea importante consiste en configurar el orden de selección de dispositivos para el boot del equipo. Para
poder realizar la instalación, deberemos seleccionar el medio disponible para la misma, normalmente CD-ROM,
pero una vez finalizada la misma, deberemos seleccionar únicamente el disco de arranque del sistema. En caso de
no ser posible, como en el ejemplo de la Figura 2, deberemos ordenar los dispositivos para que el elegido sea el
primero de la lista. Inclusive podemos deshabilitar todos los dispositivos de almacenamiento menos el dispositivo
de boot. Por ejemplo, una vez instalado el sistema operativo, se puede deshabilitar el CD-ROM del BIOS, ya que
el mismo será detectado de todas maneras por el sistema operativo.
Por último, deberemos configurar una contraseña para restringir la realización de cambios en la configuración
del BIOS.

3. Instalación
Para realizar un buen proceso de aseguramiento de un servidor GNU/Linux Debian, incluiremos su instalación.
Durante el proceso de instalación, cuya descripción completa puede encontrarse en la bibliografı́a, deberemos tener
en cuenta algunos detalles que nos permitirán asegurar un resultado exitoso.
1 Por ejemplo, OpenBSD. http://www.openbsd.org

www.arcert.gov.ar 3 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

Figura 1: Deshabilitación de puertos y periféricos

Figura 2: Deshabilitación de puertos y periféricos

www.arcert.gov.ar 4 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

Figura 3: Opciones de montaje durante la instalación

3.1. Particiones
En primer lugar, deberemos diseñar cuidadosamente el sistema de archivos. No existe una regla general, pero
podemos seguir algunos consejos para mejorar tanto la seguridad como el rendimiento. Algunos de estos consejos
consisten en:
Si el sistema va a alojar múltiples usuarios interactivos, /home deberı́a tener su propia partición.
En equipos que brinden servicios crı́ticos, /var/log podrı́a llenarse y perjudicar el buen funcionamiento
de los mismos, por lo que podrı́a separarse en otra partición .
Por esta misma razón, /tmp utilizará una partición separada.
En general, /var (pensado para todas las operaciones más dinámicas) y /usr (donde normalmente se
alojan los archivos menos susceptibles a cambios) tendrán su propio espacio.
Las particiones pueden montarse con ciertas opciones que restringen su funcionalidad (ver Figura 3). Las
restricciones más interesantes que pueden aplicarse en el momento de la instalación son (hablaremos más
tarde sobre esto en ’Opciones de Montaje’):
• nodev: No permite la creación de dispositivos (devices).
• nosuid: No permite la utilización de los bits suid y sgid.
• noexec: No permite la ejecución de archivos
En general, podemos definir que:
En ninguna partición, salvo / (o donde resida /dev), se necesitan dispositivos.
/, /usr y /var, en general, son las únicas particiones desde las cuales se deberı́a poder ejecutar archivos.
Además, sólo /usr y /var pueden necesitar el uso de suid. Estas restricciones pueden y suelen variar
según las diferentes distribuciones de GNU/Linux.

www.arcert.gov.ar 5 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

Figura 4: Esquema de particiones que propuesto para Multi-user workstation

En algunos casos puede ser recomendable montar /usr como ro (sólo lectura), pero habilitar esta opción
durante la instalación hará que ésta sea imposible de realizarse, ya que habrá que escribir en dicha partición.
Evitar la ejecución de binarios en /tmp con la opción noexec es una buena idea. Pero hay que tener en
cuenta que, en algunos casos, Debian ejecutará ahı́ algunas acciones cuando instala paquetes.
En nuestro ejemplo usaremos el esquema de la Figura 4, que es la distribución propuesta por Debian para
Multi-user workstation (estación de trabajo multiusuario).

3.2. El usuario normal

Como veremos más adelante(véase también ’Limitación del acceso de root’), el acceso al sistema como usuario
root estará muy restringido, por lo que la instalación es el momento correcto para la creación de, al menos, un
usuario no privilegiado. En nuestro ejemplo usaremos operador, tal como se ve en la Figura 5. Se debe evitar la
existencia de cuentas impersonales, por lo que el campo full-name (nombre completo) puede sernos de utilidad. El
usuario no privilegiado, además de darnos el acceso inicial al sistema, nos permitirá realizar todas aquellas tareas
que no requieran extricamente capacidades de root.
Una vez terminada la instalación del sistema operativo base, comenzaremos el fortalecimiento propiamente
dicho del sistema. Si aún no modificó el orden de boot en el BIOS, este el momento.

4. Boot Loader
Vamos a asegurar el boot loader, en nuestro caso el grub, que es el programa encargado de cargar el kernel en
memoria y ejecutarlo. Para evitar que alguien con acceso fı́sico a la consola de nuestro equipo (situación que deber
ser evitada a toda costa) pueda modificar los parámetros de inicialización del kernel, protegeremos el boot loader
contra modificaciones.
Primero, generaremos un hash del pasword que utilizaremos:

www.arcert.gov.ar 6 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

Figura 5: Creación de un usuario no privilegiado

debian:˜# grub-md5-crypt
Password:
Retype password:
$1$1nxTK1$0kdd0C8txj7nDPx5SnVx./

Una vez obtenido el hash, procederemos a insertarlo en la siguiente lı́nea en el archivo /boot/grub/menu.lst:

## password [’--md5’] passwd

# e.g. password topsecret
# password --md5 $1$gLhU0/$aW78kHK1QfV3P2b2znUoe/
# password topsecret
password --md5 $1$1nxTK1$0kdd0C8txj7nDPx5SnVx./

En este mismo archivo, editaremos el valor de la variable lockalternative, para que el password que
acabamos de crear no sólo se aplique a las modificaciones explı́citas de los parámetros de inicio del kernel, sino
que además sea necesaria para iniciar el sistema en modo single user, también conocido como Recovery Mode.

## should update-grub lock alternative automagic boot options

## e.g. lockalternative=true
## lockalternative=false
# lockalternative=true

Por otro lado, hay que modificar los permisos de /boot/grub/menu.lst para evitar que los usuarios no
privilegiados accedan al hash:

debian:˜# chmod o-r /boot/grub/menu.lst

Para completar este proceso, deberemos ejecutar el comando update-grub y ası́ hacer efectivo el cambio
del lockalternative:

debian:˜# update-grub
Searching for GRUB installation directory ... found: /boot/grub .
Testing for an existing GRUB menu.list file... found: /boot/grub/menu.lst .
Found kernel: /boot/vmlinuz-2.6.8-2-686
Updating /boot/grub/menu.lst ... done

www.arcert.gov.ar 7 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

5. Limpieza
Para continuar con la configuración del equipo vamos a minimizar la instalación, desintalando paquetes que no
se utilicen, cerrando servicios de red, y optimizando la carga de módulos del kernel.

5.1. Servicios de red innecesarios

Muchas distribuciones instalan servicios que abren puertos de red. Debian Sarge (no ası́ versiones anteriores)
instala pocos de estos, por lo que no nos atendremos al ejemplo. Para ver que procesos levantan puertos podemos
correr el comando netstat -tulp:

debian:˜# netstat -tulp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 *:time *:* LISTEN 608/inetd
tcp 0 0 *:discard :
* * LISTEN 608/inetd
tcp 0 0 *:daytime *:* LISTEN 608/inetd
tcp 0 0 localhost:smtp :
* * LISTEN 602/exim4
udp 0 0 *:discard *:* 608/inetd
udp 0 0 *:bootpc *:* 708/dhclient
debian:˜#

Como podemos observar, los servicios time, discard y daytime se encuentran habilitados y levantados vı́a inetd.
Para deshabilitarlos, procederemos a editar el archivo /etc/inetd.conf, y comentar las lı́neas correspondientes. Los
cambios se producirán al reiniciar el servicio.

debian:˜# /etc/init.d/inetd restart

Restarting internet superserver: inetd.

Por otra parte existen servicios no levantados por inetd que seguramente podremos eliminar (aunque esté escu-
chando sólo en localhost), como el caso de exim4 si no necesitamos un MTA2 :

apt-get remove --purge exim4-config exim4-base

Esto borrará la configuración y los paquetes relacionados con exim4, ası́ como sus dependencias reversas.
Por último, bootpc corresponde al cliente DHCP. No se aconseja que los servidores obtengan su configuración
de red vı́a DHCP. Puede borrarse eliminando el paquete dhcp-client.
Ası́ se debe proceder con cada uno de los servicios de red que tenga el sistema y que no sean necesarios.

5.2. Otros paquetes no utilizados

La instalación base de cualquier sistema operativo instala una serie de paquetes que, si bien son utilizados en la
mayorı́a de los casos, no siempre son totalmente necesarios. Podemos ver todos los paquetes instalados en nuestro
sistema ası́:

dpkg -l | more

Esto mostrará una larga lista (paginada con more) con el nombre del paquete, su versión y una breve descrip-
ción, tal como se ve en la Figura 6.
Como verán, los paquetes son muchos y muy variados. Deberemos utilizar nuestra experiencia e imaginación
para detectar los paquetes innecesarios de esta larga lista, siguiendo algunas reglas de sentido común. Por ejemplo:

Si sólo vamos a utilizar ethernet, todos los paquetes que tengan que ver con PPP3 no serán necesarios (ppp,
pppconfig, pppoe, pppoeconf).

En general, los paquetes de internacionalización son innecesarios (locales).

2 Mail Transport Agent (Agente de Transporte de Correos). Sistema para envio de correo electronico
3 Point-to-Point Protocol (Protocolo punto a punto)

www.arcert.gov.ar 8 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

Figura 6: Listado de los paquetes instalados (dpkg -l)

Los paquetes para desarrollo como los compiladores o intérpretes (perl, gcc) y las bibliotecas terminadas
en -dev sólo son utilizados en casos particulares, por lo que pueden borrarse.
La automatización de detección de hardware nomalmente no es necesaria, y hasta puede ser perjudicial
(hotplug, discover1-data). En caso de desinstalarlos, tendremos que prestar particular atención a la
subsección ’Módulos de Kernel’.
Los paquetes relacionados con dispositivos que no tenemos o no utilizamos son prescindibles (usbutils,
eject, setserial, fdutils)
Los programas que no utilizamos pueden borrarse (aptitude, info, ipchains, mailx, nano, telnet,
makedev)
Las bibliotecas usadas por los paquetes que borramos tampoco son necesarias (libdiscover1,libusb).
Para identificar estas bibliotecas nos puede ser de utilidad un paquete llamado deborphan4 .
Un punto importante es evitar borrar paquetes de tipo essential. Estos paquetes son, por lo general, necesarios para
el correcto funcionamiento del sistema operativo y requieren una confirmación particular.
Puede ocurrir que encontremos archivos de los que desconocemos el paquete que los instaló. Para esto puede
ser útil el comando dpkg -S. Por ejemplo, el archivo /usr/bin/e2pall pertenece al paquete tetex-bin:
debian:˜# dpkg -S /usr/bin/e2pall
tetex-bin: /usr/bin/e2pall
Una mención especial merece el paquete gcc-3.3-base, que sólo contiene documentación descriptiva y se
incluye únicamente por razones de dependencias de paquetes, por lo que puede ser conservado sin mayores pro-
blemas.
El siguiente paso será desinstalar los paquetes seleccionados. Para ello, utilizaremos el siguiente comando:
debian:˜# apt-get remove --purge aptitude dhcp-client [...]
Ası́ se eliminará tanto los paquetes como sus archivos de configuración, esto último gracias al modificador
--purge. Estemos atentos a la lista de paquetes que realmente se van a remover ya que también se borran
aquellas dependencias reversas de los paquetes definidos.
De esta manera, reducimos la cantidad de programas instalados en nuestro sistema, lo que se traduce en una
menor probabilidad de vernos afectados por algún bug.
4

www.arcert.gov.ar 9 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

Figura 7: Listado de los módulos cargados (lsmod)

5.3. Módulos de Kernel

Los módulos le dan flexibilidad al kernel, levantando drivers sin necesidad de reinicios. Evitar levantar aquellos
módulos que no utilizemos puede, además de evitar los efectos de sus bugs, incrementar la velocidad de arranque.
Las aplicaciones de detección automática de hardware cargan módulos en forma dinámica cuando son necesarios.
Para ver los que están actualmente cargados en el sistema puede emplear el comando lsmod y obtendrá un
resultado semejante al de la Figura 7.
Recordemos que en la subseccion ’Otros paquetes no utilizados’ se propuso eliminar todos los paquetes que
detectan hardware, como discover1, por lo que tendremos que forzar la carga de los drivers que utiliza nuestro
hardware para funcionar y que antes se detectaban automáticamente.
Para esto necesitaremos editar el archivo /etc/modules. Aquı́ podremos agregar los módulo que necesite-
mos levantar (la placa de red, por ejemplo) y eliminar aquellos que no sean necesarios, como ide-cd y psmouse.
En nuestro ejemplo el archivo quedarı́a ası́, siendo pcnet32 el driver de la placa de red:
ide-disk
ide-generic
pcnet32

Para cerciorarnos de que se levanta todo lo necesario al arrancar, podemos reiniciar el sistema y comprobarlo.
Hay que tener en cuenta que existen muchas aplicaciones que levantan módulos por demanda. Por ejemplo
ipv6, que es el soporte para IP versión 6, puede ser levantado por demonios que intenten escuchar en una intefaz
IPv6. Este es el caso de SSH que por defecto levantará con este soporte. Para evitar esto puede configurar estas
aplicaciones para que sólo utilizen IPv4, o bien, eliminar la posibilidad que el módulo ipv6 se cargue. Ésto último
se consigue realizando la siguente modificación en /etc/modprobe.d/aliases:

#alias net-pf-10 ipv6

alias net-pf-10 off

6. Deshabilitando el CTRL-ALT-Del
Este método de reinicializar el equipo siempre ha sido útil y atractivo en GNU/Linux, pero posiblemente no
queremos que cualquiera con acceso a la consola puede utilizarlo. Vamos a deshabilitarlo comentando la lı́nea
correspondiente en el archivo /etc/inittab:

www.arcert.gov.ar 10 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

# What to do when CTRL-ALT-DEL is pressed.

#ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

Sólo resta avisarle al proceso init que debe releer el archivo de configuración:

debian:˜# telinit q

O su equivalente,

debian:˜# kill -1 1

7. Opciones de Montaje
Las particiones realizadas en la seccion ’Instalación’ nos permiten montar los sistemas de archivos con dis-
tintas opciones, algunas de las cuales vimos en aquel apartado. La lista de particiones a montar se encuentra en
/etc/fstab. Si seleccionamos las opciones de nodev, nosuid y noexec durante la instalación el archivo que-
dará algo ası́:

# <file system> <mount point> <type> <options> <dump> <pass>

proc /proc proc defaults 0 0
/dev/sda1 / ext3 nosuid,errors=remount-ro 0 1
/dev/sda8 /home ext3 nodev,nosuid,noexec 0 2
/dev/sda7 /tmp ext3 nodev,nosuid 0 2
/dev/sda5 /usr ext3 nodev 0 2
/dev/sda6 /var ext3 nodev 0 2
/dev/sda9 none swap sw 0 0
/dev/hdc /media/cdrom0 iso9660 ro,user,noauto 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0

Si no utilizaremos el CD-ROM o la disquetera, podemos eliminar las últimas dos lı́neas de este archivo. Pero si
decidimos conservar alguna de las dos, al menos deberemos eliminar la opción user, que cumple la función de
permitir a un usuario no privilegiado montar y desmontar dicho dispositivo.
Otras opciones útiles pueden ser (para más información, man mount):

sync: Todas las operaciones de I/O5 se hace de forma sincrónica.

defaults: Son las opciones por defecto, es decir: rw, suid, dev, exec, auto, nouser, y async.

auto: Monta el sistema de archivos al inicio.

8. Usuarios y permisos
8.1. Usuarios con shell interactı́vo
Comenzaremos por revisar los usuarios creados durante el proceso de instalación. Para esto tenemos que ana-
lizar el archivo /etc/passwd, como se ve en la Figura 8.
Como podemos observar, existen varios usuarios, todos considerados del sistema (en el caso de Debian, se
caracterizan por tener un user id menor que 1000), que poseen como shell a /bin/sh, siendo esto totalmente
innecesario dado que ninguno de estos usuarios será utilizado de manera interactiva. Utilizaremos el siguiente
comando para modificar esta situación:

debian:˜# chsh -s /bin/false daemon

Y ası́ para cada uno de los usuarios no interactivos; en este caso root y operador son la obvia excepción. El
comando /bin/false siempre devuelve error y evita el login.
5 Input/Output (operaciones de Entrada/Salida)

www.arcert.gov.ar 11 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

Figura 8: Usuarios del sistema (/etc/passwd)

8.2. El bit SUID

Vamos a revisar algunos permisos importantes en los archivos. Uno de los principales peligros que encontramos
en los permisos de los archivos ejecutables es el suid bit, que permite a cualquier usuario que tenga permiso de
ejecución sobre este archivo, ejecutarlo como si realmente fuese el usuario dueño del archivo, en lugar de él mismo.
Un problema muy común, es que un programa comúnmente utilizado por los usuarios tenga como dueño a root,
y tenga prendido el bit suid. Si este programa llegase a tener un bug, por ejemplo un buffer overflow o un stack
overflow, podrı́a llegar a convertirse en la herramienta que necesita un posible atacante que haya logrado ingresar
al sistema para convertirse en root. También existe el bit guid que es lo mismo, pero aplicado al grupo.
Los archivos con este permiso pueden ser encontrados ası́ (Figura 9):
debian:˜# find / -path /proc -prune -o -type f -perm +6000 -ls

De toda la lista de archivos con este particular permiso sólo son totalmente necesarios algunos de ellos:

passwd: para que los usuarios puedan cambiar su password.

exim4: para el correcto funcionamiento del e-mail interno, si es que decidimos no borrarlo del sistema.

login: para que los usuarios puedan ingresar al sistema.

unix chkpwd: se utiliza para que los programas puedan verificar el password ingresado por el usuario, sin la
necesidad de tener cada uno el bit suid.

su: para que usuarios no privilegiados puedan convertirse en root.

Para el resto de los programas no es extrictamente necesario este permiso, salvo en casos particulares en los que
habrá que evaluar los beneficios y desventajas (por ejemplo, el uso de crontabs por parte de los usuarios). Para el
resto:

debian:˜# chmod ug-s /usr/bin/wall /usr/bin/newgrp /usr/bin/chsh [...]

8.3. Permisos de tareas planificadas

Si bien ya anteriormente le sacamos el bit suid al programa crontab, no estará de más restringir qué usuarios
pueden tener acceso a su uso. Para esto debemos crear el archivo /etc/cron.allow con una única lı́nea:

www.arcert.gov.ar 12 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

Figura 9: Archivos con el bit suid y guid (find / -path /proc -prune -o -type f -perm +6000
-ls)

root

Si este archivo existe, sólo los que estén listado en él podrán usar cron.
El comando at, utilizado para la ejecución diferida de tareas, es un caso muy similar al de cron. El archivo
/etc/at.allow se utiliza limitar su uso y su funcionamiento es identico a /etc/cron.allow.

8.4. Sudo
Una herramienta que permite tener un control mucho más estricto sobre las tareas que realizan los usuarios que
requieran privilegios administrativos es sudo. Con esta herramienta podremos configurar, entre otras cosas:

Qué usuarios pueden elevar sus privilegios (o simplemente ejecutar acciones como otros usuarios).

Qué tareas pueden realizar.

Si necesitan ingresar un password, y si es el suyo propio o el del usuario impersonado.

Restricciones horarias.

Lugar desde donde está conectado el usuario.

Registro de las acciones realizadas.

Sudo es una herramienta versátil y bien documentada. Se puede encontrar más ejemplos y detallada información
en la página principal de sudo6 .

9. Limitación del acceso de root

La idea es evitar el login directo de root. Es decir, para acceder al sistema tendremos que ingresar como un
usuario no privilegiado y después convertirnos en root mediante el comando su. Además serı́a interesante restringir
los usuarios que podrán transformarse en superusuario.
6 http://www.gratisoft.us/sudo/

www.arcert.gov.ar 13 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

9.1. El grupo wheel

Existe una forma de limitar qué usuarios pueden ejecutar el comando su. Para esto debemos editar el archivo
/etc/pam.d/su y habilitar la siguiente opción:

# before they can use ‘su’. You can also add "group=foo" to
# to the end of this line if you want to use a group other
# than the default "root".
# (Replaces the ‘SU_WHEEL_ONLY’ option from login.defs)
auth required pam_wheel.so

Ahora sólo los usuarios que pertenezcan al grupo wheel podrán utilizar el comando su. No debemos olvidarnos
de crear el grupo y agregar los usuarios necesarios al mismo:
debian:˜# addgroup --system wheel
Adding group ‘wheel’ (104)...
Hecho.
debian:˜# usermod -G wheel operador

9.2. La consola fı́sica

Esta es otra forma de mitigar una falencia en el acceso fı́sico al servidor. Se puede evitar que root acceda
directamente por una consola fı́sica al sistema. En el archivo /etc/securetty tenemos la lista de consolas en
las que root puede loguearse. Podemos simplemente comentar dichas lineas y ası́ restringir el acceso.

9.3. Acceso vı́a SSH

Si en nuestro sistema está instalado SSH como forma de administración remota (véase también ’Adminis-
tración Remota’), también debemos limitar el acceso directo de root. Para lograrlo hay que editar el archivo de
configuración de ssh en /etc/ssh/sshd config:

PermitRootLogin no

Recordemos que hay que reiniciar el servicio de SSH para que esto tenga efecto.

debian:˜# /etc/init.d/ssh restart

De esta manera, para acceder remotamente al equipo deberemos utilizar algún otro usuario.

10. Administración Remota

Vamos a suponer que es necesario acceder remotamente al equipo para su administración. Seguramente el
protocolo elegido será SSH7 . Habrá que instalar OpenSSH, que en la versión Sarge de Debian viene el servidor
junto con el cliente.

debian:˜# apt-get install ssh

Durante su instalación, deberemos responder algunas preguntas. La primera es sobre la versión de SSH a ejecutar.
Elegimos sólo permitir la versión 2 del protocolo, ya que las versiones anteriores tienen importantes defectos de
diseño que pueden comprometer la seguridad del equipo. La siguiente pregunta nos consulta sobre el bit suid en
el programa ssh-keysign. Por un lado, no utilizaremos el método de autenticación basada en host, y por otro,
intentamos evitar el uso de este bit, por lo que elegimos la opción no. La última pregunta es sobre si queremos
iniciar el servidor de SSH.
Será conveniente restringir desde dónde se puede acceder a dicho protocolo. Más allá del uso de un firewall lo
haremos vı́a tcpwrapper, soportado por OpenSSH. Usaremos la polı́tica todo denegado excepto lo expresamente
permitido. En el archivo /etc/hosts.deny:
7 Secure SHell: Protocolo que brinda, entre otras cosas, acceso remoto seguro a un shell

www.arcert.gov.ar 14 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

sshd : ALL
Y en /etc/hosts.allow, las IPs o redes de las cuales permitimos el acceso:
sshd : 192.168.31.0/24
Este método también puede utilizarse con cualquier servicio que utilice la librerı́a libwrap (hoy incluida en la libC),
o mediante la utilización del programa tcpd.

11. Parámetros del kernel

El kernel es configurable desde /etc/sysctl.conf, donde se pueden ajustar varios parámetros. Veamos
algunos de ellos8 :
# Ignorar el uso de la tecla "Petición de sistema"
kernel.sysrq=0
# Normalmente, no hay razón para utilizar broadcasts ICMP
net.ipv4.icmp_echo_ignore_broadcasts=1
# Tampoco debemos hacerle caso a respuestas ICMP que no
# pedimos
net.ipv4.icmp_ignore_bogus_error_responses=1
# Los ICMP redirects son necesarios en escasas
# excepciones (por ejemplo, cuando hay 2 gateways)
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
# Tampoco aceptamos paquetes con "source route"
net.ipv4.conf.all.accept_source_route=0
net.ipv4.conf.default.accept_source_route=0
Y para hacer efectivos los cambios inmediatamente:
debian:˜# sysctl -p

12. Selección de paquetes

En esta etapa debemos tener en especial consideración que fines va a cumplir el equipo, y seleccionar el
software a instalar en consecuencia. La principal sugerencia para esta etapa consiste en instalar únicamente el
software estrictamente necesario.
Por ejemplo, en este caso utilizaremos el equipo como servidor Web. ¿Que tipo de servidor Web? Supongamos
que sólo necesitamos un servidor Web con páginas estáticas. ¿Es necesario instalar un Apache con PHP? La
respuesta claramente es no. De hecho no sólo no vamos a necesitar PHP, sino que posiblemente ni siquiera sea
Apache la mejor opción.
Veamos algunos puntos a tener en cuenta para elegir una aplicación:
Mientras menos cosas extra tenga la aplicación, mejor. Siguiendo con el ejemplo de un servidor de web de
páginas estáticas, existen alternativas como thttpd (que tiene soporte para CGI9 ) o dhttpd. Programas más
chicos suponen menos lı́neas de código donde existe una probablididad menor de que alla bugs.
Priorizemos las aplicaciones de red que puedan ser enjauladas fácilmente dentro de un chroot.
Hay que tener en cuenta que tan mantenido está el programa. Se puede consultar en foros y listas en busca
de opiniones. En el caso de Debian podemos visitar http://packages.qa.debian.org/<nombre del paquete>
para ver cada cuanto hay nuevas versiones y sus bugs.
La escalabilidad debe ajustarse a nuestras necesidades de crecimiento. Si prevemos aumentar la carga de una
aplicación en un futuro cercano ésta debe soportarla de antemano.
8 Puede encontrar otros parámetros en http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html
9 Common Gateway Interface (Pasarela de Interfaz Común)

www.arcert.gov.ar 15 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

La interoperabilidad con otras aplicaciones semejantes son puntos importantes para no quedar atado a una
aplicación. Va a ser necesario que maneje formatos y protocolos internos que sean estandares o de fácil
migración a otros formatos.

Una vez seleccionada la aplicación es recomendable seguirle los pasos de cerca en cuanto a sus nuevas versio-
nes y bugs. Si la aplicación es un paquete Debian puede subscribirse a PTS10 . También es buena idea subscribirse
a la lista de los desarrolladores si ésta fuera pública.

13. Firewall
El servidor deberá estar operativo en una zona particular de la red, comúnmente llamada DMZ11 cuando se
trate de servicios externos, que será la única zona que recibirá conexiones desde afuera. Para restringir el acceso
suele usarse un firewall.
Pero además, cada host de nuestra red deberá tener un firewall propio, muchas veces llamado firewall de host.
Como en todas las instalaciones de GNU/Linux, la herramienta utilizada para filtrar los paquetes de red en el host
será iptables.
Para facilitar la configuración, una opción es utilizar la herramienta shorewall, que si bien los ejemplos están
pensados para un firewall en el sentido clásico (un gateway con filtrado de paquetes en modo stateful), es perfec-
tamente adaptable al uso como firewall de host. También puede usarse fwbuilder, que es una herramienta gráfica
para generar las reglas de iptables.
Algunas recomendaciones a la hora de configurar el firewall:

Permitir conexiones de entrada sólo a los puertos que tengan servicios publicos y que provengan de clientes
en las redes que correspondan (por ejemplo, restringir el acceso desde otras máquinas de la DMZ, si el
servicio es para Internet).

Permitir la salida a Internet sólo a los sitios necesarios para la actualización del equipo y los servicios que
ası́ lo requieran, como conexiones al puerto smtp desde los servidores de correo electrónico. En algunos
casos se puede poner un servidor de actualizaciones interno (con apt-proxy, por ejemplo), de manera que
sólo éste requiera salida.

Permitir la salida a otras máquinas de la DMZ sólo cuando sea para un servicio interno particular (por
ejemplo, a una base de datos).

14. Actualizaciones de seguridad

Ahora que ya tenemos el sistema medianamente asegurado, es el momento de actualizar los paquetes instalados.
Editemos /etc/apt/sources.list que es el archivo que indica dónde encontrar dichas actualizaciones.
Debe existir esta lı́nea:

deb http://security.debian.org/ sarge/updates main contrib non-free

Una vez agregadas estas referencias, debemos actualizar la base de datos local de paquetes (como en la Figura 10)
con el comando:

debian:˜# apt-get update

Y actualizar los paquetes, tal como se ve en la Figura 11

debian:˜# apt-get upgrade

Posiblemente sea de utilidad que el administrador se subscriba a la lista de DSA12 , para estar al tanto de las
actualizaciones en materia de seguridad.
10 Package Tracking System (Sistema de Seguimiento de Paquetes) http://www.debian.org/doc/manuals/developers-reference/ch-

resources.en.html#s-pkg-tracking-system
11 DeMilitarized zone (zona desmilitarizada)
12 Debian Security Announce (Anuncios de Seguridad en Debian) http://lists.debian.org/debian-security-announce/

www.arcert.gov.ar 16 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

Figura 10: Actualización de la base de datos local para paquetes (apt-get update)

Figura 11: Actualización de paquetes (apt-get upgrade)

Con este último paso podemos considerar que hemos finalizado la instalación del sistema operativo, y estamos
listos para comenzar a utilizarlo. El siguiente paso consistirá en configurar y asegurar los servicios que este
equipo deba brindar (Web, Mail, etc.), pero eso lo dejamos para otros documentos. Luego de configurados los
servicios, será el momento de realizar un back-up (véase ’Back-up)’ completo del sistema.

15. Mantenimiento
El sistema que acabamos de instalar no está terminado, ya que evolucionará con el tiempo. Seguramente se
le incorporará, quitará o modificará algún servicio o configuración. Por este motivo, habrá que tener en cuenta
los conceptos de esta guı́a durante toda la vida del servidor. En particular, no debemos olvidarnos de realizar las
actualizaciones de seguridad como se describe en la sección ’Actualizaciones de seguridad’.
Además habrá que hacer el seguimiento del servidor y tener una actitud proactiva con respecto a su seguridad.
De ello hablaremos en esta sección.

15.1. Sincronización horaria

En los próximos apartados insistiremos en la importancia de enviar a un host remoto y seguro los mensajes
generados por el sistema. La única manera de correlacionar los eventos que observemos en diferentes equipos,
será si sus relojes están perfectamente sincronizados.
Por ello, es recomendable establecer un esquema de sincronización de relojes utilizando el protocolo NTP13
Es muy normal contar con un servidor NTP en cada red, donde se sincronizan todas la máquinas y que, a su vez,
está sincronizado con uno o más relojes externos.
Las aplicaciones útiles para el esquema de sincronización pueden ser:

ntpd, servidor NTP para Unix-like. OpenNTPD, puede ser una alternativa de configuración más sencilla.

ntpdate, cliente NTP para Unix-like.

Windows incluye un servicio para la sincronización horaria.

13 Network Time Protocol, protocolo de internet para sincronizar los relojes de los sistemas informáticos en redes con latencia variable.

www.arcert.gov.ar 17 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

15.2. Back-up
Dentro de las tareas de mantenimiento, se encuentra la realización de back-ups periódicos del equipo. La
discusión sobre los diferentes métodos existentes puede ser muy amplia. Sin embargo presentamos algunas reco-
mendaciones para su ejecución:

Para realizar back-up de muchos equipos de manera combinada, será necesario contar con un buen gestor
de archivos de respaldo. Amanda14 es una buena opción libre, compatible con muchos sistemas Unix-like
(SCO, FreeBSD, IRIX, AIX, HP-UX, GNU/Linux), pero requiere Samba para trabajar con Windows. Otra
herramienta muy usada, que sı́ tiene soporte para Windows, es bacula15 .

La practicidad de las cintas nunca será superada por los medios ópticos (a menos que estos crezcan en
capacidad más de lo que lo han hecho en los últimos años), o poseamos un intercambiador de CDs de gran
capacidad.
Es recomendable realizar backups full de manera periódica, e intercalarlos con back-ups parciales.

Para que un back-up sea útil, es indispensable que pueda ser recuperado. Y para estar seguros de ésto, es
necesario que la polı́tica de back-up incluya simulaciones periódicas donde restauremos nuestros sistemas
desde las cintas.

Considerar la posibilidad de guardar copias de los back-ups en sitios remotos, para contingencias mayores.

Tener en cuenta que la sensibilidad de la información contenida en una cinta de back-up es igual a la infor-
mación más sensible que haya sido almacenada, por lo que habrá que tomar los recaudos del caso.

Los métodos más comunes de back-up en GNU/Linux son utilizar tar, cpio, o dump. Si no utilizamos un
gestor de back-up, dump es una opción muy interesante por su manejo de niveles para copias incrementales
y su integración con el sistema de archivos ext2/ext3. Como desventajas, tiene su lentitud, y que no es
compatible con todos los filesystems existentes.

La única forma de obtener una imagen exacta del disco, con la certeza de que no contendrá ningún tipo de
inconsistencia, ni a nivel lógico del disco, ni a nivel transaccional de las aplicaciones, es realizar back-ups
offline.

15.3. Auditorı́as regulares

Una aplicación interesante para revisar la seguridad de nuestro servidor es tiger. Esta herramienta realiza di-
versas verificaciones sobre la configuración y el estado de varios elementos del sistema operativo. Permite realizar
estos chequeos de manera perı́odica.
La forma más recomendada para su instalación es junto con algunos paquetes auxiliares:

debian:˜# apt-get install binutils chkrootkit lsof file libmagic1 tiger

Con su instalación por defecto, tiger realizará diariamente las verificaciones y enviará un reporte de los proble-
mas encontrados. Al igual que con las verificaciones de integridad (véase ’Chequeos de integridad’) y logs (véase
’Manejo de bitácoras (logs)’), será conveniente arbitrar los medios necesarios para que dicho reporte sea enviado
a un equipo remoto con las medidas de seguridad del caso. La opción más común para este tipo de reportes es el
envı́o por e-mail (a través de algún MTA local), pero también podrı́an utilizarse otros medios más seguros, como
por ejemplo lı́neas seriales unidireccionales.
En la Figura 12 se puede observar un reporte del análisis hecho por tiger.
14 http://www.amanda.org/
15 http://www.bacula.org/

www.arcert.gov.ar 18 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

Figura 12: Resultado del chequeo hecho por tiger (/var/log/tiger/security.report)

15.4. Chequeos de integridad

¿Cómo podemos descubrir si eventualmente el equipo resulta comprometido? Un excelente método es verificar
la integridad de los archivos existentes en el sistema de archivos. Existen varias herramientas para realizar esta
tarea:

Tripwire, prácticamente la más antigua de todas (sólo de uso libre para Linux, y bajo ciertas condiciones de
licenciamiento)
Integrit, es un clon libre de tripwire.

Debsums, que verifica la integridad de los archivos en base al hash contenido en el paquete Debian que lo
provee. No todos los paquetes tienen los hashes necesarios, por lo que la herramienta no resulta práctica.

AIDE16 , actualmente una de las más usadas y recomendables.

En general estas herramientas proveen varias opciones de verificación, incluyendo hashes con uno o más algoritmos
criptográficos, verificación de MAC time (Modificación, Acceso y Cambio), permisos, tamaño, etc. Todas proveen
una configuración de ejemplo (en el caso de AIDE, /etc/aide/aide.conf) que servirá de punto de partida
para una configuración adecuada al sistema que acabamos de instalar.
Algunas de las cosas que habrá que modificar seguramente incluirán:

Ni /etc, donde se encuentran todos los archivos de configuración, ni /boot, donde se encuentran los
archivos de inicio del sistema operativo, están contemplados en el archivo de ejemplo.

/var/log tiene algunas configuraciones especı́ficas, que seguramente causarán varios falsos positivos si
la actividad de nuestro host modifica los logs constantemente.

/home sólo está contemplado como un ejemplo. Si el sistema posee muchos usuarios independientes, se-
guramente querremos verificar como mucho que no cambie el dueño (owner) de los archivos. Si no tiene
usuarios además del administrador, vamos a querer observar cualquier tipo de cambio.

Un buen método para ajustar la configuración es agregar todos los directorios dependientes del raı́z faltantes
(/boot, /home/, etc.) con todas las verificaciones posibles, e ir ajustándolas a medida que recibimos las aler-
tas. Como mencionamos en caso de la auditorı́a interna, será conveniente que los reportes de estas verificaciones
16 Advanced Intrusion Detection Environment (Ambiente avanzado para la detección de intrusos)

www.arcert.gov.ar 19 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

sean recibidos en un host remoto, donde se tenga la seguridad de que podrán ser recuperados en caso de que una
intrusión intente borrarlos.
Además, para el caso de las verificaciones de integridad de los archivos, todos los métodos se basan en la
creación de una base de datos con el estado inicial del sistema, y la posterior comparación con ésta. Si queremos
que esta verificación sea efectiva, y no pueda ser falseada durante una intrusión, deberemos montar la base de datos
en un dispositivo de sólo lectura. Por ejemplo, en un CD-ROM (o alguna clase de dispositivo al que se le pueda
bloquear la escritura por hardware: un disquete, un pen-drive, una tarjeta flash, etc.).

15.5. Manejo de bitácoras (logs)

Los logs del sistema serán seguramente una de las herramientas más valiosas a la hora de atender un intento de
intrusión al equipo, exitoso o no.
En la mayorı́a de los sistemas UNIX-like, y por supuesto también en GNU/Linux, se utiliza el sistema syslog
para manejar los logs del sistema. Este sistema consiste en un demonio que recibe los diferentes mensajes de las
aplicaciones y el sistema operativo. Se configura a través del archivo /etc/syslog.conf, el cual tiene dos
conceptos fundamentales: facility y level. El primero es la aplicación o el componente del sistemas operativo que
genera logs. level hace referencia a la severidad del mensaje. Por cada combinación de estos se realiza una acción.
El formato entonces quedarı́a:

facility.level <Tab><Tab> acción

Ası́, para cada tipo y severidad de log habrá un tratamiento, por ejemplo, escribir un mensaje en un archivo. Estos
archivos, normalmente residen en el directorio /var/log. Como mencionamos en otros apartados, será conve-
niente que estos mensajes sean guardados en un repositorio externo, para evitar que sean falseados en caso de una
intrusión. La forma más común de realizar esta tarea es enviarlos a otro host mediante el mismo protocolo syslog,
de la siguiente manera:

*.* @loghost.ourdomain
De esta manera, todos los mensajes (de cualquier tipo y nivel), serán reenviados al host loghost.ourdomain. Una
alternativa mucho más segura, aunque pocas veces utilizada, es enviar los mensajes a través de un puerto serial a
un loghost totalmente desconectado de la red.
Existen alternativas17 al sistema syslog, como syslog-ng18 , que permite mucha mayor flexibilidad en las accio-
nes a tomar con los mensajes recibidos.
Por último, mencionaremos una herramienta que puede ayudar a la lectura de los logs almacenados, que suelen
tener un volumen importante. Esta herramienta es logcheck. La misma se basa en varias reglas, alojadas en el
directorio /etc/logcheck, que definen por medio de expresiones regulares qué mensajes son importantes, y
cuáles son inofensivos. Luego de seleccionar los mensajes según las reglas definidas, un resumen es enviado por
e-mail. De la misma manera que en los casos anteriores, podrı́a ser conveniente que este reporte sea enviado a un
host remoto.
Otra opción muy similiar es logwatch19 .

16. Herramientas para automatizar el fortalecimiento

Existen algunas herramientas que pueden ayudarnos a asegurar un servidor. Dichas herramientas son útiles, pe-
ro por ninguna razón deben reemplazar el trabajo manual y el chequeo de las configuraciones por un administrador
de sistemas.

16.1. Bastille Linux

Esta herramienta, con bastante historia en GNU/Linux, consiste en una serie de preguntas que habrá que res-
ponder, para luego automatizar varias de las tareas que hemos realizado en este manual, y algunas otras que no
17 http://www.loganalysis.org/sections/syslog/syslog-replacements/index.html
18 syslog next generation
19 http://www.logwatch.org

www.arcert.gov.ar 20 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

Figura 13: Chequeo de los bits suid con bastille (InteractiveBastille)

hemos cubierto. Se recomienda utilizar el mismo como una guı́a para ayudar a estas tareas, pero nunca para reem-
plazar la inspección personal de las mismas.
Para instalar esta herramienta, al igual que con todos los paquetes, realizaremos la siguiente operación:
debian:˜# apt-get install bastille
Luego de finalizada la instalación, podemos ejecutar el modo interactivo mediante el siguiente comando:
debian:˜# InteractiveBastille
A continuación, se nos presentarán una serie de preguntas sobre las tareas a realizar, con una explicación de sus
efectos posteriores. Por ejemplo, en la Figura 13 se observa a la aplicación consultando sobre la deshabilitación
del bit suid en diversos programas.

16.2. Paquetes Harden

Los paquetes harden de Debian son una serie de paquetes que, al igual que Bastille Linux, nos ayudarán a
asegurar un sitio, pero no reemplazarán una buena configuración.
Los paquetes harden se encargan de conflictuar con otros paquetes que, por alguna razón, son considerados
inseguros. Por ejemplo, telnet que trabaja sobre protocolos sin cifrar.
Entre otros, podemos encontrar harden-tools, que incluye algunas herramientas como el tiger, harden-doc, con
documentación sobre seguridad, y harden-servers, harden-clients, harden-remoteflaws y harden-localflaws, que
eliminan o limitan la instalación de paquetes con conocidos problemas de seguridad de distintos perfiles.

17. Otras fuentes de información

Para obtener más información sobre seguridad en la distribución Debian:
http://www.debian.org/doc/manuals/securing-debian-howto/
El manual completo de instalación de Debian puede obtenerse en:
http://www.debian.org/releases/sarge/installmanual

18. CheckList
 Pre-instalación

www.arcert.gov.ar 21 ArCERT 2006

c
 Reforzando la instalación de Debian GNU/Linux

 Restringir el acceso fı́sico.

 Aislar la red.
 Deshabilitar los puertos y dispositivos innecesarios.
 Seleccionar de dispositivo de arranque.
 Configurar password de modificación de BIOS.
 Instalación
 Particionado.
 Aislar la red.
 Ajustar las opciones de inicio en el BIOS.
 Creación de usuario/s no privilegiado/s.
 Limpieza
 de servicios de red preinstalados.
 de paquetes no utilizados.
 de módulos de kernel.
 Deshabilitar el Ctl+Alt+Del.
 Ajustar /etc/fstab.
 Usuarios y permisos.
 Ajustar las propiedades de los usuarios (shell).
 Eliminar los suid bit de los ejecutables.
 Restringir el uso del cron.
 Restringir el uso del at.
 Ajustar las opciones de sudo.
 Limitar el acceso de root.
 Crear el grupo wheel y agregar los usuarios correspondientes.
 Configurar que consolas seguras (/etc/securetty).
 Administración remota (SSH).
 Permitir sólo versión 2.
 Configurar tcpwrapper (hosts.deny y hosts.allow).
 Restringir login de root.
 Ajustar parámetros del kernel (/etc/sysctl.conf).
 Instalar paquetes (servicio/s que brindará el servidor).
 Configurar el firewall de host.
 Instalar cliente para la sincronización horaria.
 Actualizar los paquetes instalados (apt-get upgrade).
 Planear y configurar esquema de back-up.
 Instalar y configurar herramienta para integridad de archivos.
 Instalar y configurar herramienta para auditorı́as regulares.
 Configuración del envio de bitácoras a un loghost.

www.arcert.gov.ar 22 ArCERT 2006

c