Seguridad, Hacking Ético y otros

Premio NAI - Cátedra Telefónica - UPM

2008-12-19T03:49:00.000-08:00

El día 10 de Diciembre se falló la octava edición del Premio de Nuevas Aplicaciones para Internet de la Cátedra Telefónica - UPM. Una de las propuestas finalistas, llamada Iw3Caché, fue presentada por el autor de este blog junto a un compañero de trabajo, Francisco J. Gómez. Podéis visitar el blog www.iniqua.com del cual somos colaboradores.

La propuesta está relacionada con la seguridad de la información y pretende ser una herramienta para combatir el Pharming.

Nos sentimos satisfechos con el resultado y trabajaremos ahora sobre la idea con más entusiasmo y energía. Os invitamos a todos a que conozcáis la idea mediante la lectura del documento que se ha publicado en la web del concurso: Iw3Caché, un nuevo concepto AntiPharming

Todas las opiniones y comentarios serán bienvenidos.

¿Y los detalles de la vulnerabilidad DoS del protocolo TCP?

2008-10-20T07:32:00.001-07:00

Cualquiera lea este post y esté interesado en la seguridad informática, es probable que este fin de semana (18-19 de Octubre) haya buscado alguna reseña, video, resumen o cualquier tipo de información acerca de la conferencia Sec-T del 17 de Octubre donde, en principio, iba a ser el lugar y el momento elegido por Jack C. Louis y Robert E. Lee, para dar a conocer los detalles de la vulnerabilidad TCP DoS que anunciaron el pasado 11 de Septiembre.

Bueno, pues si alguien ha estado buscando esta información durante el fin de semana habrá pensado, como yo, que se ha equivocado de día, o que de pronto ha dejado de interesar a todo el mundo.

Pues no, según nos cuenta Robert E. Lee en su blog, al final han decidido retrasar la publicación de toda esta información:

"... we opted to continue to work closely with, and give more time to, the vendor and standards communities. We are not putting them under undue pressure to get poorly implemented rushed fixes out."

Van a dar mas tiempo a la comunidad y a los fabricantes para encontrar una solución efectiva, lo cual, en principio, parece una decisión acertada y ser lo más sensato.

Pero además, hay algo en el último post de Robert E. Lee que resulta curioso (que en realidad es el tema principal de la entrada), que es una respuesta del propio Robert a una página de Gordon Lyon en la que éste último, habla sobre la supuesta vulnerabilidad DoS del protocolo TCP. Gordon, también conocido como "Fyodor Vaskovich" es un experto en seguridad de red y autor del famosísimo Nmap. En esta página se cuestiona la importancia del descubrimiento de Jack C. Louis y Robert E. Lee diciendo que:

- No es más que otro nuevo ataque de Dos entre tantos otros.
- No es una amenaza tan seria como se cree ya que, entre otras cosas, para un potencial atacante no es fácil obtener un beneficio lucrativo con ataques DoS.
- Detectar y evitar un ataque que aprovechara esta vulnerabilidad no resultaría tan difícil como Robert insinúa.

Total, que Robert ha contestado en su último post a todo esto utilizando unas FAQ para ello:
(Traducción personal)

Pregunta: ¿Se ha descubierto realmente algo nuevo?
Respuesta: Los ataques que Gordon describe en sus razonamientos no son nuevos y afectan a los sistemas de hoy en día. Los detalles de la vulnerabilidad descubierta por nosotros, se encuentran en manos de las partes implicadas y Gordon puede ayudar a solucionar el problema, o quedarse mirando y lanzar comentarios destructivos. Espero que cambie de parecer y elija trabajar con nosotros...

P:¿Cómo de serio es el problema? Si ya se conocía, ¿por qué no lo utilizan los atacantes ahora mismo?
R: No creo que nadie pueda estar seguro de si los atacantes lo están utilizando o si ya están informados de todo.

P: ¿Es cierto que no hay solución a este problema?
R: Gordon dijo que "Una vez comienza el ataque, es relativamente fácil identificar y bloquear la IP origen de los ataques" Eso está por ver, ahora mismo eso no parece posible.

Así que, bueno, no podemos saber cuál de los dos lleva razón realmente; si al final no es para tanto toda la expectación generada y no han descubierto nada nuevo, o si ha sido una suerte que se haya detectado este fallo del protocolo primero desde el "lado bueno".

Ya veremos qué pasa ...

Sorteando la detección de malware

2008-08-20T03:53:00.000-07:00

Muchos antivirus trabajan rastreando y buscando firmas (signatures) de virus conocidos para detectar elementos maliciosos. Conocen las carácteristicas particulares de cada virus e intentan detectar los archivos que cumplen con esas características y que sean sopechosos.

Lo que vamos a hacer a continuación es modificar el contenido de un archivo malicioso, un Portable Executable (normalmente archivos con extensión .exe) para intentar que no sea detectado por los antivirus.

En este caso vamos a intentar ocultar un antiguo troyano llamado Tiny (tini.exe) que casi todos los antivirus son capaces de detectar. Podemos ver el resultado de enviar este troyano a Virus Total. Todos los motores antivirus lo clasifican como sospechoso:

Durante las pruebas vamos a intentar engañar al antivirus Kaspersky 7.

Mientras tenemos funcionando este AV e intentamos introducir el archivo tini.exe en nuestro PC, inmediatamente Kaspersky lo detecta y muestra una alerta de troyano. Este antivirus es bastante insistente y "follonero" y es necesario detenerlo para poder hacer las pruebas.

Lo que haremos será codificar todo el contenido de la sección .text del ejecutable (que es donde se encuentra el código del propio troyano), para que el antivirus no reconozca nada sospechoso en el código fuente de nuestro ejecutable. Para codificar el código fuente utilizaremos una simple operación XOR. Veamos cómo llevar a cabo esta codificación:

Seguir Leyendo...

Primero, modificamos manualmente con un editor de PE (LordPE por ej) las cabeceras del ejectuable y aumentamos el tamaño de la sección .data en 4096 bytes (1000 en hexadecimal). Esto lo hacemos para añadir nuestro propio código ensamblador al final de esta sección.

También aprovechamos y marcamos la sección .text como editable y la sección .data como ejecutable.

Con un editor hexadecimal tendremos que rellenar esos 4096 bytes de espacio que hemos añadido con el valor 00 hex por ejemplo.

Ahora, vamos a añadir una pequeña porción de código ensamblador al ejecutable, y para ello utilizamos Olly Debugger. Nada más abrir el tini.exe con Olly, nos lleva a la primera intrucción que se ejecuta (dentro de la sección .text):

Nosotros sobreescribimos la primera instrucción y ponemos un salto (instrucción JMP en ensamblador) a una dirección de memoria de la sección .data (donde nosotros hemos añadido los bytes de relleno) que será donde añadiremos manualmente la porción de código encargada de la codificación. Antes de sobreescribir la primera intrucción nos la copiamos donde sea para luego poder recuperarla y no alterar así nada del código original.:

Añadimos a partir de la dirección donde salta nuestro JMP las siguientes instrucciones de ensamblador:

MOV EAX,dir_comienzo_codificación    //movemos al registro EAX la dirección de memoria donde comenzará la codificación

XOR BYTE PTR DS:[EAX],0F        //realiza una operación XOR entre el contenido de la dirección de memoria que contenga EAX y el valor 0Fh

INC EAX //incrementa el valor de EAX

CMP EAX,dir_fin_codificación //comprueba si se ha llegado a la dirección de fin de codificación

JLE SHORT dir_comienzo_bucle //si no son iguales así, vuelve al comienzo del bucle

La dirección de comienzo de codificación será la siguiente a la instrucción de salto que introdujimos al comienzo del ejecutable, en la imagen superior podemos ver que esa dirección es la 00401005. Como dirección de fin de codificación ponemos una dirección que veamos que esté al final del código del ejecutable, en este caso 004012F1.

A continuación del bucle, pondremos la instrucción que machacamos al principio cuando pusimos el JMP, es decir PUSH 00403014, después, ponemos un salto a la dirección 00401005 para que regrese a la siguiente instrucción despues el primer JMP que añadimos al comienzo. Nuestro código queda así:

Ponemos un punto de ruptura en la siguiente instrucción después del bucle de codificación (por ejemplo dirección 00403027) para que se detenga la ejecución una vez salga del bucle. Cuando pulsamos el botón play del Olly, inmediatemente se ejecuta el bucle que hemos añadido y se detiene en el punto de ruptura. En este momento, todo el código ensamblador de la sección .text del PE se encuentra codificado. Ahora guardaremos estos cambios en la sección .text y creamos un nuevo archivo (tini2.exe).

Si abrimos el nuevo ejecutable con Olly podemos ver que ya no aparecen las mismas instrucciones que la primera vez que lo abrimos. Ahora, despues de nuestro JMP ha cambiado todo:

Veamos qué hace este nuevo ejecutable ejecutándolo paso a paso (F7). La primera instrucción sigue siendo el JMP que añadimos al comienzo, a continuación salta directamente al bucle que añadimos nosotros, pero aquí viene lo interesante; una vez que se complete el bucle de codificación, el contenido de la sección .text vuelve a ser el mismo que al principio ya que se le ha vuelto a aplicar la misma función XOR.

La clave está en que la víctima que ejecute este archivo, tendrá el contenido original malicioso del troyano en memoria y no en disco. Al recibir la víctima nuestro archivo en el PC, el antivirus lo inspeccionará y no encontrará nada sopechoso ya que no hay similitudes en su código fuente con ningún virus conocido, (ya que el código fuente se encuentra codificado en disco), pero una vez que la víctima lo ejecute y pase a memoria, en tiempo de ejecución se vovlerá a descodificar y la funcionalidad del troyano se mantendrá intacta.

Lo podemos comprobar si activamos de nuevo Kaspersky e inspeccionamos el archivo tini2.exe. Vemos que no detecta nada.

También se ha comprobado que el nuevo ejecutable evade las alertas del antivirus Nod32.

Después podremos ejectuarlo con prudencia y comprobar que la funcionalidad del troyano se mantiene intacta.

Queda de esta forma desmostrada la necesidad de implementar por parte de los antivirus un sistema de detección de virus que vaya más allá de las firmas.

Esta prueba no deja de ser una prueba de concepto y mediante este método no se consigue evadir a todos los sitemas antivirus. Enviando el archivo que se utilizó para las pruebas a Virus Tota l hemos obtenido 8 alertas de un total de 36, es decir, fueron capaces de detectarlo un 22% del total. El tini.exe original generó un 100% de alertas (36 de 36):

Este entrada se ha desarrollado a partir de una presentación de la Shmoocon 2008 ("Hacking and Stuff") de Mati Aharoni. Podéis descargar un video de esta presentación desde aquí: Backtrack demo

Defiéndete de ataques arp-spoofing / MITM (Man In The Middle) con ArpON

2008-06-18T05:47:00.001-07:00

ArpON (Arp handler inspectiON) es una herramienta que permite manipular algunos aspectos del protocolo ARP. Una de sus cualidades destacadas es la de hacer el protocolo ARP más seguro. Implementa dos técnicas de defensa contra ataques de envenenamiento ARP (ARP spoofing):

SARPI "Static Arp Inspection"
DARPI "Dynamic Arp Inspection"

En este caso vamos a estudiar la segunda.

DARPI
Una vez entra en funcionamiento, lo primero que hace es limpiar la caché ARP eliminando todas las entradas evitando así posibles envenamientos previos.
Después obedece a las siguientes políticas de gestión de paquetes ARP utilizando una caché propia llamada caché DARPI:

Para los paquetes ARP request:

Seguir Leyendo...

- Salientes: Los generamos nosotros, por tanto ArpON los deja pasar y añade una entrada con la dirección destino a la caché DARPI (para posteriormente ser consultada cuando lleguen paquetes ARP reply)

- Entrantes: ArpON rechaza el paquete y borra la entrada correspondiente a la dirección origen de la caché ARP (ya que este paquete puede estar envenenado); el kernel enviará un paquete ARP request a esa dirección origen, y este paquete se gestionará siguiendo la política de paquetes salientes DARPI.
De esta forma, ArpON nos defiende de ataques de envenenamiento ARP mediente paquetes ARP request.

Para los paquetes ARP reply

- Salientes: Estos paquetes los generamos nosotros y ArpON les da paso.

- Entrantes: ArpON comprueba si la dirección origen se encuentra en la caché DARPI (la que fue añadida al enviar un ARP request saliente); en ese caso, lo deja pasar y añade una entrada en la cache ARP. Si la dirección origen no se encuentra en la caché DARPI, ArpON rechaza el paquete y elimina la entrada de la caché ARP.
De esta forma, ArpON nos defiende de ataques de envenenamiento ARP mediente paquetes ARP reply.

Desde la página principal nos informan de que el servicio ArpON no afecta al rendimiento del protocolo ARP.

- Vamos una demostración de cómo trabaja esta herramienta:

Para esta demostración se ha descargado, compilado e instalado las librerías que se propone desde la página principal de ArpON:

libpcap-0.9.8.tar.gz
libnet-1.1.2.1.tar.gz
libdnet-1.11.tar.gz

Escenario:

1 Un pc con Debian instalado se defenderá de ataques arp-spoofing utilizando ArpON.

2 Otro pc con Debian instalado será el atacante y lanzará un ataque arp-spoofing (arp reply) utilizando ettercap entre la víctima y la puerta de enlace.

