martes, 21 de abril de 2015

Cuidado con lo que deseas. S.M.A.R.T. GOALS. El consultor te venderá lo que quiera...

Estimados amigos de Inseguros !!!

Seguro que todos hemos visto alguna fábula, película, parodia, etc en la que la presencia del genio de la lámpara y sus conocidos 3 deseos se vuelven en contra de uno mismo.

En el ámbito de la informática o en cualquier gestión de proyecto que se cruza por nuestro camino debemos realizar una tarea de análisis de nuestro objetivo. Por lo general, solemos buscar soluciones que consigan nuestro objetivo, pero eso solo es un punto.

SMART criteria corresponde a unas siglas que resumen a la perfección los criterios que debemos cumplir a la hora de "levantar la mano" en la reunión con nuestra mega-fantástica solución, y no parecer de primero de CCC o un simple vende humos, de los muchos que pasan por las empresas. Sirve para evaluar tanto tus soluciones mágicas como las que te ofrecen.

Vamos a poner un ejemplo cercano, conocido, de un gerente "analfabeto tecnológico" o quizás en general...

Un día se levanta y piensa que no le gusta la telefonía convencional, que ha escuchado muchas veces eso de VOZ sobre IP, y que "te ahorras el dinero" y demás benevolencias. Lo peor de todo es que antes de consultar con su responsable de informática, o eso ponía en su chapita, decide consultar con la consultora más cara de la ciudad, la mejor de la mejor.

Para ir al grano, la consultora propuso una solución basada en Lync, de Microsoft, la cual se alimentaba de Sql Server como motor de BBDD, Exchange, Lync Server, licencias, módulos de explotación de información, gb de RAM/SAN, etc

Yo he visto soluciones de este tipo de comunicaciones unificadas en empresas y realmente son un producto que ofrece todo lo que vale. Aquí es donde entra S.M.A.R.T. criteria.:

Volvemos a las siglas:


Specific –Tiene que ser una solución focalizada al propósito que estamos buscando. En el ejemplo no se define un problema-solución, sino uno conjunto de sensaciones ( la telefonia clásica fallaba) ciertas o falsas, y sobre todo el poder del gerente en tener "lo mejor de lo mejor".

Measurable – Tiene que poder medirse el progreso. En el caso del proyecto de comunicaciones, el poder establecer varias fases, sobre todo la convergencia del sistema antiguo-moderno para depurar errores. La consultora sin embargo prefería llegar y ponerlo todo en un día. Claro, con esos expertos para que medir !!! Aquí es donde al vendedor le interesa que no hayas apuntado cifras de rendimiento y demás mentiras. Por supuesto, definir que es el fin del proyecto. Para este caso, después de pagar por todo lo habido y por haber, le quedaban pequeños "flecos" como poder consultar las llamadas de una persona un día, una consulta sql de 2.000€.

Assignable – Asignable. Tu pregunta en tu empresa quien quiere más trabajo por el mismo dinero, que seguro que te salen muchas manos. Multiplica eso por una plantilla con más de 10 años dentro. Cuando el vendedor hablaba de la parte de análisis que debía hacer el personal interno, procuraba que fuera de pasada, como para no hacer mucho ruido. El proyecto no solo lo va a gestionar IT. El proyecto lo deben "configurar" los jefes de departamento para re-analizar el comportamiento de los grupos de llamadas, los re-envíos, prioridades, rutas y demás. El problema no era la falta de "asignables" o su falta de motivación por la tarea. NO, el problema es que con la lógica de negocio de los grupos de llamada se pretendía solucionar TODOS los problemas de muchos años de la empresa: Pepi no coge nunca el teléfono, Pepo almuerza 1 hora y nunca está en el sitio, a Julio no ponerselo porque es tonto. Etc etc etc. Esa línea en el presupuesto, pequeña, que encima iba a precio cero porque se asumía interna, empieza a ponerse como mi cuenta, en números rojos !!!



Realistic – Realista. Algo parecido al punto anterior en el caso de esta empresa. Pretendes que una persona que por ejemplo, está esperando el despido-finiquito, invierta tiempo,ganas, ilusión en usar "1000 ventanas más". Pretendes que Pepo el presumido use unos "pinganillos" y así estropear su look?. Pretendes que una plantilla con BAJO conocimiento en informática asuma el cambio de un teléfono analógico a "1000 ventanas"?
Time-related – Linea de tiempo. Esto suele ser la espiral que se muerde la cola. Para el ejemplo que os relato se estableció un perfecto cronograma digno de los 40 folios del presupuesto. En el se totalizaban las horas en cada fase. Qué suele pasar con esto? lo habitual es que le cuentes tus problemas al consultor con Pepa, Pepo y demás. Que el consultor te escuche, te aconseje, y que por encima de todo, su trabajo, el principal, esté acabado ( el consultor por mucha corbata que vista también tiene jefe...). Acabado es que se pueda llamar y recibir llamadas con los "pinganillos" conectados al PC. 


