Artículo publicado en el número 2/2004 de la revista “Hakin9”Todos los derechos protegidos. Distribución gratuita admitida bajo la condición de guardar la forma y el contenido actuales del artículo.

Revista „Hakin9”, Wydawnictwo Software, ul. Lewartowskiego 6, 00-190 Warszawa, piotr@software.com.plDOCUMENTO DESCARGADO DE WWW.HACKHISPANO.COM

¿Cómo se envíaun spam?Tomasz Nidecki

El envío masivo de correo electrónico

absorbe muchísimos recursos. Para lle- varlo acabo, es imprescindible una co-nexión rápida y un ordenador dedicado. Inclusosi el spammer dispone de tales recursos, el en-vío puede tardar varias horas. Los proveedoresde internet no se entusiasman, por lo general,si de repente sus conexiones son utilizadas pa-ra el envío de spam y el spammer puede perderconexión con la red antes de poder enviar lamayor parte de los mensajes. Si se le detienepuede sufrir graves consecuencias jurídicas

Con frecuencia los spammersse aprovechan de lasvulnerabilidades de lossistemas. Los costes y losproblemas relacionados con elenvío, a menudo, de decenaso de cientos de miles demensajes son trasladadosa terceros. Enterémonos en qué sebasan las técnicas empleadas porlos spammers y cómo protegernosde ellos.

bilidad por el envío de spams recae sobre ellos,dejando a los spammers impunes.Protocolo SMTPPara comprender los métodos utilizados porlos spammers es necesario saber cómo fun-ciona el protocolo más común para el envíodel correo electrónico: SMTP. Igual que lamayoría de los protocolos empleados enInternet, está basado en simples comandostextuales.

En nuestro artículo

y perfeccionar el envío emplean dos métodosbásicos. El primero está basado en la mini-mización del tiempo requerido para enviar elmensaje. Es conocido como fire and forget,es decir, ¨envía y olvida .̈ Con este métodoel ordenador que envía los spams no esperarespuesta de los servidores con los cuales secontacta. El segundo método se basa en el ro-bo de los recursos de personas ajenas que poralgún motivo han configurado mal sus sistemaso han sido víctimas de virus. La mayoría de loscostes y muchas veces, también la responsa-

aprenderás...

• de qué manera los spammers envían losspams (empleando ordenadores de personasinocentes),

• cómo proteger tu servidor ante spammers,• cómo funciona el protocolo SMTP,• qué es open relay, open proxy y zombie.

Qué deberías saber...

• cómo emplear las herramientas básicas delsistema Linux.

2 www.hakin9.org Hakin9 No 2/2004

Figura 1. Etapas del envío de correo electrónico

Historia del SMTPEl programa SNDMSG (Send Message) es el precursor del SMTP, empleado enel año 1971 por Ray Tomlinson (junto con su propio proyecto CYPNET) para lacreación de una aplicación que permitiera el envío del correo electrónico dentro dela red ARPANET. Un año más tarde, el programa utilizado en Arpanet para el envíode ficheros (FTP), fue ampliado con el comando MAIL y MLFL. Hasta el año 1980 elcorreo era enviado por medio de FTP. Fue en aquel año cuando nació el primer pro-tocolo estándar de correo electrónico, MTP (Mail Transfer Protocol), descrito en eldocumento RFC 772. MTP sufrió varias modificaciones (RFC 780, 788) y en el año1982, en el RFC 821, Jonathan B. Postel describió Simple Mail Transfer Protocol.

Desgraciadamente, el SMTP en su forma básica no cumplió todas esperan-zas. De ahí que surgieron muchos documentos que describían la extensión

delprotocolo. Entre los más importantes podemos destacar:

• RFC 1123 – exigencias para los servidores de Internet (también abarca SMTP),• RFC 1425 – introducción del estándar de las extensiones del protocolo SMTP

– ESMTP,• RFC 2505 – conjunto de sugerencias sobre protección antispam de los servido-

res,• RFC 2554 – autorización de las conexiones – introducción del comando AUTH,

El actual estándar SMTP fue descrito en el año 2001 en RFC 2821. La colección RFC

Etapas del envío del correoEl correo electrónico es enviadoen varias etapas (véase Figura 1).Para comprenderlo imaginémonosque queremos enviar un mensajede hakin9 @hakin9.org a nobody @example.com. El usuario que en-vía el mensaje utiliza el programaMozilla Thunderbird en una redlocal, el destinatario – OutlookExpress por medio de la conexióntelefónica tipo dial-up.

