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. Sólo diré que son una empresa Asturiana de Hosting (a buen entendedor…).

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. Sí, somos humanos y como todos, podemos cometer errores por mucho que lo intentemos evitar.

Un abrazo y “tengan cuidado ahí fuera” -;).

Pdta; Según WordPress, son 2.714 palabras, lo sé, ni tanto ni tan poco ¿o era al revés? ;D.

Compartir

Me alegro mucho por él ya que, viendo que en un día ha tenido más de 1.000 descargas según me comentaba, tiene que ver el tirón de su podcast y que la gente estaba ahí esperando a que se pusiera “micro a la obra” ;).

Como comento en la entrada original (acceso al audio y demás datos), en el momento de grabar. no sabíamos nada sobre la vulnerabilidad en WPS y lo he recomendado desactivar la opción caso de venir habilitada, en los comentarios de esta primera entrega.

Muchas gracias “Sr Perogrullo“ en Twitter o Dani para los amigos, ya sabes que puedes contar conmigo y ahí estaré todos los meses intentando aportar algo de lo aprendido.

Por cierto, si en el año 2010 tuve la satisfacción de que uno de nuestros podcast (especial SysAdmin con Ricardo Galli) se colase en el “Top 2010″ en tecnología (se seleccionan dos por cada categoría) en el  2011 repetimos con el que grabé para Daniel, hablando de “Hackers y Crackers“, Estad atentos a sus audios ya que sacará uno cada semana (fotografía, seguridad, tecnología, etc).

(Pdta, para los aficionados a estos temas, grabé otro sobre seguridad con Dani y está el “Especial Seguridad” con Sergio Hernando).

Compartir

Lo que sucede con estos temas es que la realidad aquí casi siempre supera a la ficción, o a esa parte en la que el típico scanner de turno, revela unos resultados negativos para el host analizado. A partir de ahí, comienza una labor que va mucho más allá de las gráficas de Nessus por citar un ejemplo.

Si hablamos de pruebas “a ciegas” (sin acceso local al sistema a analizar), ciertos banners, huellas o “fingerprint” del sistema operativo, servicios y versiones corriendo en la máquina, pueden estar modificados y hay que saber discernir entre los “falsos positivos” y la realidad. Puede suceder lo mismo con la topología de la red cuando intentas hacer un esquema de ella.

En el caso de un test con acceso físico o remoto a la máquina o red a auditar, te encuentras muchas veces con situaciones en las que tal y como comentamos Sergio Hernando y quien suscribe en un podcast especial sobre seguridad (habrá otro), en ocasiones no es posible parchear y parar un entorno en producción ya que ahí suele prevalecer el “uptime” y la productividad frente a la “posibilidad de” (que suceda algún desastre informático).

En el día a día de mi labor como consultor freelance y de la que llevo a cabo como responsable del área de hacking ético en APACHEctl, creo que lo que más cuesta, es hacer llegar bien el mensaje. Un buen estudio previo de los problemas y necesidades de la empresa, conseguir llegar a las personas adecuadas, ponerte en su lugar y no pretender que las cosas se hagan como a ti te gustarían, sino como realmente son (que sí, no somos los protagonistas) y cuando acabes tu trabajo poner en marcha un plan de actuación adecuado, es fundamental para que tu análisis no caiga en el olvido. Pero eso sí, actúa siempre con valentía y defendiendo tu trabajo y profesionalidad.

Algunos podrán pensar “bueno, yo he cobrado mi auditoría, he reportado y ahora ellos verán“. Craso error, si no das un valor añadido y las medidas necesarias a poner en marcha no se llevan a cabo, considéralo un fracaso ya que sí, habrás cobrado, pero será difícil que vuelvan a llamarte, tu informe quedará como un “ahh sí, algo hicimos con ellos pero no sirvió para nada”. Esto no quiere decir necesariamente que hayas hecho mal tu trabajo, sino que no ha sido lo que tu cliente necesitaba…

Puedes ser muy bueno en la fase de reconocimiento, localizar vectores de ataque y revelación de brechas de seguridad, pero por muy frustrante que pueda parecer, si lo que haces no tiene un fin aplicable, con el “sistema hemos topado”. Si ya tenemos un hándicap de base como lo es el que se invierte mucho en “Social Media” y en seguridad lo “justamente imprescindible” o “cuando no queda más remedio”, nuestro esfuerzo debe ser mayor aún y el objetivo es conseguir que de nuestro análisis previo, salga un segundo trabajo que no es otro que implantar las medidas adecuadas para paliar los problemas localizados.