Cuando la consultora, cansada de dar soporte, de hacer horas, en configuraciones y RE-configuraciones por culpa del cliente suele dar un toque de atención, casi siempre a modo de factura de horas. Recuerdas al principio que decía Lync Server? Cuantas consultoras específicas hay en tu Ciudad sobre esta tecnología? Son baratas? puedes irte a cualquiera sin experiencia con un servicio crítico dentro de la empresa? Se tomó una buena decisión?

A lo largo de mi vida laboral me he encontrado con muchas personas, muchos proyectos, muchas ideas de este tipo. Humaredas detectables a kilómetros con final en fuego.

Cuando te propongas una meta, sea la que sea, contempla estos 5 puntos, te puedes acordar del modelo de un coche... Lo que no puede ser es idea mágicas, que no se muy bien como, al final siempre acaban en jornadas de investigación o trabajo tiradas a la basura. Si estás inmerso en algún proyecto de este tipo, en vía muerta, y no tienes más remedio, quizás puedas plantearte dar el 100% de ti aunque sepas de antemano que no vas a llegar a nada, quizás esta experiencia infructuosa te sirva en otro ambiente-empresa. O por el contrario, puedes ponerte en modo "funcionario" y cortar a tu hora.


Como siempre, espero que os guste, gracias por leerme !!!

PD: a los más curiosos. El resultado fue un Lync Server de 70.000€ por tener pinganillos MALOS en vez de teléfonos. Los buenos se rompían y se reponían por unos de los todoacien, por lo que encima se hoy MAL.
Lo peor es que venían de un sistema mixto analógico-digital, basado en un cisco call comunicator server en HA ( es decir, dos) en la época que costaban un kilo.
 xDDDd


miércoles, 15 de abril de 2015

Bloquea el acceso de la red TOR a tus sistemas. Ejemplo CSF firewall.

Estimados amigos de Inseguros !!!

En el post de hoy vamos a dar un pequeño truco para bloquear el tráfico proveniente de la red TOR.

En el ejemplo usado vamos a implementar el bloqueo en un firewall CSF, pero el proceso es el mismo para cualquier firewall que admita comandos remotos, por ssh o como sea !!!

La idea es usar https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=TUIP para saber que nodos tienen salida hacia mi ip.

El script sería algo así:

wget -q https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=TUIP -O -|sed '/^#/d' |while read IP
do
  /usr/sbin/csf -td ${IP} 24h TOR
done

Ejecutando el script en un cron o tarea programada una vez al día, podemos banear la lista de nodos que tienen acceso a nuestra ip pública. Todos los días se actualizará la lista. Al haber usado un baneo temporal de 24 horas, no me preocupa la gestión de desbaneos.

Espero que os sirva de ayuda, gracias por leerme !!!

martes, 14 de abril de 2015

Consola web para Mod Security.

Estimados amigos de Inseguros !!!

En el post de hoy vamos a trabajar con la consola de Mod Security. Hemos escrito algún post por aquí trabajando con el popular Web Application Firewall de software libre.

Podemos elegir entre desplegar los ficheros war de la aplicación en un servidor Tomcat existente o usar una versión Standalone que nos proporciona todo lo necesario para ejecutar la consola, incluido Catalina. El proceso de instalación es muy sencillo.


Una vez descargado el proyecto ejecutamos: /opt/AuditConsole/bin/catalina.sh y  accedemos a http://address-of-your-server:8080/ con el usuario admin/admin y procedemos a configurar las opciones iniciales, muy intuitivas.


Lo opción inicial que vamos  a manejar es la de cargar un fichero .log manualmente, el clásico upload manual.


Comprobamos que se nos ha cargado la información de logs que enviamos con el fichero.



Vamos a configurar un sensor externo, la instalación de nuestro servidor web con Mod Security la cual queremos monitorizar con la consola.



Ahora comprobamos que desde el equipo en el que hemos instalado la consola accedemos al webservices que se encarga de recibir los logs de Mod Security.

http://172.16.100.61:8080/rpc/auditLogReceiver

