Quantcast
Channel: INSEGUROS Seguridad informática
Viewing all 511 articles
Browse latest View live

Recursos GRATIS para estudiar seguridad y obtener certificado.

$
0
0
En la entrada de hoy voy a "promocionar" los servicios de una empresa que casi todos conocemos.
Hablo de Eset.

Una de las compañías pioneras en el mundo de la detección de virus.

Eset pone a disposición de la comunidad una seria de cursos relacionados con la seguridad, en los cuales podemos iniciarnos en las materias propuestas, y realizar un curso tipo Moodle en el que al finalizar exitosamente el contenido y examen nos harán poseedores de un magnifico certificado acreditativo.

Desde Eset Latinoamérica podemos realizar los siguientes cursos:

Introducción a Python
ESET Mobile Security para Android
Especialista en Seguridad de la Información
Especialista en Seguridad de la Información Corporativa
Seguridad en dispositivos móviles
Navegación segura
Seguridad para PyMEs
Curso de Backup
Seguridad en las transacciones comerciales en línea
Cómo armar una red hogareña segura
Uso seguro de medios informáticos


Espero que os gusten los recursos, gracias por leerme.


OSSIM 16. Update Openvas y conexión con servidor externo via OMP.

$
0
0
En el episodio de OSSIM de hoy vamos a realizar algunas operaciones cotidianas en el mantenimiento de OPENVAS y resolución de problemas básicos, pero solo aspectos relativos a OSSIM.
También vamos a conectar un OPENVAS existente en otro servidor a nuestra consola OSSIM.

Lo primero que vamos a hacer es actualizar la base de datos de firmas o plugins por el interfaz gráfico. Recuerda tener siempre actualizado tu "hacker-kmow-how" para las amenazas recientes.


Otra manera de realizar la actualización de firmas de Openvas es mediante la consola, siguiendo estas sencillas instrucciones.




Si estás acostumbrado a usar OPENVAS en cualquiera otra distribución sabrás que la base de datos de firmas se suele corromper, sobre todo tras actualizaciones ( de Openvas o el propio OSSIM).
La solución es sencilla, regenerarla.

openvasmd --rebuild
/etc/init.d/openvas-scanner restart
/etc/init.d/openvas-manager restart
/etc/init.d/openvas-administrator restart

Como es lógico, en este punto del artículo estás pensando ¿ via Cron? por supuesto caballero/Señora !!!
openvas-nvt-sync --wget
/etc/init.d/openvas-scanner restart
perl /usr/share/ossim/scripts/vulnmeter/updateplugins.pl update

Lo hagas de la manera que lo hagas, dedícale un buen rato a la tarea, quizás por encima de los 30 minutos.

Una de las cuestiones que se presentan con Openvas OSSIM es la configuración y personalización.
Puede que en tu despliegue tengas un servidor OPENVAS previamente configurado con usuarios y políticas y quieras integrarlo en OSSIM, simplemente para tener la información de seguridad centralizada, SIEM !!!!

Lo primero que haremos es desde OSSIM comprobar que tenemos conectividad con nuestro servidor OPENVAS mediante el comando OMP.

omp -h servidor -p 9390 ( puedes omitir puerto) -u usuario -w clave -g ( man omp da una lista completa de comandos. con g listamos los tipos de scans configurados).

Una vez detectado el problema de firewall/nat/unicornios en OSSIM agregamos un nuevo sensor. Sería el mismo procedimiento que efectuaríamos en el caso de instalar un sensor remoto OSSIM ( segunda opción en el menú de instalación del fichero .ISO).


 Es curioso que lo creamos por defecto, pero tenemos que modificarlo para indicarle que va a ser VulnScan.

De esta manera podemos manejar nuestro Openvas Remoto sin tener que recrear toda la configuración existente en OSSIM.

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



OSSIM 17. PCI DDS

$
0
0

Después de varias entradas (1234567 , 89 101112 1314.,15, 16 )sobre el mundo SIEM y OSSIM, en esta ocasión vamos a hablar de una de esas normas relacionadas con la seguridad, y que sospecho que no todo el mundo es conocedor de ella.



PCI DDS: Payment Card Industry Data Security Standard. Norma en castellano.

A resumidas cuentas se trata de una norma internacional para aplicar a TODOS los agentes que intervienen en transacciones comerciales via internet mediante tarjetas de crédito/débito. Resalto TODOS ya que existe la falsa sensación entre la comunidad de que esta norma solo es aplicable si almacenas datos bancarios de clientes (e-commerce) y si usas la típica pasarela de pago de tu banco (tpv virtual) estás exento de aplicarla.

Nada mas lejos de la realidad. Lo que si es cierto es que existen varias niveles o modalidades a aplicar según la categoría de uso en la que te encuentres: no son las mismas medidas de seguridad a aplicar las que debe cumplir un banco, que una tienda online de barrio, pero en ambos casos existe normativa. Algo parecido a los niveles de seguridad de la española LOPD ( Ley Orgánica de protección de datos).

El objetivo de este artículo no es destripar la norma, sino darle un enfoque práctico.

Suelo leer varios blogs de seguridad "organizativa" o "none-tech" que dedican sendos posts a la "seguridad". Suelo ser de los que piensa que un buen responsable de seguridad o CISO debe tener tanto el aspecto técnico como el aspecto organizativo. No deberías ser consultor en seguridad si no sabes lanzar un NMAP, al igual que no deberías ser un CISO si no conces la legislación y normas que nos rodean. Prefiero el segundo caso dado mi pasión por la tecnología.



Tengo que decir sobre esta norma y su respectiva certificación algo que suelo decir para el resto de certificaciones, ya sean tipo ISO o tipo producto ( MCSE, VMWARE, CISCO, etc). Tener la certificación PCI-DDS no te proporciona seguridad, pero tener seguridad si que te proporciona poder optar a la certificación. Quiero decir con esto que lo importante no es la certificación en si, sino el trabajo que subyace para obtenerla. Si el trabajo ha sido pagar a una consultora, osea nulo, no tiene ningún sentido, mas el puro tramite de cumplir unas exigencias de cara a clientes/proveedores.



Entonces por qué habla de esta norma, cuando lo que realmente importa es la seguridad subyacente? Sencillo. Vamos a comentar los 12 aspectos principales que ocupan la PCI -DSS.( via wikipedia)
  • Desarrollar y Mantener una Red Segura
    • Requisito 1: Instalar y mantener una configuración de cortafuegos para proteger los datos de los propietarios de tarjetas.
    • Requisito 2: No usar contraseñas del sistema y otros parámetros de seguridad predeterminados provistos por los proveedores.
  • Proteger los Datos de los propietarios de tarjetas.
    • Requisito 3: Proteger los datos almacenados de los propietarios de tarjetas.
    • Requisito 4: Cifrar los datos de los propietarios de tarjetas e información confidencial transmitida a través de redes públicas abiertas.
  • Mantener un Programa de Gestión de Vulnerabilidades
    • Requisito 5: Usar y actualizar regularmente un software antivirus.
    • Requisito 6: Desarrollar y mantener sistemas y aplicaciones seguras.
  • Implementar Medidas sólidas de control de acceso
    • Requisito 7: Restringir el acceso a los datos tomando como base la necesidad del funcionario de conocer la información.
    • Requisito 8: Asignar una identificación única a cada persona que tenga acceso a un computador.
    • Requisito 9: Restringir el acceso físico a los datos de los propietarios de tarjetas.
  • Monitorizar y probar regularmente las redes
    • Requisito 10: Rastrear y monitorizar todo el acceso a los recursos de la red y datos de los propietarios de tarjetas.
    • Requisito 11: Probar regularmente los sistemas y procesos de seguridad.
  • Mantener una Política de Seguridad de la Información
    • Requisito 12: Mantener una política que contemple la seguridad de la información
Aunque suelen sonar a las típicas medidas de seguridad de la gente que "speak security" pero no las practican, nada mas lejos de la realidad te pregunto ¿ En tu organización, use tarjetas de crédito o no, implementa TODAS estas medidas?.

Este informe de Forbes con las 6 causas de fallo en las implementaciones de PCI te puede servir de ayuda para aclarar los conceptos mentales que empiezas a barajar :-)

Puede ser una buena ayuda para el departamento IT estas norma para impulsar la compra de material o servicios relacionados con la seguridad. Que tu jefe no piense que quieres un firewall para jugar o para llevarte una comisión.

Bueno, después de esta mini introducción vamos a ver que relación guarda con OSSIM.

La consola SIEM de OSSIM nos permite realizar varias de las acciones requeridas en la norma PCI DDS pero de momento, solo en versión 2.0. La actual norma versiona 3.0. Sospecho que la versión de pago AlienVault USM si adapta los requisitos a la norma 3.



También podríamos validar ciertos aspectos de la ISO 27001 pero le tengo manía. Por varias razones, pero principalmente por dos: por cobrar por descargar la norma y por la cantidad de empresas que venden seguridad cuando venden papeles.

Principalmente OSSIM lo que hace es comprobar el manejo de cada una de las áreas en base a los eventos que tiene. Por ejemplo, si tiene eventos de nuevo host descubierto porque tenemos Nagios activado y buscando cada cierto tiempo, entiende que cumplimos esa norma.
En el caso de que nos aparezca un campo sin comprobar, podemos vincularle un evento concreto para que sepa que cumplimos con esa parte de la norma gracias a esos eventos que añadimos.

Recuerda que esto es una guia orientativa del estado de tu cumplimiento PCI DDS, no es una herramienta completa que te "regale" la norma. Lo que si es cierto es que contamos con alugnos Reports preconfigurados válidos para apoyar la norma.



Podemos aglutinar las 12 grandes normas PCI en 6 respecto a OSSIM:


  • Gestión de activos. Mediante las opciones de ASSETS e INVENTORY de OSSIM podemos descubrir, identificar y monitorizar nuestros activos, algo básico en todo esto. Debemos saber que tenemos que asegurar, pero de manera dinámica, no basta con un inventario "estático" de hace un año, sin actualizar.
  • Análisis de vulnerabilidades. Mediante la integración de Openvas en OSSIM podemos programar auditorias de vulnarabilidades tal y como indica la norma. Hago ENFASIS en que no es lo mismo un Vuln Scan. que un Pen Test que luego me critcaís por ahí xD. Lo vimos aquí y aquí.
  • Detección de amenazas. Mediante el uso de sistemas HIDS/IDS y la monitorización de ficheros podemos realizar este punto perfectamente con OSSIM, como hemos visto en los artículos de Snort y OSSEC File Integrity.
  • Monitorización. La base de OSSIM es la monitorización de logs, mediante plugins OSSIM o mediante OSSEC. PCI DDS tmbien hace hincapié en la monitorización de servicios/aplicaciones y flujo de red.
  • Inteligencia. El motor de inteligencia OSSIM proporciona correlación de eventos de distintas fuentes para proporcionar algo más que visionado de logs, inteligencia. El típico ejemplo: si detectas intentos de login a un servidor SSH ( log ssh) y se produce una ejecución de comandos elevada desde la misma ip ( log kernel) y se abre un puerto ( log de servicios ) vistos en conjunto es una alarma, visto por separado son simples logs de actividad.
  • Revisión. La consola de OSSIM nos permite revisar todos los puntos anteriores e implementar medidas para la solución.
