Logo Web Xombra.com

Sitios Web Promocionados

Visitalos!

Xombra.com  - Seguridad Informatica!

Nube de TAGS

seguridad básica gnu linux iii xombra local sistema operativo multiusuario real haber varios usuarios trabajando simult a

.:Categorías:.

Aniversarios (11) Apple (31) Bugs (1917) Exploits (26) Gnu/linux (802) Hack (505) Información (22) Microsoft Windows (189) Mozilla (117) Noticias (701) Opinion (325) Php (46) Seguridad (994) Virus Y Troyanos (737)

Seguridad Básica en GNU/Linux (III Parte) - xombra.com

Seguridad Local

Linux es un sistema operativo multiusuario real: puede haber varios usuarios trabajando simultáneamente con él, cada uno en su terminal. Esto obliga a tener en cuenta medidas de seguridad adicionales. Además, según hablan las estadísticas, el mayor porcentaje de violaciones de un sistema son realizadas por usuarios locales. Pero no sólo hay que protegerse de las violaciones intencionadas, sino que el sistema debe protegernos de operaciones accidentales debidas a decuidos o ignorancia de los usuarios.

En este aspecto de la seguridad, Linux dispone de todas las características de los sistemas Unix: un control de acceso a los usuarios verificando una pareja de usuario y clave; cada fichero y directorio tienen sus propietario y permisos.

Por otro lado, la meta de la mayoría de los ataques es conseguir acceso como root, lo que garantiza un control total sobre el sistema. Primero se intentará conseguir acceso como usuario "normal" para posteriormente ir incrementando sus niveles de privilegio utilizando las posibles debilidades del sistema: programas con errores, configuraciones deficientes de los servicios o el descifrado de claves cifradas. Incluso se utilizan técnicas denominadas "ingeniería social", consistentes en convencer a ciertos usuarios para que suministren una información que debiera ser mantenida en secreto, como sus nombres de usuario y contraseñas.

En este apartado de seguridad local pretendemos dar unas ideas generales de los riesgos existentes, mecanismos para su solución y unas directrices de actuación que deberían convertirse en hábitos cotidianos.

* Cuentas de usuario, Grupos

Cada usuario del sistema está definido por una línea en el fichero /etc/passwd y cada grupo por otra línea en el fichero /etc/group. Cada usuario pertenece a uno o varios grupos y cada recurso pertenece a un usuario y un grupo. Los permisos para un recurso se pueden asignar al propietario, al grupo y a otros (resto de los usuarios). Ahora bien, para mantener un sistema seguro, pero funcional, tendremos que realizar las combinaciones necesarias entre el propietario y grupo de un recurso con los permisos de los propietarios, grupos y otros. Por ejemplo, la unidad de disco flexible tiene las siguientes características:

brw-rw-r-- 1 root floppy 2,0 may 5 1998 /dev/fd0

- Propietario: root con permiso de lectura y escritura.
- Grupo: floppy con permiso de lectura y escritura.
- Otros: resto de los usuario con permiso de lectura.

Cuando queramos que un usuario pueda escribir en la unidad de disco, sólo tendremos que incluirlo en el grupo floppy. Cualquier otro usuario que no pertenezca al grupo floppy (salvo root) sólo podrá leer el disquete.

El administrador tiene que conocer las necesidades de cada uno de sus usuarios y asignarle los mínimos privilegios para que pueda realizar su trabajo sin resultar un peligro para otros usuarios o el sistema. Más abajo veremos otro mecanismo para poder utilizar un recurso sobre el cual no tenemos privilegios.

No se asuste. Los valores que traen por defecto las distribuciones de Linux son suficiente para mantener el sistema seguro.

Otro peligro potencial para el sistema es mantener cuentas abiertas que se han dejado de utilizar. Estas cuentas pueden constituir un buen refugio para un potencial atacante y pasar desapercibidas sus acciones.

* Seguridad de las claves

La seguridad de una sola cuenta puede comprometer la seguridad de todo el sistema. Esto es una realidad ante la que debemos protegernos.

Por un lado tenemos que asegurarnos de que nuestros usuarios utilizan claves sólidas:
No deben ser una palabra conocida.
Deberían contener letras, números y caracteres especiales.
Deben ser fáciles de recordar y difíciles de adivinar.

Para comprobar que este requisito se verifica en nuestro sistema, podemos usar los mismos mecanismos que utilizan los atacantes. Existen varios programas que van probando varias palabras de diccionario, claves habituales y combinaciones de caracteres, que son cifrados con el mismo algoritmo que usa el sistema para mantener sus claves; después son comparadas con el valor de la clave cifrada que quermos averiguar hasta que el valor obtenido de un cifrado coincide con una clave cifrada. Posteriormente notificaremos al usuario que su clave es débil y le solicitaremos que la modifique.

