Revista Hack X Crack 20

8/2/2019 Revista Hack X Crack 20

1/68

HACK X CRACK: TCP - LA ESENCIA DE LAS COMUNICACIONES POR RED

LOS MEJORES ARTCULOS GRATIS EN NUESTRA WEB

PC PASO A PASO: IDS - LA SEGURIDAD CON MAYUSCULAS !!!

N 20 -- P.V.P. 4,5 EUROS

3 SERVIDORES ON LINE PARA TUS PRACTICAS DE HACK

MENU

* DETECTANDO PUERTOS EXTRAOS

NMERO 20

SISTEMA DE DETECCIONDE INTRUSOS !!!

(2PARTE)

Y CONEXIONES SOSPECHOSAS* REGLAS DE CABECERADE CONTENIDO Y DE CONTROL

* CONTRAMEDIDAS EN TIEMPO REALCONTRAMEDIDAS EN TIEMPO REAL* STREAM 4

* RPC DECODE* PORTSCAN Y PORTSCAN 2

XCOMO METER VARIOS

JUEGOS EN 1 DVD

MENUS A NUESTRO GUSTOY

PP

AA

SS

OO

PP A S O A S O

PPAASSOO

PPA S OA S OaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaP R O G R A M A N D O C O O K I E S ! ! !

8 4 1 40 9 0 2 0 27 5 6

02000

LOS IDENTIFICADORESDE SESIONLAS COOKIES


2/68


3/68

PIDE LOS NUMEROS ATRASADOS EN --> WWW.HACKXCRACK.COM

EDITORIAL: EDITOTRANS S.L.C.I.F: B43675701PERE MARTELL N 20, 2 - 143001 TARRAGONA (ESPAA)

Director Editorial

I. SENTIS

E-mail contacto

[email protected]

Ttulo de la publicacin

Los Cuadernos de HACK X CRACK.

Nombre Comercial de la publicacn

PC PASO A PASOWeb: www.hackxcrack.com

Direccin: PERE MARTELL N 20, 2 - 1.

43001 TARRAGONA (ESPAA)

Quieres insertar publicidad en PC PASO A

PASO? Tenemos la mejor relacin precio-difusin

del mercado editorial en Espaa. Contacta con

nosotros!!!

Sr. Ruben Sentis

Tfno. directo: 652 495 607

Tfno. oficina: 877 023 356

E-mail: [email protected]

Director de la PublicacinJ. Sents

E-mail [email protected]

Diseo grfico:J. M. Velasco

E-mail contacto:[email protected]

RedactoresAZIMUT, ROTEADO, FASTIC, MORDEA, FAUSTO,ENTROPIC, MEIDOR, HASHIMUIRA, BACKBONE,ZORTEMIUS, AK22, DORKAN, KMORK, MAILA,TITINA, SIMPSIM... ... ... ... ...

Contacto [email protected]

ColaboradoresMas de 130 personas: de Espaa, de Brasil, deArgentina, de Francia, de Alemania, de Japn y

algn Estadounidense.

E-mail [email protected]

ImprimeI.G. PRINTONE S.A. Tel 91 808 50 15

DISTRIBUCIN:SGEL, Avda. Valdeparra 29 (Pol. Ind.)28018 ALCOBENDAS (MADRID)Tel 91 657 69 00 FAX 91 657 69 28WEB: www.sgel.es

TELFONO DE ATENCIN AL CLIENTE: 977 22 45 80Peticin de Nmeros atrasados y Suscripciones (Srta. Genoveva)

HORARIO DE ATENCIN: DE 9:30 A 13:30(LUNES A VIERNES)

Copyright Editotrans S.L.NUMERO 20 -- PRINTED IN SPAINPERIOCIDAD MENSUALDeposito legal: B.26805-2002Cdigo EAN: 8414090202756

PP

AA

SS

OO

PP A S O A S Oaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

a

33 STST AFFAFF

4 CURSO DE PHP: MANE4 CURSO DE PHP: MANEJO DE SESIONESJO DE SESIONES

