Seguridad en Servidores Debian

René Mayorga

                      rmayorga@debian.org

Comunidad de usuarios Debian de El Salvador

6 de marzo de 2009

rmayorga (Comunidad de usuarios Debian de El Salvador) Seguridad en Servidores Debian  6 de marzo de 2009  1 / 41

Esquema

1 Introducción
2 Planeación
3 Selección de software
4 Asegurando los usuarios

Software para controlar amenazas locales

5 SSH
6 Alimentando la paranoía
7 Comentarios, sugerencias, experiencias

Introducción

Seguridad

¿Cuál es la mejor técnica de seguridad disponible?

¿Ideas?

La mejor técnica de seguridad: Consiste simplemente en desconectar el cable de energía, y ni aún así podemos estar 100 por ciento seguros, pues todavía existen datos en nuestro disco que podrían ser comprometidos por cualquier técnica.

Pero a pesar de todo, todavía resulta una de las mejores técnicas para mantener seguro mi equipo.

Trataremos de ver un par de ideas que pueden hacer que duerma más tranquilo.

Seguridad

¿Cuál es la mejor técnica de seguridad disponible?

¿Ideas?

La mejor técnica de seguridad: Consiste simplemente en desconectar el cable de energía, y ni aún así podemos estar 100 por ciento seguros, pues todavía existen datos en nuestro disco que podrían ser comprometidos por cualquier técnica.

Pero a pesar de todo, todavía resulta una de las mejores técnicas para mantener seguro mi equipo.

Trataremos de ver un par de ideas que pueden hacer que duerma más tranquilo.

Seguridad

¿Cuál es la mejor técnica de seguridad disponible?

¿Ideas?

La mejor técnica de seguridad: Consiste simplemente en desconectar el cable de energía, y ni aún así podemos estar 100 por ciento seguros, pues todavía existen datos en nuestro disco que podrían ser comprometidos por cualquier técnica.

Pero a pesar de todo, todavía resulta una de las mejores técnicas para mantener seguro mi equipo.

Trataremos de ver un par de ideas que pueden hacer que duerma más tranquilo.

Seguridad

¿Cuál es la mejor técnica de seguridad disponible?

¿Ideas?

La mejor técnica de seguridad: Consiste simplemente en desconectar el cable de energía, y ni aún así podemos estar 100 por ciento seguros, pues todavía existen datos en nuestro disco que podrían ser comprometidos por cualquier técnica.

Pero a pesar de todo, todavía resulta una de las mejores técnicas para mantener seguro mi equipo.

Trataremos de ver un par de ideas que pueden hacer que duerma más tranquilo.

Planeación

Pensando antes que todo

¿Cuál será la función principal del servidor?

Es necesario saber que *que* quiero hacer Esto influye directamente en las aplicaciones y la manera como voy a instalar el servidor. Ejemplo: Para que necesito gnome o KDE en un servidor de correo ?

Recordemos, en el caso especifico de Debian, existe un sistema base, que contiene lo necesario, luego de eso, es tarea del administrador instalar lo

que requiere para su trabajo.

En otras palabras, *NO* usemos tasksel

Pensando antes que todo

¿Cuál será la función principal del servidor?

Es necesario saber que *que* quiero hacer Esto influye directamente en las aplicaciones y la manera como voy a instalar el servidor. Ejemplo: Para que necesito gnome o KDE en un servidor de correo ?

Recordemos, en el caso especifico de Debian, existe un sistema base, que contiene lo necesario, luego de eso, es tarea del administrador instalar lo

que requiere para su trabajo.

En otras palabras, *NO* usemos tasksel

Pensando antes que todo

¿Cuál será la función principal del servidor?

Es necesario saber que *que* quiero hacer Esto influye directamente en las aplicaciones y la manera como voy a instalar el servidor. Ejemplo: Para que necesito gnome o KDE en un servidor de correo ?

Recordemos, en el caso especifico de Debian, existe un sistema base, que contiene lo necesario, luego de eso, es tarea del administrador instalar lo

que requiere para su trabajo.

En otras palabras, *NO* usemos tasksel

Pensando antes que todo

¿Cuál será la función principal del servidor?

Es necesario saber que *que* quiero hacer Esto influye directamente en las aplicaciones y la manera como voy a instalar el servidor. Ejemplo: Para que necesito gnome o KDE en un servidor de correo ?

Recordemos, en el caso especifico de Debian, existe un sistema base, que contiene lo necesario, luego de eso, es tarea del administrador instalar lo

que requiere para su trabajo.

En otras palabras, *NO* usemos tasksel

Pensando antes que todo

Recordemos desactivar Recommends, Justo después de instalar el servidor con el sistema base

Como?

  apt-config dump | grep Recom \
