3.4 JUGANDO CON EL NMAP

Es imposible al recomendar un scaner no caer en el nmap de linux ya ke brin-
da muchisimas posibilidades:

==============
Opcion | Descricion
---------------------------
-b      Capacidad de atakes de rebotes FTP
-e[interfaz] Espesificar interfaz
-f      Enviar pequeños paquetes fragmentados
-F      Espesificar rastreo rapido que compruebe los servicios estandares
-g      Definir el puerto de origen del rastreo
-i[archivo] Para que lea las direciones IP,a escanear, de un archivo.
-I      Opcion para extraer datos ident de los objetivos (si esta disponible)
-n       Para desactivar la busqueda DNS
-o[archivo]   Especificar archivo de salida
-p[puertos]   Epesificar puertos. Por rango ejemplo: 21-1024 o delimitados 21,23,25
-P0      Desactivar los pings de los host
-PB      Para utilizar en conjunto rastreos TCP y ICMP
-PI      Especificar ping ICMP
-PT[puerto]   Especificar ping TCP
-O Usar TCP/IP fingerprinting (vea abajo)
-sF      Utilizar rastreos furtivos FIN
-sS      Rastreo SYN semiabierto
-sT      Rastreo TCP conect
-sU      Rastreo UDP
-v      Activar modo personalizado

3.5 Sistemas de detencion de rastreos

he aqui un codigo para identificar rastreos de puertos SYN

---------------------------------- copiar --------------------------------

# detencion de la exploracion de puertos
# Por Stuart McClure
# este codigo verifica los intentos fallidos de un explorador de puerto
# que produce un ACK/RST. Pueden jugar con las varibles maxcount y maxtime
# para configurar la aplicacion

port_schema = library_schema:new( 1, [ "time", "ip", "int" ], scope () );
time = 0;
count = 0;
maxcount = 2; # Numero maximo permitido de ACK/RST
maxtime = 5; # Tiempo maximo permitido para que ocurra maxcount
source = 0;
port = 0;
target = 0;

filter portscan ip ()
{
if (tcp.is)
{
# buscar ACK, RST´s y, si tiene el mismo origen, contar
# solo uno

if (byte(ip.blob, 13) == 20 ) #bandera definida como ACK, RST
{
count = count + 1;

source = ip.dest;
target = ip.source;
port = tcp.sport;
time = system.time;
}
}
on tick = timeout ( sec: maxtime, repeat ) call checkcount;
}

func checkount
{
if (count >>= maxcount)
{
echo ("Port scan Georgie?, Time: ", time, "\n") ;
record system.time, source, target, port
to the_recorder_portscan;
count = 0;
}
else
count = 0;
}
the_recorder_portscan=recorder( "bin/histogram packages/sandbox/portscan.cfg",
port_schema" );

---------------------------------- fin de copiar----------------------------

Otras herramientas pueden ser el scanglogd de solar designer o el Psionic
Portsentry del proyecto Abacus () para ke de-
tecte y responda a un ataque activo. Otra heramienta que se puede utilizar
es el Firewall-1 de alerta de scaneos furtivos (
itz/intrusion.html)

Tanto como para windows 9x, nt y 2000 cualquier buen firewall detectara un
escaneo de puertos, como por ejemplo el blackIce de network ICE (.
networkice.com). Existen herramientas como el Genius que tienen funciones
entre otras de detectar rastreos de puertos, pero jeje tengo la desgracia de
informarles que ese detector de rastreo de puertos es totalmetne obsoleto,ya
que lo unico que hace es abrir el puerto 10 a a escucha de una solicitud de
conecion ( ode cualquier tipo) y si esta se efectua envia el mesge de alerta,
claro esta que la mayoria de los scaner por omicion jamas escanean el puerto
10.

[4.0 DETENCION DE SISTEMAS OPERATIVOS]

Las razones del porque debemos saber el sistema operativo en la víctima son
mas que obvias, ya que la información nos será útil en las búsquedas de vul-
nerabilidades.

[4.1 METODOS BASICOS ]

Una de las primeras pruebas a hacer seria un telnet al puerto 23 , en muchos
casos obtendremos el sistema corriendo en la victima:

[Leon@leon /]# telnet inseguro.org.ar
Trying 216.122.49.119 ...
Connected to 216.122.49.119.
Escape character is '^]'.
Red Hat linux releasse 6.1 (Cartman)
kernel 2.2.12 - 20 on i586
login:

Para quienes quieran quitar o personalizar el inicio de sección en las cone-
xiones de red, deberán modificar el los archivos /etc/issue y /etc/issue.net


Ni que hablar de probar al ftp (21):

[Leon@leon /]# telnet inseguro.org.ar 21
Trying 216.122.49.119 ...
Connected to inseguro.org.ar
Escape character is '^]'.
220 ftp29 FTP server (UNIX(r) System V Release 4.0) ready.
SYST
215 UNIX Type: L8 Version: SUNOS

Otro truco ke puede resultar es echo [Leon@leon /]# 'GET / HTTP/1.0 ' | nc
hotbot.com 80 | egrep '^Server:'



[4.1 RASTREO DE PILAS ]

Si ninguno de estos métodos no arroja un resultado favorable existen progra-
mas que realizan consultas a las pilas (stack), este método se lo conoce co-
mo stack finger printing o en español rastreo de pilas. EL rastreo de pilas
es una técnica extremadamente poderosa, pero no 100 % segura), para averi-
guar el sistema operativo instalado en el host víctima. Exiten muchos mati-
ces que diferencian el desarrollo de las pilas en ls distintos fabricantes.
A la hora de escribir las pilas cada fabricante suele interpretar a su mane-
ra la normativa RFC especifica. Por lo tanto mediante la detención de las
diferencias de estas podremos realizar suposiciones razonables de cual será
el OS que se esta utilizando.