No todo es oro lo que reduce, y debemos ser conocedores de la norma en profundidad para poder realizar o aprovechar sus beneficios.

Un ejemplo claro de la norma: 

10.7 Conserve el historial de pistas de auditorías durante, al menos, un año,con un mínimo de disponibilidad para análisis de tres meses (por ejemplo, en línea, archivados o recuperables para la realización de copias de seguridad).






La versión gratuita de AlienVault, OSSIM solo permite guardar XXX registros, por lo que debemos jugar con una estrategia de consolidación de logs mediante el reenvio de información hacia un syslog pasivo. En otro post os explicaré como podéis realizarlo mediante Tablas Sql y mediante ejecución de scripts.

Un informe cualquiera de fugas de información, como pueda ser este de Verizon indica que:

  1. 79% de las víctimas fue por razones oportunistas. Esto quiere decir que no es lo mismo hacer un google hack y buscar servidores "facilones" que buscar la manera de entrar en un sistema concreto. Esta parte tiene mucho de concienciación.
  2. 96% de los ataques no fueron de alto valor técnico. Es decir, buscar una sql inyection en un portal para sacar la información no tiene mucho componente técnico, por lo que lo puede llevar a cabo mucha más gente. Ese 4% es el que preocupa :-).
  3. 94% de los datos provenía de servidores, y no de malas prácticas por parte de usuarios ( client side).
  4. 85% de los incidentes fueron detectados pasadas semanas, es decir, cuando el daño ya está hecho y tenemos menos medidas para mitigarlo.
  5. 92% de los incidentes fue descubierto por terceras partes, es decir cuando aparecen en un foro, en un defacement o un servicio de monitorización externo. Este punto hace evidente la necesidad de saber el estado de tus sistemas, y no confiar en el appliance de 1000$ o 10000$ sino en una estrategia global que contemple todos los vectores de ataque.
  6. 97% de los incidentes podrían ser evitados con medidas sencillas. Tirón de orejas para el CISO !!!
  7. 96% de las víctimas de incidentes NO tenían una política real de cumplimiento PCI. Insisto en el comienzo, tenerla no garantiza nada, pero este dato es muy revelador.
Espero que os hayan gustado estas reflexiones sobre PCI y alguno de los detalles comentados en OSSIM. Gracias por leerme !!!

Quieres ver un video?


Aprendiendo seguridad

$
0
0
Amigos de Inseguros. Con la llegada de septiembre se acerca la época en la qué muchos jóvenes, o no tanto, deciden sus planes de estudio para el año interesandose por la seguridad.


En muchos blogs del sector podemos leer artículos muy interesantes sobre caminos para llegar a ser un profesional de la seguridad, vistos desde varias perspectivas.

Como es costumbre en Inseguros, voy a intentar dar unos consejos y mi visión personal de como debería ser un camino sólido en este mundillo.

El primer punto va a ser decir que los compañeros de profesión, por supuesto yo, estamos aún en ese camino de la formación. Todos estamos obligados a estar constantemente estudiando, practicando, aprendiendo, investigando, arreglando, rompiendo y nunca hay fin. No puedes ser futbolista teórico sin jugar partidos, hay que sudar la camiseta !!! Animo !!!.

¿Redes o programación?.¿Pentester o analista de malware? Las dos !! Puedes decantarte por cualquiera de estos dos aspectos base para profundizar sobre un área un poco más concreta. Si te gusta el mundo del Malware sin duda conocer los fundamentos de programación, ensamblador, C, Java... será necesario para poder llegar a ser un profesional. Si te interesa la seguridad desde el punto de vista ofensivo, conocer TCP/IP a fondo es el "idioma" necesario para poder realizar esas intrusiones que tanto deseas...No obstante, ambos conocimientos son necesarios en términos generales para poder evolucionar en la materia.
Por ejemplo, puedes estar haciendo un análisis de un binario infeccioso, y que necesites destripar el comportamiento de red que realice el "bicho", teniendo que conocer el área de redes algo más que en superficie. Si estás realizando una auditoria y necesitas compilar un exploit, modificar un elemento web o realizar un pequeño script en tu consola, necesitas programar.

Otra de las facetas que más me interesa de la seguridad, desde mi punto de vista de sysadmin es la "defensa". Conocer los sistemas defensivos en todas sus capas lo considero un requisito para comprender la "Security". Creo que blogs como este, como 1gbdeinformacion, HighSec, hacking ético, son un punto de partida interesante para los administradores de sistemas que leen a Chema Alonso o a Flu Project, Security By Default, etc y que les encanta la seguridad, pero quizás necesiten alguna guia más para conocer productos, tecnologías, primeros pasos y demás. No todos podemos investigar 0 days, crear herramientas, dar ponencias, etc, pero si que todos deberíamos tener un buen firewall, un ids, una buena política etc.


Formación reglada. He realizado varios cursos de preparación , cursos a distancia, certificaciones y tengo que decir que aunque me parecen interesantes para "demostrar" unos conocimientos, realmente no se aprende mucho mas que si te entrenas por tu cuenta. Hay gente que necesita tener un horario de clase, un material didactico concreto, un profesor... para animarse o centrarse. Perfecto. Yo personalmente suelo cambiar esa dedicación que si tengo, por el ahorro de dinero que supone. The money is the money...
Si te gustan las siglas, pues todo el mundo habla de CISSP, CISM, CISA y similares. En todas te piden contar con una experiencia profesional demostrable...Si quieres iniciarte o aprender no son el camino.
OCSP o CEH si son certificaciones MUY prácticas que se basan en una pequeña teória, y la prueba de concepto asociada, pero requieren de una preparación previa de al menos uno o dos años.

Parece que hoy solo pongo impedimentos :-). Quieres aprender seguridad, vamos a ello.


Lo primero que debes hacer es aprender a preguntar. Imaginas a un ladrón llamandote por teléfono para preguntarte tu pin? Entonces "ponte el gorro de hacker" y piensa como eso, como un hacker. Si cuelgo una referencia de un libro porque me gusta, no me digas que no parece el link de descarga. Si quieres ser "pirata" al menos debes saber buscarte un pdf con google...

Ahora es el turno de preparar tu laboratorio. Configura tu sistema de virtualización favorito para el sistema operativo que uses, sea el que sea !!! La gente que dice que Windows no sirve para el hacking no se mira a sus manos, son ellos los que no saben !!!

Realiza las prácticas o laboratorios que lleguen a tus manos. Puede qué muchos no los vea útiles, pero si estás aprendiendo, todo vale. Quizás hagas una práctica de hacking web que has leido en un blog y no te interese esa vertiente. HAZLA. Lo mismo solo aprendes el paso 56 y el resto es "chino", pero ya has aprendido algo. Con el tiempo y la práctica, pequeños pasos de laboratorios anteriores serán el éxito de futuros laboratorios. Se trata de eso, de adquirir el ritmo, la tendencia, el conocimiento de como funcionan mas o menos las cosas.
Si encuentras alguna área interesante profundiza sobre esa materia. Haz tus propias pruebas, variaciones en los laboratorios. No te quedes con todo lo que lees, cuestionalo todo.

La seguridad no es hacking, y muchas ves el hacking no tiene nada que ver con técnicas de seguridad, por lo que no te centres en el hacking, en la parte "guay" de poner tu cara en una web. Preocúpate por saber como funciona realmente esa web.

Te imaginas el acceso a una consola Windows Powershell por un exploit público, y no saber manejarte en el entorno?

Espero que os hayan gustado estas reflexiones. Gracias por leerme.


DDOS como actuar ante un SYN FLOOD en un servidor Linux con Iptables.

$
0
0
Voy a comentaros algunas ideas para ayudaros en el caso de estar sufriendo un ataque de denegación de servicio sin estar preparados para ello !! xD

Lo primero que debe ocurrir es darnos cuenta de que estamos sufriendo un ataque de denegación de servicio. Hay varios niveles en los que podemos detectarlo, pero suponemos que tienes un servidor web y deja de funcionar, no puedes acceder por ssh o va muy lento. Digamos que detectas un deterioro en la red.

Lo primero que debemos hacer es detectar el tipo de ataque que estamos sufriendo. Hay muchos tipos de ataques DDOS. Podemos sufrir una denegación de servicio a un servidor DNS por UDP y los famosos ataques de amplificación, podemos sufrir un SYN FLOOD, etc.

Podemos acceder a nuestro server y tirar un simple netstat -n |more para ver las conexiones en nuestro sistema. No es muy elegante, pero estamos hablando de que tienes un problema, y no tienes una solución !!!.

tcp        0      0 ****ip destino****              190.229.110.15:63027        SYN_RECV
tcp        0      0 ****ip destino****              186.56.20.157:28904         SYN_RECV
tcp        0      0 ****ip destino****              190.229.110.15:61311        SYN_RECV
tcp        0      0 ****ip destino****              190.229.110.15:61516        SYN_RECV
tcp        0      0 ****ip destino****              190.224.191.188:4192        SYN_RECV
tcp        0      0 ****ip destino****              190.229.110.15:61147        SYN_RECV
tcp        0      0 ****ip destino****              190.224.191.188:3231        SYN_RECV
tcp        0      0 ****ip destino****              117.41.182.188:56738        SYN_RECV
tcp        0      0 ****ip destino****              81.39.49.188:53471          SYN_RECV
tcp        0      0 ****ip destino****              190.224.191.188:3153        SYN_RECV
tcp        0      0 ****ip destino****              189.128.237.238:49746       SYN_RECV
tcp        0      0 ****ip destino****              190.229.110.15:62547        SYN_RECV
tcp        0      0 ****ip destino****              190.229.110.15:62271        SYN_RECV
tcp        0      0 ****ip destino****              109.185.116.199:58821       SYN_RECV
tcp        0      0 ****ip destino****              190.224.191.188:2888        SYN_RECV
tcp        0      0 ****ip destino****              190.16.76.182:64740         SYN_RECV
tcp        0      0 ****ip destino****              190.16.76.182:64006         SYN_RECV
tcp        0      0 ****ip destino****              190.16.76.182:63225         SYN_RECV
tcp        0      0 ****ip destino****              190.229.110.15:62272        SYN_RECV
tcp        0      0 ****ip destino****              190.16.76.182:65325         SYN_RECV

