PDF de programación - Configuración segura del ordenador

Configuraci´on segura del ordenador

1. Una buena medida de protecci´on consiste en crear los directorios /home/, /tmp/, /var/,
/boot/, /etc/ y /root/ en particiones distintas. Si no puede ser o no quieres, que sean
/home/, /tmp/ y /boot/. Y si esto tampoco puede ser, /home/ al menos.

Esta precauci´on no s´olo complica la tarea de controlar tu equipo a un hacker, tambi´en es ´util
en caso de que el disco duro sufra alg´un problema o hagas alg´un desastre como administrador
(podr´as recuperar tus datos m´as f´acilmente).

2. Pon clave de acceso a grub. Para ello procede de la siguiente forma:

a) Con ayuda de grub-md5-crypt generas tu contrase˜na cifrada (p.e. bqv6viye4yk1bletum).

b) La contrase˜na cifrada la introduces en menu.lst mediante la orden:

$ password -md5 bqv6viye4yk1bletum.

c) Comprueba que menu.lst s´olo es accesible a root.

Con esto dificultas el acceso al arranque de tu equipo pero no evitas que alguien pueda
utilizar un CD de arranque. Puedes poner una contrase˜na a la BIOS para evitarlo pero
tampoco es un problema insalvable para los chicos malos. Aqu´ı cada uno debe decidir d´onde
parar.

3. Utiliza contrase˜nas ocultas y aseg´urate de que el fichero shadow (situado en el directorio
/etc/) s´olo es accesible a root. Sabr´as que no usas contrase˜nas ocultas si cuando abres el
fichero passwd los usuarios aparecen definidos as´ı:

root:$1$k1BbQvLe$Py6viTumYe4Y/:0:0:root:/root:/bin/bash
...
jcano:$B6ue$1$k1pcLe$TumYe4YPy6:500:500:Jos´e Cano:/home/jcano:/bin/bash

Cuando usas contrase˜nas ocultas, en tu fichero passwd los usuarios quedan definidos as´ı:

root:x:0:0:root:/root:/bin/bash
...
jcano:x:500:500:Jos´e Cano:/home/jcano:/bin/bash

En el primer caso, las claves de los usuarios pueden verse (encriptadas, eso s´ı, pero aparecen),
en tanto en el segundo s´olo aparece una x.

El uso de contrase˜nas ocultas es una mejora en la seguridad. Algunos programas necesitan
acceder al fichero passwd y esto puede crear un agujero de seguridad (caso del Netscape 4.5,
que dejaba ver las contrase˜nas codificadas). Por tanto, lo mejor es que las claves est´en en el
archivo shadow.

4. Comprueba que el directorio /var/log/ s´olo puede ser le´ıdo por el root. Si cuando accedemos
a un equipo, introducimos un nombre de usuario que no existe, se produce un error que se
registra en los archivos auth.log y syslog1. En algunas distribuciones el error que se registra
no dice qu´e se introdujo, pero en otras distribuciones s´ı se puede leer claramente que es lo que
se escribi´o. Esto no es un problema en s´ı mismo, pero todo el mundo alguna vez introduce
la clave donde deber´ıa ir el nombre de usuario, de forma que tu clave queda registrada en
esos archivos.

5. Los servicios que no se usan deber´ıan estar cerrados y gestionados por su propio demonio, por
ello es mejor no usar los demonios inetd (o la versi´on mejorada xinetd) que gestionan tanto
servicios internos (echo, time,...) como externos (ftp, telnet,...). Lo normal es que s´olo quera-
mos usar ssh y para esto es preferible usar el correspondiente demonio sshd. Por tanto, lo m´as

1Los archivos pueden ser otros dependiendo de la distribuci´on que uses.

1

recomendable es comentar todas las l´ıneas de los archivos /etc/inetd.conf y /etc/xinetd.conf
(en las distribuciones m´as modernas esto viene por defecto).

6. En el fichero /etc/securetty s´olo deber´ıan aparecer de la consola tty1 a la tty6 y de vc1 a vc6

(comenta el resto de l´ıneas). Esto previene los ataques directos al root.

7. Comprueba que no se pueden ejecutar archivos con el bit setuserid si los valores uid y euid

no coinciden. Para ello realiza la siguiente prueba:

a) Como root escribe:

$ cp /bin/bash /tmp/kkbash
$ chmod 4555 /tmp/kkbash

b) Como usuario:

$ /tmp/kkbash
$ vi /etc/shadow

Si ves el contenido del archivo shadow, mal asunto, la ´unica soluci´on es actualizar el n´ucleo.
No te olvides de borrar kkbash.

8. Pon un protector de pantalla con clave de acceso. No pongas un tiempo de activaci´on muy
grande (p.e. 1 hora hace in´util esta medida de seguridad), pero tampoco muy peque˜no (p.e.
un salvapantallas que salta a los 5 minutos s´olo sirve para que acabes hasta el gorro de ´el y
termines por quitarlo).

9. Si usas samba aseg´urate de que los ficheros en el directorio /var/spool/lp/ s´olo pertenecen
a root. De igual modo, si usas conexiones ppp protege el archivo /etc/ppp/chop-secrets o el
archivo /etc/wvdial.conf si usas el programa wvdial.

2

Medidas preventivas

10. Elimina ’.’ del path. La costumbre de ponerlo s´olo sirve para ahorrarte un par de golpes de
tecla y, por contra, se facilita a los usuarios ganar privilegios de root mediante alg´un troyano
convenientemente colocado.