Así que el mejor consejo que humildemente te puedo dar, desde la experiencia y algún palo que profesionalmente he podido llevarme, es que las herramientas de auditoría son sólo un medio, el “fin” es que sepas o consigas hacer llegar de forma adecuada el mensaje dentro de entornos muchas veces un tanto “hostiles” hacia tu trabajo. En lugares donde hay mucho “miedo al cambio” o simplemente “tu verdad duele“, conocer las políticas de actuación o cómo es la toma de decisiones e idiosincrasia de la empresa, son casi más importantes que tu certeza con Nmap.

Y tampoco olvides que el primero que debe valorar su trabajo eres tú, por mucho que haya tanta crisis y las cosas estén complicadas, no caigas en el error de devaluarte a ti mismo. El precio es importante, pero también es un medio, conseguir el cliente, la calidad y profesionalidad, un fin, mantenerlo.

Mucha suerte ahí fuera -;).

Compartir

Al igual que en otras ocasiones, os animamos a dejar cualquier sugerencia sobre temas a tratar en sucesivas entregas del podcast, podéis hacerlo aquí o en nuestros Twitters; @antoniojperez, @daboblog, @foratinfo, @lurphoto, @n1mh,@oreixa donde los días de grabación, solemos anunciar cuando empezamos a grabar para que dejéis vuestras propuestas, comentarios o temas que os gustaría que tocásemos, pero también podéis hacerlas llegar en esta misma entrada.

Contenidos incluidos; (Duración 2,23 h)

> Intro (00:00 hasta el minuto 03:44)

(Por David Hernández, Dabo) Presentación y comentarios sobre este episodio 33.

> Kernel Panic (Minuto 03:45 hasta el 1:16 h)

En Twitter; Dabo y  Forat  (Diego aka n1mh estará en el próximo).

Alguno se quedará un tanto K.O cuando escuche a Forat y lo que le pasó con un Vaio y unos ¿drivers? para Windows 7. Hablamos también de las nuevas mejoras que vamos viendo en el Kernel, lógicamente Ubuntu 11.04 tiene un gran protagonismo (hablamos de las novedades y de cambios futuros) damos un repaso a su proyecto “Viejos ordenadores que hacen grandes cosas” (muy bien explicado),  Servers, Software libre en la empresa (o “la falta de”), seguimos con Unity – GNOME, aplicaciones, Distros “diferentes” y otras habituales recién salidas del horno, opinión, (IN) seguridad en DropBox, etc.

> Manzanas Traigo ( 1:16 h hasta 2:23 h)

En Twitter; Aj, Dabo, lur, Oreixa.

En “Manzanas Traigo” (y van) Gorka Lasa (lur) no esta, vamos a montar una petición online para su vuelta !!. Cuando subí el podcast 32, 15 min después nos enteramos del fallecimiento de Jobs, lógicamente hablamos del tema y de por dónde irán los tiros en la compañía. Del iPhone 4s, tarifas, portabilidades y operadoras. También de hardware y de problemas reales y otros que son historias, IOS 5x,  aplicaciones, opinion, sobre parches y actualizaciones de software, etc. En este “33″ Junto a Oscar Reixa, A. J Pérez.

Música;

Toda de Actual Proof, (Sunset Leaves, Necessary Spring, Venus in Cancer, World Traveler, Silver Screen, Stratosphere), con Creative Commons, su sección en Sound Click, contando además con el permiso explícito de su autor, mi colega Marc (saludos desde España-;). El podcast está alojado en ivoox.com en el canal “DaboBlog Podcast” donde además os podréis suscribir tal y como os indico debajo en los enlaces junto al audio para que os resulte más sencillo. Debajo el super banner de Forat ;D.

DaboBlog Podcast nº33, “Kernel Panic” y “Manzanas traigo”.

Ficha completaen ivoox.com del episodio 33.

Descargar fichero de audio (daboblog-podcast-n-33-kernel-panic-manzanas-traigo_md_898481_1.mp3)

Baja >el audio. Escuchar o descargar. (Navegador, lector de feeds o móvil sin Flash)