Al parecer estamos sufriendo un SYN FLOOD, por el número tan alto de conexiones SYN recibidas.

Podemos contar el número de conexiones por ip de esta manera:

netstat -anp |grep 'SYN_RECV' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

En el caso de sufrir otro tipo de ataque puedes cambiar SYN_RECV por TIME_WAIT o cualquier otro estado que detectes numeroso.
Con la salida del comando podemos ver que ip´s son las que más conexiones están haciendo de ese tipo.

Podemos tomar alguna ip y geolocalizarla con alguna página que ofrezca este servicio, como pueda ser esta.

De esta manera, con unas cuantas ip podemos saber el origen principal del ataque de denegación de servicio.

Ahora es el turno de banear en Iptables el pais entero :-).

Este script baneará las ip´s clasificadas por país de http://www.ipdeny.com/ipblocks/ data/countries
Realiza el mismo proceso varias veces, editando el script antes de ejecutarlo, y añadiendo las siglas de los países que detectas están produciendo el ataque.

Si quieres tenerlo preparado puedes descargar el script, hacerlo ejecutable (chmod +X nombre.fichero).
 
Con estas medidas no puedo garantizar que pares el ataque, pero si consigues fitrar el tráfico hacia tu servidor, descartando el tráfico de países que no te van a comprar nada ( o visitar tu web), conseguirás mitigarlo en gran medida. Salvo si tu comercio está orientado hacia China, Rusia, etc xD.

Existen varias medidas que podemos implementar para proteger nuestros servidores de ataques DDOS, pero creo que eso será motivo de otro post mas profundo.

Espero que os sirva este BOTON DEL PANICO y que nunca tengáis que usarlo.

Gracias por leerme.



Mis RSS, libros, recursos, post al respecto sobre el Aprendizaje de seguridad y sistemas.

$
0
0
En Inseguros he hablado muchas veces de mi punto de vista sobre la seguridad y sobre su aprendizaje.

Los post que más visitan tienen en este blog, quitando las de mi mama, suelen ser los relacionados con esto, con el aprendizaje.


Con el propósito de llegar a las 10 visitas al día en Inseguros, os voy a dejar una recopilación de algunos recursos propios y algunos post que hablo sobre la iniciación a la seguridad y los sistemas.

Espero que os gusten.

Te animas a publicar tus favoritos?

Recopilatorio de pentesting castellano. En este recopilatorio se clasifican una serie de artículos sobre seguridad en castellanos. Algunos artículos son mios, y los mejores y la mayoria son de la comunidad de habla hispana. Están todos ordenados por varias fases, desde la recopilación de información hasta el informe final.

Recopilatorio de libros. En este artículo os presento la portada de los últimos libros que caen en mis manos, o que me quiero comprar, que considero atractivos para el área de seguridad, virtualización y sistemas. Podrás encontrar los últimos libros de las versiones actuales. Solo la portada, el título. Si quieres piratear piratea, no obstante, si quieres ser "juacker" y no sabes bajar un libro...
Esta iniciativa sale por mi parte por el cabreo que me produce leer un libro de hacking y que me hablen de Windows Xp, abusos en protocolo Finger, y demás piezas de museo.

Mis RSS. En este Pastebin he pegado mi fichero OPML con mis RSS favoritos en el área de la seguridad. Puedes bajarlo a un fichero e importarlo en tu gestor de noticias. Si quieres recorrerlo "a mano" buscan las líneas http, pues tu mismo.

Consejos y reflexiones sobre el aprendizaje en seguridad.

A estudiar !!!!



Si odias Linux Úsalo !!! Mis comandos para novatos.

$
0
0
Odio Linux !! No me gusta, a veces no llego a comprender muchas cosas.
Odio Windows !! A veces no llego a comprender muchas cosas.
Odio Vmware !!! A veces comprendo cosas.

Así podría seguir hasta el infinito. Tampoco me gusta trabajar después de comer.

A lo largo de mi vida he tenido varias épocas en las que he querido "acercarme" al mundo del hacking y la seguridad. Soy un apasionado de la informática, de la administración de los sistemas, y de paso la seguridad, pero muy de paso.

Mi primer experiencia con la seguridad sería por el 1996 o así. Era la época de Arrakis, Jetcv e
infovia. No recuerdo muchas más.
Empecé a leer los e-zines del momento, a moverme por los distintos canales de irc, hasta que me echaban xD. Con unos módulos para Mirc podías hackear al vecino (en los canales de IRC de "España" había 50 personas).


Tengo una anécdota curiosa sobre esta época. Tenía 15 años. Internet no era como ahora, se cortaba xD. El concepto de nube no estaba extendido. Esto para mi significaba una cosa, DESCARGAR todo el material que podía, por si "se rompía Internet", por si tiraban la web o cualquier cosa esperada de algo que no puedes tocar, ni oler y apenas comprender xD.
Pasé un mes recopilando información de hacking de todos los recursos que me llegaban. Se me ocurrió crearme un fichero de texto de unas 1.000 páginas para que mi señor padre lo imprimiera en su empresa, y así poder leer y estudiar en detalle desde los RFC más populares hasta la creación de virus, pasando por las famosas Blue Box para llamar gratís y poder conectarte a la red. Recuerdo que en aquella época el movimiento reivindicativo en la red era la tarifa plana. Timofónica sonaba en todo el ciberespacio español y los recursos sobre su manipulación y hacking proliferaban.

Llego un día y le di a mi padre el fichero para hacer un uso desonesto de los recursos de impresión de su empresa, y al hombre le dio por ver un poco de que se trataba. Llego a casa y no me trajo el libro, me dio una yema ( no de huevo) y me dijo : Tu estás loco !!.


Mi padre trabajaba en Telefónica :-)

Aparte de la anécdota que me ha parecido curiosa comentar, sigo con el principio.

Aparte de la denegación de servicio que hizo mi padre, en muchas ocasiones el no conocer Linux ha sido para mi una barrera en el área de la seguridad. Si eres como yo, que te gusta Windows y no controlas mucho Linux, seguro que habrás caido muchas veces en la frustración de querer seguir algún manual o proceso, y a ver tenido que dejarlo por no conseguir "instalar un paquete" o cualquier problema relacionado con la tecnología linux subyacente, y no con el propósito del manual.

Es inevitable tener que conocer un poco el ecosistema de nuestras redes, aunque sea para una administración puntual, o para tener mas referencia de precios, maneras de trabajar, rendimientos etc.

Y dicho esto, os voy a comentar algunos comandos linux BASICOS que seguro te ayudan si eres un administrador Windows que tiene que trabajar con pequeños sistemas Linux.

Espero que os gusten.
  • Uptime. El comando básico para saber el tiempo que el equipo lleva encendido, y la carga media de la CPU en intervalos de 1, 3, y 15 minutos. Mas información aquí.
  • Top . Podríamos decir que es el "administrador de tareas" de Windows. En la salida del comando podemos ver la carga de cpu y ram de los procesos ejecutados, así como su PID. Mas info aquí.
  • IOStat. Un breve resumen de las estadísticas de input/output de disco. Mas información aquí.
  • SYSSTAT. Es un conjunto de script orientados a la monitorización. Se instala sencillamente en la mayoría de distro. bien sea con apt-get, yum o similares. Suele estar en los repos. oficiales.
    • Comando SAR. Estadística un poco avanzada sobre CPU.
    • Comando SAR -r. Estadística para memoria.
    • Comando SAR -b. Estadística para el trabajo de disco.
  • Initctl -list. Comando para listar los comando ejecutados como script´s en el inicio del sistema.
  • Fdisk -l. Comando para los parámetros básicos de los discos físicos.
  • DF -h. Comando para ver el estado de las particiones y puntos de montaje.
  • Watch -n segundos "comando". Si quieres ejecutar un comando cada cierto tiempo y ver su salida. Por ejemplo. watch -n 5 "netstat -n".
  • Netstat. Misma herramienta que en Windows.
    • Puertos a la escucha: netstat -lnp.
    • Cuenta el número de conexiones de ip del tipo indicado. netstat -anp | grep 'TIME_WAIT' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
    • Cuenta el número de conexiones según el estado. netstat -an | awk '/tcp/ {print $6}' | sort | uniq -c
  • Ethtool "nic". Las propiedades básicas de un adaptador de red concreto. La última línea te indica si el cable está conectado :-) .
  • Ifconfig. Propiedades TCP de los adaptadores. 
  • Route -n. Lista de rutas estáticas.
  • Nslookup dirección. Funciona el DNS?
  • Iptables -L -n. Lista las reglas en iptables sin resolver ip-nombre. Más rápido.
  • Nload. Script para monitorizar el ancho de banda en tiempo real y estaísticas. Requiere instalación previa. Suele estar en los repos. oficiales o compilando.
  • TCPDUMP -n. Comando para capturar paquetes. Puedes ejecutarlo para ip origen, destino, puertos y demás. Muy útil para comprobar comunicaciones. Mas info. aquí.
  • ps -e |grep "cadena a buscar". Buscar procesos en ejecución con el nombre "cadena".
  • grep cadena ruta. Buscar una cadena en un fichero sin necesidad de entrar. Útil para los logs.
  • tail -f ruta. Muestra en tiempo real un fichero de texto, casi siempre.
  • continuará...

OSSIM 18. Capturas de red.

