lunes, 1 de septiembre de 2014

Auto-Preguntas para saber tu estado de la seguridad.

Me ha gustado mucho una diapositiva que ha publicado el Sr. E.J. Hilbert sobre unas preguntas para hacerse, sobre todo si tu posición es la gerencia o dirección de departamento, para detectar si tienes un problema de seguridad.

Estamos hablando a nivel teórico, pero vamos a intentar ponerlo en práctica.
La diapositiva en cuestión es esta:

¿Quien es el responsable específico en seguridad en tu empresa?

Un clásico  !!! Los desarrolladores le pasan el problema a sistemas, los de sistemas se quejan del presupuesto de gerencia, gerencia necesita agilidad en los desarrollos, ventas vende lo que aún no está ni desarrollado, etc.

Con este pregunta no se trata de designar un responsable para "cortar cabezas" en el caso de un incidente de seguridad. Simplemente debe haber alguien que vele por la coherencia de los sistemas de seguridad, ya sean técnicos, medidas organizativas, procesos, etc.

Es importante que esta figura tenga un perfil técnico, y no se quede en la superficie de la descripción de procesos de seguridad tipo 27001 y similares, en las que se DOCUMENTA el sistema que hay, con algunas recomendaciones, pero si mi sistema de seguridad consiste en cambiar de contraseña cada 6 meses...la ISO no me soluciona nada. Es típico encontrar un CISO "burocrático" y no técnico. Ambas cualidades son necesarias.


Para apoyar un poco técnicamente este argumento, desde Inseguros hemos visto muchos posts sobre OSSIM, una consola de seguridad. Un simple software como este puede ser el comienzo para que alguien en el departamento le dedique todos los días unas horas para supervisar el estado de la nación.

¿Quien decide quien tiene acceso a qué tipo de información, y de qué manera?.

La seguridad total no existe, un clásico del verano !!! Un pc sin conexión a Internet no puede ser atacado por Internet. Esto dista mucho de la realidad, en la que generalmente los procesos productivos de la empresa priman sobre las medidas de seguridad. Información puede ser acceso en el proxy de la empresa a TODO Internet al director de RRHH, porque es hermano del directivo X. Los propios administradores de sistemas tenemos acceso a mucha información, con tan solo los logs del sistema.
Por supuesto que los departamentos deben ver solo la porción de información que necesitan, pero esta tarea es sencilla de diseñar a priori, compleja de mantener durante el tiempo.


¿Qué datos son vitales o tienen mas valor para mi empresa, quien tiene acceso a ellos, de qué manera, y cuales son los peligros a los que se enfrenta?.

Al hilo de la reflexión anterior, sospecho que las medidas de seguridad para la receta de la Coca Cola no deben ser las mismas que para entrar a tu CPD, si no es el caso en el que el CPD y el ordenador de "Pepi" es el mismo. Identificación de activos es algo básico. Medición, sean con métricas formales o con una métrica inventada por nosotros:

Información= Me da igual que salga hasta en Facebook.
Advertencia= Ojo, esto puedo verlo mi novia.
Alarma= Mi novia ha visto la foto, y cuando llegue a casa la voy a tener.
Error= Mi novia me ha dejado por un comentario inapropiado sobre la guapa del momento.


No me importa el formalismo de la métrica, pero hay que realizar un inventario y cualificar la criticidad de los datos y servicios. Gerencia o compras o quien tenga el sello de los talones debe entender y apoyar que no es lo mismo que alguien lea el correo de un diseñador, o que obtenga la información de cuentas bancarias de clientes. Con matices, si tu empresa se dedica al diseño :-).

Evaluar los posibles peligros es el siguiente paso. Puede ser que en primeras instancias no implementemos todas las medidas necesarias, pero al menos estarán en el horizonte como objetivo, y una continua revisión de los fallos y ataques que van apareciendo nos harán mas conocedores del "mundo en el que nos conectamos".

Muchos amigos me comentan o incluso pintan las caras de sus jefes cuando les hablas de appliances de seguridad. A veces son los mismos amigos informáticos los que no quieren cambiar su firewall de toda la vida por otro mas moderno, porque les costaría horas ( retomamos por aquí la figura del CISO? ).

Recuerda que la seguridad puede ser una cebolla, que te hace llorar? no :-) que funciona por capas, y podemos ir solapando medidas. Empezando siempre por las menos costosas y más "ruido" hagan. Si haces un reporte todas las semanas con los ataques o amenazas que tus sistemas detectan ( aunque sea el fuck*** router de tu ISP, tambien tiene logs !!!! ) quizás gerencia vea con mejores ojos la compra del siguiente "cacharro".