| sed 's/1/0/' > /etc/apt/apt.conf.d/02user

Pensando antes que todo

Recordemos desactivar Recommends, Justo después de instalar el servidor con el sistema base

Como?

  apt-config dump | grep Recom \
| sed 's/1/0/' > /etc/apt/apt.conf.d/02user

Pensando antes que todo

Recordemos desactivar Recommends, Justo después de instalar el servidor con el sistema base

Como?

  apt-config dump | grep Recom \
| sed 's/1/0/' > /etc/apt/apt.conf.d/02user

Planeación

planeando mis Particiones

¿Para qué hago diferentes particiones en mi OS ? ¿Ideas?

Con las particiones puedo manejar permisos, y hacer mi sistema mucho mas seguro es decir, asegurarme que después de mi instalación no se pueda instalar nuevo software. A menos que el administrador lo requiera.

¿Para qué hago diferentes particiones en mi OS ? ¿Ideas?

Con las particiones puedo manejar permisos, y hacer mi sistema mucho mas seguro es decir, asegurarme que después de mi instalación no se pueda instalar nuevo software. A menos que el administrador lo requiera.

¿Para qué hago diferentes particiones en mi OS ? ¿Ideas?

Con las particiones puedo manejar permisos, y hacer mi sistema mucho mas seguro es decir, asegurarme que después de mi instalación no se pueda instalar nuevo software. A menos que el administrador lo requiera.

¿Cómo esta eso de la seguridad en las particiones?

a, ver, si ejecutamos man mount Podemos ver algunas cosas interesantes, como :

        rw     Mount the file system read-write.
[.....]
        ro     Mount the file system read-only.
[....]
        exec   Permit execution of binaries.
[.....]
noexec  Do not  allow  direct  execution
       of any binaries.

Pero, pero!, yo ya conocía desde antes esa opciones!.

¿Cómo esta eso de la seguridad en las particiones?

a, ver, si ejecutamos man mount Podemos ver algunas cosas interesantes, como :

        rw     Mount the file system read-write.
[.....]
        ro     Mount the file system read-only.
[....]
        exec   Permit execution of binaries.
[.....]
noexec  Do not  allow  direct  execution
       of any binaries.

Pero, pero!, yo ya conocía desde antes esa opciones!.

Planeación

Veamos lo de las particiones

Pensemos en un esquema de particiones básicas:

Figura: siempre /

rmayorga (Comunidad de usuarios Debian de El Salvador) Seguridad en Servidores Debian  6 de marzo de 2009  8 / 41

Planeación

Veamos lo de las particiones

Planeación

y la seguridad

Pero que tiene que ver todo esto con la seguridad ?

Figura: que hago con esa partición

Pero que tiene que ver todo esto con la seguridad ?

Figura: que hago con esa partición

Particionando para hacer mi servidor seguro

Entonces, puedo tener una configuración que evite:

A un usuario común y silvestre descargar un código (exploit) y luego de compilarlo, ejecutarlo en su home o /tmp un programa instalado no podría descargar ni modificar bibliotecas del sistema, pues puedo mantener /usr/lib y /lib montados con ro no se podrían agregar programas nuevos o modificar programas en /bin, /sbin, /usr/bin, /usr/sbin, solo el administrador

La idea es simple, solo root usando mount -o remount puede alterar los flags para ejecutar o tomar alguna acción, luego volver al estado anterior para que el usuario no pueda tomar ventaja de algún exploit para escalabilidad de permisos.

Particionando para hacer mi servidor seguro

Entonces, puedo tener una configuración que evite:

A un usuario común y silvestre descargar un código (exploit) y luego de compilarlo, ejecutarlo en su home o /tmp un programa instalado no podría descargar ni modificar bibliotecas del sistema, pues puedo mantener /usr/lib y /lib montados con ro no se podrían agregar programas nuevos o modificar programas en /bin, /sbin, /usr/bin, /usr/sbin, solo el administrador

La idea es simple, solo root usando mount -o remount puede alterar los flags para ejecutar o tomar alguna acción, luego volver al estado anterior para que el usuario no pueda tomar ventaja de algún exploit para escalabilidad de permisos.

Particionando para hacer mi servidor seguro

Entonces, puedo tener una configuración que evite:

A un usuario común y silvestre descargar un código (exploit) y luego de compilarlo, ejecutarlo en su home o /tmp un programa instalado no podría descargar ni modificar bibliotecas del sistema, pues puedo mantener /usr/lib y /lib montados con ro no se podrían agregar programas nuevos o modificar programas en /bin, /sbin, /usr/bin, /usr/sbin, solo el administrador