$
0
0
En la entrada número 18 de la serie (1234567 , 89 101112 1314.,15, 16 ,17vamos a hablar de las funciones de captura de red de OSSIM.


Desde el blog me suelen hacer preguntas sobre los procesos que escribo en Inseguros, y siempre uso mi experiencia general en la informática, discriminando los errores básicos, hasta llegar a los de alto nivel. Si no haces ping al host no puedes escanearlo !!!.

Usar una tool en linea como tcpdump o gráfica como wireshark es tu decisión, pero debes estar familiarizado con los ficheros pcap de capturas y saber leer entre líneas lo que ocurre en tu red.

Una de las comodidades que nos ofrece OSSIM es poder capturar, visualizar o descargar capturas de red entre dispositivos. Muy útil para la parte de configuración de OSSIM, pero realmente útil a la hora de detectar un incidente de seguridad, mediante los eventos, y poder ampliar la información mediante la captura de datos y posterior análisis.

Desde la versión Free ( no el USM de Alient Vault) no he podido vincular la captura de red teniendo como desencadenante un evento. Solo he podido capturar manualmente, pero no está nada mal.

Las teclas del piano son tan sencillas como click, click, click.


Es muy cómodo poder filtrar la captura desde origen y destino.


Podemos descargar el fichero o visualizarlo in situ.


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



OSSIM 19. El poder de la correlación. ejemplo iptables denial of services

$
0
0
SERIE OSSIM. (1234567 , 89 101112 1314.,15, 16 ,17 18)
En el artículo de hoy vamos a trabajar con la correlación, el motor de inteligencia de OSSIM.

Hemos visto muchos usos de OSSIM relacionados con la seguridad, pero momento no deja de ser un Syslog centralizado, con una interface gráfica, y una serie de herramientas integradas en una distribución.

El mundo SIEM ( Gestión de eventos de la seguridad de la información) es toda una disciplina dentro de la seguridad, al igual que el pentesting, reversing, forensic etc. Esta es la opinión de la gente de Gartner sobre el software SIEM para 2014.


Cuando alguien se inicia en este mundo suele empezar con la instalación de una herramienta de logs centralizada en la que observar lo que pasa en su entorno. El principal reto es discriminar los logs de información, identificando cuales son relativos a la seguridad, o la seguridad que yo necesito.

Vamos a poner un ejemplo gráfico.


Hay eventos de seguridad, hay logs, es gráfico, pero es un logs de 3 minutos, filtrado por las opciones que me deja el front-end (log-analyzer). Como encontrar un incidente de seguridad más o menos complejo, en un log de 300.000 líneas, para un solo día? Ahí es donde podemos usar el motor de inteligencia de OSSIM.

Vamos a trabajar con un supuesto de iptables.

Cuando ejecutamos una regla en iptables tenemos la opción de indicar que haga log, creamos dos líneas una para el drop y otra para el log, en orden inverso xD ( si primero bloqueas, no llega al log).

Yo tengo activado en OSSIM el PLUGIN que parsea los logs de iptables, que los "entiende", sin tener que hacer uno a medida con regular expressións.

Cada vez que iptables bloquea un paquete de una ip por la coincidencia de una regla, crea un log que visualizo en OSSIM.


Esto es mucha información, en unos segundos se nos va a llenar la lista de este evento. El ser humano tiene la capacidad de adaptación, por lo que el segundo día, no haces NADA con los logs, los borras, buscando el log mágico que te de toda la información a un click... Igual que con las alertas de Nagios mal configuradas, el servicio de correo al final es un simple "heart beat" del sistema, si llevas una tarde sin alertas de Nagios es que Nagios está roto, no que todo va bien :-).

En el tercer artículo la serie hablábamos de crear una política para incluir los eventos que no nos interesan, o que nos proporcionan poca información, para ocultarlos en el sistema.

Una de las opciones que indicamos fue la de no mostrar los eventos en el panel SIEM, pero usarlos en la correlación.


Podemos hacer esto con el evento de arriba de Iptables, que no lo muestre, pero lo use con la inteligencia.

Podría haber usado el típico ejemplo de la fuerza bruta: no muestres un login_failed, pero en tres intentos muestra un evento de fuerza bruta. Pero quizás este también os interese.

El propósito de mi correlación es detectar amenazas persistentes o ataques de denegación de servicios distribuidos.

Si tenemos unas reglas de iptables para cortar ataques, como sabemos que seguimos siendo atacados? Con este log de iptables. Recuerda que son ip´s que están baneadas y aún siguen intentando conectar.

Mi correlación va a ser simple, cuando encuentre 50 ocurrencias del log, muestra un evento que diga: Posible DDOS 50 intentos.

**
La idea completa es anidar esta correlación con otra correlación. Tener este evento, y que ocurra en más de 50 ip de origen, es un claro síntoma de un ataque DDOS. Para una ip o dos puede ser un bot tonto o un mal hacker. La idea es asociar una serie de medidas de contención automáticas contra un ataques DDOS.
**

Entramos en la sección de inteligencia y a continuación Directives.


Podemos ver las directivas que vienen con OSSIM, incluso clonarlas para editarlas a nuestro gusto.
Nosotros vamos a por todas y creamos una nueva.


Si leíste la teoría del artículo 10 sobre el cálculo del riesgo, esta parte es obvia.


Elegimos el Data Source del evento, en este caso indicamos que es un evento IPTABLES.
A continuación indicamos el evento que queremos que dispare nuestra correlación. Si no indicamos nada la correlación se iniciaría con cualquier evento de esa fuente.


Ahora podemos granular, afinar los orígenes y destinos del evento. Podemos trabajar como siempre en OSSIM con la información de Assets, o incluso con la variables Home_Net.



Podríamos indicar más opciones como tipo de puerto, usar los campos específicos del evento, usuario y contraseña si el evento manejase esta información, etc. Para esta regla no es necesario.

Ahora añadimos una acción, que será la ejecución de otra regla. En este caso, crearemos la misma regla que anteriormente, pero modificaremos el número de ocurrencias a 50.


Es importante indicar que la Reliability o la posibilidad de que este evento no sea un falso positivo, un valor que al ejecutar la regla del cálculo del riesgo de un valor por encima de 1, o no nos mostrará la información en el SIEM. Seguro que te has leído la teoría :-)

La directiva queda de la siguiente forma:



De esta manera, no tenemos los molestos logs por cada intento de conexión, pero cuando una ip intente 50 veces conectar, nos aparecerá el evento de posible DOS.