Suscríbete al canal En GPodder | iTunes | iGoogle | tu lector de RSS

¿No ves el reproductor integrado vía tu lector de RSS?, entra con tu navegador

Nos volvemos a escuchar en el número 34 del podcast (Fecha “Primeros de Diciembre “).

Tenéis también todos los episodios desde el primero en esta nueva sección del blog y en este link de ivoox.com.

Archivo del Podcast;

DaboBlog Podcast nº1

DaboBlog Podcast nº2

DaboBlog Podcast nº3

DaboBlog Podcast nº4

DaboBlog Podcast nº5

DaboBlog Podcast nº6

DaboBlog Podcast nº7

DaboBlog Podcast nº8

DaboBlog Podcast nº9

DaboBlog Podcast nº10

DaboBlog Podcast nº11

DaboBlog Podcast nº12

DaboBlog Podcast nº13

DaboBlog Podcast nº14

DaboBlog Podcast nº15

DaboBlog Podcast nº16

DaboBlog Podcast nº17

DaboBlog Podcast nº18

DaboBlog Podcast nº19

DaboBlog Podcast nº 20

DaboBlog Podcast nº 21

DaboBlog Podcast nº 22

DaboBlog Podcast nº 23

DaboBlog Podcast nº 23,5 (Especial SysAdmin)

Daboblog Podcast nº 24 (Especial Fin de año).

DaboBlog Podcast nº 25

DaboBlog Podcast 26

DaboBlog Podcast Especial Amazon EC2

DaboBlog Podcast 27

DaboBlog Podcast Especial Seguridad

DaboBlog podcast nº 28

DaboBlog podcast nº 29

DaboBlog podcast nº 30

DaboBlog podcast nº 31

DaboBlog podcast nº 32

Compartir

También el del encuentro “Bloggers de seguridad 2011″, mesa redonda en la que tuve el privilegio de estar junto a Jose Selvi, Manolo Benet, Sergio De Los Santos y Yago Jesús. Lo cierto es que me da bastante palo verme en pantalla y soy el mayor de los críticos conmigo mismo, pero ayer al fin lo visioné, y me reafirmo en las buenas sensaciones que tuve durante mi participación y estancia en León.

Los vídeos;

Todas las ponencias y talleres de ENISE.

El vídeo de nuestra mesa redonda

Para acabar, suscribo al 100% lo que ha publicado Yago en Security By Default, me refiero al gran trato recibido por INTECO, mención especial a Alberto (no tengo tu Twitter;) Javier Berciano y Francisco Losada, un saludo para el resto del equipo y compañeros de mesa, además del público que asistió al evento, sin olvidar a quienes estaban con el streaming -;).

Compartir

Bueno, sobre lo de Twitter y el cambio de password vía web no voy a hablar mucho porque los habituales de DaboBlog lo sabéis. Ya hice la demo en el pasado FIMP, demostrando que se podía acceder (en el caso que presenté) con un cliente móvil con la contraseña antigua todo el tiempo que quisieras hasta que que cerrase la sesión (también lo mencioné en el 5EBloggers del ENISE e hice otra demo vía móvil a varios compañeros de mesa). A modo de recordatorio, en caso de pérdida de un móvil u otro dispositivo ya sabéis, o borrado remoto, o ir a Twitter y revocar el acceso a la aplicación. Aún cambiando vía web el password, seguirán conectados a tu cuenta.

Ahora Dropbox.

Que suceda lo mismo con Dropbox ya no sé si es algo que me preocupa más pensando en la cantidad de cuentas que estarán siendo observadas en caso de robo/pérdida de dispositivo, o por las muchas consecuencias que puede tener dado el tipo de datos que se almacenan. Ojo, desde un móvil y en la aplicación de escritorio (en mi caso Debian + KDE) como se puede comprobar en la captura de pantalla, captura que con toda la intención, está hecha junto al mensaje de Dropbox avisando del cambio de password. (Luego dicen que soy un paranoico por cifrar todo lo que tengo en Dropbox salvo algún PDF o ebook sin importancia…).

Mensaje de "cambio de password" y conectado en mi equipo...

El problema es que si vas al sitio web y revocas el acceso, ya se te avisa que serán conservados los archivos almacenados en el dispositivo de turno…Por lo que cada uno tiene que sacar sus propias conclusiones. Yo lo tengo muy claro, prevenir para no lamentar. Cifrar todo lo que realmente quieras que sea privado y contar con la posibilidad de que pueda suceder algo así.