IP atacante: 192.168.6.137 dirección MAC uu:vv:ww:EC:D4:B9
IP víctima: 192.168.6.150 dirección MAC xx:yy:zz:55:38:C3
IP puerta de enlace: 192.168.6.1 dirección MAC rr:ss:tt:C0:00:08

Primero, veamos el desarrollo del ataque sin utilizar ArpON:

$ ettercap -T -M arp /192.168.6.150/ /192.168.6.1/

Una vez lanzado el ataque, podremos consultar la caché ARP de la víctima y comprobar que en dicha tabla, la dirección mac correspondiente a la puerta de enlace (192.168.6.1) es en realidad la dirección mac del atacante (:::EC:D4:B9). En la siguiente imagen podemos ver la salida de ettercap al lanzar el ataque:

Observamos el cambio en la caché ARP antes y después del lanzar el ataque.
Antes:
Después:

En este instante la víctima enviará al atacante, sin saberlo, todos los paquetes con destino a la puerta de enlace.

- Veamos qué sucede cuando se lanza el mismo ataque pero ArpON está en funcionamiento:

Ejecutamos ArpON en el pc que deseamos proteger en modo dinámico (DARPI):

$./arpon -i eth0 -y

Observamos que lo primero que hace es borrar todas las entradas de la caché ARP. En este caso, la tabla contenía entradas de las direcciones IP 192.168.6.1, 192.168.6.2 y 192.168.6.254:

Si en ese momento consultamos la caché ARP obtenemos que está vacía:

ArpON nos permite observar las acciones que va realizando en cada momento, si el atacante lanza el mismo ataque que antes, observamos lo siguiente:

Al recibir los paquetes ARP reply envenenados del atacante, observamos que al no encontrar la dirección origen en la caché DARPI, inmediatamente elimina esta entrada de la caché ARP. Este proceso lo repetirá para cada paquete ARP reply envenenado que reciba:

Veamos ahora qué sucede cuando se recibe una petición ARP válida y cómo comprueba que no está enveneada. En este caso será un host con IP 192.168.6.136 (xx:yy:zz:34:F4:F4) el que se comunicará con la víctima.

1. Recibe un paquete ARP request de la 192.168.6.136
2. Al no encontrar la dirección origen del paquete en la caché DARPI borra la entrada de la caché ARP
3. Añade la dirección origen a la caché DARPI y lanza un ARP request a esta dirección
4. Recibe la respuesta (un paquete ARP reply) y esta vez sí que se encuentra la dirección origen en la caché DARPI, por tanto borra esta entrada de la caché DARPI y la añade a la caché ARP

Google-Hacking con Metagoofil

2008-04-24T01:35:00.000-07:00

La recopilación de información es la primera fase en la evaluación de seguridad. un paso necesario en una prueba de intrusión. Se centra en recoger tanta información como sea posible sobre una aplicación objetivo.

Metagoofil es una herramienta que se encarga de extraer Meta-Datos de ciertos ficheros accesibles en los websites.

Los ficheros que utiliza son los clasicos utilizados en ofimática PDF,PPT,DOC,XLS y MDB

La manera de operar de la herramienta se basa en realizar búsquedas en Google (Google-Hacking) dentro del dominio del Objetivo, y solo de los ficheros con formatos concretos.

Una vez identificados los ficheros, se bajan de la web a nuestra máquina donde Metagoofil extraerá la informacion interesante, por último genera un HTML con los resultados.

De esta forma tenemos una fuente más de donde extraer usuarios potenciales de los sistemas objetivos.

Seguir Leyendo...

Esta herramienta utiliza libextractor para obtener la meta-información de los archivos. Tendremos que instalarla aparte.

Acaba de publicarse la nueva versión de esta herramienta (MetaGooFil 1.4 - 20/04/2008) que obtiene la dirección MAC de los documentos Microsoft Office.
Es capaz de obtener:
Nombres de usuario, rutas de los archivos y direcciones MAC.

Otro punto más que proteger por parte de los responsables de seguridad.

Enlaces:
http://www.edge-security.com/metagoofil.php
http://www.s21sec.com/metagoofil/metagoofil.html

Certificados digitales

2008-04-11T02:58:00.000-07:00

Un certificado digital es una versión "firmada" o verificada de una clave pública.
Los certificados digitales siguen el estándar X.509 para definir su formato. Las extensiones de estos certificados pueden ser:

.P7b - Estructura PKCS#7. Usado para firmar y/o cifrar mensajes (contiene sólo la clave pública).
.Pfx - Estructura PKCS#12. Puede contener claves públicas y claves privadas (protegido mediante clave simétrica)
.CER - Certificado codificado en CER, algunas veces es una secuencia de certificados
.DER - Certificado codificado en DER
.PEM - Certificado codificado en Base64, encerrado entre "-----BEGIN CERTIFICATE-----" y "-----END CERTIFICATE-----" Puede contener claves privadas o públicas.

Nota: Cuando queremos exportar un certificado, si elegimos el formato PKCS#7 sólo estaremos exportando la clave pública, por en contrario, si elegimos el formato PKCS#12 también estaremos exportando la clave privada.

A la hora de utilizar certificados digitales en una infraestructura PKI para fortificar las comunicaciones en internet, las organizaciones disponen de dos opciones:

Seguir Leyendo...

1ª Utilizar un certificado raiz de confianza autofirmado
Una organización puede optar por crear su propia CA para firmar sus propios certificados digitales. Esta CA poseerá un certificado raiz o certificado autofirmado que cada navegador que acceda a un portal bajo SSL deberá añadir previamente a su lista de certificados de confianza, si no lo hace, cada vez que se intente acceder a ese recurso, el navegador devolverá un error de certificado. Más adelante veremos por qué.
Se dice que es un certificado autofirmado porque que el propietario y el emisor son la misma entidad.

2ª Utilizar un certificado firmado por una Autoridad de Certificación, solicitando y pagando por la firma de una entidad certificadora reconocida. De esta forma, la CA es la responsable de asegurar que la identidad del propietario del certificado es auténtica. En este caso los navegadores no necesitan instalar ningún certificado raiz de la CA ya que al ser una Autoridad Certificadora reconocida, estos certificados raiz ya se encuentran instalados por defecto en los navegadores.

Procedimiento de adquisición de un certificado digital:

- Cuando una organización desea solicitar un certificado de seguridad para utilizarlo, por ejemplo, en un servidor web protegido con SSL, primero debe realizar una solicitud de certificado o CSR (Certificate Signing Request). Una CSR consiste en generar un "pre-certificado" (pre-certificado porque no está firmado aún) con los datos de la entidad solicitante: nombre de la organización, correo, DN Distinguished Name (dato de mucha importancia ya que identificará el dominio sobre el que se alojará el recurso) entre otros. Cuando se crea una CSR se obtiene dos ficheros:
cert.pem -> pre-certificado
key.pem -> clave privada que utilizará el servidor web para futuros handshake de SSL