/etc/ossim/server/**********************# vim user.xml

<?xml version="1.0" encoding="UTF-8"?>

<directive id="500001" name="syn flood" priority="1">
   <rule type="detector" name="syn flood" from="!HOME_NET" to="HOME_NET" port_from="ANY" port_to="ANY" reliability="0" occurrence="1" plugin_id="1503" plugin_sid="6">
      <rules>
         <rule type="detector" name="SYN FLOOD 50" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" port_to="ANY" reliability="6" occurrence="20" plugin_id="1503" plugin_sid="6"/>
      </rules>
   </rule>
</directive>

En otra entrada realizaremos una directiva o correlación que anide otra correlación, y haremos alguna un poco más compleja usando diferentes data sources e incluso ntop.

**
por ejemplo podríamos crear una directiva que sea:
si encuentra más de un evento snort ( dos por ejemplo) y luego encuentra un login_ok desde la misma ip, alertar de un posible ataque fructuoso.

si encuentra un brute force y luego un login de ese mismo usuario, aunque sea de una ip origen distinta...
**

Espero que os guste, gracias por leerme.

Comienzan los premios bitacoras. GO GO GO !!!

$
0
0
El rubio y la rubia, el moreno y la morena, más de un calvo... comienza este año la carrera de popularidad de los premios Bitácoras 2014 !!!


Por si no lo sabias, Bitácoras RTVE convoca todos los años unos premios a la comunidad blogger en distintas modalidades, desde recetas de cocina, viajes, tecnología, arte, y desde unos años, y por suerte, Seguridad informática.

El proceso consiste en nominar hasta 5 blogs por categoría, previo login con Facebook o Twitter.

Durante todos los años de vida de Inseguros he aparecido en la lista, por lo que realmente sirvieron las clases a mi madre para que aprendiera a votar. Suelo andar en la posición 20-30, lo que indica que tengo mucho que aprender aún de la comunidad de bloggers-hackers de habla hispana.

Suele haber mas de uno "queme" con la famosa lista. Algunos blogs no son de seguridad, otros son de empresas, otros son demasiado buenos, otros son demasiado malos, pero me parece una iniciativa interesante. Al menos todos los años descubro blogs que no conocía y adquiero una nueva fuente de conocimiento. En la mayoría de los casos, coincido con los maestros que regentan esas bibliotecas online. Los cursos de formación son muy caros y muchos los imparten gratis !!!

El día que llegue al número uno, que pienso hacerlo, hablaré con Chuck Norris para que elimine cualquier rastro de actividad hackers, estáis advertidos.


Si te apetece votarme, y he puesto bien el botón, gracias !!!
  
Votar en los Premios Bitacoras.com

OSSIM 20. Wireless IDS Kismet y prueba de concepto de ataque.Parte 1.

$
0
0

En el capítulo de hoy de Inseguros sobre la serie OSSIM vamos a hablar de Kismet.
(1234567 , 89 101112 1314.,15, 16 ,17 18, 19)



Kismet es un sistema de detección de intrusos wireless. No me refiero a monitorizar la red wifi con snort, y detectar los ataques de la red cableada ( brute force, exploit,etc), sino detectar específicamente los ataques que se producen sobre la infraestructura wifi.


Para ponernos en situación, mejor leer el manual oficial de Kismet para saber que tipos de ataques detecta, lo que serían las "reglas" de snort/modsec/etc.




Alert name:       NETSTUMBLER
Alert type: Fingerprint
Alert on: Netstumbler probe requests
WVE: WVE-2005-0025
Alert name: DEAUTHFLOOD
Alert type: Trend
Alert on: Deauthenticate/Disassociate Flood
WVE: WVE-2005-0019
WVE-2005-0045
WVE-2005-0046
WVE-2005-0061
Alert name: LUCENTTEST
Alert type: Fingerprint
Alert on: Lucent link test
Alert name: WELLENREITER
Alert type: Fingerprint
Alert on: Wellenreiter SSID brute force attempt
WVE: WVE-2006-0058
Alert name: CHANCHANGE
Alert type: Trend
Alert on: Previously detected AP changing to a new channel
WVE: WVE-2005-0019
Alert name: BCASTDISCON
Alert type: Fingerprint
Alert on: Broadcast disconnect/deauthenticate
WVE: WVE-2005-0019
WVE-2005-0045
WVE-2005-0046
WVE-2005-0061
Alert name: AIRJACKSSID
Alert type: Fingerprint
Alert on: SSID of 'airjack'
WVE: WVE-2005-0018
Alert name: PROBENOJOIN
Alert type: Trend
Alert on: Clients probing for networks, being accepted by that
network, and continuing to probe for networks.
Alert name: DISASSOCTRAFFIC
Alert type: Trend
Alert on: Traffic from a source within 10 seconds of a
disassociation
WVE: WVE-2005-0019
WVE-2005-0045
WVE-2005-0046
WVE-2005-0061
Alert name: NOPROBERESP
Alert type: Fingerprint
Alert on: Probe response packet with 0-length SSID tagged
parameter
WVE: WVE-2006-0064
Alert name: BSSTIMESTAMP
Alert type: Trend
Alert on: Invalid BSS timestamps indicative of an access point
being spoofed.
WVE: WVE-2005-0019
Alert name: MSFBCOMSSID
Alert type: Signature
Alert on: MAC src address used as CPU instructions by MSF when
exploiting the Broadcom SSID overflow
WVE: WVE-2006-0071
Alert name: LONGSSID
Alert type: Signature
Alert on: SSID advertised as greater than IEEE spec of 32 bytes
Alert name: MSFDLINKRATE
Alert type: Signature
Alert on: Beacon frame with over-long 802.11 rates tag containing
exploit opcodes
WVE: WVE-2006-0072
Alert name: MSFNETGEARBEACON
Alert type: Signature
Alert on: Large beacon frame containing exploit opcodes
Alert name: DISCONCODEINVALID | DEAUTHCODEINVALID
Alert type: Signature
Alert on: Unknown / reserved / invalid reason codes in deauth and
disassoc packets

Como puedes observar, son los clásicos ataques Wifi.

Para realizar este despliegue he optado por instalar el sniffer wifi, Kismet, en una máquina independiente. El motivo es que OSSIM está instalado sobre Vmware y como todos sabemos, Vmware no es buen amigo de los interfaces Wifi.


Es un Kali con una tarjeta de red wifi. La típica máquina P4 2,4ghz 512 Mb. Pero que funciona de lujo.


Lo que vamos a hacer es integrar dos "opciones" de Kismet con OSSIM. Una serán las alertas cuando se produzcan los ataques. Otra opción será documentar nuestra infraestructura Wifi obtenida con Kismet, para el inventario de áctivos. Un requisito de la famosa PCI- DSS es monitorizar la red wifi, algo que me parece perfecto.


Lo primero que hacemos en el servidor OSSIM es habilitar el tráfico de logs desde el sensor e indicarle la ubicación de los mismos en local:


if $fromhost == 'ip_wids' then /var/log/kismet.log
&~

Ahora habilitamos el envio desde el WIDS hacia Ossim:

echo "*.* @ip_ossim > /etc/rsyslog.d/wids_alienvault.conf
Service rsyslog restart en ambos extremos.

Con esto ya podemos ver los logs del sistema WIDS en ossim mediante un tail a la ruta indicada.

El siguiente paso es ejecutar Kismet en el Wids y comprobar que tenemos actividad.

/usr/bin/kismet_server -t kismet -f /etc/kismet/kismet.conf 2>&1 | logger -t kismet -p local7.1

Si nos devuelve a bash, no ha funcionado. 
Vamos a configurar alguna cosa más en el kismet.conf, como:

Descomentamos ncsource=wlan0 o cualquiera que sea el nombre de tu adaptador wifi.
gps=false.
Cambiamos el prefíjo de los logs:
logtemplate=/var/log/kismet/%n_%D-%i.%l

Aprovechamos este momento para editar la regla apspoof=Foo... en donde cambiamos el nombre y cambiamos el ssid "Foobar" por el nombre de un ap que esté en nuestro alcance. De esta manera vamos a comprobar que como no hemos cambiado la mac que aparece, al detectar el AP y no coincidir con la mac proporcionada, nos generará una alarma.
En el proceso normal de uso debemos añadir una regla por cada AP que tenga un nombre SSID distinto. Si es el mismo, basta con añadir mas direcciones mac mediante una coma.

La alerta generada sería así:

Oct  1 08:34:06 localhost kismet: ALERT: APSPOOF Unauthorized device (C8:D7:19:FB:67:01) advertising for SSID 'MySSID', matching APSPOOF rule Foo2 with SSID which may indicate spoofing or impersonation.

Lanzamos un ataque DOS Deauth. Comprobamos que Kismet detecta el ataque.

airodump-ng wlan0 -> anotamos un bssid y su channel.
iwconfig wlan0 channel x > ponemos nuestra tarjeta en el mismo canal.
aireplay-ng --deauth 0 -a bssid wlan0




Espero que os guste el artículo. En el siguiente episodio terminaremos con la 
integración en OSSIM. Gracias por leerme.

Seguridad "Management" o seguridad "Tech".

$
0
0
El propósito del blog Inseguros, entre otros, es el de acerca el mundo de la seguridad a los profesionales de la administración de sistemas, técnicos e incluso principiantes en el hacking ético.

En el mundo de la seguridad informática existe una distinción entre los perfiles de los participantes que me gustaría comentar.

El hacking ético es una área puramente técnica, en la que la persona suele poseer grandes conocimientos en redes, protocolos, seguridad web, móviles, reversing, análisis de tráfico, etc, pero suelen tener poco conocimiento de la gestión de la seguridad.


La seguridad defensiva suele ser un perfil en el que el participante cuenta con un conocimiento mas o menos general de la parte de hacking ético, pero sobre todo conocen las medidas defensivas a implementar para conseguir solucionar o mitigar los incidentes de seguridad.

Existe un perfil de analista de malware/cibercrime el cual es altamente técnico, y suele coincidir con una gran base de conocimiento respecto al hacking ético y la seguridad defensiva.

Aunque existen mas perfiles, creo que con estos ejemplos ilustro la vertiente tecnológica de estas ramas.


Bajo otra rama podríamos llamar a los participantes como "security management".
Suele ser un perfil de gestión. Conocen la teoría de los riesgos, en el mejor de los casos, conocen las medidas teóricas para su defensa, pero no tienen por qué conocer la parte técnica.

En la comunidad hacker este perfil es el más despreciado, ya que consideramos que es muy fácil hablar de gestión de incidentes, pero es difícil implementar una solución técnica que realmente me aporte seguridad, no solo control.


Yo pienso que los extremos son malos, y tanto un perfil muy técnico, como un perfil muy de gestión adolecen de debilidades.

Voy a poner algunos ejemplos. Como técnicos podemos implementar una solución UTM Vpn Ipsec http ssl rsa 2048 con 2af. Muy bien, una buena ristra de siglas y tecnologías. Bien. Perfecto, eres un freak tecnológico, un gurú de la seguridad !!! Y si la semana que aparece HeartBleed, o mejor dicho, ese mes, estabas de vacaciones y no parcheastes? Estabas de luna de miel en Cancún sin posibilidad de conectarte. Has hecho bien tu trabajo? NO. Debería existir un plan de contingencia en el que se contemple un equipo de gestión de incidentes para estos casos. Puede que el equipo de gestión seas tu mismo, pero tiene que estar regulado que al ocurrir un incidente tan importante como este, exista la posibilidad de actuar, y no depender de un viaje, o que es fin de semana y tienes el móvil apagado.


Vamos a poner el caso contrario. Eres un gran gestor de la seguridad de la información. Implementas un SGSI en el que documentas todas tus medidas de seguridad, pero eres incapaz de montar un sistema de prevención (no detección) de intrusos. Puede que a nivel gestión identifiques con su Score la criticidad del incidente, pero lo importante es remediarlo.

El otro día fui a una entrevista de trabajo en mi ciudad. La empresa me llamó una mañana para asistir a la sede esa misma tarde. Con mi vena freak pensé en hacer un pequeño análisis de seguridad. Bueno, mas bien un análisis básico del "estado de la nación IT".
Comprobé el registrador del dominio, los registros DNS. Como muchas empresas, tenían la web en un proveedor de renombre, pero el registro MX apuntaba a una ip local, la típica de Ono-Telefónica...
Realice un fast port scan por la red TOR, no con el fin de encontrar nada, sino con el fin de detectar si implementaban medidas de seguridad.

Encontré una serie de servicios web. Un Apache en el puerto http/s suele estar medio protegido, pero un Apache en el puerto 100 me pareció curioso.

En efecto, era un Joomla sin actualizar, vulnerable. Una clave DEBIL. Era la típica web que hace el informático de turno para un cliente, un nuevo CMS o similar que está probando, pero que publica en Internet para enseñárselo a su jefe.


El caso es que a pesar de tener unos 5 appliances de seguridad, de Fortinet (Fortiweb, Fortimail, Forti Gay...) tenían un fallo de seguridad que me permitió "sentarme" en una de sus máquinas virtuales. Una vez dentro, aparte de acceder a todas las claves de conexión a BBDD averigüé su infraestructura interna. No quise seguir ya que no tenía autorización, y no me lo iban a pagar, pero podría haber petado TODA la empresa, y a algunos de sus clientes.

Aparte de la charla de que buscaban un informático puntero, comprometido, dedicado, innovador, entregado,etc por 15.000€/brutos estuvimos hablando de la seguridad. Es curioso porque SOLO con una auditoría de seguridad y pentesting ya hubiera "producido" casi el mismo dinero que me ofrecía por un año !!!

El sujeto, el gerente, un poco avergonzado se excusaba en que esa web era de pruebas, que era un portal oculto, que no tenía información de producción, etc.


Intentó hacerme sentir que no había hecho ningún trabajo de seguridad importante, y que cualquiera podría haberlo hecho. BIEN, pero entonces, asumes que por esa tonteria, podrías haber sufrido un ataque SERIO con bastante perdida de información ( los backups de contingencia estaban disponibles para borrarlos).

Que importa que el incidente se hubiera producido por un fallo TONTO de actualización, o de contraseña, o que hubiera sido un avanzado APT con 0 days y un procedimiento digno de una novela? Al final, sea cual sea la técnica, lo importante es el acceso.

Una solución muy sencilla, aparte de la formación al informático, hubiera sido programar una auditoría semanal, en la que se hubiera revelado el nuevo servicio en el puerto 100, y alguien debería haber preguntado eso que era, como estaba, si era seguro. Una medida NO TECNICA, porque en vez de una auditoría semanal, el informático podría haberlo comunicado verbalmente.

Si repasas las charlas de las conferencias en las que los "gurús" explican accesos o intrusiones practicadas en clientes, en la mayoría de los casos, se parte de un pc mal actualizado, un antivirus mal actualizado o inexistente, un fallo de ingeniería social (un click, un usb, una url)medidas "low tech" que por muchas medidas de seguridad técnicas que implementes, la gestión de las mismas es una pieza clave.

No se trata de hacerse un experto en ISO 27001/2, LOPD o similares, pero tampoco pensar que el mundo es mar de bits, en el que todo se controla con la tecnología, ya que la tecnología la manejamos humanos.

Si yo quiero juackear tu empresa, como robar un banco, no voy a entrar por tu firewall mas o menos bien configurado, al igual que en el banco no pretenderías robar por la puerta de la caja de seguridad. En un banco intentarías entrar por las rejillas de ventilación, o por un túnel. Con el hacking pasa lo mismo. Cualquier medida es buena, para conseguir tu objetivo.

Si anoto unos cuantos mails de tu empresa, de trabajadores en Linkedin. Y mando a varios empleados un mail diciendo: soy amigo de XXX, lo vi el otro día por XXX sitio y me ha dicho que te mande un currículum a ti. Gracias. Cuanta gente pincharía en el enlace?

Espero que este texto mal escrito te sirva de reflexión para analizar cual es tu "vertiente". Si eres Tech te sugiero que amplíes tus conocimientos con algún proceso formal o metodología que te ayude a gestionar tu seguridad. Si eres un manager, te sugiero que profundices en las medidas técnicas que emplean los cibercriminales y su parte defensiva.

No te fíes de los gurus de la técnica, ni de los gurus de la gestión, ya que vivimos en un mundo en el que nos toca lidiar con la fea y con la guapa, con los High-tech y con los script-kiddies. Con ataques de Rusia y con ataques de alguien de tu pueblo.

Espero que os guste el artículo, gracias por leerme.



Prevención de fugas de información en logs. Campo Passwords y Mod security

$
0
0
Cuando un atacante pretende comprometer un sistema, una de las ubicaciones que debe observar son los logs. Imaginaros el caso de un sistema comprometido, en el que el atacante accede a los logs del sistema, en el que se muestran en claro los usuarios y contraseñas de nuestros usuarios. Se lo pondríamos muy fácil.


En algún cliente me ha ocurrido la situación de  presentar una solución tipo Snort, Mod Security e incluso un simple Squid Proxy para proporcionar elementos de seguridad, y ser la propia gerencia la que descartaba este tipo de soluciones por la exposición de información sensible, y casi siempre personal, al departamento IT o el departamento que accede a los logs ( redundante, los informáticos lo vemos todo, desde el de micro-informática hasta el sysadmin-boss).

Con un proxy podemos ver los hábitos de navegación de nuestros director de ventas, que son muy decorosos...Con Snort podemos detectar aplicaciones prohibidas, como pueda ser el famoso BroadCast de Dropbox...

Para proporcionar un nivel de seguridad y confianza en la gestión de logs de Mod Security, vamos a crear una pequeña regla al respecto.

Lo que hacemos es crear una regla tan sencilla como la siguiente. Con ella simplemente lo que hacemos es que en fase 5,la parte de logging, sanitice !*"!^·*!^"*·! (limpie los caracteres de un campo con asteriscos).

SecRule &ARGS:password "@eq 1""phase:5,t:none,id:123458,nolog,pass,sanitiseArg:password"


Esta regla de por sí no generará alarma, simplemente que en nuestras reglas existentes, cuando detecte un campo password, "limpiará" el registro con ****.

Veamos un ejemplo. Lanzo un "ataque" ficticio sobre una aplicación, para que salte cualquiera de las alarmas que tenemos configuradas ( en este caso salta una alarma por hacer match de la palabra UNION).


Como puedes ver, aparece la contraseña en claro.
Sin embargo una vez activada nuestra nueva regla, podemos comprobar que el mismo ataque, genera la misma alerta, pero limpia el campo.


Como puedes ver, esta simple regla puede propiciar que gerencia vea con buenos ojos tu medida de seguridad, y no estés viendo todas las passwords de los clientes. Pobres ilusos xD pero bueno, creo que todo el mundo es consciente de que este tipo de información es manejada por el departamento IT.

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



Introduccion a Mod Security y reglas free Owasp.

$
0
0
Como alguna vez hemos hablado en este blog aquí y aquí, Mod security es el Web Application Firewall del mundo software libre más usado.

Mod Security funciona como módulo embebido de Apache o para cualquier web server como reverse proxy.



Las funciones que nos permite este WAF son las clásicas:
  • Monitorización en tiempo real de los accesos web. Podemos delimitar el acceso a nuestros recursos web no solo con htaccess, sino con reglas específicas.
  •  Virtual Patching. Este concepto me parece muy interesante, al igual que con Snort, tenemos la posibilidad de crear una regla que detecte un exploit concreto contra una vulnerabilidad concreta, y podemos parar la ejecución, aún contando con la vulnerabilidad sin parchear. Muy útil para sistemas heredados, integrados o con dificultad para actualizar.
  • Logging. Como herramienta de registros de la actividad http/s.
  • WEB Hardening. Podemos crear reglas para securizar nuestro webserver. Por ejemplo, podemos crear una regla que inspeccione el Body Response y detecte una fuga de información de una caída de Mysql, inyectando código en la respuesta o redirección a otro recurso, para evitar dan información al atacante. Hay muchas, algunas las iremos comentando en Inseguros.
  • ...
Como habéis podido leer, funciona como un ids tipo Snort/Suricata, en el que el motor mod security examina todo el tráfico en base a una reglas, y en el caso de que hagan "Match", que encuentre el patrón de la regla, podemos vincular una acción.


Es decir, aparte de la potencia de procesamiento de Mod Security, lo importante son las reglas.
Si te vas a animar en probar Mod Security sobre tus webserver, puedes hacerlo de una manera muy sencilla.
El proceso es bajar mod security, compilarlo (hay millones de tutoriales) habilitar el módulo en Apache. Bajar las reglas que más te gusten y trabajar.


No tengas miedo en montar Mod Security y pensar en que vas a parar tráfico legítimo, o que vas a cargar el web server. Mis pruebas dan que Mod Security carga el webserver en un 8%/10%. Las reglas las podemos evaluar antes de que corten, en modo DetectionOnly. Cuando hayamos "trasteado" con las reglas podemos pasar a la acción habilitando las acciones, pero podemos estar tranquilos en que mientras lo analizamos, no estaremos cortando tráfico legítimo.

El conjunto clásico de reglas que todo el mundo se baja de manera gratuita es Owasp Core Rule Set.
Vamos a ver una regla simple para que os hagáis una idea de su simpleza, o quizás de su complejidad xD.

SecRule REQUEST_HEADERS:User-Agent "@pmFromFile modsecurity_35_bad_robots.data" \
"chain,phase:2,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',t:none,block,msg:'Rogue web site crawler',id:'990012',tag:'OWASP_CRS/AUTOMATION/MALICIOUS',tag:'WASCTC/WASC-21',tag:'OWASP_TOP_10/A7',tag:'PCI/6.5.10',severity:'4',capture,logdata:'%{TX.0}'"

Esta regla se engloba en modsecurity_crs_35_bad_robots.conf
Lo que tenemos es un fichero .data que almacena los user_Agent maliciosos conocidos...(actualizar de vez en cuando) y si en el Request Headers detecta alguno en User-Agent hace un BLOCK, con un mensaje concreto en la alerta. Esto es lo más relevante de momento de esta regla. Ya entraremos en detalle con las reglas, simplemente quiero que veáis como se hacen, y que son "asequibles" de programar o interpretar.

Vamos a interpretar una alerta generada por esa regla de arriba.

--e2b5db05-A--
[16/Oct/2014:10:16:06 +0200] VD9@xrIhfmwAADLzPPYAAAAA ip origen 15866 ip destino 80
--e2b5db05-B--
GET /*************/?gclid=*************************** HTTP/1.1
Host: dominio atacado
User-Agent: NIKTO
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: ******************
Cookie: cookie_****=1; __utma=*******************                                                  971.72.39.utmgclid=CKCyoq3dsMECFSuWtAodRyMAxg|utmccn=(not%20set)|utmcmd=(not%20set); optimizelySegments=%7B%221               
Connection: keep-alive
Cache-Control: max-age=0