Usando este mecanismo, al menos podemos garantizar que no estaremos en inferioridad de condiciones con respecto a los atacantes locales.

Un conocido programa para realizar el descifrado de claves es John the Ripper.

Por otro lado, las claves cifradas se almacenan en el fichero /etc/passwd. Cualquier usuario del sistema tiene permiso de lectura sobre este fichero. Lo que es peor, agujeros en los navegadores permiten que se puedan leer ficheros arbitrarios de una máquina (evidentemente, que el usuario de navegador tenga permiso para leer), de manera que lleguen hasta un hacker que cree páginas web que exploten estos agujeros. No te pierdas una demostración para Netscape 4.5. Entonces puede parecer a primera vista que nos encontramos con un grave agujero de seguridad. El atacante, una vez obtenido el fichero /etc/passwd no tiene más que ejecutar su programa revientaclaves favorito y sentarse a esperar hasta que empiecen a aparecer nombres de usuario con sus respectivas contraseñas, algo que suele pasar muy rápidamente. Con suerte, si el administrador es ingenuo o dejado, incluso dará con la clave del root, abriéndosele así las puertas a la máquina objetivo. Para solucionar esta vulnerabilidad, podemos recurrir a contraseñas en la sombra (shadow passwords), un mecanismo consistente en extraer las claves cifradas del fichero /etc/passwd y situarlas en otro fichero llamado /etc/shadow, que sólo puede leer el root y dejar el resto de la información en el original /etc/passwd. El fichero /etc/shadow sólo contiene el nombre de usuario y su clave, e información administrativa, como cuándo expira la cuenta, etc. El formato del fichero /etc/shadow es similar al siguiente: usuario : clave : ultimo : puede : debe : aviso : expira : desactiva : reservado

usuario: El nombre del usario.
clave: La clave cifrada
ultimo: Días transcurridos del último cambio de clave desde el día 1/1/70
puede: Días transcurridos antes de que la clave se pueda modificar.
tiene: Días transcurridos antes de que la clave tenga que ser modificada.
aviso: Dias de aviso al usuario antes de que expire la clave.
expira: Días que se desactiva la cuenta tras expirar la clave.
desactiva: Días de duración de la cuenta desde el 1/1/70.
reservado: sin comentarios.

Un ejemplo podría ser: julia : gEvm4sbKnGRlg : 10627 : 0 : 99999 : 7 : -1 : -1 : 134529868

El paquete de Shadow Passwords se puede descargar desde cualquiera de los siguientes sitios, con instrucciones para su instalación:

ftp://i17linuxb.ists.pwr.wroc.pl/pub/linux/shadow/shadow-current.tar.gz
ftp://ftp.icm.edu.pl/pub/Linux/shadow/shadow-current.tar.gz
ftp://iguana.hut.fi/pub/linux/shadow/shadow-current.tar.gz
ftp://ftp.cin.net/usr/ggallag/shadow/shadow-current.tar.gz
ftp://ftp.netural.com/pub/linux/shadow/shadow-current.tar.gz

