Swatch (http://sourceforge.net/projects/swatch/) es un sistema para la monitorización de eventos del sistema que está escrita en Perl. Las 3 características que convierten a "Swatch" en un sistema potente a pesar de su simpleza son:
* Configuración rápida y sencilla contenida en uno o varios archivos "centralizados".
* Reporte instantáneo de los eventos registrados por swatch, bien por correo electrónico o bien por stdout (salida standard por pantalla).
* Permite personalizar la salida de los mensajes para una lectura más clara y cómoda.

Una de las cosas que mas valoro de swatch es que (a diferencia de sistemas como logwatch que solo se ejecutan a intervalos de tiempo regular) los reportes son instantáneos. Así estaremos informados al instante de todas las acciones que ocurran en nuestro sistema y eso en caso de algun tipo de intrusión está muy bien valorado pues aunque el proceso sea terminado (kill) tendremos ya esa pista indiscutible de que algo está pasando en nuestro sistema.

Configuración:

Como en casi en todas las configuraciones de este tipo de programas, lleva algo de tiempo crear una configuración 100% adaptable a nuestras necesidades y que muestro solo la información que estrictamente le indicamos.

La configuración se hace en un Debian Lenny con un kernel 2.6.24 parchedo y usando el gestor de paquetes apt, aunque claro está que esto no exime de que se pueda instalar en otro tipo de escenarios.

Cuando se instalan los paquetes de swatch (apt-get install swatch) hay que pasar inmediatamente a configurar el archivo de configuración el cual NO EXISTE. Esto puede despistar al administrador mas "novato" puesto que no tenemos un archivo base en el que basarnos para construir la configuración, la cual debemos empezarla de 0.
Lo más lógico sería crear el archivo: /etc/swatch.conf para mantener una compatibilidad con la ubicación de los demás archivos de configuración, aunque, en realidad no importa puesto que el archivo de configuración puede indicarse a la hora de invocar swatch con la opción "-c" o "--config-file".
Antes de empezar a hacer nada es conveniente centralizar TODOS los logs ASCII del sistema en uno solo por medio de syslog.conf.
La razón de hacer esto es que swatch solo permite revisar un archivo de log por medio de la opción "-t" o "--tail-file" así que o lanzamos varias instancias incluyendo los archivos de log que nos interesen o hacemos lo que antes comentamos (centralizar todo) de modo que solo tengamos que incluir el archivo central el cual podemos crear en syslog de la siguiente manera en: /etc/syslog.conf

*.* -/var/log/central

de modo que todos los mensajes con todas las facilities vayan a parar a "central".
Ahora para que surta efecto la nueva configuración reiniciamos syslog: kill -1
, de manera que ya tendremos nuestro archivo creado recibiendo todos los mensajes.
Ahora pasamos configurar el archivo de conf de swatch, /etc/swatch.conf (p.ej).

Para configurarlo podemos usar estas simples "directivas":
-echo: Escribe la incidencia por pantalla en negrita, en color rojo, subrayada, parpadeando ... ; ej- echo bold red
-bell: Hace sonar una campan a cada X veces ; ej- bell 5
-exec: Ejecuta el comando/script especificado; ej- exec iptables -A INPUT -j LOG
-pipe: Va de la mano de exec y se usa para ejecutar un comando justo despues de "exec" y permite mantenerlo en ejecución hasta que otro "pipe" se ejecute o hasta que swatch termine; ej- sh /root/report.sh $2 $3
-mail: Envía un correo electrónico con la coincidencia encontrada además de poder especificar el subject; ej- mail adress=swatch\@algo.com,subject=Logeando ...
-write: Envía mensajes a usuarios con la coincidencia; write nobody
-throttle/threshold: Especifica el número de repeticiones de un mensaje en caso de que este se repita muchas veces en muy poco tiempo (util para no inundar la pantalla de mensajes o e-mails con alertas sobre un posible ataque a nuestro servidor ssh).
Esta opción puede resultar algo compleja y confusa pero una vez que se entiende es fácil comprender la lógica; ej- throttle threshold=3,delay=0:1:0,key=$4

threshold track_by="ssh",type=limit,count=1,seconds=900

* track_by="palabra" -> Palabra que debe repetirse en el tiempo indicado.
* type= ->
[limit]: Repite la coincidencia un número de veces especificadas en "count" cada "seconds"
[threshold]: Repite la acción durante el tiempo especificado en "seconds".
[both]: Repite (1 sola vez) la coincidencia despues de varias coincidencias definidas en "count" ignorando las coincidencias ocurridas mientras dure "seconds".

-count -> Define una cantidad de veces (conteo).
-seconds -> El número de segundos que definen la accion.

-continue: Permite a swatch seguir comprobando si el patron especificado se ajusta con otros patrones.

Construyendo la configuración:

He de decir que para construir el archivo de configuración en swatch se deben usar expresiones regulares y si lo deseamos podemos usar la sintaxis de "awk" especificando previamente la siguiente opción "--awk-field-syntax" al invocar swatch.
Bien. La estructura de un archivo de configuración de swatch es la siguiente:

watchfor /{expresión regular}/

Fácil. Veamos un ejemplo muy sencillo:

watchfor / Accepted password for /
echo green


Este es un ejemplo muy simple. Lo que hacemos es imprimir en pantalla la línea coincidente con "Accepted password for" que en este caso sería: Oct 24 20:17:21 arkan0id sshd[2690]: Accepted password for root from 192.168.1.10 port 52817 ssh2 , de color verde porque puse: echo green ;)

