Según leemos en H-Online (ENG), se ha reportado un fallo de seguridad catalogado como de impacto alto en «Apache Traffic Server» (CVE-2012-0256).
Dicho bug afecta prácticamente a todas las ramas 2.x y 3.x (incluso las de desarrollo) y se recomienda actualizar a la mayor brevedad posible a la versión 3.0.4 dado que evita tanto ataques de denegación de servicio (DoS) o la ejecución arbitraria de código.
Más información (Apache Server).
A través de Hispasec nos hacemos eco de las vulnerabilidades remotas localizadas en el contenedor de servlets Apache Tomcat, desarrollado por la Apache Software Foundation, las cuales han sido consideradas como de importancia por sus mantenedores, con lo que se recomienda a aquellos administradores que lo usen en su servidor procedan a comprobar si su versión de Tomcat es una de las afectadas. En concreto se trata de los siguientes fallos:
Más información y solución en Hispasec
Como habéis podido leer hoy en Daboweb, hace unas horas os informábamos acerca de los parches que ha aplicado Debian con una nueva versión de Apache que solventaba la vulnerabilidad y los ataque DoS CVE-2011-3192 (además de uno específico en mod_dav) tanto en la rama «oldstable» (Lenny) como en la «stable» (squeeze).
Os informamos que ya está disponible una nueva versión de Apache (2.2.20) que solventa dicho bug por lo que es más que recomendable su actualización a la mayor brevedad posible, además de revertir los posibles cambios (por ejemplo la activación de mod_deflate) relalizados para mitigar el impacto del bug cuando aún no había parches oficiales.
Información sobre cambios y correcciones | Descarga de la nueva versión | Fuente Sans.
Hace unos días os hablamos de la vulnerabilidad que afectaba al servidor web Apache. Esta vulnerabilidad permitía ataques de denegación de servicio y que con un número limitado de peticiones, dicho ataque dejase al servidor web afectado sin recursos por un excesivo consumo de memoria y CPU.
Debian ha puesto a disposición de los usuarios los correspondientes parches que solventan dicha vulnerabilidad (CVE-2011-3192) (etiquetados como 2.2.9-10+lenny10 y 2.2.16-6+squeeze2.)
Además, se añade un parche específico para la versión «oldstable» (Lenny) que solventa un bug que afecta a mod_dav (CVE-2010-1452) que también podía derivar en ataques de DoS en el servidor web.
Más información sobre el anuncio (Debian DSA-22981 Apache 2) en Debian.
En estos momentos, en el sitio web oficial de Apache aún no hacen mención a una nueva relase que corrija estos bugs, pero se espera que en unas horas esté disponible una versión con el parche para su instalación/compilación.
Concretamente, la vulnerabilidad ha sido catalogada como «Range header DoS vulnerability in Apache 1.3 and Apache 2» (CVE-2011-3192:). El tema es serio ya que con un número relativamente bajo de peticiones, pueden producirse ataques de denegación de servicio, debido a un excesivo consumo de memoria y CPU.
Como prueba de concepto, está el script escrito en Perl denominado»killapache«. Para comprobar si vuestro servidor es susceptible de recibir este tipo de ataques, os recomendamos leer la entrada sobre el tema de Jordi Prats en»systemadmin.es»
Este bug, del que se espera que en 96 h aproximadamente esté parcheado (aunque hablan de parches para las versiones 2.0x y 2.2x, no para la 1.3x según informan), afecta especialmente a Apache junto a módulos relativos a la compresión de ficheros, como puede ser el caso de uno tan popular como mod_deflate. Debido a la falta de actualizaciones, se proponen varias medidas para paliar los efectos del bug.
Estas actuaciones se pueden combinar con otras soluciones de «apoyo» como podrían ser Mod-Evasive, Mod-Security, (D) DoS Deflate, la configuración de vuestro firewall, etc.
(#Disclaimer; En la fuente original ya se informa que estas medidas pueden afectar al normal uso de los sitios webs en los que se implementen. Vídeo por streaming, sesiones activas, ciertas descargas, cookies y otras peticiones legítimas).
1) Utilizar «mod_headers«; (Ponedlo debajo de la directiva «ServerRoot»)
RequestHeader unset Range
2) Usar «mod_rewrite» para limitar el número de intervalos:
RewriteCond % {HTTP:range} ^bytes=[^,]+(,[^,]+) {0,4}$
RewriteRule. *-[F]3) Reducir el tamaño en bytes de las peticiones; (mejor con la opción 1)
LimitRequestFieldSize 200
4) Usar temporalmente un módulo de «recuento» como mod_rangecnt.c. (esta opción mejor la última…)
http://People.Apache.org/~dirkx/mod_rangecnt.c (descarga directa)
5) Quitar «mod_deflate» temporalmente, la «menos mala» quizás.
(Alguna consideración sobre su desactivación aparte de un «a2dismod» en Debian y derivados)
«Removing any AddOutputFilterByType/SetOutputFilter DEFLATE entries. Disable it with «BrowserMatch .* no-gzip«
Ante las dudas que os puedan surgir, os recomendamos permanecer atentos a posibles parches y leer la fuente original de este artículo o está información de «Debian Security» en el que hablan del bug y cómo afecta a Apache en su versión estable. También es recomendable seguir este hilo para contrastar e ir leyendo más información.
Por David Hernández (Dabo).
Publicada la primera versión beta de este utilizadísimo servidor web opensource. Se están haciendo muchos trabajos para mejorar las prestaciones del mismo, como pueden ser cambios en los módulos de multiproceso, con una mejora en el soporte asíncrono de lectura y escritura. También se han añadido nuevos modulos como mod_ratelimit, para limitar el ancho de banda que consumen los clientes, o bien mod_slotmem_shm, que crea una área de memoria compartida con el scoreboard del estado de los procesos/threads de Apache entre otros.
Recordemos que se trata de una versión no apta para producción y que no es recomendable su uso en sistemas finales, pero en la que los profesionales del sector puedn ir viendo cuales serán las novedades que traerá consigo la versión definitiva.
Nuestro compañero Dabo se pone en esta ocasión al micro junto a Ricardo Galli (Menéame, UIB) en un episodio especial de su podcast dedicado a la administración y gestión de un servidor o proyecto web.
El resultado, ha sido una didáctica charla sobre sysadmins entre dos colegas que nos van haciendo entrar en escena a medida que transcurre el podcast abarcando las siguientes cuestiones;
Escalado web, MySQL, Amazon, Apache, Ngnix, Caching, Monitorización, Seguridad.
Acceder a «Especial SysAdmins en Kernel Panic» (Dabo) | «Un podcast para SysAdmins« (Gallir).
Junto a la entrada original en DaboBlog, se puede ver una extensa documentación de todo lo comentado en el audio.
Acaba de salir una nueva versión de este conocidísimo servidor web open source, concretamente la 2.2.16, la cual da solución a dos vulnerabilidades, una de denegación de servicio en los módulos «mod_cache» y «mod_dav», así como otra de divulgación de información sensible en «mod_proxy_http». En el caso del primer fallo se trataba de un error que ocurría cuando se enviaban por parte de un atacante direcciones http especialmente manipuladas y creadas para tal fin, gracias a una vulnerabilidad en la directiva «CacheIgnoreURLSessionIdentifiers» presente en Apache desde la versión 2.2.14.
Desde el proyecto Apache se recomienda la actualización inmediata a esta nueva entrega. En este enlace tenéis mas información al respecto, sobre todo las versiones afectadas en cada vulnerabilidad y enlaces a los parches que se han publicado para esta eventualidad.
Si decimos que la industria del Malware, además de molesta, perniciosa y cansina, está siempre «a la última» en cuanto a técnicas de infección-redifusión, no sería nada nuevo ya que de todos es sabido.
Pero no está de más tener en cuenta esta información que podemos leer en Slashdot (ENG) con origen en este enlace (ENG), en la que se hacen eco de un aumento de ataques a través de servidores DNS vulnerables o con configuraciones potencialmente explotables, que son un filón para los crackers que consiguen hacerse con el control de esos servidores DNS, redirigiendo varios subdominios legítimos a una IP diferente y desde donde se llevan a cabo los ataques (de todo tipo) hacia el usuario a través de su navegador.
Sirva también a modo de recordatorio para los que administramos un servidor web, ya que como bien apuntan en la entrada original, a veces, una vez que has configurado las zonas DNS así como los diferentes dominios principales y subdominios, puede que no se revisen con la frecuencia que sería deseable y más si son subdominios creados no para servir páginas, sino para alojar por ejemplo imágenes, ficheros, etc, donde rara vez se consulta vía web sino más bien por FTP-SFTP.
Aunque personalmente opino que si ya se han hecho con el control de tu DNS, estás técnicamente K.O. Si hablamos de un servidor web bajo GNU/Linux, no está de más revisar esas configuraciones DNS y usar herramientas como «nslookup» o hacer consultas DNS con el comando «dig» para ver que está todo correcto y que tanto los dominios principales como subdominios, apuntan a IPs correctas.
Y para acabar, hablando de subdominios, es importante revisar a nivel de Apache que no queden expuestos o la vista de todos los subdominios (listado de directorios), aunque con un simple «index.php» o «.html» en el directorio principal del subdominio, caso de que como dije antes no se sirva tráfico web desde él, el contenido alojado dentro no quedará expuesto.
Como bien comenta su autor en la introducción de este tutorial de HowToForge que os recomendamos hoy, está claro que hay otras alternativas al excelente servidor web Apache, en algunos casos, más ligeras con el consumo de recursos (memoria básicamente) como sucede con el servidor web multiplataforma con licencia BSD Nginx (otra alternativa sería lighthttpd).
Además, como podréis leer, el proceso de instalación y puesta en funcionamiento es muy sencillo, siendo en este caso válido para dos distros de GNU/Linux tan populares como Ubuntu y Debian (en la que hay sólo una pequeña diferencia), aunque en otras distros será muy parecido también, dependiendo de que sistema de instalación o manejo de paquetes tenga.
Esta guía de instalación de Nginx con PHP 5.3 y PHP-fpm, está escrita en Inglés, pero cualquier usuario que esté acostumbrado a estas prácticas, no tendrá ningún problema para ponerlo en marcha. Se entiende que en ambos casos, hay instalada una versión estable y funcional de Ubuntu o Debian.
Acceso a; Servidor web Nginx + PHP 5.3 + PHP-fpm en Ubuntu/Debian (ENG)
Ha sido reportada por Ryan Giobbi una vulnerabilidad explotable tanto local como remotamente en Webmin y Usermin. Según nos informan desde Webmin, El bug se explota mediante un ataque por usuarios no autorizados contra la cookie de una sesión de un usuario con acceso a Webmin y podría permitir conectarse a su interfaz web sin introducir el password.
Aunque ciertamente no es fácil explotar este bug, os aconsejamos actualizar lo antes posible Webmin junto a Usermin dado que se trata de un software para controlar un servidor web con las consecuencias que un hecho así podría traer.
Las versiones afectadas son;
Webmin versiones anteriores a la 1.500.
Usermin versiones anteriores a 1.430.
La solución pasa por instalar;
Se han reportado vulnerabilidades en MySQL para Debian GNU/Linux 4.0 (Etch) y 5.0 (Lenny) explotables remotamente que podrían llevar a provocar ataques de denegación de servicio o la ejecución de código arbitrario en el sistema afectado.
Debian ya ha puesto a disposición de los usuarios las versiones que solventan estos bugs, por lo que es más que necesario actualizar MySQL a la mayor brevedad posible.
La solución pasa por instalar las siguientes versiones de MySQL;
Debian GNU/Linux etch – > mysql-dfsg-5.0 versión 5.0.32-7etch11
Debian GNU/Linux lenny -> mysql-dfsg-5.0 versión 5.0.51a-24+lenny2
Fuente, descarga y más info (para todas las arquitecturas)
Se han reportado varias vulnerabilidades en el popular servidor web Apache que pueden ser explotadas tanto local como remotamente para provocar un ataque de denegación de servicio o comprometer un sistema vulnerable.
Los fallos están causados por diversos errores en APR (Apache Portable Runtime) y APR-util y afectan a versiones 2.2.12 y anteriores.
La solución pasa por actualizar Apache a la versión 2.2.13 siendo más que aconsejable su inmediata actualización ya que esa versión también incorpora otras mejoras.
Fuente VUPEN | Más info versión 2.2.13 (Apache).
En algunas ocasiones, habréis visto como vía iptables o usando un firewall tipo Shorewall, APF, o los que vienen con un CPanel, Plesk etc, el acceso a los hosts virtuales en Apache a través de vuestro cliente FTP, se ve afectado con continuas caídas o simplemente, al intentar conectar da un “timeout”.
Una de las ventajas de Pure FTPd (entre muchas otras) es que nos permite definir a través de que rango de puertos se tramitaran las conexiones pasivas (de ese modo se conectan la mayoría de los clientes FTP). Como sabéis, el servidor FTP puede estar “escuchando” un puerto y a la espera de recibir conexiones (por ej el 21) y luego, deriva las transferencias hacia otros puertos.
Este hecho, en otros servidores FTP puede provocar muchos dolores de cabeza al administrador del sistema, ya que es muy complicado saber a priori a través de que puertos se realizarán las transferencias de datos y por lo tanto, a la hora de establecer las políticas de acceso al servidor web en el firewall este hecho se revela como un problema.
Por suerte, en Pure FTPd, se pueden definir estos puertos de un modo sencillo para luego incluirlos en vuestro firewall. Dentro de /etc/pure-ftpd/conf, tenéis que crear un fichero con el nombre PassivePortRange (como está, con mayúsculas y minúsculas) caso de que no esté creado.
Abrís vuestro editor de texto favorito para crearlo, en este caso vim;
vim PassivePortRange
y una vez dentro, tendréis que incluir el rango de puerto deseado del modo siguiente;
27750 28000
En este caso he incluido ese rango de puertos pero pueden ser otros (cuidado de que no estén usándose por otro servicio), podéis dar un vistazo a los puertos más comunes y su función o servicio.
Después y una vez definido ese rango de puertos en vuestro firewall, sólo tendréis que reiniciar el PureFTPd para que los cambios se hagan efectivos del siguiente modo;
/etc/init.d/pure-ftpd restart o /etc/init.d/pure-ftpd-ldap restart si está ejecutándose bajo ldap.
Os tendrá que aparecer algo similar a esto;
Restarting ftp server: Running: /usr/sbin/pure-ftpd-ldap-virtualchroot -l ldap:/etc/pure-ftpd/db/ldap.conf (omito algunas opciones) -p 27750:28000 -B
Ese -p 27750:28000 indicará que las transferencias en modo pasivo se harán entre esos puertos (-p passiveportrange) y si esos puertos están bien indicados en el firewall os podréis conectar vía FTP sin problemas.
(Update 5/12/2012)
Buen apunte del amigo Rastreador (vía Twitter) un tip para Amazon:
Añadiría que si ip serv. <> ip publica hay q utilizar pasv_address=ip_publica . En AWS imprescindible
Por David Hernández (Dabo).
¿Quieres comentar algo sobre este post? Puedes hacerlo en nuestro foro de noticias
Desde hace unos años, rkhunter se ha convertido para mi en una herramienta imprescindible, puedes usarlo en un servidor web o en tu ordenador personal como una forma más de asegurarlo. A continuación, os daré algunos detalles sobre sus funciones o uso.
Esta ligera y potente aplicación con licencia GPL, está ideada para detectar puertas traseras en tu sistema o alertar de actividades sospechosas en el mismo.
Se puede lanzar también al programador de tareas (Cron) para que realice una comprobación diaria de la integridad del sistema, además, puede configurarse para que te envíe un mail con el resultado del scan.
Realiza entre otras las siguientes operaciones (consulta la ayuda);
Análisis del disco duro en busca de los rootkits más comunes.
Comparaciones de hashes MD5.
Busca ficheros que son usados habitualmente por rootkits.
Realiza un análisis de ficheros binarios y los que se hayan movidos de su lugar habitual.
Busca cadenas sospechosas en módulos como LKM y KLD.
Módulos de Apache así como su configuración.
Interfaces funcionando en modo promiscuo (posibles sniffers).
Aplicaciones a la “escucha” que usen la librería libcap.
Ficheros que hayan sido borrados recientemente y los ocultos.
Llo más normal es ejecutar un rkhunter -c (check all, análisis completo) pero recordad ejecutar un rkhunter –update al menos semanal para que actualice las firmas de malware y toda su base de datos de detección para estar al día con todas las amenazas que van surgiendo.
Para su correcto funcionamiento, requiere un Shell Bash o Korn y algunos módulos de Perl que encontrarás en la mayoría de las distribuciones seguramente ya instalados.
Rkhunter está disponible para entornos GNU/Linux, Unix, BSD o Solaris.
De todos modos hay que ser un tanto paciente con las alertas que devuelve una vez finalizado el análisis ya que en ocasiones puede dar algún «falso positivo» y hacer sonar la voz de alarma, os recomiendo documentaros bien y buscar información al respecto antes de eliminar cualquier fichero sospechoso.
Para instalarlo, además de poder bajar el código fuente y compilarlo, la forma más sencilla es vía apt-get install rkhunter.
Os recomiendo también ChkRootkit que viene a realizar unas funciones parecidas con mucha efectividad.
Sitio web de Rkhunter | | En SourceForge | En Freshmeat |
Por David Hernández (Dabo).
¿Quieres comentar algo sobre este post? Puedes hacerlo en nuestro foro de noticias.
© 2024 Daboweb | Seguridad y ayuda informática | All Rights Reserved.