¿Cuando fue el último análisis de seguridad efectuado, quien lo ha ejecutado, y donde esta la documentación?

Un escaneo de puertos hacia tu sede ya es un análisis de seguridad. Básico, rudimentario, pero ya puedes detectar algún pequeño fallo de seguridad o diseño.

Realizar un test de intrusión es una tarea compleja, MUY COMPLEJA, pero realizar o aproximarse a una auditoría de vulnerabilidades está al alcance de todos. Por ejemplo este post de Openvas reciente es bastante útil.

No sirve que asistas a un congreso como NAVAJA NEGRA y vuelvas el lunes con ganas de cambiar el security-space de tu empresa. Si sirve !!! pero poco a poco. Demuestra con informes periódicos, claros y concisos la necesidad de implementar medidas de seguridad concretas. Recuerda, empieza por las baratas !!!

¿Tiene tu empresa una política de concienciación de amenazas, gestión y operaciones diarias?

Esta parte, la humana, tannn importante en la seguridad no la venden las grandes consultoras, se hace desde dentro.

Todos saben que no deben abrir ficheros de correos. Todos saben que no deben abrir un fichero llamado despidos-2015.pdf .... Todos saben que no deben revisar sus correos personales en la oficina... Si es así, compruébalo !!! Por ejemplo en Inseguros vimos Simple Phishing Toolkit para realizar campañas de concienciación internas, en la que podíamos medir la efectividad de esa nota que pasamos a todo el mundo con las medidas de seguridad básicas en el uso de Internet en la empresa...

En la parte de operaciones diarias el empleado, el usuario debe conocer exactamente la manera de trabajar que la organización espera de el en materia de seguridad. Si el acceso hacia la empresa se hace por VPN ipsec no le dejes usar ese VNC de comodín que hay por ahí instalado que es muy cómodo para "conectarse un minuto" en vez de instalar el cliente L2TP. Al menos, que sepa cual es la manera correcta.

¿Quien es el responsable de velar por la información expuesta en las redes sociales y las fugas de información?

Un buen Community Manager se puede encargar un poco de esto. Igual que muchos CM gestionan las malas opiniones de productos y servicios en web, foros y demás, también podría ser instruido en revisar periódicamente Pastebin, ZoneH o Google !! en busca de datos de la empresa que gestiona. Al fin y al cabo, es reputación en la red.


Recuerdo una empresa en la que puse su ip en Google, algo muy básico en las auditorías, y tras pasar los whois y demás servicios encontré un foro en Ruso en el que ponía algo así como: Ip: Центр обработки данных с общественными системами Windows, и SQL Server.
Кажется, больница. y alguna cositas más... en abierto.

¿Tiene su empresa un plan de contingencia para la seguridad?

La contingencia siempre es necesaria. En alguna empresa en la que he prestado servicios como administrador de sistemas he intentado siempre tener un plan de contingencia. Aunque sea en papel !! No me refiero a que esté descrito en papel, sino que si un proceso crítico como pueda ser la recogida de datos de un cliente no está disponible por un fallo informático, pueda crearse una "ficha en papel" para que la información se vuelque al sistema una vez se restablezca. Esto es sencillo y si haces bien esta tarea, podrás irte de vacaciones más tiempo !!!

En el caso más técnico, por ejemplo en el caso de estar sufriendo un ataque DDOS. Tiene tu comercio ON-Line alguna medida? puedes bloquear en modo "botón de emergencia" la procedencia de las conexiones? el tipo?.

Si has sufrido un Defacement, tienes una copia de seguridad operativa, lista para parchear y poner en producción lo más rápido posible?


En el caso de una infección de Malware, tienes delimitada la red por segmentos y cuentas con alguna herramienta de análisis de tráfico para detectar los movimientos?

Hay muchas medidas de contingencia que se pueden implementar, como siempre, empezamos desde la más barata en adelante. La virtualización que hemos visto aquí nos sirve de ayuda a la hora de preparar un buen plan de contingencia.

Vital el punto de la detección, para poder actuar.

¿Tiene su empresa la capacidad de exponer una brecha de seguridad para poder pararla?

Este párrafo se podría extender muchísimo, desde la clásica aproximación de open source si o no, hasta la reputación de una empresa, pasando por actividades ilegales de empresas.

Imaginaros que una banda de cibercriminales roban la base de datos Access instalada en local en el pc del contable, la típica aplicación que no aparece en ningún sitio que esconde el dinero negro ( Si eres de fuera de España quizás esto no sea tan habitual :-)  ). No creo que puedas acudir a las fuerzas de seguridad para que reclamar la persecución de estos criminales.