Otro ejemplo mas complicado
watchfor /(: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=(.*) user=(.*)$)/
exec iptables -A INPUT -s $2 -m state --state ESTABLISHED -j REJECT --reject-with icmp-host-unreachable
echo red

Este ejemplo es algo mas complejo (pero no mucho). Lo que hacemos en este caso es imprimir la coincidencia de la cadena definida como parte de una expresión regular cuyos campos "rhost=" y "user=" pueden tomar cualquier valor al estar anidados acompañados por .* e ir anidados por (). Hay que entender que al anidar podemos referirnos al valor como $N número de campos anidados tengamos, por ejemplo: La frase entera esta contenida en () por lo cual eso tomaría el valor $1 y rhost=(.*) tomaría el valor $2 así como user tomaría el valor $3. Por ese motivo en la regla de "exec iptables [...]" en la opción de origen "-s" hemos puesto $2, porque se corresponde con la ip del usuario (rhost). Esto se hace así porque previamente no conocemos la ip del usuario, por lo cual esto se puede aplicar a otras cosas.
Siguiendo con lo de antes, al tener la directiva: "echo red" la coincidencia se imprimirá en rojo (esto no sirve mucho pero es muy visual y queda mas bonito :D), ademas se le denegará el acceso al usuario , por lo cual esto puede ser muy efectivo si queremos quitarnos de encima a potenciales atacantes.
Oct 24 20:16:23 arkan0id sshd[2690]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.10 user=root

El ejemplo anterior puede combinarse con la opción: pipe, en cuyo caso quedaría así:
pipe /root/report.sh $2 $3,
Lo que hacemos es que llamamos a un script que recibe parámetros:

#!/bin/bash
echo "Intento de entrada no autorizada en $1 por: $2"

así que con lo que previamente expliquemos podemos fácilmente modificar el mensaje de salida.

Eso si, habrá cosas que a lo mejor no se puedan probar hasta que no ocurran así que lo que podemos hacer es hacer uso de la sencilla herramienta "logger" para mandar mensajes al syslog y comprobar que funcionan nuestras directivas:

#comprobar la carga de modulos
watchfor / Loaded /
bell 1
echo green

Y finalmente podemos usar el flag "-d" que nos permite "daemonizar" el proceso de manera que corre en segundo plano de forma semi-transparente y añadirlo al inicio del sistema de forma que cuando arranquemos tengamos al programa logeando y funcionando (update-rc.d swatch defaults)

Espero que os haya servido para algo este artículo, un saludo.