La idea es simple, solo root usando mount -o remount puede alterar los flags para ejecutar o tomar alguna acción, luego volver al estado anterior para que el usuario no pueda tomar ventaja de algún exploit para escalabilidad de permisos.

Particionando para hacer mi servidor seguro

Entonces, puedo tener una configuración que evite:

A un usuario común y silvestre descargar un código (exploit) y luego de compilarlo, ejecutarlo en su home o /tmp un programa instalado no podría descargar ni modificar bibliotecas del sistema, pues puedo mantener /usr/lib y /lib montados con ro no se podrían agregar programas nuevos o modificar programas en /bin, /sbin, /usr/bin, /usr/sbin, solo el administrador

La idea es simple, solo root usando mount -o remount puede alterar los flags para ejecutar o tomar alguna acción, luego volver al estado anterior para que el usuario no pueda tomar ventaja de algún exploit para escalabilidad de permisos.

Particionando para hacer mi servidor seguro

Entonces, puedo tener una configuración que evite:

A un usuario común y silvestre descargar un código (exploit) y luego de compilarlo, ejecutarlo en su home o /tmp un programa instalado no podría descargar ni modificar bibliotecas del sistema, pues puedo mantener /usr/lib y /lib montados con ro no se podrían agregar programas nuevos o modificar programas en /bin, /sbin, /usr/bin, /usr/sbin, solo el administrador

La idea es simple, solo root usando mount -o remount puede alterar los flags para ejecutar o tomar alguna acción, luego volver al estado anterior para que el usuario no pueda tomar ventaja de algún exploit para escalabilidad de permisos.

Selección de software

Seleccionando mi software

Primero recordando *NO* usar taskel en la instalación

luego, una vez instalado el OS podemos decirle a APT que no instale Recommends por defecto, de esta manera nos aseguramos que el software instalado en el Servidor sea solo lo necesario y las dependencias correctas.

Para esto ejecuto:

apt-config dump | grep Recom | sed 's/1/0/' > \
/etc/apt/apt.conf.d/05userconf

Software a instalar

La idea es mantener *solo* el software necesario. Por defecto en Debian muchos servicios se encuentran desactivados y las configuraciones por defecto son básicas, por lo que es bueno solo instalar software necesario.

Asegurando los usuarios

los usuarios......

El mayor problema de seguridad, la mayor amenaza potencial, y el mayor riesgo de botar todo mi esquema de seguridad, son sin duda alguno los

propios usuarios.

por tanto existen varias opciones a tomar en cuenta, primero, preguntarme:

Necesita un shell en el sistema? que servicios podrán estar disposibles a todos los usuarios voy a necesitar comportamé como un BOFH ?

los usuarios......

El mayor problema de seguridad, la mayor amenaza potencial, y el mayor riesgo de botar todo mi esquema de seguridad, son sin duda alguno los

propios usuarios.

por tanto existen varias opciones a tomar en cuenta, primero, preguntarme:

Necesita un shell en el sistema? que servicios podrán estar disposibles a todos los usuarios voy a necesitar comportamé como un BOFH ?

los usuarios......

El mayor problema de seguridad, la mayor amenaza potencial, y el mayor riesgo de botar todo mi esquema de seguridad, son sin duda alguno los

propios usuarios.

por tanto existen varias opciones a tomar en cuenta, primero, preguntarme:

Necesita un shell en el sistema? que servicios podrán estar disposibles a todos los usuarios voy a necesitar comportamé como un BOFH ?

los usuarios......

El mayor problema de seguridad, la mayor amenaza potencial, y el mayor riesgo de botar todo mi esquema de seguridad, son sin duda alguno los

propios usuarios.

por tanto existen varias opciones a tomar en cuenta, primero, preguntarme:

Necesita un shell en el sistema? que servicios podrán estar disposibles a todos los usuarios voy a necesitar comportamé como un BOFH ?

los usuarios......

El mayor problema de seguridad, la mayor amenaza potencial, y el mayor riesgo de botar todo mi esquema de seguridad, son sin duda alguno los

propios usuarios.

por tanto existen varias opciones a tomar en cuenta, primero, preguntarme:

Necesita un shell en el sistema? que servicios podrán estar disposibles a todos los usuarios voy a necesitar comportamé como un BOFH ?

Asegurando los usuarios

ahora después de decidir

pues el usuario podrá entrar, ahora a pensar como hago para que no me arruine la vida

Asegurando los usuarios Software para controlar amenazas locales

Pensemos que software vamos a usar

cracklib Cracklib2 es una librería en C, su función principal es prevenir al usuario usar passwords sencillos. Existe un módulo para PAM, llamado libpam-cracklib

cracklib

Una vez instalado libpam-cracklib simplemente es necesario editar mi configuración de PAM.

