IPv6
Este articulo pretende ser
una introduccion al TCP/IP convencional y una
explicacion de lo que sera
en un futuro el IPv6 (o lo que se esta
pretendiendo que sea).
La mejor manera de moverse
bien en Internet (y en cualquier red) es saber
como funciona, asi que
intentare hacer una explicacion basica del protocolo
IP actual. Despues pasare a
explicar lo que sera (o pretendera ser) el
protocolo IPv6, asi ya
tendremos alguna idea de como va a funcionar, y
estaremos mas prevenidos y
preparados; para nosotros el futuro ya es
historia, no lo olvideis...
-- IP convencional
-----------------------------------------------------
Empecemos por el principio,
que es saber como se organiza la estructura de
una red (venga, que
comienza el rollo ;-) en el modelo OSI (Open System
Interconnection) tenemos
siete niveles distintos:
* El nivel mas bajo es el FISICO, que se encarga de
transferir la informacion desde un emisor a un
receptor
por un canal determinado, procurando que esta
informacion
llegue a su destino lo menos alterada posible.
* Seguidamente tenemos el nivel de ENLACE, que es el
pavo
que se ocupa de a¤adir bits de control de errores,
paridad,
redundancia y esas cosillas.
* Despues tenemos el nivel de RED. Este individuo se
encarga
de dirigir el trafico de la red, ademas de
conocerla en si
misma para determinar asi el camino mas corto desde
el
emisor hasta el receptor (si, ya se que
Chorifonica tiene
algo chungo este nivel :-D); es aqui donde entra
el
protocolo IP.
* Despues viene el se¤or nivel de TRANSPORTE, que
corrige
los posibles errores que haya podido tener el
nivel de
red, ademas de optimizar sus recursos, que es un
poco
despistadillo el chaval y no se fia un pelo de
el... aqui
entraria el TCP.
* Despues
viene el pollo del nivel de SESION, que mantiene
la conexion y hace los negocios con los parametros
pertinentes
(longitud, full-duplex...).
* Ahora llega el nivel de PRESENTACION, que mas que nada
a¤ade caracteristicas varias, como puede ser una
compresion o un cifrado de los datos.
* Y por fin llega el nivel de APLICACION; con este
nivel es
con el que mas estamos familiarizados. El pollo
este hace
posible la ejecucion de comandos relativos a las
aplicaciones (sirve por ejemplo para poder coger
el correo
via smtp, hacer una sesion telnet o alguna cosilla
mediante
ftp, o incluso para poder navegar por www).
Bien, todo claro? no? pues
venga que te espero...
ya? valen pos sigo...
Asi pues os debe haber
quedado claro que no debemos mirar al IP como una
unica cosa aislada.
Recordemos que un protocolo es una serie de normas. Estas
normas constituyen el
protocolo.
TCP es el pavo que se
encarga de fraccionar la informacion en forma de
paquetes (debes recordar,
lo repetimos no se cuanto ya en SET, que la
conexion no es continua
aunque parezca lo contrario. Se forma mediante la
recepcion de miles de
paquetitos chiquititos unos detras de otros, miralos
ellos que monos) y los
enumera para que en el destino puedan juntarlos y
obtener asi la informacion.
Vamos a hacer un esquemita:
.-------------------------------------------------------------------.
|
imaginemos que esto es la informacion |
`-------------------------------------------------------------------'
Ahora viene el IP y le dice por donde tiene que ir.
Me salto los dos niveles anteriores porque son
bastante
obvios.
.-------------------------------------------------------------------.
| |
`------------------------------------------------.------------------'
.--.
servidor .---. UA |
|
|-----------------------|
|---------'
servidor `-.' Lisboa `---'
| .---------------.
| | |
.-----'-.--------------------| |
servidor--Madrid | Tu ordenador
|
| |
`---------------'
Vale, ahora ya tiene el camino, vamos a cortarlo
TECEPEEEE, vente paca cai que cortar esto, jodio!
no
.------------. .-----. .--. .------. .---------. .--.
.----------. .-. me
| 65 b | | 12 b| |1b| | 30 b | | 50 b
| |1b³ | 60 b | | | ca
`------------'
`-----' `--' `------' `---------' `--' `----------' `-' be
lis
to
Valen, ahora que, a enviarlo, pos venga...
le toca al nivel de sesion y presentacion
<Sesion> Eh
tu, que va un paquetito de 65 b.
<Tu ordenador> Valen, mandemelo tio...
<Presentacion> Espera que lo cifro por si las moscas;
entre tu y yo
chaval, la clave es xxxx.
<Tu ordenador> Oky tio! sin problema... Ya lo he pillao.
<Sesion> Ya?
Pues toma otro de 12 b.
<Tu ordenador> Vale, que bien, este no esta cifrao, menos
curro pa mi.
<Sesion> Ya?
jo que rapido chaval, debes tener una fibra optica
por lo menos! toma uno de 1 b.
<Tu Ordenador> Ya lo tengo! que va, no te creas, solo soy
un Amiga con
un modem de 14.4.
<Sesion>
Vale Transporte, todo Ok! Ya decia yo que no eras de Intel,
bueno, toma otro de 30 b.
<Presentacion> Basta de charla ya no!? yastabien! espera
pavo que te lo
comprimo a ver si te callas!
<Tu ordenador> Jo, como se ha puesto... Ya lo tengo
pesao!
Mientras tanto en algun lugar oscuro de tu procesador, el nivel
de
transporte cuida de que ningun paquete llegue duplicado, que no
tenga
errores y encima va cortando en cachitos la informacion que
viene y la
que se va...
Bueno, esto se asemeja un
poquito a la realidad, pero es solo para que
cojais la idea.
Hasta aqui las siete capas
OSI (aunque en algunos casos son nueve, pero no
quisiera liaros ahora con
eso).
Lo que importa: el IPv4
actual. Todos los ordenadores conectados a una red
deben tener una
identificacion frente a esta, y frente a todos los demas
ordenadores conectados. El
protocolo IPv4 utiliza 32 bits en bloques de 4
bytes. Eso que significa?
que hay 4 bloques, a 1 byte por bloque, lo que
quiere decir que cada
bloque tiene una cifra entre 0 y 255. Hay mucha gente
que se hace un taco con
esto, aunque es bien sencillo. Voy a explicarlo con
mas claridad:
cada ordenador conectado a la red tiene un DNI de 32 bits. Por
ejemplo
11010101110010110011001001110100
Los dividimos en 4 bloques, o sea que nos quedan 8 bits en cada
bloque:
11010101.11001011.00110010.01110100
Y esto nos da un numerillo decimal por cada bloque; por supuesto
podria
coger una calculadora y traducir los numeros de arriba a decimal,
pero
no tengo ganas de ponerme a buscar la calcu... en fin... ahi va:
195.170.23.12
Esta direccion identifica a UNA SOLA maquina conectada a la red.
Aunque
esto no pasa al reves. Una maquina con distintos nodos debe tener
tantas
direcciones IP como nodos tenga.
Algun lumbreras clasifico las direcciones IP en cuatro clases
(A,B,C,D).
* En las redes de clase A el primer byte puede llegar desde 0
hasta
127.
* Las clases B desde 128 hasta 191.
* Las clases C desde 192 hasta 223.
* Aun no he visto ninguna de clase D... no preguntes :)
Bien, veamos ahora que hace cada clase.
* Si la red es de clase A se tienen 128 subredes y pueden
tener 16777216 maquinas conectadas como maximo
(los 24 bits que restan hacen 2 elevado a 24=16777216
posibles
direcciones).
* Si la red es de clase B permite 16384 subredes y 65536
maquinas
conectadas (16 bits restantes: 2 elevado a 16=65536).
* Si la red es de clase C las pueden tener hasta 2097152
subredes
y 256 maquinas con una direccion.
Vale, hasta aqui el IPv4. Cual es el problema? Internet esta
creciendo de
forma exponencial, y ya se van acabando las direcciones, tanto de
red
como de maquina, asi que los chicos de IETF (Intersne Enjiniring
Tasc
Fors) se han puesto a currarse un nuevo protocolo llamad IPng
(next
generation) o IPv6 (ya veras lo que nos vamos a reir). Ahora yo
me
pregunto ¨Que ha pasado con el IPv5?, por favor si alguien lo
sabe que me
conteste, en serio...
Bien, hemos quedado que a falta de direcciones IPv4, se curra la
pe¤a un
nuevo protocolo, IPv6 para poder direccionar a
tropocientosmilymas
ordenadores, pero no nos olvidemos de la red que hay ya (IPv4),
asi que
ademas de desarrollar un nuevo protocolo, este debera ser
compatible con
el antiguo IPv4 (je! como el Gindous 3.1 y el 95 ;).
-- IP version 6 (lo que
sera, o se espera que sea) ---------------------
Ademas de la falta de direcciones del IPv4 se a¤aden dos problemas
mas
que obligan a cambiar el protocolo actual:
* Internet utiliza routers que dirigen el trafico de la red a
partir de
unas tablas de redireccionamiento. Al haber mas y mas
direcciones IP,
estas tablas van creciendo mas y mas y maas y maaaasss, hasta
que...
PIIIM! se acabo...
* El otro inconveniente es que IPv4 no permite establecer
importancia
a los datos enviados (aqui queria yo llegar a parar, a ver
que excusa
ponen para esto). A ver, dicen que esto es necesario por
ejemplo en
aplicaciones de video y audio, asi, los de video y audio
tendran un
flujo continuo de datos, mientras que las news o el e-mail
tendra un
nivel de importancia menor. (ahora me pregunto yo... que
pasaria si
yo, que tengo mucha pasta, voy al encargadillo de alli de
Internet y
le digo que mi empresa necesita un flujo de datos continuo,
que si le
podria hacer un arreglillo, que si un jamon, que si no lo
hundo, que
mis datos son muy importantes, le como la olla, paqui
palla... Esto
seria algo discriminatorio para con los demas internautas,
no? Ya
esta el asqueroso poder haciendo de las suyas de un fenomeno
extraordinario como es Internet).
Pasemos al tema tecnico:
Lo que destaca mas de este protocolo es que pasa de tener una
direccion
de 32 bits (4 bytes) a tener una de 128 bits (16 bytes). es decir
que 2
elevado a 128 da un total de... 3.401 x 10^38, que viene a ser
algo asi
como un 3 seguido de 38 ceros (unas cuantas mas que el IPv4).
Ahora viene
lo interesante: los paquetes contienen unas cabeceras donde se
encuentra
la informacion de control para su viaje (jur jur jur! esto se
calienta).
Se han a¤adido mejoras en la confidencialidad (jajajajja, que
risa) y
autentificacion; los datos estan encriptados y no existen
extensiones que
permitan identificar al usuario (AJAJJJAJJAJJAJAJAAIU, permitidme
que
dude un poco eso).
Lo interesante:
Las cabeceras suplementarias son (esto son las cosas con las
que
podremos jugar):
* cabecera de fragmentacion:
utilizada por el emisor para mandar paquetes de un
tama¤o superior al que se puede enviar (creo que se
van a
poner aun mas de moda los nukes).
* cabecera de encaminamiento:
aqui el emisor establece una lista de nodos
intermedios que
debe seguir el paquete hasta llegar a su destino.
* cabecera de autentificacion:
que sirve para asegurar la integridad de los
paquetes
(desde luego mi paquete si que sigue integro ;)
* cabecera de confidencialidad:
que encripta los datos para protegerlos.
Vale, todo esto no serviria de nada si este nuevo protocolo no
mantuviera una compatibilidad con el anterior, asi que la
manera de
expresar las direcciones IP debe ser parecida; veamos como se
lo han
montado:
* una de las maneras podria ser representar ocho bloques de
2 bytes
cada uno (quedamos que era una direccion de 16 bytes=128
bits).
Esto se haria asin:
1523h:4AF7h:567Ah:B543h:A45Eh:4444h:12ACh:D634h
esta es la que mas se esta utilizando. Id preparando lapiz y
papel para apuntarlas! yo me se unas cuantas de memoria,
pero de
esta manera no se va a acordar ni su padre.
* la segunda manera es sustituir por "::" los
ceros consecutivos,
asi que la direccion 1234h:0:0:0:0:0:0:122Fh se podria
escribir
como 1234h::122Fh. Eso ya me empieza a gustar...
* la tercera manera (que practicamente ya les tiene
convencidos) es
la REALMENTE compatible con IPv4. Seria poner seis
bloques de 16
bits y cuatro bloques de 8 bits (IPv4). aver, mas o menos
seria
asi:
h:h:h:h:h:h:d.d.d.d
o algo asi:
0:0:0:0:0:4AF7:195.170.23.12
o lo que es lo mismo
::4AF7:195.170.23.12
Bien, ahora asi, como tema de reflexion: ¨Os imaginais a
telefonica
poniendose al dia en esta cuestion? JAJJJJAAJAJAJ, me descojono
solo de
pensar la que pueden llegar a montar (por cierto, un saludo
chicos!).
IPv6 sera una presa facil al principio; petara mas que una
escopeta de
feria.
Que os parece? divertido, no? sacad vuestras propias
conclusiones, pero
yo creo que este protocolo es una muestra mas de como el poder
y el
dinero son aliados; el poder ha visto dinero en Internet y aqui
lo
teneis; la utopia de cualquiera al que le guste la informatica
tirada
por los suelos. Una muestra mas de fascismo indirecto. En
fin... que le
vamos a hacer; uno de mis dos sue¤os con respecto a la
informatica
seria montar una red que se auto-expandiera (como es el caso de
Internet o Fido). El otro es hacer un Sistema Operativo...
Igual soy
poco realista, pero hay que intentarlo. Mi madre suele decir
"No sue¤es
tu vida, vive tus sue¤os", y aqui me encuentro escribiendo
en una
revista de hackers... Yo no me considero hacker, ni siquiera
pienso que
se, por que en realidad no se nada, al igual que todos
nosotros, no
sabemos nada... per hay que intentarlo...
Bien, espero que mi debut
en SET haya sido satisfactorio para todos.
Lamento la peque¤a clase de
etica :))
Un saludo!
Tyako Hatsumaru
SMTP
-[ 0x0F
]--------------------------------------------------------------------
-[ SNMP
]--------------------------------------------------------------------
-[ by UnderCode
]-----------------------------------------------------SET-17-
ttttttttttt cccccc ppppp
*** iiiiiiiii ppppp
ttttttttttt ccc
cc pp pp
*** iiiiiiiii pp
pp
ttt ccc pp
pp *** iii pp pp
ttt ccc pp
pp *** iii pp pp
ttt ccc ppppp *** iii ppppp
ttt ccc ppp ***
iii ppp
ttt ccc ppp *** iii ppp
ttt ccc cc
ppp *** iiiiiiiii ppp
ttt cccccc ppp
*** iiiiiiiii ppp
SMTP
Simple Mail Transference Protocol
(protocolo de transferencia simple de
correo)
-------------------------------------------------------------
Buenas, buenas, otra vez yo desde el cono sur intentando
llegar a la
comunidad del under informatico.
En esta ocasion les traigo algo de TCP/IP el conjunto de
protocolos base se
Inet. Este peque¤o articulo intentara explicar un poco que
es el SMTP y como
utilizarlo, previo a esto debo aclarar que algunos terminos
requieren un
cierto conocimiento previo (solo elemental) sobre el
protocolo TCP/IP, pero
intentare ser lo mas claro posible, para eso voy a dividir
el articulo en
dos partes: teorica y practica (ya me parezco un profe de
la uni, no?). Si
a alguien no le interesa la palabreria, puede pasarse a la
segunda parte que
es mas entretenida, o bien saltarse la nota completa que el
resto de la
revista esta de seguro mejor que esto.
1a Parte (aburrida)
TEORIA: donde se encuentra el Correo Electronico dentro de
TCP/IP
=======
Bueno, el protocolo TCP/IP se hizo bastante popular en los
ultimos tiempos
debido a la masificacion de Internet, la cual lo usa como
protocolo base, por
lo tanto es obligacion (si, asi es!!!) que conozcamos que
es y como funciona
TCP/IP.
Por ahora solo voy a explicar un poco como se maneja el
mail en Internet sin
entrar en demasiados detalles.
TCP/IP es un conjunto de protocolos dispuestos en forma de
capas la cantidad
de estas capas varia de acuerdo a distintos autores, pero
por lo general se
definen de 3 a 5 estratos.
Dentro de esta pila existe una que esta en el ultimo nivel
denominada "capa
de aplicacion", esta capa esta formada por las
aplicaciones y procedimientos
que usa la red.
Como decia, dentro de TCP/IP existe la capa de aplicacion,
esta contiene
todos los servicios que podemos utilizar como usuarios de
una red TCP/IP
(Internet es solo un caso de red montada sobre el, pero no
es necesariamente
la unica), dentro de estas aplicaciones que ya conocemos
encontramos FTP,
Telnet, SMTP, HTTP, etc. Veamos
que es eso del SMTP. No se me duerman que es
interesante.
Ok, todos conocemos el e-mail, no?...cierto, es una de las
aplicaciones mas
ampliamente difundidas en lo que a Internet respecta. Si
alguno quiere
enterarse del formato utilizado para la correspondencia,
puede leerse la
RFC 822. La definicion que alli se establece solo permite
el intercambio
de mensajes constituido por lineas de texto ASCII. No se
distingue entre
el mensaje y el sobre (huh?), es decir, todos los mensajes
son tratados
como una pieza unica dentro de la cual existen campos de
cabecera, estos
campos tambien son conocidos por todos quienes alguna vez
enviamos un mail:
subject, to, from, cc, etc. Estos
campos son palabras claves ASCII que se
colocan al principio de los mensajes seguidos por dos
puntos (:) y el valor
del mismo a continuacion.
Bueno, dentro de la capa de aplicacion tenemos las diversas
aplicaciones (que
mas podria haber?), pero estas a su vez poseen diversos
protocolos para su
funcionamiento, en el caso del mail se llama SMTP, este nos
permite el manejo
de la red de correo electronico. Por lo general una
aplicacioon de correo
electronico se ejecuta en un host (digamos server del ISP),
donde cada
usuario con acceso posee un buzon (o mailbox si se quiere).
Cuando
ingresamos al host (por el puerto 25) podemos enviar
mensajes a otros
usuarios del mismo y leer nuestros mensajes en el buzon que
tengamos
asignado.
Estos buzones son mantenidos por el sistema de
administracion de archivos,
son simplemente directorios que contienen archivos de texto
(nuestros
mensajes).
Pero si se desean intercambiar mensajes con los otros host,
SMTP tambien
cuenta con los mecanismos que lo permiten, de modo que no
solo podemos
intercambiar mensajes con los usuarios de nuestro host,
sino tambien con
distintos host dentro de la red, y, obviamente, sus
usuarios.
El protocolo SMTP envia los mensajes de la siguiente
manera: el host recibe
el mensaje preparado por el servicio de correo. Al recibir
el mensaje, se
utiliza el TCP para para enviarlo, al igual que para
recibir los mensajes.
Como el SMTP no tiene especificada la interfase de los
usuarios, estos no
pueden distinguir el caso en que se envie correo local (en
el mismo host)
o remoto (a traves de la red hacia otro host).
Los clientes de e-mail permiten la lectura de los archivos
que hay
almacenados en los buzones de los usuarios autorizados como
asi tambien el
envio de mensajes que el servidor de e-mail se encarga de
distribuir. A
estos servicios se los conoce como servicio de e-mail y lo
ofrecen diversos
daemons, entre estos esta el famoso "sendmail".
Digo famoso porque es el mas utilizado en la actualidad
entre los host de
Internet. Se lo llama tambien "delibery", asi que
si ves esto en lugar de
sendmail por ahi, es lo mismo, aunque por lo general
(siempre diria yo) vas
a encontrarte con sendmail.
El sendmail funciona atendiendo de modo constante el puerto
25, conectandose
con daemons de otros sistemas para intercambiar mensajes.
Bueno, si me siguieron hasta este punto, aqui les doy su
premio jejee...
2a Parte (lo divertido)
PRACTICA: Como utilizar el SMTP
========
Quien mas, quien menos, todos alguna vez vimos en las zines
de H/C/P/V o
libros y revistas de informatica un listado de puertos de
TCP. Quien mas,
quien menos, tambien habra leido informacion sobre el
escaneo de puertos.
Tratare de aclarar como utilizamos el puerto 25.
Luego del respectivo scan a un determinado blanco (linda
forma de definirlo,
no?) obtenemos una lista de los puertos que este tiene
abiertos, digamos 80,
21, 25, etc...25 dije?...ese es!!
Por ejemplo, luego de un port scan a mi web (?)
www.undercode.com
encontramos que tiene abierto el puerto 25. Listo, el paso
siguiente es
conectarnos al host mediante Telnet al famoso puerto 25 de
mail. Todo lo
que este precedido por un numero son las respuestas del
host, las lineas
con # son solo comentarios mios.
$ telnet
telnet> open www.undercode.com 25 # llamamos al sistema por el
# puerto de mail
220 UNDERCODE.MAILSERV SMTP # esta presentacion varia de un
Service at 15 Nov 98 03:05:13 GMT # sistema a otro,
en algunos
# casos hasta se nos indica que
# version de sendmail
se esta
# usando
HELO undercode # se le indica al server quien es
# el usuario que esta en sesion
250 UNDERCODE.MAILSERV - Hello, undercode # la maquina remota me saluda :-)
Ahora vamos a mandar un mail:
MAIL From: undercode@undercode.com
250 MAIL accepted
RCPT To: bgates@windoze.com # :-)
250 Recipient accepted
DATA # le indicamos que lo que
sigue
# sera el texto del
mensaje
354 Start mail input; end with
<CRLF>.<CRLF> # muy importante: al finalizar el
# mensaje hay que
indicarle al
# host que termino,
esto se hace
# con una linea que
solo tiene un
# punto "."
Date: Wed, 15 Jul 98 03:06:50
From: undercode@undercode.com
To: bgates@windoze.com
Subject: Promocion!!
Se~or Gates, tenemos un nuevo servicio en limpieza y
cuidado del cabello,
si le interesa, solo responda a este mail indicandolo.
.
250 OK
QUIT
221 UNDERCODE.MAILSERV.COM Service
closing transmission channel
Como se ve el servidor envia sus respuestas con un numero
delante, estos
tienen distintos significados de acuerdo con la primera
cifra, si:
-----------------------------------------------------------------
| Empieza con
| Significa |
-----------------------------------------------------------------
| 2
| Operacion ejecutada satisfactoriamente. |
-----------------------------------------------------------------
| 3
| Se requiere una accion a continuacion. |
-----------------------------------------------------------------
| 4 | Error temporal.
Ej. el disco esta lleno. |
-----------------------------------------------------------------
| 5
| Error permanente. Ej. no existe el recipiente. |
-----------------------------------------------------------------
En el caso de un error temporal (4) los mensajes se guardan
y se envian mas
tarde, en cambio cuando el error es permanente (5) el
mensaje es devuelto al
emisor indicando un codigo de error.
Veamos lo que hicimos antes, al iniciar con HELO se indica
el nombre del
sistema (o usuario) que inicia la conexion con el sendmail.
Luego con MAIL
indicamos que estamos por enviar un mensaje y RCPT le
indica al daemon a que
destino ira dirigido. Por ultimo DATA contiene el mensaje
en ASCII, recuerden
que habia comandos que se introducian en el cuerpo del
mensaje, ya vimos como
se le indico la fecha (Date:), el origen (From:), el
destino (To:) y el
asunto (Subject:), recuerden finalizar el mensaje con una
linea que solo
contenga un ".". En el caso que se quiera enviar
en el texto del mensaje
un punto como linea, se deben colocar dos puntos seguidos
".." para que el
sendmail lo interprete como texto y no como final de DATA.
Creo que QUIT no es necesario que lo explique, verdad?
Bueno esto es lo que podemos hacer para enviar mensajes
desde telnet sin usar
cliente de e-mail alguno, pero aqui se presenta una
situacion que no habia
mencionado: cuando nos conectamos por el puerto 25 al host
este nos recibe y
por lo general nos indica la version de sendmail que
utiliza, pero nunca nos
pide login ni password para entrar, salvo que queramos ver
los mensajes de
algun buzon que tenga alojado. Probemos entonces enviar un
mail sin hacer
HELO, a ver...
open UNDERCODE.MAILSERV.COM 25 # es el nombre del servidor de
# mail que aparecio antes
220 UNDERCODE.MAILSERV SMTP
Service at 15 Nov 98 03:08:13 GMT
MAIL From: steve_jobs@apple.com
250 MAIL accepted
RCPT To: bgates@windoze.com
250 Recipient accepted
DATA
354 Start mail input; end with
<CRLF>.<CRLF>
Date: Wed, 15 Jul 98 03:06:50
From: steve_jobs@apple.com
To: bgates@windoze.com
Subject: ladron!!!
Maldito nerd te robaste mi entorno de ventanas, te voy a
caer encima!!
.
250 OK
QUIT
221 UNDERCODE.MAILSERV.COM Service
closing transmission channel
Como veran el origen del mensaje puede no ser real, y aun
asi el sendmail lo
enviara. El se~or Gates recibira nuestro saludo y de
acuerdo al campo From de
su cliente de correo vera que su colega Jobs le escribio.
Es el metodo que
utilizan los programas de correo anonimo como el AnoniMail
que anda
circulando por ahi. Puede llegar a servir para joder a un
amigo o algo asi,
pero es muy simple de rastrear. Es muy facil de saber quien
envia un mail de
este modo, simplemente viendo las propiedades del mensaje
(en Outlook,
Netscape, etc) se obtiene el servidor de donde proviene, y
como cada sesion
en el sendmail es loggeada....en fin, ya saben.
Otro comando interesante para utilizar es "vrfy",
su sintaxis es
vrfy <usuario>
Donde usuario (sin los <>) es algun usuario
registrado en el servidor, si el
usuario existe este comando nos dara bastante informacion
del mismo, y si no
nos indica un mensaje de error. Puede ser util a la hora de
hacer Ingenieria
Social contar con algunos datos de la persona, no?
Listo, hasta aqui llegamos por ahora, si alguien lo desea
puede probar otras
cositas del sendmail, esto solo era una introduccion para
quienes deseen
aprender un poquito de SMTP y como lo utilizan los clientes
de mail, ya
saben si tienen algo para comentar, criticar, agregar, etc,
de esta nota,
mi mail y llave PGP estan a su disposicion.
UnderCode
<++> keys/UnderCode.asc
Tipo Bits/Clave
Fecha Identificador
pub 1024/488E0455 1998/10/09 UnderCode <undercode@iname.com>
-----BEGIN PGP PUBLIC KEY
BLOCK-----
Version: 2.6.3ia
mQCNAzYeNK4AAAEEANDRJ8J/6+qrXdpaTgZwUSgfbVZ8QAxQlWOcS3np2UPkdzfN
UlEnHnwSe/3Hy653MOthzivtyfyJPtGrYJffeRhwWMcjR/Gy1sg0SHus1NQFbqcP
7j4isB1xat08Ezt1a9eSNp7UUk6FHbo9MV05r/2a6o9bXVSG4F/BxOZIjgRVAAUR
tB9VbmRlckNvZGUgPHVuZGVyY29kZUBpbmFtZS5jb20+iQCVAwUQNh40rl/BxOZI
jgRVAQFrvQQAjPB3N41j7eggukyYp1gbY1+gaS3zzRXroOd46uIEADQb0dWRVQPz
LcjTT8G5Qm4orzjvtQV8r6G3A0aPNuOoq/mkzj30yDFgz0J55UUdT7GnFsKNplQE
26gho+0Ek3Zctad63Dz3AzK5RsRrLlCre5RhIYBf3s4ursJXX7CiBys=
=KAfp
-----END PGP PUBLIC KEY BLOCK-----
<-->
--oo>>>> INTRODUCCION AL TELNET (I)
<<<<oo--
by Krip7iK
El primer dia ke entre en cierto canal irc de hack donde
habia numerosos
primerizos una de las preguntas que mas tuve que responder
tenia que ver con
esta utilisima herramienta, tan desconocida por todos los
que comienzan en
internet (en gran medida por la arrolladora fama del web,
irc etc.). Bien, con
esta serie de articulos pretendo, o mejor, pretendemos
hacer frente a todas
esas dudas y preguntas en lo que al telnet concierne.
En este primer articulo de esta serie yo me encargare de
explicar las nociones
mas basicas, y si no me agobia el tiempo y sigo con ganas
comenzare con
alguno de los puertos mas tipicos y utiles, el 25 (SMTP,
envio de correo).
Como en el resto de articulos que estoy redactando,
intentare partir de lo mas
basico. Y como no, puede que lo mas basico requiera
recordar aquellos tiempos
en que usaba algo mas que ahora el famoso WINDOWS. Bien,
telnet, no es mas que
un programa basado en el
modelo cliente/servidor, haciendo este de cliente,
con la particularidad de que no esta limitado a ser
utilizado para un solo
tipo de servidor, como veremos a continuacion.
Dicho programita lo encontraremos en casi cualquier S.O.
que tenga soporte
para redes TCP/IP, (como ejemplos mas normales, en
cualquier tipo de UNIX
(Linux, FreeBSD, Irix, Solaris...y demas), como en los S.O.
del Micro$oft
(NT,W95, W98), e incluso sin haber tocado uno desde tiempos ancestrales
aseguraria que los S.O. de Mac tb. poseen esta
herramienta), vamos...
practicamente cualquier sistema operativo que utilicemos
para acceder a
internet (me olvidaba del OS/2!!), poseera un cliente
telnet que podamos
utilizar. No sere yo quien me dedique a explicar como
arrancar todas y cada una
de las diferentes presentaciones del telnet dependiendo del
S.O, pero si
dire al menos que en UNIX, basta con ejcutar el comando
telnet, al igual que
desde una ventana de MS-DOS en los sistemas?? de
BillyPuertas (estos ultimos
tb. permiten una ejecucion usando unos menus... pero eso os lo dejo pa
vosotros, ademas me parece menos directo). En ambos casos
los parametros a
pasar al ejecutar el cliente telnet son los mismos:
telnet DNS|IP
<PORT>
esto es, a continuacion del comando deberemos especificar a
que makina
deseamos acceder mediante telnet, ya sea mediante su
nombre, o mediante su IP,
y opcionalmente a que puerto concreto, por defecto nuestro
cliente tratara de
engancharse al puerto 23 (telnet, donde se nos proporciona
una shell del
sistema). Sobre los puertos hablamos a continuacion.
¨¨Que hace el cliente telnet?? Simplemente trata de
conectarse a un programa,
que hace de servidor de este, alojado en la makina ke le
indiquemos. ¨¨Como
sabe a cual de los multiples programas que pueden hacer de
servidores de el
en la maquina remota debe engancharse??... Ahi es donde
entran en juego los
puertos (puertos software) del host remoto. Los puertos
software serian algo
asi como procesos "corriendo en el fondo", quiza
ni siquiera corriendo,
simplemente esperando una llamada para activarse, de modo
que cuando
conectamos a una makina debemos especificar tambien a que
puerto de esta
deseamos ser conectados, activando asi un servidor
determinado, en el caso de
que el puerto que hemos especificado este abierto, esto es
con algun daemon
(server) asociado, y activado.
Bueno,bueno... ya estamos mas o menos situados no?? Veis
ahora por donde
andan las capacidades de telnet???... casi todo en internet
verdad??. Si aun
no os habeis situado, o no veis cual es su capacidad espero
que la siguiente
lista con los puertos mas tipicos y basicos os sirva para
haceros una idea;
incluire tan solo unos pocos puertos, los mas usados,
utiles, o de servicios
mas famosos, para un mayor detalle de los numeros de
puertos y los servicios a
los que estan asociados ver: TCP ports--> RFC793; UDP
ports--> RFC768; en el
/etc/services de vuestro LINUX; o bien simplemente
conseguid el texto
port_n.txt (muy completo y rapido de consultar) que
procurara nuestro
web-master (Luk!) colocar en la seccion de archivos del web
(espero que este
para cuando salga el primer numero... pero no aseguro
nada... delego esta
responsabilidad en Luk, asi ke ya sabes compa¤ero!!!).
Como decia aqui van los puertos que oireis mas
frecuentemente, junto con los
protocolos que soportan y una brevisima descripcion:
PUERTO
PROTOCOLOS NOMBRE DEL SERVICIO DESCRIPCION
7 tcp/udp echo repite lo que
enviemos
11 tcp/udp systat info de los usuarios
activos
13 tcp/udp daytime dia y hora en
el server
21 tcp/udp ftp File Transfer
Protocol
22 tcp/udp ssh Login Remoto
SSH(secure Shell)
23 tcp/udp telnet Telnet...ya he
explicado no??
25 tcp/udp smtp Simple Mail Transfer
Protocol
36 tcp/udp time Lo dice el nombre!!
42 tcp/udp nameserver Host Name Server
53 tcp/udp domain Domain Name Server (DNS)
69 tcp/udp tftp Trivial FTP
79 tcp finger Info sobre usuarios
80 tcp http Web os suena verdad??
101 tcp hostname normalmente en sri-nic
110 tcp pop3 Servidor POP3 de correo.
119 tcp nntp News server. USENET
Bueno, hay miles mas, algunos con servicos estandarizados
que pueden ser
interesantes, ver el archivo recomendado; otros de libre
uso por cada uno
donde podemos encontrarnos algunas sorpresas... o poner
nosotros las nuestras!
Bien, ahora que ya andamos todos bastante situados podria
dejaros a vustro
aire para que experimenteis por vosotros que es lo que pasa
en cada uno de
estos puertos, o que vierais como algunos suelen estar
cerrados... por ke
sera??
Pero como ya prometi al principio del articulo, y como lo
prometido es deuda,
tendre que contaros algo, aunque sea lo mas basico sobre
los demonios que
corren en el puerto 25, smtp, generalmente alguna version
de sendmail.
Como ya habreis deducido o ya sabriais por medio de este
puerto podemos
realizar envios de mail, algo que puede llegar a ser muyyy
interesante.
Como cuento yo esto... bien, creo que con un listado de los
comandos mas
tipicos y un ejemplito bastara no??, la informacion cuanto
mas directa y
clarita mejor no??, y si hay dudas... para eso tenemos la
lista de correo, el
tablon... o en ultima instancia nuestros mails no??.
Entonces comencemos con los comandos:
HELO
MAIL FROM:
RCPT TO:
DATA
HELP
Procedimiento a seguir para enviar un e-mail:
Bueno, lo primero... como es logico sera encontrar una
makina con su puerto 25
abierto; si probais con nombres como smtp. o mail. ISP de
internet o cualquier
dominio en general, encontareis rapidamente servidores smtp
(de envio de
correo, o sea con el 25 abierto). Bien, ya tenemos la
makina, entonces solo
queda acceder... (lo presentare como en mi makina ocurre,
cada uno que se
marque su caso analogo ok??, ah si, en mi makina soy root!!
;)) os sorprende?
(XDD).
--------------------LOG--------------------
[root@B4z3_z3r0/]#telnet
smtp.makina.es 25
Trying XXX.XXX.XXX.XXX
Connected to smtp.makina.es
Escape character is '^]'.
[si ahora os dice: Connection closed by foreign host.
entonces es que la
makina en
cuestion tiene el puerto 25 cerrado]
220 smtp.makina.es ESMTP Sendmail
8.8.7/8.8.7; Fri, 19 Mar 1999 22:18:23 +0100
help [ponemos esto para ver que comandos acepta]
<------***!*!*!*
214-This is Sendmail version 8.8.7
214-Topics:
214- HELO EHLO MAIL
RCPT DATA
214- RSET NOOP QUIT
HELP VRFY
214- EXPN VERB ETRN
DSN
214-For more info use "HELP
<topic>".
214-To report bugs in the
implementation send email to
214- sendmail-bugs@sendmail.org.
214-For local information send
email to Postmaster at your site.
214 End of HELP info
[Bien ahora vamos al grano... el resto os lo dejo para ke
experimenteis!!]
mail from: yo@meloinvento.com [Esto seremos nosotros!!jeje] <----*!*!
250 yo@meloinvento.com... Sender ok
rcpt to: victima@email.com [A
quien vamos a escribir hoy???] <--!*
250 victima@email.com... Recipient ok
data [para
iniciar a decir cosas] <----!**!*
354 Enter mail, end with
"." on a line by itself
Esto es un mail anonimo... bueno.. casi!!, luego explico
por que casi.
Cuando quiera acabar el mail... solo tengo ke hacer caso de
la linea de un
poco mas arriba y poner un punto en una linea como voy a
hacer ahora!!
. [Esto termina
nuestro mail] <------*!*!*!*!*
250 WAA00978 Message accepted for
delivery
quit
221 smtp.viktima.es closing
connection
Connection closed by foreign host.
--------------------LOG--------------------
Y con esto hemos acabado el ejemplo practico!!!.
Utilidades y Limitaciones:
Creo ke la utilidad ha kedado patente en el ejemplo de un
poco mas arriba no??.
Bien, nos sirve para enviar mail desde donde keramos...
siempre ke tenga el
puerto 25 abierto. Si keremos ke se vea desde donde lo
enviamos solo hay ke
poner un nombre (en teoria el ke seria nuestro nombre de
usuario) sin @lokesea
detras en el comando mail from: , y si lo ke vamos a hacer
es dejar un mail a
un usuario del servidor smtp en el ke estamos, pues en el
rcpt to: solo habra
que poner su nombre de usuario, sin la @hkjhsak ok??.
Como veis, en teoria podriamos hacernos pasar por
cualkiera!! no creeis??.
Problemas... uno bastante gordo es que algunos servidores
smtp no dejan ke en
el mail from se ponga cualkier cosa, pero eso solo pasa en
algunos, la mayoria
te deja, pero tb. esa mayoria envian una informacion
adicional que no nos hara
mucha gracia ke sea enviada si lo ke keriamos era falsear
un mail o hacer mail
anonimo... esa informacion adicional que envian se puede
ver con muchos
programas de gestion del correo, y tiene la forma:
--------------------LOG--------------------
Return-Path:
<masfalso@kejud.as>
Received: from smtp.viktima.es
(nuestra.procedenc.ia [ip.xxx.xxx.xxx])<--OJO!!!
by destino.es (8.8.7/8.8.7) with
SMTP id WAA00989
for victima@no.tan.pardillo.es;
Fri, 19 Mar 1999 22:36:59 +0100
Date: Fri, 19 Mar 1999 22:36:59
+0100
From: masfalso@kejud.as
Message-Id: <199903192136.WAA00989@viktima.es>
X-Authentication-Warning:
smtp.viktima.es: nuestra.procedenc.ia -->>
-->> [ip.xxx.xxx.xxx] didn't
use HELO protocol X-Status: N
Status: R
Return-Receipt-To:
Esto es mas falso ke Judas!!.
--------------------LOG--------------------
Esto es lo que yo por ejemplo veo en todo el mail ke me
llega, y como veis con
una simple mirada y revision puedo ver el recorrido ke
habra llevado el mail
hasta llegar a mi. En este caso ha sido bastante directo,
pero podria ser mas
complicado. Como veis el servidor smtp ke hemos usado
refleja nuestra IP !!!!
Esto es lo ke no nos permite hacer mail anonimo, a no ser
ke nuestra IP, no de
gran informacion sobre nosotros... pero eso es otra
historia (seguid leyendo
esta DP ok?).
El que el server refleje nuestra IP de procedencia es lo
mas normal, pero
quiza podamos encontrar algun server corriendo un daemon
antiguo que no
implemente este hecho, esto es ke no refleje nuestra IP...
buscad!!, si hay
suerte me avisais OK!! Pero yo no os recomiendo realizar
esa busqueda...seria
mas facil modificar nuestro daemon, para ke no envie
informacion de nosotros, o acceder a
ese server de smtp desde una makina a la ke hayamos
accedido antes (hacer el
telnet viktima.es 25 desde una shell en otra makina), o
simplemente
conseguirnos una IP, ke no diga mucho de nosotros,...
incluso se me a pasado
por la cabeza ultimamente el intentar hacer un ataque
IP-spoofin (falseo de
IP; a lo mejor escribo algo sobre esto para algun numero
siguiente... solo
teneis ke pedir!!), pero en lugar de usarlo para saltar un
firewall o hacer un
acceso a una shell, para hacer un envio de e-mail... pero
bueno, eso lo dejo
caer, por si alguno con mas conocimientos se anima, yo por
mi parte si
encuentro tiempo (siempre ando pillado!!! :(( ) intentare
algo en esta linea
(ya os informare si consigo algo!!).
Como ultima reflexion... recomendaros utilizar un buen
programa para el
correo. En LINUX cualkiera es bueno (al menos los mas
comunes dan toda esta
info). En Windows... no estoy muy puesto, pero creo ke
Pegasus la da, y seguro
ke muchos mas, conseguid uno de esos. Ademas aparte de la
ruta ke siguio el
mail, podemos saber ke programa uso para el envio, si lo
hizo con alguno o a
pelo... Mucha informacion util!!!.
Bien... esto va a ser todo sobre el telnet en este numero,
seguiremos con este
tema en los siguientes numeros, tratando otros puertos, y
lo ke se nos pueda
ocurrir sobre ellos, incluso si nos lo proponemos
amplio/amos este articulo
con bugs/exploits para distintos daemons de smtp, o
bugs/exploits para los
daemons que expliquemos en cada articulo,.. no se, ya
veremos!! ;)) (de todos
modos... solo hay ke pedir.. escribimos por y para
vosotros... ya sabeis donde
enviar las peticiones y preguntas no??
daemons_paradise@iname.com)
Aki Akab0.!!
Krip7iK (kriptik@cyberdude.com)
FDM.
-[
0x0A ]--------------------------------------------------------------------
-[ THE MODEM CONNECTION
]----------------------------------------------------
-[
by Paseante ]------------------------------------------------------SET-19-
THE
MODEM CONNECTION.
=()==()==()==()==()==()==()==()==()==()==()==()==()==()=
Todo
aquello que nunca quisiste saber sobre los modems
pero
nosotros de todas maneras te vamos a contar.
=()==()==()==()==()==()==()==()==()==()==()==()==()==()=
/ '--''--''--''--'\
\ I Introduccion \
\ .--.--.--.--.--. /
Donde explico el motivo del presente.
Breve rollete.
/'--''--''--''--'-\
\ II Habemus Palo \
\ .--.--.--.--.--./
Donde los novicios reciben aburrida teoria en cazos.
Largo rollete.
/'--''--''--''--''\
\ III Genesis \
\ .--.--.--.--.- /
Donde el DTR se encendio y el beep se hizo bit.
Tipico rollete
/'--''--''--''--''--'\
\ IV La Bruja Averia \
\.--.--.--.--.--.--.-/
Donde la culpa se la lleva quien la merece.
Rollete con ilustraciones.
/'--''--''--''--'-\
\ V Parafernalia \
\ .--.--.--.--.--./
Donde se habla de diversas posibilidades.
Rollete
con fundamento.
/'--''--''--''-\
\ A Apendice \
\.--.--.--.--.-/
Donde se muestra la belleza y utilidad del log.
Rollete auxiliar.
<-I-> Introduccion <-I->
~~~~~~~~~~~~~~~~~~~~~~~~~~
Dificilmente encontraremos algo tan omnipresente en las
comunicaciones
actuales como el humilde y simple modem, pieza clave en la
expansion de
FidoNet primero e Internet despues, el modem no ha recibido
toda la
atencion que se merece por parte de sus usuarios. La mayor
parte de las
veces nos conformamos con que funcione o como maximo con
'afinar' la
cadena de inicializacion.
Tampoco los canales de informacion 'alternativa' han
profundizado nunca
en el estudio de los modems, en esta y otras publicaciones
under se ha
escrito de todo tipo de cachivaches minoritarios pero no
del mas popular
periferico de los ultimos a~os.
No creo que sea porque todo el mundo domine por completo
las posibilidades
de su modem, lo achacaria a la falta de interes y
posiblemente incluso de
sex-appeal, tienden a interesarnos mas los equipos caros y
complejos a los
que no tenemos acceso que aquello que vemos cada dia sobre
nuestra mesa.
Hasta ahora solo le pedimos a nuestro modem que nos conecte
a la red y
damos por hecho que ahi comienza la aventura, ahora cuando
el modem se
enfrenta de manera creciente a nuevas tecnologias mas
rapidas y baratas
no olvidemos los momentos, la gente y las cosas que hemos
conocido
gracias a el.
<-II-> Habemus Palo <-II->
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Un repaso general a los conceptos basicos de la
comunicacion con modem.
Ya sabemos todos que el modem "es un periferico
surgido de la necesidad de
usar las lineas telefonicas para la comunicación entre
ordenadores, en
resumen un MODulador/DEModulador transforma la se~al
digital que envia un
ordenador a una se~al analogica que viaja por la linea
telefonica
convencional y que el modem del otro extremo volvera a
convertir en digital."
Un esquema simple de como funciona una
"conversacion" entre modems comienza
con uno de los dos marcando el numero, el otro modem oira
la llamada y
contestara poniendo en la linea un tono que inequivocamente
le distingue como
un modem y una portadora o carrier unos momentos despues,
el modem
llamante esperara a oir una portadora que conoce y
contestara poniendo a su
vez otra portadora en la linea algo mas baja de tono.
Las portadoras se mantienen durante toda la conexion,
cuando dicha se~al se
pierde se acaba la comunicacion (y sin embargo en la
realidad algunos modems
no ponen portadora alguna en la linea).
Una vez que ambos modems han acordado velocidad comienza el
intercambio
de opciones (MNP, V42bis...) mediante un proceso de
Pregunta/Respuesta
hasta que deciden que estan listos para recibir y enviar
datos.
En este momentos muchos modems encienden el led CD (Carrier
Detect)
Con la una conexion establecida podemos empezar a
transmitir datos, aqui
entra en juego la UART, la UART es un chip instalado en el
puerto serie
que se encarga de a~adir a los datos los bits de principio,
final y paridad y
mandarlos de manera sincronizada por el puerto serie.
Hay diferentes versiones de UART, aunque cualquier
ordenador de unos a~os
para aca incorpora alguna revision del modelo 16550. Los
modems internos
llevan su propia UART.
Una de las ventajas principales de las nuevas UARTs es que
el buffer de
recepcion es mayor con lo cual se necesita interrumpir
menos a nuestro
sistema operativo y la multitarea sera algo mas que un
eslogan.
Con la conexion establecida y la UART ocupandose de regular
los envios de
datos llega el momento de preocuparse por los errores, por
cada bit que
enviamos se genera un tono y cuantos mas bits queramos
enviar mas tonos
tendremos que generar en el mismo tiempo. Eso significa que
el ruido o la
baja calidad de la linea que pueden no interferir en
comunicaciones a 2.400
bps pueden en cambio arruinar datos que viajen a mayor
velocidad.
La forma mas simple de correcion de errores es el llamado
"control de paridad"
que consiste en sumar todos los datos de un paquetes y
mandar un bit que
informa si la suma es par o impar. En caso de que el modem que
recibe los
datos no concuerde la suma es que un error se ha producido
al transmitir el
paquete.
Los modems generalmente son capaces de generar tonos que
van hasta los
4800Hz aunque por encima de los 3400Hz dichos tonos estan
atenuados, gracias
a que no solo generan tonos en banda de voz se puede usar
el modem como
un marcador programable DTMF
La tecnica para mandar mas bits en el mismo tiempo
simplemente explicada es
llegar a poner mas tonos en la linea simultaneamente, los
modems de 28.800
bps son capaces de enviar hasta 12 tonos diferentes, con
una resolucion media
de 0.15Hz por lo general donde los de 2.400 bps solo ponian
uno.
El limite, llamado Limite de Shannon, que se ha establecido
para una linea
analogica ronda los 35.000 bps, los modem de 33.600 bps
estan muy cerca de el.
(despues vemos que pasa con tu modem de 56k)
Las 'altas' velocidades hacen que el antiguo control de
paridad no puede ser
eficiente a estas tasas ya que la sensibilidad de los
nuevos modems al
ruido podria hacer cambiar los datos sin llegar a cambiar
la paridad.
Para evitar que estos errores pasen inadvertidos se realiza
una comprobacion
de suma sobre cada paquete de datos, esta operación
matematica reflejara que
ha ocurrido un cambio en el paquete si al ser comparada con
el checksum del
otro extremo no concuerda.
El paso siguiente para mejorar las prestaciones de los
modems es la
compresion, enviar los datos repetidos de una manera mas
eficiente. La idea
basica es que una secuencia como:
01010001 01010001 01010001 01010001 01010001 01010001
01010001
Se envia mas rapidamente diciendo 01010001*7, asi nacieron
normas como
v42.bis y MNP-5 que primero intentan comprimir los datos y
despues ademas se
ocupan de corregir los errores.
Pero si como suele ocurrir te bajas un archivo comprimido
entonces
te puedes comer esas normas con patatas.
Como la velocidad a la que nuestro modem recibe datos suele
ser diferente
a la velocidad de conexion con nuestro equipo surge la
necesidad de
regular el "flujo de datos" del modem al
ordenador.
La tecnica mas antigua de control de flujo es el llamado
"Xon/Xoff" o
control software hoy en dia en desuso.
Llego despues el control de flujo por hardware aplicable
cuando nuestro
modem externo esta conectado a un puerto serie, se trata de
una serie de
se~ales electricas agrupadas en un protocolo llamado RS-232
que
regula el control de flujo y el control de la llamada.
{-}{-}........S.p.e.e.d.........
Los estandares de
velocidad vienen definidos por una organización llamada
ITU-T, esto garantiza que los modems que cumplen dichas
normas podran
negociar la velocidad maxima excepto por motivos de calidad
de la linea.
(Luego hablaremos de eso)
Las normas V.34 y V34.bis son los estandares para las
velocidades de 28.8kbs
y 33.6kbs, en ocasiones algunos fabricantes se adelantan al
estandar
ofreciendo modems mas veloces pero incapaces de dar esa
velocidad al negociar
con modems que no posean la misma norma. Asi modems de 28.8
que alcanzaban
esa velocidad con la norma no estandar V.Fast se comportan
como modems de
14.4kbs con modems de 28.8kbs que cumplen el estandar v.34.
Hoy en dia la velocidad minima seria la de 33.6kbs, ningun
modem por debajo
de esa velocidad merece la pena como nueva adquisicion
salvo que vaya a estar
sometido a requisitos muy puntuales (como por ejemplo
limitarse a enviar
faxes).
Con respecto a la adecuacion a las normas muchos modems
incorporan una
memoria flash que se puede actualizar para que el modem
automaticamente sea
capaz de aumentar su velocidad o incorporar nuevos
estandares. Normalmente
los fabricantes de mayor prestigio hacen disponibles estas
actualizaciones en
sus paginas web para que los usuarios las descarguen
gratuitamente.
- Y como deja lo de los 56kbs al Shannon ese?
Basandose en la asuncion de que uno de los dos modems que
interviene en la
conversacion esta directamente conectado a una linea
digital es posible
superar la barrera de los 33.6kbs y llegar a recibir datos
a 56kbs, el modem
que envia los datos evita convertirlos en analogicos puesto
que esta unido a
una linea digital, los datos siguen siendo digitales justo
hasta que llegan
al "ultimo salto" antes del destino en donde se
convierten en analogicos y
son recogidos por el modem del cliente que los transforma
en digitales de
nuevo.
Al evitar una conversion y ganar en tiempo y calidad es
posible obtener este
aumento de velocidad que en todo caso solo se da en uno de
los caminos
(recepcion) ya que en el modo de envio los datos viajan a
33.6kbs (dado que
el cliente no esta conectado a una linea digital y tiene
por fuerza que
convertir los datos en analogicos para su envio)
Dos tecnologias han pugnado por este mercado k56Flex y X2,
ambas
incompatibles entre si, hasta que finalmente se ha impuesto
el estandar v.90
que garantiza que cualquier modem que cumpla esta norma es
capaz de recibir
datos a esta velocidad.
Muchos modems k56Flex y X2 pueden usar v.90 por medio de
las actualizaciones
anteriormente comentadas.
{-}{-} Nuevas Tendencias:
El baratillo.
HSP y Winmodem (RPI)
Ahora tienes un modem barato y con unas siglas raras,
digamos que has
'adquirido' un HdSPM DeLuxe y quieres saber que diferencias
hay con uno
de esos "Winmodems" o con un modem "de
verdad".
Pues aqui iba a aprovechar yo y largarte otro rollete bueno
pero al final
he pensado que "lo breve si bueno dos veces
breve", digo bueno:
-Modem "de verdad", incorpora en hardware el DAA,
DSP y controlador.
-Winmodem-RIP (Rockwell Protocol Interface), incorpora DAA
y DSP en hard.
-Soft modem o HSP (Hijo de su P* Madre o Host Signal
Processing) incorpora
el DAA y el CODEC
en hardware.
Aclarido? Pues como recomendacion el HSP ni regalado, el
Winmodem solo si
robarlo no representa excesivo riesgo y el modem de verdad
solo si no tienes
otra opcion.
En cuanto a las siglas que no hemos explicado, en dos
palabras...
DAA - Data
Acquisition Arrangement, esto hace que el bicho
se pueda
comunicar por la red timofonica.
DSP -
Digital Signal Processor. El corazon del melon.
Como regalo
a~adido viene con el CODEC
CODEC -
Termino muy usado que viene a ser la abreviatura
de
CODificador/DEsCodificador.
Controlador
- Ya deberias saber lo que es esto.
Y como afectan estas diferencias al funcionamiento y rendimiento?.
Ya
me parece que quieres saber mucho tu. :-)
Un Winmodem (o controller-less modem en jerga 'tesnica') no
afecta en
exceso al rendimiento, lo unico que cambia es que necesita
un driver por
software para poder usar la CPU como controlador del modem.
En un sistema moderno esto no supone un impacto muy grande
en el rendimiento
diario del sistema.
Un HSP (o soft-modem en jerga 'tesnica') incorpora en su
placa solo la
DAA y el CODEC, eso significa que tanto el trabajo del
controlador como el
del procesador DSP lo tiene que hacer nuestro ordenador. Es
por tanto
mas "pesado" para el sistema que un Winmodem y
hace uso mas intensivo de los
recursos del PC. Claro que si tienes uno de estos PII
350Mhz y solo quieres
enviar faxes de cuando en cuando......
Por ultimo solo nos queda comentar para acabar la
introduccion que el
control del modem se realiza mediante el set de comandos AT
de Hayes
(comando at, comando at, siempre alerta estan!!) aunque hay
algunas
extensiones propias de cada fabricante
Normalmente los comandos Hayes solo se utilizan por el
usuario para pasar al
modem la configuracion de inicio deseada aunque tambien
pueden hacerse servir
para obtener mas informacion sobre el mismo modem y sus
posibilidades.
usualmente la cadena que nos salvara es AT&F que carga
la configuración de
fabrica por defecto.
[Volver arriba y releer cinco veces? S/N]
<-III->
Genesis <-III->
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Pues ahora es cuando empezamos a usar esos comandos AT para
ver que es lo
que hacemos y donde estamos. Aclarar antes de empezar que
esto de
"compatibilidad Hayes" no asegura que todos los
modems tengan todos los
comandos ni que los mismos comandos no hagan cosas
diferentes en distintos
modems, de hecho las hacen, pero aunque los mismos comandos
proporcionen
informaciones diferentes o tengan otros usos dependiendo
del modem, las
diferencias no suelen ser muy grandes. En fin, que todos
sabreis lo que
significa "compatible" en Informatica........
Asi que abrimos nuestro programa de terminal (esto es
cualquier programote
que nos permite enviar comandos al modem y si es posible
ver la respuesta)
y vamos a ver que trasto acabamos de mangar.
ATI: Identificacion
del modem
La familia "ATI" nos va a dar mucha informacion,
particularmente resaltemos
a:
ATI3-ATI5 y ATI11.
Que nos van a devolver informacion sobre velocidad,
fabricante, revision del
firmware y muchas cosas mas que varian de modem a modem.
Con los varios ATI ya sabemos mas o menos a que marca
pertenece nuestro
modem y podemos ir a la web a ver si hay actualizaciones
porque tenemos
los numeros de version del firmware pero que carajo de
configuracion
carga el modem por defecto?
AT&V: Muestra la configuracion activa y los perfiles
almacenados.
AT\S: Parecido pero en mas bonito y algo mas explicativo.
Ahora ya sabemos que modem tenemos e incluso que *opciones*
tenemos
activadas y cuales no, ademas nos ha dado el valor de
algunos registros
que contienen datos de importancia.
Estos registros (registros S) guardan toda una serie de
valores que
afectan de manera fundamental al rendimiento y las
capacidades de nuestro
modem.
Para leer un registro S:
ATSn? (Muestra el
valor del registro Sn)
Para cambiar el valor de un registro S:
ATSn=x (n numero registro, x valor que contendra)
Por ejemplo el registro S82 contiene el modo en que se
trata el break, segun
su valor podria hacer que al recibir la se~al de break
desde el modem remoto
[AT\B] nuestro modem borre todos los datos del buffer.
Y por ejemplo, el registro S0 contiene el nº de rings que
nuestro modem
espera antes de contestar al telefono, con ATS0=0 no
contestara nunca.
Una vez que se quien soy la pregunta logica parece ser....
Y quien me llama??
Lo primero saber nuestras limitaciones:
AT#CID=?
Devuelve si tu modem soporta Caller-ID y que formatos, caso
de que lo haga
en vez de darte el mensaje de ERROR entonces hacemos lo
siguiente:
AT#CID=1
Muestra los datos disponibles sobre el llamante incluyendo
cabeceras:
DATE: Fecha
TIME: Hora
NUMBER: Numero desde el que se recibe la llamada
NAME: Nombre del
sujeto (no, no lo busca en las paginas amarillas XDD )
Evidentemente estos datos se muestran en el instante en que
nuestro modem
RESPONDE a una llamada externa (no, no vale para saber el
numero del tio
que te kickea en IRC)
Esta informacion se envia entre el primer y segundo ring
concretamente
algunos milisegundos despues de sonar el primer ring y
exactamente hasta
un pu~ado de milisegundos antes de que suene el segundo
ring.
Iba a explicar yo aqui como funciona todo esto pero resulta
que abro
un zip y me encuentro que en otro zine ya le han dedicado
un articulo
completo. Moskis. Leetelo y date por enterado.
Aunque nuestro modem y nuestra teleco soporten este
servicio puede suceder
que en el campo del numero remoto nos encontremos con una P
que indica que
el llamante ha solicitado la privacidad del numero.
Se puede hallar utilidad al Caller-ID en control de
llamadas, bloqueo de
personas non-gratas o mil cosas mas que se te ocurran.
Aprovechando que estamos ya mas sueltos y con confianza no
viene de mas
explicar que el modem tiene dos modos principales de
funcionamiento, algo
que unos cuantos han aprendido ya a base de desconexiones,
que son:
- Modo comandos: En este estado el modem interpreta los
caracteres recibidos
desde el terminal
como comandos (no era muy dificil)
Pasar modo datos a
modo comandos: +++
- Modo datos: El terminal se puede conectar a otro terminal
remoto gracias
al enlace de los
modems que envian al otro extremo de la comunicacion los
caracteres
recibidos.
Pasar modo
comandos a modo datos: ATO
De hecho la cadena para pasar a modo comandos mientras se
esta en linea
viene especificada en el registro S2, se puede anular el
pase a comandos
de nuestro modem cambiando este valor por uno superior a
127
ATS2 Codigo de
escape (predeterminado + ascii 43)
ATS2= 128 (Deshabilita pase a comandos)
El modo exacto de enviar la cadena para pasar a modo
comandos incluye una
referencia a otro registro S, el 12 que indica el tiempo
entre caracteres.
Enviar caracter en S2 - Esperar S12 o mas - Enviar caracter
en S2...
Cualquier caracter que se reciba en este proceso lo anula y
fuerza el volver
a enviar la cadena desde el principio.
<-IV-> La Bruja
Averia <-IV->
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Si perteneces al 90% de gente que se conecta habitualmente
a redes
usando modem seguro que estas hartos de acordarte de los
progenitores
de (Infovia, Infovia+, nuestro ISP, Timofonica, Retenet,
los nodos "locales"..
..y una larga lista).
Tambien estaremos hartos del choteo que se traen cuando
llamamos para
protestar teniendo que asistir una vez tras otra a la
espa~olisima
especialidad de "le_paso_el_muerto_a_otro". En
Timofonica dicen que Ivia+
funciona y que es culpa del ISP, los otros dicen que la
culpa es de tu modem,
o que "los americanos se estan conectando justo ahora
y claro..."
Y como se yo si realmente mi linea es mala, si las
desconexiones son
problema mio, del ISP o de la ONU?. Hemos probado ya lo de
acercar el
bote de mayonesa al cajetin telefonico y dejarlo alli a ver
si se corta pero
eso no parece muy valido como prueba.
Comencemos por el comienzo y a traves de un largo proceso
intentaremos
descubrir el motivo por el cual nos conectamos a 300bps con
nuestro flamante
56kbs y porque se nos corta la conexion cada 15 minutos.
Despues podremos insultar con mas razones y fundamento :-D
Vamos a probar la conexion de nuestro modem al ordenador.
AT&T3: Bucle digital local
En este test los datos enviados al modem son devueltos por
este al
ordenador para que podamos comprobar que la comunicacion
entre ambos
equipos es correcta.
Tr: Transmisor del
modem
.---------. Rc: Receptor del modem
| | _______
| |
---test---> [ | Tr ]
| PC | [ | ]
| | <--test---- [ | Rc ]
| | [_|_____]
`---------'
`-----------> Los datos no llegan a ser
modulados ni demodulados.
AT&T1: Bucle analogico local
Una vez comprobado que nuestro modem recibe correctamente
las indicaciones
del ordenador y viceversa pasamos a recibir la parte mas
transcendental,
el receptor y el transmisor.
Los datos son reenviados al equipo tras pasar por el
interface digital
del modem.
.---------.
| |
.-------.
| | >--test-------> Tr ---test---.
|
PC | [ ] |
Linea
| | <--test-------- Rc <--test---+ Timofonica
| | [_______] |
`---------'
`------> No
cuesta dinero.
Con el comando AT&T8 el modem se aplica su propio
conjunto de pruebas y las
reenvia en bucle.
Al finalizar nos informa del numero de errores registrados.
Esto que hemos hecho en casa podemos hacerlo a traves de la
linea
telefonica contando para ello con la colaboracion de un
modem remoto,
en este caso tendremos un bucle digital remoto y un bucle
analogico remoto.
(Aqui ya nos cuesta dinero puesto que pagamos una llamada)
AT&T6, envia una peticion de reconocimiento de bucle al
modem remoto
que puede denegarlo (manualmente seria AT&T5) o
aceptarlo (manualmente
AT&T4) dependiendo de lo que digan sus registros S.
Terminal ------>
Transmisor ------> Linea -----> Receptor
<------ Receptor <------ Timofonica <-----
Transmisor
El antiguo bucle analogico pero con mas gente, enviamos
datos al modem, este
los manda hacia un modem remoto que NO los pasa a su
terminal sino que nos
los envia de vuelta en bucle y finalmente comprobamos como
ha ido la cosa.
Tambien se puede realizar un autotest remoto con el comando
AT&T7, la
duracion del bucle viene determinada en un registro S, el
S18.
Ahora ya sabemos que nuestro modem funciona razonablemente
bien y
empezamos a pensar mal de Timofonica, vamos a ver que linea
tenemos.
Hay un par de maneras basicas:
-*- Manera Uno:
Manera metodica o la cuenta de la vieja
1. Nos conectamos
a nuestro ISP/BBS manualmente desde un programa terminal
2. Pasamos a modo
comandos y AT&V1, este comando nos devuelve informacion
referente a la
conexion actual entre ellos uno llamado "Line Quality".
3. Apuntamos el
valor no vaya a ser que se nos olvide.
4. Desconectamos
5. Repetimos los
pasos anteriores hasta que creamos haber encontrado un
valor medio.
Un ejemplito de
AT&V1
[En este caso
nos da info sobre la _ultima_ conexion]
TERMINATION REASON.......... LOCAL
REQUEST
LAST TX data rate........... 33600
BPS
HIGHEST TX data rate........ 33600
BPS
LAST RX data rate........... 33600
BPS
HIGHEST RX data rate........ 33600
BPS
Error correction PROTOCOL... LAPM
Data COMPRESSION............ V42Bis
Line QUALITY................ 039 -----> Oops, vaya con Timofonica.
:->>
Receive LEVEL............... 025 ------> Timofonica
sigue triunfando.
Que valor es bueno?. Pues depende de la velocidad a la que
quieras conectar
pero cualquier cosa mayor de 30 es ya fastidiosa y te
permite quejarte
con razon y con datos fiables en la mano (no te haran caso
y te torearan
pero al menos tendras argumentos para que no te pongan las
banderillas)
-*- Manera Dos:
Manera metodica Plus o la ecuacion de la vieja
1. Nos conectamos
a nuestro ISP/BBS manualmente desde un programa terminal
2. Pasamos a modo
comandos y enviamos al modem AT%Q1, nos devuelve valores
EQM, RX y TX.
3. ATO, volvemos a
linea y aprovechamos la conexion (ya esta bien de pagar
para hacer
pruebas!)
4. Vamos
repitiendo la cosa y alternando modems remotos.
Ahora que tienes
una buena lista de valores (los apuntaste?) veamos que
nos dicen estos.
Para TX y RX los
valores deben estar entre 10-20 pero lo mas importante
es el valor de EQM ya que es un dato fundamental a la hora
de que el modem
decida usar los mecanismos de fallback/fall forward (metodo
por el cual la
velocidad sube o *baja* dependiendo de la calidad que la
linea ofrezca)
Los "buenos" valores de EQM son siempre relativos
a la velocidad a la que
te quieres conectar, el tipo de modem, la version de
firmware....etc.
Normas basicas: EQM cuanto menor mejor.
Cuanta mas rapido te quieras conectar mas "sube"
el
valor de la EQM.
(EQM viene de Eye Quality Monitor)
** EQM entre 0?! y 25 **
O no estas conectado o puedes aumentar la velocidad hasta
el tope.
** EQM entre 26 y
40 **
Podrias llegar a conseguir un aumento de velocidad con
algunos ajustes
de configuracion (lease registros S)
** EQM entre 41 y
55 **
En estas condiciones tu modem no puede dar mas de si.
** EQM mayor de 55
**
La linea es una patata, deberias bajar la velocidad (si,
aun mas!)
si notas que hay muchos errores o la conexion es inestable.
Cambiate de pais.
En el caso hipotetico y muy improbable de que la linea
parezca estar bien
y la culpa de los fallos de conexion no sea de quien todos
sabemos
puede ser de utilidad grabar un archivo de registro para
que
cuando le cantes las verdades a tu ISP sobre su
"maravilloso nodo local"
tengas a manos cosas como esta:
02-24-1999 17:28:54.07 - Remote
modem hung up.
02-24-1999 19:38:22.21 - Remote
modem hung up.
02-27-1999 23:02:24.56 - Remote
modem hung up.
Vaya, diria que te estan colgando el telefono??. Que pasa,
no hay ancho
de banda y desconectan a clientes de forma aleatoria??
;->>
Ademas un archivo siempre viene bien para otras cosas
(ocupar espacio
en tu HD, saber cuanto tiempo tarda el modem en marcar,
saber quien ha
forzado la desconexion..etc)
<-V-> Parafernalia
<-V->
~~~~~~~~~~~~~~~~~~~~~~~~~
Empezaremos por algo que no podia faltar: la seguridad; y
es que muchas
veces nos topamos con sistemas de rellamada (call-back) que
dicho sea de
paso han dado lugar a mucho mito y literatura.
Existen dos modos basicos establecidos para controlar el
acceso, los
llamaremos Modo Uno y Modo Dos. ;-)
Modo Uno: Permite la conexion tras introducir una clave
Modo Dos: Modo Uno+Cuelga y llama al numero asociado a esa
clave
Caso de encontrarnos con alguno de estos modos podemos recurrir
a la
literatura anteriormente mencionada o echar mano de los
siguientes
recursos que nos proporciona el modem.
Si nuestro modem ha negociado una conexion MNP tenemos la
opcion de pasar
a modo comandos y teclear:
AT*R
Con ello estamos pidiendo al modem que intente poner al
remoto en
RCM (Remote Configuration Mode), de conseguirlo veremos
aparecer
en nuestra pantalla lo siguiente:
REMOTE PASSWORD:
Como nos la sabemos (lo dudabas??) tras su introduccion nos
aparecera el
siguiente indicador de ordenes.
!AT
Y podremos mandar comandos de control al modem remoto, con
algunas
restricciones (evidentemente no podremos pedirle que marque
otro numero
porque ya esta conectado con nosotros)
Cuando nos hayamos cansado de trabajar o jugar.
!AT AT*E
Y el modem remoto sale del RCM devolviendo sobre la linea
un codigo de OK.
Aunque la preocupacion por la seguridad se ha extendido es
habitual que
incluso lugares que parchean rapidamente su software, usan
herramientas
de seguridad de manera periodica y han establecido una
politica de
seguridad se "olviden" de modificar, quiza por el
desprecio al que hacia
mencion en la introduccion o por ignorancia, la clave de
acceso remoto
asi que en muchos lugares la clave por defecto continua
siendo valida: QWERTY
{12345 tambien es una opcion}
Con el comando AT*C podemos almacenar el password para que
otro modem pueda
entrar en configuracion remota (si la conexion es MNP).
Este password
tiene un longitud de entre 6-12 caracteres de tipo
alfanumerico.
Pero que pasa con el sistema de call-back?. Pues que una
vez que se
puede mandar comandos a otro modem quiza necesitemos saber
alguno
de estos.
AT*L: Mediante este comando visualizamos el directorio de
seguridad en
la forma <Numero> <Clave> <Numero de
callback>
<Numero> <Clave> <Numero de callback>
1 miclave 987654321
2 soyyo 123456789
3 platanito
En este ejemplo si al el prompt de REMOTE PASSWORD:
hubiesemos introducido
la clave 1 o 2 el modem remoto habria marcado los
respectivos numeros pero
con la 3 no hubiera hecho llamada de comprobacion al no
tener asociado ningun
numero.
Supongamos ahora que queremos "a~adir" un nuevo
usuario a esta lista,
AT*P4 hanoirocks 88899897
Con este comando el listado anterior pasaria a ser como
sigue
<Numero> <Clave> <Numero de callback>
1 miclave 987654321
2 millave 123456789
3 platanito
4 hanoirocks 88899897
Como veis no es muy dificil, dejo como ejercicio saber que
pasaria
de teclear estos dos comandos.
AT*P1 myerstad 88899897
AT*P4 hanoirocks
A la hora de saber si nuestro modem esta sujeto a posibles
RCM por parte
de terceros el contenido del registro S80 (ATS80?) es muy
importante,
concretamente:
S80 - bit 6: Deniega/Permite configuracion remota
S80 - bit 7: Inhabilita/Deshabilita callback
[Esto puede variar segun el modelo de modem, ya te lo
avise]
Caso de que el bit 6 de S80 este puesto a uno nos interesa
bastante
el contenido de S202
S202: Contiene el caracter de escape para el acceso remoto,
si para el
acceso local este valor se guardaba en S2 y consistia por
defecto en
tres simbolos '+' en el acceso remoto los simbolos son
cuatro '*' con
un intervalo de un segundo.
**** -->
Secuencia de escape remota
Esta secuencia trabaja en cualquier conexion cuando el
remoto tiene activado
el RCM (bit 6 de S80 a 1), esto nos lleva a una situacion
similar a la que
obteniamos con el comando AT*R (pero sin obligacion de que
la conexion sea
MNP). Tras el tipico
REMOTE PASSWORD:
(Suerte que nos la sabemos de antes!)
Veremos el siguiente prompt
>
Detras del simbolo es donde introducimos los comandos AT,
cuando nos
hayamos aburrido...
> AT*X
Nos devuelve a donde estabamos (si teniamos una conexion de
datos el enlace
se mantiene, con AT*E para salir de un RCM establecido por
AT*R no
volveriamos al enlace sino al modo comandos de nuestro
modem)
Como explicamos antes no todos los comandos AT estan
disponibles en modo
remoto pero muchos si, prueba por ejemplo ATH y ya veras
como te diviertes.
:->>
En resumen hay dos grandes maneras de tomar el control de
un modem remoto,
con la secuencia de escape remota y a traves del RCM, ambas
tienen sus
requisitos y limitaciones.
Hay una curiosidad adicional para los amantes de la
ingenieria social, se
trata de la facilidad del modem para crear un enlace de
datos cuando
originalmente se trata de una llamada de voz, solo
necesitamos que el sujeto
objetivo teclee en un terminal ATD (origen) y nosotros
mandaremos ATA al
nuestro (destino), o viceversa, la conversacion se pierde y
ahora son los
modems los que estan enlazados (siempre que compartan linea
con el telefono
claro). Esto puede posibilitar la realizacion de conexiones
"furtivas" o
"subvencionadas".
Pues ahora nos vamos a:
AT*B
Y vemos que numeros tenemos en la "Lista negra",
tiempos atras tuvo
cierto auge, uno o dos casos documentados :-) , el
aprovechar estas
posibilidades del modem para un curioso ataque DoS, el
ingresar el numero de
Infovia -055- en la lista de numeros "prohibidos"
causando el efectivo
bloqueo del usuario y el mosqueo consiguiente (llamadas a
todo quisque y
acusaciones sin fundamento). A quien se le puede ocurrir
algo asi?.
...La verdad esta..me he olvidado donde pero seguro que en
algun sitio.
Aqui se acaba la cosa, cuando te aburras te puedes leer el
articulo
que se que te has saltado 3/4 partes. :-)
<-A-> APENDICE <-A>
~~~~~~~~~~~~~~~~~~~
Es habitual entre los hackers que pueblan este y otros
paises
loguear cosas, diferentes tipos de cosas, una practica muy
extendida
es loguear conexiones o intentos de conexion con la
intencion de depurar
errores, aprender, perder el tiempo u otros motivos
similares.
En este caso veremos como cualquier usuario puede acceder a
esta informacion
mas detallada sin necesidad de instalar Linux y hacer pppd -debug o
teclear comandos como tail -f /var/log/messages ni nada por
el estilo.
El denostado Windouuuuuss 95! nos permite loguear el
establecimiento de la
conexion tanto desde el punto de vista del modem como desde
el punto de
vista meramente 'protocolario'. Ya es algo.
04-02-1999 17:53:01.08 - Standard
Modem in use.
04-02-1999 17:53:01.12 - Modem
type: Standard Modem
04-02-1999 17:53:01.12 - Modem inf
path: MDMGEN.INF
04-02-1999 17:53:01.12 - Modem inf
section: Gen
04-02-1999 17:53:01.41 - 115200,N,8,1
04-02-1999 17:53:01.87 - 115200,N,8,1
Hasta aqui Windows se estaba preparando, ahora pasa a
inicializar el modem.
04-02-1999 17:53:01.93 - Initializing
modem.
04-02-1999 17:53:01.93 - Send:
AT<cr>
04-02-1999 17:53:01.94 - Recv:
AT<cr>
04-02-1999 17:53:03.93 - Recv: <no response>
04-02-1999 17:53:03.93 - WARNING:
Unrecognized response. Retrying...
Nada, que no chuta, asi que lo vuelve a intentar.
04-02-1999 17:53:03.93 - Send:
AT<cr>
04-02-1999 17:53:03.95 - Recv:
AT<cr>
04-02-1999 17:53:03.95 - Recv:
<cr><lf>OK<cr><lf>
04-02-1999 17:53:03.95 -
Interpreted response: Ok
04-02-1999 17:53:03.95 - Send:
ATE0V1<cr>
04-02-1999 17:53:03.95 - Recv: ATE0V1<cr>
04-02-1999 17:53:03.96 - Recv:
<cr><lf>OK<cr><lf>
04-02-1999 17:53:03.96 -
Interpreted response: Ok
04-02-1999 17:53:03.96 - Send:
ATX4<cr>
04-02-1999 17:53:03.96 - Recv:
<cr><lf>OK<cr><lf>
04-02-1999 17:53:03.96 - Interpreted response: Ok
La configuracion se ha llevado a cabo con exito, han pasado
2 segundos.
04-02-1999 17:53:03.97 - Dialing.
04-02-1999 17:53:03.97 - Send:
ATDT#########<cr>
04-02-1999 17:53:25.19 - Recv:
<cr>
04-02-1999 17:53:25.19 -
Interpreted response: Informative
04-02-1999 17:53:25.19 - Recv:
<lf>
04-02-1999 17:53:25.19 -
Interpreted response: Informative
04-02-1999 17:53:25.20 - Recv:
CONNECT 115200
A los 24 segundos ya estamos conectados, Windows informa
que desconoce
haber negociado opciones de compresion o control de
errores.
04-02-1999 17:53:25.20 -
Interpreted response: Connect
04-02-1999 17:53:25.20 - Connection
established at 115200bps.
04-02-1999 17:53:25.20 -
Error-control off or unknown.
04-02-1999 17:53:25.20 - Data
compression off or unknown.
04-02-1999 17:53:25.34 -
115200,N,8,1
04-02-1999 18:54:54.56 - Hanging up
the modem.
04-02-1999 18:54:54.56 - Hardware
hangup by lowering DTR.
04-02-1999 18:54:55.77 - WARNING:
The modem did not respond to lowering DTR.
Trying software hangup...
Nuestro modem esta configurado para ignorar las se~ales
hardware.
04-02-1999 18:54:55.77 - Send: +++
04-02-1999 18:54:56.80 - Recv:
<cr><lf>OK<cr><lf>
04-02-1999 18:54:56.81 -
Interpreted response: Ok
04-02-1999 18:54:56.81 - Send:
ATH<cr>
04-02-1999 18:54:57.64 - Recv:
<cr><lf>OK<cr><lf>
04-02-1999 18:54:57.64 - Interpreted response: Ok
La desconexion por software se ha llevado a cabo con exito.
04-02-1999 18:54:58.12 - Session
Statistics:
04-02-1999 18:54:58.12 - Reads : 2877981 bytes
04-02-1999 18:54:58.12 - Writes: 269278 bytes
04-02-1999 18:54:58.12 - Standard
Modem closed.
Lo mismo pero desde el punto de vista de los protocolos nos
muestra
todo el proceso de puesta en marcha y negociacion de
nuestro enlace
asi como los protocolos y opciones que va a aceptar el
servidor.
Esto requeriria un articulo entero pero mientras puedes
leer las RFC
pertinentes y las tonterias que pongo yo.
04-02-1999 07:27:51.93 - Server
type is PPP (Point to Point Protocol).
Comienza el FSA -Finite State Automaton- que solo con el
nombre asusta.
04-02-1999 07:27:51.93 - FSA :
Adding Control Protocol 80fd (CCP) to control
protocol chain.
04-02-1999 07:27:51.93 - FSA :
Protocol not bound - skipping control
protocol 803f
(NBFCP).
Este nombrecito
NBFCP corresponde al NetBios Framing Control Protocol
04-02-1999 07:27:51.93 - FSA :
Adding Control Protocol 8021 (IPCP) to control
protocol chain.
04-02-1999 07:27:51.93 - FSA :
Protocol not bound - skipping control protocol
802b (IPXCP).
04-02-1999 07:27:51.93 - FSA :
Adding Control Protocol c029 (CallbackCP) to
control protocol
chain.
04-02-1999 07:27:51.93 - FSA : Adding Control Protocol c027
(no description)
to control protocol chain.
Y este sin
descripcion es el Shiva Password Authentication Protocol
04-02-1999 07:27:51.93 - FSA :
Adding Control Protocol c023 (PAP) to control
protocol chain.
04-02-1999 07:27:51.93 - FSA :
Adding Control Protocol c223 (CHAP) to control
protocol chain.
04-02-1999 07:27:51.93 - FSA :
Adding Control Protocol c021 (LCP) to control
protocol chain.
This-Layer-Up
que nos vamos. Segunda fase.
04-02-1999 07:27:51.93 - LCP :
Callback negotiation enabled.
04-02-1999 07:27:51.93 - LCP :
Layer started.
04-02-1999 07:27:52.08 - LCP :
Received and accepted ACCM of a0000.
Ein?. Que dice uste?. Mapear caracteres de control?. Pos fale.
04-02-1999 07:27:52.08 - LCP :
Received and accepted authentication protocol
c223 (CHAP).
Chap, chap,
chapchapchap (hay que ponerle musica mentalmente)
Segurisimo que
el funcionamiento del protocolo lo han explicado
en algun
texto/ezine/whatsoever en castellano.
04-02-1999 07:27:52.08 - LCP :
Received and accepted magic number 19fdfa95.
04-02-1999 07:27:52.08 - LCP :
Received and accepted protocol field
compression option.
04-02-1999 07:27:52.08 - LCP :
Received and accepted address+control field
compression option.
04-02-1999 07:27:52.08 - LCP :
Received configure reject for callback control
protocol option.
Oh, que
lastima!. Un Conf-Rej para nuestro querido CBCP. Un aplauso
por haberlo intentado
con user-specifiable number y dos narices.
04-02-1999 07:27:52.20 - LCP :
Layer up.
04-02-1999 07:27:52.20 - CHAP :
Layer started.
04-02-1999 07:27:52.96 - CHAP :
Login was successful.
Estamos dentro...
(frase historica). Comienza la tercera fase
04-02-1999 07:27:52.96 - CHAP :
Layer up.
04-02-1999 07:27:52.96 - IPCP :
Layer started.
04-02-1999 07:27:52.96 - IPCP : IP
address is 0.
04-02-1999 07:27:52.96 - CCP :
Layer started.
04-02-1999 07:27:53.13 - FSA :
Received protocol reject for control protocol
80fd.
El servidor nos
informa que no soporta CCP (Compression Control Protocol)
04-02-1999 07:27:53.13 - CCP :
Layer finished.
04-02-1999 07:27:53.16 - IPCP :
Received and accepted compression protocol
request f 0.
Gimme IP Joanna before the morning comes.
04-02-1999 07:27:53.16 - IPCP :
Received and accepted IP address of 9f51112d.
04-02-1999 07:27:55.54 - IPCP :
Received and accepted compression protocol
request f 0.
Nuestra posicion
en esta negociacion consiste en aceptar lo que nos den
pero siempre
puedes intentar cambiar las cosas.
04-02-1999 07:27:55.54 - IPCP : Received
and accepted IP address of 9f51112d.
04-02-1999 07:27:56.18 - IPCP :
Changing IP address from 0 to 9f51112d.
04-02-1999 07:27:56.18 - IPCP :
Accepting primary DNS 9f5110a4.
04-02-1999 07:27:56.18 - IPCP :
Accepting backup DNS 9f5110a1.
04-02-1999 07:27:56.29 - IPCP :
Layer up.
04-02-1999 07:27:56.29 - FSA : Last
control protocol is up.
Que frase tan bonita.
Y ahora listo,
ya podemos desconectar.
04-02-1999 07:54:53.73 - Remote
access driver is shutting down.
04-02-1999 07:54:53.73 - CRC
Errors 0
04-02-1999 07:54:53.73 - Timeout
Errors 0
04-02-1999 07:54:53.73 - Alignment
Errors 0
04-02-1999 07:54:53.73 - Overrun
Errors 0
04-02-1999 07:54:53.73 - Framing
Errors 0
04-02-1999 07:54:53.73 - Buffer
Overrun Errors 0
04-02-1999 07:54:53.73 - Incomplete
Packets 0
04-02-1999 07:54:53.73 - Bytes
Received 1146895
04-02-1999 07:54:53.73 - Bytes
Transmittted 137315
04-02-1999 07:54:53.73 - Frames
Received 1534
04-02-1999 07:54:53.73 - Frames
Transmitted 1861
04-02-1999 07:54:53.73 - LCP :
Layer down.
04-02-1999 07:54:53.73 - CHAP :
Layer down.
04-02-1999 07:54:53.73 - IPCP :
Layer down.
04-02-1999 07:54:53.73 - CCP :
Layer started. --->
Otro que esta bueno.
04-02-1999 07:54:53.86 - LCP :
Received terminate acknowledgement.
04-02-1999 07:54:53.86 - LCP :
Layer finished.
04-02-1999 07:54:53.86 - Remote
access driver log closed.
Vale, no es tan detallado como otra informacion que se
puede conseguir pero
lo hace Windouuuuuss 95! solito, asi que todos aquellos que
pensais que
"como tengo Windouuuuuss 95! no puedo hacer nada ni
aprender nada ni
hackear nada hasta que no me ponga Linux en el 2010". Tais quivocados!!.
* NOTA: Windouuuuuss 95! is a
trademark of Microchof Corp.
All rights reversed.
Se acabo el tormento.
Y recordad, hagais lo que hagais.
Tened cuidado ahi fuera.
Paseante
.
INDICE:
1º Protocolo IP
Introducción
El protocolo IP
Direccionamiento IP
Protocolos de Ruteo nivel IP
Protocolos de Resolución de
direciones
Mensajes de error y control en
IP (ICMP)
Protocolo de datagrama de
Usuario (UDP)
2º Protocolo de
control de transmisión TCP
Servicio de Transporte de flujo
confiable
Puertos, conexiones y puntos
extremos
3º La interfaz de
socket
La paradigma de E/S de UNIX y de
la red
La abstracción de socket
4ºSistema de nombre
de dominio (DNS)
Introducción
Resolución de nombres
1º
IP
(Protocolo de internet)
- Introducción:
Hoy en día podemos decir que la
arquitectura TCP/IP es sobre la que se sustenta el 90% de las redes actuales.
Los principios de la
arquitectura TCP/IP se encuentran ARPANET(red de comunicaciones militar del gobierno
de los EE.UU.), y con la expansión de Internet como un "juego" para
la gran mayoría de la sociedad se ha convertido en el negocio más rentable de
hoy en día, lo que explica su gran expansión actual.
Antes de continuar debemos
definir las diferentes capas que componen
la arquitectura TCP/IP, que
consta de 4 niveles:
1º Subred (enlace y físico)
2 º Interred (red IP)
3º Protocolo proveedor de servicios (
Transporte TCP o UDP)
4º Nivel de aplicación
* Protocol internet -
IP
El protocolo IP es la
parte integral del TCP/IP, este
protocolo IP se encarga del direccionamiento de los datagramas de información,
y la administración del proceso de fragmentación y desfragmentación de dichos
datagramas. Debemos definir el concepto de datagrama como la unidad de
transferencia que el Ip utiliza, siendo utilizada también como datagrama IP.
Las características
de este protocolo son las siguientes:
*No orientado a
conexión
*Transmisión en
unidades denominadas datagramas
*No hay corrección de
errores ni control de congestión
*No está garantizada
la entrega en secuencia.
*No está garantizada
la entrega única.
La entrega del datagrama en Ip no está
garantiza porque éste se puede retrasar, enrutar o mutilar al dividir y
reensemblar los fragmentos del mensaje.
En cuanto al ruteo
(encaminamiento) este puede ser:
*Paso a paso a todos los nodos.
*Mediante tablas de rutas
estáticas o dinámicas.
* Direcciomiento IP
La dirección que
utiliza el TCP/IP es de 32 bits y ésta sirve para identificar una maquina y la
red a la cual está conectada. El encargado de asignar las direcciones IP es el
NIC (centro de información de Red).
Existen
diferentes formatos para la dirección IP, la elección de uno o de otro,
dependerá del tamaño de la red. Los cuatro formatos son los siguientes:
Clase A Red(7 bits) Dirección
local (24 bits)
Clase B Red(14 bits) Dirección local (16
bits)
Clase C Red(21 bits) Dirección
local (8 bits)
Clase D Dirección de difusión múltiple (28 bits)
Cada dirección esta
formada por un par (red), y Dir. Local en donde se identifica la red y el host
dentro de la red.
Para identificar la
clase se utilizan los 3 primeros bits de orden más alto.
Las direcciones de
Clase A corresponden a redes grandes que permiten 1.6 millones de hosts. Las de
Clase B permite tener 12320 redes con 65024 hosts en cada una. Las de Clase C
permite 2 millones de redes con 254 hosts cada una y por ultimo las de Clase D
se utiliza para la multidifusión. Para que no se diga que queda
incompleto....... os menciono que existe otra Clase más y esta es la Clase E.
Bueno ahora os voy explicar lo
que pasa por ejemplo en los cybers donde existen redes internas...... como
todos sabemos. Cada máquina tiene una
dirección ip, y a partir de esta una la
red determina si los datos se enviaran a través de una compuerta (GTW, ROUTER).
* Protocolos de Ruteo
¿Cómo pueden los
routers en un sistema autónomo aprender acerca de redes dentro del sistema y
redes externas?
En internet en la cual existen varias rutas físicas, los
administradores por lo general selecionan una de ellas como ruta primaria. Los
ruteadores interiores normalmente se comunican con otros y intercambian
información de accesibilidad a red o información de ruteo de red a partir se
puede deducir la accesibilidad.
Protocolo de
información de ruteo
Entre los I.G.P.
(Interior Gateway Protocol) mas usados esta el RIP, comunmente conocido como
ROUTED. Este protocolo RIP es consecuencia directa de la implantación del ruteo
de vector-distancia para redes locales. Divide las maquinas en activas y
pasivas. Los routers activos anuncian
sus rutas a los otros; las maquinas pasivas listan y actualizan sus
rutas en base a estos anuncios. Sólo un router puede correr RIP en modo activo
de modo que un anfitrión deberá correr el RIP en modo pasivo. Un router con RIP
en activo difunde un mensaje cada 30 segundos, esta información contiene datos
tomados de la base de datos actualizada. Cada
mensaje consiste en pares, donde cada par contiene una dirección IP y un
entero que representa la distancia hacia esta red.
El RIP por tanto hace
uso de un vector de distancias, con métrica por número de saltos donde se
considera que 16 saltos o más es infinito. De esta manera, el número de saltos
o el contador de saltos a lo largo de
una trayectoria desde una fuente dada hacia un destino dado hace referencia al
número de routers que un datagrama encontrará a lo largo de su trayectoria. Por
tanto lo que se hace es utilizar el conteo de saltos para calcular la
trayectoria óptima. Ahora deberíamos hablar de los errores que se maneja el RIP
que son ocasionados por algoritmos subyacentes.... pero esto ya os lo dejo por
vuestra cuenta....
- Protocolos de
resolución de direcciones.
Existen dos tipos de
direcciones, las dir. Físicas (MAC) y las direcciones IP. El problema está en
la transfomación necesaria de estas direcciones, y en este problema de asociación de direcciones en TCP/IP para redes como Ethernet, se utiliza un
protocolo de bajo nivel para asignar
direciones en forma dinámica y evitar
la utilización de una tabla de conversiones. Este protocolo se denomina
ARP. Y permite que un anfitrión
encuentre la dirección física de otro anfitrión dentro de la misma red
física con solo proporcionar la dirección IP de su objetivo. Si nos situamos en
el caso contrario, en el que una máquina debe contactar con el servidor para
conseguir su dirección IP antes de que se pueda comunicar por TCP/IP, entonces
el encargado de esta tarea es el RARP que utiliza el direccionamiento físico de red para obtener la dirección IP
de la máquina.
* ICMP
Si un router no puede entregar o rutear un datagrama , o
si el router detecta una condición anormal que afecte su capacidad para
direccionarlo, necesita informar a la fuente original para que evite o corrija
el problema. Para hacer esta tarea se
agrego al protocolo TCP/IP un mecanismo de mensajes de propósito especial, el
Protocolo de Mensajes de Control
Internet es decir ICMP. Este permite
que los routers envíen mensajes de error de control hacia otros routers
o anfitriones. Así cuando un datagrama causa un error, el ICMP
sólo puede reportar la condición del error a la fuente original del datagrama y
esta debe corregirlo.
Formato de los
mensajes ICMP:
Debo aclarar que cada
ICMP tiene un formato propio y diferente, pero todos constan de tres campos, un
campo TIPO de mensaje, que identifica el mensaje ; un campo CODIGO que
proporciona más información sobre el tipo de mensaje; y por último un campo SUMA DE VERIFICACION. Para el que no lo
sepa los ICMP que reportan errores siempre incluyen el encabezado y los
primeros 64 bits de datos del datagrama que causo el error, para que el
receptor determine con mayor rapidez la causa del error.
Tipos de TYPE:
Campo TYPE Tipo
de Mensaje ICMP
0 Respuesta
de ECO
3 Destino
inaccesible
4 Disminución
de origen
5 Redirecionar
8 Solicitud
ECO(PING)
11 Tiempo excedido para
un datagrama
12 Problemas de
parámetros de un datagrama
13 Solicitud
de TIMESTAMP
14 Respuesta
de " " " "
15 Solicitud
de información
16 Respuesta
de información
17 Solicitud
de Máscara
18 Respuesta
de Máscara
-UDP
Empecemos por imaginar
que cada máquina contiene un grupo puertos de destino que son abstractos y que se llaman puertos de protocólo. Cada
uno de estos puertos se identifica por
medio de un número entero positivo. Así para comunicarse con un puerto de
protocolo del destino la máquina necesita saber la dirección IP y el número
entero del puerto de protocolo dentro de la maquina destino. Y he aquí donde
entran los UDP, los cuales contienen la información del puerto de protocolo de
la maquina que envía y del puerto de protocolo de la maquina que recibe, y asi
la información llega a su destino exacto. Sin entrar en detalles os informaré
que los paquetes UDP se pueden perder, duplicar o llegar sin orden y tan
rápidos como puedan, y así poder llegar a una velocidad más rapida de la que el
receptor pueda procesar.... con esto os explicareis muchas cosas aquellos que
utilizáis "NUKES" y en
realidad no sabeis lo que utilizáis, valga la redundancia.
Formato UDP:
Los mensajes UDP
constan de un encabezado UDP y un área de datos UDO. El encabezado se divide en
4 campos de 16 bits, que especifican el puerto desde el que se envió el
mensaje, el puerto para el que se destina, la longitud del mensaje y una suma
de verificación UDP.
2º
TCP
* Servicio de
transporte de flujo confiable.
A continuación vamos
a ver el servicio más importante y mejor conocido a nivel de transporte, la
entrega de flujo confiable y el Protocolo de Control de Transmisión.
Podemos decir que al nivel más
bajo la red o las redes nos pueden proporcionar una entrega de paquetes no
confiable, los paquetes se pueden extraviar o destruir a causa de errores.
En muchas ocasiones en un nivel más
alto, los programas de aplicación
necesitan enviar gran cantidad de datos desde una maquina a otra, en
estos casos utilizar un sistema de entrega no confiable sería una opción penosa..... por lo cual el TCP se
ha convertido en el protocolo general y ideal para estos casos.
Encontramos 5 funciones o
características del TCP:
* Servicio Orientado
a conexión: El servicio de entrega de flujo en la maquina destino pasa al
receptor exactamente las misma secuencia de bytes que pasa el transmisor en la
máquina origen.* Antes de que se comuniquen los dos extremos se requiere
negociar una conexión*
* Conexión de
Circuito Virtual: Durante la
transferencia, el software de protocolo en las dos maquinas continúa
comunicándose para verificar que los datos se reciban correctamente.*El
servicio emula una conexión dedicada punto a punto es decir los paquetes llegan
en el mismo orden, sin duplicados..........*
* Transferencia con
memoria intermedia: Los programas de aplicación de datos envían a través el
circuito virtual pasando respectivamente bytes de datos al software de
protocolo. Al transferirse datos cada aplicación utiliza piezas del tamaño que encuentre adecuado, así el
protocolo los entrega a la otra aplicación en el orden que le fueron entregados
y nada más que el receptor los recibe se verifican. Atención, el tamaño en el
que la aplicación divide los paquetes de datos.... no tiene nada que ver con la
división que hace el software del protocolo, en el sentido de que el este
software puede reunir varios paquetes y "juntarlos" en otro mayores
formando un datagrama mayor y que el considere apropiado para enviar, hay que
mencionar el push que es un mecanismo que empuja por así decirlo a los
datagramas que envía el software del
protocolo así como los que se reciben, y es también entra en funcionamiento
cuando existe una "congestión".
* Flujo no
estructurado: Posibilidad de enviar información de control de flujo junto a
datos.
* Conexión Full
Duplex: Existe una transferencia concurrente en ambas direcciones.
* PUERTOS, CONEXIONES
Y PUNTOS EXTREMOS.
Al igual que el UDP el TCP utiliza números de puerto de protocolo para identificar
el destino final dentro de una maquina. Cada puerto tiene asignado un número
entero pequeño entero utilizado para identificarlo.
Vamos a pensar en un
puerto como una cola de salida en la que
el software de protocolo pone o coloca datagramas entrantes. En realidad el TCP
utiliza la conexión no el puerto de protocolo, en donde las conexiones se
identifican por puntos extremos. A continuación explicare lo que es un punto
extremo. Un punto extremo e un par de números enteros(host, puerto), en la cual
el host es la IP y puerto es un puerto
TCP en el anfitrión. Son dos puntos extremos los que definen las conexiones,
así dos conexiones pueden utilizar el mismo punto extremo, lo que es debido a
que el TCP identifica una conexión por medio de un par de puntos extremos. En
el TCP se combina la asignación dinámica y la estática de puertos mediante un
conjunto de asignación de puertos bien conocidos para programas llamados con
frecuencia, pero la salida de la mayor parte de los números disponibles para el
sistema se asigna conforme los
programas lo necesitan. A continuación un muestra de algunos ejemplos de puerto
TCP:
DECIMAL CLAVE
DESCRIPCIÓN
0 reservado
1 TCPMUX Multiplexor TCP
5 RJE Introducción de función
remota
7 ECHO
Eco
23 TELNET Conexión por terminal
42 NAMESERVER Nombre del host del servidor
79 FINGER Comando finger
* Debo informar al
que no lo sepa, que hay CLAVE-UNIX y estas son diferentes en gran parte.
3º
SOCKET
* El paradigma de E/S
de UNIX y la E/S de la RED.
Vamos a ver como la
interface UNIX BSD se utiliza el TCP/IP en programación. Más en concreto el winsock
proporciona la funcionalidad de socket para MsWindows. Aunque tendría que haber empezado por
distinguir los protocolos de interface y el TCP/IP. En su origen las
operaciones UNIX se agrupaban en un
paradigma conocido como Open-Read-Write-Close que son los paradigmas que
seguían los E/S de UNIX anteriormente, y una de las primera implementaciones de TCP/IP también utilizo este
paradigma. El grupo que añadió los
protoclos de TCP/IP al BSD decidió que, al ser los protocolos de red eran más
complejos que lso dispositivos convencionales de E/S, la interacción entre los
programas de usuario y de protocolos de red debian ser a su vez más compleja. Y
se decidio abandonar este paradigma.
* La abstracción de
Socket
En el socket se
centra la base para la E/S de red en UNIX.
El socket es la
generalización del mecanismo de archivos UNIX que proporciona un punto final
para la comunicación.
En pocas palabras el socket es
una API en la que el servidor espera en
un puerto predefinido y el cliente puede utilizar sin embargo un puerto
dinámico.
4º
DNS
* Resolución de
nombres.
La resolución de
nombres se realiza de arriba hacia abajo, empezando por el servidor de nombres
raíz y posteriormente los demás que se encuentren en las diferentes ramas del
árbol de la red. La utilización del sistema de nombres de dominio se puede
utilizar de varia formas: una en la que contactas un servidor de nombres cada
vez y otra en la que el software cliente realiza una solicitud de nombres de
dominio que contiene el nombre a resolver, en donde se envía la solicitud a un
servidor de nombres para su resolución.
En el momento en que
un servidor de nombres de dominio recibe una solicitud del estilo mencionado
anteriormente, verifica si el nombre señala un subdominio sobre el cual tenga
autoridad, en este caso traduce el nombre de acuerdo con su base de datos y
anexa una respuesta a la solicitud, antes de enviarla de regreso al cliente. En
el caso de que el servidor de nombre no sea capaz de resolver la solicitud
enviada se pondrá en contacto con otro servidor que sea capaz de resolverla
para posteriormente darle respuesta al cliente.
Por [SnAkE] CiBahHaCk