Medidas contra el SPAM en MoinMoin
Contents
Medidas a nivel de aplicación
BadContent
MoinMoin incluye una eficiente medida denominada BadContent. Por favor, remítase al anterior vínculo para más información en su uso y en la configuración de listas locales ó LocalBadContent
Analizadores de contenido
Existe la posibilidad de usar herramientas especializadas en la detección y registro de spam y sus patrones, usando principalmente motores bayesianos. Para más información es sugerido seguir la página oficial del proyecto
Medidas a nivel de web server
Tal como se protege el motor de MoinMoin, es recomendable incluir protecciones a nivel de backend. MoinMoin puede ser usado con varios web servers y apache (uno de los más populares) incluye extensiones que permiten filtrar las conexiones entrantes de forma muy eficiente.
Otras medidas
Aunque menos frecuente, es posible «cerrar» el wiki y únicamente permitir a usuarios autenticados efectuar cambios en el mismo. Es una solución útil en intranets y wikis privados.
el-directorio.org/slcolombia.org y el spam
El sitio de el-directorio.org/slcolombia.org no es ajeno a éste vandalismo emergente y así durante algunas temporadas hemos sido objeto de innumerables ataques (muchos de ellos éxitosos) buscando incluir contenido de diversos tipos en el mismo. Tras analizar la naturaleza de los ataques, hemos incluído una combinación de medidas que para nuestro caso, han resultado en la reducción de éstos actos vandálicos casi al mínimo tendiendo fácilmente a la nulidad. Comentaremos a continuación «a grosso» modo las estrategias.
Estrategia No. 1
La primer estrategia: habilitar las protecciones a nivel de moin con BadContent. Su instalación es tan simple como eliminar un comentario del wikiconfig.py y reiniciar la instancia de MoinMoin, aunque debe tenerse cuidado pues genera continuo tráfico de internet entre el servidor local y los servidores de MoinMoin en Alemania y otros mirrors.
Estrategia No. 2
Un módulo para apache maravilloso: modsecurity. Su instalación es como los demás módulos de apache (vía apxs en caso de haber compilado su soporte) y tras ello, basta con cargar un archivo adecuado de reglas para empezar a ver en los logs información de extrema utilidad:
[Thu Aug 23 04:25:48 2007] [error] [client 190.48.46.231] mod_security: Warning. Pattern match "p o k e r.*\\\\.[a-z]{2,}" at POST_PAYLOAD [msg "XSS attack"] [severity "EMERGENCY"] [hostname "slcolombia.org"] [uri "/AlejandroVelandia/Blog/2006-09-04"]Gracias a ésto, es posible determinar la dirección IP del atacante junto con otros datos que sumados permiten conocer la cantidad de ataques, su frecuencia y destino predeterminado.
![/!\](/wiki/classic/img/alert.png "/!\"){kind=small}
Una constante revisión de los logs permite depurar las reglas para minimizar al máximo los falsos positivos y negativos.
Estrategia No. 3
Bien, ya los ataques éxitosos han disminuido/cesado, sin embargo (al menos en nuestro caso) los intentos desde ciertas direcciones ips (spambots?) eran permanentes lo cual nos sugirió tomar medidas respecto a ellos, la solución: sec ó simple event correlator. SEC es una herramienta que audita logs de sistema en espera de patrones (vía expresiones regulares) y al dispararse un evento se toma una medida (de cualquier tipo). Ésto nos abre una puerta maravillosa a la seguridad proactiva pues permite tomar acciones apenas suceden eventos, en nuestro caso el bloqueo de esos spambots vía reglas de firewall cuando se generan entradas en el log de apache asignado al virtualhost.
OpenBSD y sus sistema de filtrado de paquetes incluyen una característica muy útil: las tablas. Con ellas, es posible añadir host/redes/segmentos a reglas de forma muy veloz, con alta eficiencia y sin reinicializar servicios. De éste modo, las reglas de firewall lucen así:
block in log on $int_if from <spammers> to any block out log on $int_if from <spammers> to any
y los elementos de la tabla, así:
# pfctl -t spammers -T show 24.30.49.215 24.80.81.184 24.158.233.147 24.169.168.127 24.173.249.200 24.193.233.203 41.201.199.9 41.201.223.122 41.201.244.247 41.207.18.126 58.18.31.150 59.12.180.142 59.17.236.229 59.90.16.58 59.160.212.138
Estrategia No. 4
Usar TextChas. En éste momento es una de las medidas más eficientes y requiere tener el moin en la rama 1.6.x
Estrategia No. 5
Más que una estrategia es una buena práctica: revisar logs, tener nuestros sistemas actualizados y probar las políticas que aplicamos.
Conclusión
Sé que suena repetitivo pero la mejor defensa es un buen ataque y con herramientas como las existentes podemos ser competitivos frente a los incidentes.