Podemos modificar el puerto o la ruta desde el script catalina.sh que levanta el servidor de la consola.

En el servidor donde tenemos instalado Mod Security modificamos unas cuantas líneas para hacer que el log se encamine por mlogc hacia nuestro server. Indicamos el fichero de configuración.


En el fichero de configuración de mlogc tenemos que establecer la url y el nombre de usuario y contraseña del sensor que previamente hemos configurado.

Ahora ya podemos ver los eventos de Mod Security en nuestra consola en modo on-line.


Espero que te haya gustado el post y te sea útil, gracias por leerme !!!

lunes, 13 de abril de 2015

Honeypots XIII. Phpmyadmin + modsecurity+lua parser.

Amigos de Inseguros.

Hemos escrito ya algunos artículos sobre Honeypots (1, 2, 3, 4 ,5, 6 , 7. 8 9 11 12 ).

Dentro de los artículos que estoy escribiendo sobre recolección de inteligencia, vamos a hablar hoy de un pequeño Honeypot llamado PHPMYADMIN. Podemos usarlo para crear nuestra base de datos de reputación online. Con nuestro sistema de despliegue automático de Honeypot.

El título lo explica todo. Es un honeypot de interacción media. No solo tenemos el formulario de login sino un interface de uso "parecido" al real.




La instalación del honeypot es muy sencillo, seguimos el manual, simplemente copiamos el directorio del proyecto bajo nuestro webserver, le damos unos permisos al fichero de log y listo. En el fichero de login.php podemos habilitar el usuario/contraseña que dará acceso al falso phpmyadmin.

Lo interesante de este honeypot para mí es la pequeña interacción que le permite al atacante, ya que el sistema de logs que proporciona es muy escueto, quedando reducido a fecha, ip, recurso.


Con esta información podría trabajar con la dirección IP, pero prefiero saber qué está pasando realmente. Para ello, he instalado Mod Security sobre el Apache que sirve al honeypot, para recolectar toda la información sobre el ataque. El proceso lo he realizado sobre una máquina Honeydrive, por lo que el proceso de instalación de mod security para debian/ubuntu genérico me sirve. 

apt-get install libapache2-modsecurity
mv /etc/modsecurity/modsecurity.conf-recommended modsecurity.conf
service apache2 reload

Modifico el fichero modsecurity.conf para indicarle que me haga log de todos los eventos, no solo los 400 y 500 como se marca por defecto SecAuditLogRelevantStatus lo dejó así: SecAuditLogRelevantStatus "^(?:5|2|4(?!04))" y por supuesto hago un apache2 reload.

Para quitarme los Internal Dummy de Apache, configuro en apache2.conf la siguiente directiva:

SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
SetEnvIf User-Agent ".*internal dummy connection.*" dontlog

De esta manera ya podemos ver la información detallada de la actividad maliciosa sobre el honeypot.


Bien, ahora tenemos un honeypot funcionando y modsecurity generando fichero de logs. Todos sabemos lo complicado de parsear este log, y mucho mas si modificamos las opciones de "profundidad" de log. Para solventar este problema, voy a usar la posibilidad de mod security para ejecutar scripts.

Podemos ejecutar cualquier scripts en sh, pero si queremos tomar variables de mod security debemos emplear un script en LUA. La directiva está bien documentada en el manual de referencia. SecRuleScript y el script en LUA podría tener algo de este aspecto.

function main()
        local remote_addr = m.getvar("REMOTE_ADDR");
        if remote_addr == nil then
                return nil
        end
local request_uri = m.getvar("REQUEST_URI");
        if request_uri == nil then
                return nil
        end
-- INFO:::RULE_ID. Contiene el id de la regla que se ha ejecutado.
        local rule_id = m.getvar("RULE.id");
        if rule_id == nil then
                return nil
        end
