Con frecuencia la parte más complicada de una política de seguridad es
concienciar a los usuarios de la necesidad de medidas básicas de prevención
contra ataques. Demasiados usuarios opinan que las historias de crackers
que atacan ordenadores sólo suceden en las películas o en organizaciones
militares de alta seguridad; nada más lejos de la realidad: en cualquier
universidad ocurren a diario incidentes de seguridad, de los que sólo una
pequeña parte se detecta (y muchos menos se solucionan). Sería pues
muy recomendable para el administrador imprimir una hoja con las medidas de
seguridad básicas o la política del sistema, y entregar una copia a
cada usuario al crear su cuenta.
- Contraseñas aceptables
Es conveniente que los usuarios elijan claves medianamente resistentes a ataques
de diccionario; una contraseña como patata o valencia es un
gran agujero de seguridad para la máquina, aunque el usuario que la usa no
tenga ningún privilegio especial. Hemos de ver la seguridad como una cadena
cuya fuerza depende principalmente del eslabón más débil: si falla éste,
falla toda la cadena. Sin embargo, el problema de estas claves es que pueden
llegar a ser difíciles de recordar, de forma que mucha gente opta por
apuntarlas en el monitor de su estación o en la parte inferior de sus
teclados; obviamente, esto es casi peor que el problema inicial, ya que como
administradores no podemos controlar estas situaciones la mayor parte de las
veces. Podemos (y sería lo recomendable) recomendar a los usuarios que
utilicen combinaciones de mayúsculas, minúsculas, números y símbolos
para generar sus claves, pero de forma que la combinación les pueda resultar
familiar: por ejemplo, combinar números y letras de la matrícula del
coche con algunos símbolos de separación; claves de este estilo
podrían ser V#GF&121, @3289?DH o JKnB0322. Obviamente
estas claves son más resistentes a un ataque que beatles, pero tampoco
son seguras: las acabamos de escribir.
- Confidencialidad de las claves
Hemos de concienciar a nuestros usuarios de que las contraseñas no se
comparten: no es recomendable `prestar' su clave a otras personas, ajenas o
no al sistema, ni por supuesto utilizar la misma clave para diferentes
máquinas. Este último punto muchas veces se olvida en sistemas de I+D, donde
el usuario se ve obligado a utilizar passwords para muchas actividades y
tiende invariablemente a usar la misma contraseña; incluso se utiliza la
clave de acceso a un equipo Unix para autenticarse en juegos de red (MUDs o
IRC) o, lo que es igual de grave, para acceder a equipos Windows, de forma que
las vulnerabilidades de seguridad de estos sistemas se trasladan a Unix.
- Conexiones cifradas
Hay que potenciar entre los usuarios el uso de programas como ssh/scp o
ssl-telnet/ssl-ftp para conectar al equipo. La parte cliente de estos
programas es muy simple de utilizar, y nos puede ahorrar muchos dolores de
cabeza como administradores. Incluso existen clientes para Windows y MacOS, por
lo que nadie tiene excusa para no usar sistemas cifrados (se puede conseguir
que su uso sea completamente transparente al usuario); casi la mejor
forma de que los usuarios los utilicen es dejando de ofrecer ciertos servicios
sin cifra, como telnet, ftp, rlogin o rsh.
- Ejecución de programas
Nunca, bajo ningún concepto, instalar o ejecutar software que no
provenga de fuentes fiables; hay que prestar atención especial a programas
que nos envíen por correo o por IRC, ya que se puede tratar de
programas trampa que, desde borrar todos nuestros ficheros, a enviar por correo
una copia del archivo de contraseñas, pueden hacer cualquier cosa: imaginemos
que un `amigo' nos envía un juego a través de cualquier medio -
especialmente IRC - y nosotros lo ejecutamos; incluso disponer del
código fuente no es ninguna garantía (>qué usuario medio lee un
código en C de, quizás, miles de líneas?). Ese programa puede hacer
algo tan simple como rm -rf $HOME/* sin que nosotros nos demos cuenta,
con las consecuencias que esta orden implica.
- Desconfianza
Hemos de desconfiar de cualquier correo electrónico, llamada telefónica o
mensaje de otro tipo que nos indique realizar una determinada actividad en el
sistema, especialmente cambiar la clave o ejecutar cierta orden; con
frecuencia, un usuario se convierte en cómplice involuntario de un atacante:
imaginemos que recibimos una llamada de alguien que dice ser el administrador
del sistema y que nos recomienda cambiar nuestra clave por otra que él nos
facilita, con la excusa de comprobar el funcionamiento del nuevo software
de correo. Si hacemos esto, esa persona ya tiene nuestra contraseña para
acceder ilegalmente a la máquina y hacer allí lo que quiera; hemos de
recordar siempre que el administrador no necesita nuestra ayuda para comprobar
nada, y si necesita cambiar nuestra clave, lo puede hacer él mismo.
- Un último consejo...
Cualquier actividad sospechosa que detectemos, aunque no nos implique
directamente a nosotros, ha de ser notificada al administrador o responsable de
seguridad del equipo. Esta notificación, a ser posible, no se ha de realizar
por correo electrónico (un atacante puede eliminar ese mail), sino en
persona o por teléfono.
En muchas ocasiones, cuando un usuario nota un comportamiento extraño en el
sistema, no notifica nada pensando que el administrador ya se ha enterado del
suceso, o por miedo a quedar en ridículo (quizás que lo que nosotros
consideramos `extraño' resulta ser algo completamente normal); esta
situación es errónea: si se trata de una falsa alarma, mucho mejor,
pero...>y si no lo es?
© 2002 Antonio Villalón Huerta