114 CURSO DE T4 CURSO DE TCP/IP: TCP/IP: TCP (CP ( TRANSMISION CTRANSMISION CONTRONTROLOL

PRPR OOTTOCOC OL.OL.

334 XB4 XB OOX (VI): MENU XX (VI): MENU X

337 CURSO DE SEGURID7 CURSO DE SEGURIDAD EN REDES - IDS (II)AD EN REDES - IDS (II)


4/68

Pgina 4 PC PASO A PASO N 20

1. Introduccin de session

La sesin va unida al usuario, se pueden crear

variables a nivel de sesin que son accesiblesdesde cualquier pgina siempre que la sesineste activa.

Una sesin se crea cuando un usuario accedea una pgina web, a partir de ese momentotodos los accesos a las pginas de ese sitoweb pueden seguirse a travs de la sesincreada. Cada sesin creada lleva asociado unidentificador, que identificar esa sesin conel usuario que provoc su creacin.

Adems, las variables definidas a nivel de

sesin permanecen accesibles desde todaslas pginas php del site, durante toda lasesin del usuario, por lo tanto son unaespecie de variables globales que permanecenactivas mientras la sesin est activa.

Una sesin estar activa siempre que elusuario se comunique con el servidor web,cambie de una pgina web a otra, enve unformulario, etc. Cada sesin tiene un tiempomximo de inactividad permitida (lo normalsuele ser 20 minutos, pero se puede cambiarese valor), si un usuario permanece sin

actividad durante un periodo de tiempodeterminado o abandona el sitio Web, todassus variables e identificadores de sesin sonborrados.

Dentro del fichero php.ini, modificando elvalor de la variable session.cookie_lifetimese modifica el tiempo de vida (o tiempo deinactividad) de la sesin.

La variable session.cookie_lifetimeespecifica la duracin de la cookie en segundos,que se manda al navegador. El valor 0 significa

"hasta que se cierra el navegador", y es elque se encuentra por defecto.

Un ejemplo muy claro de esto es la bancaelectrnica. Si nos identificamos en nuestrobanco on-line para consultar el saldo denuestra cuenta bancaria y nos vamos a tomarun caf, seguramente, cuando volvamos elbanco no nos dejar realizar ms operacioneshasta que nos volvamos a identificar en elsistema.

Otro ejemplo de la utilizacin de las sesiones

es el comercio electrnico, cuando compramosvamos almacenando productos en el carritode la compra y, aunque cambiemos de pginaweb, los productos siguen estando en el carrito.Esto es gracias a que la informacin relativaa esos productos est almacenada en variablesde sesin.

Existen dos formas de mantener y continuaruna sesin mientras el usuario navega por laspginas web. En la primera de ellas esmediante el uso de las cookies (datosguardados en el cliente) y en la segunda, elidentificador de la sesin se incluye en la URL

de la pgina como un parmetro ms. Elmdulo de gestin de sesiones que proporcionaPHP permite util izar ambas formas.

El mdulo de sesiones admite ambas formas.Las Cookies son la mejor opcin, pero comono son fiables (los clientes no estn obligadosa aceptarlas), no podemos confiar en ellas. Elsegundo mtodo incrusta el "session id"directamente en las URLs.

curso de PHPAPRENDE A MANEJAR SESIONES

Continuamos con el curso de PHP y en esta entrega aprenderemos a manejar sesiones.

He decidido explicar las sesiones antes de seguir con socket, ya que con el manejo de las

sesiones se comprende como un portal puede dar acceso a partes privadas.

Existen varias formas de mantener la sesin del navegante, se explicarn algunas, las

ms conocidas y que encontrareis en la mayora de portales.


5/68

PC PASO A PASO N 20 Pgina 5

Las sesiones (y toda la informacin relativaa ellas) en PHP se guardan ficheros que estnen un directorio. Este directorio estespecificado en la variable session.save_path

dentro del apartado [Session] del ficherophp.ini.

Todas las variables y parmetros necesariospara el correcto funcionamiento de las variablesse encuentran en el fichero php.ini.

Tanto para leer como para escribir variablesde sesin utilizaremos el array asociativo$ H T T P _ S E S S I O N _ V A R S [ v a r ] o$_SESSION[var] que es su versin abreviada.

Vamos a ver el uso de las sesiones "plan

rpido" con un ejemplo ejemplo:

1)- En primer lugar tenemos el cdigo de unapgina PHP (llamemosla php7.php) que guardalas variables nombre, apellidos y sessionIden la sesin. Ya sabes, como siempre copiael cdigo en el Block de Notas y guardalo conel nombre php7.php

Sesion Paso 1Siguiente

- En segundo lugar tenemos otra pgina(sessiones7.php) donde recogeremos el valorde dichas variables almacenadas en la sesin.Ya sabes, como siempre copia el cdigo en elBlock de Notas y guardalo con el nombrephp7.php

Sesion Paso 2

Nombre:

Apellidos:

SesionId:

Para que se almacenen las variables en la sesin primerodebemos ejecutar el cdigo de la primera pgina PHP(php7.php) y a continuacin ejecutaremos la segundapgina. Si no siguiramos esta secuencia y ejecutsemosdirectamente el cdigo de la segunda pgina, las variablesde la sesin no tendran ningn valor.

El resultado que obtendremos ser el siguiente:

Visto el ejemplo vamos a ver el tema con ms detalle.

2. Funciones

2.1 session_startEsta funcin crea una nueva sesin o contina con lasesin actual.La sintaxis de la funcin es la siguiente:

session_start();

Programacin PHP - Programacin PHP - Programacin PHP - Programacin PHP


6/68


Todas las pginas PHP que utilicensesiones deben incluir esta funcin queindica al intrprete PHP que recupere

toda la informacin relativa a las sesiones,para posteriormente hacer uso de ella.

Esta funcin debe escribirse antes de quese escriba cualquier carcter en el cliente,incluso antes de las cabeceras HTML, sino es as se producir un error. Paraevitar problemas es mejor colocar estafuncin al principio de nuestra pginaPHP.

2.2 session_destroy

Esta funcin elimina todos los datosasociados a una sesin.La sintaxis de la sesin es la siguiente:

session_destroy();

Est funcin no borra la sesin ni la cookiedonde se encuentra almacenada, sloborra los datos asociados a la misma, esdecir, borra las variables que seencuentran asociadas a una sesin.

2.3 session_nameEsta funcin devuelve el nombre de lasesin utilizada en ese momento. Pordefecto, este valor es PHPSESSID yesta definido dentro del fichero php.ini.Si se desea especificar un nombrediferente a la sesin, ste se deberpasar como parmetro de la funcin.

La sintaxis de la funcin es la siguiente:session_name(nombreSesion);

El parmetro nombreSesion es opcional.

Y el resultado obtenido al ejecutar elcdigo anterior es:

2.4 session_module_name

Devuelve el valor de la variablesession.save_handler situada en elficherophp.iniencargada de definir el tipo

de controlador utilizado para grabar yrecuperar el manejo de las sesiones quepor defecto es files.

La sintaxis de la funcin es la siguiente:session_module_name(handler);

El parmetro handler es opcional.

2 .5 se ss i o n _ sa v e _ p a t h

Permite conocer la ruta en la que seguardan las sesiones si el valor desession.save_handler es files. En lamayora de los casos se trata de undirectorio temporal.

Esta funcin recupera y modifica el valorde la variable session.save_path delfichero php.ini.

Si session_save_path apunta a un

directorio con permiso de lectura por elresto de usuarios, como/tmp (la opcinpor defecto), los dems usuarios delservidor pueden conseguir robar lassesiones obtenindolas de la lista dearchivos de ese directorio.

La sintaxis de la funcin es la siguiente:session_save_path(path);


7/68


El parmetro path es opcional.

Y el resultado obtenido es:

2.6 session_id

Esta funcin devuelve el identificador dela sesin del usuario en el sitio Web, porlo tanto es una de las funciones msimportantes en el manejo de la sesin.


2.7 session_registerEsta funcin se encarga de registrar losparmetros que se le pasan a la funcin,como variables a nivel de sesin. Por lotanto el nmero de argumentos de esta

funcin no es fijo y depender de las variables quedeseemos declarar.

Para explicar el funcionamiento de la funcinsession_register() lo veremos en el siguiente ejemplo(sesion1):

Sesion Paso 1

Siguiente

Y recogemos los valores en la siguiente pgina(sesion2), que guardaremos como sessioones5.php:

Sesion Paso 2

Nombre:

Apellidos:

SesionId:



8/68



Los valores de las variables almacenadasen la sesin se recogen utilizando$HTTP_SESSION_VARS[nombre_variable] pero tambin se puede utilizar suversin reducida $_SESSION, tal comopodemos ver en el ejemplo anterior.

Como podemos observar la recogida delos valores de las variables tambin lapodemos realizar mediante el array$GLOBALS que guarda todas las variablesde mbito global.

Si no se llamase la funcin session_start()para continuar con la sesin, no se podranrecuperar las variables globales.

Si nuestro script usa session_register(),no funcionar en entornos en donde ladirectiva PHP session.register_globals dephp.ini est deshabilitada. Actualmenteel uso de session.register() estdesfasado, por ello tanto para guardarcomo para recoger las variables de la

sesin utilizaremos $_SESSION comoya se ha visto anteriormente.

2.8 session_unregister

Esta funcin realiza el proceso contrariode la funcin anterior (session_register).Se encarga de eliminar la relacin entre

la variable y la sesin. Los argumentos de esta funcinson los nombres de las variables que queremosliberar.

Si sustituimos el cdigo de sesion2 por el siguiente:

Sesion Paso 2

Nombre:

Apellidos:

SesionId:

Recuerda que debemos ejecutar antes el cdigo desesion1 y despus el de sesion2

Obtendramos el siguiente resultado:



9/68


Para vaciar el valor de una variable de sesin tambin lopodemos realizar como en cualquier otra variable utilizandola funcin unset(nombre_variable) (Definida en el tema1)

2.9 session_is_registered

Esta funcin nos permite averiguar si una variable ya hasido registrada en la sesin. La funcin devolver true sila variable est registrada en la sesin y false en casocontrario.

Al sustituir el cdigo de sesion2 por el siguiente cdigo:

Sesion Paso 2

Nombre:

Apellidos:

SesionId:

Antes de utilizar session_unregister:

Variable Nombre:REGISTRADA

NO REGISTRADA

Apellidos:

REGISTRADA

NO REGISTRADA

Despus de utilizar session_unregister:
Variable Nombre:

REGISTRADA

NO REGISTRADA Apellidos:

REGISTRADA

NO REGISTRADA

Recuerda que debemos ejecutar antes el cdigode sesion1 y despus el de sesion2



10/68

Obtendremos el siguiente resultado:

Para comprobar si variable de sesin hasido inicializada, tambin lo podemosrealizar como en cualquier otra variableu t i l i z a n d o l a f u n c i nisset(nombre_variable) (Definida en eltema1)

2.10 session_decode

Recupera todos los datos de la sesinque estn almacenados en una cadenay que es pasada como argumento, dandovalores a las variables utilizadas en lasesin.

La sintaxis de la funcin es la siguiente:session_encode(string datos);

2.11 session_encode

Codifica los datos que provienen de lasessin actual, en una variable de tipostring.

La sintaxis de la funcin es la siguiente:session_encode();

3. Cookies

Uno de los problemas que nosencontramos en Internet es no poderidentificar a los usuarios que visitannuestras pginas. Si un usuario abandonanuestro site y a los cinco minutos vuelve,el servidor no es capaz de saber si setrata del mismo usuario o de otrodiferente. No nos vale controlar esto conlas sesiones, ya que si el usuario cerrase

su navegador o reiniciase su equipo,estara en una sesin distinta y lehabramos perdido la pista. Otra manerade mantener la sesin identificando alnavegante es utilizando las cookies.

Para solucionar este problema utilizaremoslas cookies, que son pequeos ficherosde texto que el servidor deposita en elcliente (es un espacio que reserva elnavegador) para que, si posteriormente

el mismo usuario accede al servidor, stees reconocido por el servidor al examinarla cookie previamente depositada.

El pequeo fichero de texto que formauna cookie se guarda de la siguienteforma:nombre=valory, a pesar de que se trata de algoinofensivo, estn rodeadas de unaseguridad adicional:un navegador web como Internet

Explorer o Netscape, tan slo puedealamacenar un nmero mximo de300 cookies en total y no ms de 20cookies por servidor.

Adems el tamao de una cookie estlimitado a 4kb. Si se alcanzase el lmitede 300 cookies, estas se iran eliminandopor antigedad.




11/68


El uso de las cookies es muy habitual enlas Webs en los que debe existir unseguimiento de las acciones del usuario.

Las cookies son parte de la cabeceraHTTP, por tanto debemos llamar la funcinsetcookie() (utilizada para crear cookies)antes de que se produzca cualquier salidaal navegador. Cualquier cookie del cliente,automticamente se convertir en unavariable PHP igual como ocurre con losmtodos de datos GET y POST,dependiendo de las variables deconfiguracin register_globals yvariables_order.

En PHP 4.1.0 y posteriores, la matrizauto-global $_COOKIE ser siempreactualizada con cualquier cookie mandadapor el cliente.

$HTTP_COOKIE_VARS tambin seactualiza en versiones anteriores de PHPcuando la variable de configuracintrack_vars est activada. (Siempre estactivada a partir de PHP 4.0.3.)

3.1 Crear una Cookie

Para trabajar con cookies, lo primero quedebemos hacer es crear una cookie ypara ello utilizaremos la funcin setcookie

La sintaxis de la funcin es la siguiente:

int setcookie (string nombre, stringvalor, int caducidad, string ruta,string dominio, int secure)

Todos los parmetros excepto nombreson opcionales. Tambin podemossustituir cualquier parmetro por unacadena de texto vaca ("") y saltar asese parmetro.

Los parmetros caducidady secure son nmeros enteros

y no podemos sustituirlos con una cadena de texto

vaca, en su lugar debemos utilizar un cero (0).

El parmetro caducidades un entero de tiempo tpico

de UNIX tal como lo devuelven las funciones time()

o mktime().

El parmetro secure indica que la cookie se debe

transmitir nica y exclusivamente sobre una conexin

segura HTTPS.

Si deseamos asignar mltiples valores a una cookie

simple, aade simplemente [] a el nombre de la cookie,

es decir, convertir a la cookie en un array de cookies.

Al ejecutar el cdigo anterior obtenemos el siguiente

resultado:



12/68

setcookie() define una cookie para serenviada con el resto de la informacin

de la cabecera HTTP.

Las cookies deben enviarse antes de

mandar cualquier otra cabecera (esta es

una restriccin de las cookies, no de

PHP). Esto requiere que situemos las

llamadas a esta funcin antes de cualquier

etiqueta o .

Si escribimos cualquier cosa antes de la

creacin de la cookie la ejecucin de

nuestra pgina PHP generar un error.

3.2 Borrar una Cookie

Para borrar una cookie se utiliza el mismo

sistema que para crear una nueva, pero

no se le asocia ningn valor.

De esta forma se elimina la cookie del

cliente.

3.3 Leer una Cookie

Para acceder al contenido de una cookie,

basta con utilizar el nombre de la variable.

Tambin podemos acceder al valor de lacookie utilizando:$HTTP_COOKIE_VARS[nombre].

O podemos utilizar su forma abreviada.

El resultado de ejecutar los tres ejemplosanteriores es:

print(HTTP_COOKIE_VARS: . $HTTP_COOKIE_VARS[alumno]);



13/68

3.4 Limitar el alcance de las

cookies

Las cookies se pueden limitar por mediode los parmetros que utilizamos en su

creacin, la limitacin de una cookie serealiza por tres mbitos:directorio de acceso: delimita el

directorio de acceso a la cookie, solo enel directorio que le indiquemos podremostener acceso a la cookie. Se define en elparmetro ruta en la creacin de la cookie.fecha de caducidad: estable la fecha

de caducidad de la cookie, se le debeindicar por medio de un nmero entero,utilizando las funciones mktime() o time().

Se define en el parmetro caducidadenla creacin de la cookie.dominio de procedencia: slo puede

accede a esa cookie el dominio indicadoen su creacin. Se define en el parmetrodominio en la creacin de la cookie.

4 Enviar cabeceras HTTP

Utilizaremos la funcin header() paraenviar cabeceras http. Su sintaxis es lasiguiente:

header(Nombre Cabecera: valor cabecera);

Al igual que la funcin setcookie se debeutilizar esta funcin al principio de lapgina, antes de escribir cualquier valoren el cliente.

En la siguiente entrega haremos uso detodo lo aprendido aplicado y seguiremoscon los sockets.



14/68


1. INTRODUCCION

Despus de haber estado hablando

indirectamente sobre el protocolo TCP/IPdurante 10 meses en la serie RAW, al finvamos a entrar de lleno en la base detodo esto: la base sobre la que se apoytoda la serie RAW.

Al hablar del protocolo TCP al fin vamosa comprender qu es lo que ocurrerealmente cuando hacemos un Telnet yla necesidad de establecer conexionesde este tipo.

Comprenderemos tambin por qu seutiliza TCP como protocolo de transportepara la mayora de las aplicaciones, alcompararlo con UDP y comprobar queson muchas las ventajas.

Con este artculo, entramos a fondo enconceptos nuevos, como son lasconexiones virtuales, el control de flujo,los flags, etc. Quiz no os queden deltodo claros los conceptos despus determinar de leerlo, pero no os preocupis,que est todo previsto.

El curso continuar con una segundaentrega dedicada a TCP, en la cualaclararemos muchos de los conceptosque quedarn hoy en el aire, y veremosuna serie de ejemplos que conseguirn

con la prctica lo que no se puedeconseguir con la mera teora.

Adems, para hacerlo un poco msamena, la segunda entrega incluirtambin algunas tcnicas de hackingbasadas en el funcionamiento de TCP,que es lo que a muchos de vosotros msos interesa. ;-) Aprenderemos adems aconstruir las cabeceras tal y como son enrealidad, en binario. Pero lo msimportante es que podremos ver en detallecmo es el trf ico que circulaconstantemente entre nuestro ordenadory la red Internet.

