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
Comprobar conectividad con el servidor OSSEC: ncat -u ip-servidor-ossec 1514


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


Comprobar si recibes datos desde clientes ossec al puerto 1514.
tcpdump -i eth0 port 1514


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.

jueves, 14 de agosto de 2014

OSSIM 12. Como monitorizar webserver > 1mill. files. TCP tunning, Inotify, OSSEC performance y demás.

Amigos veraneantes y no, de Inseguros.
Para esta entrada del verano voy a comentar algunos consejos que ido recopilando y usando en un despliegue empresarial que seguro os servirá de ayuda.


El escenario es un web server con distintos dominios y una larga seria de ficheros, mas o menos 1.000.000 de ficheros.
La idea es monitorizar la integridad de dichos ficheros, mediante el agente OSSEC, el cual indexará varios datos como el tamaño, el hash md5 y el sha-1.

Si has seguido la serie de artículos dedicados a Ossim, habrás configurado algún agente.
Vamos a usar su capacidad de realizar File Integrity Monitoring editando el fichero ossec.conf (  /var/ossec/etc/).
En el incluimos la ruta de ficheros que queremos monitorizar.
Ignoramos algún directorio, extensión de ficheros y poco más respecto al Syscheck.

<syscheck>
    <!-- Frequency that syscheck is executed - default set to every 22 hours -->
    <frequency>79200</frequency>

    <!-- Directories to check (perform all possible verifications) -->
    <directories>/etc,/usr/bin,/usr/sbin</directories>
    <directories>/bin,/sbin</directories>
    <directories>/var/www/vhost</directories>
  
    <!-- Files/directories to ignore -->
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/mnttab</ignore>
    <ignore>/etc/hosts.deny</ignore>
    <ignore>/etc/mail/statistics</ignore>
    <ignore>/etc/random-seed</ignore>
    <ignore>/etc/adjtime</ignore>
    <ignore>/etc/httpd/logs</ignore>
    <ignore>/etc/utmpx</ignore>
    <ignore>/etc/wtmpx</ignore>
    <ignore>/etc/cups/certs</ignore>
    <ignore>/etc/dumpdates</ignore>
    >ignore>/etc/svc/volatile&lgt;/ignore>
  </syscheck>
Es muy sencillo y lo recomendables pasarse por la documentación oficial y leer todos los parámetros disponibles.

Hasta este punto es muy sencillo. Ahora debemos añadir una regla en nuestro decoder en OSSIM para que emita una alerta cuando un fichero nuevo se cree. Si no hacemos este paso podríamos verlo en la parte servido de OSSEC en el servidor OSSIM, pero queremos verlo graficamente.
Editamos local_rules.xml en nuestro servidor OSSIM /var/ossec/rules/ y añadimos:


<rule id="554" level="10" overwrite="yes">
       <category>ossec</category>
       <decoded_as>syscheck_new_entry</decoded_as>
       <description>File added to the system.</description>
       <group>syscheck,</group>

<alerts>

    <log_alert_level>1</log_alert_level>
    </alerts>

Recuerda que estas reglas son las únicas que no se "machacaran" con los updates...



En el supuesto de establecer que cada 8 horas compruebe el millón de archivos que existe en este caso la lectura/escritura se vería considerablemente mermada, y todos sabemos que el Performance de los servidores reside en el almacenamiento ( Ram y persistente).

Ossec emplea la función Inotify del Kernel de Linux  ( > 2.6.13) que nos permite el Real Monitoring es decir, en tiempo real, detecta los cambios... Justo lo que necesitamos. Esta función es empleada para muchos desarrollos debido a la agilidad que proporciona.

Inotify almacena en Kernel Space una estructura de datos en la que almacena los ficheros a revisar y las acciones asociadas. De esta manera, tendremos agilidad respecto al acceso a disco. 
Para poder ver el el número máximo de ficheros "controlados" podemos ejecutar:

cat /proc/sys/fs/inotify/max_user_watches 


En mi caso he tenido que aumentar el tamaño para que no desborde el sistema. Realmente entran en cola, pero con la cantidad de ficheros se congestiona entra cada revision de SYSCHECK y no da los resultados correctamente. Cuanto lo subo?

Lo primero que debemos saber es que en sistemas 64 bits, cada watch, cada objeto suervisado ocupa en memoria 1 kb. Para el millón de ficheros empleo 1 GB ( 1mill. kb)Al usar Kernel Space no entra en Swap, por lo que si te mueves en entornos de poca memoria ojo !!!.
Para modificar el valor: echo fs.inotify.max_user_watches=1000000 >> /etc/sysctl.conf

Si queremos ver los procesos que están consumiendo recursos de Inotify podemos ejecutar: 



ps -p `find /proc/*/fd/* -type l -lname 'anon_inode:inotify' -print | sed s/'^\/proc\/'/''/ | sed s/'\/fd.*$'/''/`

Otra de las configuraciones que he revisado el tamaño del buffer TCP. En una conexión TCP existe un mecanismo de control de flujo en el que ambos extremos de la conexión conocen el espacio disponible para procesar los paquetes. Aumentando este tamaño a las capacidades actuales de velocidad y memoria, podemos obtener rendimiento entra la comunicación de nuestro agente OSSEC y el servidor OSSEC instalado en OSSIM. En el caso de necesitar performance para copiar ficheros grandes por la red y similares, este TCP TUNNING nos ayudará.

Para comprobar los tamaños del buffer TCP podemos ejecutar:


cat /proc/sys/net/ipv4/tcp_mem


Ajustamos a 12 MB como se recomienda para servidores de más de 4gb y líneas ADSL.


alienvault:~# echo 'net.core.wmem_max=12582912' >> /etc/sysctl.conf

alienvault:~# echo 'net.core.rmem_max=12582912' >> /etc/sysctl.conf
sysctl -p

Ejecutamos estas modificaciones en ambos extremos, OSSEC agente y servidor.

De esta manera he conseguido tener el millón de ficheros controlado ante modificaciones deseada o no, subida de ficheros y en general medidas anti-defacement, RFI y demás amenazas WEB.

Espero que os sirva de ayuda para este proyecto o para cualquier otro.

Gracias por leerme.