$EDITOR /etc/pam.d/common-password
password   required   pam_cracklib.so minlen=6 lcredit=0 \
ucredit=-1 dcredit=-1 ocredit=0  retry=3

Asegurando los usuarios Software para controlar amenazas locales

cracklib

La documentación la pueden encontrar con man 8 pam cracklib pero, resumiendo PAM-cracklib acepta algunas de estas opciones

retry, errores del usuario minlen=N, número de caracteres minimos para los passwords dcredit=N, número de caracteres númericos requeridos ucredit=N, letras Mayúsculas lcredit=N, letras minúsculas ocredit=N, Otros caracteres La documentación la pueden encontrar con man 8 pam cracklib pero, resumiendo PAM-cracklib acepta algunas de estas opciones

retry, errores del usuario minlen=N, número de caracteres minimos para los passwords dcredit=N, número de caracteres númericos requeridos ucredit=N, letras Mayúsculas lcredit=N, letras minúsculas ocredit=N, Otros caracteres La documentación la pueden encontrar con man 8 pam cracklib pero, resumiendo PAM-cracklib acepta algunas de estas opciones

retry, errores del usuario minlen=N, número de caracteres minimos para los passwords dcredit=N, número de caracteres númericos requeridos ucredit=N, letras Mayúsculas lcredit=N, letras minúsculas ocredit=N, Otros caracteres La documentación la pueden encontrar con man 8 pam cracklib pero, resumiendo PAM-cracklib acepta algunas de estas opciones

retry, errores del usuario minlen=N, número de caracteres minimos para los passwords dcredit=N, número de caracteres númericos requeridos ucredit=N, letras Mayúsculas lcredit=N, letras minúsculas ocredit=N, Otros caracteres La documentación la pueden encontrar con man 8 pam cracklib pero, resumiendo PAM-cracklib acepta algunas de estas opciones

retry, errores del usuario minlen=N, número de caracteres minimos para los passwords dcredit=N, número de caracteres númericos requeridos ucredit=N, letras Mayúsculas lcredit=N, letras minúsculas ocredit=N, Otros caracteres La documentación la pueden encontrar con man 8 pam cracklib pero, resumiendo PAM-cracklib acepta algunas de estas opciones

retry, errores del usuario minlen=N, número de caracteres minimos para los passwords dcredit=N, número de caracteres númericos requeridos ucredit=N, letras Mayúsculas lcredit=N, letras minúsculas ocredit=N, Otros caracteres La documentación la pueden encontrar con man 8 pam cracklib pero, resumiendo PAM-cracklib acepta algunas de estas opciones

retry, errores del usuario minlen=N, número de caracteres minimos para los passwords dcredit=N, número de caracteres númericos requeridos ucredit=N, letras Mayúsculas lcredit=N, letras minúsculas ocredit=N, Otros caracteres La documentación la pueden encontrar con man 8 pam cracklib pero, resumiendo PAM-cracklib acepta algunas de estas opciones

retry, errores del usuario minlen=N, número de caracteres minimos para los passwords dcredit=N, número de caracteres númericos requeridos ucredit=N, letras Mayúsculas lcredit=N, letras minúsculas ocredit=N, Otros caracteres

/etc/shadow

En /etc/shadow se guarda mucha información referente a los usuarios y sus passwords, por ejemplo, la última fecha de cambio de password el

tiempo necesario para que el password expire, etc.

Esto es un taller ¿verdad?

Entonces, todo a leer man 5 shadow

/etc/shadow

En /etc/shadow se guarda mucha información referente a los usuarios y sus passwords, por ejemplo, la última fecha de cambio de password el

tiempo necesario para que el password expire, etc.

Esto es un taller ¿verdad?

Entonces, todo a leer man 5 shadow

/etc/shadow

En /etc/shadow se guarda mucha información referente a los usuarios y sus passwords, por ejemplo, la última fecha de cambio de password el

tiempo necesario para que el password expire, etc.

Esto es un taller ¿verdad?

Entonces, todo a leer man 5 shadow

/etc/passwd

Si hacemos un cat /etc/passwd podemos ver algo interesante

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh

rmayorga (Comunidad de usuarios Debian de El Salvador) Seguridad en Servidores Debian  6 de marzo de 2009  26 / 41

/etc/passwd

Si hacemos un cat /etc/passwd podemos ver algo interesante

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh

rmayorga (Comunidad de usuarios Debian de El Salvador) Seguridad en Servidores Debian  6 de marzo de 2009  26 / 41

Asegurando los usuarios Software para controlar amenazas locales

/etc/passwd

Estos usuarios necesitan tener shell ?

Entonces, a quitarlo, como root, cambiemos esos /bin/sh por /bin/false