Imaginaros que comprometen la seguridad de las cuentas de tus clientes por una simple SQLi. Está tu organización preparada para comunicar el incidente a los usuarios pidiéndoles que cambien sus contraseñas, o vas dejar que se publique la información con el daño a tus clientes?

Si recientemente has invertido en seguridad, en una de esas empresas con más portafolio que valor, deberías hacerte estas preguntas para ver si esa empresa realmente te está dando "seguridad" o "falsa sensación de seguridad" con sus auditorías semestrales y sus manuales copy&paste.

Si vas a invertir en seguridad, ten muy en cuenta estas reflexiones a la hora de implementar tus medidas, o contratar el servicio externo.

Si eres un experto en seguridad seguro que todo esto te lo sabes, y que tendrás anécdotas para cada párrafo la mar de simpáticas. ¿Por qué no las cuentas?

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

viernes, 29 de agosto de 2014

OSSIM 14. Rutas de configuración y logs para el trabajo con OSSEC/OSSIM.

Actualizado constantemente...

Has leído ya los 13 artículos previos a este?

En el mundo OSSIM- OSSEC no he conseguido encontrar "la biblia" o documento perfecto. Para realizar los procedimientos básicos es mas o menos sencillo encontrar buenas referencias de información, como este humilde blog :-)  pero para el trabajo diario es necesario conocer muchos ficheros de configuración y registros para ver que está ocurriendo y poder segmentar. El típico "no me llega los logs" hay que delimitarlo en que parte falla el proceso.

He decidido crear este mini post recopilando las rutas y ficheros que para mi son de ayuda en mi día a día.

Espero que os guste.

Como comprobar que están llegando paquetes de una ip concreta a un servidor:
tcpdump -i eth0 -v -w /dev/null 'src ip'


OSSEC-Cliente.

Configuración general del cliente: /var/ossec/etc/ossec.conf
Log del cliente OSSEC: /var/ossec/log/ossec.log

OSSEC-Servidor.

Comprobación de actividad recibida por un agente concreto.
/var/ossec/bin/agent_control -lc * lista los agentes.
/var/ossec/bin/agent_control -i 002 * muestra la información.

Controlar los últimos cambios en ficheros detectados por Syscheckd (útil para el FIM)
/var/ossec/bin/syscheck_control -i agente
Ampliar detalles de cambios sobre un fichero concreto
/var/ossec/bin/syscheck_control -i agente -f /ruta/fichero_modificado


Comando de servicio para el servidor OSSEC.
/var/ossec/bin/ossec-control {start|stop|restart|status|enable|disable}

Logs para ver la estadística de eventos por un día. 
El formato es por cada dia un fichero, dentro: Hora, SID, LEVEL, y las veces que se ha producido. Al final del fichero tenemos el resumen:

 /var/ossec/stats/totals/2014/Sep/ossec-totals-01.log


OSSIM-Servidor.

Actividad de los agentes hacia OSSIM: /var/log/agent.log

Actualizar la versión de OSSIM desde consola, no desde el GUI:

alienvault-update -c -v -d

Reinicio de servicios.




OSSIM 13. Conectando un sensor Snort externo y jugando con scripts.

En anteriores episodios de OSSIM, el sistema SIEM open source de AlienVault hablamos de:

1234567 , 89 10, 11, 12 13, 14.

Por cierto, has visto el cuadrante mágico de Gartner para el mundo SIEM de 2014?



En esta entrega vamos a conectar nuestro sistema Snort externo a OSSIM.
Aunque la distribución OSSIM trae por defecto snort y suricata para la recolección de eventos, por motivos de infraestructura puede que queramos conectar los logs de un sistema snort externo, como pueda ser un VPS, una delegación remota, un segmento de red aislado, etc.


El procedimiento es sencillo, aunque deberíamos mejorarlo por tema de perfomance, ahora os cuento.
Basícamente lo que hacemos es que configuamos Snort con una salida syslog.
Configuramos rsyslog en el servidor snort para que envie al rsyslog de OSSIM.
Configuramos el plugin en OSSIM para Snort-Syslog, para que sepa decodificar los eventos.
Adicionalmente vamos a crear una política que ejecute un script por cada detección de evento. El script realizará un baneo de la ip que origina el evento, en varios servidores.

La configuración de snort para la salida hacia SYSLOG es:

alert_syslog output: host = IP: PUERTO, LOG_AUTH LOG_ALERT