En la primera etapa, el programaMozilla Thunderbird contacta con elservidor SMTP señalado en lasopciones de la cuenta del usuariohakin9 @hakin9.org – mail.software.com.pl. El mensaje está enviadoal servidor a través del protoco-lo SMTP. En la segunda etapa,mail.software.com.pl mira en losregistros de los servidores DNS.Se entera de que el responsable

Hakin9 No 2/2004 www.hakin9.org 3

de la recepción del correo deldominio example.com es mail.example.com. Toda esta informa-ción se encuentra en el registroMX (Mail Exchanger) publicadopor la DNS responsable del dominoexample.com (podemos obtenerlapor medio de los programas hosto dig: host -t mx example.com o digexample.com.mx).

En la tercera etapa, mail.software.com.pl conecta con mail.example. com y le pasa el men-saje. En la siguiente etapa,mail.example.com entrega elmensaje recibido al buzón localde correo del usuario nobody. Enla última etapa, el usuario delbuzón nobody conecta por mediode la conexión dial-up con el ser-vidor mail.example.com a travésdel protocolo POP3 (o IMAP) conayuda del programa OutlookExpress y recoge el mensaje. Pue-de ocurrir que el mensaje recorraun camino más largo. El remitentepodría utilizar servidores de correoseparados, p. ej. recepcion.software.com.pl y envío.software.com.pl.De este modo el mensaje pasaríade losusuariosa travésderecepcion.software.com.pl, entregado a envío.software.com.pl y, a continuación,enviado a mail.example.com. Delmismo modo en el caso demail.example.com en la recepcióny entrega del correo al usuariopuedenestar implicados varios ser-vidores.

¿El sucesor de SMTP?Dan Bernstein, autor del qmail, desar-rolló el protocolo de nombre QMTP(Quick Mail Transfer Protocol), quedebería sustituir a SMTP. QMTPelimina muchos de los problemas quese presentan en SMTP, pero es inco-mpatible con su antecesor. Desgra-ciadamente, no se ha implementadoen ninguna parte, a parte del propioqmail.

Más información sobre QMTP:http://cr.yp.to/proto/qmtp.txt

Figura 2. Etapas de la comunicación por medio de SMTP

4 www.hakin9.org Hakin9 No 2/2004

Programas que toman parteen el envío del correoEn el envío del correo participan va-rios programas:

• El programa usado por el usuariofinal, que sirve no sólo para re-cibir y enviar, sino también paraleer y escribir emails, es conoci-do como MUA – Mail User Agent.Ejemplos: Mozilla Thunderbird,Outlook Express, PINE, Mutt;

• La parte del servidor responsa-ble de la comunicación con losusuarios (recepción del correo)y del envío y recepción del correode otros servidores es conocidacomo MTA – Mail Transfer Agent.Los más conocidos son: Send-mail, qmail, Postfix, Exim;

• La parte del servidor respon-sable de la entrega del correoal usuario local se llama MDA– Mail Delivery Agent. Ejemplosde MDA autónomos: Maildrop,Procmail. La mayoría de los MTAposeen mecanismos propios deentrega del correo local a losusuarios, por tanto no siemprees necesario emplear MDA adi-cionales.

Etapas de la comunicación enSMTPEl envío de un mensaje con laayuda del SMTP está dividido envarias etapas. He aquí un ejemplode una sesión SMTP entre los ser-vidores mail.software.com.pl y mail.example.com. Los datos enviadospor mail.software.com.pl están mar-cados con el símbolo > y los datosrecibidos de mail.example.com: <.Tras el establecimiento de la co-nexión, mail.example.com se pre-senta así:

< 220 mail.example.com ESMTP Program

informando que su nombrecompleto de host (FQDN) esmail.example.com. Asimismo, nosenteramos de que podemos utilizarlos comandos ESMTP (del SMTPextendido: véase el cuadro) y queel MTA utilizado es Program. Elnombre del programa es opcional,algunos MTA, por ej.: qmail, no loofrecen.

Nos presentamos así:

> HELO mail.software.com.pl

como respuesta obtenemos:

< 250 mail.example.com esto significaque mail.example.com está listopara recibir el correo. Acontinuación introducimos la di-rección de correo electrónico delremitente del email a la que podre-mos recibir eventuales mensajesdevueltos:

> MAIL FROM:<hakin9@hakin9.org>

< 250 ok

Introducimos las direcciones de losdestinatarios:

> RCPT TO:<test1@example.com>

< 250 ok

> RCPT TO:<test2@example.com>

< 250 ok

> RCPT TO:<test3@example.com>

< 250 ok

Luego, tras el comando DATA trans-ferimos las cabeceras y el con-tenido del mensaje. Separamoslas cabeceras del contenido conuna línea vacía y terminamos elmensaje con un punto en la siguien-te línea:

Tabla 1. Lista de los comandos del protocolo SMTP utilizados con másfrecuencia:

Comando DescripciónHELO <FQDN> Presentarse al servidorEHLO <FQDN> Presentarse al servidor conectado con la

petición de darnos un listado de loscomandos ESMTP disponibles

MAIL FROM:<dirección> Introducir la dirección de correoelectrónico del remitente del emaila la que podremos recibir eventualesmensajes devueltos

RCPT TO:<dirección> Introducir la dirección del destinatario delmensaje

DATA Pase al modo de recepción del contenidodel mensaje

AUTH <mecanismo> Autorización de la conexión (ESMTP); entrelos mecanismos más conocidos tenemos:LOGIN, PLAIN y CRAM-MD5

Podéis encontrar una lista extensa de comandos SMTP y ESMTP en lasiguiente dirección: http://fluffy.codeworks.gen.nz/esmtp.html

> DATA

< 354 go ahead

> From: nadie@hakin9.org

> To: todos@example.com

> Subject: Nada

>

> Esto es una prueba

> .

< 250 ok 1075929516 qp 5423

Después de enviar el mensaje, po-demos terminar la conexión:

> QUIT

< 221 Bye

El servidor no siempre es capazde llevar a cabo nuestras orde-nes. Si obtenemos un códigoque comience con la cifra 4 (códi-go de la serie 4xx) eso significaque el servidor temporalmenterechaza la recepción del mensaje.

Hakin9 No 2/2004 www.hakin9.org 5

Listado 1. El open relay mássencillo

$ telnet lenox.designs.pl 25< 220 ESMTP xenox> helo hakin9.org< 250 xenox> mail from:<hakin9@hakin9.org>< 250 Ok> rcpt to:<nobody@example.com>< 250 Ok> data< 354 End data withS <CR><LF>.<CR><LF>> Subject: test>> Esto es una prueba> .< 250 Ok: queued as 17C349B22> quit< 221 Bye

Deberíamos intentar enviarlo unpoco más tarde. Si obenemosun código que comience con lacifra 5 eso significa que el ser-vidor definitivamente rechaza larecepción de nuestro correo e inten-tos posteriores carecen de sen-tido. Un listado con los comandosmás importantes y los códigos obte-nidos del servidor SMTP se ilustraen las Tablas 1 y 2. Servidoresopen relay Cuando fuecreado el protocolo SMTP, noexistía el problema del

do: el proveedor de internet pue-de anular el contrato con motivodel uso del servidor para finesilegales o inmorales. Tercero: ladirección IP del ser vidor termina-rá en las listas negras y muchosser vidores dejarán de recibir susmensajes (la eliminación de la IPde muchas listas negras es muydifícil, incluso a veces imposible).

Empleo del open relayComprobemos lo fácil que es em-plear el open relay para el envío despam. Comoejemplo tomaremosunode los servidores polacos que estámal configurado, utilizado por losspammers: lenox.designs.pl. Comopodemos observar en el Listado 1,en este caso no tuvimos que reali-zar pasos complicados para enviarun mensaje. El servidor consideraa todos que conectan con él comousuarios autorizados para enviarcorrespondencia. Es el tipo delservidor open relay más peligroso,puesto que es el más fácil de apro-vecharse.

Existen otros open relay, unpoco más difíciles de utilizar porlos spammers. Como ejemplo po-demos tomar uno de los servidoresde correo que está mal configuradodel portal polaco O2: kogut.o2.pl.

Listado 2. Servidor openrelay que permiteel envío sólo a usuariosexistentes hakin9@hakin9.org