Pero es que en un Core i3 que tengo con Debian, incluso estando el equipo apagado y arrancándolo, ayer vi que sigo conectado con la contraseña antigua y actualizando cambios sin el más mínimo problema, también desde un iMac con el cliente de Dropbox corriendo en OS X y desde un Windows XP bajo DropBox en Debian, así que…

En el móvil, borrando un fichero con el password antiguo...

Este tipo de situaciones que se dan en muchos servicios que utilizamos de forma masiva, hacen que en casos como los que comento, conviertan a esa “amigable” y tan de moda “nube” en una tormenta tropical a gran escala para quien los sufre…Esta entrada lleva como “borrador” más de 3 días h y sigo accediendo con normalidad a mi cuenta de Dropbox con el password anterior. Y como “regalito” final, no olvides que Dropbox, vía web, tiene una sección que pone “archivos eliminados”, sí, guarda copias de ficheros que tenías archivados, así que puedes pasarte por ahí y hacer una buena limpieza no vaya a ser que…

Compartir

Edito y añado, ya están los vídeos.

Creo que un buen resumen acerca de lo que hablamos lo hizo (y muy rápido, dada la hora a la que nos retiramos) Sergio de los Santos en el Blog del laboratorio de Hispasec. (no “de los Santosm” como dice ABC, tampoco su crónica, leyendo ya el primer párrafo se ajusta a la realidad-;). Edito y añado la crónica de Manolo (grande;) en Security Art Work, así podéis leer todos los puntos de vista.

Por añadir algo a los suyos, entramos en un debate con opiniones diversas sobre si la concienciación en buenas prácticas sobre seguridad informática era efectiva. Bien desde la divulgación pura y dura, acompañada de la dureza de posibles sanciones, etc. Sobre este punto hay una cosa que tengo muy clara, independientemente de las opiniones vertidas, la realidad es que todos los que estábamos en la mesa, desde hace años, venimos haciéndolo en distintos medios y seguiremos haciéndolo. Creo que por encima de nuestras opiniones o percepciones, seguiremos porque es necesario y más con el panorama actual, ciertos mensajes sí llegan al usuario final.

En mi caso creo recordar que me centré relativos a las configuraciones por defecto en los servidores web tal y como se entregan a los clientes, las posibles responsabilidades legales en caso de fugas de información, de viejos problemas en nuevos dispositivos e infraestructuras, del gran nivel en materia de seguridad que tenemos aquí sin falta de mirar tanto hacia fuera, volví a hablar del bug (escribiré una entrada) del cambio de passw en Twitter vía web y cómo desde el móvil se accede con el cliente de turno (en este caso Echofon) hasta que no hagas un “logout”, de que la formación en seguridad es un activo para la empresa, etc.

La “foto oficial” (tomada con mi teléfono y sin una justa atribución;)

Click para ampliar la imagen

De izquierda a derecha;

Javier Berciano (@jberciano) de  INTECO-CERT.

Manolo Benet (@mbnet) de  Security Art Work.

Sergio de los Santos (@ssantosv) de  Hispasec.

(Sín gorra y en el medio para el “balance de blancos de la foto;)

 Jose Selvi (@JoseSelvi) de  Pentester

Yago Jesús (@Yjesus) de  Security By Default.

Francisco Losada (@flosadam) de INTECO-CERT.

Por cierto, en la foto falta Alberto López (un saludo desde aquí) y dejando a un lado nuestra mesa o ponencia, quiero resaltar el excelente trato que se nos dio a todos, el gran componente humano, la cercanía y ganas de ayudar que hay detrás de unas siglas como INTECO.

Sobre todos los contenidos que aportan día a día y su calidad, es algo que cualquiera puede comprobar vía web. Herramientas de seguridad, formación gratuita en línea, boletines de noticias, documentación en PDF sobre cuestiones de privacidad en redes sociales, para PYMES o autónomos y un largo etc. Yo tengo descargados muchos de sus contenidos.

