INFOVIA, RADIUS, PUSI, SYNFLOOD Y OTRAS ZARANDAJAS
Primero pedir disculpas a todos los sufridos lectores de este artículo
puesto que si muchos de los conceptos que en el se citan pueden resultar
obvios, no se me ocurre otra manera de ir entrando en harina.
sLMÆ (Sociedad LiMitadisimæ).
Que es infovia ?
Una red paralela a la Internet estrucucturada también en protocolo TCP/IP, de
tal forma que podemos acceder a INET (Internet) atraves de ella, es lo que
Telefónica, la compañia que explota este producto, ha denominado INFOVIA.
Para ello han tomado una Clase A de direcciones (10.0.0.0-10.255.255.255),
direcciones estas reservadas para pruebas en INET, y han estructurado la red,
de tal manera que si una de estas IP consiguiera acceder a INET, no causaria
mayores problemas, dado que son direcciones no validas en INET, debemos de
tener en cuenta que cuando accdemos a INET la dirección que tenemos en ese
momento es la que nuestro proveedor nos asigna, esto se consigue gracias
al radius, verdadero artífice de toda esta estructura paralela para ello
al configurar nuestro acceso especificamos "login@proveedor", de tal manera
que el CSIV (Centro Servidor de Infovia), sabe perfectamente a que CPI (Centro
Proveedor de Infovia) tiene que lanzar la petición de validación de usuario.
En la actualidad existen 3 CSIV en Madrid, Barcelona y Valencia, con la
particularidad que si cualquiera de ellos cayera, los otros 2 tomarian la
carga, esto se debe a que desde la versión de radius 2.0, entre otras mejoras
los pools que asigna cada CPI son únicos, con lo que siempre podremos acceder
aún en el caso de que tengamos una IP fija.
Que es radius ?
En su origen es un programa cliente servidor para verificación de usuarios
remota, pero que ha sido adaptado por Telefónica para establcer la estrucutura
de infovia. Las fuentes las podeis encontrar en "ftp.ascend.com", pero realmente
estan tan modificadas que ya no tienen nada que ver con el estado actual del
radius, por otra parte Telefónica lejos del espiritu de linux, (Es habitual en
linux facilitar las fuentes del programa, y luego uno lo compila), no facilita
las fuentes, pero esto es entrar ya en temas filosóficos, así que vayamos con
lo que realmente nos interesa.
La maquina del ISP donde por defecto siempre se monta el server de radius es
la "X.X.X.2", quedando la "X.X.X.1" reservada para el router del proveedor.
Normalmente el fichero donde se encuentran todas las claves de acceso de los
usuarios es "/etc/raddb/usuarios_INFOVIA", a no ser que a la hora de arrancar
radius se haya indicado lo contrario.
"radiusd -d direc -u file"
Ahora el fichero de configuracion de usuarios es "/direc/file".
"radiusdll"
Igual que el radiusd pero el acceso lo comprueba de una base de datos dbm,
la diferencia es que ahora cada vez que se produzca una alta, el proveedor
debera de indexar el fichero de acceso, aunque para nuestros propositos el
usuarios_INFOVIA sigue siendo el interesante. El problema es que para
comprobar donde se encuentra el fichero de acceso no tenemos otro remedio
que acceder a la maquina en cuestión.
Finalmente el puerto por el que radius escucha las peticiones de autentificación
de usuarios es el 1645.
*(1)*
Unas notas sobre PUSI
En los canales de hack aparte de las famosas boxes, siempre se acaba hablando
de si es posible que Telefónica sepa el número de teléfono desde el que un
usuario accede a infovia, pues bien señores la respuesta es SI en la mayor
parte de los casos, para ello utilizan la señalización por canal común.
CCS (Chanel Common Signaling- Señalización por canal comun).
En señalización PUSI se envia la información de muchos enlaces por el canal
16 de un MIC (Modulacion de Impulsos Codificados), no como se venia haciendo
hasta el momento en las centrales analogicas, es decir mandar la señalización
de todo el MIC por su canal 16 (CAS, Señalización por canal asociado). Para
ello la señalización va en forma de paquetes, y desde la última revisión de
software de los modulos digitales, se ha implementado la facilidad de mandar
el número A (Abonado llamante). En la actualidad todas las centrales digitales
implementan esta facilidad, ahora bien, la información del numero llamante
solo la recibe infovia, no pasando este dato al CPI, esto en la versión 2.0
de radius por que anteriormente si que se facilitaba este dato al CPI.
*(2)*
Log de una llamada señalización PUSI
ENVIADO :08011a05a104039090a31801891e0284836c0801833330303339377007c1
6861636b6974
00001000 Discriminador de protocolo: 08
Protocolo Q.931.
Valor de referencia de llamada: 011a
26.
ESTABLECIMIENTO (SETUP) ----->
a1
* E.I. ENVIO COMPLETO: a1
04039090a3
* E.I. CAPACIDAD PORTADORA: 04
Longitud: 03
-00----- Norma de codificación:
Norma del CCITT.
---10000 Capacidad de transferencia de información:
Audio a 3'1 kHz.
-00----- Modo de transferencia de información:
Modo circuito.
---10000 Velocidad de transferencia de información:
Modo circuito, 64 kbit/s.
---00011 Protocolo de capa 1 de la información de usuario:
Recomendación G.711 del CCITT, ley A.
180189
* E.I. IDENTIFICACION DE CANAL: 18
Longitud: 01
-0------ Identificador de interfaz:
Interfaz implícitamente identificado.
--0----- Tipo de interfaz:
Interfaz de acceso básico.
----1--- Preferido/exclusivo:
El canal indicado es, exclusivamente, el aceptable.
-----0-- Indicador de canal D:
El canal identificado no es el canal D.
------01 Selección de canal:
Canal B1.
1e028483
* E.I. INDICADOR DE PROGRESO: 1e
Longitud: 02
-00----- Norma de codificación:
Norma CCITT.
----0100 Localización:
Red pública a la que se conecta el usuario remoto.
-0000011 Descripción de progreso:
La dirección de origen no es RDSI. Indica que el equipo de
usuario de origen no es RDSI.
6c080183333030333937
* E.I. NUMERO LLAMANTE: 6c
Longitud: 08
-000---- Tipo de número:
Desconocido.
----0001 Identificación del plan de numeración:
Plan de numeración de RDSI/Telefónico.
-00----- Indicador de presentación:
Presentación permitida.
------11 Indicador de verificación:
Número proporcionado por la red.
Cifras del número:
300397
7007c16861636b6974
* E.I. NUMERO LLAMADO: 70
Longitud: 07
-100---- Tipo de número:
Número de abonado.
----0001 Identificación del plan de numeración:
Plan de numeración de RDSI/Telefónico.
Cifras del número:
Aqui deberia de estar el número ;-)
RECIBIDO:08019a01
00001000 Discriminador de protocolo: 08
Protocolo Q.931.
Valor de referencia de llamada: 019a
26.
AVISO (ALERT) <-----
RECIBIDO:08019a077e1104494e464f524d41544943412049425953957c0841806861636b
6974
00001000 Discriminador de protocolo: 08
Protocolo Q.931.
Valor de referencia de llamada: 019a
26.
CONEXION (CONN) <-----
7e1104494e464f524d41544943412049425953
* E.I. USUARIO A USUARIO: 7e
Longitud: 11
00000100 Discriminador de protocolo:
Caracteres AI5.
Información de usuario:
INFORMATICA IBYS
95
* E.I. CAMBIO CON ENCLAVAMIENTO: 95
-----101 Identificación de conjunto de códigos:
Elementos de Información específicos CEPT.
7c0841806861636b6974
* E.I. NUMERO CONECTADO: 7c
Longitud: 08
-100---- Tipo de número:
Número de abonado.
----0001 Identificación del plan de numeración:
Plan de numeración de RDSI/Telefónico.
-00----- Indicador de presentación:
Presentación permitida.
------00 Indicador de verificación:
Número proporcionado por el usuario no verificado por la red.
Cifras del número:
Aqui deberia de estar el número ;-)
ENVIADO :08011a0f
00001000 Discriminador de protocolo: 08
Protocolo Q.931.
Valor de referencia de llamada: 011a
26.
ACUSE DE CONEXION (CONN ACK) ----->
ENVIADO :08011a45080284901e02828828114c494245524143494f4e204e4f524d41
4c
00001000 Discriminador de protocolo: 08
Protocolo Q.931.
Valor de referencia de llamada: 011a
26.
DESCONEXION (DISC) ----->
08028490
* E.I. CAUSA: 08
Longitud: 02
-00-----Norma de codificación:
Norma del CCITT.
----0100 Localización:
Reservado.
-0010000 Valor de la causa:
Liberación normal de la llamada.
1e028288
* E.I. INDICADOR DE PROGRESO: 1e
Longitud: 02
-00----- Norma de codificación:
Norma CCITT.
----0010 Localización:
Red pública a la que se conecta el usuario local.
-0001000 Descripción de progreso:
En este momento se encuentra disponible una información o
una secuencia adecuada dentro de banda.
28114c494245524143494f4e204e4f524d414c
* E.I. VISUALIZACION: 28
Longitud: 11
Información de visualización:
LIBERACION NORMAL
RECIBIDO:08019a4d
00001000 Discriminador de protocolo: 08
Protocolo Q.931.
Valor de referencia de llamada: 019a
26.
LIBERACION (REL) <-----
ENVIADO :08011a5a
00001000 Discriminador de protocolo: 08
Protocolo Q.931.
Valor de referencia de llamada: 011a
26.
LIBERACION COMPLETA (REL COM) ----->
/* Fin del log de la llamada */ /* ------------------------- */
*(3)*
Log de lo que recive un CPI
Conexión:
23-03-1997 20:15:34
User-Name = "usuario"
NAS-Identifier = 172.14.1.62
NAS-Port = 20130
Acct-Status-Type = Start
Acct-Delay-Time = 0
Acct-Session-Id = "225502093"
Acct-Authentic = RADIUS
Client-Port-DNIS = "1055"
Framed-Protocol = PPP
Framed-Address = Direccion.que.le.asigna. el CPI
Desconexión:
23-03-1997 20:23:17
User-Name = "usuario"
NAS-Identifier = 172.13.1.21
NAS-Port = 20311
Acct-Status-Type= Stop
Acct-Delay-Time = 0
Acct-Session-Id = "226304198"
Acct-Authentic = RADIUS
Acct-Session-Time = 4581
Acct-Input-Octets = 52427
Acct-Output-Octets = 188320
Acct-Input-Packets = 8958
Acct-Output-Packets = 889
Ascend-Disconnect-Cause = 47
Ascend-Connect-Progress = 60
Ascend-Data-Rate = 14400
Ascend-PreSession-Time = 18
Ascend-Pre-Input-Octets = 375
Ascend-Pre-Output-Octets = 302
Ascend-Pre-Input-Packets = 44
Ascend-Pre-Output-Packets = 10
Ascend-First-Dest = Primera.dirección.IP.con la que conecta el cliente.
Caller-Id = "4513"
Client-Port-DNIS = "1055"
Framed-Protocol = PPP
Framed-Address = Direccion.que.tenia
Fin del log del CPI
Synflood
Este ataque es del tipo denial of service (DOS), y funciona debido a la propia
implementación del protocolo TCP/IP. Al ser TCP/IP un protocolo orientado a
la conexión, si dos hosts quieren intercambiar datos, primero deben de
establecer la conexión entre ellos, para ello TCP lleva acabo un proceso
de 3 tiempos conocido como "3-way handshake", por ejemplo si la maquina A está
ejecutando un cliente y quiere conectar con el server B, el proceso sera el
siguiente:
1- A ----- SYN ----- > B
2- A <-- SYN/ACK ---- B
3- A ----- ACK ------> B
(1) El cliente (A) le dice al servidor (B) que quiere conectarse, para ello
activa el flag SYN, ajusta el campo de numero de secuencia en la cabecera TCP
con su ISN (numero inicial de secuencia).
(2) El server responde con su ISN y un ACKnowledgement (Reconocido).
(3) El cliente ahora ACK el ISN del server.
Ahora una vez establecida la conexión, podrán intercambiar datos.
Flags de control de TCP
SYN: Número de secuencia de sincronización.
Solo se utiliza en el proceso de establecimiento de la conexión, le
indica al receptor que compruebe el campo de número de secuencia y
anote su valor en el ISN, para ello TCP posee un contador de 32 bits.
ACK: Acknowledgement (Reconocimiento).
Este flag almacena el número de secuencia del siguiente paquete esperado.
RST: Reset.
Destruye la conexión.
URG: Urgente.
Indica que el puntero de urgencia es valido.Por ejemplo si en una conexión
telnet el cliente pulsa ctrl-C, esto se considera urgente y el flag es
activado.
PSH: Push.
El receptor no pondrá en cola los datos del paquete, y se los pasara a la
aplicación lo antes posible, este flag siempre está activo en conexiones
interactivas como telnet.
FIN: Finish.
Se ha finalizado de enviar datos, aunque se pueden seguir reciviendo.
Para garantizar accesos simultaneos al modulo TCP, el protocolo nos ofrece un
interface de usuario llamado "port", los puertos son usados por el kernel para
identificar los procesos de red, junto con la IP suministran un punto final de
conexión de red, en realidad en cualquier momento todas las conexiones de
internet quedan perfectamente definidas por la dirección IP y puerto del cliente,
y dirección IP y puerto del servidor.
Estructuras de memoria en una conexión TCP
Dependiendo del sistema operativo, las estructuras difieren, veamos las de
linux.
Socket (socket{}): Almacena información relativa a la comunicación local como:
protocolo usado,informacion de direcciones, colas de conexion,
buffers, flags, etc ...
Sock (sock{}) : información específica del protocolo.
Sk (sk_buff{}) : Información mas específica del protocolo incluyendo la
información de cabecera de paquete, contiene tambien un
sock{}.
Backlog : Son unas estructuras de memoria muy grandes.Cada vez que un
server recive una petición SYN de un cliente debe de hacerse
sitio en memoria, de tal forma que si no existiese un número
maximo de conexiones pendientes de verificación, esta
situación nos podria llevar a dejar al server sin memoria
disponible, para evitar esto el server dispone de un
mecanismo de control en el que se especifica el límite de
peticiones de conexión que un socket TCP puede tener
abiertas sin llegar a establecer la conexión , este límite
se conoce como "Backlog", señalar como aquí se encuentran
tanto las peticiones de conexión (3-way handshake), como
las conexiones completadas que aún no han sido aceptadas
por la aplicación.
Este "Backlog" no es número muy grande, y aunque nos
parezca raro, tampoco tiene por que serlo dada la rapidez
que TCP tiene a la hora de establecer conexiones, si
recibimos una petición de un cliente y la cola de "Backlog"
está llena, es más que seguro que al retransmitir el cliente
la petición de conexión ya tendremos de nuevo sitio en la
cola de backlog, en suma se trata pues de un proceso muy
rapido.Existe otro parametro dentro del backlog conocido
como gracia "grace", de tal forma que si se alcanza el
máximo número de peticiones de conexión el sistema dispone
de un margen de gracia para nuevas conexiones.
Valores relaes de backlog en sistemas operativos:
Sistema Operativo Backlog Grace
SunOS 4.x.x 5 3
IRIX 5.2 5 3
Linux 1.2.x 10 0
FreeBSD 2.1.5 128
Win NTw 4.0 6 0
Al ataquerrrrr !!!!
Una conexión TCP se inicia cuando un cliente lanza una petición de conexión
a un server, para ello el cliente manda el flag SYN activado en la cabecera
TCP, al llegar este paquete a un socket receptivo en el server y una vez
demultiplexado el paquete, obtenidas las direcciones de la cabecera TCP y
comprobado que el checksum es correcto, se inicializa un temporizador de 75
segundos pasando la conexión a modo SYN_RCVD (SYN recibido), para ello el
server contesta a esta petición con SYN/ACK, y son creadas todas las
extructuras de memoria correspondientes para la nueva conexión.
¨ Pero que ocurre si la dirección IP obtenida del cliente no es valida, es
decir si el cliente esta mandando una IP que no es la suya (Spoofing) y
ademas esta no esta acesible en internet en el momento de la conexión ?,
en este caso el proceso "3-way handshake" nunca se llegara a completar
con lo que el server esperará los 75 segundos del temporizador de conexión
antes de reinizializarse, puesto que está mandando paquetes SYN/ACK a una
dirección NO en red de la que nunca recibirá respuesta , ¨ Y si ademas
mandamos varios paquetes de conexión de forma que alcancemos el límite de
backlog del server ?, ahora tenemos un puerto "FLOODEADO" si se me
permite la expresión, esto es, el puerto en cuestión no puede aceptar nuevas
conexiones por que está intentando resolver las peticiones tiene en la cola
de backlog, y ademas solo se van a resolver cuando temporicen los 75 segundos.
Caracteristicas
Este tipo de ataque requiere muy poca cantidad de ancho de banda para llevarse
a cabo, puesto que en realidad la cantidad de datos que necesitamos enviar para
floodear un puerto es muy pequeña, simplemente nos bastará con mandar 6
paquetes por minuto para tener un puerto totalmente parado.
*(4)*
Apendice
(1) En el apartado de radius e infovia no me he extendido, puesto que el
árticulo corria el riesgo de hacerse excesivamente largo.
(2) Propongo al avezado lector una practica de agudeza.En el log de llamada
con señalización PUSI, el numero del llamante es la fecha de terminación de
este artículo, el número del teléfono llamado ha sido omitido, ¨Sois
capaces de descubrirlo? :-)
(3) Tambien he incluido un log de lo que recibe un CPI, para terminar con
el bulo de que el proveedor de internet conoce el número de tel‚fono del
usuario, aunque tener claro que si vuestra linea es digital infovia si
que lo conoce. En las versiones anteriores de radius este dato si que era
suministrado al proveedor.
(4) En un principio pense en poner las fuentes de un prog para hacer spoofing,
synflooding, pero teniendo en cuenta de que nunca se sabe en que manos puede
caer lo he omitido.
Por último quiero dar las gracias a "La llave maestra" por los buenos
momentos que me hizo pasar mientras la ojeaba :-))))
En proximos números TCL/TK un interface para el firewall, modulación de
espectro expandido (Enlaces de 2 Mg por radio), acceso a INET por radio,
validación remota de usuarios para los routers, o lo que ustedes gusten
si vuelven a darme otra oportunidad. ;-)
Na2Cl-U2.
sLMa (Sociedad LiMitadisimA).
(C) 1997-2001 by !Hispahack
Para ver el web en las mejores condiciones, usa una resolución
de 800x600 y Netscape Navigator