- La CA recibe la solicitud de certificado y comprueba que los datos que contiene se corresponden realmente con la entidad que lo solicita (cada CA utiliza sus propios metodos). Una vez comprobado, la CA crea una firma a partir de su llave privada y los datos del "pre-certificado" y genera un certificado ya firmado y definitivo y lo hace llegar a la organización que lo solicitó.

Una vez la organización reciba el certificado ya firmado, deberá instalar este certificado en su servidor web.
Ejemplo de configuración del fichero httpd.conf de apache:


...
SSLEngine on
SSLCertificateFile /etc/httpd/conf/certificado-firmado.pem

<- certificado ya firmado
SSLCertificateKeyFile /etc/httpd/conf/key.pem <- clave privada que obtuvimos cuando generamos la CSR. ...

A continuación se muestra el proceso de negociación o Handshake entre el cliente y el servidor:

Hacer click sobre la imagen para agrandar

Autenticación a un servidor SSH utilizando cifrado asimétrico

2008-04-09T05:00:00.001-07:00

Vamos a configurar el método de autenticación a un servidor con Windows y freeSSHd instalado, utilizando el cliente putty y un sistema de cifrado de clave pública.

- Generamos nuestro par de claves:
Abrimos el PuTTy Key Generator (puttygen.exe) y puslamos sobre "Generate". Nos pide que generemos información aleatoria moviendo el cursor sobre la zona gris.
Copiamos el texto que viene en la sección "key" en un editor de texto, por ejemplo bloc de notas. Lo guardamos en el directorio donde el servidor de ssh freeSSHd guarde las claves públicas. Este directorio es por defecto "C:\Archivos de programa\freeSSHd\" y se puede modificar en la pestaña "Authentication". Este documento lo guardamos con el nombre del usuario que tengamos para el freeSSHd. Este usuario deberá tener configurado como método de autorización "Public key (SSH only)"; lo comprobamos en la pestaña "Users" seleccionando un usuario y pulsando sobre el botón "Change". Por otra parte, tendremos que tener a "Allowed" o "Required" el parámetro "Public key authentication" en la configuración del freesshd para que nos permita este tipo de autenticación. Volvemos al PuTTy Key Generator y puslamos sobre "Save private key" para guardar la llave privada en un lugar seguro (en el cliente).
Podemos utilizar passphrase o no para guardarla, si elegimos que sí, cuando intentemos conectar nos la pedirá.

Seguir Leyendo...

- Probamos a conectarnos.
Abrimos putty en el cliente y nos vamos a Connection -> SSH -> Auth, y en la sección "Authentication parameters", indicamos la llave privada que usaremos para autenticarnos. Elegimos la que hayamos guardado con el PuTTy Key Generator.

- Podemos utilizar Pageant.exe para que gestione automáticamente las claves privadas que utilizaremos para autenticarnos:
Ejecutamos pageant.exe y nos coloca en la barra de sistema un icono, cuando hacemos doble click sobre él nos abre una ventana donde aparecen listadas las claves privadas que contiene. La prmiera vez aparecerá vacía y tendremos que añadir las claves privadas pulsando sobre "Add key", si la clave tiene passphrase asociada nos la pedirá en ese momento. Al arrancar putty, detectará automáticamente que pageant está funcionando y utilizará las llaves privadas que contenga. Cuando haya varias, putty probará una por una hasta que encuentre alguna que corresponda con la cabe pública del usuario que esté logeando en el servidor.

NOTA: Si no queremos que nos pida usuario al conectar, podemos añadir un usuario por defecto en "Auto-login username" en Connection -> Data.

- Si ya tenemos un par de claves generadas con freeSSHd, para utilizarlas, tan solo tendremos que pulsar sobre el botón "Load" en el PuTTy Key Generator, seleccionar "All files (*.*)" en "Tipo:" y abrir la llave privada .rsa o .dsa. Una vez abierta, tendremos que volver a repetir los mismos pasos que si las hubieramos generado directamente con el puttygen.exe, es decir, guardar la llave pública con el nombre del usuario y la privada con extensión ppk.

