Sencilla guía de seguridad en el sistema
Este documento, probablemente no esté libre de erratas, ni se distribuye con garantía alguna.
Sin embargo, es de distribución libre y gratuíta. Usélo bajo su responsabilidad.
Objetivo: Aprender las cosas básicas sobre segruridad en Debian, para saber cuidarse y protegerse.
Lo elemental, es saber el funcionamiento - a nivel usuario, al menos- del sistema operativo Debian GNU/Linux (donde se guarda la configuración, para qué sirven los permisos, donde estan los log de cada rograma, etcétera.) Aquí, auque daré una muy breve descripción, es preferible ya saberlo.
La configuración de su sistema, se guarda, para la gran mayoría de la aplicaciones en dos lugares.
En el directorio /etc, se guarda la configuración básica de un programa (tal como si debe o no cargarse al inicio, de que manera debe correr, a que usuarios estará disponible, etcétera).
Por otra parte, hay algunos programas a los que los usuarios del sistema pueden acceder normalmente, teles como navegadores web, clientes de chat, editores, shells, etcétera. Para estos programas, suele no ser suficiente la configuración de /etc, es decir, un usuario puede querer que su navegador no admita ninguna cookie, mientras que otro prefiere que se le pregunte por cada una de ellas. Esta configuración, suele almacenarse en un directorio -habitualmente oculto, o sea, de los que empiezan con .-, en el home del usuario, que suele llamarse de la misma manera del programa, por ejemplo, .mc la (se guarda la configuración del shell MC)
Consejos para un sistema más seguro:
- No use nombres de usuario que sean fácil de "embocar" por fuerza bruta como pepe, php, etc. Un ejemplo de un usuario "seguro" puede ser
jx_perezokernestok - No use contrseñas "sencillas" como
123456. Una buena contraseña es una que no empieze por un número, sea de al menos, 8 caracteres, no sea una secuencia lógica y combine mayúsculas, minúsculas, números y signos de puntuación, por ejemplo:Bq9}j5[xY - Desabilite en el archivo de ssh
/etc/ssh/sshd_configel acceso desde root, modificando la líneaPermitRootLogin, modíficándole Yes po No, y en caso de que esta línea no exista, agreguela. Debería verse algo comoPermitRootLogin No - En el archivo mencionado de ssh, reemplace en la línea
Listenel puerto habitual 22 de ss por otro, como 1462. Esto ayuda a que, si hacen un análisis de cuántos y qué puertos tenemos abiertos, le sea más difícil probar a nuestro agresor que estamos corriendo ssh. En éste archivo déle asegúrese de haberle dado el valor no a la líneaPermitEmptyPasswords, ésto puede convertir en broma la seguridad del sistema. - Además, en el anterior archivo, puede deshabilitar el login de cualquier usuario, que no sea el que especifiquemos. Ésto se hace cambiando -o agragando si no existe- a la línea
AllowUserscon el nombre de los usuarios autorizados a acceder por ssh. Ésto es útil de esta forma: piense que tiene un troyano que creo el usuario agerg98. Un atacante, puede entrar a su sistema vía ssh, usando éste usuario. En cambio, si éste usuario agerg98 no existe en ésta línea de usuarios permitidos, en teoría, no podría acceder. - En lo posible, no use telnet, pues se transmite en texto plano y es fácil que alguien capture ese usuario y contraseña y pueda, ulteriormente, ingresar a su equipo.
- Use, si lo prefiere, algún programa como
portsentry, que abre varios puertos en el equipo, siempre que no estén ya ocupados. Entonces, si un posible atacante escanéa su equipo, verá un montón de puertos abiertos, que en definitiva, no conducen a nada. Sirva para burlarse, y hacer perder tiempo a su atacante. Sea consciente de que cuantos más puertos tenga realmente abiertos, menos efectivo resultará portsentry. - Aseguresé que nadie más que root (y el grupo shadow, si lo prefire) tengan de ningún modo acceso, a: /etc/passwd, a /etc/shadow, /etc/group y /etc/gshadow.
Logs
El objetivo de este apartado, es indicar los principales logs (o registros) del sistema operativo Debian GNU/Linux
Éstos se guardan en el directorio /var/log y, para los siguientes nombres de fichero, deberá suponerse éste directorio.
auth.log: Aquí se grarda registro de TODOS los ingresos al sistema, incluyendo los intentos fallidos. Podemos ver, por ejemplo, todas las entradas correspondientes a ssh con escribirless /var/log/auth.log | grep ssh | moreapache2/access.log: Si está montando un servidor web Apache, versión 2.xx.xx, en este fichero verá todos los accesos al servidor.apache/access.log: Si está montando un servidor web Apache, versión inferior a la 2, en este fichero verá todos los accesos al servidor.apache-ssl/access.log: Si está montando un servidor web seguro Apache (conexión encriptada), en este fichero verá todos los accesos al servidor.
Si en su sistema recibe intentos de login por ssh, desde IPs de desconocidos, puede optar si así lo desea, por programas como fail2ban
Biografía:
1. Securing Debian Manual
2. Manual de Seguriad de Debian
3. Guia de Seguridad en Red
Enviado por tazok el 17 Octubre, 2005 - 16:55.
En el archivo mencionado de ssh, reemplace en la línea Listen el puerto habitual 22 de ss por otro, como 1462. Esto ayuda a que, si hacen un análisis de cuántos y qué puertos tenemos abiertos, le sea más difícil probar a nuestro agresor que estamos corriendo ssh.
Ésto es seguridad por oscuridad y es MUY mala idea. Primero, para ver que hay escuchando en qué puerto es tan simple como hacer un "telnet ip puerto". Hay que evitar la falsa sensación de seguridad que proporciona ésto. Para asegurar un servicio hay que:
a) enjaularlo
b) reducir los privilegios que utiliza vía linux capabilities por ejemplo.
c) utilizar pax para los buffer overflows.
# Aseguresé que nadie más que root (y el grupo shadow, si lo prefire) tengan de ningún modo acceso, a: /etc/passwd, a /etc/shadow, /etc/group y /etc/gshadow.
Por defecto nunca se permite. Como siempre un usuario que explote un servicio cargado por el superusuario no necesitará de acceso al archivo de contraseñas. Moraleja: NO poner a la escucha servidores si no se sabe lo que se está haciendo.
Además, en el anterior archivo, puede deshabilitar el login de cualquier usuario, que no sea el que especifiquemos. Ésto se hace cambiando -o agragando si no existe- a la línea AllowUsers con el nombre de los usuarios autorizados a acceder por ssh. Ésto es útil de esta forma: piense que tiene un troyano que creo el usuario agerg98. Un atacante, puede entrar a su sistema vía ssh, usando éste usuario. En cambio, si éste usuario agerg98 no existe en ésta línea de usuarios permitidos, en teoría, no podría acceder.
Si alguien o algo ha conseguido permisos de superusuario lo último que debería preocuparnos es que cree una cuenta de usuario. Podría hasta sobreescribir la interfaz de llamadas al sistema e incluso que el kernel pusiera a la escucha un demonio oculto de todas las aplicaciones de usuario como puerta trasera(sin necesidad de troyanizarlas) en la que respondiera a cierta contraseña y que por ejemplo permitiera a cierto nick (no presente en el archivo shadow) acceder con permisos de superusuario.Con permisos de superusuario todo es cuestión de imaginación. Moraleja: Si acceden como superusuario reinstala
---
"Don't accept that what's happening;
Is just a case of others' suffering;
Or you'll find that you're joining in
-Pink Floyd- On the turning away.
Enviado por chacal el 18 Octubre, 2005 - 13:07.
Respuesta a En el archivo mencionado de
-
Ésto es seguridad por oscuridad y es MUY mala idea. Primero, para ver que hay escuchando en qué puerto es tan simple como hacer un "telnet ip puerto". Hay que evitar la falsa sensación de seguridad que proporciona ésto. Para asegurar un servicio hay que:
a) enjaularlo
b) reducir los privilegios que utiliza vía linux capabilities por ejemplo.
c) utilizar pax para los buffer overflows.
La seguridad por oscuridad es mala idea si "solo" usamos esa seguridad. Si se usa como complemento es muy útil sobre todo para evitar bots y usuarios malintencionados con escasos conocimientos. Pero también es util en otros aspectos muy relacionados con los anteriores, y es para evitar procedimientos directos de ataque, porque primero necesitarán saber en que puerto está el servicio, y ese escaneo les delatará.
salu2
pd: ahora bien, hay que configurar un buen aids
---
www.yawag.org y mi blog - www.yawag.org/chacal
Enviado por tazok el 20 Octubre, 2005 - 13:08.
Respuesta a
Ésto es seguridad por oscuridad
La seguridad por oscuridad es mala idea si "solo" usamos esa seguridad. Si se usa como complemento es muy útil sobre todo para evitar bots y usuarios malintencionados con escasos conocimientos. Pero también es util en otros aspectos muy relacionados con los anteriores, y es para evitar procedimientos directos de ataque, porque primero necesitarán saber en que puerto está el servicio, y ese escaneo les delatará.
La seguridad por oscuridad NO es seguridad. Además genera una falsa sensación de seguridad a todas luces peligrosa. Todos los servicios deben asegurarse como si formaran parte un anillo, es decir, primero la parte interna (kernel, control de accesos) y la parte externa del anillo (la que está en contacto con internet) debe ser la última en ser asegurada. Es muy parecido a un modelo de código abierto, no utiliza la seguridad por oscuridad (al contrario que el software propietario) por lo dicho antes, comenzando su seguridad en su parte interna (corrección de gran cantidad de fallos por parte de programadores) y no en la ocultación de éstos.
Los escaneos pueden realizarse de forma oculta (no creo que un scanner con una frecuencia de pruebas realmente baja sea fácilmente detectado por un ids).
Moraleja: No prepares los sistemas contra los scripts-kiddies, prepáralos contra todos y esa preparación hará de sus bots inútiles. ;)
---
"Don't accept that what's happening;
Is just a case of others' suffering;
Or you'll find that you're joining in
-Pink Floyd- On the turning away.
Enviado por chacal el 21 Octubre, 2005 - 18:34.
Respuesta a La seguridad por oscuridad es
La seguridad por oscuridad NO es seguridad.
ok.
Además genera una falsa sensación de seguridad a todas luces peligrosa.
Es lo que comentaba antes, seguridad por oscuridad por si sola no, xq tarde o temprano caerá.
Es muy parecido a un modelo de código abierto, no utiliza la seguridad por oscuridad (al contrario que el software propietario) por lo dicho antes, comenzando su seguridad en su parte interna (corrección de gran cantidad de fallos por parte de programadores) y no en la ocultación de éstos.
No, no es lo mismo. Una analogía sería decir que es más dificil acertar a un blanco movil que a uno fijo. En este caso nadie te está impidiendo nada, simplemente se está "ocultando" a ojos que no saben mirar.
Los escaneos pueden realizarse de forma oculta (no creo que un scanner con una frecuencia de pruebas realmente baja sea fácilmente detectado por un ids).
Simplemente con que te hagan un ssh al 22, estado en otro puerto, ya has caido en la trampa. (Prueba el portsentry, te lo recomiendo)
Moraleja: No prepares los sistemas contra los scripts-kiddies, prepáralos contra todos y esa preparación hará de sus bots inútiles. ;)
Si, pero el tocho de logs te lo comes como un bendito... cosa que podrías evitar (así como la carga de red...).
salu2!!
---
www.yawag.org y mi blog - www.yawag.org/chacal
Enviado por RicardoIVieitez el 26 Octubre, 2005 - 16:19.
Respuesta a La seguridad por oscuridad es
<i>Los escaneos pueden realizarse de forma oculta (no creo que un scanner con una frecuencia de pruebas realmente baja sea fácilmente detectado por un ids).</i><br><br>
Sí (por ejemplo con la opción -sS, cmo root en nmap), pero así verán sólo los puertos que están abiertos.<br>
Para saber que tienes corriendo, ya existirá log (lo he probado contra mi propio sistema).
---
When you think only about yourself, you'll destroy world around all, making all equal time...