--e2b5db05-F--
HTTP/1.1 403 Forbidden
Last-Modified: Wed, 07 Aug 2013 10:59:35 GMT
ETag: "*************"
Accept-Ranges: bytes
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 546
Connection: close
Content-Type: text/html

--e2b5db05-H--
Message: Access denied with code 403 (phase 2). Matched phrase "nikto" at REQUEST_HEADERS:User-Agent. [file "/e                                                         tc/httpd/modsecurity.d/activated_rules/modsecurity_15_customrules.conf"] [line "16"] [id "990002"] [rev "2"] [msg "Request Indicates a Security Scanner Scanned the Site"] [data "nikto"] [severity "CRITICAL"] [ver "OWASP_CR S/2.2.6"] [maturity "9"] [accuracy "9"] [tag "OWASP_CRS/AUTOMATION/SECURITY_SCANNER"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"]
Action: Intercepted (phase 2)
Stopwatch: 1413447366270242 2499 (- - -)
Stopwatch2: 1413447366270242 2499; combined=530, p1=165, p2=356, p3=0, p4=0, p5=8, sr=63, sw=1, l=0, gc=0
Producer: ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/); OWASP_CRS/2.2.6.
Server: Apache
Engine-Mode: "ENABLED"

--e2b5db05-Z--

Para esta regla, he resaltado los campos más relevantes en negrita, que como puedes comprobar, coinciden con la regla comentada.

Tengo que decir que el conjunto de reglas Owasp para mi es como un "Pattern & design". Me explico. Imaginaros un ataque web concreto, con una url asi:  http://dominio/admin.php?user=hygugugu&cmd=cmd.exe.

Es una tontería pero sirve de ejemplo. Tenemos un ataque que mediante una url concreta de un fabricante, con un parámetro concreto de un usuario, nos permite ejecutar una consola de sistema. Mod Security no va a detectar el ataque concreto contra ese fabricante, sino que detecta un "ataque" porque según el conjunto de reglas Owasp, hacer una llamada a CMD.exe es de por si un ataque.


Esto tiene algo bueno y malo. Lo bueno es que detectará los ataques pasados, presentes y futuros que empleen CUALQUIER llamada por url a CMD.exe. Lo malo es si tu usas esta función?

Ese es el trabajo que debemos realizar una vez instalamos Mod Security y las reglas Owasp en modo DetectionOnly. Detectar que comportamientos legítimos de nuestras aplicaciones son detectadas como alertas, y tenemos que o modificar la aplicacion... xD  o hacer whitelist de esa regla para una ip, dominio, vhost o regla concreta.

Pongo otro ejemplo, si en tu aplicación web entras por dominio, pero existen enlaces hacia url por IP, OWASP rules detecta esto como un ataque...