rmayorga (Comunidad de usuarios Debian de El Salvador) Seguridad en Servidores Debian  6 de marzo de 2009  27 / 41

Asegurando los usuarios Software para controlar amenazas locales

/etc/passwd

Estos usuarios necesitan tener shell ?

Entonces, a quitarlo, como root, cambiemos esos /bin/sh por /bin/false

rmayorga (Comunidad de usuarios Debian de El Salvador) Seguridad en Servidores Debian  6 de marzo de 2009  27 / 41

Grupo Wheel

Wheel es un grupo común en algunos UNIXs como BSD pero en GNU/Linux no se encuentra por defecto este famoso grupo.

¿Alguien sabe que hace Wheel?

Básicamente en un UNIX, se permite a cualquier usuario que se encuentre dentro del grupo Wheel ejecutar su. Si el usuario no esta en Wheel aunque tenga conocimiento del password de otro usuario(incluido root) no podra hacer su

Grupo Wheel

Wheel es un grupo común en algunos UNIXs como BSD pero en GNU/Linux no se encuentra por defecto este famoso grupo.

¿Alguien sabe que hace Wheel?

Básicamente en un UNIX, se permite a cualquier usuario que se encuentre dentro del grupo Wheel ejecutar su. Si el usuario no esta en Wheel aunque tenga conocimiento del password de otro usuario(incluido root) no podra hacer su

Grupo Wheel

Wheel es un grupo común en algunos UNIXs como BSD pero en GNU/Linux no se encuentra por defecto este famoso grupo.

¿Alguien sabe que hace Wheel?

Básicamente en un UNIX, se permite a cualquier usuario que se encuentre dentro del grupo Wheel ejecutar su. Si el usuario no esta en Wheel aunque tenga conocimiento del password de otro usuario(incluido root) no podra hacer su

Por que Wheel no existe en GNU/Linux y si en BSD

” A veces, algunos listillos intentan hacerse con el poder total sobre el resto de usuarios. Por ejemplo, en 1984, un grupo de usuarios del laboratorio de Inteligencia Artificial del MIT decidieron tomar el poder cambiando el password de operador del sistema Twenex y manteniendolo secreto para el resto de usuarios. (De todas maneras, hubiera sido posible desbaratar la situacin y devolver el control a los usuario legtimos parcheando el kernel, pero no sabra como realizar esta operacin en un sistema Unix.) ”

– Richard M. Stallman, Manual de GNU su (man 1 su)

Por que Wheel no existe en GNU/Linux y si en BSD

” A veces, algunos listillos intentan hacerse con el poder total sobre el resto de usuarios. Por ejemplo, en 1984, un grupo de usuarios del laboratorio de Inteligencia Artificial del MIT decidieron tomar el poder cambiando el password de operador del sistema Twenex y manteniendolo secreto para el resto de usuarios. (De todas maneras, hubiera sido posible desbaratar la situacin y devolver el control a los usuario legtimos parcheando el kernel, pero no sabra como realizar esta operacin en un sistema Unix.) ”

– Richard M. Stallman, Manual de GNU su (man 1 su)

Asegurando los usuarios Software para controlar amenazas locales

No me interesan las experiencias juveniles de RMS, yo quiero Wheel!

Fácil, simplemente editamos /etc/pam.d/su y quitamos el comentario

  auth       required   pam_wheel.so

Después de esto, nada mas es necesario asegurarnos de agregar a los usuarios al grupo wheel (si el grupo no existe, no llore, créelo!)

Fácil, simplemente editamos /etc/pam.d/su y quitamos el comentario

  auth       required   pam_wheel.so

Después de esto, nada mas es necesario asegurarnos de agregar a los usuarios al grupo wheel (si el grupo no existe, no llore, créelo!)

Fácil, simplemente editamos /etc/pam.d/su y quitamos el comentario

  auth       required   pam_wheel.so

Después de esto, nada mas es necesario asegurarnos de agregar a los usuarios al grupo wheel (si el grupo no existe, no llore, créelo!)

ROOT no se debe de usar

Puedo restringir los dispositivos tty en los cuales root puede hacer login es decir, puedo dejar que root *solo* se pueda logear en /dev/tty5. Esto se

puede hacer usando el archivo /etc/securetty

También debo evitar vivir validado en el sistema como root, en Debian, existe el grupo adm si yo soy el administrador del sistema puedo agregar mi usuario al grupo adm de esta forma podre revisar los logs del sistema, sin necesidad de estar como root.

ROOT no se debe de usar

Puedo restringir los dispositivos tty en los cuales root puede hacer login es decir, puedo dejar que root *solo* se pueda logear en /dev/tty5. Esto se

puede hacer usando el archivo /etc/securetty