[4.2 Tipos de sondeos stack ]

--> Sondeo FIN: Se envía un paquete FIN a un puerto abierto o cualquiera ke
no incluya un flag SYN o ACK. EL comportamiento de correcto del SO seria no
responder al flag FIN (según el RFC 793), sin embargo muchos desarrollos de
pilas (como MS Windows, BSDI, CISCO, HP/UX, MVS, e IRIX ) responderán con un
paquete reset (flag RESET)

--> Sondeo Bogus Flag: SE introduce una bandera TCP indefinida (64 o 128) en
la cabecera TCP de un paquete SYN Algunos sistemas operativos de linux (con
kernels anteriores al 2.0.35) mantendrán la bandera en su paquete de res-
puesta. Otros sistemas operativos resetean la conexión.

--> Muestreo de numero de secuencia Inicial (ISN): La premisa básica es en-
contrar un patrón en la secuencia inicial elegida por la implementacion TCP
cuando responde a una solicitud de conexión. Existen entre varios grupos de
OS que generan de distinta manera los ISN.

--> Supervisión de bit no fragmentado: Algunos sistemas operativos activaran
la opción "no-fragmentación" de IP para mejorar su rendimiento. Vigilando
este bit observaremos que tipos de sistemas operativos muestran este compor-
tamiento

--> Tamaño de ventana inicial TCP: Se analiza el tamaño de la ventana ini-
cial en los paquetes de respuesta. En algunos desarrollos de pilas este ta-
maño es único y puede ayudar bastante en la precisión del mecanismo de se-
guimiento.

--> Valor ACK. Las pilas IP difieren en el valor de la secuencia que usan en
el campo ACK.por lo que algunos desarrolladores responderán con el mismo nu-
mero de secuencia que han recibido y otros responderán con ese numero de se-
cuencia + 1

--> Control de error de mensaje ICMP: Los sistemas operativos cumplen la
RFC 1812 () y limitan la velocidad a la
que se en vían los mensajes de error. Si se enviaran paquetes UDP a algún
puerto con un numero aleatorio elevado, es posible contar el numero de men-
sajes recibidos no contestados en un intervalo de tiempo determinado. hay
que tener en cuenta que UDP no es un protocolo orientado a la conexión y en
muchos casos dichos paquetes podrían resultar descartados por la red,por es-
te caso aplicaciones como el nmap solo utilizan este método cuando se usa en
conjunto con rastreos UDP (# nmap -OsU ip)

--> Citado de mensajes ICMP: Los sistemas operativos difieren la cantidad de
información que cita cuando aparecen mensajes de error ICMP. si se examina
el mensaje citado, podríamos realizar ciertas hipótesis sobre cual es el
sistema operativo destino.Por ejemplo podríamos identificar las maquinas ba-
jo Linux y Solaris aun cuando no tengan ningún puerto escuchando.

--> Integridad del eco de mensajes de error ICMP: Algunos desarrolladores de
pilas pueden alterar las cabeceras IP cuando devuelven mensajes de error
ICMP. Si examinamos el modificaciones producidas en las cabeceras, podremos
realizar ciertas hipótesis Por ejemplo, AIX y BSDI nos regresan un datagrama
IP con el campo "longitud total" que es 20 bytes mas grande. Algunos BSDI,
FreeBSD, OpenBSD, ULTRIX, y VAXen alteran el ID del datagrama IP que les
mandaste.
Mientras el checksum va a cambiar debido que se cambia el TTL de todas for-
mas, hay algunas maquinas (AIX, FreeBSD, etc.) que regresan un checksum in-
consistente o de 0.

--> Tipo de servicio (TOS): En los mensaje del tipo "ICMP port unreachable"
(puerto ICMP no alcanzable) se pueden examinar el TOS. La mayor parte los
desarrolladores de pilas utilizan un 0, pero existen otras posibilidades

--> Gestion de fragmentacion: Tal y como lo resaltaron thomas Ptacek y Tim
Newsham en el informe " insercion, evacion y denial of service. Como evitar
el itrusismo en la red" ( lo podemos encontrar en
es/support/whitepapers/security/IDSpaper.pdf),cada pila maneja de forma di-
ferente la superposición de los fragmentos. Algunas pilas, cuando recompo-
nen los fragmentos, escriben los datos nuevos encima de los viejos y vice-
versa. Analizando como se recomponen los paquetes de sondeo, se pueden rea-
lizar suposiciones sobre el OS objetivo.


--> Opción TCP: Las opciones TCP se definen en el RFC 7 y, de forma mas
reciente, en RFC 123 () Las opciones mas avan-
zadas proporcionadas por el mismo suelen encontrarce en los desarrollos de
las pilas mas modernas. Enviando un paquete para que se han definido una
serie de opciones (por ejemplo,no operación, tamaño máximo de segmento,fac-
tor de escala de ventana y estampaciones de hora)

NOTA: Para diferenciar algunas versiones de sistemas operativos, como el
windows, se puede simplemente empezar con antiguos ataques para Windows DoS
(Ping of Death, WinNuke, etc) y después cambiar un poco mas arriba a ata-
ques como Teardrop y Land. Después de cada ataque, hacer un ping para ver
si cayeron.Cuando finalmente el host caiga, se puede deducir la versión que
están corriendo, e incluso hasta de paquete o parche.