nota: No pienses que si en tu equipo s´olo trabajas t´u esta precauci´on no te afecta. El acceso
a root es (y debe) ser m´as dif´ıcil que a la cuenta de un usuario, de esta forma si un hacker
entra en tu equipo s´olo queda comprometida una cuenta de usuario. Por ejemplo, es posible
(y una buena idea) configurar ssh para que el acceso como root sea imposible, pero esto
pierde su utilidad si alguien entra en tu ordenador y se lo pones f´acil para convertirse en
administrador.

11. Elimina los archivos /etc/issue y /etc/issue.net para no dar informaci´on del sistema. Al
eliminarlos complicas la tarea de saber (desde el exterior) qu´e sistema operativo tienes
instalado.

12. Si s´olo una persona usa el ordenador haz inmutables los archivos shadow y passwd (y las

copias shadow- y passwd-) con el comando:
$ chattr +i shadow

13. Haz inmutables los archivos de los directorios: /bin/, /sbin/, /lib/, /usr/bin/ y /usr/sbin/.

Los archivos de estos directorios no deber´ıan ser f´acilmente modificables.

14. Evita el uso de contrase˜nas en ficheros de usuario. Esta pr´actica permite pasar la contrase˜na
a ciertos programas, de modo que no tenemos que escribirla, pero es como dejar la llave de
tu casa debajo del felpudo. Un hacker buscar´a estos ficheros y se lo est´as poniendo f´acil para
que sepa tu contrase˜na.

Tampoco escribas tu contrase˜na en l´ınea de comando pues puede quedar registrada en los
archivos de registro. Lo mejor es que introduzcas tu contrase˜na por stdin (que por otra parte
es lo habitual).

15.

sudo permite que un usuario pueda realizar ciertas tareas propias del administrador, de esta
forma no es necesario que este usuario conozca la clave del administrador. Esta opci´on es de
utilidad en un ordenador con varios usuarios pero es insegura. Si s´olo una persona utiliza el
ordenador esta aplicaci´on sobra.

16. Sospecha de todo script con procedencia dudosa. Y si tiene llamadas al comando system,
con m´as motivo. Todo script que incorpore llamadas al sistema operativo tiene que mirarse
con lupa.

17. Ten a mano un CD Live que te permita arrancar el equipo en caso de emergencia.

18. Consulta peri´odicamente alguna p´agina web donde informen de las vulnerabilidades encon-

tradas en el software que tengas instalado.

3

Conexi´on a red

19. Con el comando ifconfig -a se obtienen los dispositivos que est´an a la escucha en tu equipo.
Lo normal para un equipo en la universidad es que aparezcan eth0, lo y sit0. Si aparecen
m´as, aseg´urate de que su presencia est´a justificada.

nota: Una forma (que no es infalible) de detectar la presencia de un sniffer escuchando en
la red es que este comando devuelva la siguiente l´ınea:

UP BROADCAST RUNNING PROMISC MULTICAST

Lo normal es que se lea:

UP BROADCAST RUNNING MULTICAST

20. Los dispositivos de red traen a veces una contrase˜na por defecto. Esta contrase˜na se puede
encontrar f´acilmente en Internet, as´ı que aseg´urate de que cambias esta contrase˜na (parece
incre´ıble, pero es de lo m´as com´un no cambiarla).

21. Aseg´urate de que usas el protocolo de conexi´on IPv6, que es el ´ultimo.

22.

Instala un cortafuegos. A mi me gusta firestarter por su sencillez y eficacia. El ´unico punto
que te puede resultar dif´ıcil se refiere al filtro ICMP en el que recomiendo filtrar todo menos
no disponible y marcado de tiempo.

23. Cuando tengas el cortafuegos instalado (y est´es desconectado de Internet) ejecuta:

$ netsat -an
Cuantos menos puertos LISTEN tengas, mejor2 (s´olo deber´ıas tener abiertos los puertos
que necesites, ni uno m´as). De los puertos ESTABLISHED comprueba que son conexiones
internas.

En particular comprueba que los puertos del 6000 al 6063 est´an cerrados, hay pocas razones
que justifiquen tenerlos abiertos y por contra son un riesgo para ti. Lo m´as probable es que
si los tienes abiertos es por una mala configuraci´on de las Xwindows.

2P.e. yo s´olo tengo cuatro abiertos.

4

Correo electr´onico

24. Si no usas correo seguro utiliza una contrase˜na exclusiva para este servicio, no uses la de
usuario o la de root. El correo electr´onico cuando no est´a cifrado no es una carta, es una
postal. Mediante un sniffer cualquiera puede ver lo que escribes (incluida tu clave). Por
tanto, s´olo hay dos opciones: cifras el correo o asumes que te pueden leer el correo (pero no
comprometes m´as).

25. Mediante tunneling se puede leer el correo de forma segura usando ´unicamente POP. Esta
t´ecnica establece un t´unel cifrado mediante SSH entre tu equipo y tu servidor de correo
(venus).

Lo primero que tienes que hacer es configurar la conexi´on SSH a venus para que se autentifique
mediante el uso de clave p´ublica/privada. Para esto es mejor que consultes alg´un manual
pero b´asicamente consiste en generar una clave p´ublica y otra privada mediante ssh-keygen
-t dsa1, la clave privada se queda en tu equipo (s´olo accesible a root) y la p´ublica la colocas
en venus. De esta forma accedes a venus de forma segura sin escribir tu clave.

El segundo paso es escribir el siguiente script:

#! /bin/sh
evolution&
ssh -nx -L 43210:venus.escet.urjc.es:110 [email protected]

N´otese que pongo a la ”escucha”el puerto local 43210 pero que puede ser otro (el puerto 110
s´ı es fijo, corresponde al puerto por el que ”habla”venus). As´ı mismo, supongo que se usa
evolut