-- INFO:::RULE_MSG. Contiene una descripcion de la rule que se ha ejecutado.
        local rule_msg = m.getvar("RULE.msg");
        if rule_msg == nil then
                return nil
        end
 local log_file = "/turuta//modsec_full.log"
        file = io.open(log_file,"a")
        file:write("IP: "..remote_addr.."\n".."Metodo: "..request_method.."\n".."Protocolo: "..request_protocol.."\n"..Matched by: "..matched_vars_names.."\n".."Regla id: "..rule_id.."\n".."Regla msg: "..rule_msg.."\n".."Hora: "..time.."\n".."----------------------".."\n")
        file:close()
end

De esta manera podemos obtener en un único registro, todas las variables o campos que nos interesan del log de Mod Security. Con esa información podemos alimentar nuestro sistema de inteligencia o de base de datos de reputación online con la información que nos llega de este honeypot, basado en PhpMyAdmin.

Como siempre, gracias por leerme, espero que os guste.

jueves, 9 de abril de 2015

NTP para ataques DDOS amplification. Identificación, explotación y mitigación.

Amigos de Inseguros.

En el capítulo de hoy vamos a ver algún consejo a la hora de trabajar con los servidores NTP y como los maleantes pueden utilizarlo para hacer el mal !!!

Para empezar, NTP es el protocolo utilizado para sincronizar equipos con un servidor...funciona por UDP. Cuando repasamos el protocolo UDP recordamos que no mantiene la conexión, solo envía el paquete y confía en su recepción.

Una de las amenazas mas reales que estamos sufriendo las organizaciones son los ataques de denegación de servicio. El objetivo de estos ataques, como sabes, es generar el mayor tráfico posible hacia nuestros sistemas para conseguir colapsarlo y hacer que esté deje de funcionar.

Vamos a imaginar que tenemos una conexión a Internet que nos proporciona 1kb de subida. Y tengo un servidor que procesa 10 kb de entrada. Con 10 conexiones como las mías colapsaría el servidor. Esto es lo que hace el ataque de la famosa herramienta Loic de Anonymous y similares ataques syn flood.


Que es la amplificación? Imagina que por cada 1kb de subida que yo tengo, que envio al servidor, magicamente se multiplica por 10. Con una conexión como la mia colapsaría los 10kb de capacidad del servidor, por lo que me es más fácil realizar la denegación de servicio.

Vamos a usar un fallo o mala configuración en servidores NTP accesibles en Internet que podemos usar para amplificar una petición NTP y dirigirla como si la hubiera pedido una víctima, para que sea la víctima la que reciba la respuesta.

Existe un comando en versiones antiguas de NTPd <4.2.17 que me permite en remoto, acceder al comando monlist y listar los últimos 600 equipos que han realizado una petición de tiempo.

Vamos a probarlo con un equipo público en Internet vulnerable.
Lo podemos realizar con el script NSE mon-list o directamente consultando el comando con el cliente ntp.



Mediante esta petición UDP que es muy pequeña podemos recibir gran cantidad de información. En este servidor de pruebas que he encontrado solo hay un par de ip´s clientes que han consultado al servidor NTP, pero es suficiente para amplificar mi petición. De una petición pequeña que hago me devuelve una respuesta más grande.

Aquí es donde vas a comprender porque se utilizan protocolos sobre UDP. Si yo realizo esa petición falseando la dirección ip de origen, y en su lugar ingreso la ip de una víctima de nuestro ataque, la respuesta le llegará a la víctima. Hemos conseguido amplificar nuestra petición a un "tercer equipo" que va a inundar de respuestas a la víctima. El ataque de denegación de servicio lo realiza el servidor NTP mal configurado que permite esta consulta.

Vamos a realizar una captura de red del tráfico de salida para la petición y otra para la respuesta para ver el ratio de amplificación en bytes.


Como se aprecia el ratio es muy pequeño, no llega ni a 1x2. Vamos a probar con otro servidor NTP expuesto con la mala configuración o vulnerabilidad.


El resultado de la captura de red lo dice todo.


El factor de amplificación para este servidor NTP es de x32. Deberíamos corregir un poco estos valores porque realmente el tamaño del paquete udp de la petición es de 234 bytes.


Al igual que con ataques de amplificación DNS, cualquier servicio basado en UDP es "susceptible" a ser empleado por este procedimiento. El profesor Nolla en su blog tiene unos artículos sobre amplificación ddos con servidores Quake3 que recomiendo leas.

Como es lógico, en el caso de implementar un servidor NTPd accesible en Internet por la razón que sea, debes comprobar que no tienes una versión vulnerable, o al menos, deshabilitar el comando monlist.

Existen listas públicas en Pastebin con listados de servidores NTP mal configurados disponibles para nuestras perrerías. Quizás muchos sean honeypots.

De cara a defendernos del ataque, tenemos pocas posibilidades aunque si que podemos parar/loguear en nuestro firewall los paquetes udp 123 con un tamaño de 482 bytes que es el tamaño de cada paquete pero al final si el ataque persiste y no se implementa una medida de desviación previa, con más capacidad de procesamiento, podremos registrar y mitigar el ataque, pero no pararlo. El DDOS es lo que tiene !!!

Como siempre, espero que os guste el artículo, gracias por leerme !!!