Sobre los compañeros del “5EBloggers“, que voy a decir, después de la sorpresa de última hora con la incorporación de Sergio, ha sido toda una experiencia para mi compartir ponencia, “plato y mesa”" además de alguna copa, con gente a la que sigues habitualmente y por fin les puedes poner cara, pero también comprobar, que en “las distancias cortas”, te dejan las mismas buenas sensaciones que en la distancia que te separa de ellos a través del cable de red cuando lees sus contenidos.

También pude “ponerles cara” a muchos otros como David Barroso, Ignacio Vázquez, Pablo Teijeira, etc y ver a gente ya conocida como Samuel Linares además de algún otro (del que no tengo su Twitter;).

En definitiva, una experiencia como para repetir sin dudarlo, gran organización, profesionalidad y más humanidad. Muchas gracias a INTECO-CERT por haberme hecho partícipe de un evento como este y un saludo a toda la gente con la que he estado estos días.

Compartir

Hoy vamos hablar de una herramienta interesante que ya mencioné  hace más de un año en el pasado FIMP. Se trata de “Whatweb”, (acceso a la web del proyecto y su lugar en GitHub). Se trata básicamente de una herramienta capaz de identificar las versiones instaladas de la gran mayoría de CMS (gestores de contenidos) actuales, plugins y una gran variedad de aplicaciones web. También proporciona datos tan relevantes como versiones de Apache, SSL o PHP a través de la información extraída de las “cabeceras” o “banners” que lee cuando realiza una petición al website en cuestión.

"Features" (Según se lee en la web del proyecto):
	* Over 1000 plugins
	* Control the trade off between speed/stealth and reliability
	* Plugins include example URLs
	* Performance tuning. Control how many websites to scan concurrently.
	* Multiple log formats: Brief (greppable)
          XML, JSON, MagicTree, RubyObject, MongoDB, SQL.
	* Proxy support including TOR
	* Custom HTTP headers
	* Basic HTTP authentication
	* Control over webpage redirection
	* Nmap-style IP ranges
	* Fuzzy matching
	* Result certainty awareness
	* Custom plugins defined on the command line

Por lo general, simplemente dentro del directorio desde donde hayamos descargado Whatweb, ejecutamos;

Buscando información con Whatweb y “Server Spy”.

dabo@debian:~/whatweb$ ./whatweb *****web_muy_conocida.com

http://******.com [302]  HTTPServer[Apache/2.2.9 (Debian) mod_ssl/2.2.9 OpenSSL/0.9.8g], RedirectLocation[/es/], X-Powered-By[PHP/5.2.6-1+lenny13],

Como podéis ver, ese servidor, revela mucha información. Pero no hace falta usar nuestro apreciado Nmap ni otras técnicas más complejas a la hora de recopilar información. Si ponemos como ejemplo Spotify, hubiese bastado con una extensión para Iceweasel / Firefox tan simple como puede ser “Server Spy“.

Si hablamos de la detección de versiones en un gestor de contenidos tan utilizado como WordPress, sobre el que hace unos días escribí una entrada con medidas para mejorar su seguridad, junto a una recopilación de  20 plugins recomendados, vamos al siguiente párrafo…

Como ejemplos bajo WordPress, podríamos ver muchos sites tan visitados (supongo, que no es mi caso;) como la web del “incombustible” Sylvester Stallone (la foto de portada no tiene desperdicio), u otros tan visitados como Mashable funcionan con este CMS . (Aclarar que en muchas ocasiones, simplemente viendo el código fuente, además de la versión de WordPress, también se suelen revelar muchos otros datos de interés).

dabo@debian:~/whatweb$ ./whatweb http://****web_muy_conocida.com/

http://******.com/ [200] X-Powered-By[PleskLin], WordPressSpamFree[2.1.1.1], HTML5, HTTPServer[Apache], WordPress[3.2.1], JQuery, UncommonHeaders[x-pingback], MetaGenerator[WordPress 3.2.1],

Ahí, incluso vemos algún plugin como WordPressSpamFree y su versión, además de la propia de WordPress. Pero en este caso, el servidor está mejor configurado si hablamos de “seguridad por oscuridad” ya que no revela la misma información que el que aloja la web de Spotify, la diferencia es la presencia por ejemplo de Plesk junto a WP.

Con un “simple” curl -i

Pero también, desde la línea de comandos, con una simple petición realizada con “curl“, ya sería suficiente para conseguir mucha información

dabo@debian:~$ curl -i spotify.com