$ telnet kogut.o2.pl 25< 220 o2.pl ESMTP Wita> helo hakin9.org< 250 kogut.o2.pl> mail from:<ania@o2.pl>< 250 Ok> rcpt to:<< 250 Ok> data< 354 End data withS <CR><LF>.<CR><LF>> Subject: test>> Esto es una prueba> .< 250 Ok: queued as 31B1F2EEA0C> quit< 221 Bye

Como observamos en el Listado 2,bastó con adivinar el nombredel usuario para hacerse pasarpor él y enviar el mensaje. En elcaso de algunos servidores es su-ficiente dar el nombre del dominiolocal, incluso no tiene que existirel usuario por el que nos hacemospasar.

Observamos una situación si-milar en el Listado 3: otra vez nos

spam y cada usuario tenía la capa-cidad de utilizar cualquier servidorpara enviar sus mensajes al mundo.Ahora, cuando los spammers bus-can la oportunidad de aprovecharsede algún servidor y enviar miles demensajes, este método no es acon-sejable. Los servidores que permi-ten el envío de correo al mundo sinautorización son conocidos comoopen relay.

Cada servidor que permitea usuarios no autorizados el envíode correo, tarde o temprano cae enmanos de los spammers, lo quepuede acarrear consecuenciasmuy serias. Primero: porque puedeprovocar una reducción de eficaciadel ser vidor, el cual en vez de reci-bir y entregar mensajes a usuariosautorizados, enviará spam. Segun-

Tabla 2. Lista de los códigos de respuesta más importantes:

Código Descripción220 Servicio activo: el servidor nos da la bienvenida informando

que le podemos enviar el comando250 Comando aceptado354 Se puede empezar a introducir el contenido del mensaje450 El buzón del usuario está ocupado por el momento

(p. ej.: bloqueado por otro proceso)451 Error local durante el procesamiento del correo452 No hay espacio en el disco por el momento500 No existe el comando501 Error en el comando o en sus parámetros502 El comando no se implementó550 Buzón del usuario inaccesible552 Se ha excedido el límite de espacio en el disco

Podéis encontrar una lista completa de códigos y de normas de crearlos enRFC 2821 (en nuestro CD).

6 www.hakin9.org Hakin9 No 2/2004

¿Cómo no llegar a ser el open relay?El protocolo SMTP permite:

• recibir el correo del usuario (MUA) y enviarlo a otro servidor (MTA),• recibir el correo de otro servidor (MTA) y enviarlo al usuario local (MUA),• recibir el correo de un servidor (MTA) y enviarlo a otro servidor (MTA).

No hay ninguna diferencia en la manera de enviar los mensajes por medio de MUA yMTA. Lo más importante es si la dirección IP del destinatario es de confianza (por ej.:

enla red local) y si el remitente está en el dominio local o externo.

El envío del correo fuera de nuestro servidor se conoce como relaying. No pode-mos permitir el relaying sin autorización para que los spammers no puedan usar nues-tro servidor para llevar a cabo sus actividades. Por lo tanto, durante la configuracióndel servidor SMTP hay que tener en cuenta lo siguiente:

• Si el mensaje está destinado a uno de los dominios atendidos por nuestro servidortiene que ser recibido sin autorización.

• Si el mensaje es enviado por un usuario local (desde el MUA en el servidor) enla red local o desde una IP permanente autorizada y el remitente es usuarioexterno, el mensaje puede ser recibido sin autorización (sin embargo, se reco-mienda su autorización).

• Si el mensaje es enviado por un usuario externo (por ej.: de una IP dinámica) y eldestinatario es un usuario externo, el mensaje puede ser recibido sin autoriza-ción.

Listado 3. Servidor multistageopen relay que permite elenvío sólo a los usuariosexistentes

$ telnet smtp.poczta.onet.pl 25< 220 smtp.poczta.onet.pl ESMTP> helo hakin9.org< 250 smtp.poczta.onet.pl> mail from:<ania@buziaczek.pl>< 250 2.1.0 Sender syntax Ok> rcpt to:<hakin9@hakin9.org>< 250 2.1.5 Recipient addressS syntax Ok;S rcpt=<hakin9@hakin9.org>> data< 354 Start mail input;S end with <CRLF>.<CRLF>> Subject: test>> Esto es una prueba> .< 250 2.6.0 Message accepted.> quit< 221 2.0.0 smtp.poczta.onet.pl Out

encontramos con el servidor decorreo de uno de los portales pola-cos más grandes, esta vez Onet (locurioso es que Onet declara ser uncombatiente activo de los spams...).Es lo que se conoce como multista-ge open relay, es decir, el mensajees recibido por una IP y enviadopor otra.

Para enterarnos de esto te-nemos que analizar las cabece-ras Received (véase el cuadro)del mensaje recibido. Comoobservamos en el Listado 4, el men-saje fue recibido por ps8.test.onet.pl(213.180.130.54) y enviado al des-

Cabeceras Received

tinatario por smtp8.poczta.onet.pl(213.180.130.48). Esto dificulta ladetección de que el servidor fueconfigurado como open relay, pero nomolesta en absoluto utilizarlo para elenvío de spams.

Otro tipo de open relay son losservidores con mal configuradaautorización del remitente (SMTP-AUTH). Permiten el envío de cor-reo tras introducir cualquier loginy contraseña. Esto a menudo lessucede a los administradores prin-cipiantes del qmail que por algúnmotivo no leyeron la documen-tación del parche SMTP-AUTH

e invocaron de modo incorrecto elqmail-smtpd.

El programa qmail-smtpd conel parche incorporado requieretres argumentos: el FQDN, el pro-grama que verifica la contraseña(compatible con checkpassword)y el parámetro adicional del progra-ma que verifica la contraseña (porejemplo, qmail-smtpd hakin9.org

/bin/checkpassword /bin/true).Un error frecuente es poner /bin/

true como segundo parámetro,ya que entonces la verificación dela contraseña es siempre exitosa(independientemente del loginy contraseña introducidos). De lamisma manera, el spammer puedeintentar un ataque de diccionario

Las cabeceras Received son elementos obligatorios de cada mensaje. Determinanel camino desde el remitente hasta el destinatario (cuanto más arriba esté colocadala cabecera, más cerca estará del servidor del destinatario). Las cabeceras sonañadidas automáticamente por los servidores de correo. Sin embargo, el spammerpuede agregar sus propias cabeceras, tratando de borrar su identidad y echar laculpa a otra persona. Las únicas cabeceras siempre verdaderas son las que colocael servidor del destinatario (las de más arriba). Las demás pueden ser falsas.Gracias a las cabeceras Received podemos identificar la IP del remitente real delmensaje y también reconocer si el mensaje fue enviado por medio de open relay uopen proxy. No obstante, el análisis de las cabeceras no es una tarea fácil, ya que noexiste un método estándar para su formulación y cada servidor de correo muestrala información a su manera.

(ing. dictionary attack), por lo tantorecomendamos que las contrase-ñas de los usuarios utilizadas parala autorización del SMTP no seantriviales.

Servidores open proxyOtro tipo de servidores mal configu-rados que pueden ser empleadospor los spammers son los openproxy, o sea, los servidores proxya los que pueden conectar usuarios

Hakin9 No 2/2004 www.hakin9.org 7

Listado 4. Cabeceras Received del correo recibido del servidormultistage open relay

Received: from smtp8.poczta.onet.pl (213.180.130.48) by mail.hakin9.org with SMTP; 23 Feb 2004 18:48:11 -0000Received: from mail.hakin9.org ([127.0.0.1]:10248 "helo hakin9.org") by ps8.test.onet.pl with SMTP id <S1348420AbUBWSrW>; Mon, 23 Feb 2004 19:47:22 +0100

Listado 5. Servidor open relaycon configuración erróneaSMTP-AUTH

$ telnet mail.example.com 25< 220 mail.example.com ESMTP> ehlo hakin9.org< 250-mail.example.com< 250-PIPELINING< 250-8BITMIME

no autorizados. Los servidores openproxy pueden funcionar en basea una gama extensa de progra-mación y protocolos. El protocolomás frecuente es HTTP-CONNECT,pero hay algunos open proxy quepermiten la conexión a través de losprotocolos HTTP-POST, SOCKS4,SOCKS5 y otros.

Un open proxy puede ser usadopor el spammer de manera idénticaque open relay para enviar corres-pondencia no autorizada. Además,muchos open proxy permiten ocultarsu dirección IP. Un proxy de esta ín-dole es un bocado exquisito para losspammers.

Empleo del open proxyEn el Listado 6 está ilustrado el em-pleo de un open proxy que permiteconexión por medio de HTTP-CON-NECT en el puerto 80. La mayorparte de la conexión es la comuni-