2. DIFERENCIAS ENTRE TCP YUDP

Por si no lo habis hecho, es importanteque antes de continuar repasis los dosartculos anteriores del curso de TCP/IP(Introduccin, y UDP), ya que vamos aempezar comparando este nuevoprotocolo con el que ya conocamos, el

protocolo UDP.

2.1. Conexiones virtuales

Volvemos a insistir una vez ms en queuna de las principales diferencias entreTCP y UDP es la existencia de conexionesvirtuales. Como ya vimos, el protocoloTCP se dice que es orientado a conexin

CURSO DE TCP/IP: (3 ENTREGA)TCP (TRANSMISION CONTROL

PROTOCOL) - 1 parte.- Empezaremos a estudiar las CABECERAS TCP

- Veremos las diferencias entre TCP y UDP

- Qu es eso de "protocolo orientado a la conexin"? ---> conexiones virtuales


15/68


(en realidad conexiones virtuales),al contrario que UDP (no orientado aconexin).

Las implicaciones de esto son muchas,tal y como iremos viendo a lo largo delartculo.

De momento quedmonos con la idea deconexin virtual.

Por qu se habla de conexiones virtuales,y no de conexiones a secas? Paraencontrar una respuesta a esta preguntabasta con pensar un poco en la

arquitectura de la red Internet (y decualquier red TCP/IP).

Si Internet hubiese existido hace 50 aos,probablemente su arquitectura hubierasido muy diferente, igual que la redtelefnica de ahora es muy diferente ala que haba entonces. La red telefnicade aquellos aos dependa de una figurahumana bien conocida: la telefonista.

Las telefonistas eran unas mujeres casib i n i cas que ac tuaban comointermediarias entre los distintos clientesde la red telefnica para que estospudieran comunicarse entre s. Cuandoun cliente deseaba hablar con otro, una

te le fon is tat en a quees t ab l e ce runa conexinmanual entre

las lneas dea m b o sc l i e n t e s ,conectandolos cab lescorrespon-dientes en unp a n e l d econexiones.

Imaginemos cmo habra sido la Interneten aquellos aos. Un autentico ejrcitode internetistas trabajando 24 horas

para dar servicio a todas las conexionesque estableciese cualquier cliente: cadavez que alguien desease leer su correoelectrnico, una internetista tendra queestablecer una conexin en el panel entreel cliente y su servidor de POP3, cada vezque alguien visitase una pgina web unainternetista tendra que establecer unaconexin entre el cliente y el servidor dela pgina web, etc., etc.

Desde luego, esto habra sido una locurainviable, sin contar con el hecho de quela red sera muy lenta y muy insegura.

Si tratsemos de mejorar esta ideasustituyendo a las internetistas humanaspor un medio mecnico automatizado queestableciese las conexiones medianterels seguiramos teniendo muchosproblemas, y uno de los ms preocupantessera el de la velocidad.

Se mire por donde se mire, una red enla que haya que establecer nuevasconexiones cada vez que se desee utilizarun servicio siempre ser ms lenta queuna red en la que todo est conectadode antemano.

Y precisamente esa es la topologa de lared Internet: todo est conectado deantemano. Nuestro PC siempre tiene unnico cable que nos conecta con Internet

(el cable de red que va al router, o elcable que va al modem, o el cable etreoque nos une con nuestra estacinwireless). Y lo mismo ocurre con cualquiermquina conectada a Internet. Nuncahay que cambiar ningn cable de sitio,por muy diferentes que sean lasconexiones que queramos establecer.Tanto si vamos a enviar un correo a

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)


16/68


nuestro mejor amigo, como si vamos aver una pgina web de Japn, lasconexiones fsicas son siempre las

mismas.Esto hace que los protocolos de la redInternet tengan necesariamente que estarmuy bien pensados para que esto no delugar a un completo caos. Para evitarestas confusiones nace el concepto deconexin virtual, que busca las ventajasde las redes en las que las conexionesno estn establecidas de antemano, perosin toparse con sus desventajas.

Si bien todo sigue conectado deantemano, las conexiones virtualesemulan el mecanismo por el cual, antesde comenzar una comunicacin entre dospuntos, es necesario poner a ambaspartes de acuerdo y establecer unaconexin entre ambas.

En teora, las conexiones virtualespermiten, igual que una conexin real,que la comunicacin no sea escuchadapor nadie que no est conectado al cableque une ambos puntos, que terceraspersonas no puedan intervenir en lacomunicacin enviando datos que nosean de ninguna de las dos parteslegtimas, que nadie pueda hacerse pasarpor otro, etc., etc. Por supuesto, todoesto es en teora pero, como biensabemos, nada en este mundofunciona como en teora debera. ;-)

Qu es lo que caracteriza una

conexin?

Las conexiones de las que hemos habladoson siempre conexiones entre dospuntos, y as son todas las conexionesen TCP. Aunque puedas estar en un chathablando con 100 personas a la vez, enrealidad toda esa comunicacin se realizaa travs de pares de conexiones.

Para entenderlo, veamos el caso de unchat entre 3 personas. Podramos pensaren primer lugar en una solucin que fuese

un nico cable con 3 conectores queconectase entre s a los 3 interlocutores.

Pero, que ocurrira si quisiramos metera una persona ms en la conversacin?Tendramos que quitar el cable de 3conectores y cambiarlo por uno de 4?Sera mucho ms sencillo un sistema enel cual todo funcionase mediante cablesde slo dos conectores. Para que alguienentrase o saliese del chat, bastara conconectar o desconectar un slo cable,pero no habra que modificar toda la red,y el resto de usuarios del chat no se veran

afectados por lo que hiciera uno solo.

Para poder realizar este chat entre 3personas mediante cables de 2 conectoresse hace imprescindible la presencia de unintermediario que gestione todas lasconexiones de todos los usuarios. Esta esprecisamente la misin de un servidorde chat.



17/68


Como vemos en esta otra imagen, ahorahay 3 cables en lugar de uno slo, y cadacable conecta a un nico usuario con elservidor que gest iona el chat.

Es importante comprender que esto quehemos dicho de los cables de slo dos

conectores no se refiere a lasconexiones fsicas de Internet, si noa las conexiones virtuales que nos da elprotocolo TCP.

De hecho, muchas redes TCP/IP tienenfsicamente conectadas todas susmquinas entre s, en lugar de realizarlas conexiones mediante cables punto apunto, pero insisto en que esto sloocurre con las conexiones fsicas, perono con las conexiones virtuales, que son

siempre punto a punto.

Por lo que hemos visto hasta ahora, es obvio que lo

primero que caracteriza a una conexin son los dos

extremos que conecta. En nuestro contexto, los

extremos de la conexin se identifican mediante lasconocidas direcciones IP.

Pero la identificacin de los extremos no es lo nico

que caracteriza una conexin. Cada uno de los

extremos podra tener varios conectores diferentes,

as que no slo basta saber con quin conectas, si

no tambin dnde. En nuestro contexto, cada uno

de los conectores de un mismo extremo seran los

diferentes servicios: HTTP, FTP, POP3, etc.

Por tanto, al igual que ocurra con UDP, otro de los

parmetros que caracterizan una conexin TCP son

los puertos de conexin de ambos extremos.

Si se tratase de conexiones fsicas, no hara falta

mucho ms para ser caracterizadas. En cambio, al

tratarse de conexiones virtuales, necesitamos algn

mecanismo que identifique una conexin establecida.

Y es aqu donde vemos la principal diferencia entre

TCP y UDP.

Los paquetes TCP contienen un campo en su cabecera

que no contienen los paquetes UDP. Este campo

adicional es el que permite identificar la conexin

virtual a travs de la cual circula el paquete.

La solucin ms obvia que podramos encontrar

para implementar este identificador de conexin

sera utilizar un nmero que identificase

unvocamente la conexin. Pero esta solucin

presentara varios problemas, el mayor de los cuales

sera quiz la seguridad.

Si una conexin se identifica permanentemente por

un mismo nmero, es slo cuestin de tiempo que

un atacante encuentre ese nmero por fuerza bruta

y as, con slo spoofear su IP (utilizar algn

mecanismo para enviar paquetes en nombre de una

IP que no sea la suya), se pueda colar en la conexin

ajena. Una solucin mucho mejor es utilizar un

nmero que vaya cambiando con cada paquete,

segn unas ciertas normas establecidas entre los

dos extremos.

Hablando claro...!


Hablando claro, no importa como conectes fsicamente tu PC

a otros PCs (hay mil maneras de hacerlo, unas son punto a

punto y otras no). Lo importante es que TU PC (y cualquier

otro PC del mundo), cuando utilice el protocolo TCP,

establecer siempre conexiones virtuales punto a punto.


18/68


Esto en realidad no es tal y como lo pinto. Este

nmero cambiante realmente existe, pero su principal

finalidad no es la de identificar conexiones, si no

ms bien la de mantener el estado de evolucin deuna conexin, y saber as en todo momento qu

paquetes se pueden enviar y qu paquetes se pueden

recibir a travs de esa conexin.

Este nmero es el llamado nmero de secuencia,

pero mejor ser que no nos precipitemos ms, que

ya habr tiempo de ver todo esto en detalle.

2.2. Fiabilidad en la comunicacin

Como ya cont en el artculo sobre UDP, al contrarioque ste, el protocolo TCP tiene un mecanismo para

asegurar que los datos llegan correctamente a su

destino. Para conseguir esto, cada paquete TCP que

llegue a un destino ha de ser respondido por ste

mediante otro pequeo paquete que confirme la

recepcin.

Esto sera as en el caso ms sencillo,pero menos comn, que sera el de unacomunicacin unidireccional, donde slouna de las partes enviase datos a la otra.

En la prctica, la mayora de los serviciosson bidireccionales, por lo que esnecesario intercalar los paquetestransmitidos con las confirmaciones delos paquetes recibidos.Esto podra dar lugar a un gran nmerode paquetes (el doble, exactamente), yaque a cada paquete de datos habra quesumar adems el correspondientepaquete de confirmacin.

Una solucin mucho ms eficiente esenglobar en un slo paquete los datostransmitidos y la confirmacin de los datos

