IPlog es una aplicación que corre sobre GNU/Linux, FreeBSD, OpenBSD y BSDI encargada de loguear tráfico TCP, UDP y ICMP para estudiarlo en tiempo real y avisarnos de la detección de alguno de estos tipos de acciones: Scans de puertos TCP/UDP, TCP null scans, FIN scans, TCP "Xmas" scans y ataques de denegación de servicio (DOS) del tipo: UDP & ICMP "smurf", bogus TCP flags, TCP SYN scans, ICMP ping floods y IP fragment attacks. Basa sus capacidades en la dependencia libpcap, muy utilizada en software de monitorización y análisis de redes.

Otra de sus reconocidas posibilidades es la de poder engañar a la funcionalidad de Nmap de reconocimiento del sistema operativo escaneado, imposibilitando la extracción del fingerprint correcto. Puede que no sea el programa más completo y liviano para este tipo de menesteres pero su facilidad de uso lo hace interesante en muchos escenarios y vamos a dedicar unas lineas a explicar la forma de uso de este programa.

Instalar IPLog: http://www.busindre.com/como-compilar-iplog-sin-errores-parche/

Podemos usarlo mediante un fichero de configuración o invocando las opciones desde la linea de comandos, en este articulo explicaremos a utilizar iplog introduciéndole los parámetros de forma manual, una vez comprendido si quiere puede informarse de como hacerlo con un fichero de configuración mirando el manual.

$ man iplog

Sintaxis de Uso:

# iplog [opciones]

Opciones de IPLog:

"(*)" -> Opciones por defecto activadas.

--user ó -u user|UID -> Ejecuta Iplog con un uid determinado.
--group ó -g group|GID -> Ejecuta Iplog con un gid determinado.
--logfile ó -l file -> Loguea la salida en el fichero indicado.
--pid-file file -> Usa el fichero como PID del proceso.
--ignore ó -d -> Ignora el trafico de DNS que tengamos en el fichero /etc/resolv.conf
--interface ó -i if0,...,ifN -> Escucha en las interfaces indicadas.
--promisc ó -a network -> Pone la tarjeta en modo promiscuo para loguear salidas.
--kill ó -k -> Mata el proceso iplog si se encuentra corriendo.
--restart ó -R -> Reinicia iplog si está corriendo.
--no-fork ó -o -> Ejecutar iplog en primer plano.
--stdout ó -L -> Log to stdout.
--help ó -h -> Muestra la ayuda (Inglés).
--version ó -v -> Muestra la versión de iplog usada.

--facility facility -> Especifica el syslog facility.
--priority priority -> Especifica el syslog priority.

--tcp[=true|false|toggle] -> Loguea el tráfico TCP traffic. (*)
--udp[=true|false|toggle] -> Loguea el tráfico UDP traffic. (*)
--icmp[=true|false|toggle] -> Loguea el tráfico ICMP traffic. (*)

--log-ip[=true|false|toggle] ó -w -> Loguea la IP junto con el hostname..
--log-dest[=true|false|toggle] ó -D -> Loguea el destinatario del tráfico recibido.
--dns-cache[=true|false|toggle] ó -c -> Usar la cache DNS (Nscd). (*)
--get-ident[=true|false|toggle] ó -e Muestra información sobre la identidad (Protocolo Ident).

--tcp-resolve[=true|false|toggle] ó -T -> Resuelve las IPs del trafico TCP. (*)
--udp-resolve[=true|false|toggle] ó -U -> Resuelve las IPs del trafico UDP. (*)
--icmp-resolve[=true|false|toggle] ó -I -> Resuelve las IPs del trafico ICMP. (*)
--disable-resolver ó -N -> NO realiza ninguna resolución de IP - Dominio. (*)

--verbose[=true|false|toggle] ó -V -> Modo Verbose.
--fool-nmap[=true|false|toggle] ó -z -> Engaña la resolución de SO de Nmap (fingerprints).
--scans-only[=true|false|toggle] ó -m -> Solo loguea escaneos de puertos.
--detect-syn-flood[=true|false|toggle] ó -s -> No resuelve nombres en un SYN flood. (*)