Para activar contraseñas en la sombra, tiene que ejecutar pwconv como root; acción que creará su fichero /etc/shadow. Si su distribución de Linux no incluye contraseñas en la sombra o encuentra alguna dificultad para incorporar esta característica, existe un documento HOWTO (CÓMO) titulado Shadow-Password-HOWTO (http://www-personal.engin.umich.edu/~jgotts/linux/howto/Shadow-Password-HOWTO/Shadow-Password-HOWTO.html) que le puede resultar de gran utilidad. Aquí podrá encontrar también información adcional que le puede ayudar a mantener su seguridad local. Hasta ahora hemos visto diversas situaciones en las que podemos aumentar la seguridad usando una clave. Piense que tiene que recordar cada una de las claves que utiliza, piense que NO debe anotar NUNCA su clave en un papel (y menos pegarla a la pantalla). En alguna situación olvidar una clave puede ser un serio problema.

* El bit SUID/SGID

En muchas ocasiones un proceso necesita ejecutarse con unos privilegios mayores (o menores) que el usuario que lo lanzó. Por ejemplo, un usuario puede modificar su propia clave con el mandato passwd, pero esto implica modificar el fichero /etc/passwd, y para esto un usuario "de a pie" no tiene permiso. ¿Cómo se soluciona? Pues activando el bit SUID del comando passwd (nótese que cuando esto sucede, la x de ejecutable pasa a ser una s):
ls -la /usr/bin/passw*

-r-sr-xr-x 1 root bin 15613 abr 27 1998 /usr/bin/passwd

Esto quiere decir que cuando se ejecute, el proceso correspondiente va a tener los privilegios del propietario del comando (es decir, el root), no del usuario que lo lanzó. En otras palabras, el proceso generado por passwd pertenece a root. A primera vista, esto puede parecer una seria brecha de seguridad. Y lo es. Si el programa funciona correctamente, no tiene por qué dar problemas; pero pequeños defectos en el programa pueden ser utilizados por alguien para tratar de ejecutar otro código distinto con los privilegios de este proceso. El método suele ser el desbordamiento de la pila (buffer overflow).

Cualquier atacante que haya entrado en un sistema de forma ilegítima intentará dejar una shell con el bit SUID para mantener ese nivel de privilegio cuando vuelva a entrar en el sistema.

SGID es lo mismo que SUID, pero aplicado al grupo.

Así pues, tenga cuidado con los programas con el bit SUID/SGIG. Puede encontrarlos con root# find / -type f \( -perm -04000 -o -perm -02000 \) -print

Tenga en cuenta que algunos programas (como passwd) tienen que tener el bit SUID. Compruebe en los lugares habituales, (que indicamos en la sección correspondiente) que ninguno de los programas propiedad del root o SUID que utiliza en su sistema, tiene un fallo de seguridad conocido que pueda ser explotado.

Nunca debe permitir que quede una shell SUID corriendo en el sistema. Si el root deja desatendida la consola durante unos instantes (recuerde, debe utilizar siempre xlock), un intruso podría escribir lo siguiente:# cp /bin/sh /tmp/cuenta-root
# chmod 4755 /tmp/cuenta-root

creándose una versión SUID de la shell sh. En el futuro, cuando el atacante ejecute ese programa, cuenta-root, ¡se convertirá en root! Si lo escondiera en un directorio oculto, la única forma de encontrarlo sería escaneando el sistema completo como se ha explicado antes.

Y recuerde, nuca escriba guiones de shell SUID.

* Seguridad del root

Los peores destrozos de un sistema es probable que no vengan de ningún cracker, o de un malévolo intruso. En muchísimas más ocasiones ha sido el propio administrador el que ha destrozado el sistema. Sí, el root. ¿Por qué? Por descuido, por exceso de confianza, por ignorancia. Evitar este problema no es difícil. Siguiendo unas fáciles normas, podrá protegerse de Vd. mismo:

No use la cuenta de root por norma. Evítela. Intente primero cualquier acción como un usuario normal, y si ve que no tiene permiso, piense porqué y use el comando su si es necesario.
Ejecute los comandos de forma segura verificando previamente la acción que va a realizar. Por ejemplo si quiere ejecutar rm borrar.*, ejecute primero ls borrar.* y si es lo que pretende modifique el mandato y ejecútelo.
Ciertos mandatos admiten una opción (-i) para actuar de forma interactiva. Actívela, si no lo está ya añadiendo estas líneas a su fichero de recursos par la shell:
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'

Siempre puede evitar estas preguntas, a veces incordiosas, con el mandato yes, cuando esté seguro de la operación que está realizando: $ yes s|rm borrar.*

Como ya deben saber, el directorio actual no está, por defecto, en la ruta de búsqueda de ejecutables (PATH). Esto garantiza que no lanzaremos, sin darnos cuenta, un ejecutable que esté en el directorio actual llamado, por ejemplo ls.
Evite que la clave del root viaje por una red sin cifrar. Utilice ssh u otro canal seguro.
Limite los terminales desde los que se puede conectar root. Es preferible limitarlo a la consola del sistema. Esto se puede decidir en /etc/securetty. Si necesita una sesión remota como root, entre como usuario normal y luego use su.
Actúe de forma lenta y meditada cuando sea root. Sus acciones podrían afectar a un montón de cosas. ¡Piénselo antes de teclear!

Hay herramientas como sudo (http://www.courtesan.com/sudo/) que permiten a ciertos usuarios utilizar comandos privilegiados sin necesidad de ser root, como montar o desmontar dispositivos. Además registra las actividades que se realizan, lo que ayuda a determinar qué hace realmente este usuario.

Enlaces relacionados:
Seguridad Básica en GNU/Linux (I Parte)
http://www.xombra.com/go_articulo.php?articulo=75

Seguridad Básica en GNU/Linux (II Parte)
http://www.xombra.com/go_articulo.php?articulo=77

Fuente:
http://iec.csic.es/criptonomicon

 



Publicado el: 28/10/2006
Visto: 784073 Veces



Imprimir PDF