/home/blaster [ Blaster's blog ]

Archive for the ‘seguridad’ Category

Consiste en mandar paquetes ICMP de “echo request” (como los de un ping) con una falsa dirección de origen (la IP de la víctima) a una dirección de difusión (”broadcast”). De esta forma alcanzarán muchas máquinas, cada una de las cuales enviará sus paquetes de respuesta a la dirección origen de la petición (cuyos datos estaban falseados y apuntaban a la víctima). El resultado es que la máquina víctima se ve inundada de paquetes IP, resultando en una saturación de su enlace (algo así como si le hubieran hecho un ping a lo grande).

Desgraciadamente la víctima no puede hacer nada para evitarlo. La solución está en manos de los administradores de red, los cuales deben configurar adecuadamente sus routers para filtrar los paquetes ICMP de petición indeseados (broadcast) o bien configurar sus máquinas para que no respondan a dichos paquetes. Es decir, que lo que se parchea son las máquinas/redes que puedan actuar de intermediarias (inocentes) en el ataque y no la máquina víctima.

De igual forma también se podría evitar el ataque si el router/firewall de salida del atacante (p.ej. el ISP al que pertenece) estuviera convenientemente configurado para evitar spoofing. Esto se haría filtrando todos los paquetes de salida que tuvieran una dirección source (origen) que no perteneciera a la red interna (desde la cual salimos).

Para más información sobre “smurf” os remito a:

http://www.quadrunner.com/~c-huegen/smurf.txt

Con esta técnica conseguimos spoofear nuestro hostname, es decir, que un servidor nos asocie el nombre de host que queramos (y no el que tiene realmente, que es único) (en realidad, puede haber más de uno, pero sólo uno es el real, lo que se conoce como “canonical name” mientras que los demás son simples “aliases”).

La explicación detallada es compleja y excede los objetivos de este documento. A título informativo paso a esbozar o perfilar lo que sería el Inject.

Cada servidor (ya sea de IRC, ftp, étc) tiene asociado uno o más “servidores de nombres” (NS, del inglés: Name Server) que resuelven todas las peticiones de conexión que le llegan: para cada IP que peticiona conexión buscan y almacenan el hostname correspondiente para su posterior uso. El proceso sería el siguiente:

- un usuario de la máquina A intenta conectarse a un puerto de la máquina B (el servidor IRC, ftp, …).
- B recibe la dirección IP desde la que peticionamos (la de A) y se la entrega a C (otro host: el NS) para que la resuelva.
- C resuelve y devuelve su respuesta a B.
- B se “cree” la respuesta y la cachea en memoria.

Ahora tiene un par IP-hostname. A partir de este momento nosotros estamos identificados en el servidor con el hostname dado anteriormente por el NS.

Como se puede intuir el truco está en forzar al NS a que de una respuesta falsa (siempre en favor nuestro :-)). Digamos que modificamos los datos del NS para que responda a nuestra IP con el hostname que nosotros queremos y no con el que debería hacerlo realmente. Se dice que hemos “inyectado” (injectado, en inglés :-P) el NS.

El cómo hacer esto último es lo complicado y sólo voy a decir que el truco se basa en la “resolución recursiva” de los NS (cuando un NS no sabe la respuesta a la petición que le ha llegado lanza una nueva petición a otro NS, que posiblemente sí sepa la respuesta, y así sucesivamente –> de ahí la “recursividad”) y en tener finalmente un NS trucado que de respuestas falsas y que nosotros reprogramamos a nuestro gusto.

La principal ventaja es una vez más el anonimato (aparte de poder ir vacilando por el IRC con una identidad del tipo root@nasa.gov :-O).

Se describe como un servidor DNS que hace uso de información falsa recibida desde un host que no es autoridad para la información. Es una amenaza significativa para la seguridad de las organizaciones que no han tomado medidas para protegerse de ella. El DNS Spoofing puede permitir a los atacantes acceder al correo de un sitio, y puede hacer que los usuarios sean redirigidos a sitios Web incorrectos incluso proporcionando una abertura para un ataque de Negación de Servicio.

Ejemplos de modus operandi:
Escenario: La compañía, TAMJTeK Inc., está compitiendo para acabar el desarrollo del último software de juegos antes de que el capital de la empresa salga. Se comienza a anunciar el aviso pendiente de una brecha en tecnología de este juego en el sitio Web de Internet. Usted tiene una llamada de uno de los socios de la empresa. Ella desea saber por que termina llegando a http://www.hackncrack.net cuando intenta llegar a http://www.tamjtek.com. Usted intenta conectarse al sitio Web y, seguro, termina llegando a http://www.hackncrac.net. Usted prueba algunos otros sitios y todo parece muy bien excepto, que encuentra que su competidor más fuerte ha anunciado una brecha en el mismo juego. Su sitio Web demuestra una imagen de su juego, la cual parece notablemente similar a la suya con aspectos virtualmente idénticos. ¿Coincidencia? Quizás no.

En este año una aplicación desarrollada descubre que un número substancial de compañías en línea son vulnerables a DNS Spoofing. Esta vulnerabilidad hace que el escenario de TAMJTeK Inc. sea posible. Un ejemplo muy conocido de DNS Spoofing ocurrió en 1997 cuando Eugene Kashpureff redirigió a los que intentaban conectarse al registrar de dominios InterNIC y los llevaba a su propio sitio Web AlterNIC. EL señor Kashpureff utilizó el método de agregar un registro de datos falso en la respuesta de la consulta. Más recientemente, el DNS Spoofing y el secuestro de dominios fueron logrados usando solamente correo electrónico y un fax.

Ejemplo 1: Asume los siguientes dos dominios, hackncrack.net y tamjtek.com con las siguientes configuraciones:

Hackncrack.net (10.0.0.0) Tamjtek.com (11.0.0.0)
Ns1.hackncrack.net (10.0.0.5) ns1.tamjtek.com (11.0.0.5)
http://www.hackncrack.net(10.0.0.6) http://www.tamjtek.com(11.0.0.6)

El atacante ha modificado el servidor de nombres Hackncrack para responder a una consulta recursiva para los registros DNS Hackncrack con un falso registro autoritario, mapeando http://www.tamjtek.com a la dirección IP 10.0.0.6. El atacante entonces dirige una consulta al servidor de nombres TAMJTeK preguntando por los registros DNS sobre el sitio del atacante. El servidor de nombres TAMJTeK resuelve la consulta yendo al servidor de nombres Hackncrack. Desde que el servidor de nombres TAMJTeK no esta protegido contra DNS Spoofing, acepta y almacena el registro falso que incluye la respuesta. Siempre que una consulta se haga al sitio Web de TAMJTeK, el registro para el sitio Web Hacncrack será regresado y todo será redireccionado a http://www.hacckncrack.net. El atacante en Hackncrack puede también engañar un registro MX para dirigir el correo de TAMJTeK a su servidor de correo. Un registro falso MX puede desapercibir una cantidad de tiempo significativa si el atacante esta bien informado.

Ejemplo 2: Prediciendo el número de consulta ID, un atacante puede realizar otra adaptación de DNS Spoofing personificando un servidor de nombres. El protocolo DNS usa el protocolo UDP para comunicarse. Dada la naturaleza sin conexión de UDP, DNS es diseñado para establecer comunicaciones ordenadas entre equipos. Esto es logrado identificando datagramas con un número de consulta ID. El host que inicia la consulta asigna este número. En las versiones anteriores de BIND, este se incrementaba secuencialmente para cada nueva consulta. Con este ejemplo, podra observar como el atacante engaña a los usuarios de TAMJTeK.com haciendo parecer que ellos van a http://www.AnyBank.com cuando, en realidad, se están conectando a http://www.Hackncrack.net. El atacante en Hackncrack.net consulta TAMJTeK.com para la información que los atacantes poseen del dominio. El servidor de nombres TAMJTeK resuelve las consultas referidas a Hackncrack.net El servidor de nombres del atacante regresa la información correcta sobre sí mismo a TAMJTeK.com y el servidor de nombres de la víctima lo reenvía al host del atacante que inició la consulta. Para montar este ataque, el intruso tiene que, primero, aprender cual es el número ID de la consulta. Escuchando los datos durante la consulta se puede obtener éste. Una vez que el número ID sea disponible, el atacante hace un datagrama de la respuesta del DNS con información falsa: http://www.AnyBank.com = 10.0.0.6 y lo configura como si la fuente fuera ns.AnyBank.com. El atacante inicia una consulta para TAMJTaK.com preguntando por información sobre AnyBank.com e inserta el datagrama modificado en la línea como la respuesta. De nuevo, el servidor de nombres inseguro TAMJTeK.com acepta y almacena los datos. Cuando los usuarios de TAMJTeK intentan conectarse a http://www.AnyBank.com, ellos son redirigidos a una página Web específica en el servidor Web Hackncrack que contiene exactamente la información de la página de la cuenta AnyBank.com. En este punto, el atacante puede recolectar cuentas de usuarios y números de PIN a voluntad.

Ejemplo 3: Este ejemplo no describe un ataque DNS Spoofing en el sentido técnico más estricto del término pero, los resultados al final son los mismos y se puede decir que este estilo de ataque tiene el potencial para “envenenar” la caché de cada servidor de nombres en el Internet. Network Solutions Inc. fue el primero y sigue siendo uno de los primeros en registrar nombres de dominio. Durante el proceso de registro, NSI ofrece tres métodos de autorización y autenticación para proteger los registros contra actualizaciones no autorizadas. Estos métodos son colectivamente referidos por NSI como “Guardian”. El contacto personal que esta listado en el registro de nombre de dominio, también es conocido como un Guardian. Estos métodos son:

1. Mail-Form (Mínima Seguridad): El contacto somete una dirección de correo electrónico de la cual toda la administración de registro origine. Cuando un cambio de registro se somete a la NSI vía correo electrónico, la dirección de correo electrónico fuente es comprada con la dirección de correo sometida durante el inicio del dominio original.
2. Cryp-Password (Un poco de Seguridad): Durante la disposición inicial, el contacto escoge una contraseña. Esta contraseña es cifrada y almacenada en la base de datos del NSI. Cuando el administrador somete un cambio de registro, la versión en texto plano de la contraseña es incluida. NSI cifra el texto plano de la contraseña que acompaña la petición de cambio y la compara con la original.
3. PGP (Más Seguridad): NSI soporta mensajes cifrados con PGP si se originaron desde una plataforma Unix. Ninguna otra plataforma es soportada en este momento.

Los nombres conocidos como Nike, Net Media, Web Networks, Exodus y el Consorcio World Wide Web han sido afectados por la trampa del proceso de autentificación de la actualización de registros DNS. Durante un incidente, las pertenencias de Internet.com y otros 1300 dominios fueron transferidos lejos de Net Media cuando NSI recibió un fax que consistía en documentos falsos. Llevó varios días para que el dueño legal de los documentos retomara el control de los mismos. Imagine el estrago de algunos que justo al inicio de leer el correo electrónico corporativo, fueron redirigidos durante la confusión. Obviamente, cuanto más seguro el proceso de autentificación, más seguros los registros del dominio.

Una posible solución sería eliminar las relaciones de confianza basadas en la dirección IP o el nombre de las máquinas, sustituyéndolas por relaciones basadas en claves criptográficas; el cifrado y el filtrado de las conexiones que pueden aceptar nuestras máquinas también son unas medidas de seguridad importantes de cara a evitar el spoofing.

Fuentes:
http://www.ibiblio.org/pub/linux/docs/LuCaS/Manuales-LuCAS/doc-unixsec/unixsec-html/node274.html
http://www.seguridad.unam.mx/labsec/tuto/?id=135&ap=articulo&cabecera=2

¿Por qué no debe usar el FTP normal un administrador?

La mayoría de la gente usa el FTP, que es inseguro para cargar y descargar archivos usando un programa FTP desde su casa. El problema es que su nombre de USUARIO y su CONTRASEÑA son enviados como texto puro por FTP, de modo que un hacker podría robar esta información con cierta facilidad y así tener acceso a su servidor.

¿Qué es el SFTP o FTP seguro?

Elimina la necesitad de usar FTP, usando SSH para conectarse a su servidor para cargar y descargar archivos. Conéctese usando SSH2 (como lo haría en todo caso con su programa SSH) y su conexión será segura.

¿Qué ventajas tiene el SFTP?

a) Su nombre de usuario y contraseñas circularán con seguridad.

1. Descargue e instale un cliente SFTP en su computadora doméstica.

El de mi preferencia es Filezilla

http://sourceforge.net/project/showfiles.php?group_id=21558

NOTA: Filezilla trabaja en parte con PUTTY, de modo que Ud. tendrá que instalar también PUTTY en su máquina.

2. Configure su cliente SFTP.

Si Ud. está usando Filezilla:

a. Abra el programa.
b. Pulse sobre Edit.
c. Pulse sobre Settings.
d. Abra el árbol de conexiones..
e. Pulse sobre SFTP settings.
f. Ponga “Use Compression” para ser usado por defecto.
g. Opte por usar SSH2 (es más seguro).
h. Pulse sobre OK.
i. Pulse sobre File.
j. Pulse sobre File Manager.
k. Pulse sobre New Site.
l. Entre la dirección IP de su SSH en Host.
m. En “ServerType” ponga SSH2, que funcionará por defecto con el puerto 22.
n. Cambie el número de puerto si ya tiene configurado algún otro para SSH.
o. En “LogonType” ponga Normal.
p. Entre con su nombre de USUARIO y CONTRASEÑA DE SSH.
q. Pulse sobre Save y Exit.

Y ya está. Ahora trate de conectarse con su servidor vía SSH2 usando su cliente SFTP, pulsando sobre el icono de conexión que está en la barra de tareas (en el extremo izquierdo). Debe funcionar. Si no funciona verifique nuevamente el IP de su SSH, Número de Puerto, Usuario y Contraseña.
Recuerde que se trata de los mismos datos que Ud. usa en su cliente SSH, como Putty, por ejemplo.

Al terminar, Ud. estará en condiciones de entrar mediante Filezilla (u otro cliente SFTP) y disfrutar de un acceso FTP seguro a su servidor, mediante conexión SSH. Su servidor ya no tendrá una puerta FTP activa y el servidor FTP
estará deshabilitado, lo que le ahorrará también algunos recursos.

Una sesion de correo con telnet

Podemos leer nuestro correo en una sesion de telnet. ¿Utilidad? piensa por ejemplo en la posibilidad de ver una lista de todos los mensajes nuevos en el servidor, antes de descargarlos, o borrarlos alli sin necesidad de bajarlos, o incluso consultar el correo desde cualquier ordenador, sin necesidad de configurar el programa de mail.

Para ello iniciaremos una sesion telnet, pero no por el puerto habitual, sino por el específico POP3 (110) que es donde escucha el server de correo. Toma nota de que esto sirve para los e-mails ordinarios, pero no para el correo-web (hot-mail y similares). Para mas detalles puedes estudiar aqui la especificación POP3.

Una vez conseguida la conexión con el servidor de correo, este nos indica que esta listo para recibir comandos, por ejemplo:

+OK POP3 server ready

Iniciamos la sesion introduciendo nuestro nombre de usuario y password:

USER nombre_usuario
PASS password

Y obtendras contestación del servidor acerca de si has sido o no autenticado.
Ten en cuenta que el servidor puede dar respuesta positiva aunque metas un nombre de usuario inexistente. Solo cuando recibas respuesta positiva a ambos, nombre y contraseña, podrás operar con el servidor.

Recuerda que en la especificación POP3 los comandos son una sola palabra (de tres o cuatro letras maximo), que puede ir seguida o no de argumentos. El comando y su argumento iran separados por un solo espacio.

Cada comando introducido obtendrá una respuesta del servidor, que será positiva o negativa. La respuesta puede ir o no seguida de una explicación

+OK comando introducido correctamente
-ERR comando erróneo

Cuando el servidor emite a nuestro comando una respuesta con varias lineas, la ultima linea consistirá en un punto (”.”). Y en el caso de que alguna de las lineas de la respuesta a su vez comenzase con un punto, se añade un punto adicional para distinguirla de la ultima linea.

comandos utiles:

STAT (status) solicita el estado de tu buzón de correos. El servidor responderá informando de cuantos mensajes hay a la espera, en el siguiente formato: +OK mm bb, donde mm es el numero de mensajes, y bb el numero de bytes del total.

LIST te lista todos los mensajes (identificador más el tamaño). Puedes ejecutarlo solo (ofrecera el numero total de mensajes) o con un argumento (numero de mensaje) y solo obtendras como respuesta el tamaño de ese mensaje:

LIST
+OK 2 messages (320 octets)
1 120
2 200
.

LIST 2
+OK 2 200

LIST 3
-ERR no such message, only 2 messages in maildrop

TOP nn nl para ver las cabeceras y primeras lineas del mensaje (nn sería el numero del mensaje que quieras ver, nl el numero de lineas de la cabecera, p ej: TOP 1 ALL)

RETR # para ver un mensaje, debe especificarse su numero en la lista

DELE # borra el mensaje elegido. El borrado no es al enviar el comando, sino al terminar la sesión

RSET recupera los mensajes marcados para borrado

NOOP (No Operation) instruye al servidor para que no ejecute ninguna acción, salvo responder con un mensaje de confirmación (+OK).

UIDL (Unique Identifier List) sirve para asignar un identificador unico a todos los mensajes o a uno especifico.

APOP (Authenticate Post Office Protocol) Este comando puede ser usado como sustituto del binomio USER - PASS para identificar y validar un usuario. Su utilidad es evitar que el password del usuario viaje por la red de forma no encriptada. La sintaxis es: APOP (nombre) (codigo).

QUIT cierra la conexión. Si se cierra la sesión sin este comando, los mensajes marcados para borrado no se destruiran.

Una sesion típica: en negrita, el tecto tecleado por nosotros.

+OK mx0.redestb.es POP3 server (Post.Office v2.0 0813
with ZPOP version 1.0) ready Sun, 22 Oct 2000 20:23:15 +0100

user minombre
+OK Password required for minombre

pass micontraseña
+OK Maildrop has 0 messages (0 octets)

quit
+OK mx0.redestb.es POP3 server closing connection

y ahora una con mensaje : ))

conectamos:

+OK Hello there.

user minombre
+OK Password required.

pass micontraseña
+OK logged in.

stat
+OK 1 1756

top 1 5
+OK headers follow.
Return-Path: <*****@******.es>
Received: from tsmtp3.ldap.isp (unknown [195.235.113.141])
by pomerol.nexen.net (Postfix) with ESMTP id 5AFBD82DC
for <****@nexen.net>; Mon, 23 Oct 2000 21:18:31
+0200 (CEST)
Received: from ******** ([***.**.***.**]) by
tsmtp3.ldap.isp (Netscape Messaging Server 4.1)
with SMTP id G2WDI902.M4D for <******@nexen.net>;
Mon, 23 Oct 2000 21:15:45 +0200
Message-ID:
<000c01c03d26$14f49a00$3e6760d5@teleline>
From: "irv" <*****@******.es>
To: <******@nexen.net>
Subject: probando. Esto es el "asunto" del mensaje
Date: Mon, 23 Oct 2000 21:18:52 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0009_01C03D36.D807EBE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

This is a multi-part message in MIME format.

.

Bueno, hemos conectado, solicitado status y recibido cabecera. Ahora a recuperar el mensaje, y borrarlo del servidor (y hacer QUIT para el borrado efectivo):

retr 1
+OK 1756 octets follow.
Return-Path: <******@*******.es>
Received: from tsmtp3.ldap.isp (unknown [195.235.113.141])
by ******.*****.net (Postfix) with ESMTP id 5AFBD82DC
for <*****@****.net>; Mon, 23 Oct 2000 21:18:31
+0200 (CEST)
Received: from teleline ([***.**.***.***])
by tsmtp3.ldap.isp
(Netscape Messaging Server 4.1) with SMTP id G2WDI902.M4D
for <****@****.net>; Mon, 23 Oct 2000 21:15:45
+0200
Message-ID: <000c01c03d26$14f49a00$3e6760d5@teleline>
From: "*****" <****@*****.es>
To: <*****@****.net>
Subject: probando. Esto es el "asunto" del mensaje
Date: Mon, 23 Oct 2000 21:18:52 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0009_01C03D36.D807EBE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.
4133.2400

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C03D36.D807EBE0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Prueba de mensaje recuperado con telnet.
Esto es el CUERPO del mensaje

------=_NextPart_000_0009_01C03D36.D807EBE0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
Prueba de mensaje recuperado con = telnet. Esto es el=20
CUERPO del mensaje</FONT></DIV></BODY></HTML>

------=_NextPart_000_0009_01C03D36.D807EBE0--

.

dele 1
+OK Deleted.

quit
+OK Bye-bye.

irc por telnet

Si, por que no?. Las conversaciones no serán tan fáciles de seguir, pero es perfectamente posible:

$ telnet irc.lleida.net 6667
Trying 194.149.73.7...
Connected to irc.lleida.net.
Escape character is '^]'.
:jupiter2.irc-hispano.org NOTICE IP_LOOKUP :*** Found your hostname (CACHED!).
user pepe localhost localhost :soy pepe
nick io22
PING :1199599470
pong :1199599470
:jupiter2.irc-hispano.org 001 io22 :Welcome to the IRC-Hispano Internet Relay Network io22
:jupiter2.irc-hispano.org 002 io22 :Your host is jupiter2.irc-hispano.org, running version u2.10.H.09.25
:jupiter2.irc-hispano.org 003 io22 :This server was created dl oct 10 2005 at 16:11:59 CEST
:jupiter2.irc-hispano.org 004 io22 jupiter2.irc-hispano.org u2.10.H.09.25 dioswkgxXrRhSB biklmnopstvrRM
:jupiter2.irc-hispano.org 005 io22 CHANMODES=b,k,l,imnpstrRM CHANTYPES=#&+ KICKLEN=160 MAXBANS=75 :are supported by this server
:jupiter2.irc-hispano.org 005 io22 MAXCHANNELS=25 CHANNELLEN=64 MAXTARGETS=20 MODES=6 NICKLEN=15 :are supported by this server
:jupiter2.irc-hispano.org 005 io22 PREFIX=(ov)@+ SILENCE=15 TOPICLEN=240 WALLCHOPS WHOX :are supported by this server
:jupiter2.irc-hispano.org 005 io22 USERIP CPRIVMSG CNOTICE CHARMAPPING=rfc1459 NETWORK=IRC-Hispano :are supported by this server
:jupiter2.irc-hispano.org 005 io22 MAP SAFELIST QUITLEN=250 AWAYLEN=160 XMODE FNC GHOST WATCH=96 :are supported by this server
:jupiter2.irc-hispano.org 251 io22 :There are 10869 users and 3173 invisible on 25 servers
:jupiter2.irc-hispano.org 252 io22 36 :Helper(s), 12 IRCop(s) and 8 official bot(s) online
:jupiter2.irc-hispano.org 253 io22 2 :unknown connection(s)
:jupiter2.irc-hispano.org 254 io22 10703 :channels formed
:jupiter2.irc-hispano.org 255 io22 :I have 1037 clients and 1 servers
:jupiter2.irc-hispano.org 265 io22 :Current local users: 1037 Max: 1842 (29 de Marzo de 2006 -- 22:07 +02:00, since 20051128-17:46)
:jupiter2.irc-hispano.org 266 io22 :Current global users: 14042 Max: 16253 (16 de Enero de 2006 -- 22:47 +01:00, since 20051128-17:46)
:jupiter2.irc-hispano.org 422 io22 :MOTD File is missing
:jupiter2.irc-hispano.org NOTICE io22 :on 1 ca 1(2) ft 10(10)
:io22 MODE io22 :+x

Si quieres probarlo, algunos consejos: tras conectar con el server, necesitas hacer login; para eso teclea user tunombre hostname servername :nombre_real y pulsa ENTER. En la línea siguiente (el server no habrá dado todavía ninguna respuesta) teclea nick tunick

Y ya estarás dentro. Los comandos son los mismos que los que puedas usar con cualquier programa de chat, pero sin necesidad de la barra /. Cada vez que quieras hablar (coun un canal, con otro nick) debes escribir el comando PRIVMSG

Un par de detalles mas: al escribir cualquier cosa que tenga mas de dos palabras, precede la frase con dos puntos: PRIVMSG #ayuda_irc :Hola al canal. Y lo mas divertido de todo: no olvides contestar a los PING del servidor con un PONG (con el mismo número recibido) o se cortará la conexión.