recibidos.

En esta figura vemos cmo las mquinasA y B intercambian paquetes a travs deuna misma conexin, actuando ambossimultneamente como transmisores yreceptores.

En primer lugar, la mquina A enva elprimer paquete (Paquete 1 A). Una vezrecibido el paquete 1 A, la mquina Bdecide tambin empezar a enviar suspropios paquetes, por lo que enva unnico paquete a A en el que engloba laconfirmacin de que recibi el paquete 1A, as como su propio paquete 1 B.

A esto responder la mquina A enviandoel siguiente paquete de los que deseatransmitir, pero englobando en el mismotambin la confirmacin de que recibicorrectamente el paquete 1 B.

As continuara la comunicacin, hastaque la mquina A decidiese dejar detransmitir sus propios datos, por lo que

su nica misin consistira ya slo enseguir confirmando la recepcin de lospaquetes que le enva B, como ocurre enla figura con el caso del paquete 2 B, alcual la mquina A responde slo con unaconfirmacin de recepcin, pero sinenglobar ms datos en el mismo paquete,ya que A no tiene ya nada ms que deseeenviar.



19/68


Qu ocurre si uno de los paquetesse pierde por el camino? Cada vez queuna mquina transmite un paquete TCP,

sta no lo borra de su memoria, si noque lo deja almacenado an por untiempo, esperando que llegue laconfirmacin de su recepcin. Si stallega, se podr borrar el paquete de lamemoria, y olvidarse para siempre del. En cambio, si pasado un tiempoprudencial no ha llegado la confirmacinde su recepcin, se asumir que elpaquete no ha llegado a su destino, porlo que ste se retransmitir. As, elpaquete se conservar en la memoriatodo el tiempo que sea necesario,reenvindolo cada cierto tiempo, hastaque al fin llegue la confirmacin de queel paquete fue recibido.

En el caso de que, debido a estosreenvos, un mismo paquete llegue msde una vez al mismo destino, no habrningn problema, ya que el diseo deTCP permite diferenciar perfectamenteun paquete de otro, por lo que al detectar

la duplicacin simplemente se rechazarla copia.

2.3. Orden en los datos

Tal y como decamos tambin en elanterior artculo, TCP identifica cadapaquete con un nmero de secuenciaque permite ordenarlos correctamenteindependientemente de su orden dellegada al destino.

En el caso de UDP, los paquetes se ibanprocesando segn iban llegando. Encambio, en TCP un paquete se puededividir en fragmentos que podrn llegaren cualquier orden, y los datos no seprocesarn hasta que se hayan recibidotodos los fragmentos y estos se hayanordenado segn el nmero de secuenciade cada paquete.

2.4. Tratamiento de paquetesgrandes

Esta capacidad de dividir los datos enfragmentos ordenados, combinada con elsistema de confirmacin de respuestasde TCP, convierte a ste protocolo en unprotocolo de transporte ideal para latransmisin segura de grandes cantidadesde datos.

2.5. Control de flujo

Aqu entramos ya en un nuevo concepto

que habr que introducir, ya que es unode los conceptos bsicos del campo delas redes y telecomunicaciones.

Hasta ahora hemos tratado las redes ylas mquinas como si fuesen perfectas,sin limitaciones. Pero sabemos muy bienque en la vida real esto no es as ya que,por ejemplo, el ancho de banda de unared es uno de los factores msdeterminantes de su efectividad.

Hemos asumido que los paquetes se ibantransmitiendo a diestro y siniestro, y queestos iban a ser recibidos sin problemas.Bueno, no exactamente... Hemos dichoque s que poda haber problemas en larecepcin, pero realmente no hemoshablado de los problemas del ancho debanda.

Si la nica solucin ante la congestin de

la red fuese el mecanismo explicadoanteriormente para asegurarnos de quetodos los datos llegan al destino, elproblema no se solucionara si no que, alcontrario, sera cada vez mayor.

Imaginemos la situacin. La mquina A,que transmite los paquetes, es demasiadorpida para lo que es capaz de procesar



20/68


la mquina B, que recibe los paquetes.Por tanto, la mquina A empieza a enviarpaquetes a toda velocidad y sin

compasin, esperando las confirmacionesde la mquina B. Como B no da abasto,no es capaz de enviar las confirmacionesde recepcin a tiempo. Al no llegar lasconfirmaciones, A se pondr a reenviarlos paquetes anteriores, al mismo tiempoque contina enviando paquetes a diestroy siniestro, por lo que la congestin,sumando los paquetes nuevos y los viejos,ser muchsimo mayor.

Si no se implementa algn mecanismopara evitar este caos, la situacin puedehacerse insostenible en poco tiempo. Unmecanismo que se encargue de ajustarel f lujo de la comunicacin esprecisamente lo que se conoce comocontrol de flujo.

En el caso de TCP, disponemos de unsencillo mecanismo de control de flujo,que consiste en incluir en la cabecera de

cada paquete un campo que indica alotro extremo de la comunicacin cmoestamos de congestionados. Esta medidade la congestin la llevamos a cabodiciendo cuntos bytes estamospreparados para recibir. Segn nosvayamos saturando, este nmero sercada vez menor, y el otro extremo de la

comunicacin, a no ser que sea un mal-nacido (que los hay), tendr que actuaren consecuencia, relajndose un poco y

dndonos tiempo a asimilar lo que ya nosha enviado.

Ms adelante veremos en detalle cmose implementa el control de flujo en TCP.

3. LO QUE S QUE TIENEN ENCOMN TCP Y UDP

Como no todo va a ser diferencias, vamosa ver los puntos en comn entre ambosprotocolos de transporte que, en el fondo,son bastante parecidos.

En primer lugar, TCP tambin se apoyasobre el protocolo IP y, en este caso, elnmero de protocolo asignado a TCPpara que la capa de red (la capa IP) puedaidentificar el protocolo de transporte, esel nmero 6.

Como ya sabemos, la cabecera IPcontendr entre sus campos uno queidentifique el protocolo de transporte queest por encima de l.

Todo esto que...!


Todo esto que estamos explicando despus lo tocaremos

en la realidad. Veremos los paquetes TCP y dnde est

localizado cada concepto del que hablamos.


21/68


El punto en comn ms importante entre

TCP y UDP es que el mecanismo de

identificacin de servicios es el mismo:

cada paquete, tanto en TCP como enUDP, lleva dos nmeros de puerto

(origen, y destino), ambos comprendidos

entre 0 y 65535 (16 bits).

Los puertos de TCP funcionan

exactamente igual que los de UDP, pero

no tienen ninguna relacin entre s, es

decir, existen 65536 puertos para TCP, y

otros 65536 puertos diferentes para UDP.

Si, por ejemplo, en un firewall cierras elpuerto 21 de TCP, no estars cerrando

al mismo tiempo el puerto 21 de UDP,

ya que son totalmente independientes.

Otro punto en comn es que ambos

protocolos incluyen una suma de

comprobacin en cada paquete, que

verifica la correccin de los datos incluidos

en el mismo. La cabecera que se codifica

en la suma de comprobacin de TCP esmuy similar a la que se utiliza en UDP.

4. LA CABECERA TCP ENDETALLE

Entramos ya en los detalles tcnicos del

protocolo TCP. En este caso, el RFC que

los especifica es el RFC 793. Desde la

pgina de los RFC (http://www.rfc-

editor.org) podemos bajar tanto versinen TXT (http://www.rfc-editor.org/cgi-

bin/rfcdoctype.pl?loc=RFC&letsgo=793

&type=ftp&file_format=txt), como versin

en PDF (http://www.rfc-editor.org/cgi-

bin/rfcdoctype.pl?loc=RFC&letsgo=793

&type=ftp&file_format=pdf).

Como vemos, el RFC tiene 91 pginas,por lo que es bastante ms denso que lamayora de los RFCs que hemos vistohasta ahora (tanto en la serie RAW comoen el curso de TCP/IP). An as, no esdemasiado duro de leer, sobre todo siprescindimos de algunas cosas pocoimportantes para la comprensin delprotocolo, como la especificacin de lasvariables del TCB, o toda la parte del finalrelativa al procesamiento de eventos. Encualquier caso, ya sabis que aqu tendrisun buen resumen de todo lo ms

importante. ;-)

Como ya somos expertos en protocolos,vamos a plantar aqu directamente lacabecera TCP. No pierdas de vista estaimagen, haremos referencia a ella a lolargo de todo el artculo.

RFC 793 en espaol!


RFC 793 en perfecto espaol!!! Como ya hemos comentadomuchas veces, tenemos traducidos muchos de los RFC al espaol

en la Web www.rfc-es.org. Este es el trabajo de muchas personas

que desinteresadamente estn colaborando en un proyecto

realmente descomunal: traducir los ms de 3000 documentos, si

controlas de Ingles y te animas, ya sabes :)

El RFC 793 en castellano est en http://www.rfc-

es.org/getfile.php?rfc=0793


22/68


Bueno, bueno, la cosa ya va siendo msseria, eh? ;-)Que nadie se asuste! Ya veris como

en un momento comprendemos todo loque hay en esa imagen aparentementetan complicada.

Vamos a ir viendo campo por campo todala cabecera, para luego entrar en detalleen el tamao de los campos a nivel debit (ya en el prximo artculo).

4.1. Puerto de origen

Este campo tiene el mismo significadoque en el caso de UDP. En TCP es deespecial importancia, porque es condicinnecesaria (aunque no suficiente) paraidentificar una conexin virtual.

4.2. Puerto de destino

Tambin tiene el mismo significado queen UDP, y tambin es condicin necesaria(aunque no suficiente) para identificar

una conexin virtual.

Es decir, si nos llega un paquete quecoincide en IP de origen, IP de destino,Puerto de origen, y nmero de secuencia,con los de una conexin virtual, pero nocoincide el puerto de destino, entoncesese paquete no se puede considerarperteneciente a esa conexin virtual. Lomismo ocurre si el que cambia es elpuerto de origen.

4.3. Nmero de Secuencia

Aqu empieza lo ms divertido, ya queeste campo es uno de los que ms nosdar que hablar. El nmero de secuenciaes un nmero bastante grande (32 bits)que tiene varias funciones.

Por un lado, identifica unvocamentea cada paquete dentro de una conexin,y dentro de un margen de tiempo. Es

este nmero el que nos permite detectarsi un paquete nos llega duplicado. Duranteun margen de tiempo (que depende delflujo de los datos y, por tanto, tambindel ancho de banda) tenemos la garantade que en una determinada conexinvirtual no habr dos paquetes diferentescon el mismo nmero de secuencia.

Por ejemplo, en una conexin de 2Mbps,este margen de tiempo es de unas 4 horasy media, mientras que en una conexinde 100Mbps el margen es de 54 minutos.

