feb 10 2012
De Servidores Web comprometidos y personas o empresas que no se comprometen.
Disclaimer:
Este post puede considerarse como un acto de promoción dado que soy parte “interesada” o directamente implicada por mi participación 
en los casos que comento. Ante las (lógicas) posibles dudas, vamos a apelar a aquello de “pásate por ejemplo” por daboweb.com que en breve cumple 10 años y sólo verás un lugar más de ayuda informática, totalmente desinteresado, sin publicidad y hecho por amigos, no colaboradores, amigos, reitero, por y para la comunidad, aprovecho la ocasión para mandar un saludo a mis compañeros de Caborian.
Además, son más cinco años junto a vosotros por aquí en DaboBlog como para que os venga a contar películas en formato TS Screener (recuerda, descarga, pero con calidad).
¿Por qué esta entrada? Y tan tarde…
Bueno, era algo que tenía pendiente, a pesar de que intento conservar cierta actividad en las webs que promuevo o participo, colaborar con el podcast de mi amigo Dani, con el que he grabado unos audios sobre seguridad Wifi y seguridad en dispositivos móviles “para todos los públicos” (por cierto, sobre DaboBlog Podcast, pronto sacaremos un nuevo episodio, o eso espero;), como os decía, es frustrante por ejemplo, abrir Twitter y no poder leeros como me gustaría, no devolver todo el feedback que llega, dejar de publicar aquí con mayor regularidad o en Daboweb, DebianHackers, etc, pero uno da hasta donde da y tiene sus limitaciones. Acabo de ver que mi último post es del día 18 de Enero, día del famoso “Blockout“.
Situación actual.
Actualmente me encuentro inmerso entre una marea de cursos que estoy impartiendo (dentro de las actividades que llevo a cabo desde davidhernandez.es) y otra marea, pero en este caso, con APACHEctl.com junto a mis compañeros. Hablo de mareas de bytes, servidores web, auditorías de seguridad, terminales, intervenciones de urgencia, etc y todos los problemas a los que se puede enfrentar un autónomo en una época como esta, además de un proyecto en común que va gestándose con paso firme y a ritmo suave con Emma Fernández, buscando una diversificación en base a ciertos servicios que demandan algunos clientes.
Servidores y aplicaciones web, usuarios, condicionantes…
Y de mi actividad principal quería hablaros, servidores, seguridad, clientes, SysAdmins y algún ISP que en lugar de “Internet Service Provider“, bien podría ser un acrónimo de “Internet Sopla Pollas“. Sí, de varios hechos que he podido comprobar con mis propios ojos, algunos adelantados en medio de sensaciones entre el cabreo o la falta de comprensión por mi parte y…ciertamente hacen falta más de 140 caracteres para expresarlo. Eso sí, 140 caracteres son pocos, pero aunque tampoco quiero abusar de vuestro limitado tiempo en medio de una multitarea cada vez más acuciante, reconoceréis que a casi un post por mes, tengo que exprimir un poco el teclado ;)
Partamos de la base de que no siempre se puede actualizar como te gustaría o querría el cliente, existen ciertas dependencias entre algunas aplicaciones web, versiones del S.O, entornos de producción que no se pueden parar (de todo esto hablamos Sergio Hernando y yo en el “Especial Seguridad“) y situaciones en las que hay limitaciones tanto técnicas, comerciales o administrativas que impiden un estado ideal de algunos sistemas web en producción. Me tranquiliza en lo personal, saber que en ninguno de estos casos se den esas circunstancias.
Por otro lado, si alguien que trabaje en seguridad o sistemas no entiende que bajo ciertas condiciones, su infraestructura puede ser comprometida, debería pensar en cambiar de trabajo porque cuando viene un cliente buscando que le vendas una utopía, o veo en algún sitio web eso de “garantizamos al 100 % tu seguridad” me quedo alucinado o pienso ¡Qué envidia, si yo pudiera…!
A dos días de terminar de impartir un curso sobre SGSI, LOPD, LSSICE y todas las implicaciones y embrollos legales que se pueden dar cuando manejas datos de terceros, (aprovecho para saludar a esos 14 alumnos con los que tanto aprendo;), cada vez me doy cuenta de que en la solidez de la gestión de la seguridad entran en escena tantos protagonistas (ISP, Webmaster, sofware instalado, usuarios, SysAdmin, etc) que controlar todas esas variables al 100 % es prácticamente imposible, os recomiendo (sobre el factor humano) esta entrada “Por qué falla la seguridad” de los colegas de Security By Default.
¿Por qué? las acciones realizadas por personas a nivel individual influyen en tu trabajo y puedes preveer una actuación en concreto, pero no cambiar ciertas condiciones o costumbres del ser humano. De ahí que sea tan importante un “plan B” y sobre todo hacer que el “plan A” se vaya al carajo para ver cuánto tiempo tardas en poner en marcha ese “plan B” y dar por hecho que puedes encontrarte con el peor de los escenarios posibles.
Si lo ves o planificas de ese modo, no estarás poniéndote vendas en los ojos que acabarán seguramente provocándote una “ceguera operativa” cuando el escenario ideal se convierta en la peor de tus pesadillas, o la de tu cliente, si cuando contacta contigo y está siendo víctima de una fuga de información o ataque a sus sistemas, las cosas no van como debieran. Aún así, sé consciente siempre de tus limitaciones o carencias, e intenta aprender y aprovechar tus puntos fuertes, pero sin dejar de trabajar la parte que menos controlas o te gusta, para conseguir un mayor equilibrio. Créeme, hay gente “ahí fuera” que sabe mucho más de los que están (o estamos) a veces en un plano “mediático” (eventos, reseñas, referencias) en el que se vende mucho humo y prevalecen los conceptos en lugar de las realidades.
De servidores web bajo Debian Etch que jamás se han actualizado.
Con este (sub) título no debería extenderme mucho. Hablamos de una empresa que me contrató para impartir unas clases sobre administración de servidores web bajo GNU/Linux. Dicho cliente (de Asturias) tenía contratado un servidor dedicado con un proveedor local, no daré nombres ya que aún mantiene una relación contractual y no seré yo quien promueva más malas artes por su parte, pero tampoco seré quien recomiende sus servicios, quizás hasta me lean, seguro que se ven “retratados” por lo de MaxClients 40 TimeOut = 300.
En el curso, a modo de ejercicio, fuimos creando paso a paso un servidor GLAMP y llegado el momento, se migraron algunos dominios a su máquina, en ese momento es cuando accedí al servidor dedicado contratado con esa empresa. Ya cuando hice un barrido rápido con Nmap lo vi claro pero…cuando haces un uname -a , cat /etc/debian_version o miras el source.list, puedes quedarte K.O.
El que el cliente tuviese una distribución de Debian de hace 5 años que ya no tiene actualizaciones desde finales de 2010 (ojo con Debian Lenny que desde hace unos días ya no recibirá actualizaciones de seguridad !!) puede considerarse bastante fuerte con unas 20 webs en producción. Pero…¿Cómo se queda uno si ve que la salida de tail /var/log/aptitude es = 0? WTF. Si, hay que joderse y “joder” al prójimo, jamás se había actualizado, no daba crédito y tras varias comprobaciones pude ver que era así de crudo y duro. En un primer momento pensé que había un problema con los logs, fue tan fácil como ir tecleando apache2ctl -V, mysql -v, etc, para ver que eran las versiones originales según venían en Debian 4.
Ahora bien, el listillo jamás había metido un update pero ojo, sí que había tenido tiempo para poner en el apache2.conf la directiva “maxclients” en 40. Todo ello con un “bonito” TimeOut de 300 seg, sí amigos, ¿el motivo? piensa mal y acertarás, claro, para ahorrar ancho de banda en su CPD…Limita a 40 conexiones o IPs diferentes en cada máquina y de ese modo, paga menos a su proveedor. Pero hay que ser malo o tener “mala fe” (vi el history y controlar, controlan) para dejar en 300 seg el TimeOut cuando sabes que si hay 40 IPs diferentes conectadas, hasta que se cierre una conexión de Apache que quede inactiva y dé paso a la 41, pasarán la friolera de 300 segundos, luego el cliente, ya se dio cuenta del motivo por el cual a veces le llamaban con eso de “es que me dicen que no se puede entrar a mi web”.
De servers con CentOS, un Cpanel sin actualizar y 3 joomlas crackeados.
Uno de los primeros síntomas por los cuales el cliente se da cuenta de que tiene un problema en su servidor, es en el momento que empiezan a venir e-mails rebotados o marcados como spam y entras en alguna (o varias) de las “blacklists” (o listas negras) habidas y por haber. Esa actividad inusual de envíos de correos desde el localhost, sin estar asociados a ningún dominio, ya es algo que debería mosquearte y luego llega “ese momento” (de la revelación).
El panorama no podía ser peor, una máquina con una versión de CentOS sin actualizar al igual que la versión de Cpanel desde la que se administraba, medidas de protección cuasi-nulas tanto a niveles más bajos del sistema, como protección de ataques de fuerza bruta, picos de tráfico indeseado, escaneos de puertos un tanto “intrusivos”, configuraciones del servidor bajo mi punto de vista inadecuadas para la gran cantidad de webs que alojaba, etc. El cliente pagando por una administración delegada que efectivamente no se estaba realizando, no en este caso a su proveedor de hosting, sino a un tercero. Dicho cliente había sufrido un ataque a varios de los Joomlas instalados (sí, mirad por ahí en las carpetas de imágenes a ver si veis algún .php que no debería estar ahí…), tenía todo un entorno de acceso remoto por una puerta trasera vía web para enviar spam de forma masiva, acceder a las bases de datos, subir ficheros, etc.
Ahh, también un servidor de IRC en la raiz “/”, desde esa máquina se habían realizado ataques de pishing haciendo de pasarela, algo que pudimos comprobar mientras hacíamos el análisis, reportando por mi parte a INTECO CERT la situación de un segundo servidor comprometido (que por cierto, actuaron muy rápido avisando al ISP o dueño del dominio ya que se palió casi al instante). ¿Vaya panorama eh?. Siendo sinceros, el administrador de ese sistema no hizo su trabajo, pero si te dedicas a desarrollar o implementar algún CMS como WordPress o Joomla, lo mínimo que deberías hacer es estar al tanto de las posibles actualizaciones de seguridad que van publicándose, nadie está a salvo de un “0 day”, pero de eso a dejar pasar varias ramas o versiones hay un paso…
De una “gran” empresa de hosting y “rayos por las nubes”.
Este tema fue quizás más extraño, se trataba de un sistema “On Cloud” de estos muy modernos en los que a golpe de click, vas clonando, arrancando máquinas bajo demanda y pensando que todo se soluciona así, a base de “clicks” y monitores o paneles web muy pomposos pero que no se enteran de lo que pasa por su interfaz de red (o sistema de ficheros NFS lento como el sólo…) no hablo de Amazon por cierto.
Por resumirlo, el cliente sufrió un ataque en 3 máquinas virtualizadas sin tener en marcha ninguna web visible, es decir, había unas direcciones IP con un servidor de aplicaciones, otro para MySQL y otro para Apache en pre-producción. Entraron “hasta la cocina” y se enteraron 7 días después. ¿Los motivos o vectores de entrada? bueno, por cuestiones “técnico-económicas” el cliente no quiso realizar una auditoría forense y si mal no recuerdo, pidió un clonado de los discos virtualizados por si en un futuro, viese pertinente hacerla.
Esta “aparentemente” y aparente gran empresa de hosting, una vez acabados los trabajos a realizar por nuestra parte (que en APACHEctl no estoy yo sólo;), después de estar tirando en plan bestia con varios servidores (yo) para probar todas las medidas implementadas (ataques de fuerza bruta, escaneos de puertos de esos que hacen algo de “ruido”, denegación de servicio intentando “floodear” algún puerto o servicio inundándolo de peticiones SYN – TCP, el cliente pidió los resultados de ese día, y cuando comparó el resultado del sistema de control de logs que le instalamos con lo que pidió a su ISP, era como para darte la risa (por decir algo), “se ha detectado cierto tráfico ICMP“, os aseguro que monté una buena, y ojo, todas las soluciones instaladas por nosotros se basan en Software Libre o herramientas Open Source y su “ultra-mega firewall” por hardware, (imagina el típico “SonicWall de 9.000 €) desde el que se realizaba un NAT hacia las máquinas virtuales, no se enteró de nada…Acabo recordando que el cliente (empresa desarrolladora) se enteró 7 días después, teniendo que dar muchas e incómodas explicaciones al cliente final.
De otro “gran” ISP que cobra por administrar, no lo hace y entorpece.
Y además de no hacerlo, actualizar los sistemas del cliente, cuando ese o esos clientes (dos en una semana) piden acceso SSH, todo son problemas, no vamos a ir al tema legal y la denostada (por mi desde sus inicios) LSSI que dice que “el ISP no es responsable de los contenidos que aloja el cliente siempre que no sea el creador de sus contenidos, pero tiene que actuar con rapidez caso de que queden expuestos datos de terceros o la propia infraestructura web“, vamos a eso de “estoy siendo víctima de un ataque, no doy con ello y como vosotros no sois capaces de pararlo y dar con el vector de entrada, por favor, ceded el paso ya que cada minuto es vital para mi negocio.
Es lo que pasa con ciertas ventas o mejor dicho “fusiones” que queda mejor, es como lo de la Coca Cola de los 80, queda el nombre y algo del gusto de antaño, pero la esencia…se perdió entre tanta “alianza estratégica“. Aquí hablamos de máquinas comprometidas intentando redirigir el tráfico hacia sitios maliciosos (que afortunadamente se paró a tiempo) y clientes que se sientes totalmente impotentes frente a una situación muy dura en la que como he dicho, cada minuto, segundo, cuenta…
Podría seguir comentando algún tema localizado en una auditoría de seguridad que realizamos a unos 30 equipos, redes, servidores, etc, en una empresa hace unos días, pero quizás aún el cliente no ha leído el informe recién enviado y es mejor que lo vea con detalle desde la tranquilidad y no en pinceladas que pueda dejar aquí escritas. Tampoco voy a poner nombres, en muchos de estos casos, se están o bien finiquitando relaciones contractuales o arreglándolas, lo siento pero si me preguntas por algún sitio en el que confiar, pasa al siguiente párrafo…
¿Y ahora qué?
Podrás preguntarte…¿todo el mundo lo hace mal? no, ¿las cosas están feas ahí fuera? sí. No deja de ser toda una paradoja que cuando alguien dice que “mi hosting es genial, etc, etc” lo hacen porque simplemente ven que su web está activa y llegado el caso (no en todos los casos que comento), el servicio de atención al cliente es bueno, contestan en tiempo y forma, etc pero…cuando tienes problemas es el momento de darte cuenta de a quien le estás dando las llaves que abren (o pueden cerrar) las puertas de tu negocio.
No sé si habría que decir a la gente eso de “mira, piensa que un servidor web es como tu ordenador de casa, tiene que estar actualizado, pero también los programas que usas a diario, del mismo modo que tienes un antivirus, bla, bla, bla“. Pero mejor quédate con eso de, actualiza primero todos los CMS que tengas instalados en tu servidor (foros, blogs, etc), realiza o contrata una auditoría de seguridad al menos una vez al año, asegúrate de que efectivamente tu SysAdmin o ISP estén actualizando/administrando esa máquina, haz lo mismo que con los médicos, pide siempre una segunda opinión, (pásate por el “Especial SysAdmin“ con Ricardo Galli) créeme, si estás leyendo esto te confesaré que soy el primero que dudo de mi propio trabajo y entre los miembros de APACHEctl y allegados, no paramos de auditarnos y ponernos a prueba, además de tirarnos de las orejas si nos pillamos en un renuncio. Y ojo, por fiarte, no te fíes ni de nosotros al 100 % si llegas a contratarnos.
Un abrazo y “tengan cuidado ahí fuera” -;).
Pdta; Según WordPress, son 2.664 palabras, lo sé, ni tanto ni tan poco ¿o era al revés? ;D.
Hola amigos, como sabéis, no hace mucho tiempo 
Luego, cuando fui aprendiendo a base de prueba-error, pasé a meterle mano a servidores dedicados más potentes y a administrar otros de terceros. En estos 5 años, he ido pasando por diferentes fases hasta llegar a comprender más o menos como se mueve todo esto.
Quizás lo más complejo haya sido darle forma a todo o más bien resumir lo más importante. Esa fase ya está superada (más o menos-;) y ahora queda preparar cada uno nuestra parte. Dispondremos de 60 min y lo haremos en dos bloques, estamos controlando ahora mismo el tiempo para cada uno de ellos. En ambos casos, apoyaremos lo comentado con ejemplos realizados en riguroso (esperemos que no falle-;) directo.
También se verán ejemplos de cómo un buscador puede tumbarte un servidor, ataques XSS, vulnerabilidades en PHP y otros servicios, seguridad por oscuridad con varios ejemplos y sus correspondientes test de intrusión externos, ver un firewall en acción y algún consejo para usarlos, búsqueda de Rootkits, control de puertos y servicios a la escucha, etc.