HTTP/1.1 302 Found
Date: Mon, 24 Oct 2011 18:22:33 GMT
Server: Apache/2.2.9 (Debian) mod_ssl/2.2.9 OpenSSL/0.9.8g
Location: http://www.spotify.com/
Vary: Accept-Encoding
Content-Length: 312
Content-Type: text/html; charset=iso-8859-1

El mismo ejemplo realizado con este blog (también bajo Debian y Apache, no vamos a descubrir/ocultar ahora la pólvora;) con esa petición vía curl, devolvería una mínima información.

dabo@debian:~/$ curl -i daboblog.com

HTTP/1.1 301 Moved Permanently
Date: Mon, 24 Oct 2011 18:25:04 GMT
Server: Apache
X-Pingback: http://www.daboblog.com/xmlrpc.php
Location: http://www.daboblog.com/
Vary: Accept-Encoding
Content-Length: 0
Content-Type: text/html; charset=UTF-8

Simplemente pone “Apache” y no se proporciona otra información. ¿Cuál es la diferencia?. Básicamente, la forma de evitar este exceso de información y por resumirlo en dos acciones a realizar (que hay mucho más, lógicamente), se trata de modificar lo siguiente.

Cambiando la configuración de Apache.

En la configuración de Apache (en Apache 2 y Debian estaría por defecto en /etc/apache2/apache2.conf)

Cambiamos los siguientes valores; “ServerTokens” por defecto está en “Full”, lo cambiamos a “Prod”. Otra directiva, “ServerSignature” por defecto está en “On”, lo cambiamos a “Off”.

Luego con un /etc/init.d/apache2 reload para que vuelva a “leer” la configuración de Apache sería suficiente ¿o no?.

Realmente no, ya que, a través de otra directiva por defecto que viene en la configuración de PHP, se revela también información acerca de estas cuestiones tal y como se puede comprobar aún con esa directiva cambiada en Apache con otro curl -i.

Cambiando la configuración de PHP.

Para ello, editamos el fichero de configuración de PHP, php.ini (En Debian o Ubuntu sería por lo general en /etc/php/apache2/php.ini). En otras distros al igual que con Apache (o httpd.conf) podéis buscar con un find / -iname php.

El valor “expose_php” por defecto está en “On”, hay que ponerlo en “Off” (no olvidéis hacer un “reload” a Apache para que cargue esta nueva conf de PHP). Esta directiva, además de revelar que está ejecutándose PHP, algo que no es un riesgo para la seguridad realmente, también proporciona información sobre la versión de Apache y en ocasiones del S.O, por lo que tampoco como se ha podido ver, no harían falta herramientas como xprobe o la función “fingerprint” de Nmap para saber que distro o versión de GNU/Linux corre en el servidor.

Como podéis ver, eso de “la seguridad por oscuridad” de oscuro tiene poco, yo diría que “clarifica” las cosas, aunque esto de la seguridad web es un concepto mucho más amplio, donde la “seguridad total” es un mito hablando de estos entornos. Estamos hablando de técnicas simples y nada intrusivas, pero que pueden hacer que nos llevemos algún susto si nos pilla con el pie cambiado alguna actualización, o sale el típico “0 day” (que nos puede pasar a todos). Nos vemos en el capítulo 2 de “/* Sec Tools */”.

Compartir

Con el tema “Hacia una sociedad conectada más confiable” (ceo que el tema dará mucho juego), pudiendo seguirse de un modo presencial (entrada libre hasta completar el foro) o para quienes no puedan asistir, vía web. Tras una primera intervención por parte de quienes formamos la mesa, luego habrá un turno de preguntas y respuestas. En Twitter, el “hashtag” será; #5Ebloggers

En la mesa compartiré espacio junto a;

Moderador; Javier Berciano (Coordinador del Área de Operaciones de INTECO-CERT)

José Selvi Pentester | Manuel Benet Security Art Work |  Yago Jesús SecurityByDefault

Así que ya sabes, si te pasas por León, allí nos veremos, gracias a la organización por invitarme a asistir y un saludo a los compañeros de mesa ;).

Más info; “Encuentro Blogueros de Seguridad 2011“.

Compartir

