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.






_______________________________________________
Lugro mailing list
[email protected]
http://www.lugro.org.ar/mailman/listinfo/lugro

Responder a