He detectado que de esta manera añade al syslog local del servidor Snort los logs, en la rama /var/log/messages.

En el fichero /etc/rsyslog.conf añadimos el servidor remoto, en nuestro caso, OSSIM, que previamente tiene hechos el nat y la reglas del firewall ya que son dos elementos conectados mediante la red de redes (Internet? )

auth.alert @ip:puerto

En esta sección podrás encontrar si cotejas este procedimiento con otros, que la gente hace *.* @. Con esto estaríamos enviando todos los logs del syslog del servidor snort hacia OSSIM, los logs de Snort, y todos los del sistema.
De la manera que indico se filtran gran parte de eventos, aunque se puede jugar más con rsyslog para crear un filtro por la palabra Snort. Tampoco es muy preocupante, pero el Performance disminuye ya que tiene que enviar más log. No muy grave. 

Esto va a hacer que como mediante el agente OSSEC TAMBIEN INSTALADO EN EL SERVIDOR SNORT, para File Integrity Monitor como vimos en el anterior capítulo, está recolectando y enviando logs a OSSIM de sur /var/log/messages, en OSSIM tendremos duplicado el evento IDS Snort, uno que le viene por OSSEC y otro que enviamos por Rsyslog. Crearemos una regla para excluir esto...

Ahora toca el turno de la parte receptora, el servidor OSSIM. En la linea del rsyslog autorizamos la recepción de logs del servidor Snort.

*.* @ip snort.

Ahora configuramos una regla para que los logs que vengan de Snort, los almacene en un fichero exclusivo. Este fichero será el que indiquemos en el plugin snort-syslog ( el que conoce la estructura del log) para poder leer.

vim /etc/rsyslog.d/snortovh.conf :
if $ fromhost == '***********' then /var/log/snortovh2.log
& ~

vim /etc/ossim/agent/plugins/snort_syslog.cfg
source=log
location=/var/log/snortovh2.log

Reiniciamos en ambos servers rsyslog.

En Ossim>configuration>deployment>sensor config.>collection añadimos el plugin snort-syslog.


Ya tenemos los eventos en el SIEM.


Has visto las ip que aparecen con un circulo amarillo? recuerdas el post de OTX? eso es una ip maliciosa. 

Ahora retomamos el post para creación de políticas para nuestros logs, y metemos el evento genérico IDS EVENT que nos viene de /var/log/messages y que no se parsea bien, y lo metemos en una política que me gusta usar llamada "errores_habituales" en la que añado los id de evento que me aparecen, pero no quiero ver en el SIEM. Recuerda que a OSSIM le van a llegar los eventos de Snort por dos vías, por rsyslog y por ossec. Como hemos configurado el plugin que lee snort_syslog para que lea los log del rsyslog, los de ossec aparecen genéricos, por eso los omitimos.

Y ahora? Ya tenemos información de lo que pasa en nuestro servidor. Ahora vamos a pasarle la IP a un script por cada evento, para que banee en varios firewalls. No es la mejor opción, pero dada la infraestructura y necesidades del servidor Snort ( es un vps externo) no podemos poner Snort en modo inline, en modo IPS, es decir, que Snort no para los ataques. Las reglas DROP no funcionan, por ejemplo, si está puesto en modo pasivo mediante un port mirroring o span port en un switch.


Si un atacante ejecuta un exploit, este se ejecuta, pero lo detecta Snort y banea la ip. Esto es útil para escaneos y herramientas de juacker, ya que si el primer exploit o ataque no es satisfactorio, esa ip se banea. En el caso de usar un ataque mediante la red Tor, la cosa se complica ya que la IP del atacante no será la misma. Para estos casos yo recomiendo unos scripts que se bajan todos los días y se incluyen en iptables con las ip´s de Tor que tienen acceso a tu servidor. En otro capítulo lo hablamos o me lo preguntáis directamente.


Las posibilidades de ejecutar comando por cada detección es increíble, la imaginación al poder.

Simplemente tenemos que crear un script en el servidor OSSIM, con la identificación de la shell o lenguaje al principio, como indican las buenas prácticas de scripting, y darle permisos de ejecución.

En OSSIM, creamos una política e indicamos que es para todos los eventos de Snort Signature.


Más abajo en Policy Consequences creamos una acción de ejecución de script, y la vinculamos a la política. Debemos hacer un Reload Policies para que quede activa.



Puedes crear un script sencillo que te escriba en un log para probar que funciona. Por ejemplo.

#!/bin/sh