Por qu este margen de tiempo vara enfuncin del flujo de datos? Pues locomprenderemos en cuanto veamos ques exactamente el nmero de secuencia.

Y es que el nmero de secuencia es muchoms que un mero identificador depaquetes. El valor del nmero desecuencia no es aleatorio, si no que tiene

un significado muy concreto. El nmerode secuencia es el orden en bytes queocupan los datos contenidos en elpaquete, dentro de una sesin.

Es decir, supongamos que el primerpaquete enviado una vez establecida unaconexin tiene un nmero de secuencia0, y el paquete contiene 200 bytes dedatos. El siguiente paquete que se enviasetendra que tener 200 como nmero de

secuencia, ya que el primer paquetecontena los bytes del 0 al 199 y, portanto, el orden que ocupan los datos delsegundo paquete es el siguiente: 200.

Por qu decamos entonces que elnmero de secuencia ident i f icaunvocamente un paquete dentro de unmargen de tiempo? Porque el nmero de



23/68


secuencia es siempre creciente, por loque un paquete posterior a otro siempretendr un nmero de secuencia mayor.

Claro que... ser mayor en mdulo 32.Esto significa que, una vez que el nmerode secuencia valga 232 1, es decir, elmayor nmero que se puede representarcon 32 bits, el prximo nmero desecuencia utilizado ser 0, es decir, sedar la vuelta al marcador.

Por supuesto, cunto se tarda en dar lavuelta al marcador depende directamentede cuntos datos se enven, y en cuantotiempo.

En la imagen podemos ver reflejado esto.Como vemos, el primer nmero desecuencia es 0, y el primer paquetecontiene 200 bytes de datos. Por tanto,el segundo paquete tendr nmero desecuencia 200. Este paquete contiene12345 bytes de datos, por lo que elprximo paquete tendr como nmerode secuencia: 200 (nmero de secuenciaanterior) + 12345 = 15345.

As contina la sesin, hasta que unpaquete tiene como nmero de secuencia232 1, y contiene 300 bytes de datos.En teora, el prximo nmero de secuenciatendra que ser 232 1 + 300 pero, comosolo contamos con 32 bits pararepresentar este nmero, tendremos quedar la vuelta al marcador, es decir,convertir el 232 en un 0, por lo que nos

quedara: 0 1 + 300 = 299. Por tanto,299 sera el nmero de secuencia delprximo paquete.

En realidad, el nmero de secuencia notiene por qu comenzar en cero. Elprincipal motivo es que si todas lasconexiones empezasen en 0, no se podranreutilizar las conexiones.

Ya a estas alturas, habiendo visto todoslos campos relevantes, podemos afirmarque lo que identifica una conexin sonestos 5 parmetros: ip de origen, ip dedestino, puerto de origen, puerto dedestino, y nmero de secuencia.

Imaginemos que, por ejemplo, nuestrosoftware de correo electrnico estconfigurado para comprobar si tenemosmensajes nuevos cada 30 segundos. Elprograma tendr que establecer unaconexin TCP/IP con el puerto 110 (puertode POP3) de un servidor POP3 cada 5segundos. En este caso, 4 de losparmetros que identifican la conexinpodran ser iguales: puerto de origen,puerto de destino, ip de origen, e ip dedestino.

Digo que podran porque el puerto deorigen se podra cambiar de una conexina otra (el resto de parmetros no sepodran cambiar de ninguna manera),aunque esto en muchos casos no serposible o conveniente. Por tanto, el nicoparmetro con el que podemos jugar para

poder establecer nuevas conexionessimilares sin que se confunda la nuevacon una vieja que ya se cerr, es elnmero de secuencia.

Si cada vez que el programa de correose reconecta al servidor POP3 utilizamosel mismo nmero de secuencia paracomenzar la sesin (por ejemplo, 0), si



24/68


llegase un paquete muy retrasado delservidor de correo de una conexinanterior (de los 5 segundos anteriores),

no habra forma de saber si este paqueteperteneca a la sesin anterior, o a lanueva sesin. Una forma sencilla de evitaresto es no utilizar siempre el mismonmero de secuencia para comenzar unasesin, si no ir utilizando nmeros desecuencia cada vez mayores.

Veamos un ejemplo de esto a partir dela siguiente figura.

En primer lugar, la mquina A abre unaconexin con la mquina B. Una vezabierta la conexin, A empieza atransmitir sus datos, empezando por unpaquete con nmero de secuenciaSeq = 0. B lo recibe y devuelve suconfirmacin de recepcin.

A continuacin, A transmite un nuevopaquete, con nmero de secuencia 200(por tanto, el primer paquete tena quecontener 200 bytes de datos). Por algnazar del destino, este paquete va a tardar

ms de lo normal en llegar a B. Como Aya ha enviado lo que quera, cierra laconexin, a pesar de que todava no ha

recibido la confirmacin de que B recibiel paquete Seq = 200.

Inmediatamente despus, A decideestablecer una nueva conexin con B paraenviarle otros datos. Comienza enviandoun primer paquete con Seq = 0, al cualresponde B con su confirmacin derecepcin. Para entonces, ya ha llegadoa B el paquete Seq = 200 de la anteriorconexin, por lo que construye su paquetede confirmacin. Pero la mala suerte seconfabula contra estas dos mquinas, y

justo en ese instante A enva un nuevopaquete, que tiene tambin nmero desecuencia 200. Inmediatamente B envala confirmacin de recepcin del paqueteSeq = 200 de la anterior conexin.

Qu ocurre a partir de aqu?

1.- Desde el punto de vista de A, Bha recibido correctamente el ltimo

paquete, por lo que continatransmitiendo nuevos paquetes,borrando de su memoria el paqueteSeq = 200, por lo que nunca loreenviar.

2.- Desde el punto de vista de B,acaba de recibir un nuevo paqueteSeq = 200. Como B ya habarecibido un paquete Seq = 200,interpreta que ste paquete es unreenvo del anterior, por lo que lodesecha.

Por tanto, ni B recoge el paqueteSeq = 200, ni A se entera de lo que hapasado. En realidad las cosas no sonexactamente como las pinto, pero yairemos viendo ms adelante cmo es todoesto realmente.



25/68


Por supuesto, el nmero de secuencia

no sirve slo para detectar paquetes

duplicados, o para diferenciar unas

conexiones de otras, si no tambin parapoder ordenar los paquetes. Como el

nmero de secuencia representa el orden

exacto en bytes de los datos, es imposible

confundirse a la hora de unir los datos

en el orden correcto.

4.4. Nmero de confirmacin

Este campo es el que se utiliza para hacer

las confirmaciones de recepcin de las

que tanto hemos hablado. Su

funcionamiento es muy similar al del

nmero de secuencia, porque en realidad

tambin representa un orden en bytes

de los datos.

Lo que se enva en el nmero de

confirmacin es otro nmero de 32 bytes

que indica cul es el prximo byte que

estamos esperando rec ib ir .

Si nuestro compaero en una conexin

nos enva un paquete con nmero de

secuencia 2000, y el paquete contiene

350 bytes de datos, el prximo nmero

de secuencia sera el 2350. Si queremos

confirmar que hemos recibido el paquete

con nmero de secuencia 2000,

tendremos que enviar en nuestro paquetede respuesta un nmero de confirmacin

que valga 2350, diciendo as: Ya puedes

enviarme el paquete 2350. He recibido

todo bien hasta aqu. Vamos a ver la

misma figura que pusimos al hablar sobre

el nmero de secuencia, pero esta vez

incluyendo los nmeros de confirmacin.

Este campo slo tiene significado si elpaquete tiene activo el flag ACK, peroeso ya lo veremos ms adelante.

4.5. Comienzo de datos

Este campo no era necesario en el casode UDP, ya que la cabecera UDP tiene untamao fijo de 8 bytes. En cambio, la

cabecera TCP puede tener un tamaovariable, tal y como veremos msadelante, por lo que es necesario indicara partir de qu punto comienzan los datosy termina la cabecera.

Este punto de comienzo no se expresaen bytes, como podramos esperar, si noen palabras de 32 bits. Si nos fijamosen la cabecera, veremos que estestructurada en filas, cada una de las

cuales mide 32 bits. La primera filacontiene los puertos de origen y destino,la segunda el nmero de secuencia, latercera el nmero de confirmacin, etc.

El valor ms habitual para este campo es5, que equivale a 20 bytes de cabecera,es decir, lo mnimo que puede ocupar lacabecera TCP.



26/68


4.6. Espacio reservado

Despus del campo comienzo de datos,

vemos que hay uno en el quesimplemente pone 0. Este es un espacioreservado de 4 bits, que hay que dejara cero, sin ms.

4.7. FLAGS (URG, ACK, PSH,RST, SYN, FIN)

Aqu tenemos tambin un asunto que vaa dar mucho que hablar. Los flags sonuna serie de indicadores de control, de

un nico bit cada uno, con diferentesfunciones que detallo a continuacin.

4.7.1. Flag URG (Urgent)

Cuando este flag est activo (vale 1, enlugar de 0), estamos indicando que elpaquete contiene datos urgentes. Laespecificacin de TCP no detalla qu sedebe hacer exactamente ante unos datosurgentes, pero lo normal es atenderlos

con mxima prioridad.

Si, por ejemplo, estamos procesandodatos anteriores, y nos llega un paquetecon datos urgentes, normalmenteaplazaremos el procesamiento de losdatos anteriores para prestar toda nuestraatencin a los datos urgentes.

Y para qu pueden servir los datosurgentes? No es habitual encontrarlos,

pero un claro ejemplo es cuandodeseamos abortar alguna accin. Porejemplo, si alguna vez habis conectadopor Telnet con un sistema remoto (elpropio servicio de Telnet del puerto 23,no los experimentos raros que hacamosen la serie RAW ;-) sabris que con lacombinacin de teclas CONTROL- C sepuede abortar cualquier accin.

Imaginemos que queremos ver elcontenido de un archivo remoto, porejemplo en Linux, y hacemos un cat del

archivo:

cat archivo.txt

El caso es que, despus de hacer el cat,descubrimos que el archivo es muchoms largo de lo que esperbamos y, paracolmo, no nos interesa. PulsamosCONTROL-C y el listado del archivo seaborta sin necesidad de esperar a que elarchivo termine de mostrarse entero.

El paquete que hemos enviado a lamquina remota conteniendo la orden deabortar el listado, tiene un flag URG

activo.Si no existiese este mecanismo,probablemente la mquina remota seguiraenfrascada en su asunto inmediato, quees mostrar el listado del archivo, y nohabra hecho caso a nuestro CONTROL-C hasta que no hubiera terminado con losuyo.

Para garantizar una mayor efectividad delflag URG hay que combinarlo con el flag

PSH, que veremos ms adelante.

4.7.2. Flag ACK (Acknowledge)