También debo evitar vivir validado en el sistema como root, en Debian, existe el grupo adm si yo soy el administrador del sistema puedo agregar mi usuario al grupo adm de esta forma podre revisar los logs del sistema, sin necesidad de estar como root.

SSH

necesito ssh, pero quiero dormir tranquilo

ssh puede ser nuestro mejor amigo, o nuestro peor enemigo. Por ejemplo, tener ssh abierto a todo mundo es un problema, pues soy un destino para script kiddies y ataques de fuerza bruta.

SSH

necesito ssh, pero quiero dormir tranquilo

ssh puede ser nuestro mejor amigo, o nuestro peor enemigo. Por ejemplo, tener ssh abierto a todo mundo es un problema, pues soy un destino para script kiddies y ataques de fuerza bruta.

SSH

TIPS para SSH

Un par de cosas útiles:

Deshabilitar el login con root No esconder el puerto, eso no funciona ni ayuda usar timeout *SOLO* permitir ssh v2

Un par de cosas útiles:

Deshabilitar el login con root No esconder el puerto, eso no funciona ni ayuda usar timeout *SOLO* permitir ssh v2

Un par de cosas útiles:

Deshabilitar el login con root No esconder el puerto, eso no funciona ni ayuda usar timeout *SOLO* permitir ssh v2

Un par de cosas útiles:

Deshabilitar el login con root No esconder el puerto, eso no funciona ni ayuda usar timeout *SOLO* permitir ssh v2

SSH

Defendiendome de script kiddies que usan fuerza bruta

Algún que otro software útil:

fail2ban sshguard auth2db scponly

Algún que otro software útil:

fail2ban sshguard auth2db scponly

Algún que otro software útil:

fail2ban sshguard auth2db scponly

Algún que otro software útil:

fail2ban sshguard auth2db scponly

Algún que otro software útil:

fail2ban sshguard auth2db scponly

Alimentando la paranoía

Auditando

Existe una gran cantidad de aplicaciones disponibles, que me pueden ayudar a monitorear mis logs, esto da sin duda una mejor perspectiva de

que pasa en el sistema.

multitail acct fail2ban syslog samhain

Alimentando la paranoía

Auditando

Como buen BOFH necesito ejecutar de cuando en cuando comandos que me permitan ver como esta todo

algunos:

ps -fea me puede ayudar para ver que hay interesante se tienen que buscar procesos con SETUID de root y cosas raras netstat -puta me puede ayudar a ver que pasa en mi red si existen conexiones raras y cosas as, es bueno borrarlas o quitarlas last, w, who, history son una manía muy buena en cada login

Auditando

Como buen BOFH necesito ejecutar de cuando en cuando comandos que me permitan ver como esta todo

algunos:

ps -fea me puede ayudar para ver que hay interesante se tienen que buscar procesos con SETUID de root y cosas raras netstat -puta me puede ayudar a ver que pasa en mi red si existen conexiones raras y cosas as, es bueno borrarlas o quitarlas last, w, who, history son una manía muy buena en cada login

Auditando

Como buen BOFH necesito ejecutar de cuando en cuando comandos que me permitan ver como esta todo

algunos:

ps -fea me puede ayudar para ver que hay interesante se tienen que buscar procesos con SETUID de root y cosas raras netstat -puta me puede ayudar a ver que pasa en mi red si existen conexiones raras y cosas as, es bueno borrarlas o quitarlas last, w, who, history son una manía muy buena en cada login

Auditando

Como buen BOFH necesito ejecutar de cuando en cuando comandos que me permitan ver como esta todo

algunos:

ps -fea me puede ayudar para ver que hay interesante se tienen que buscar procesos con SETUID de root y cosas raras netstat -puta me puede ayudar a ver que pasa en mi red si existen conexiones raras y cosas as, es bueno borrarlas o quitarlas last, w, who, history son una manía muy buena en cada login

Auditando

Como buen BOFH necesito ejecutar de cuando en cuando comandos que me permitan ver como esta todo

algunos:

ps -fea me puede ayudar para ver que hay interesante se tienen que buscar procesos con SETUID de root y cosas raras netstat -puta me puede ayudar a ver que pasa en mi red si existen conexiones raras y cosas as, es bueno borrarlas o quitarlas last, w, who, history son una manía muy buena en cada login

Root no es necesario

En mi caso, como BOFH, rara vez necesito hacer su o sudo ( si usar sudo es buena idea ) es un mito que root es necesario por ejemplo, si ejecuto