Quería hablar de otro conjunto de reglas, pero me he animado a escribir esta pequeña guia para ver si os animáis a instalar vuestro mod security en cualquier máquina virtual ,en cualquier apache que tengas por ahí, y así poder seguir los artículos. Vamos !!!

Si tenéis alguna duda en la instalación inicial o en el setup, podéis contactar conmigo por correo en minick @ hotmail.com.

Gracias por leerme, espero que os guste !!!.

Reglas para Mod Security Free. Comodo y Atomic.

$
0
0
Como vimos en la pequeña introducción del anterior capítulo, cuando hablamos de Mod Security debemos hablar de un conjunto de reglas que sirvan de patrón al WAF para detectar intrusiones.

En esta entrada os voy a comentar simplemente un par de recursos disponibles, de manera gratuita, para nuestras implementaciones de Mod Security.


La primera es el conjunto de reglas del firewall Comodo para Mod Security.
Debes realizar el registro para descargar las reglas.

Si en tu fichero de configuración de Mod Security tienes algo como así:

<IfModule mod_security2.c>
    # ModSecurity Core Rules Set configuration
        Include modsecurity.d/*.conf
        Include modsecurity.d/activated_rules/*.conf

    # Default recommended configuration
    SecRuleEngine DetectionOnly

Pues simplemente copia los ficheros en esa ruta y realiza un service httpd reload (o similar) para que cargue las reglas.

Os recomiendo realizar esta gestión en un entorno de pre-producción o testing, para no cortar el tráfico legítimo.

Si simplemente estas jugando, puedes habilitar el DetectionOnly para revisar el comportamiento de Mod Security, sin cortar tráfico. repito, SIN CORTAR TRAFICO !!!.


El otro conjunto de reglas que vamos a incorporar es la versión de trial de 30 días de Atomic Corp.
Podemos registrarnos y descargar el conjunto de reglas. Podremos usarlas ilimitadamente, pero no podremos actualizarlas pasados los 30 días.

El link de descarga es este.

Algunas de las utilidades que empleo es apachectl configtest Cuando haces un restart del servicio Apache puedes ver los errores que pueden producir que no arranque Apache, como por ejemplo un problema con alguna de las reglas. Cuando realizas un reload, el comando no tira ninguna opción, por lo que si tienes algún problema debes usar apachectl configtest para delimitar el problema.

Por ejemplo, si cargas las reglas Atomic, una buena recomendación es hacerlo de fichero en fichero, para ir haciendo Reload y validando reglas. Si copias el fichero 10_asl_rules.conf, el de mas tamaño, tendrás un problema al hacer Reload.

service httpd reload
Reloading httpd: not reloading due to configuration syntax error
                                                           [FAILED]

Con el comando:

apachectl configtest
Syntax error on line 241 of /etc/httpd/modsecurity.d/activated_rules/10_asl_rules.conf:
Error creating rule: Could not open phrase file "/etc/httpd/modsecurity.d/activated_rules/sql.txt": No such file or directory

Vamos a hacerle caso y a copiar tambien el fichero en cuestión. Hacemos service httpd reload y bingo, recarga apache.

Ahora a mi me gusta hacer un tail  y revisar el log que tira, buscando las nuevas reglas.
tail -F /var/log/httpd/modsec_audit.log |grep -A8 -B17 10_asl_rules


Con la salida del grep A8 y b17 saco las lineas after y before de encontrar el nombre de la regla, para ver la IP, y el resto de reglas que han podido saltar. Lanzo un Nikto y veo que ocurre.

Como podéis apreciar, me saltan 3 reglas, las de Comodo, las de Atomic, y una regla custom que yo tenía creada "parecida". Ya que no vamos a actualizar las reglas Comodo/Atomic por su restricción "trial", podemos modificar directamente el fichero de reglas y comentar las que no nos interesen. Recuerda que cuantas menos reglas procese Apache, mas ligero correrá. Aparte, me hace difícil gestionar esa regla en mi consola OSSIM.

Mando el tail a un fichero, y lanzo Nikto, w3af, openvas, wpscan, joomscan, o cualquiera de las tools que quieras comprobar. Con esta gestión, podemos depurar las reglas para darles un poco mas de coherencia al uso de 3 motores de reglas.


El siguiente paso sería realizar varios circuitos funcionales, para detectar falsos positivos. Realizar una compra, escribir un post, subir una imagen, cualquier proceso que ocurre legítima en tu aplicación web.

Recuerda que como trabajamos en DetectionOnly no estaremos cortando tráfico legítimo.

Una de las inquietudes que se plantean con este sistema es en entornos de producción en los cuales se trabaja directamente con el entorno, sin pre-producción o testing, corremos el riesgo de modificar cualquier comportamiento en nuestra aplicación que haga que alguna regla haga MATCH, días después de haber validado la regla, por lo que se hace casi imprescindible tener con un entorno de validación, algo lógico pero no siempre puesto en práctica por la mayoría de PYMES.

Tanto si te toca defender tus aplicaciones, como si realizas labores de pentesting, recomiendo contar con un entorno de WAF para comprobar como se detectan los ataques que sufrimos/producimos.

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











Qué hace un CISO aparte de ver gatitos en Internet?

$
0
0
En la entrada de hoy voy a comentaros algunas de las labores que debería realizar un CISO (Chief Information Security Officer).

Tanto si eres uno de ellos, o quieres serlo, o simplemente eres un administrador de sistemas sin tantas siglas, seguro que alguno de los ámbitos te recuerda que hoy debes mirar los logs :-)


Seguramente los consultores de RRHH especializados en esta área deben conocer, con lo bien que hacen su trabajo, pero bueno, si alguno cree bien usarlo, que lo use, es gratis.


  • PREVENCION DE AMENAZAS.
    • Seguridad de aplicaciones.
    • Gestión de vulnerabilidades.

  • DETECCION DE AMENAZAS.
    • Gestión de LOGS, correlación, SIEM.
    • Gestión de ALERTAS, file integrity monitor, AV, WAF, IDS/IPS, etc.
    • Data Lost Prevention.

  • GESTION DE INCIDENTES.
    • Respuesta ante incidentes,
    • Relación con los medios.
    • Investigación forense.

  • GESTION DE LA IDENTIDAD.
    • Cuentas, usuarios, contraseñas, 2AF, roles,integración con RRHH. 

  • GESTION DEL RIESGO.
    • Seguridad física.
    • Pentesting.
    • Revisión de código.
    • Políticas y procedimientos.

  • ASPECTOS LEGALES.
  • AUDITORIA Y CUMPLIENTO DE ESTANDARES.
  • ARQUITECTURA DE SEGURIDAD.
    • Redes.
    • Aplicaciones.
    • Acceso remoto.
    • Tecnologías de cifrado.
    • Backup, recuperación, plan anti-desastres.

  • REQUISITOS DEL NEGOCIO.
    • Presupuestos.
    • SLA.
Espero que os sirva de ayuda, para ampliar más información en todas estas áreas de conocimiento o trabajo que todo buen CISO debe gestionar.

Gracias por leerme !!!

Hacker? Hacker Etico? Auditor? y qué mas os da el nombre?

$
0
0
Seguro que todos habéis leído la publicación por la RAE de la inclusión de varios términos, en concreto HACKER referenciado como pirata informático.

Me hace mucha gracia el revuelo que ha creado esto en la comunidad de seguridad informática y he decidido expresar aquí mi opinión al respecto.

Pregunta a cualquier persona ajena a este mundo, que significa la palabra HACKER. ¿Qué te va a responder? pirata informático. En la televisión, en el cine, en las entrevistas, en todos los medios ajenos al propio colectivo, el término HACKER implica consideraciones "ilegales".

Como digo, estos términos se emplean en medios AJENOS, aunque en muchas ocasiones dentro de nuestro colectivo.

Voy a hacer un paralelismo con algo similar, con lo que llevo luchando toda mi vida, y con el paso de los años he aprendido a gestionar, a no hacer caso, ya que no soy muy purista con el lenguaje, y mucho menos con la tendencia a clasificar y etiquetarlo todo.

Desde que tengo uso de la razón ( realmente hace muy poco tiempo  :-) ) he sido y soy un apasionado del Hip Hop. Desde que era pequeño escucho música RAP. Me siento parte del colectivo Hip-Hop, un movimiento reivindicativo, anti-sistema, un medio de expresión artística mediante el graffiti, el rap,dj´s y el break dance.

Cuando alguien de mi entorno conocía esta afición, siempre me han asociado con "El principe de Bell Air". Ese estilo de ropa "cagada", americana, con gorra, incluso la mayoría de la gente al descubrir estos gustos, imitaban saludos "raperos" con gestos de manos etc.

Si piensas en Rapero o Rappers, seguro que piensas en esa imagen.


Un rapero es aquel que canta Rap. Punto. El termino está desvirtuado por los medios ajenos, que no tienen ni idea. A mi, ME DA IGUAL lo que la gente opine, y como quieran llamarme. Lo que si es seguro es que mi estilo de vestir no tiene nada que ver con el que se supone que debería tener un rapero.

Si piensas en un rockero, no piensas en una persona que le gusta el Rock, casi seguro que pienses en un tipo con pelos largos, camisetas oscuras, conciertos y posiblemente cerveza/calimocho en mano.


Voy a ir más allá, Disc Jockey. En la RAE lo identifican como "pincha discos". Entonces, los DJ de ahora que pinchan música con el pc, no son DJ? Si le preguntas a un purista en la materia, te dirá que si no usas Vinilo no seas DJ, pero TODO el mundo llama DJ a cualquier persona que mezcla canciones, analógico o digital.

Para la gente con pensamientos políticos de izquierdas, la derecha es FACHA, pija.


Para la gente con pensamientos políticos de derechas, la izquierda es Perroflauta, hippie.


Alguna vez has usado?:
  • No hay moros en la costa.
  • Vas hecho un gitano.
  • Trabajas más que un negro.
  • etc.

Volviendo al término Hacker. Para mi, un hacker tiene varias connotaciones. Metiéndome en la piel de mi profesión, el término Hacker es el que todos conocemos, quizás el famoso debian-hacker, que se puede resumir como una persona con inquietudes más allá del funcionamiento deseado por un sistema, descubriendo nuevas funcionalidades, restricciones, etc.

Si me meto en la piel de un ciudadano de la calle, tengo que asumir, que Hacker es un pirata informático.

Me parece genial distinguir entre Hacker y Hacker ético, porque no siendo PURISTA, representa el término Hacker, orientado a hacer el bien o el mal.

Por poco que nos guste, en la sociedad en la que vivimos, el término Hacker está asociado a que te roben la clave de Hotmail, el perfil de Facebook, o las conversaciones de Whatsapp del novio/a de turno. Tanto os preocupa?

Cuando voy a un congreso de seguridad informática y escucho las típicas bromas sobre Windows, yo no monto en cólera y "lucho" por aquello que creo: tu Windows es malo porque TU no sabes usarlo. Pues no, me la trae al paire. Con esto me pasa lo mismo, es más, me parece super curioso que la gente se mueva con esto.

Para mi, mi profesión es la administración de sistemas, de manera segura, quizás un poco de seguridad informática, medidas defensivas ,en las que me toca conocer las medidas ofensivas, pero ni por allá paso me considero un Hacker, ni ético ni no ético.

Creo que de toda la comunidad que sigues, seguimos, hay muy pocos hackers, y la mayoría somos profesionales de la seguridad. Por eso, no se por qué tanto revuelo.

Voy a ir más allá. He leído que el Sr. Alonso ha creado una iniciativa para cambiar este término. Bien, siendo purista, el blog no se llama "un informático en el lado DEL MAL" ? todos sabemos que es una broma, una manera de escribir, con cierto gancho, pero todos sabemos que Chema Alonso no hace el mal, sino el bien. Nos ponemos puntillosos con el nombre del blog?

He hecho un pequeño muestreo con Google hacking... de los sitios de seguridad informática más populares en castellano, los que admiro, sigo y aprendo a diario y en casi todos he encontrado referencias erròneas el término hacker, es decir, nosotros mismos lo empleamos supuestamente MAL.

Se que soy yo, que por mi manera de pensar, me da igual con que palabra me encasillen, ya que lo que realmente me preocupa es mi carrera profesional, mis inquietudes, y lo que la gente me diga no me preocupa, pero insisto, me parece de risa que os preocupa tanto esto.

Gracias por leerme, qué opinas tu? o mejor dicho, que transcendencia tiene que gente que no sabe de nuestro oficio, no emplee los términos exactos? realmente no te identificas con Hacker ético?


OSSIM 21. Varios usos de la Reputation Data. Firewall, detección de tráfico e inclusión.

$
0
0
Hace unos capítulos hablamos aquí sobre OTX, la base de datos de reputación de AlienVault, El resumen es que podemos usar nuestra información de atacantes de la consola OSSIM para contribuir con una base de datos de reputación global, la que podemos usar para nuestras medidas defensivas.


En este capítulo vamos a darle ese uso, el defensivo, y no el meramente documental.

El primer uso, el más sencillo, podría ser integrar en nuestro sistema firewall, si lo permite, la lista de direcciones "maliciosas" para que sean baneadas. Este post no trata de eso, ya que cada sistema lo realiza de manera distinta, pero comentar que el fichero está disponible en un formato muy amigable ( tan sencillo como copiar en CSF blocklist, por ejemplo).


La ruta alienvault:/etc/ossim/server/reputation.data

El segundo uso que vamos a comentar es la monitorización de nuestros servicios IP en la base de datos. Esto quiere decir que añadimos nuestros equipos públicos, y configuramos una alerta para que en el caso de ser introducidos, por ejemplo por la presencia de malware en algún equipo que está "trabajando internet", el servicio nos envíe una alerta para poder gestionar la inclusión.
Esta configuración la hacemos directamente desde la url de Alienvault, con nuestro usuario.


Espero que os sirvan estas ideas para implementar en vuestros escenarios de seguridad xD.

Gracias por leerme !!!


EMET 5.1. Transformando "siguiente, siguiente, siguiente" en un proceso de seguridad empresarial.

$
0
0
En el capítulo de hoy de Inseguros vamos a hablar de una herramienta de seguridad gratuita de Microsoft llamada EMET, Enhanced Mitigation Experiencie Toolkit, recientemente actualizada a su versión 5.1.


Una descripción acertada es la de la propia Microsoft, por lo que copy&paste de Ms.

¿Qué es el Kit de herramientas de Experiencia de mitigación mejorada?
El Kit de herramientas de Experiencia de mitigación mejorada (EMET) es una utilidad que ayuda a prevenir que se exploten vulnerabilidades de seguridad en el software. EMET logra esto mediante el uso de tecnologías de mitigación de seguridad. Estas tecnologías funcionan como obstáculos y protecciones especiales que debe sortear el autor de un ataque para aprovechar las vulnerabilidades de software. Estas tecnologías de mitigación de seguridad no garantizan que no se puedan explotar las vulnerabilidades de seguridad. Sin embargo, su misión es dificultar al máximo dicha explotación.



EMET Security MitigationsIncluded
Attack Surface Reduction (ASR) Mitigation
Export Address Table Filtering (EAF+) Security Mitigation
Data Execution Prevention (DEP) Security Mitigation
Structured Execution Handling Overwrite Protection (SEHOP) Security Mitigation
NullPage Security Mitigation
Heapspray Allocation Security Mitigation
Export Address Table Filtering (EAF) Security Mitigation
Mandatory Address Space Layout Randomization (ASLR) Security Mitigation
Bottom Up ASLR Security Mitigation
Load Library Check – Return Oriented Programming (ROP) Security Mitigation
Memory Protection Check – Return Oriented Programming (ROP) Security Mitigation
Caller Checks – Return Oriented Programming (ROP) Security Mitigation*
Simulate Execution Flow – Return Oriented Programming (ROP) Security Mitigation*
Stack Pivot – Return Oriented Programming (ROP) Security Mitigation

Si eres un administrador de sistemas como yo, con apenas conocimiento sobre el mundo del reversing y del exploiting, creo que cabe destacar que Emet implementa medidas de seguridad para las técnicas habituales de explotación de vulnerabilidades en sistemas Windows. No funciona como un antivirus y su motor de firmas, sino que protege de comportamientos no deseados, como el intento de evadir DEP, ASLR, etc.

Si quieres profundizar en alguna de las tecnologías de evasión puedes leer esta guia en castellano, del instituto ese público famoso en España. 
Si queréis leer más sobre Certificate Pinning.


Lo mejor es probarlo, instalarlo siguiendo las opciones por defecto, hasta llegar a la interface gráfica.


Como se puede apreciar en la imagen, tenemos una lista de procesos en ejecución, y un icono de si está usando las medidas de protección Emet. Vamos a tomar un proceso como Winword.exe, para configurar su protección.


Tan sencillo como habilitar las opciones de seguridad.
Otra vista más gráfica y representativa puede ser esta.


Una de las opciones a destacar es la posibilidad de integrar la instalación de la herramienta mediante paquetes MSI con GPO´s de Active Directory o Configuration Manager.

Tenemos una línea de comandos preciosa, que nos sirve para habilitar/Deshabilitar medidas, o para usar una configuración base para todos nuestros equipos, mediante un fichero xml de configuración.

<EMET Version="5.1.5426.28431">
  <Settings>
    <ExploitAction Value="StopProgram" />
    <AdvancedSettings DeepHooks="True" AntiDetours="True" BannedFunctions="True" />
    <Reporting Telemetry="True" TrayIcon="True" EventLog="True" />
    <SystemSettings DEP="Application Opt In" SEHOP="Application Opt Out" ASLR="Application Opt In" Pinning="Enabled" />
  </Settings>
  <EMET_Apps>
    <AppConfig Path="*\Adobe\Acrobat*\Acrobat" Executable="Acrobat.exe">
      <Mitigation Name="DEP" Enabled="true" />
      <Mitigation Name="SEHOP" Enabled="true" />
      <Mitigation Name="NullPage" Enabled="true" />
      <Mitigation Name="HeapSpray" Enabled="true" />
      <Mitigation Name="EAF" Enabled="true" />
      <Mitigation Name="EAF+" Enabled="true">
        <eaf_modules>AcroRd32.dll;Acrofx32.dll;AcroForm.api</eaf_modules>
      </Mitigation>
      <Mitigation Name="MandatoryASLR" Enabled="true" />
      <Mitigation Name="BottomUpASLR" Enabled="true" />
      <Mitigation Name="LoadLib" Enabled="true" />
      <Mitigation Name="MemProt" Enabled="true" />
      <Mitigation Name="Caller" Enabled="true" />
      <Mitigation Name="SimExecFlow" Enabled="true" />
      <Mitigation Name="StackPivot" Enabled="true" />
      <Mitigation Name="ASR" Enabled="false" />
    </AppConfig>

El comando para importar el fichero podría ser: emet_conf.exe --import fichero.xml

Espero que os guste la idea, y por supuesto, gracias por leerme.


Gente que copia los artículos literalmente.

$
0
0
Como todos sabéis, existen varios sitios web que permiten obtener una imagen de como se encontraba una web en un momento dado. Uno famoso es Archive.org.

Esta mañana me he encontrado con un sitio parecido. El sitio es este.

Tengo que dar las gracias al señor en cuestión, porque aunque haga suyos los artículos, como si el fuera el redactor, realmente hace una gran labor ya que si por algún motivo Inseguros, Chema Alonso Blog, Security By default y demás caen, siempre podrás leer nuestros artículos en ese blog...

Algunos ejemplos curiosos:

Original: http://www.elladodelmal.com/2014/11/como-funciona-el-software-de-espionaje.html
Backup:http://soymikael.blogspot.com.es/2014/11/como-funciona-el-software-de-espionaje.html

Original:http://www.securitybydefault.com/2014/10/6-herramientas-para-la-identificacion.html
Backup:http://soymikael.blogspot.com.es/2014/11/herraminetas-para-auditar-en-primer.html

Original: http://www.elladodelmal.com/2014/07/mitagacion-de-ataques-pass-hash-y-pass.html
Backup: http://soymikael.blogspot.com.es/2014/07/mitigar-ataques-active-directory.html

Original:http://kinomakino.blogspot.com.es/2012/11/libros-para-estudiar-dejate-la-web-xd.html
Backup: http://soymikael.blogspot.com.es/2014/11/mis-libros-favoritos-aparte-de-la.html

Es la risa porque al buscar algunos textos, los de Chema Alonso me salen en muchos sitios, es decir, que este hombre "sufre" tambien estos plagios, a un nivel desmesurado !!!

Es un honor que copien mis post.

Realmente me da igual, porque tampoco creo que gane dinero el hombre con esto, o lo mismo... el año que viene gana Bitácoras 2015 con nuestros artículos xD.

Que cosas !!!
Viewing all 511 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>