Cuando este flag est activo (vale 1, enlugar de 0) significa que nuestro paquete,aparte de los datos propios que puedacontener, cont iene adems una

Qu no sabis...!


Qu no sabis lo que es cat? Pues tendris que repasar los

artculos ya publicados sobre Linux de esta misma revista.

;-) y si no, consulta el google (www.google.com).


27/68


confirmacin de respuesta a lospaquetes que est enviando el otroextremo de la conexin.

Por tanto, el campo nmero deconfirmacin no tiene significado a noser que est activo este flag.

4.7.3. Flag PSH (Push)

Cuando este flag est activo (vale 1, enlugar de 0) indicamos a nuestro propiosistema, y al sistema remoto con el queestamos conectados, que deben vaciar

sus buffers de transmisin y recepcin...Creo que ha llegado el momento de hablarsobre los buffers de transmisin yrecepcin. :-m

En todo sistema TCP tiene que haber dospequeas memorias, o buffers: una paratransmisin, y otra para recepcin. Estasmemorias son unas colas de paquetesen las que se van almacenando los

paquetes que hay que procesar en esperadel momento adecuado.

Por ejemplo, supongamos que unaaplicacin que corre en nuestro sistemadesea enviar un archivo, que ser partidoen 4 paquetes TCP. A pesar de quenuestra aplicacin lance la orden de enviarel archivo en un slo instante, nuestrosistema no podr enviar de golpe los 4paquetes. Por tanto, tendr que construir

los paquetes, y luego ponerlos en unacola para que se vayan enviando uno trasotro.

Si el sistema pudiera enviar los 4 paquetesa la vez no habra necesidad de tenerninguna cola, pero en la prctica, comoen cualquier cola, slo se puede pasarde uno en uno.

En la imagen podemos ver cmo lospaquetes sin flag PSH se van encolandoen el buffer de transmisin. Cuando elsistema construye el ltimo paquete (elpaquete Seq = 300), ya puede comenzarel envo del archivo. Por tanto, en el ltimopaquete incluye el flag PSH.

A partir del instante en que hemos metidoen el buffer el paquete con flag PSH, elsistema ir enviando uno tras otro lospaquetes a travs del cuello de botellaque supone el canal de salida. Se tratade un cuello de botella porque por l slopuede pasar un nico paquete en cadainstante, por lo que los paquetes tendrn

que ir envindose de uno en uno segnel orden en que fueron ubicados en elbuffer de transmisin. Al tratarse de unacola, el primero en llegar ser el primeroen salir (lo que se llama una cola FIFO),por lo que primero saldr el paquete conSeq = 0.

El ltimo paquete en salir ser el quetiene Seq = 300, que es precisamente elque lleva el flag PSH. En la siguienteimagen vemos todo esto desde el puntode vista del receptor.



28/68


Por el canal de entrada irn llegando lospaquetes uno tras otro. Se irnalmacenando en el buffer de recepcin,

y no sern procesados hasta que llegueel ltimo paquete, que contiene el flagPSH. Como este paquete es el quecompleta el archivo de 400B, para cuandollegue, el sistema receptor ya podrprocesar los datos de los 4 paquetes yreconstruir el archivo original.

Como decamos, el flag PSH debecombinarse con el flag URG cuando hayadatos urgentes. El flag URG ser elencargado de decir al receptor que hade atender los datos con mximaprioridad, y el flag PSH se asegurar deque el paquete no se retrase esperandoen los buffers.

4.7.4. Flag RST (Reset)

Cuando este flag est activo (vale 1, enlugar de 0), estamos indicando al otroextremo de la conexin que algo no anda

bien, ya que los datos que nos han llegadono coinciden con nuestra conexin, porlo que se ha perdido la sincronizacinentre ambas partes.

Ante cualquier campo incorrecto querecibamos (nmeros de secuenciainvlidos, o flags no esperados)tendremos que responder con un paquetecon este flag activo, para que el otroextremo se entere del problema, y secierre la conexin para re-sincronizarambas partes.

Un uso tpico de este flag es cuandoestamos intentando conectar con unservidor, enviando varios paquetes paraestablecer la conexin, y al final uno deellos tiene xito. Si despus de esepaquete de conexin siguen llegando al

servidor el resto de nuestros intentos deconexin, el servidor nos responder conRST a cada nuevo intento de conexin,

para que nos olvidemos de esa conexiny nos centremos en la que ya tenemos.

4.7.5. Flag SYN (Synchronization)

Cuando este flag est activo (vale 1, enlugar de 0), estamos indicando al otroextremo que deseamos establecer unanueva conexin. Este flag se utilizanicamente al abrir una nueva conexin.

Ms adelante veremos el mecanismoexacto por el que se establecen lasconexiones, as como algunas cuestionesde seguridad relacionadas con este flag.

4.7.6. Flag FIN (Finish)

Cuando este flag est activo (vale 1, enlugar de 0), indicamos al otro extremode la conexin de que, por lo que anosotros respecta, la conexin ya se

puede cerrar.

Normalmente, una vez que enviemosnuestro propio FIN, tendremos queesperar a que nuestro compaero nosenve el suyo. Una vez puestos los dosde acuerdo en que no hay ms que hablar,se puede cerrar la conexin pacficamente.

Tanto RST como FIN se utilizan parafinalizar conexiones, pero la diferencia es

que RST avisa de una situacin de error,mientras que FIN avisa de unaterminacin sin problemas.

Ante una terminacin con RST,normalmente las aplicaciones avisarn alusuario, por ejemplo con una ventanaavisando que se ha perdido la conexin.



29/68


4.8. Ventana

Este campo es el que se utiliza para llevar

a cabo el control de flujo implementadoen TCP.

Como ya dije, el control de flujo permiteevitar la congestin debida a la diferenciade velocidad (bien por capacidad deprocesamiento, o bien por ancho debanda) entre ambas partes de unaconexin.

Una forma muy sencilla de conseguir esto

es hacer que cada extremo de la conexinvaya indicando a cada momento cmode congestionado est. La mejor formade indicar esta medida de congestin esdecir cuntos bytes vamos a ser capacesde procesar en un momento dado.

Por tanto, a cada paquete le acompaaun nmero de 16 bits, que es el nmerode bytes que estamos preparadospara recibir en el prximo paquete. Estosignifica que, como mximo, un paquetepodr contener 65536 bytes de datos,es decir, 64KB, ya que es el mximo quepodemos solicitar en cada momento.

Normalmente, el tamao de la ventanaest relacionado con la cantidad deespacio libre que tenemos en el bufferde recepcin.

Vamos a ver un ejemplo.

En primer lugar, la mquina A enva unpaquete de 1000 Bytes, con nmero desecuencia 0.

La mquina B lo recibe y procesacorrectamente, y enva su confirmacinde recepcin, indicando que la mquinaA puede continuar enviando a partir delbyte 1000 (Ack=1000). Adems, le indicaque est preparada para recibir otros1000 bytes ms. Si hacemos cuentas, enrealidad lo que est diciendo la mquinaB es que est preparada para recibir losbytes del 1000 al 1999.

La mquina A contina transmitiendo, ylo hace esta vez con 1000 bytes ms dedatos, empezando, por supuesto, por elnmero de secuencia 1000.

La mquina B tambin los recibe sinproblemas, pero se est empezando aagobiar un poco, por lo que avisa en suconfirmacin de que el prximo paqueteno podr ser tan grande y, como mucho,tendr que ser de 500 bytes nada ms.

La mquina A, en cambio, no ha recibidoa tiempo la nueva ventana, y ha seguidoenviando los paquetes al ritmo que llevabaanteriormente. Por tanto, el prximopaquete (Seq=2000) contiene tambin1000 bytes de datos, a pesar de que lanueva ventana de B admite slo 500bytes.

Justo despus de enviar este paquete

demasiado grande, la mquina A recibeya el aviso de B de que se estcongestionando, por lo que decide esperara ver cmo se las apaa su compaero.

Cuando B ha podido procesar unoscuantos datos, avisa a A de que puedeseguir enviando, aunque slo ha procesado500 bytes de los 1000 que le envi y,



30/68


adems, el prximo paquete tendr queser como mximo de 250 bytes.

En respuesta, A enva un nuevo paquete,comenzando en el byte 2500, yconteniendo tan slo 250 bytes.

Todo esto es muy bonito, A y B son muyamigos, y A le va enviando a B las cosaspoco a poco cuando ste se agobia. Peroesto en realidad no es una idea muybuena. Si A va haciendo caso a B segnste le vaya diciendo lo que puedemanejar, y B va avisando a A segn vayaliberando hueco en su buffer de recepcin,los paquetes que se transmitan irnsiendo cada vez ms pequeos.

En el peor de los casos, podra llegar aser 0 la ventana de B, y en el instanteen que hiciese hueco para un mserobyte, avisar a A, por lo que A le enviaraun paquete con un nico byte de datos.Esto dara lugar a una transferencia muypoco efectiva de los datos, donde muchosde los paquetes seran de un tamaoridculo.

Por tanto, es aconsejable no irajustndose literalmente al tamao dela ventana, si no dejar unos pequeosmrgenes. Por ejemplo, cuando se detecteque la ventana va decreciendo pormomentos, lo mejor es esperar un tiempopara dejar que la ventana vuelva arecuperar toda su capacidad, y continuarentonces la transmisin. Si fusemos con

prisas, empendonos en enviar ms yms datos, la reduccin de tamao de laventana sera cada vez mayor, y latransferencia cada vez menos eficiente.

En el caso de que la ventana llegue a sercero, la responsabilidad del receptor (elque se ha congestionado) es avisarcuando su ventana se recupere, con un

mensaje (vaco si hace falta) cuya nicafinalidad sea precisamente avisar delcambio de la ventana. Por otra parte, la

responsabilidad del emisor (el que hacongestionado al otro) es dejar de enviarms datos, y esperar un tiempo prudencialpara continuar la transmisin pasadosunos dos minutos, si es que el receptorno ha enviado una nueva ventana antes.

4.9. Suma de comprobacin

Al igual que en el caso de UDP, la sumade comprobacin se calcula mediante unaoperacin de aritmtica binaria (suma en

complemento a uno de 16 bits) que serealiza sobre una cabecera especial quecontiene los datos ms relevantes.

Cada vez que se recibe un paquete TCP,hay que realizar esta misma operacincon los datos recibidos, y comparar elnmero obtenido con el campo suma decomprobacin del paquete. Si ambosnmeros no son iguales, los datos sonincorrectos, y ser necesaria una

retransmisin de los mismos. En ese caso,no enviaremos la confirmacin derecepcin pertinente, esperando a que elemisor decida retransmitir el paquete alver que no les respondemos.

Aunque ya lo coment en el anteriorartculo, os recuerdo que tenis detalladala operacin de la suma de comprobacinen el RFC 1071, y que tenis un cdigode ejemplo en C en la siguiente URL:

http://www.netfor2.com/tcpsum.htmEn este caso no tenis que realizar ningunamodificacin sobre el cdigo, ya que sirveprecisamente para calcular la suma decomprobacin de TCP.

La cabecera que se forma para llevar acabo la suma de comprobacin es lasiguiente:



31/68


Como vemos, es igual que la de UDP,slo que en este caso el protocolo es el6, en lugar del 17.

4.10. Puntero de urgencia

Cuando hablamos sobre el flag URGdijimos que serva para indicar que elpaquete contiene datos urgentes.

Pero, significa esto que los datos tienenque ir en un nico paquete para ellossolos? Esto podra ser poco eficiente, yaque los datos urgentes podran ser tanslo unos pocos bytes, y nos obligara aenviar paquetes casi vacos slo parapoder transmitir el dato urgente.

Por ejemplo, el CONTROL-C del quehablbamos, es un comando muy breve,y sera un desperdicio enviar paquetesvacos que slo llevasen ese comando.Por tanto, TCP permite combinar enun mismo paquete datos urgentescon datos no urgentes.

Para conseguir esto, el campo punterode urgencia nos indica el punto a partirdel cual terminan los datos urgentes.

Si, por ejemplo, nuestro paquete contiene1000 bytes de datos, y el puntero deurgencia es 150, sabremos que los 150primeros bytes del paquete son urgentes,y los otros 850 son datos normales.Por supuesto, esto slo tendr sentido siel flag URG est activo. Si no es as, elcampo puntero de urgenciasimplemente ser ignorado.

4.11. Opciones

Llegamos al fin al ltimo campo de lacabecera TCP. Este campo es opcional, yes el responsable de que la cabecera TCPsea de tamao variable y, por tanto, dela necesidad del campo comienzo dedatos. En realidad, slo existe una opcindefinida por el estndar en el RFC de

TCP, pero la cabecera se dise conprevisin de incluir otras opciones.

La opcin definida se utiliza nicamenteal establecer una nueva conexin. Lo queindica este campo opcional es el mximotamao de los segmentos que estamosdispuestos a recibir. Un segmento es cadauna de las partes en las que se dividenlos datos, por lo que nuestro compaerode conexin no debe enviarnos nunca

paquetes ms grandes de lo queindiquemos con esta opcin. En el casode que no usemos este campo opcional,nos podr enviar paquetes de cualquiertamao ajustndose, eso s, a nuestraventana de recepcin.

Y qu relacin hay entonces entre laventana de recepcin y el tamao mximode segmento?

Pues la ventana es un parmetro dinmico,que va variando segn la congestin quehay en cada momento, mientras que eltamao mximo de segmento es unaconstante para toda la sesin, que seestablece de antemano. Muchas veces,el tamao mximo de segmento sermenor que la ventana. Esto puede parecerabsurdo, pero no es as, ya que el tener



32/68


una ventana mayor que el tamaomximo de segmento indica que tenemosrecursos suficientes para recibir varios

paquetes en poco tiempo.Por tanto, el tamao mximo desegmento no es til para realizar uncontrol de flujo, si no tan slo unarestriccin para el tamao mximo quepueden tener los paquetes.

Pero vamos a ver cmo se indicaexactamente esta opcin. Como ya hemosvisto, existen dos casos: o que noindiquemos ninguna opcin, o queindiquemos el tamao mximo de

segmento.

En el primer caso, simplemente terminaren este punto la cabecera TCP, ycomenzarn a partir de aqu los datos.Por eso, cuando hablbamos del campocomienzo de datos dijimos que eltamao mnimo de la cabecera (que eseste caso) es de 20 bytes.

En el segundo caso, en cambio, habrque rellenar el campo opciones de la

cabecera. Y no slo eso, si no que ademshay que ajustarlo a un tamao de 32bits, que es lo que ocupa cada fila de lacabecera TCP (en realidad, se trata deltamao de la palabra, ya que la idea defilas es slo una abstraccin para verms fcilmente la estructura de lacabecera).

La opcin que hemos mencionado, lanica definida en el RFC, encajaexactamente en 32 bits, por lo que no

hay que hacer ningn ajuste. El formatoexacto de esta opcin lo veremos msadelante cuando veamos las cabeceras anivel de bits.

En cambio, no slo existen las opcionesdefinidas en el RFC 793. Podemos veruna lista de opciones TCP mantenidas,para variar, por el IANA, en:http://www.iana.org/assignments/tcp-parameters

Una opcin que nos podremos encontrarcon facilidad de las de esa lista, es laopc i n SACK , u t i l i zada pa raconfirmaciones selectivas (SelectiveACKnowledgment).Los detalles sobre esta opcin los tenisen el RFC 2018 (ftp://ftp.rfc-editor.org/in-notes/rfc2018.txt).

Si las opciones no encajan en 32 bits,habr que completar la fila con ceros.

Para separar las opciones entre s se utilizauna opcin especial sin ningn efecto(NOP = No OPeration) que ocupa unnico byte.

Para terminar la lista de opciones existetambin otra opcin especial, de un nicobyte, que indica que no hay mas opcionesy, por tanto, una vez completada la palabrade 32 bits, vendrn a continuacin los

datos del paquete.

Todo esto lo veremos en ms detalleen el prximo artculo, en el cualempezaremos construyendo comoejercicio una cabecera TCP desde ceroa bajo nivel, es decir, en binario puroy duro. Espero que estis preparados!;-)



33/68

Para terminar, os incluyo aqu la cabeceraTCP con los nombres originales, en ingls,por si completis este curso con alguna

otra lectura, para que veis lacorrespondencia y no os liis.

Autor: PyC (LCo)

IMPORTANTE!


IMPORTANTE:Ya habr tiempo de pasar a la practica, ahora es importante

que empecemos a familiarizarnos con un montn de

trminos y conceptos que seguramente (para la mayora)

son completamente desconocidos.

No te preocupes demasiado si muchas cosas te han quedado

oscuras, ya empezars a verlas claras cuando relacionemos

la teora con la practica y veas la utilidad real de cada

concepto explicado aqu.


34/68


Bienvenidos un mes ms a la serie XboxLife. Este mes vamos a ver el Menu X,que nos permitir crear mens a nuestrogusto y as meter varios juegos en un

mismo DVD.

Pues manos a la obra, aqu tenis la listade lo que necesitamos:

Xbox con ModChip instalado.

Grabadora de DvD.

MenuX

Nero 6.019 o Superior

Editor de fotos (es opcional).

Todo menos el Men X se ha explicadoanteriormente, si no sabis de lo queestoy hablando pasaros por la Web ypedid los nmeros atrasados.

El software Menu X puedes descargarlodesde aqu en formato RAR:

http://www.megagames.com/console/

cgi-bin/dl.cgi?id=xbox&file=cpxmenux!rar

Descomprimimos el RAR o ZIP en una

carpeta que puede llamarse Menu (que

original que soy).

Esto es lo que veremos:

Nos metemos en la carpeta ISO yveremos esto:

Tambin puedes...!

Este men...!

Xbox Life VIMenu X

Por Alfonso Menkel- Descubriremos cmo realizar nuestros propios menus gracias a una versin hackeada

de la version oficial.

- Meteremos varios Juegos en un DVD

Tambin puedes descargarlo en formato ZIP de la Web de

la revista (www.hackxcrack.com).

Este men es el mismo que viene en las demos de la revista

oficial de Xbox. Fue hackeado y puesto a nuestro servicio.

Gracias.


35/68


Borramos la carpeta xbmedia, ya queesta carpeta es la que contiene elWindows Media Placer (y no nos interesa).

Aqu crearemos una carpeta por juego,solo como ejemplo yo crear 4 carpetasque corresponden a distintos emuladores:Nintendo, SuperNintendo, Nintendo64,PlayStation.

Recordad que esto es solo un ejemplo,vosotros pondris tantas carpetas como

juegos queris meter (siempre y cuandono superis los 4,4 GB de tamao total).

Ahora lo que vamos a hacer, es modificarla apariencia del men, para ello nosvamos a la carpeta de MenuX/Media:

Con un editor de fotos (por ejemplo AdobePhotoshop) podemos modificar todasestas imgenes a nuestro gusto. Aqu

dejo la correspondencia de cada imagenen el men:

--> Screen.Png = El fondo del men--> wait.png = La imagen que sale cuandoarrancas una aplicacin del DVD.--> Dn.png = Es una flecha que se coloca

justo debajo del recuadro de la lista dejuegos, esta apunta hacia abajo.--> Up.png = Lo mismo que el anterior,pero dirigido hacia arriba.

Todos los archivos tienen que llamarsedel mismo modo, con la misma extensin.

Screen.png es el fondo del men constade dos partes fundamentales, la lista de

juegos y la imagen previa:

Si modificas el screen.png, ten cuidado yrespeta las dimensiones de estos cuadrados

que te he marcado en rojo. En todo caso,puedes hacerlos mayores que los que vienen,pero nunca ms pequeos, ya que nopodremos modificar el tamao de estas celdas.

Cuando tengamos todas las imgenes listas,nos fijamos en esta misma carpeta en elarchivo ambient.wma.

Esta es la cancin que sonar durante laejecucin del men. Podemos cambiar el

XBOX LIFE (VI) - MENU X - XBOX LIFE (VI) - MENU X - XBOX LIFE (VI) - MENU X - XBOX LIFE


36/68


archivo por otro con la misma extensin ylisto, el men ya tiene la pinta y la msicaque nos gusta.

Ahora nos dirigimos a la carpeta sshot, dondeencontraremos la imagen previa del mediaplayer, es una imagen con extensin png ysus dimensiones son de 400 Pixeles de anchoy 300 de alto.

La borramos y ponemos aqu una imagen conextensin png (de las mismas medidas) porcada juego que vayamos a poner en el DvD.Acordaros de los nombres, ya que ahoratendremos que decirle al men qu imagenva con cada juego.

Copiamos los juegos a sus carpetascorrespondientes de la carpeta ISO.

Nos vamos a la carpeta Men y veremos unarchivo llamado config.txt, lo editamos conun editor de texto plano (por ejemplo el Blocde Notas de Windows):

Como podemos ver en la imagen, tememosesto:

TITLE=Xbox Media PlayerINFO=divx/vcd/networkGFX=media.pngDIR=xbmedia

Donde TITLE es el nombre del juego quesaldr en la lista de juegos.

INFO es la breve descripcin del juego.

GFX es la imagen previa del juego, la/las quehemos colocado en el directorio sshot.

DIR es el directorio dentro de la carpeta ISOdonde se encuentra el juego.

Entre juego y juego hay que dejar una lnea

en blanco.

As quedara el mo:

TITLE=Nintendo.INFO=Emulador.GFX=nintendo.pngDIR=Nintendo

