Transparencias de clase sobre DHCP

Tal y como comentaba ayer en esta entrada, voy a ir dejando todas mis transparencias de clases, ponencias, conferencias y cursos en Slideshare.

Hoy toca el turno del servicio DHCP, clase que impartía en la asignatura de Administración e Instalación de Redes de Computadores en las titulaciones de Informática.

De las diferentes versiones (en función de los años) que tengo, he decidido publicar estas:


Transparencias de la clase sobre DNS en el Grado de Informática

Revisando el material de clase que tengo, he comprobado que creé transparencias de temas que, casi seguramente, no vuelva a utilizar y antes de que se pierdan en la profundidad de mi sistema, las he dejado (o dejaré ya que tengo que revisar muchas de ellas) en Slideshare.

De la asignatura de Administración de Redes de Computadores, he dejado, por ahora, la dedicada al servicio DNS.

Aquí la tenéis:

¡¡¡Espero que os sean útiles!!!


Más sobre WordPress

WordPress, como gestor de contenidos (CMS) ampliamente utilizado, se encuentra en el punto de mira de los “analizadores y aprovechadores” de agujeros de seguridad. Cualquier preocupación es poca y, por tanto, además de las tareas de fortalecimiento y análisis tratadas antes en este blog (I y II), debemos considerar aplicar otras: básicamente plugins que nos ayudan a mejorar la seguridad de nuestro sitio. Un listado bastante completo de ellos lo podéis encontrar en este gran trabajo recopilatorio de David Hernández.

Leer más


Port Knocking con iptables

Existe software desarrollado, como knockd, que nos permite utilizar una técnica de protección muy interesante: Port Knocking La idea es que, cuando se da una secuencia concreta de conexiones a determinados puertos, se habilita otro, que es nuestro objetivo final. Por ejemplo, tenemos deshabilitado el acceso al servidor SSH y, tras recibir una secuencia de conexión a los puertos 2000, 2002 y 50005, se activa la conexión, para esa IP de origen, al puerto 22 del SSH. Es una técnica más de las utilizadas para la fortificación de SSH (no es la panacea, ya que se puede descubrir la secuencia fácilmente, pero ya se sabe que cuanto más azúcar, más dulce).

Esta función se puede desarrollar  de manera muy sencilla con iptables y el módulo recent (que gestiona listas dinámicas de IPs  y que ya utilizamos para controlar el número de conexiones entrantes desde una misma IP en esta entrada). La siguiente lista de órdenes habilitaría el acceso al servicio SSH para la IP de origen desde la que se intente la conexión (en la secuencia correcta) a los puertos 2000 y 3000:

/sbin/iptables -N CADENA_PASO2
/sbin/iptables -A CADENA_PASO2 -m recent --name PASO1 --remove
/sbin/iptables -A CADENA_PASO2 -m recent --name PASO2 --set
/sbin/iptables -A CADENA_PASO2 -j LOG --log-prefix "ENTRANDO EN PASO 2: "
/sbin/iptables -I INPUT -m recent --update --name PASO1
/sbin/iptables -I INPUT -p tcp --dport 2000 -m recent --set --name PASO1
/sbin/iptables -I INPUT -p tcp --dport 3000 -m recent --rcheck --name PASO1 -j CADENA_PASO2
/sbin/iptables -I INPUT -p tcp --dport 22 -m recent --rcheck --seconds 5 --name PASO2 -j ACCEPT

Con estas reglas, debemos activar la política por defecto a DROP, para la cadena INPUT; también necesitamos una regla ACCEPT, para el puerto de origen 22 para cualquier destino en la cadena OUTPUT.

Para conectarnos, podemos ejecutar uno de los siguientes bloques de órdenes:

nmap -sn -PS2000 --host_timeout 200 --max-retries 0 servidor
nmap -sn -PS3000 --host_timeout 200 --max-retries 0 servidor
ssh [email protected] # Ahora está permitido 
telnet servidor 2000
telnet servidor 3000
ssh [email protected] # Ahora está permitido 

Con la segunda opción, los telnets estarán esperando a que salte el timeout y con 5″ de ventana de tiempo…

En cuanto a la primera:

  • “-sn”: No port scan
  • “-PS4000”: TCP SYN al puerto 4000
  • “–max-retries 0”: que no intente ningún reenvío
  • “–host-timeout 200”: que espere 200ms

Si queremos emular al conocido personaje Seldon Cooper,  y sus 3 “toques” cada vez que llama a una puerta, solo debemos añadir un puerto y su correspondiente fase más. Así, por ejemplo, para que la secuencia de activación de SSH sea: 4000, 2000, 3000, deberíamos configurar las iptables de la siguiente manera:

/sbin/iptables -N CADENA_PASO2
/sbin/iptables -A CADENA_PASO2 -m recent --name PASO1 --remove
/sbin/iptables -A CADENA_PASO2 -m recent --name PASO2 --set
/sbin/iptables -A CADENA_PASO2 -j LOG --log-prefix "ENTRANDO EN PASO 2: "
/sbin/iptables -N CADENA_PASO3
/sbin/iptables -A CADENA_PASO3 -m recent --name PASO2 --remove
/sbin/iptables -A CADENA_PASO3 -m recent --name PASO3 --set
/sbin/iptables -A CADENA_PASO3 -j LOG --log-prefix "ENTRANDO EN PASO 3: "
/sbin/iptables -I INPUT -m recent --update --name PASO1
/sbin/iptables -I INPUT -p tcp --dport 4000 -m recent --set --name PASO1
/sbin/iptables -I INPUT -p tcp --dport 2000 -m recent --rcheck --name PASO1 -j CADENA_PASO2
/sbin/iptables -I INPUT -p tcp --dport 3000 -m recent --rcheck --name PASO2 -j CADENA_PASO3
/sbin/iptables -I INPUT -p tcp --dport 22 -m recent --rcheck --seconds 5 --name PASO3 -j ACCEPT

Estas líneas que implementan la funcionalidad port knocking se deben añadir a los filtros que tengamos en nuestro servidor (o router, pero en este caso las reglas anteriores deben ir a la cadena FORWARD) y debemos tener en cuenta que:

  1. Las comunicaciones para SSH (o el servicio que sea) deben estar INHABILITADAS.  Con, por ejemplo, /sbin/iptables -P INPUT DROP lo logramos. La activación se hace con las órdenes del port knocking. Si no queremos ser tan drásticos: /sbin/iptables -A INPUT -p tcp –dport 22 -j DROP
  2. Debemos tener una regla que habilite las conexiones establecidas. Si no, nuestra sesión durará 5″ 🙁 Por ejemplo, una podría ser: /sbin/iptables -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT

¡Espero que os sea útil!

 Referencias

  1. man iptables
  2. Guía avanzada de nmap elaborada en conjunto por CSIRT-CV y el Centro Criptológico Nacional (CCN)

Deshabilitar la carga de ficheros en MySQL

Un posible ataque que se puede realizar contra cualquier aplicación web y, por extensión, contra el gestor de base de datos y el sistema donde este corre, son las SQLi. Sí, al sistema operativo, también. ¿Cómo? Pues, aprovechando una SQLi descubierta, intentar descargar ficheros críticos del sistema. Qué ficheros se podrá cargar dependerá del usuario con el que se esté ejecutando el demonio del gestor de base de datos. Es decir, podrá descargar aquellos para los que tenga permisos de lectura (y /etc/passwd lo puede leer cualquier usuario, ¡recuérdalo!)

Para evitar la fuga de información crítica de nuestro sistema, podemos:

  1. Como buena práctica recomendada para todos los servicios, ejecutar el demonio con un usuario con los mínimos permisos necesarios.
  2. Otra buena práctica recomendada: “enjaular el servicio” Con chroot impedir el acceso al sistema de archivos de nuestro sistema.
  3. Y el caso que nos ocupa: Dehabilitar la carga del ficheros en el gestor. Para el caso del MySQL en /etc/mysql/my.cnf, escribiremos

[mysqld]

local-infile=0

secure-file-priv=/dev/null

Si queremos hacerlo solo para determinados usuarios (los que usan nuestra aplicación web para conectarse a la base de datos son unos excelentes candidatos 😉 ), basta con revocar el privilegio file_priv a esos usuarios:

REVOKE priv_type [(column_list)] [, priv_type [(column_list)]] ...
    ON [object_type] {tbl_name | * | *.* | db_name.*}
    FROM user [, user] ...
FLUSH PRIVILEGES;

Referencias


DNS+P2P

El principal mecanismo para controlar qué se publica o no (más bien qué es accesible) en Internet actualmente se realiza mediante el DNS. Cuando un juez dictamina que debe cerrarse cierta página por que incumple la ley (como por ejemplo esta) si ésta se aloja en un servidor contra el que no puede actuar la justicia, lo normal es que se recurra al DNS.

Leyendo el blog de Enrique Dans, me he topado con una entrada en la que se comenta la posibilidad de descentralizar el sistema de gestión del DNS que realiza actualmente ICANN mediante una propuesta que se basa en el protocolo P2P.

En esta entrada me gustaría que analizarais esta propuesta y comentemos las formas, posibilidades, funcionamiento etc. de este tipo de soluciones.


DNS + Blogs

Vuestro compañero Daniel Navarro, propone esta entrada para comentar en el blog:

Tenemos un servidor que da un servicio web (por ejemplo apache).
Los dominios y los contextos del servidor se van añadiendo de forma automática
a través de un formulario de alta para los clientes, el cual añade a la
configuración DNS la entrada correspondiente al dominio dado
de alta y a su vez añade en la configuración del servidor web el contexto
para que pueda servir este dominio.

Ejemplo:
Cliente: prueba

Dominio: prueba.misblogs.com

Entrada en el DNS:  =prueba:X.X.X.X:300

Contexto de apache: ServerName prueba.misblogs.com

El problema que se plantea es que desde que un cliente se da de alta hasta
que puede acceder a su blog puede pasar tiempo, ya que tienen los DNS que
utilice este cliente que actualizar la zona. ¿Se podría hacer alguna
configuración en la cual no hiciese falta actualizar el DNS cuando se diese
de alta un nuevo cliente?
Planteo el siguiente tema: Tenemos un servidor que da un servicio web (por
ejemplo apache). Los dominios y los contextos del servidor se van añadiendo
de forma automática a través de un formulario de alta para los clientes, el
cual añade a la configuración DNS la entrada correspondiente al dominio dado
de alta y a su vez añade en la configuración del servidor web el contexto
para que pueda servir este dominio.

Ejemplo:
Cliente: prueba

Dominio: prueba.misblogs.com

Entrada en el DNS:  =prueba:X.X.X.X:300

Contexto de apache: ServerName prueba.misblogs.com

El problema que se plantea es que desde que un cliente se da de alta hasta
que puede acceder a su blog puede pasar tiempo, ya que tienen los DNS que
utilice este cliente que actualizar la zona. ¿Se podría hacer alguna
configuración en la cual no hiciese falta actualizar el DNS cuando se diese
de alta un nuevo cliente?

¿Podrá soportar España 4.000.000 de bajas de clientes de banda ancha?

Cerca de cuatro millones de ciudadanos no pueden acceder a la banda ancha en España en función de su sitio de residencia; a este indicador negativo para el desarrollo de la Sociedad de la Información en España, se le podrían sumar bajas masivas de clientes del Adsl más lento y caro de Europa.

Las entidades representativas de la comunidad internauta, los profesionales y los consumidores informáticos en España estiman en cuatro millones la cifra de clientes de banda ancha, ADSL y cable, que podrían darse de baja si finalmente se confirma el acuerdo que REDTEL está negociando con las sociedades de gestión de los derechos de autor abanderadas por la SGAE, para que en España se den tres avisos antes de desconectar o ralentizar la conexión a Internet por usar redes P2P.

A la disminución de ingresos se sumarían las posibles indemnizaciones que podrían derivarse por incumplimiento de contrato de las operadoras y las sanciones aplicables en base a los artículos 8 (”Restricciones a la prestación de servicios y procedimiento de cooperación intracomunitario”) y 11 (”Deber de colaboración de los prestadores de servicios de intermediación”) de la Ley 34/2002, de 11 de julio, de Servicios de la Sociedad de la Información y de Comercio Electrónico, modificado por la Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información.

Mientras las operadoras de telecomunicaciones tratan de sortear la crisis, las sociedades de gestión de los derechos de autor, intentan conseguir prebendas para las empresas productoras de contenidos tratando de convencer a todo el mundo de que el intercambio de archivos entre particulares por Internet es un acto delictivo y que supone fuertes pérdidas al sector de entretenimiento.

Sin embargo tanto la fiscalía como las sentencias dictadas establecen que el intercambio de archivos con copyright restrictivo por redes P2P no es un delito y no es punible de ninguna forma cuando se trata de archivos públicos o bajo licencias copyleft (la mayoría de los casos)

Las propias entidades de gestión de derechos de autor han reconocido en el “Informe de la industria de contenidos en España“, publicado por ASIMELEC, que no hay una bajada de ingresos en el sector y que solo la música tiene un retroceso en la venta a través del canal tradicional (aunque no se informa del aumento de ingresos por, entre otros, actuaciones en directo, descargas y publicidad)

Lo cierto es que las negociaciones que se están llevando a cabo bajo el auspicio del Ministerio de Cultura, pueden suponer que algunas de las empresas más solventes y con mayor capacidad tecnológica de España empiecen a perder clientes a marchas forzadas. Lo que repercutirá en su cuenta de resultados y en su capacidad de mantener el empleo.

Pero lo más grave es que un acuerdo de esta naturaleza atenta contra la libre competencia, frena en seco el acceso a la Sociedad de la Información en España menoscabando los derechos civiles de los ciudadanos y alejando aún más el derecho constitucional de acceso a la cultura y al conocimiento.

Firmado: Juan A. Gil y un montón más. Pon la tuya publicando el texto en tu blog.


Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Más información.