Hello bricomaniacos!!
Este artículo sirve para demostrar lo que muchos ya sabíamos, que basar las relaciones de confianza entre host-host o host-dispositivo. etc, basandonos en la efímera seguridad de una ip es cuanto menos inútil. Quizá hace 15 años fuera viable, pero hoy en día no lo es.
Como ejemplo tomo mi propio router que (además de muchísimos otros) tienen la funcionalidad de permitir solo y exclusivamente el acceso a la configuración vía HTTP de determinadas direcciones para así conseguir un poco más de seguridad y no permitir que alguien externo a nuestra red pueda cambiar fácilmente la configuración ... pero como veremos eso sige siendo cosa de niños gracias a hping3.

No voy a entrar demasiado en el manejo de hping3 puesto que a parte de extenso me llevaría mucho tiempo explicar una a una sus posibilidades y se sale un poco del objetivo del artículo.

Mi router está configurado para que SOLO Y EXCLUSIVAMENTE la IP: 192.168.1.2 acceda a la configuración del router y si otra ip que no sea esa intenta conectar obtiene un bonito mensaje parecido a este:

No se puede conectar
Firefox no puede establecer una conexión con el servidor en 192.168.1.1
...

y tal.
Aquí entra en juego hping3 (suponiendo que la ip del router sea la genérica para un router doméstico: 192.168.1.1)

Las opciones que vamos a utilizar son:
-I -> Permite enrutar el tráfico generado por una interfaz determinada.
-S -> Le indicamos que envíe un paquete SYN, que es el que usamos para iniciar la conexión.
-p -> Indicamos el puerto, generalmente el 80
-a -> (mi favorita) :) Esta opción es la más importante pues le podemos indicar que IP será la de destino y por lo general una distinta a la nuestra sin tener que configurar a mano la interfaz pues sería laborioso a la vez que inútil. Tambien es válido --spoof
-c -> El número de paquetes a enviar.

Como yo ya se la ip correcta estoy haciendo trampa, pero veamos como se comporta con una ip no válida.

[arkan0id]:~# hping3 192.168.1.1 -I eth0 -S -p 80 --spoof 192.168.1.10 -c 5
HPING 192.168.1.1 (eth0 192.168.1.1): S set, 40 headers + 0 data bytes
len=46 ip=192.168.1.1 ttl=254 id=9312 sport=80 flags=RA seq=0 win=1024 rtt=3.0 ms
len=46 ip=192.168.1.1 ttl=254 id=9315 sport=80 flags=RA seq=1 win=1024 rtt=3.3 ms
len=46 ip=192.168.1.1 ttl=254 id=9318 sport=80 flags=RA seq=2 win=1024 rtt=2.8 ms
len=46 ip=192.168.1.1 ttl=254 id=9319 sport=80 flags=RA seq=3 win=1024 rtt=4.2 ms
len=46 ip=192.168.1.1 ttl=254 id=9320 sport=80 flags=RA seq=4 win=1024 rtt=2.2 ms

... debemos de fijarnos en los flags devueltos por hping: RA (RST/ACK), osea que el puerto está cerrado para nuestra ip. Es lógico, estamos mandando un SYN a un puerto con una ip no válida ...
Probemos ahora con una ip válida:

[arkan0id]:~# hping3 192.168.1.1 -I eth0 -S -p 80 --spoof 192.168.1.2 -c 5
HPING 192.168.1.1 (eth0 192.168.1.1): S set, 40 headers + 0 data bytes
len=46 ip=192.168.1.1 ttl=254 id=9565 sport=80 flags=SA seq=0 win=1024 rtt=14.6 ms
len=46 ip=192.168.1.1 ttl=254 id=9566 sport=80 flags=SA seq=1 win=1024 rtt=4.0 ms
len=46 ip=192.168.1.1 ttl=254 id=9567 sport=80 flags=SA seq=2 win=1024 rtt=2.7 ms
len=46 ip=192.168.1.1 ttl=254 id=9568 sport=80 flags=SA seq=3 win=1024 rtt=4.2 ms
len=46 ip=192.168.1.1 ttl=254 id=9569 sport=80 flags=SA seq=4 win=1024 rtt=2.6 ms

Eso está mejor amigo .. si os fijáis los flags devueltos son (SYN/ACK) osea que nos ha respondido al SYN que hemos enviado de forma satisfactoria, lo que quiere decir que con esa ip tenemos comunicación :)

Y eso es todo. La problemática que podemos encontrar es: y si la IP del router no es la 192.168.1.1 o cualquier otra de cualquier otro rango que acabe en "1" que es lo mas frecuente? ... eso tiene facil respuesta. Si estas en un red local conectado con cable Ethernet la tienes que saber por fuerza .. y si estas por wifi ... también. El verdadero "problema" es a la hora de saber en que puerto "real" escucha el servidor http del router porque no tiene por que ser el 80.
Para esto nos valemos de la opción --scan ... y lo guapo es que hping es muy listo y nos muestra solo las respuestas positivas en una bonita tabla ascii como la siguiente:

[arkan0id]:~# hping3 192.168.1.1 -I eth0 -S --scan "102-110" --spoof 192.168.1.2 -c 5
Scanning 192.168.1.1 (192.168.1.1), port 102-110
8 ports to scan, use -V to see all the replies
+----+-----------+---------+---+-----+-----+-----+
|port| serv name | flags |ttl| id | win | len |
+----+-----------+---------+---+-----+-----+-----+
100 : .S..A... 254 4903 1024 46
All replies received. Done.

:)
Puerto 100 y justo al lado los flags S/A (SYN/ACK). Da igual donde se esconda, al final damos con el.
Que esto sirva de recordatorio para hacernos ver que las relaciones de confianza basadas en ip son inseguras e ineficientes.

Saludos.

En el mercado del maravilloso mundo del libro hay como en todos lados: libros buenos, libros mediocres, libros malos, libros que no convencen ... en definitiva libros de todo tipo y para todos los gustos y en informática no iba a ser menos.
Aquí pongo algunos libros de los cuales tengo buenas referencias y que tengo en mi "lista de compra" , osea que están en el punto de mira para ser leídos.
Aunque no puedo emitir un juicio "justo" y personal sobre ellos (ya que no me he leído todos) si que cuento con descripciones de la editorial del mismo que aunque no dicen mucho si podemos hacernos una idea de lo que trata el libro.
A continuación hago una selección de libros que pueden resultar interesantes tanto a administradores de sistemas como a iniciados en el mundo de la informática, seguridad o redes que quieren profundizar:

#1
Título: Extreme Exploits
Editorial: Anaya Multimedia
Autor/es: Victor Oppleman y otros.
Nº Edición: 1º
Año edición: 2006
ISBN: 9788441520097
Idioma: Español
Precio aproximado: 39 €
- ¿donde encontrarlo?

#2
Título: Hackers en Linux (Secretos y soluciones para la seguridad de Linux)
Editorial: McGraw Hill
Autor/es: Hatch Brian y Lee James
Nº y Año de edición: 2º - 2003
ISBN: 9788448139421
Idioma: Español
Precio aproximado:
- ¿donde encontrarlo? [1]

#3
Título: Blindaje de Redes
Editorial: Anaya Multimedia
Autor/es:
Nº y Año de edición:
ISBN:
Idioma: Español
Páginas: 720
Precio aproximado: 45 €

* reDuh - TCP Redirection over HTTP:
Esta herramienta nos permite, como su nombre indica, redirigir conexiones tcp sobre http. Si por ejemplo en una red tenemos denegado el acceso a IRC con este programa redirigimos el tráfico a un servidor en el cual previamente hemos subido el archivo "reDuh.jsp" que acompaña al programa.
Posteriormente se puede/debe correr el cliente: "reDuhClient" para que escuche en un puerto de la máquina local (1010 por defecto) y apuntando al servidor al cual hemos subido el archivo ".jsp".
De esta manera sencilla, al usar cualquier programa y usando como proxy el "bouncer" local podemos salir por puertos que están restringidos normalmente. Eso si, debemos de tener en cuenta que si utilizamos el archivo reDuh.jsp en un servidor perteneciente a la misma red local tenemos que asegurarnos de que la ip asociada a este no esté bloqueada (evidente) porque si no no estaremos haciendo nada.
-
Download reDuhClient (the local proxy)
Download reDuhu Server Pages (JSP/PHP/ASP)

[+] info
-

* Synner - eth->ip->tcp packet generator:
Synner permite forjar paquetes eth/ip/tcp con el fin de permitirnos testear nuestros firewalls y demás filtros de paquetes. Es capaz de enviar paquetes pre-generados muy rápidamente con ips, direcciones mac, flags TCP, payloads y todo lo que se permita personalizar en los protocolos con los que trabaja.
Habría que tenerlo en cuenta a la hora de testear nuestra red contra ataques DoS.
*nota: También puede interesar: nemesis, hping3
-
Download Synner
-

* FSlint:
FSlint es un conjunto de herramientas las cuales nos permiten encontrar ciertas "irregularidades" en nuestro sistema de archivos.
Permite encontrar en el momento: archivos duplicados, enlaces simbólicos incorrectos, nombres de archivos extraños, directorios vacíos, archivos duplicados, nombres duplicados en programas que podrían entrar en conflicto, IDS conflictivos ... . En definitiva puede resultarnos útil como "kit" de limpieza para nuestro máquina .... y mucho mas! :)
-
Download FSlint

[+] Captura
-

En GNU/Linux y en sistemas basados en Unix en general tenemos la suerte de tener variedad de firewalls y "aditivos" para estos tales como analizadores de logs y frontends gráficos.
A continuación hago una recopilación referente a programas para iptables, que posiblemente sea el firewall más usado en Linux. La recopilación es fruto de mi investigación sobre dicho software y lo que he ido encontrando en los últimos meses con el pequeño inconveniente de que me ha sido imposible probarlo todo con lo cual me es imposible emitir un juicio personal sobre dichas herramientas así que en algunas me limitaré a copiar la descripción que acompañe al paquete pertinente.

Para este artículo se distingen entre 4 tipos de complementos para iptables:
-Manejadores
-Logueadores
-Frontends gráficos
-Complementos

* Manejadores.
Nos permíten añadir, eliminar y editar reglas de iptables. En definiva, nos permite gestionar la configuración de iptables a nuestro antojo sin tener que lidiar con reglas a tan "bajo nivel" y nos ofrecen una interfaz algo más amigable que la simple y pura línea de comandos.
Para esta categoría contamos con:
-Shorewall:
-Vuurmuur: Sin duda este es mi "manager" preferido para iptables. Está escirto en C y ofrece una bonita interfaz en curses accesible mediante vuurmuur_conf. Las opciones que ofrece son muchas, permitiéndonos crear zonas y añadir, borrar y editar reglas de forma interactiva. Una de las cosas mas destacadas es que ofrece un monitor en tiempo real de las conexiones registradas por el módulo conntrack.
-ferm: Ferm es un programa cuya función primordial es reducir el tiempo de administración y creación de las reglas de iptables con el objetivo de que el administrador pueda centrarse más en construir buenas reglas que escribirlas. Ferm usa un simple pero poderoso lenguaje que permite: funciones, arrays, bloques, etc.
-FIAIF: Este es un shell-script en bash que por su estructura permite ser altamente configurable y (segun su autor) no es necesario saber shell scripting para configurarlo. Enre sus muchas características destaca el soporte para "baneo" de direcciones MAC, el ajuste del QOS de la red y el soporte para Traffic Shapping (ideal para redes locales), entre otras.

* Logueadores.
Gracias a ellos podemos loguear e interpretar los resultados vertidos por nuestro firewall. Aunque iptables se vale de syslog para un administrador que tenga que revisar el tráfico logueado diariamente puede ser muy tedioso puesto que aunque ordenada la salida puede ser algo incómoda de interpretar a largo plazo. Por ello contamos con programas como ... :
-WFlogs: Es una herramienta que analiza los logs de Netfilter con la posibilidad de poder ver la salida en formato texto, HTML o en tiempo real.
-fwLogWatch: Este programa analiza los registros de Netfilter generando informes en formato de texto, HTML o en tiempo real. Además, permite responder a ataques ejecutando scripts o modificando las reglas del firewall. Dispone de una interfaz web para administración remota.
-fwAnalog: Este programa es un shellscript cuya función es parsear y resumir los logs de iptables.

* Complementos.
-Fail2ban: Analiza los logs generados por iptables y permite bloquear el acceso a determinados servicios en base a reglas. Si alguna de esas entradas de logs coinciden con alguna regla definida por nosotros fail2ban es capaz de variar las reglas de iptables para impedir la conexión de cualquier IP que nosotros le indiquemos.

Este es un borrador sobre la configuración de PSAD bajo Linux corriendo Debian Lenny. Aunque la configuración puede ser genérica para otras distribuciones con gestores de paquetes puede diferir en mayor o menor medida en caso de que tuviera que ser compilada de manera independiente con lo que a ese punto debería revisarse la documentación sobre dicho programa desde la página oficial: http://www.cipherdyne.com/psad/docs/

[+] Nombre: PSAD
[+] Web: http://www.cipherdyne.com/
[+] Familia: Hardening
[+] Tipo: IPS
[+] Lenguaje: Perl
[+] Puntuación: 8/10

Introducción:
PSAD, (Port Scan Attack Detector). Como su propio nombre indica es un software que nos permite detectar los escaneos de puertos que son dirigidos a nuestra máquina, aunque en la práctica hace algunas cosas más como identificar el tipo de escaneo, ip del atacante, puertos que reciben mayores sondeos, etc ...

Instalación:
Es la propia de nuestra distribución. Como este manual se basa en Debian Lenny usamos apt para instalarlo haciendo un:
apt-get install psad

Haciendo un: dpkg -L / -S psad nos podemos hacer una idea de todos los archivos con los que cuenta psad ya que algunos de ellos los usaremos para configurarlo.

Configuración:
Antes de nada hay que decir que psad se vale de los logs generados por iptables para conocer el estado de las conexiones que se realizan. De esta forma, leyendo los logs de iptables psadwatch (demonio de psad) puede determinar si nuestro equipo está siendo atacado.
Para ello debemos hacer 2 cosas antes de continuar.
Lo primero es configurar nuestro demonio syslogd para que envíe todos los mensajes generados por el kernel con facility "info". Para ello debemos añadir la siguiente línea: "kern.info |/var/lib/psad/psadfifo", sin las comillas al final del archivo /etc/syslog.conf
Con esto lo que conseguimos es que se envíen TODOS los mensajes del kernel con facility "info" a una "tubería" llamada: psadfifo que es la que se encarga de proporcionarle de manera correcta los mensajes al demonio psadwatch que más adelante veremos.
Hecho esto nos dirigimos al archivo de configuración de psad (ubicado en: /etc/psad/psad.conf) donde explicaré todas sus partes. Es algo largo y si nos equivocamos en alguna opción podemos conseguir que el programa no funcione como esperamos o que directamente no arranque.
Si alguna vez en vuestra vida habéis configurado SNORT notaréis que el archivo de configuracón de psad tiene cierta similitud con este. Aunque luego veremos que no solo en el archivo de configuración se parecen.

La estructura del archivo de configuración de psad es muy simple.
Primero aparece el "nombre de la variable" y justo a la derecha, despues de un par de tabulaciones, su "valor" y seguidamente un ";" que quiere decir que esa línea concluye. Cuando modifiquemos algún valor de alguna variable es mu importante conservar el ";" justo al final del valor de la misma o de lo contrario el programa no se iniciará.
*nota: Las líneas que comienzan con "#" se ignoran, no se interpretan.

A continuación entramos en detalle en la configuración de psad:

EMAIL_ADDRESSES root@localhost; -> Aquí va la configuración de correo donde se nos envían las notificaciones generadas por psadwatch.

HOSTNAME venom; -> El nombre de nuestra máquina.

HOME_NET any; -> Esta opción define el rango de direcciones de nuestra red local. En caso de que tengamos varias redes locales en nuestra intranet podemos tener "any" (por defecto) para que tengo efecto en todas. En caso contrario tendríamos que indicarle el rango pertinente.

EXTERNAL_NET any; -> Aquí definimos el rango de direcciones que consideramos "fuera" de nuestra intranet.

FW_SEARCH_ALL Y; -> Esto quiere decir que si está activado, osea en "Y" psad revisará TODOS los mensajes generados por iptables.

FW_MSG_SEARCH LOG; -> Si la variable anterior está definida en "N" quiere decir que psad solo revisará mensajes que son generados mediante la orden --log-prefix de iptables e ignorar los que no incluyan esta. Esto parece ser lo más conveniente si solo queremos analizar los mensajes que podrían ser de nuestra interés, aunque hay que considerar que también puede tomar valores diferentes como DROP o REJECT, depende de como lo hayamos definido en la configuración de nuestro iptables con "--log-prefix".

SYSLOG_DAEMON syslogd; -> Aquí debemos indicarle el demonio de log del sistema que estemos usando para que psad pueda pasarle los mensajes. En debian es syslogd así que podemos dejarlo así.

DANGER_LEVEL1 5; -> Aquí definimos el "nivel de
DANGER_LEVEL2 15; -> peligro" dependiendo del número de
DANGER_LEVEL3 150; -> paquetes que recibamos por segundo.
DANGER_LEVEL4 1500; -> Si consideramos que con 10000
DANGER_LEVEL5 10000;-> paquetes nos podemos poner nerviosos como para asignarle un nivel de peligro 5 podemos dejarlo así, sino se puede cambiar.
Hay que tener en cuenta que si se solapa alguna opción con el archivo auto_dl (ya veremos mas adelante lo que es) lo que hay en ese archivo será preferente a lo que hayamos puesto aquí.

CHECK_INTERVAL 5; -> Esto es el número de segundos de espera antes de volver a revisar el archivo de log.

SNORT_SID_STR SID; -> Aquí definimos los valores a buscar por psad en caso de que las reglas de iptables se hayan construido con fwsnort o snort2iptables. En principio se podría dejar así.

PORT_RANGE_SCAN_THRESHOLD 1; -> Se recibirá una alerta después de que se haya excedido el número de puertos definidos en esta variable. Por ejemplo: Si sufrimos una exploración de puertos y se han registrado una cantidad de paquetes superior a: 1500 tal y como lo teníamos configurado en: DANGER_LEVEL4, si se detecta un escaneo a solo 1 puerto más se enviará otra alerta y si ponemos el valor a 5 necesitaremos 5 escaneos a puertos mas para emitir otra alerta.

ENABLE_PERSISTENCE Y; -> Algunos atacantes esperan un largo tiempo antes de lanzar otro escaneo contra una máquina determinada. Con esto podemos hacer que tenga en cuenta ese tiempo y lo asocie al mismo atacante.

SCAN_TIMEOUT 3600; -> Aquí ajustamos el tiempo (en segundos) de la opción descrita anterior.

SHOW_ALL_SIGNATURES N; ->

ALERTING_METHODS ALL; -> Aqúi configuramos el tipo de alerta con el cual queremos que psad nos avise en caso de que registre algún posible ataque. "nosyslog" y "noemail" respectivamente sirven para logear los mensajes en /var/syslog/psad y para no recibir correos de las alertas. Poniendo los 2 juntos separados por "," desactivaremos las alertas.

Da miedo, ver la lista publicada de los servidores dns de los ISP españoles en la web de bandaancha que aun no han sido parcheados ante el problema grave del DNS que permite falsear las consultas que recibe el servidor vulnerable en cuestion ...
Por lo que se ve hubo alguien que no pudo esperar a la convención de la DefCon de Agosto para que Dan hiciera pública la vulnerabilidad así que este individuo publicó los detalles de la misma en su blog.
Por ese y otros motivos y sobre todo por la dejadez o "descuido" de los "administradores de sistemas" podemos jugar con los servidores DNS vulnerables gracias a los exploits para la plataforma metasploit publicados por la gente de www.caughq.org | [1] | [2] , los cuales nos permiten modificar la consulta DNS que un servidor hace hacia otro con direcciones no cacheadas y así poder modificarlas a nuestro antojo.

Que se diviertan }:)

Después del "lío" en los principales software's DNS de internet en los que estuvieron trabajando: Debian,Cisco,Microsoft,Novell y otras empresas importantes del sector para solventarlo, nos llega una nueva versión de Zodiac, un programa para el testeo de servidores DNS.
Entre sus numerosas características se encuentra:

* Sniffing on all kinds of configured devices (Ethernet, PPP, …)
* Capturing and decoding nearly all types of DNS packets, including packet decompression
* Ncurses driven text based frontend with interactive commandline and multiple windows
* Threaded design allow more flexibility when adding your own features
* Clean code, commented and tested just fine, ready for you to extend
* Internal DNS packet filtering allows installation of pseudo DNS filters you can “select()” on a large set of DNS packet construction primitives
* DNS name server versioning using BIND version requests
* DNS local spoofing, answering DNS queries on your LAN before the remote NS
* DNS jizz spoofing, exploiting a weakness within old BIND versions
* DNS ID spoofing, exploiting a weakness within the DNS protocol itself

Puede descargarse desde aquí.
Que lo disfruten

[+] info

Ains ... que sería de nosotros sin ellos.
En este artículo intento explicar los sencillos pasos para, ¿esniffar? no... conseguir extraer la información que capturamos, pero no me refiero a información en formato texto, osea en hexadecimal o ascii o ... ,porque ese trabajo ya nos lo hace el esniffer lógicamente, sino a extraer los ficheros que capturamos en formato (data), su forma original. Imágenes jpg, png, .. vídeos ... los archivos que se envían o que se reciben en el irc, jabber..., ejem .. messeger y todo lo que se nos ocurra o hayamos capturado.

Para ello podemos hacer uso de cualquier sniffer que sea capa de guardarnos la captura en un simple archivo. Yo personalmente por costumbre y convención lo suelo hacer en un archivo .cap , pero no guardarlo en un archivo de texto con esta extensión, sino usar algún programa que sea capaz de guardarlo en este formato. Eso es debido a que algunos programas solo son capaces de entender el formato pcap, de ahí lo que os he dicho antes.
*wireshark
*tshark
*tcpdump
*tcpflow
*tcpick
*ngrep

.. son algunos de los sniffers que podemos usar para capturar los datos de nuestra red.
Ahora suponiendo que tenemos nuestro archivo guardado podemos usar algún programa para extraer dichos datos.
Voy a comentar a continuación 2 de ellos, que son los que conozco. Uno específico y otro genérico.

1.-tcpxtract: es capaz de extraer archivos de imágen, vídeo y comprimidos de un archivo guardado pcap, aunque en su configuración (/etc/tcpxtract) se pueden añadir firmas para que soporte todos los archivos que queramos y posteriormente poder extraerlos.
Con la opcion: tcpxtract -f archivo.cap -o directorio_salida ... nos volcará toda la información reconocible por el programa y lista para poder visualizar.

2.-foremost: mi querido y amado foremost :). Este no sirve para esto, en realidad sirve para extraer archivos hasta de debajo de las piedras, y como no, es muy usado en informática forense para recuperación de archivos.
Su uso: foremost -t [extensión] -v -i [archivo.cap] -T .Nos crea una carpeta llamada output donde vuelca los datos y dentro de esta subcarpetas nombradas con la extensión de los archivos que haya recuperado.
Como apunte, destacar que foremos puede usarse en dispositivos de bloques e imágenes de discos ... pero eso ya para otro artículo.

Saludos