TITLE=Super NintendoINFO=Emulador.GFX=Snintendo.png

DIR=Super nintendoTITLE=Nintendo 64.INFO=EmuladorGFX=N64.pngDIR= Nintendo64

TITLE=PlayStationINFO=EmuladorGFX=psx.pngDIR= PlayStation

Guardamos los cambios.

Arrancamos el archivo MenuX-xdi.bat y nosconfigurara el mensegn le hemos dicho.

Ya esta, quemamos enun DvD el contenido dela carpeta ISO tal y comohe explicado en nmeros anteriores.

El mes que viene veremos como crear CDs yDVDs autoinstalables.

Salu2

XBOX LIFE (VI) - MENU X - XBOX LIFE (VI) - MENU X - XBOX LIFE (VI) - MENU X - XBOX LIFE

Si habis...!

Si habis seguido los artculos anteriores publicados en la

revista, podis pasarlo por la red al HD del la consola y

as cercioraros que todo ha salido bien antes de grabar el

DVD.


37/68


INTRODUCCIN

En el artculo anterior aprendimos a instalarsnorte iniciamos nuestra primera incursinen el mundo de las reglas y directivas del

pre-procesador... ahora nos toca conocerloms a fondo.

En esta ocasin vamos a tener que realizaralguna que otra modificacin en la instalacinde snort, de hecho nos tocar en LINUXcompilar el cdigo fuente desnorte incluiralguna caracterstica que no se incluye en lospaquetes rpm, no te alarmes... todo estardetallado para que consigas el objetivo.

Como recordatorio digamos quesnorttrabajaen varios modos, como esniffer, como

capturador-grabador de paquetes o comoNIDS, lo que nos ocupa es conocer lascapacidades de snort en modo IDS ,concretamente en modo NIDS (NetworkIDS)

En este (NIDS) modo podemos ejecutarsnorten dos modos:

Modo logging, que grabar en disco todoslos paquetes que circulan por la red o haciao desde un host.

Modo Alerta, en el cual comprobar siexisten reglas de comportamiento de lospaquetes y en su caso nos vuelca un informeo registro de aquellos paquetes queconcuerdan con las mismas, advirtindonosde las infracciones que se cometan.

A su vez, el modo alerta dispone de algunasopciones que se pueden lanzar desde la lneade comandos de snort, estas son:

Full, es el modo por defecto y alertar detodos los paquetes que provoquen una alertay volcar todo el contenido de los mismos

Fast, como full pero slo registrar losmensajes de alerta, el timestamp (fecha/hora)

ip origen e ip destinoSyslog, que enviar los sucesos a un servidorSyslog definido

Unixsock o unsock, que enva las alertasa un servidor de dominio *NIX

SMB, que enva las alertas mediantemensajes Winpopup (mensajes emergentes)

None, en el que slo se emitirn logs, nadade alertas...

Si queremos utilizar algn modo de alertascomo los que definimos anteriormente, laorden sera (observa la opcin A que esquien indica el modo de alerta):

Hay algunas matizaciones con los modosSyslog y SMB, ms adelante las descubriremos,por ahora slo es necesario que recuerdesque se pueden usar y que existen.

Si queremos usarsnortsin generar alertasbastara utilizar la sintaxis:snort de l /var/snort_logs/

Recordemos como se iniciabasnort....

snort de l directorio de logs c directorio y fichero del

archivo de configuracin

Ejemplo:snort de l /var/snort_logs/ -c /etc/snort/snort.conf

snort de A fast l /var/snort_logs/ -c /etc/snort/snort.conf

curso de seguridaden redes - ids (II)

- Vamos a avanzar en el conocimiento del SNORT

- Estudiaremos las reglas, contramedidas y MUCHO MAS


38/68


Para complicar ms la cosa, podemosformatear la salida de logs es decir, darleun aspecto para su posterior lectura entrelos modos de presentacin ms habituales

estn:

CSV (Comma Separated Values), es unmodo habitual para observar los registrosdesde una hoja de clculo o base de Datos

Syslog, para personalizar la salida hacia elservidor Syslog

Database, para escribir la salida a Bases deDatos tipo MySQL, ODBC, ORACLE, etc..

Null, no crea archivos de logs pero s alertas

Tcpdump o Windump, formato de salidapara aplicaciones tcpdumo o windump

SnmpTrap, enviar registros SNMP

Unified, Formato de salida binario que puedeser ledo por diversas aplicaciones, es elmtodo de salida ms rpido

XML, pues lo imaginas.... formatos de salida

en lenguaje XML

Bueno, esto nos servir como introduccin

para ms adelante, cuando nos toque abordar

losplug-ins de salida... al igual que antes...

con que recuerdes que no todo es texto y con

el mismo formato es suficiente.

Tras la introduccin... pasemos a lo que nos

ocupa en este artculo: Las Reglas

LAS REGLAS de las REGLAS....

Ya nos hicimos a la idea de para qu puede

servir el definir reglas en elIDS, las reglas

son el alma en la deteccin de intrusos...

aquellos paquetes que cumplan (o no cumplan)

las reglas pasarn o no pasarn... mejor

dicho... se registrarn o no se registrarn.

Las reglas quesnortpuede aplicar al trficode red se basan en las cabeceras de lospaquetes y en el cuerpo o contenido de losmismos y en el control de flujo, por tanto

podremos aplicar reglas de cabecera, reglasde contenido y reglas de control.

LAS VARIABLES:

Antes de meternos de lleno en las reglas,vamos a ver unas cuantas cosas. Para quesnortpueda comparar esas reglas con algoo desde alguna parte se utilizan variables,la sintaxis genrica de las variables es:

var nombre_de_variable valor_de_variable

Todas las variables se definen en el archivode configuracin (snort.conf) y se procesan

de arriba abajo, y como es comprensible,deben estar definidas e inicializadas antes deusarse.

Ejemplos:

Si queremos asignar el contenido de otravariable a una nueva, usaremos:

var nueva_variable $variable_anterior

Esto es:

var MI_DNS $DNS_SERVER

var ESTA_ES_MIRED $INTERNAL_NET

Estars pensando qu pasara en estos ltimos

casos si las variables que actan como valores

de las nuevas no estuvieran previamentedefinidas... un error... para ellosnortpuede

utilizar el siguiente mtodo:

Esto significa que si $RED_INTERNA no estdefinida previamente, se asignar el valor172.28.0.0/16 a la variable ESTA_ES_MIRED

var DNS_SERVER 172.28.0.98

var INTERNAL_NET 172.28.0.0/16

var INTERNAL_NETS [172.28.0.0/16, 192.168.1.0/24, 10.0.0.0/8]

var ESTA_ES_MIRED $(RED_INTERNA:172.28.0.0/16)

Seguridad - IDS (II) - Seguridad - IDS (II) - Seguridad - IDS (II) - Seguridad - IDS (II) - Seguridad


39/68


Hasta se pueden lanzar mensajes de errorpara que avise de los mismos... por ejemplo:

Echa un vistazo al archivosnort.confparaver las variables que usa... entre ellasencontrars estas con estos valores (oparecidos):

Algunos valores especiales para la asignacinde variables son:

any Cualquier valor

! Negacin, por ejemplo !80 es NO el 80,

LAS REGLAS

Tras definir las variables tendremos que decidirqu reglas vamos a incluir en el IDS y lasdirectivas delpre-procesadorque queramos...

Normalmente las reglas a ser utilizadas sedeclaran mediante las lneas include y lasdirectivas delpre-procesadormediante laslneaspreporcessor:Ejemplo sacado del archivo de configuracinoriginal

(snort.conf)RULE_PATH /etc/snort/rules.....

preprocessor stream4_reassemble

preprocessor stream4: disable_evasion_alerts

...

include $RULE_PATH/local.rules

include $RULE_PATH/bad-traffic.rules

inc lude $RULE_PATH/exp lo i t . ru les

Lgicamente el hecho de incluir una regla en

el archivo de configuracin no lo es todo... lo

importante es conocer qu tiene esa regla. En

el archivo de configuracin simplemente se le

dice asnortque deseamos utilizar tal o cual

regla y ser en los archivos especificados

donde t end remos que de f i n i r e l

comportamiento de la regla.

Lo mismo podramos aplicar al pre-procesador... en la siguiente seccin nosocuparemos de l, ahora toca reglas....

Ya sabemos que snortvalida las reglas devarias formas, consulta las cabeceras de un

paquete de datos, consulta el contenido deese paquete, controla el flujo de datos... otodas a la vez...

volvemos con las analogas... las cabecerasseran el equivalente de las seas, remitente,etc. Del sobre de una carta o correo postal,mientras que las reglas de contenido abriranel sobre y buscaran dentro para leer lo quedice y actuar en consecuencia...

Las reglas de Cabecera inspeccionan:

Protocolos usados

Puertos origen y/o destino

Direcciones IP origen y/o destino

Las reglas de Contenido inspeccionan:

La totalidad o parte de la informacin queno es cabecera.

Las reglas de Control de f lujoinspeccionan:

La direccin del trfico (del cliente alservidor, del servidor al cliente)

El nmero de paquetes transmitidos

El tiempo de cada sesin

Las contramedidas o reacciones

....

var ESTA_ES_MIRED $(RED_INTERNA:? Vic_Thor, define RED_INTERNA)

Seguridad - IDS (II) - Seguridad - IDS (II) - Seguridad - IDS (II) - Seguridad - IDS (II) - Seguridad


40/68


Las reglas se definen de una forma muysencilla:

Accin Protocolo IP/red origen Puerto

origen Direccin IP/red Destino Puertodestino Contenido control de flujo

Vamos a detallarlo:

Accin puede ser: pass, log, alert, dynamico activate

Protocolo puede ser: ICMP, TCP, IP o UDP,hay otros pero fundamentalmente estos.

Origen y/o Destino son: Direcciones IPindividuales o direcciones de red en notacin

CIDRDireccin es decir si va hacia el origen o haciael destino

Contenido es todo aquello que contiene elpaquete, es decir los datos de que trasportanlos protocolos.

Control de Flujo: Tiempo transcurrido, nmerode paquetes, corte de la conexin...

Vamos a ver un ejemplo de una regla tipo:_

Accin: alert

Protocolo: tcp

IP/red or igen: 172.28.0 .0/16

Puerto Origen: cualquiera

Direccin: Desde el origen al destino

IP/red destino: Cualquiera

Puerto destino: 80

Lo que nos quedara as:

alert tcp 172.28.0.0/16 any -> any 80

Esta regla generara una alerta al usar elprotocolo TCP cuyo origen del paquete seadesde la red 172.28.0.0/16 y desde cualquierpuerto hacia cualquier red cuyo destino seael puerto 80.

En otras palabras, si cualquier PC de la red

Documents

Revista Hack X Crack 20