/bin/echo `/bin/date`: La IP $1 Está atacado >> /tmp/prueba-script.log

chmod 755 script.sh

También puedes probar a pasarle más argumentos al script, como hacemos cuando la acción es enviar un correo informativo.

Espero que os guste el artículo y como siempre, gracias por leerme !!!




miércoles, 27 de agosto de 2014

OPENVAS self-fingerprint. Maquillando al atacante.

Voy a retomar una serie de artículos de mi amigo 1GBDEINFORMACION en donde nos deleita con el artículo uno y dos sobre los primeros pasos con OPENVAS, en este caso bajo KALI LINUX.

Una de las primeras acciones que debes realizar con OPENVAS es camuflar un poco los scan config.
Si el destino de nuestro test es un sistema con algún tipo de medidas de seguridad como firewal, ids/ips, waf y similares, el scan no llegará a buen puerto, tan solo por los User-agents.

El primer paso que debes hacer es configurar todos tus plugins que usen conexiones http con un USER-AGENT válido, no del tipo "OPENVAS" o "ARACHNI". Esta información es la más básica para las medidas defensivas.

Algunos ejemplos.





Usando simplemente la opción del buscador, podemos identificar rapidamente todos los tags.

Otra de las cuestiones que me interesa es la detección en si misma del PortScan.

En muchas instalaciones de Snort no se activa las reglas pre-procesador de http inspección y strem5. Y un portscan no se detecta, salvo por esta regla:

[**] [1:2002911:4] ET SCAN Potential VNC Scan 5900-5920 [**]
[Classification: Attempted Information Leak] [Priority: 2]
08/27-17:41:17.601600 ********:5024 -> ******
TCP TTL:49 TOS:0x0 ID:11387 IpLen:20 DgmLen:40
******S* Seq: 0xBD99  Ack: 0x0  Win: 0x10  TcpLen: 20
[Xref => http://doc.emergingthreats.net/2002911]

En vez detectarlo con otros puertos.

Time: 08/27-17:06:14.534884
event_ref: 0
***** -> 200.81.44.206 (portscan) TCP Portsweep
Priority Count: 5
Connection Count: 0
IP Count: 6
Scanned IP Range: 173.194.113.234:212.111.97.154
Port/Proto Count: 2
Port/Proto Range: 25:80

Dicho esto, debemos clonar uno de los perfiles de puertos que trae de casa OPENVAS, ya que estos no se pueden editar. Editamos la copia, y borramos el rango de puertos que la alerta de Snort nos indica como VNC Scan.



Esta claro que si necesitas auditar estos servicios, deberás preparar otra estrategia como hacer netcat desde tor o similares.

Algunas de las opciones que podemos configurar para la evasión de sistemas de seguridad son las siguientes. Una de las cosas buenas que tiene OPENVAS es que informa de todas las posibilidades, por lo que no temas en darte una vuelta por la configuración e incluso aprender xD.




Como es lógico con estas recomendaciones no conseguirás saltar las medidas de seguridad de un sistema bien implementadas, como puedan ser Snort (IPS) + MODSECURITY (engine On) + Firewall State, pero seguro que para muchas malas implementaciones o sistemas desprovistos te puede ser útil.

Para agilizar o digamos customizar el scan config me gusta ver los logs del scan, para detectar la ejecución de plugins, los time-out y demás.
Por ejemplo, en Kali tenemos este log bajo:
/var/lib/openvas/users/om/kbs/IP.
Me encuentro con que este plugin está tardando mucho:


Si no me es muy interesante, deshabilito el plugin, que reside bajo la familia Port Scan ( En esta misma sección me gusta QUITAR el ping scan, lo que viene siendo un -Pn con nmap).
Una búsqueda por internet me informa del plugin.



Esta es una manera de ir personalizando nuestra configuración de scan, dependiendo del trabajo previo que hayamos hecho el la fase de Intelligence Gathering & Information Gathering. ( no tiene sentido atacar con plugins para Windows cuando en el trabajo previo con técnicas OSINT nos dice que es un sistema Linux).

No olvides exportar tu xml para backup con la configuración de scan que vas preparando, ya que es un trabajo costoso el llegar a crearte tus profiles preferidos.

Como siempre, espero que os sirva de ayuda y gracias por leerme !!!


lunes, 25 de agosto de 2014

Borrar el tag Powered By en servidores Apache

Es tan sencillo como añadir en tu fichero de configuración httpd.conf o apache2.conf:

Header unset X-Powered-By
 

Espero que os sirva de ayuda.
Related Posts Plugin for WordPress, Blogger...