--log-frag[=true|false|toggle] ó -y -> Loguea ataques de paquetes fragmentados. (*)
--log-traceroute[=true|false|toggle] ó -t -> Loguea tracerouters. (*)
--log-ping-flood[=true|false|toggle] ó -P -> Loguea ICMP DOS. (*)
--log-smurf[=true|false|toggle] ó -S -> Loguea ataques smurf. (*)
--log-bogus[=true|false|toggle] ó -b -> Loguea ataques usando paquetes con flags falseadas. (*)
--log-portscan[=true|false|toggle] ó -p -> Loguea escaneos de puertos. (*)
--log-udp-scan[=true|false|toggle] ó -F -> Loguea escaneos o flods de puertos UDP. (*)
--log-fin-scan[=true|false|toggle] ó -f -> Loguea escaneos FIN. (*)
--log-syn-scan[=true|false|toggle] ó -q Loguea escaneos SYN. (*)
--log-xmas-scan[=true|false|toggle] ó -x -> Loguea escaneos Xmas. (*)
--log-null-scan[=true|false|toggle] ó -n -> Loguea escaneos NULL. (*)

Escaneo de Puertos

Los programas que escanean puertos se basan en enviar cierto tipo de paquetes para determinar si una determinada aplicación esta escuchando a través de un puerto. Este tipo de paquetes pueden ser muy variados como vamos a ver a continuación, usaremos Nmap para el ejemplo, mostrando los tipos de scans comentados en la introducción seguido de la linea que el programa iplog usará para informarnos del mismo.

Opciones de Nmap / Mensajes de iplog:

-sT: TCP scan -> TCP: port scan detected
-sN: TCP Null -> TCP: null scan detected
-sF: FIN Scan -> TCP: FIN scan detected
-sX: Xmas scans -> TCP: Xmas scan detected
-sS: SYN scans -> TCP: SYN scan detected
-sU: UDP scan -> UDP: scan/flood detected

NOTA: La opción -O de nmap permite obtener información sobre el sistema operativo que corre bajo la máquina escaneada, si usamos iplog con la opción -z, el escaner de puertos no podrá obtener el fingerprint correcto debido a que falsea las respuestas y por lo tanto nmap no deducirá que SO se está usando en el host. Este tipo de solicitudes no se loguean en las salidas de IPLog, no reporta la peticiones de información sobre el sistema operativo usado.

Ataques DOS

Una vez vistos los tipos de escaneos vamos a ver que mensajes muestra la salida de IPLog tras los ataques UDP & ICMP "smurf", bogus TCP flags (Paquetes TCP con flags falsas), TCP SYN scans, ICMP ping floods y IP fragment attacks.

Ataques DOS / Mensajes de iplog:

UDP & ICMP "smurf" -> ICMP/UDP: smurf attack detected

Bogus TCP flags -> TCP: Bogus TCP flags set

TCP SYN scans -> TCP: SYN scan detected (Puede ser flood o scan)

ICMP ping floods -> Ping flood detected

En lo referente a "IP fragment attacks", Iplog puede mostrar muchos tipos de mensajes (TCP SYN, TCP/NULL,..) dependiendo del tipo de paquete fragmentado (TCP/UDP/ICMP), suele mostrar al lanzarse ataques de paquetes TCP fragmentados la linea "Duplicate IP fragments from X.X.X.X". (Puede ser flood o scan).

NOTA: Los paquetes fragmentados para provocar DOS se encuentra en desuso pero son comúnmente usados para intentar saltar débiles listas de control de acceso o atacar dispositivos de gama baja.

Como el tipo de conexiones y protocolos usados para los floods son muy parecidas o idénticas a las usadas por los escaners de puertos, IPLog puede avisar del ataque como un flood o como un escaneo de puertos, pero para saber diferenciarlos debidamente hay que estar atentos a los tiempos entre el comienzo del ataque, el numero de paquetes recibidos y cuando termina. Sí el reporte del número de paquetes es excesivo y tiene una duración más o menos larga, suele referirse a un ataque de flood DOS. Veamos un ejemplo:

Salida de un escaneo con paquetes SYN:

01:15:01 TCP: SYN scan detected [ports 256,389,23,25,1723,80,22,...] from X.X.X.X [port 47118]
01:15:51 TCP: SYN scan mode expired for X.X.X.X - received a total of 89 packets (2136 bytes).

Salida de un Flood con paquete SYN:

01:26:51 TCP: SYN scan detected [port 0] from X.X.X.X [ports 1075,1076,1077,1078,1079,...]
01:26:53 TCP: port scan detected [port 0] from X.X.X.X [ports 1075,1076,1077,1078,1079,...]
01:29:02 TCP: port scan mode expired for X.X.X.X - received a total of 359 packets (7180 bytes).
01:30:04 TCP: SYN scan mode expired for X.X.X.X - received a total of 33867 packets (46552540 bytes).

Un ataque DOS que se base en múltiples solicitudes http desde una IP sería logueado por Iplog de la siguiente manera:

02:21:21 TCP: port scan detected [port 80] from X.X.X.X [ports 34781,34782,34783,34784,34785,...]
02:23:03 TCP: port scan mode expired for X.X.X.X - received a total of 4170 packets (166800 bytes).

Para hacer flood / DOS hay muchas herramientas, pero para realizar pruebas de concepto recomendamos el uso de hping, que nos permite crear paquetes TCP/IP a nuestro gusto para nuestras pruebas. Con el comando ping podemos hacer pruebas de flood (Opción -f) para generar DOS.

Debemos recordar que este tipo de técnicas DOS, como es el ICMP flood, el smurf, DOS mediante paquetes SYN,.. Han ido quedando en desuso según han mejorado las implementaciones de las pilas TCP/IP y el establecimiento de medidas de seguridad de forma estandar en los enrutadores. Sin embargo, siempre podemos encontrar productos en el mercado, normalmente de gama baja (Tecnología de hogar), con problemas en el tratamiento de paquetes que producen cuelgues o permitan saltarse ciertas restricciones de seguridad dependiendo de la estructura o cantidad de paquetes recibidos.

Por ejemplo, los ataques DOS basadas en la técnica smurf son muy difíciles de realizar actualmente en redes WAN / Internet, los routers de los ISP por defecto no dejan pasar a través de ellos solicitudes a direcciones broadcast ni permiten falsear direcciones IP origen de sus clientes. Para demostrar esto tenemos esta imagen donde se aprecia que un ping a una red vulnerable a smurf es imposible de aprovechar debido al filtrado que realiza el ISP. Para saber si nuestro ISP filtra también las direcciones salientes spoofeadas vale con intentar hacerlo y observar como siempre se nos contestan los paquetes pongamos el origen que pongamos.

Esto se debe a que el paquete al llegar al ISP con un origen (Dirección IP) no registrada para esa linea contratada, se cambia inmediatamente por la IP origen correcta, por lo que de permitir un smurf y tener este tipo de filtro, el que realice el DOS se encontraría con la horma de su propio zapato. Como vemos en esta imagen de abajo, el ping responde cuado falseamos la dirección origen de los paquetes, por lo que deducimos que hay filtro por parte del ISP que usamos para salir a Internet.

¿Como puedo crear pequeños scripts para realizar flood?

Para crear ataques y usarlos para pruebas de concepto podemos hacer uso de bucles infinitos como el siguiente. En la shell ponemos:

$ while true; do COMANDO; done

Un ejemplo simple para insertar un comando en el anterior bucle infinito podría ser "curl http://www.microsoft.com", con eso se realizarían muchas peticiones http a la web http://www.microsoft.com. Para potenciar el efecto podemos ejecutar el mismo código desde varias terminales y ordenadores. La herramienta Hping3 tiene una opción denominada --flood que viene al pelo para realizar pruebas DOS mediante la creación de paquetes al gusto para cada tipo de ataque (Bogus TCP flags, TCP SYN scans,...).

