Recomendaciones de seguridad para usuarios

Recomendaciones de seguridad para los usuarios y administradores

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 mucho 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 no es un gran agujero de seguridad para la máquina, aunque el usuario que la usa 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 clases 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 diferente 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 el equipo. La parte cliente de estos programas es muy simple de utilizar, y nos puede ahorrar muchos dolores de cabeza como adminsitradores. 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 qu, 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 cualqueir 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, esta persona ya tiene nuestra contraseña para acceder ilegalemente a la máquina y hacer allí lo que quiera; hemos de recordar siempre que el adminstrador no necesita nuestra ayuda para comprobar nada, y si necesita 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 ususario 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?

Referencias rápidas

Prevención:

Cerrar los servicios de inetd que no sean estrictamente necesarios.
No lanzar demonios en el arranque de máquina que no sean estrictamente necesarios.
Minimizar el número de ficheros setuidados o setgidados en la máquina.
Instalar TCP Wrappers y utilizar una política restrictiva: echo ALL:ALL >/etc/hosts.deny.
Utilizar TCP Wrappers para controlar el acceso a nuestro sendmail, o utilizar un wrapper propio para este demonio.
Sustituir telnet, ftp o similares por ssh y scp.
No permitir ficheros $HOME/ .rhosts en los directorios de usuarios, y no establecer relaciones de confianza en /etc/hosts.equiv.
Deshabilitar las cuentas del sistema que no corresponden a usuarios reales (uucp, lp...).
Instalar un sistema Shadow Password para que los usuarios no puedan leer las claves cifradas.
Deshabilitar las cuentas de usuarios que no conecten al sistema.
Utilizar versiones actualizadas del núcleo del sistema operativo.
Evitar sobrecargas de servicio planificando pkill –HUP inetd en nuestro fichero crontab.

Detección:

Configurar Tripwire nada más instalar el sistema y guardar sus resultados en un medio fiable; cada cierto tiempo, ejecutar Tripwire para comparar sus resultados con los iniciales.
Chequear periódicamente los logs en busca de acltividades sospechosas.
Utilizar órdenes como ps, netstat o last para detectar cualquier evento fuera de lo normal en el sistema, pero no confiar ciegamente en los resultados que se nos muestran en pantalla: seamos paranoicos.
Comprobar periódicamente la integridad de ficheros importante de nuestro sistema, como /etc/passwd, /etc/exports, /etc/syslog.conf, /etc/aliases o ficheros de arranque.
Comprobar también elementos como los permisos o el propietario de los ficheros que se encuentran en los directorios de usuarios.

Recuperación:

Nunca hay que ponerse nervioso: nuestra máquina ni ha sido la primera ni lamentablemente será la última en sufrir un ataque. No es el fin del mundo.
Desconfiar de cualqueir sprograma que se encuentra en el sistema; utilizar programas del CD-ROM del sistema operativo, o versiones estáticas de los mismos, para tracear las actividades del intruso.
Si es posible, reinstalar el sistema operativo ocmpleto y aplicarle los parches de seguridad que el fabricante pone a nuestra disposición; permanecer atentos a los directorios de usuarios y a los programas que éstos contienen.
Si pensamos que la integridad del sistema peligra mucho, desconectar directamente el cable de red: utilizar ifconfig down o detener el sistema con shutdown puede incluso acarrearnos problemas.
Obviamente, antes de poner el sistema de nuevo a funcionar en red, estar completamente seguro que los problemas de seguridad que el atacante aprovechó están solucionados.

Usuarios: