Telnet

Telnet (Telecommunication Network1) es el nombre de un protocolo de red que nos permite

acceder a otra máquina para manejarla remotamente como si estuviéramos sentados delante
de ella. También es el nombre del programa informático que implementa el cliente. Para que la
conexión funcione, como en todos los servicios de Internet, la máquina a la que se acceda
debe tener un programa especial que reciba y gestione las conexiones. El puerto que se utiliza
generalmente es el 23.

Funcionamiento[editar]
Telnet sólo sirve para acceder en modo terminal, es decir, sin gráficos, pero es una
herramienta muy útil para arreglar fallos a distancia, sin necesidad de estar físicamente en el
mismo sitio que la máquina que los tenga. También se usaba para consultar datos a distancia,
como datos personales en máquinas accesibles por red, información bibliográfica, etc.
Aparte de estos usos, en general telnet se ha utilizado (y aún hoy se puede utilizar en su
variante SSH) para abrir una sesión con una máquina UNIX, de modo que múltiples usuarios
con cuenta en la máquina, se conectan, abren sesión y pueden trabajar utilizando esa
máquina. Es una forma muy usual de trabajar con sistemas UNIX.

Problemas de seguridad y SSH[editar]

Su mayor problema es de seguridad, ya que todos los nombres de usuario y contraseñas
necesarias para entrar en las máquinas viajan por la red como texto plano (cadenas de texto
sin cifrar). Esto facilita que cualquiera que espíe el tráfico de la red pueda obtener los nombres
de usuario y contraseñas, y así acceder él también a todas esas máquinas. Por esta razón
dejó de usarse, casi totalmente, hace unos años, cuando apareció y se popularizó el SSH, que
puede describirse como una versión cifrada de telnet -actualmente se puede cifrar toda la
comunicación del protocolo durante el establecimiento de sesión (RFC correspondiente, en
inglés- si cliente y servidor lo permiten, aunque no se tienen ciertas funcionalidad extra
disponibles en SSH).

Telnet en la actualidad[editar]
Hoy en día este protocolo también se usa para acceder a los BBS, que inicialmente eran
accesibles únicamente con un módem a través de la línea telefónica. Para acceder a
un BBS mediante telnet es necesario un cliente que dé soporte a gráficos ANSI y protocolos
de transferencia de ficheros. Los gráficos ANSI son muy usados entre los BBS. Con
los protocolos de transferencia de ficheros (el más común y el que mejor funciona es
el ZModem) podrás enviar y recibir ficheros del BBS, ya sean programas o juegos o ya sea el
correo del BBS (correo local, de FidoNet u otras redes).
Algunos clientes de telnet (que soportan gráficos ANSI y protocolos de transferencias de
ficheros como Zmodem y otros) son mTelnet!, NetRunner, Putty, Zoc, etc..

Manejo básico de telnet[editar]

Para iniciar una sesión con un intérprete de comandos de otro ordenador, puede emplear el
comando telnet seguido del nombre o la dirección IP de la máquina en la que desea trabajar,
por ejemplo si desea conectarse a la máquina purpura.micolegio.edu.com deberá
teclear telnet purpura.micolegio.edu.com , y para conectarse con la dirección IP
1.2.3.4 deberá utilizar telnet 1.2.3.4 .
Una vez conectado, podrá ingresar el nombre de usuario y contraseña remoto para iniciar una
sesión en modo texto a modo de consola virtual (ver Lectura Sistema de usuarios y manejo de
clave). La información que transmita (incluyendo su clave) no será protegida o cifrada y podría
ser vista en otros computadores por los que se transite la información (la captura de estos
datos se realiza con un packet sniffer).
Una alternativa más segura para telnet, pero que requiere más recursos del computador,
es SSH. Este cifra la información antes de transmitirla, auténtica la máquina a la cual se
conecta y puede emplear mecanismos de autenticación de usuarios más seguros.
Actualmente hay sitios para hackers en los que se entra por telnet y se van sacando las
password para ir pasando de nivel, ese uso de telnet aún es vigente.

Seguridad[editar]
Hay 3 razones principales por las que el telnet no se recomienda para los sistemas modernos
desde el punto de vista de la seguridad:

 Los dominios de uso general del telnet tienen varias vulnerabilidades descubiertas a lo
largo de los años, y varias más que podrían aún existir.

 Telnet, por defecto, no cifra ninguno de los datos enviados sobre la conexión (contraseñas
inclusive), así que es fácil interferir y grabar las comunicaciones, y utilizar la contraseña
más adelante para propósitos maliciosos.

 Telnet carece de un esquema de autentificación que permita asegurar que la

comunicación esté siendo realizada entre los dos anfitriones deseados, y no interceptada
entre ellos.

En ambientes donde es importante la seguridad, por ejemplo en el Internet público, telnet no

debe ser utilizado. Las sesiones de telnet no son cifradas. Esto significa que cualquiera que
tiene acceso a cualquier router, switch, o gateway localizado en la red entre los dos anfitriones
donde se está utilizando telnet puede interceptar los paquetes de telnet que pasan cerca y
obtener fácilmente la información de la conexión y de la contraseña (y cualquier otra cosa que
se mecanografía) con cualesquiera de varias utilidades comunes como tcpdump y Wireshark.
Estos defectos han causado el abandono y despreciación del protocolo telnet rápidamente, a
favor de un protocolo más seguro y más funcional llamado SSH, lanzado en
1995. SSH provee de toda la funcionalidad presente en telnet, la adición
del cifrado fuerte para evitar que los datos sensibles tales como contraseñas sean
interceptados, y de la autentificación mediante llave pública, para asegurarse de que
el computador remoto es realmente quién dice ser.
Los expertos en seguridad computacional, tal como el instituto de SANS, y los miembros
del newsgroup de comp.os.linux.security recomiendan que el uso del telnet para las
conexiones remotas debería ser descontinuado bajo cualquier circunstancia normal.
Cuando el telnet fue desarrollado inicialmente en 1969, la mayoría de los usuarios de
computadoras en red estaban en los servicios informáticos de instituciones académicas, o en
grandes instalaciones de investigación privadas y del gobierno. En este ambiente, la seguridad
no era una preocupación y solo se convirtió en una preocupación después de la explosión del
ancho de banda de los años 90. Con la subida exponencial del número de gente con el
acceso al Internet, y por la extensión, el número de gente que procura crackear los servidores
de otra gente, telnet podría no ser recomendado para ser utilizado en redes con conectividad
a Internet.
Secure Shell
SSH (o Secure SHell) es el nombre de un protocolo y del programa que lo implementa cuya
principal función es el acceso remoto a un servidor por medio de un canal seguro en el que
toda la información está cifrada. Además de la conexión a otros dispositivos, SSH permite
copiar datos de forma segura (tanto archivos sueltos como simular sesiones FTP cifradas),
gestionar claves RSA para no escribir contraseñas al conectar a los dispositivos y pasar los
datos de cualquier otra aplicación por un canal seguro tunelizadomediante SSH y también
puede redirigir el tráfico del (Sistema de Ventanas X) para poder ejecutar programas gráficos
remotamente. El protocolo TCP asignado es el 22.

Seguridad[editar]
SSH trabaja de forma similar a como se hace con telnet. La diferencia principal es que SSH
usa técnicas de cifrado que hacen que la información que viaja por el medio de comunicación
vaya de manera no legible, evitando que terceras personas puedan descubrir el usuario y
contraseña de la conexión ni lo que se escribe durante toda la sesión; aunque es posible
atacar este tipo de sistemas por medio de ataques de REPLAY y manipular así la información
entre destinos.

Historia[editar]
Al principio sólo existían los r-commands, que eran los basados en el programa rlogin, el cual
funciona de una forma similar a telnet.
La primera versión del protocolo y el programa eran libres y los creó un finlandés llamado Tatu
Ylönen, pero su licencia fue cambiando y terminó apareciendo la compañía SSH
Communications Security, que lo ofrecía gratuitamente para uso doméstico y académico, pero
exigía el pago a otras empresas. En el año 1997 (dos años después de que se creara la
primera versión) se propuso como borrador en la IETF.
A principios de 1999 se empezó a escribir una versión que se convertiría en la implementación
libre por excelencia, la de OpenBSD, llamada OpenSSH.

Versiones[editar]
Existen 2 versiones de SSH, la versión 1 de SSH hace uso de muchos algoritmos de cifrado
patentados (sin embargo, algunas de estas patentes han expirado) y es vulnerable a un
agujero de seguridad que potencialmente permite a un intruso insertar datos en la corriente de
comunicación. La suite OpenSSH bajo Red Hat Enterprise Linux utiliza por defecto la versión 2
de SSH, la cual tiene un algoritmo de intercambio de claves mejorado que no es vulnerable al
agujero de seguridad en la versión 1. Sin embargo, la suite OpenSSH también soporta las
conexiones de la versión 1.
Mecanismos de transición IPv6
Ir a la navegaciónIr a la búsqueda
Los mecanismos de transición a IPv6 son las tecnologías que facilitan y facilitarán la
transición de Internet de su infraestructura IPv4 al sistema de direccionamiento de nueva
generación IPv6. Concretamente, hay métodos que permitirán a hosts conectados únicamente
a IPv4 ó IPv6 acceder a recursos sólo disponibles utilizando el otro protocolo.
La Internet Engineering Task Force (IETF) gestiona a los grupos de trabajo y discusiones
hacia los Internet Drafts y procesos Request for Comments para desarrollar estos métodos.
Algunos mecanismos básicos de transición a IPv6 están ya definidos en la RFC 4213.

Stateless IP/ICMP Translation (SIIT)[editar]

La traducción IP/ICMP sin estado (asíncrona) traduce entre los formatos de
cabecera IPv6 y IPv4. El método SIIT define un rango de direcciones IPv6 llamado direcciones
IPv4-traducidas (IPv4-translated). Es el prefijo (subred) ::ffff:0:0:0/96 y se puede escribir
como ::ffff:0:a.b.c.d, donde la dirección en formato IPv4 a.b.c.d se refiere a un nodo
"IPv6-disponible" (IPv6-enabled). Se ha elegido el prefijo para que diera un checksum de 0,
evitando cambios en el checksum de la cabecera del protocolo de transporte.1
El algoritmo permite que hosts IPv6 sin dirección IPv4 asignada se comuniquen con host sólo-
IPv4. La asignación de direcciones y los detalles del encaminamiento no se abordan en la
especificación.
La especificación es un producto de un grupo de trabajo IETF NGTRANS, y se redactó
inicialmente en febrero de 2000 por E. Nordmark de Sun Microsystems. La especificación
estándar del protocolo está en la RFC 6145.2

6rd.[editar]
6rd es un mecanismo para facilitar un rápido despliegue de IPv6 a través de
infraestructuras IPv4 de los Proveedores de Servicios de Internet (PSI, o las siglas ISP en
inglés). Utiliza traducciones asíncronas entre direcciones IPv4 e IPv6, y transmite
paquetes IPv6 dentro de túneles IPv4 automáticos que siguen las mismas rutas optimizadas
entre nodos como cualquier otro paquete IPv4.
Ha sido utilizado para el primer gran despliegue de un servicio IPv6 con direcciones nativas a
finales de 2007 (RFC 55693). La especificación estándar del protocolo está en la RFC 5969.4

Transport Relay Translation (TRT)[editar]

La RFC 3142 define el método Traducción en capa de Transporte (Transport Relay
Translation o TRT), reservando para él el rango unicast C6::/64 . Es el método más común
de NAT-PT/NAPT-PT; se basa en la translación entre los registros DNS AAAA y A conocida
como DNS-ALG, definida en la RFC 2694.

NAT64[editar]
Artículo principal: NAT64

NAT64 es un mecanismo que permite a hosts IPv6 comunicarse con servidores IPv4. El
servidor NAT64 dispone de al menos una dirección IPv4 y un segmento de red IPv6 de 32-bits
(por ejemplo 64:ff9b::/96 , véase RFC 6052, RFC 6146). El cliente IPv6 construye la
dirección IPv6 destino utilizando el rango anterior de 96 bits más los 32 bits de la dirección
IPv4 con la que desea comunicarse, enviando los paquetes a la dirección resultante. El
servidor NAT64 crea entonces un mapeo de NAT entre la dirección IPv6 y la dirección IPv4,
permitiendo la comunicación.5

DNS64[editar]
Cuando un Servidor DNS con funcionalidad DNS64 recibe una petición de dominio por registro
AAAA, pero sólo dispone de registros A, crea registros AAAA a partir de los registros A. La
primera porción de la dirección IPv6 creada apunta a un traductor IPv6/IPv4, y la segunda
incluye la dirección IPv4 del registro A. El traductor en cuestión suele ser un servidor NAT64.6
Hay dos puntos importantes a tener en cuenta con el mecanismo de transición:

 Sólo funciona cuando se utiliza DNS para encontrar la dirección del host remoto. Si se
utilizan direcciones IPv4 directamente, el servidor DNS64 no podrá estar involucrado.
 Dado que el servidor DNS64 responde con registros no especificados por el propietario
del dominio, la validación DNSSEC contra el propietario fallará, salvo que el servidor
DNS64 que hace la traducción sea asimismo propietario del dominio.

Proyectos[editar]
Los mecanismos mostrados a continuación están actualmente en discusión o han sido
abandonados por la IETF.
Dual-Stack Lite (DS-Lite)[editar]

DS-Lite

Debido al agotamiento de las direcciones IPv4,7 se diseñó Dual-Stack Lite para permitir a
un proveedor de servicios de Internet (ISP) omitir la asignación de una dirección
IPv4 al equipo local de cliente (CPE). En su lugar, asignan únicamente direcciones IPv6
globales. (Un entorno Dual Stack normal requiere la asignación de direcciones públicas IPv4 e
IPv6).
El CPE distribuye direcciones IPv4 privadas en la LAN del cliente, de igual modo que un
dispositivo NAT. La subred es elegida aleatoriamente por el cliente, tal como en el modelo
NAT. La diferencia estriba en que en lugar de realizar un NAT, el CPE encapsula el paquete
IPv4 dentro de un paquete IPv6. El CPE utiliza su conexión IPv6 para enviar el paquete a
un Carrier Grade NAT (CGN) del ISP, que sí dispone de una dirección IPv4 pública. Se
desencapsula el paquete IPv6, restaurando el paquete IPv4 original; se le aplica NAT al
paquete IPv4 y se encamina a la Internet IPv4. El CGN identifica flujos de tráfico únicamente
registrando la dirección IPv6 pública del CPE, la dirección IPv4 privada y los puertos TCP o
UDP.8
Address plus Port (A+P)[editar]
Dirección más Puerto [A+P] utiliza un NAT en la red del cliente (o cerca de él) para acceder a
la Internet IPv4. El proveedor de Internet proporciona una dirección IPv4 (como se hace hasta
ahora) y un rango de puertos TCP/UDP para el NAT. El tráfico IPv4 de salida es traducido
(nateado) utilizando el rango de puertos TCP/UDP disponible, y el proveedor de servicios
encaminará los paquetes de vuelta al cliente adecuado utilizando tanto la dirección IPv4
destino como el puerto TCP/UDP de destino. 9 10
4rd[editar]
4rd es un mecanismo que permite el despliegue residual de servicios IPv4 sobre redes IPv6. A
igual que el 6rd, utiliza mapeos de direcciones asíncronos entre IPv6 e IPv4. Soporta una
extensión de la dirección IPv4 basada en puertos de la capa de transporte. Es similar a A+P,
pero cada cliente puede tener hasta 4 rangos de puertos, con los puertos derivados
algorítmicamente del prefijo IPv6 del cliente.

Túnel (informática)
Ir a la navegaciónIr a la búsqueda
Se conoce como túnel o tunneling a la técnica que consiste en encapsular un protocolo de
red sobre otro (protocolo de red encapsulador) creando un túnel de información dentro de
una red de computadoras. El uso de esta técnica persigue diferentes objetivos, dependiendo
del problema que se esté tratando, como por ejemplo la comunicación de islas en
escenarios multicast, la redirección de tráfico, etc. La técnica de tunelizar se suele utilizar
para transportar un protocolo determinado a través de una red que, en condiciones normales,
no lo aceptaría. Otro uso de la tunelización de protocolos es la creación de diversos tipos
de redes privadas virtuales.
El establecimiento de dicho túnel se implementa incluyendo una PDU (unidad de datos de
protocolo) determinada dentro de otra PDU con el objetivo de transmitirla desde un extremo al
otro del túnel sin que sea necesaria una interpretación intermedia de la PDU encapsulada. De
esta manera se encaminan los paquetes de datos sobre nodos intermedios que son incapaces
de ver en claro el contenido de dichos paquetes. El túnel queda definido por los puntos
extremos y el protocolo de comunicación empleado, que entre otros, podría ser SSH. Así, el
protocolo A es encapsulado dentro del protocolo B, de forma que el primero considera al
segundo como si estuviera en el nivel de enlace de datos.
Uno de los ejemplos más claros de utilización de esta técnica consiste en la redirección de
tráfico en escenarios IP Móvil. En escenarios de IP móvil, cuando un nodo-móvil no se
encuentra en su red base, necesita que su home-agent realice ciertas funciones en su puesto,
entre las que se encuentra la de capturar el tráfico dirigido al nodo-móvil y redirigirlo hacia él.
Esa redirección del tráfico se realiza usando un mecanismo de tunneling, ya que es necesario
que los paquetes conserven su estructura y contenido originales (dirección IPde origen y
destino, puertos, etc.) cuando sean recibidos por el nodo-móvil.

Ejemplos de protocolos tunelizados[editar]

Protocolos orientados a datagramas:

 L2TP (Layer 2 Tunneling Protocol)

 MPLS (Multiprotocol Label Switching)
 GRE (Generic Routing Encapsulation)
 PPTP (Point-to-Point Tunneling Protocol)
 PPPoE (point-to-point protocol over Ethernet)
 PPPoA (point-to-point protocol over ATM)
 IPSec (Internet Protocol security)
 IEEE 802.1Q (Ethernet VLANs)
 DLSw (SNA over IP)
 XOT (X.25 datagrams over TCP)
 6to4 (IPv6 over IPv4 as protocol 41)
 Teredo
Protocolos orientados a flujo:

 TLS (Transport Layer Security)

 SSH (Secure Shell)
Túnel SSH[editar]
El protocolo SSH (secure shell) se utiliza con frecuencia para tunelizar tráfico confidencial
sobre Internet de una manera segura. Por ejemplo, un servidor de ficheros puede compartir
archivos usando el protocolo SMB (Server Message Block), cuyos datos no viajan cifrados y
que una tercera parte que tuviera acceso a la conexión (algo posible si las comunicaciones se
realizan en Internet) pudiera examinar a conciencia el contenido de cada fichero trasmitido.
Para poder montar el sistema de archivo de forma segura, se establece una conexión
mediante un túnel SSH que encamina todo el tráfico SMB al servidor de archivos dentro de
una conexión cifrada SSH. Aunque el protocolo SMB sigue siendo inseguro, al viajar dentro de
una conexión cifrada se impide el acceso al mismo.
Por ejemplo, para conectar con un servidor web de forma segura, utilizando SSH, haríamos
que el cliente web, en vez de conectarse al servidor directamente, se conecte a un cliente
SSH. El cliente SSH se conectaría con el servidor tunelizado, el cual a su vez se conectaría
con el servidor web final. Lo atractivo de este sistema es que hemos añadido una capa de
cifrado sin necesidad de alterar ni el cliente ni el servidor web.