Otro tipo de logueos de Iplog:

Tracerouter -> Traceroute: UDP: traceroute

Las herramientas como Iplog son también denominadas "Snifferslog" porque loguean todo el tráfico de la red, de usar iplog sin indicar ciertas opciones (filtros) para que solo detecte lo que nos interese (Comunmenteme escaneos y ataques DOS) mostrará todo tipo de conexiones por únicas y comunes que sean, http, pings, ftp, etc,... Por eso se recomienda usar la opción "--scans-only=true", de esta forma solo informará de ataques y escaneos.

NOTA: Si usamos "--scans-only=true" y se escanea el servidor utilizando solo un par de puertos a estudiar, iplog NO nos avisará ya que no lo interpreta como un escaneo, como es de esperar. Si por ejemplo unas determinadas máquinas hacen muchas solicitudes al puerto 80, en la salida de iplog se mostrara como un scan http, pero debemos interpretar debidamente la salida de log para no caer en confusiones, se debe prestar atención a la duración de esos "ataques". Es muy conveniente sacar unos logs cuando el servidor está realizando un funcionamiento normal con un tráfico normal, para así poder comparar las salidas una vez se sufran ataques y no caer en falsos positivos.

IPLog y la opción --promisc / -a

La aplicación IPLog por defecto solo loguea las conexiones entrantes a la interfaz de red, cuando nos escanean los puertos, cuando nos floodean, en resumen, cuando los paquetes van dirigidos a nuestro ordenador. Esto explica que al tener funcionando Iplog en una máquina A y desde esa mismo host A realizar un flood a un servidor B, nos detecte las contestaciones de B como un ataque, generalmente como ataque smurf.

La opción --promisc nos posibilita poder identificar las conexiones salientes a una determinada red / host, no solo las entrantes a nuestro ordenador. Esta opción es especialmente útil si queremos vigilar a nuestro PC de forma de que si se realiza un ataque, desde el ordenador o desde alguna de las máquinas que lo usen como gateway a una determinada red, podremos saberlo. Veamos un ejemplo.

Teniendo wlan0 con una dirección IP 192.168.1.34 ejecutamos el siguiente comando:

# ping -f 66.249.91.103

Obteniendo una salida de IPLog (Usando --promisc):

# iplog -o -L -D -a 66.249.91.0/24 --scans-only=true --ignore --disable-resolver -i wlan0


ICMP: ping flood detected to 66.249.91.103 from 192.168.1.34

Ahora veamos la salida sin usar la opción "--promisc":

# iplog -o -L -D --scans-only=true --ignore --disable-resolver -i wlan0


ICMP/UDP: smurf attack detected to 192.168.1.34 from 66.249.91.0

Al no detectar el tráfico saliente, detecta solo las respuestas del flood (ping -f) de 66.249.91.103 y NO avisa del ataque que estamos realizando, sino que lo entiende como un ataque smurf a nuestra propia máquina, como antes dijimos, ya que solo analiza los paquetes entrantes. El usar esta opción, indicando la red o host que queremos mantenga vigilados con respecto al trafico saliente, limita el uso de IPLog para que detecte ataques orientados a la propia máquina donde está corriendo, ya que solo le interesará el trafico saliente a esa red / IP, si queremos que loguee todo, podríamos hacer un apaño usando como parámetro: 0.0.0.0/0

De usar esta opción de la siguiente manera:

-a 0.0.0.0/0

Le estamos diciendo a IPLog que identifique los ataques emitidos y recibidos por nuestro host en la interfaz definida en la opción "-i". Esto nos permite poder usar GNU/Linux o BSD como router para otros hosts e identificar cuando nuestros usuarios atacan ciertas máquinas y detectar cuando nos están atacando a nosotros o a alguno de los hosts que enrutemos. Si estamos enrutando y queremos detectar si las maquinas que enrutamos realizan determinados ataques, el programa IPLog debemos colocarlo usando la opción -i, lo más próximo a las redes que se enrutan. Veamos un ejemplo práctico dado este escenario:

Ejemplo de salida cuando usamos nuestro host como gateway:

Esquema:

GNU/Linux_GATEWAY (eth0) - - - - - - - RED 2 - - - - - - 192.168.2.X
(eth1) 192.168.1.33
|
|
|
RED 1
|
|
|
192.168.1.1
Router ISP [INTERNET]

La máquina GNU/Linux_GATEWAY que hace de router tiene dos redes:

eth0: 192.168.2.0/24
eth1: 192.168.1.0/24

Sobre esa máquina GNU/Linux, ejecutamos el siguiente comando y observamos la salida:

# iplog -o -L -D -a 0.0.0.0/0 --scans-only=true --ignore --disable-resolver -i eth0 -l /var/log/iplog_eth0


UDP: traceroute from 192.168.2.19 to 91.200.143.20
UDP: scan/flood detected to 208.67.222.222 [port 53] from 192.168.2.19 [ports 33043,33044,...]
ICMP: ping flood detected to 65.55.11.222 from 192.168.2.20
TCP: port scan detected to 192.168.1.1 [port 80] from 192.168.2.11 [ports 45169,45170,...]
UDP: scan/flood detected to 80.58.0.33 [port 53] from 192.168.2.19 [ports 33044,33045,33046,...]
UDP: scan/flood detected to 80.58.32.97 [port 53] from 192.168.2.19 [ports 33044,33045,33046,...]
TCP: Xmas scan detected to 64.38.255.172 [ports 256,53,113,21,...] from 192.168.2.19 [port 40263]
UDP: scan/flood detected to 91.200.143.20 [ports 33438,33439,...] from 92.168.2.11 [port 38047]


TCP: port scan detected to 192.168.2.19 [port 22] from 192.168.1.31 [ports 2389,2390,2391,...]
TCP: port scan detected to 192.168.2.19 [port 7777] from 91.65.122.90 [ports 33858,33860,33861,...]
SYN scan detected to 192.168.2.19 [port 6568] from 51.30.43.3 [ports 47627,48958,35224,...]
TCP: port scan detected to 192.168.2.19 [port 25] from 83.38.28.194 [ports 46263,46264,46265,...]
TCP: Bogus TCP flags set by 91.200.143.20:42018 (dest 192.168.2.19:7777)

ICMP: ping flood detected to 147.243.3.83 from 192.168.2.20
ICMP/UDP: smurf attack detected to 192.168.2.20 from 147.243.3.0 (FALSO POSITIVO)


En el primer párrafo de la salida observaremos ataques realizados por las máquinas de la RED 2 (192.168.2.0) a diferentes puntos, todos realizados por los hosts 192.168.2.19, 192.168.2.11 y 192.168.2.20. Al usar la opción "-a 0.0.0.0/0" podemos detectar también los ataques que sufren las máquinas de la RED 2, que es lo que viene a mostrar el segundo párrafo, donde podemos ver como primera linea un ataque a ssh de un miembro de RED 1 a 192.168.2.19 (RED 2).

NOTA: Si nos fijamos en el último párrafo vemos lo que comentábamos anteriormente, la detección del ataque smurf se debe a las contestaciones del flood generado por 192.168.2.20 sobre 147.243.3.83

Para ver si IPLog ha puesto nuestra tarjeta en modo promiscuo, podemos hacer uso de este comando $ dmesg | grep -i device que mostrará un mensaje de este tipo:

device wlan0 entered promiscuous mode
device wlan0 left promiscuous mode

IPLog también avisa cuando una interfaz se cae:

Warning: interface eth0 went down.
Interface eth0 was reopened.

Enlaces de Interés:

Detectar redes amplificadoras (SMURF) http://www.powertech.no/smurf/
Información sobre TCP/ICMP: http://www.nebrija.es/~cmalagon/...hxc.pdf
Presentación sobre DOS: http://www.it46.se/downloads/../dosattacks_slides_escuderoa.pdf