cación con open relay (los mismoscomandos que en el Listado 2).Sin embargo, antes de conectarnoscon el servidor SMTP, establece-mos contacto con open proxy y consu ayuda nos conectamos con MTA.Durante la conexión declaramosque la comunicación se llevaráa cabo por medio del protocoloHTTP/1.0; sin embargo, no lo utili-zamos.

Para el spammer lo más confor-table es encontrar un ser vidor openrelay que al mismo tiempo tengainstalado un servidor de correolocal. En la mayoría de los casosel MTA sin autorización acepta lasconexiones del proxy local tratán-dolas del mismo modo que las delos usuarios locales. En estas si-tuaciones el spammer no tiene queconocer ningún ser vidor open relayy puede tranquilamente llevara cabo su actividad a costa y respo-

< 250-SIZE 10485760< 250 AUTH LOGIN PLAIN CRAM-MD5> auth login< 334 VXNlcm5hbWU6> cualquier cosa< 334 UGFzc3dvcmQ> cualquier cosa< 235 ok, go ahead (#2.0.0)> mail from:<hakin9@hakin9.org>< 250 ok> rcpt to:<nobody@nowhere.com>< 250 ok> data< 354 go ahead> Subject: test>> Esto es una prueba> .< 250 ok 1077563277 qp 13947> quit< 221 mail.example.com

Listado 6. Servidor openproxy empleado para elenvío anónimo decorrespondencia por openrelay

¿De dónde toman los spammers las direcciones open relayy open proxy?Buscar por cuenta propia servidores mal asegurados puede resultar bastante proble-mático. Sin embargo, basta con recibir un spam enviado por open relay u open proxypara poder utilizarlo. Para verificar si bajo la dirección IP sospechosa hay un openrelay, podemos usar el script rlytest (http://www.unicom.com/sw/rlytest/ ), en cambio,para detectar un open proxy: pxytest (http://www.unicom.com/sw/pxytest/ ). Ambos seencuentran en nuestro CD.

Los spammers que están interesados en per feccionar su actividad utili-zan, sobre todo, bases de direcciones comerciales open relay y open proxy.Es muy fácil encontrarlas, basta con escribir en cualquier buscador la palabraopen proxy u open relay y hacer click en los primeros vínculos (p. ej.: http://www.openproxies.com/ – 20 USD mensuales, http://www.openrelaycheck.com/– 199 USD semestrales).

Otro método para obtener direcciones es descargar la zona que contengadirecciones open relay u open proxy de uno de los servidores DNSBL (véaseel artículo Protección contra spams en el servidor). De la página web http://www.declude.com/junkmail/support/ip4r.htm podéis bajar un listado con todoslos servidores de este tipo. Para descargar la zona podemos emplear la aplicaciónhost: host -l <nombre de la zona> <dirección DNSBL>. Desgraciadamente,muchos servidores DNSBL no permiten bajar zonas completas.

$ telnet 204.170.42.31 80> CONNECT kogut.o2.pl:25 HTTP/1.0>< HTTP/1.0 200S Connection established< 220 o2.pl ESMTP Wita> helo hakin9.org< 250 kogut.o2.pl> mail from:<ania@o2.pl>< 250 Ok> rcpt to:<hakin9@hakin9.org>< 250 Ok> data< 354 End data withS

<CR><LF>.<CR><LF>> Subject: test>> Esto es una prueba> .< 250 Ok: queued as 5F4D41A3507> quit< 221 Bye

8 www.hakin9.org Hakin9 No 2/2004

nsabilidad de otra persona, di-ficultando en gran medida sudetección (la IP del spammerestará únicamente en los logs delservidor proxy y el destinatariode la correspondencia podrá re-cibirla solamente con ayuda deladministrador del proxy). Si elspammer está muy interesado enocultar su IP puede emplear variosopen proxy en cascada (conectan-do el primero con el segundo y asísucesivamente hasta llegar al ser-vidor de correo).

ZombieZombie es un método nuevoy a la vez el más invasor, empleadopor los spammers para traspasarlos costes y las responsabilidades

La historia de spam

a terceros. Esta técnica está basa-da en la unión de un virus (worm)con un troyano. El objetivo es crearun open proxy en el ordenador in-fectado por el virus. De esta mane-ra se crea una red enorme de openproxy anónimos, de los que se apro-vechan los spammers de todo elmundo.

El ejemplo más conocido dezombie son los virus de la serieSobig. He aquí como funciona elvariante Sobig.E:

• El primer elemento, después deinfectar el ordenador del usuario(al abrir el adjunto de un email),se envía a todas las direccionesencontradas en los archivos .txty .html del disco duro.

• Entre las 19:00 y las 23:00, horaUTC, se conecta con una de las22 direcciones IP que contieneel código del virus) en el puerto8998 UDP para obtener la direc-ción URL de la que podrá tomarel segundo elemento.

• Tras haber tomado el segundoelemento (el troyano) se instalay se ejecuta; la dirección IP delordenador infectado es enviadaal autor del zombie. A continua-ción, se toma el tercer elemento.

• El tercer elemento es el pro-grama Wingate modificado,que después de su instalaciónautomática pone en marcha elopen proxy en el ordenador delusuario.

Podéis encontrar más informaciónsobre los virus de la serie Sobig enla URL http://www.lurhg.com/sobig.

La palabra spam proviene del nombre de jamón con especias enlatado producidopor la empresa Hormel Foods – SPAM. Las siglas proceden de Shoulder Porkand hAM o SPiced hAM. ¿Cómo se empezó a asociar jamón con especias con elcorreo indeseado? Parcialmente la culpa por ello tienen los autores del show MontyPython’s Flying Circus. En uno de sus sketches se representa un restaurante cuyadueña recomienda SPAM, un componente de cada plato. A las mesas está sentadoun grupo de vikingos cantando spam, spam, spam, lovely spam, wonderful spam(spam, spam, spam, rico spam, maravilloso spam), con lo cual de vez en cuandoensordece a la dueña.

Es difícil determinar quién fue primero en usar la palabra spam para denomi-nar los abusos en la red. Puede ser que los pionieros eran los MUDs (de Multi-User Dungeon), los usuarios de juegos RPG de texto quienes solían aplicareste término a envíos que contentían demasiados datos en una entrega (hoydía es más frecuente llamarlo flooding). Es posible que la palabra spam se hayaempleado por primera vez en los chats Bitnet Relay, que eran los precursores deIRC.

Por el primer caso de spam en el correo se considera una carta enviada en1978 por Digital Equipment Corporation. Dicha empresa mandó un anuncio sobreel nuevo ordenador DEC-20 a todos los usuarios de Arpanet de la costa occidentalde los E.E.U.U. Sin embargo, la palabra spam no se adoptó antes de 1994, cuandoen Usenet apareció un anuncio del despacho de los abogados Lawrence Canteray Martha Siegiel. Informaban en él de su servicio de rellenar formularios de la lote-ría para visado americano. El anuncio fue enviado mediante un script a todos losgrupos de discusión de entonces.

Actualmente, con la noción spam se determina correo electrónico enviado apropósito, en grandes cantidades, a personas que no desean recibir tales men-sajes. Pueden (pero no tienen que) ser ofertas comerciales, propaganda política,etc. Desde hace poco se suele llamar ham (del ing.: jamón) el correo que no esspam.

Más sobre la historia de spam en:http://www.templetons.com/brad/spamterm.html,http://www.geocities.com/SiliconValley/Way/4302/spam.htmlSketch del spam (Monty Python’s Flying Circus – 1969): http://www.rompecadenas.com.ar/sketch.htm

html. El único método seguro contralos

zombies es el uso de programas an-tivirus y sistemas IDS (Intrusion De-tection System, por ejemplo, Snort)que nos ayudarán a detectar openproxy en nuestra red.

Mejor prevenir quecurarComo podemos ver, no es difícilaprovecharse de los servidores malconfigurados. Para el administradorde un servidor vulnerable las conse-cuencias pueden ser muy serias y elspammer saldrá probablemente im-pune. Por tanto, no hay que menos-preciar la problemática relacionadacon la seguridad de los servidoresante los spammers.

Así que antes de arrancar nues-tro propio servidor proxy, asegu-rémonos de que solamente losusuarios de la red local están auto-rizados a utilizarlo. Nuestro servidorde correo debe exigir autorización,a pesar de que los portales polacosmás grandes nos dan un mal ejem-plo en este campo. Probablementese vea afectada la comodidad denuestros usuarios, pero el objetivode este funcionamiento no tiene queconvencer a nadie.

Hakin9 No 2/2004 www.hakin9.org 9