- Si tenemos un par de claves generadas con OpenSSH (utilizando por ej. el comando # ssh-keygen -t dsa), seguiremos el mismo proceso importando la clave privada en el puttygen.exe y guardándola en formato ppk.

Secunia Software Inspector

2008-03-28T05:29:00.000-07:00

Secunia ofrece un servicio gratuito que puede resultar muy útil para mantener correctamente parcheado y actualizado todo el software de nuestra máquina. Ofrece la posibilidad de realizar un análisis símplemente accediendo a la web y descargando un applet (cuya firma es verificada correctamente).
Secunia analiza los programas instalados y detecta los que se encuentran desactualizados y por tanto pueden resultar inseguros. Nos facilita también información sobre la vulnerabilidad concreta a la que está expuesta la versión oboleta del software instalado.

Nos permite además descargarnos (de nuevo, de forma gratuita) el software a nuestra máquina para instalarlo, y realizar así un análisis más exhaustivo. Al finalizar el análisis, nos presenta un informe en el que nos detalla las alertas de cada software instalado junto con la versión vulnerable de cada programa, además de un enlace directo a la actualización recomendada correspondiente.

Secunia Software Inspector

SPA (Single Packet Authorization) con fwknop

2008-03-25T08:33:00.000-07:00

En este artículo se pretende hacer una introducción al concepto de ‘port knocking’ (técnica que se puede usar como complemento para securizar servicios que se encuentren detrás de un firewall) y más concretamente a una de sus variantes, ‘Single Packet Authorization’ (SPA), mediante un ejemplo práctico guiado paso a paso utilizando fwknop, una implementación de SPA de código abierto, bajo sistemas linux.

Introducción a Port Knocking

En informática, port knocking es un método utilizado para abrir puertos en un firewall mediante un conjunto de intentos de conexión lanzados sobre puertos cerrados. Cuando en el servidor se recibe la secuencia correcta de conexión, las reglas del firewall son modificadas dinámicamente para permitir al host que envió los paquetes conectar a un puerto/s específico/s.

El principal objetivo de port knocking es prevenir escaneos de puertos a un determinado equipo para evitar potenciales ataques a servicios vulnerables. Esto se consigue ya que, a menos que se envíe la secuencia de knocks correcta, los puertos aparecerán como cerrados para cualquiera que lance un escaneo sobre el equipo. Un 'port knocking' es similar a un handshake y consiste en una serie de paquetes TCP, UDP o incluso ICMP dirigidos cada uno a un puerto concreto en la máquina destino. La complejidad del 'knock' puede ir desde una simple lista de paquetes protocolo-puerto hasta un complejo hash encriptado controlado según IP origen y/u otros factores.

Ejemplo: Un demonio sshd configurado por defecto escuchará en el puerto 22. Configuramos el firewall para que cierre el puerto 22 y elegimos como secuencia de 'knocks' la sucesión TCP-100, UDP-200, TCP-300 que habilitará el puerto 22 en la máquina. El puerto permanecerá cerrado hasta que un usuario intente inicializar conexiones TCP y UDP hacia los puertos 100, 200 y 300 en ese mismo orden. En este caso, el puerto se abrirá durante un intervalo de tiempo determinado. En caso contrario, el usuario recibirá un paquete RST/ACK cuando inicialice conexiones TCP hacia el puerto22.

Pero Port Knocking tiene algunas debilidades:

Seguir Leyendo...

- Un atacante que no conozca la secuencia de 'knocks', mediante fuerza bruta, podría llegar a obtener la secuencia requerida para habilitar un determinado servicio.

- Monitorizando las comunicaciones, un atacante podría intentar detectar una secuencia de puertos para reproducirla posteriormente contra el servidor para conseguir acceso al servicio protegido.

- Las secuencias de port knock pueden ser encriptadas y existen diversas implementaciones que se pueden encontrar en www.portknocking.org. Pero cada paquete enviado puede contener sólo dos bytes de información debido al tamaño de 16 bits que tienen los campos de los puertos en las cabeceras TCP y UDP. Por tanto, para enviar una secuencia cifrada, utilizando por ejemplo un algoritmo simétrico de 128 bits, una secuencia de port knock estaría formada por 128/16=8 paquetes. Aquí nos encontramos con un posible problema de entrega desordenada de paquetes ya que en este caso no hay una conexión cliente-servidor (tipo TCP). Se puede añadir un retardo de medio segundo para evitar este problema, y en este caso el tiempo de entrega de la secuencia llegaría a 4 segundos. Pero si se decide utilizar algoritmos de cifrado asimétricos, la cantidad de bits a enviar es más grande y el tiempo de entrega de estos paquete se vuelve excesivo e inviable. Esto puede resultar una gran desventaja del port knocking.

Conclusión: Port knocking provee algunas ventajas que aumentan las seguridad, pero también tiene algunas limitaciones serias que hay que tener en cuenta. SPA (Single Packet Authorization) es un protocolo relativamente nuevo que mantiene los beneficios del port knocking pero soluciona algunas de las limitaciones del mismo.
Las primeras noticias que se tuvo de la implementación de SPA surgieron en Mayo de 2005 como una parte de un software llamado fwknop www.cipherdyne.org/fwknop.

Descripción de SPA (Single Packet Authorization)

SPA es una variante del port knocking donde sólo un 'knock' es necesario para validar la petición. Éste 'knock' consiste en un paquete encriptado.
SPA ofrece una arquitectura similar a la del port cknocking:

Ambos sienen componentes cliente y servidor,
El servidor matiene el control de filtrado por defecto a DROP
El servidor monitoriza paquetes de forma pasiva.

Pero aquí es donde acaban las similitudes.

La principal ventaja que ofrece SPA es que la cantidad de información que puede ser incluída en el paquete sólo se encuentra limitada por el MTU. Esta ventaja permite que mediante SPA se pueda incluir en el paquete no sólo información de acceso, sino también por ejemplo, comandos que sean ejecutados en el sevidor SPA.

En definitiva, SPA provee un nivel de seguridad similar al port knocking en términos de proteger un servicio con un filtrado de paquetes en un sistema con una política por defecto de INPUT a DROP. En este entorno, cualquiera que realice un escaneo a la máquina no sería capaz de detectar si un servicio está realmente activo en ella, lo cual dificulta la explotación de muchas vulnerabilidades. SPA ofrece una solución elegante las limitaciones del port knocking.

Vamos a ver mediante un ejemplo práctico, cómo utilizar fwknop en modo Single Packet Authorization para proteger y ofrecer acceso al demonio OpenSSH.
- fwknop define el siguiente formato de paquete en la capa de aplicación:

16 bytes de datos aleatorios
Nombre del usuario cliente
Timestamp del cliente
Version fwknop
Modo (acceso or comando)
Acceso (o una cadena de comando)
Resumen MD5 /SHA

Una vez que el cliente fwknop contruye el paquete con los campos arriba indicados, el paquete entero es encriptado usando un algoritmo de clave simétrica (128 bits) o asimétrica (utilizando GnuPG con una longitud de clave de 1024 - 4096 ). Por defecto, el cliente enviará un paquete UDP al puerto 62201, aunque esto se puede modificar fácilmente (mediante el uso del parámetro --Server-port)

A continuación se muestra un ejemplo de instalación, configuración y prueba de fwknop:

Tendremos que tener instalado GnuPG tanto en el servidor como en el cliente.

- Instalamos el servidor OpenSSH


# apt-get install openssh-server

- Instalamos los requisitos para fwknop:


# apt-get install build-essential libpcap-dev mailx

- Instalamos fwknop en el servidor:
En este caso, hemos instalado la versión 1.9.2 del 12 de Marzo de 2008

# wget http://www.cipherdyne.org/fwknop/download/fwknop-1.9.2.tar.gz
# tar zxvf fwknop-1.9.0.tar.gz
# cd fwknop-1.9.0
# sudo ./install.pl

- Nos hace una serie de preguntas a las cuales se ha contestado lo siguiente:

In which mode will fwknop be executed on the local system?
(client/[server]): server

Which of the following data acquistion methods would you like to use?
([pcap], file_pcap, ulogd, syslogd, syslog-ng): pcap

Which network interface would you like fwknop to sniff packets from? eth0

Enable fwknop at boot time ([y]/n)? y

- Podemos añadir fwknop al arranque del sistema:


# update-rc.d fwknop defaults 20

- Instalamos fwknop en el cliente:


# apt-get install build-essential libpcap-dev mailx

# wget http://www.cipherdyne.org/fwknop/download/fwknop-1.9.2.tar.gz (12 Mar 2008)

# tar zxvf fwknop-1.9.0.tar.gz

# cd fwknop-1.9.0

# sudo ./install.pl

En este caso, contestamos con las mismas respuestas excepto que indicamos que se instale como cliente.

- Generamos par de claves en el cliente:

# gpg --gen-key

- Nosotros elegimos las siguientes opciones:

Tipo -> DSA
Tamaño -> 2048
Periodo -> La clave no caduca nunca
Nombre y apellidos: client fwknop
Correo: cf@cf.com

- Obtenemos:

pub   1024D/A174FC70 2008-03-24

uid                  Server fwknop

sub   2048g/3220AE91 2008-03-24

- Exportamos la clave a un fichero

# gpg -a --export A174FC70 > fwknop-client.asc

- Generamos par de claves en el servidor:

# gpg --gen-key

Tipo -> DSA
Tamaño -> 2048
Periodo -> La clave no caduca nunca
Nombre y apellidos: Server fwknop
Correo: sf@sf.com

- Obtenemos:


pub   1024D/D417D41A 2008-03-09
uid                  Server fwknop 
sub   2048g/F5F02C2B 2008-03-09

- Exportamos la clave a un fichero:

# gpg -a --export D417D41A > fwknop-server.asc

Copiamos los ficheros respectivos en las máquinas e importamos las claves.

- Importamos la clave del servidor en el cliente:

# gpg --import fwknop-server.asc

# gpg --sign-key sf@sf.com

- Importamos la clave del cliente en el servidor:

# gpg --import fwknop-client.asc

# gpg --sign-key cf@cf.com

- Finalizando la instalación:

- Editamos /etc/fwknop/access.conf:


SOURCE: ANY;
OPEN_PORTS: tcp/22;
DATA_COLLECT_MODE: PCAP;
GPG_HOME_DIR: /root/.gnupg;
GPG_DECRYPT_ID: D417D41A;
GPG_DECRYPT_PW: password para la llave D417D41A;
GPG_REMOTE_ID: A174FC70;
FW_ACCESS_TIMEOUT: 30;

- Iniciamos fwknop:

# /etc/init.d/fwknop start

- Prueba de funcionamiento:

- Ejemplo de sintaxis:


fwknop -a 'puertos' --gpg-recip SERVER_KEY --gpg-sign CLIENT_KEY -s -D SERVER_IP

Con -s indicamos que el servidor SPA utilice la ip de origen de la cual recibió el paquete para crear la regla.En lugar de -s se puede utilizar -w que realizará una petición a www.whatismyip.com para averiguar la ip origen

- Probamos con:

# fwknop -a 'tcp/22' --gpg-recip D417D41A --gpg-sign A174FC70 -s -D 192.168.6.137

- Si todo ha ido bien, el servidor añade la entrada correspondiente a iptables. Ésta se mantendrá durante 60 segundos, después de los cuales se eliminará automáticamente.
En este caso, nos crea una regla que permite a la IP 192.168.6.137 conexiones tcp al puerto 22.

- Podemos comprobar que todo ha ido bien consultando los logs en el servidor SPA:

# tail -f /var/log/syslog | grep fwknop

- Y cuando se acabe el tiempo disponible para realizar la conexión:

- Podemos consultar las reglas iptables en tiempo real con:

# watch -n1 iptables -L -n

NOTA:
fwknop crea una nueva una nueva cadena en iptables llamada FWKNOP_INPUT y la cadena INPUT hace referencia a ésta.
En el servidor probamos poniendo la política INPUT del iptables por defecto a DROP pero no la cadena OUTPUT. Hay que tener en cuenta que fwknop, por defecto, sólo añade reglas a FWKNOP_INPUT. También se puede habilitar en fwknop.conf para que se cree utilice la cadena
FWKNOP_OUTPUT y así se creará reglas para permitir tráfico OUTPUT.

- Para que se mantenga la conexión SSH que hayamos establecido durante el tiempo permitido, tendremos que tener en iptables una regla que permita las conexiones ya establecidas. Si no, la conexión quedará cortada cuando fwknop elimine la regla correspondiente. En nuestro caso, hemos añadido:


# iptables -A INPUT -p tcp -i eth0 -m state --state ESTABLISHED, RELATED -j ACCEPT

Referencias:

http://www.hispasec.com/unaaldia/3382

http://www.cipherdyne.org/fwknop/

http://mscoder.org/en/haking/articles_html.html

https://help.ubuntu.com/community/SinglePacketAuthorization

FreeRADIUS + MySQL

2008-03-17T02:51:00.001-07:00

FreeRADIUS + MySQL
Gestión de usuarios

En el siguiente manual, vamos a ver cómo utilizar el gestor de bases de datos MySQL para administrar usuarios y grupos de usuarios de un servidor de autenticación RADIUS.

Instalamos mysql


# apt-get install mysql mysql-sever-4.1
# apt-get install freeradius-mysql

Creamos la base de datos para utilizar con radius:


mysql> create database radius;
mysql> grant all privileges on radius.* to radius@localhost;
mysql> set password for radius@localhost = old_password('radius');

Ejecutamos el script para generar tablas y demás:
primero descomprimimos en /usr/share/doc/freeradius/examples/mysql.sql


# gzip -d mysql.sql.gz
# mysql -u root -p radius < /usr/share/doc/freeradius/examples/mysql.sql

Creamos un usuario para ver si funciona:

Seguir Leyendo...

Las tablas que usa RADIUS para la gestión de usuarios son las siguientes:

usergroup: Aquí se define a qué grupo pertenece cada usuario.
Campos:

id. Identificador de registro.
UserName. Nombre de usuario.
GroupName. Grupo al que pertenece el usuarios

radcheck: Aquí se definen las contraseñas de cada usuario.
Campos:

id. Identificador de registro.
UserName. Nombre de usuario.
Attribute. Tipo de contraseña. En nuestro caso, ‘User-Password’.
Op. Es el operador que se usará para la comprobación. Para nosotros ‘==’.
Value. La contraseña.

radreply: En esta tabla se definen los atributos sobre la conexión y sesión de los usuarios; por ejemplo, IP asignada y tiempo de espera máximo. En nuestro caso, permitimos que se asignen los de DEFAULT contenidos en el archivo ‘users’; por lo tanto, no insertamos nada en la tabla.

radgroupreply: Similar a radcheck pero permite establecer atributos a un grupo de usuarios completo.
Campos:

id. Identificador de registro.
GroupName. Nombre de grupo.
Attribute. Nombre del atributo que se quiere agregar.

Nosotros sólo hicimos uso de uno, el tipo de autenticación: ‘Auth-Type’.
Op. Es el operador que se usará para la comprobación. Para nosotros ‘:=’.
Value. El valor del atributo. Nuestro Auth-Type es ‘EAP’.

Creamos usuario usuario_admin en el grupo admin:


mysql> insert into usergroup values ('usuario_admin','admin','');

Añadimos la contraseña para el usuario admin:


mysql> insert into radcheck values ('','usuario_admin','Password','==','[password]');

Añadimos el atributo local al grupo admin: (no es necesario)


mysql> insert into radgroupcheck values ('','admin','Auth-Type',':=','local');

Esteblecemos atributos del grupo admin


mysql> insert into radgroupreply values ('', 'admin', 'Framed-Protocol', ':=', 'PPP');
mysql> insert into radgroupreply values ('', 'admin', 'Service-Type', ':=', 'Framed-User');
mysql> insert into radgroupreply values ('', 'admin', 'Framed-Compression', ':=', 'Van-Jacobsen-TCP-IP')

Configuramos RADIUS para que gestione los ususarios con MySQL:
Editamos /usr/local/etc/raddb/clients.conf y configuramos las IPs o subrredes desde las que se aceptarán peticiones. En este caso, además de localhost, se aceptarán peticiones de un AP con IP 192.168.6.1:


client 127.0.0.1{
ipaddr = 127.0.0.1
secret = secretradius
shorname = AP
nastype = other
}
client 192.168.6.1{
ipaddr = 192.168.6.1
secret = secretradius
netmask = 32
shortname = windows
nastype = other
}

Ahora editamos /usr/local/etc/raddb/clients.conf para indicar a RADIUS IP del servidor MySQL, usuario y password:


# Connect info
server = "localhost"
login = "radius"
password = "password_basededatos"

# Database table configuration
radius_db = "radius"

A continuación editamos /usr/local/etc/raddb/sites-avaliable/default y terminamos de configurar los parámetros necesarios:


authorize {
preprocess
chap
mschap
suffix
eap
sql
}

authenticate {
Auth-Type PAP {
                pap
}
Auth-Type CHAP {
                chap
}
Auth-Type MS-CHAP {
                mschap
}
}
preacct {
preprocess
acct_unique
suffix
}

accounting {
detail
radutmp
sql
}

session {
radutmp
sql
}

post-auth {
sql
}

pre-proxy {
}

post-proxy {
eap

}

Si el servidor mysql está en otro host, en /etc/mysql/my.cnf parcheamos la linea bind-address=127.0.0.1

(Al arrancar el servicio radiusd -X me daba error con el puerto 1812 y he tenido que detener los servicios smb)

A mí me ha dado error en una tabla y he tenido que modificar las columnas de la tabla radpostauth:


mysql> alter table radpostauth change user username varchar(64);
mysql> alter table radpostauth change date authdate timestamp;

En el sql.conf he desparcheado el parámetro read_groups y lo he puesto a "no" porque me daba error con una tabla que no existía que hacía referencia a los grupos

Para exportar/importar bade de datos (por si hicera falta):
Para exportar la base de datos radius:


# mysqldump -u [user] -p --opt [nombre_db] > fichero.sql

Para importarla:
Primero la creamos


# mysql -u [user] -p
mysql> create database radius;
mysql> \q
# mysql -u [user] -p [nombre_db] <>

Podemos instalar phpmyadmin para gestionar MySQL


# apt-get install phpmyadmin

Yo he tenido un problema con la configuración y he tenido que hacer lo siguiente:
He cambiado el fichero /var/www/phpmyadmin/config.inc.php porque me daba un error de blowfish, lo que he hecho es cambiarlo por config.sample.inc.php y en este último he borrado el valor del parámetro "controluser" y el de "controlpass" y los he dejado vacíos.
Así ya me ha funcionado.

Podremos instalar phpmyadmin para gestionar via web MySQL y poder administrar los usuarios más fácilmente:


# apt-get install phpmyadmin

Nos muestra un asistente durante la instalación para configurar phpmyadmin automáticamente. Primero nos pregunta qué servidor web esatmos utilizando, en nuestro caso indicamos apache2 (aunque es altamente recomendable utilizar apache-ssl).
Indicamos el usuario para el sitema de configuración ("admin" por defecto) e indicamos la contraseña.
Reiniciamos apache y accedemos desde un navegador a https://[ip_servidor]/phpmyadmin
Cuando accedemos, podremos encontrarnos con un error que nos dice que necesitamos configurar una clave secreta blowfish (algoritmo de cifrado simétrico que utiliza una passprhase para encriptar el password)
En realida lo que tenemos que hacer es modificar los permisos de los ficheros:
/etc/phpmyadmin/blowfish_secret.inc.php
/etc/phpmyadmin/htpasswd.setup

Es recomendable cambiar la passphrase que viene por defecto ya que por defecto les asigna el grupo www-data y nosotros usamos el usuario y grupo httpd:


# chown root:httpd blowfish_secret.inc.php
# chown root:httpd htpasswd.setup

Ya podemos acceder con un usuario que tenga privilegios en la base de datos. Por ej. root.

Ahora desde phpmyadmin podremos añadir usuarios.
Sólo hay que añadir un registro en usergroup y otro en radcheck por cada usuario (ver imagen).

Instalación y configuración de SNORT en sistemas basados en Debian

2008-03-14T06:39:00.000-07:00

SNORT es un sistema open source de detección de intrusos (IDS) y un sistema de prevención de intrusos (IPS) capaz de realizar análisis en tiempo real de tráfico en redes IP. Actualmente se encuentra desarrollo por parte de Sourcefire.

SNORT realiza análisis de portocolos y es usado habitualmente para boquear o detectar gran variedad de ataques y pruebas como buffer overflows, escaneos de puertos, ataques a aplicaciones web, intentos de OS fingerpirnting, etc.

Este manual, es una adaptación del documento "11 step guide to build a Debian based Intrusion
Detection Sensor (IDS) with Snort 2.4.5 or Snort 2.6" que se puede encontrar en www.snort.org

Solución basada en Snort+MySQL+PHP+BASE+Apache-SSL.
Se ha utilizado una versión estable Debian 2.6.

Instalamos todos los paquetes necesarios para esta guía:


# apt-get update
# apt-get install ssh
# apt-get install apache-ssl apache-common libapache-mod-php4 \
mysql-server mysql-common mysql-client php4-mysql \
libnet1 libnet1-dev libpcre3 libpcre3-dev autoconf automake1.9 \
libpcap0.8 libpcap0.8-dev libmysqlclient15-dev \
php4-gd php4-pear libphp-adodb vim gcc make \
php4-cli libtool libssl-dev gcc-4.1 g++

Al instlar el apache-ssl nos pedirá los parámetros para configurar el certificado que usará.

A continuación se nos sugiere instalar el firewall lokkit por su sencillez. Obviamos este paso.

Descargamos e instalamos SNORT:

Seguir Leyendo...

Instalamos en este caso la versión 2.8.0.1 (28 de Noviembre de 2007)
La última versión estable a día 12 de Marzo es 2.8.0.2 (19 de Febrero de 2008) y la podemos descargar desde: http://www.snort.org/dl/current/snort-2.8.0.2.tar.gz


# cd /usr/local/src
# wget http://snort.org/dl/old/snort-2.8.0.1.tar.gz
# tar xvzf snort-2.8.0.1.tar.gz
# cd snort-2.8.0.1
# ./configure --with-mysql --enable-dynamicplugin
# make
# make install

Instalamos y configuramos las reglas:
Las reglas VRT (Sourcefire Vulnerability Research Team), son las reglas que desarrolla el equipo de soporte de SNORT. Hay tres tipos de reglas VRT que podremos encontrar en el portal www.snort.org.

Reglas para suscriptores. Es decir, de pago. Permanentemente actualizado.

Reglas para usuarios registrados (basta con crearse una cuenta).

Reglas disponibles para usuarios no registrados. Muy desactualizadas.

Por otra parte, hay un grupo de reglas de la comunidad. Son reglas que gente de todo el mundo va desarrolando y envía a snort para que las publiquen.

Descargamos las reglas para la versión 2.8 (tipo 2 :)) en http://www.snort.org/pub-bin/downloads.cgi
Nos registramos y generamos un oink-code -> ...64188359a0f2248... para poder descargarlas.
En este caso las hemos descargado en el directorio /root:


# cd /etc/snort
# mv /root/snortrules-snapshot-2.8.0.1.tar.gz .
# tar xvzf snortrules-snapshot-2.8.0.1.tar.gz   MD5 -> 61b7818176609e8753bb10b98ae9a820
# cp /usr/local/src/snort-2.8.0.1/etc/*.conf* .
# cp /usr/local/src/snort-2.8.0.1/etc/*.map .

Configuramos /etc/snort/snort.conf:


var RULE_PATH /etc/snort/rules
var HOME_NET 192.168.1.0/24
var EXTERNAL_NET !$HOME_NET

Podemos crear una regla sencilla para comprobar... (ToDo)

Levantamos snort con:


# /usr/local/bin/snort -Dq -u snort -g snort -c /etc/snort/snort.conf

-c fichero de configuración
-D Ejecuta Snort en modo demonio
-g Indica el grupo (elimina privilegios de root a Snort después de terminar su inicialización)
-q Modo Quiet. No muestra información de inicialización ni banner.

Si tenemos apache2 previamente instalado, podemos tener problemas entre el apache2 y apache-ssl

Configuramos MYSQL:
Ponemos password a root de mysql si no lo tiene ya:


# mysqladmin -u root password "password"

Iniciamos mysql:


# mysql -u root -p

Creamos la BD snort:


mysql> create database snort;

Creamos un usuario "snort" en la BD y le asignamos permisos:


mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort@localhost;

Le asignamos un password.


mysql> SET PASSWORD FOR snort@localhost=PASSWORD('password');

Ejecutamos el script que creará las tablas de la BD snort:


# cd /usr/local/src/snort-2.8.0.1/schemas
# mysql -u root -p <>

Configuramos snort para que utilice mysql:
Editamos /etc/snort/snort.conf y buscamos, descomentamos y configuramos la linea:


output database: log, mysql, user=snort password=mipass dbname=snort host=localhost

Reiniciamos snort


# kill -9 pid

Hacemos un escaneo a la máquina con nmap por ej. y comprobamos que ha guardado algún evento con:


# mysql -u root -p -D snort -e "select count(*) from event"

Configuramos apache-ssl:
Si tenemos apache2 instalado, deberemos eliminarlo del arranque.
Para ésto, podemos poner:


# update-rc.d -f apache2 remove

Editamos /etc/apache-ssl/httpd.conf
Buscamos y descomentamos:


AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps

Editamos /etc/php4/apache/php.ini y descomentamos:


extension=mysql.so

Reiniciamos apache:


/etc/init.d/apache-ssl restart

Instalamos BASE (Basic Analysis and Security Engine. Front-end web para analizar alertas del snort):