Ya he hablado antes en DaboBlog de seguridad y WordPress. No hace mucho, publiqué en mi cuenta de Twitter un enlace con el título “Hardening WordPress” (la guía oficial de WordPress para fortificar instalaciones de WordPress). El amigo Jordi Prats de “System Admin”, escribió un artículo “Configuración segura de Apache para WordPress“, con el fin de evitar el listado de plugins frente a una auditoría realizada con nuestro querido Nmap (vía el script http-wp-plugins para nmap)

En el caso de Jordi, fue a raíz de un post muy interesante de Chema Alonso (de “El lado del mal”) en el que realizaba un ataque de este tipo, con algún tip más (por ejemplo el típico error del listado de directorios en Apache y entrar “hasta la cocina”).

Pero tenía pendiente esta entrada sobre este tema y está dedicada especialmente a Dani de “El Arca de la alianza” ya que en alguna ocasión me lo había comentado, y era algo en “pendiente” desde que grabé con él un podcast sobre “Iniciación a la seguridad informática”.(y a ver si retomas la publicación bandido;).

Sobre todo esto se ha escrito por supuesto mucho y muy bien en otros blogs, pero destaco y recomiendo leer los enlaces a las entradas de WordPress.org, Jordi , Chema, Security By Default y Oreixa (con esos seis enlaces ya tenéis una buena hoja de ruta para empezar) ya que me parece que todo puede ser complementario. También citaré alguno útil en el caso de que tengáis el registro de usuarios activado en vuestro blog.

Además de cuestiones como proteger la cuenta de admin (o cambiar el nombre), tener passwords potentes (y cambiarlos), habilitar incluso el acceso por SSL al área de administración (Oscar Reixa habló de ello y publicó una entrada de la parte que tocó de WordPress junto a mi en el FIMP 2010) o una configuración de PHP para que en el caso de que haya algún fallo en la ejecución de una función o un plugin (display errors “off”) para que no revele el “path” o ruta de la instalación de WordPress (un tema publicado no hace mucho en Security By Default, recomendable su lectura). Sobre cuestiones de seguridad, servidores web y Apache (que está todo relacionado), quizás os sirva también de ayuda el resumen de mi participación en el FIMP de Gijón (2010).

# 21 Plugins para dotar a WordPress de más seguridad.

#Actualizado, gracias por vuestras sugerencias ;)

 Vamos a pensar que no todo el mundo tiene acceso vía SSH para controlar su servidor, puede estar en un hosting compartido y creo que sobra decir que si no tenéis vuestra instalación, temas en algún caso y plugins actualizados, de poco servirán muchas de las medidas de prevención comentadas.

Akismet; Todo un clásico, poco hay que hablar de él, salvo que conviene mirar de vez en cuando los comentarios o “trackbacks” ya que no es muy difícil ver “falsos positivos” y más cuando alguien en un comentario alguien mete más de 3 enlaces como se puede configurar en “Ajustes-Comentarios”). Web del plugin

Comment Timeout; Como complemento a Akismet es perfecto. Permite cerrar los comentarios en entradas antiguas, tanto a nivel global, como en cada entrada individualmente. También funciona con los “pingbacks” o “trackbacks”. Web del plugin.

WordPress Backup (BTE); Realizar una copia de seguridad de vuestro tema actual, uploads, imágenes, el tema actual, etc en un directorio (formato .zip) también hay una opción para enviarlo todo por e-mail. Web del plugin.

WordPress Database Backup; Como complemento al anterior, realizar backups de vuestra base de datos (incrementales) y además, tiene la opción de poder enviarlos por e-mail. Web del plugin.

Automatic WordPress Backup; Según nos sugiere e informa en los comentarios Rastreador “Este plugin realiza backups periódicos de tu instalación de WordPress contra un servidor S3 de amazon”. Web del plugin.

WP-DBManager; al igual que si desde vía SSH ejecutáis comandos MySQL como mysqlcheck -o (optimize) – c (check) -r (repair), este plugin hará lo mismo, ayudando a que vuestra base de datos esté siempre a punto. Web del plugin.

Stop Spammer Registrations Plugin; Aquí ya entramos en el tema de los blogs con registro de usuarios habilitado, previene y puede dejar en “cola” de aprobación, a los usuarios con correos o IPs que puedan estar marcados como “spammers” por StopForumSpam.com, Project Honeypot, DNSBL o BotScout. Web del plugin.