ls -l /var/log/*.log

Puedo ver que todos los logs pertenecen al grupo adm, por lo que si agrego a un usuario a ese grupo, este usuario puede leer y hacer debug con

logs, sin necesidad de ser root

Root no es necesario

En mi caso, como BOFH, rara vez necesito hacer su o sudo ( si usar sudo es buena idea ) es un mito que root es necesario por ejemplo, si ejecuto

ls -l /var/log/*.log

Puedo ver que todos los logs pertenecen al grupo adm, por lo que si agrego a un usuario a ese grupo, este usuario puede leer y hacer debug con

logs, sin necesidad de ser root

Root no es necesario

En mi caso, como BOFH, rara vez necesito hacer su o sudo ( si usar sudo es buena idea ) es un mito que root es necesario por ejemplo, si ejecuto

ls -l /var/log/*.log

Puedo ver que todos los logs pertenecen al grupo adm, por lo que si agrego a un usuario a ese grupo, este usuario puede leer y hacer debug con

logs, sin necesidad de ser root

los chroot son mis amigos

Si, los chroot son fáciles de crear, no requieren mucho y son buena carne de cañon por ejemplo, pongamos un chroot para apache

# mkdir -p /srv/chroot/apache
# debootstrap lenny /srv/chroot/apache
...
...
# cd chroot/dev/
# cp /dev/MAKEDEV . && ./MAKEDEV generic && cd ..
# mount -t devpts devpts /dev/pts
# mount -t proc proc proc/
# cd && chroot /srv/chroot/apache
# apt-get install apache2

Listo, ahora, en el web http://localhost recuerde que apache no puede estar en el mismo host usando el mismo puerto :)

ahora un par de recomendaciones....

rmayorga (Comunidad de usuarios Debian de El Salvador) Seguridad en Servidores Debian  6 de marzo de 2009  38 / 41

los chroot son mis amigos

Si, los chroot son fáciles de crear, no requieren mucho y son buena carne de cañon por ejemplo, pongamos un chroot para apache

# mkdir -p /srv/chroot/apache
# debootstrap lenny /srv/chroot/apache
...
...
# cd chroot/dev/
# cp /dev/MAKEDEV . && ./MAKEDEV generic && cd ..
# mount -t devpts devpts /dev/pts
# mount -t proc proc proc/
# cd && chroot /srv/chroot/apache
# apt-get install apache2

Listo, ahora, en el web http://localhost recuerde que apache no puede estar en el mismo host usando el mismo puerto :)

ahora un par de recomendaciones....

rmayorga (Comunidad de usuarios Debian de El Salvador) Seguridad en Servidores Debian  6 de marzo de 2009  38 / 41

los chroot son mis amigos

Si, los chroot son fáciles de crear, no requieren mucho y son buena carne de cañon por ejemplo, pongamos un chroot para apache

# mkdir -p /srv/chroot/apache
# debootstrap lenny /srv/chroot/apache
...
...
# cd chroot/dev/
# cp /dev/MAKEDEV . && ./MAKEDEV generic && cd ..
# mount -t devpts devpts /dev/pts
# mount -t proc proc proc/
# cd && chroot /srv/chroot/apache
# apt-get install apache2

Listo, ahora, en el web http://localhost recuerde que apache no puede estar en el mismo host usando el mismo puerto :)

ahora un par de recomendaciones....

rmayorga (Comunidad de usuarios Debian de El Salvador) Seguridad en Servidores Debian  6 de marzo de 2009  38 / 41

chroots, recomendaciones

Recuerde configurar sus locales y todo, como en un servidor nuevo puedo poner ssh a escuchar en un puerto X o puede también ponerlo dentro de un screen o automatizar el mount de dev y proc y hacer un script que lo haga todo en el arranque.

Puedo poner varios servicios, usar diferentes ramas de la distro y cuando algo pase, simplemente copio mis configuraciones, creo otro chroot nuevo, y listo :), es más fácil de hacer backup también

chroots, recomendaciones

Recuerde configurar sus locales y todo, como en un servidor nuevo puedo poner ssh a escuchar en un puerto X o puede también ponerlo dentro de un screen o automatizar el mount de dev y proc y hacer un script que lo haga todo en el arranque.

Puedo poner varios servicios, usar diferentes ramas de la distro y cuando algo pase, simplemente copio mis configuraciones, creo otro chroot nuevo, y listo :), es más fácil de hacer backup también

chroots, recomendaciones

Recuerde configurar sus locales y todo, como en un servidor nuevo puedo poner ssh a escuchar en un puerto X o puede también ponerlo dentro de un screen o automatizar el mount de dev y proc y hacer un script que lo haga todo en el arranque.

Comentarios, sugerencias, experiencias

últimos detalles

Puedo poner varios servicios, usar diferentes ramas de la distro y cuando algo pase, simplemente copio mis configuraciones, creo otro chroot nuevo, y listo :), es más fácil de hacer backup también Recordemos, siempre vamos a estar en la lucha entre seguridad versus usabilidad por lo que no vamos a lograr nunca una ni otra, lo importante

es estar en un balance optimo.

Ahora, haciendo una pequeña reseña de que quedo y falto:

Y lo que falto fue:

El Sistema de archivos Firewalls tcpwrappers archivos con permisos raros (SETUID, SETGID, etc) centralizar nuestros logins (ldap, radius...) etc. etc. etc.

rmayorga (Comunidad de usuarios Debian de El Salvador) Seguridad en Servidores Debian  6 de marzo de 2009  40 / 41

Recordemos, siempre vamos a estar en la lucha entre seguridad versus usabilidad por lo que no vamos a lograr nunca una ni otra, lo importante

es estar en un balance optimo.

Ahora, haciendo una pequeña reseña de que quedo y falto:

Y lo que falto fue:

El Sistema de archivos Firewalls tcpwrappers archivos con permisos raros (SETUID, SETGID, etc) centralizar nuestros logins (ldap, radius...) etc. etc. etc.

rmayorga (Comunidad de usuarios Debian de El Salvador) Seguridad en Servidores Debian  6 de marzo de 2009  40 / 41

Recordemos, siempre vamos a estar en la lucha entre seguridad versus usabilidad por lo que no vamos a lograr nunca una ni otra, lo importante

es estar en un balance optimo.

Ahora, haciendo una pequeña reseña de que quedo y falto:

Y lo que falto fue:

El Sistema de archivos Firewalls tcpwrappers archivos con permisos raros (SETUID, SETGID, etc) centralizar nuestros logins (ldap, radius...) etc. etc. etc.

rmayorga (Comunidad de usuarios Debian de El Salvador) Seguridad en Servidores Debian  6 de marzo de 2009  40 / 41

Recordemos, siempre vamos a estar en la lucha entre seguridad versus usabilidad por lo que no vamos a lograr nunca una ni otra, lo importante

es estar en un balance optimo.

Ahora, haciendo una pequeña reseña de que quedo y falto:

Y lo que falto fue:

El Sistema de archivos Firewalls tcpwrappers archivos con permisos raros (SETUID, SETGID, etc) centralizar nuestros logins (ldap, radius...) etc. etc. etc.

rmayorga (Comunidad de usuarios Debian de El Salvador) Seguridad en Servidores Debian  6 de marzo de 2009  40 / 41

Recordemos, siempre vamos a estar en la lucha entre seguridad versus usabilidad por lo que no vamos a lograr nunca una ni otra, lo importante

es estar en un balance optimo.

Ahora, haciendo una pequeña reseña de que quedo y falto:

Y lo que falto fue:

El Sistema de archivos Firewalls tcpwrappers archivos con permisos raros (SETUID, SETGID, etc) centralizar nuestros logins (ldap, radius...) etc. etc. etc.

rmayorga (Comunidad de usuarios Debian de El Salvador) Seguridad en Servidores Debian  6 de marzo de 2009  40 / 41

Recordemos, siempre vamos a estar en la lucha entre seguridad versus usabilidad por lo que no vamos a lograr nunca una ni otra, lo importante

es estar en un balance optimo.

Ahora, haciendo una pequeña reseña de que quedo y falto:

Y lo que falto fue:

El Sistema de archivos Firewalls tcpwrappers archivos con permisos raros (SETUID, SETGID, etc) centralizar nuestros logins (ldap, radius...) etc. etc. etc.

rmayorga (Comunidad de usuarios Debian de El Salvador) Seguridad en Servidores Debian  6 de marzo de 2009  40 / 41

Recordemos, siempre vamos a estar en la lucha entre seguridad versus usabilidad por lo que no vamos a lograr nunca una ni otra, lo importante

es estar en un balance optimo.

Ahora, haciendo una pequeña reseña de que quedo y falto:

Y lo que falto fue:

El Sistema de archivos Firewalls tcpwrappers archivos con permisos raros (SETUID, SETGID, etc) centralizar nuestros logins (ldap, radius...) etc. etc. etc.

rmayorga (Comunidad de usuarios Debian de El Salvador) Seguridad en Servidores Debian  6 de marzo de 2009  40 / 41

Comentarios, sugerencias, experiencias

Gracias :)

Bueno, gracias a todos, esta presentación se encuentra bajo una licencia

libre y pueden obtener una copia completa del código fuente en: http://rmayorga.org/talks.

Parches, pu..adas, preguntas y todo es bienvenido en

                   rmayorga@debian.org

Gracias :)

Bueno, gracias a todos, esta presentación se encuentra bajo una licencia

libre y pueden obtener una copia completa del código fuente en: http://rmayorga.org/talks.

Parches, pu..adas, preguntas y todo es bienvenido en

                   rmayorga@debian.org