# cd /var/www
# rm index.html (opcional)
# wget http://internap.dl.sourceforge.net/sourceforge/secureideas/base-1.2.5.tar.gz
# tar xvzf base-1.2.5.tar.gz
# mv base-1.2.5 base
# chmod 777 base

Abrimos un navegador y escribimos en la barra de direcciones https://[ip_servidor]/base
Pulsamos continue, elegimos idioma y ponemos como path del adodb -> /usr/share/php/adodb
Pulsamos "continue".

Introducimos los siguientes parámetros:


Database Name: snort
Database Host: localhost
Database Port: (en blanco para puerto por defecto)
Database User Name: snort
Database Password: pass

Pulsamos "continue":

Introducimos usuario -> root y su contraseña, y nada más (tampoco marco el check).

Pulsamos "continue":
Pulsamos sobre el botón "create baseag" y nos informa de si se ha creado todo correctamente.
Pulsamos "Ir al paso 5"

Y ya lo tenemos funcionando...

Cambiamos permisos al directorio base:


# chmod 755 /var/www/base

Para que funcionen las gráficas:
Cambiamos el siguiente enlace:


# rm /etc/alternatives/php
# ln -s /usr/bin/php4 /etc/alternatives/php

Ejecutamos:


# pear config-set preferred_state alpha

Editamos /etc/php4/cli/php.ini y descomentamos:


extension=gd.so

Ejecutamos:


# pear install Image_Color
# pear install Image_Canvas
# pear install Image_Graph

Reiniciamos apache-ssl.

Barnyard (programa para procesar logs de eventos de forma unificada, mejora el rendimiento de snort y proporciona tolerancia a fallos en caso de caída de la BBDD)
En este caso no lo instalamos.

Pasando del banyard

Configuramos actualizaciones de las reglas:
Descargamos e instalamos oinkmaster para que haga actualizaciones automáticas de las reglas:


# cd /usr/local/src
# wget http://internap.dl.sourceforge.net/sourceforge/oinkmaster/oinkmaster-2.0.tar.gz
# tar xvzf oinkmaster-2.0.tar.gz
# cd oinkmaster-2.0
# cp oinkmaster.pl /usr/local/bin
# mkdir /usr/local/etc
# cp oinkmaster.conf /usr/local/etc

Editamos /usr/local/etc/oinkmaster.conf y nos vamos a la linea:


#Example for Snort-current...

Y descomentamos la siguiente linea:


url = http://www.snort.org/pub-bin/oinkmaster.cgi/oinkcode/filename

Sustituimos [b]oinkcode[/b] por uno válido: ...64188359a0f22...

A continuación hacemos:


# mkdir /tmp/oinktest
# /usr/local/bin/oinkmaster.pl -o /tmp/oinktest

Si todo va bien nos descargará más reglas, las desempaquetará e instalará...

Podemos añadir una copia de seguridad de las reglas antes de instalarlas con la opción -b (sin probar)


# mkdir /tmp/OINKBACK por ej
# /usr/local/bin/oinkmaster.pl -o /tmp/oinktest -b /tmp/OINKBACK

Ésto, hará una copia de las reglas en OINKBACK antes de instalar las nuevas.

Creamos el script de inicio de SNORT:
Creamos y editamos /etc/init.d/snort
Añadimos al fichero lo siguiente:


#!/bin/bash
/sbin/ifconfig eth0 up
/usr/local/bin/snort -Dq -u snort -g snort -c /etc/snort/snort.conf -i eth1

Lo hacemos ejecutable:


#chmod +x /etc/init.d/snort-barn

Utilizamos update-rc.d will para crear los enlaces en los directorios rc?.d:

#update-rc.d snort defaults 95

Reiniciamos y comprobamos que todo funciona correctamente

FINE