Además del comentado “Stop Spammer Registrations”, que ayuda con el Spam y usuarios potencialmente peligrosos puede estar bien usarlo junto a;

Cimy User Extra Fields; Posibilita la opción de reforzar el área de registro del blog, con campos personalizables, sistemas de verificación del registro, puedes ver en una lista de los usuarios pendientes de activar su cuenta, etc (ejemplo en Daboblog con otro parecido, Register Plus Redux). Web del plugin.

Wp Contact Form 7 + Really Simple CAPTCHA; Una buena opción de formulario de contacto junto a la función de Captcha del “Really Simple” para evitar Spam en el envío de correos. Web de WP Contact Form 7 | Web de Really Simple Captcha.

WP Hide Dashboard; También útil para blogs con registro de usuarios, remueve los campos innecesarios del perfil de usuario para que no pueda acceder a otras áreas administrativas. Web del plugin.

Login LockDown; Plugin para prevenir ataques de fuerza bruta contra el usuario / password. Por citar un ejemplo, puedes definir que con 3 intentos fallidos de “login”, se realice un bloqueo contra la IP durante 600 seg. Luego verás una lista de las IPs bloqueadas (pudiendo sacar alguna de esa “lista negra”. Web del plugin.

AskApache Password Protect; Un gran plugin que no estaba añadido, permite autenticación “HTTP Basic” o una más segura “HTTP Digest Authentication”. Te puede ayudar a bloquear Spam y conservar recursos de CPU, memoria, base de datos, etc. Puedes elegir un usuario y password para proteger además del login, directorios como wp-admin, wp-includes, wp-content, plugins, etc. Web del plugin.

Exploit Scanner; Puede ser útil en el caso de que vuestra instalación haya sido comprometida, para buscar en la base de datos, o ficheros, rastros de y huellas de un ataque (también busca en el CSS, HTML, etc). Ojo a los 128 mb de memoria. Web del plugin.

Secure WordPress; Múltiples funciones como pueden ser; remover la versión de WordPress, crear un archivo “index.php” en /themes o /plugins para evitar el listado de directorios, proteger vuestro WordPress contra peticiones de URL maliciosas, evitar que tanto WP a nivel de Core o sus plugins no se actualice salvo por administradores, remover de wp_head opciones como “Windows Live Writer” o “”Really Simple Discovery”" o remover informaciones de error en el login. Web del plugin.

Block Bad Queries (BBQ); Ayuda como el anterior a proteger WordPress de peticiones de webs o IPs maliciosas, realiza un chequeo de cadenas excesivamente largas (por ej mayores de 255 caracteres) , también controla peticiones URI / “Base 64″, etc. Web del plugin

WP-Sentinel; Además de un sistema de bloqueo de IP, alertas al usuario en caso de ataque, etc, protege la instalación de algunos ataques tan comunes como; “Cross Site Scriptings, HTML Injections, Remote File Inclusions, Local File Inclusions, SQL Injections, Cross Site Request Forgery, Login bruteforcing, Flooding“. Web del plugin.

WP Security Scan; Realiza un chequeo de tu WordPress buscando posibles vulnerabilidades y sugiere acciones correctivas en campos como; passwords, permisos de ficheros, seguridad de tu base de datos, oculta la versión de WP, protección para la zona de administración y remueve la etiqueta ” WP Generator META” del “core” de WP. Web del plugin.

AntiVirus for WordPress; Su función es realizar búsquedas diarias con reportes vía mail de en vuestro WP por si hay algún script o llamada maliciosa, protege de ciertos exploits e inyecciones de spam. Otra protección contra el malware en vuestro blog. Web del plugin.

Mutex; (tal y como publican en Security By Default) “Es un plugin para WordPress que incorpora PhpIds y además, lo integra perfectamente en WordPress permitiendo su administración desde el panel de gestión”. Web del plugin.

Además de todo esto, os recomiendo dar un vistazo a esta entrada del mes pasado en DaboBlog sobre “Web Site Defender“, un servicio muy interesante para controlar instalaciones de WordPress. Y recordad borrar el readme.html que da la versión !

Espero que os sea de utilidad, partiendo de la base que siempre se podrán encontrar brechas de seguridad en un sistema remoto y, que ese concepto de la “seguridad total” es sólo eso, un concepto, estas acciones os ayudarán a estar “un poco más tranquilos”, saludos ;).

Compartir