[LUG.ro] Re: [LUG.ro] Denegación de servicio en p op3 por mala configuración en inetd.conf

[Horacio Castellini]

Me extraña.... basicamente se aconseja nunca se dejar al inetd para
que atienda solicitudes masivas, sino que se deja al demonio que las
atienda...
Como por ejemplo el sendmail... uno puede activarlo por inetd, pero si
debés atender mas de 10 solicitudes el manual te recomienda que lo
ejecutes como demonio sin pasar por el inetd. Ya que lo dejás
tontorulo más si debés extremar las medidas de seguridad con el
tcpwaper!! Que veo que no lo usas y confias en la solidez del servidor
pop.

Reiniciar el inetd cada 10 minutos puede ser una solución de
emergencia al estilo la "gran window". Pero seguro que se debe existir
otras más profeciona

> Les paso una nota para que me digan que les parece. La colgue del blog
> también:
>
> http://www.criadoindomable.info/2006/12/04/denegacion-de-servicio-en-pop3-por-mala-configuracion-en-inetdconf/
>
> Al preparar un esquema de seguridad para una red, generalmente se comete el
> error de pensar que hay servicios que están configurados bien por defecto. Es
> muy común que los implementadores de soluciones libres tengan la falsa
> confianza de seguridad y dejen las cosas como vienen de fabrica sin siquiera
> poner un mínimo de atención a la configuración de otros servicios
> involucrados.
>
> El caso que comentare es sobre una denegación de servicio (DoS) sobre un
> servidor pop3 utilizando solid-pop3d como servidor y inetd para atender la
> conexiones en un servidor Debian GNU/Linux.
>
> En este caso, no se tiene habilitado el acceso a pop3 desde el mundo, siendo
> utilizado solamente en la red interna.
> Aplico este ejemplo por lo conversado en post anteriores en cuanto a los
> ataques desde el interior, intencionales o no, pero que suceden con más
> frecuencia que lo que se desearía.
>
> Ataque:
>
> Un usuario está esperando un mail y reiteradamente le da al botón enviar y
> recibir para chequear si ha llegado.
> El demonio inet.d detecta estos pedidos reiterados como un ataque DoS y deja
> de atender pedidos para pop3 por un tiempo X. Se ha provocado con esto,
> efectivamente, una ataque de DoS ya que el servicio no esta disponible. Si
> tenemos una red mediana, unos 50 usuarios, tendremos varias llamadas
> solicitando una solución al problema en ese lapso.
> Según un análisis posterior de los logs, el usuario impaciente chequeo correo
> a razón de unas 6 veces por segundo durante un lapso de 10 segundos, lo que
> dio un total de 60 pedidos al servicio pop3 en menos de un minuto, a esto se
> le puede sumar los pedidos de los demás usuarios.
> El demonio inet.d, por defecto, atiende unos 40 pedidos por minuto, superado
> este máximo, deshabilitara el servicio en cuestión y la saturación de la
> linea telefónica por reclamos.
>
> Configuraciones:
>
> Veamos un poco la configuración que se utilizo.
> La misma fue por defecto con lo cual, recordemos, atenderá 40 pedidos por
> minuto. Para ver más detalles sobre la configuración del inet.d hacer man
> inetd.conf.
>
> El archivo de configuración indica:
>
>
> pop3 stream tcp nowait root.mail /usr/sbin/tcpd /usr/sbin/solid-pop3d
>
> Los campos por numero son:
> 1: es el nombre del servicio, en nuestro caso, pop3. El mismo tiene que estar
> detallado en /etc/services para ser considerado correcto.
>
> 2: describe el tipo socket asociado a la conexión.
> 3: protocolo de red utilizado por el servicio.
> 4: Concurrencia: puede ser waith o no waith
> 5: usuario que ejecuta el servicio
> 6: Programa a ejecutar
>
> Configuración correcta:
>
> Con esta configuración tenemos el problema que como por defecto se tendrán 40
> conexiones por minuto, el usuario impaciente tiene todas las herramientas
> para hacer una denegación de servicio.
>
> El manejo de las conexiones se debe a que el servicio pop3 es multihilo (puede
> atender más de una conexión al mismo tiempo) con lo cual no tiene que esperar
> a terminar una conexión para iniciar otra y por eso en el campo 4 se pone
> nowait.
>
> Para poder solucionar este inconveniente, bastara con agregar la cantidad de
> atenciones que queramos tener y una configuración en el cron para que cargue
> cada cierto tiempo el demonio inet.d a fin de que no se provoque un DoS
> superado este punto.
> Para saber cuantas conexiones se necesitan , bastara con ver los logs de pop3
> y ver cuanto es lo normal en un minuto. Sabiendo el tipo de servidor que se
> tenga, se podrá determinar una cantidad de conexiones óptima para brindar el
> servicio pop3 sin que se produzcan caídas.
> Tomemos por ejemplo el doble de lo que esta por default, es decir, 80
> conexiones por minuto.
>
> La configuración necesaria para esto es muy simple. Bastara con poner la
> cantidad de conexiones en el campo 4 (concurrencia) separado del nowait con
> un punto:
>
>
> pop3 stream tcp nowait.80 root.mail /usr/sbin/tcpd /usr/sbin/solid-pop3d
>
> Luego configuraremos el /etc/crontab para que recargue el inetd cada 10
> minutos.
>
> 0,10,20,30,40,50 * * * * root /etc/init.d/inetd restart
>
> Con estas configuraciones, estaremos menos propensos a un ataque DoS interno o
> externo (si es el caso).
> El ver la simplicidad con la que se puede dejar sin un servicio, aunque sea
> por un corto tiempo, tiene que hacer recapacitar al administrador para tener
> en cuenta las configuraciones por defecto como una solución general.
> "Cuando se requiere brindar un servicio con un alto nivel de seguridad, se
> requiere una configuración especifica, adaptada a los requerimientos y
> características de lo que se está cuidando".
>
>
>
> Saludos y espero opiniones.
>
> --
>
> Sebastián D. Criado - scriado{en}ciudad.com.ar
> L.U.G.R.o - http://www.lugro.org.ar
> GNU/Linux Registered User # 146768
> -------------------------------------------------------------------
> "Si el Universo fuera un programa estaría hecho en C, y correría sobre
> un sistema UNIX"
>                                                   Anónimo.
>
>
>
>
>