El Blog de Loretahur
Todo cuerpo sentado en el wáter hará sonar el timbre de la puerta (Ley de nicagar puedeuno)
Mostrando entradas de la categoría Seguridad
OpenID, una auntenticación para gobernarlos a todos
Publicado por loretahur a las 17:159 Ene
Últimamente están saliendo a la palestra muchos casos de robos de cuentas gracias a la ingeniería social, es decir, el engaño de toda la vida. Ni las plataformas más potentes se libran, porque, como se suele repetir en el mundo de la seguridad, ésta es tan fuerte como el más débil de sus eslabones: el usuario. Así que si alguien os vende un día la moto de la seguridad total, desconfiad de inmediato. Eso no es posible.
Una tecnología que lleva un tiempo interesándome para la autenticación es OpenID. A continuación veremos sus puntos fuertes y sus puntos débiles.
¿Qué es OpenID?
Según la wikipedia es un sistema de identificación digital descentralizado, con el que un usuario puede identificarse en una página web a través de una URL o un XRI. Es decir, una forma de autenticarse en las páginas web sin necesidad de tener un usuario por cada una de esas plataformas. Algo así como mandar a todas las webs a un lugar central a pedir nuestras credenciales. Ese servidor central se denomina proveedor de identidad o IdP. ¿Os imagináis no tener que exprimiros más los sesos cada vez que tenéis que iniciar sesión en esa página de la que no recordáis ni el nombre de usuario ni la contraseña? Se acabó también usar la misma contraseña para todo (con el peligro que eso entraña). Basta con meter nuestra url de identificación para que se ponga en contacto con nuestro IdP. Incluso podremos decidir qué datos compartimos con esa página en concreto.
Para los que crean webs, también puede ser de gran ayuda porque ya no tienen que encargarse de la gestión de usuarios.
Pero cuidado, que no todo el campo es orégano. Esto también hace que tengamos un único pie de apoyo. Si logran hacerse con nuestra contraseña en el IdP, habremos comprometido toda nuestra identidad digital. Y hacer phising de esta cuenta puede llegar a ser realmente fácil. Por ejemplo, puedo crear una página “tarro de miel” (es decir, para atraer a los incautos) que necesite logueo con OpenID. Cuando lo haga el usuario, le redirigiré a una página falsa para que meta sus credenciales. Y es que el problema es que soy yo quien hace la redirección al IdP.
Además, estamos dando un inmenso poder a ese servidor central (que sabrá incluso por donde navegamos). La ventaja es que nosotros mismos podemos tener nuestro propio servidor y así no depender del manido cloud computing (es la ventaja que tienen los estándares web abiertos).
Más son los problemas que aún aquejan a este sistema, así que mi recomendación es que no se haga uso de él para cosas muy importantes 
¿Cómo hacemos que nuestro blog haga de IdP?
No es que haga de IdP tal como lo he explicado anteriormente, sino que sirve de intermediario (algo así como lo hace Feedburner con nuestros rss). Dado que es más difícil que cambiemos la dirección de nuestra página personal que la plataforma que nos da las credenciales, me parece la mejor solución.
Para que esto funcione, copiamos las siguientes líneas dentro de las etiquetas <head> (en este ejemplo se hace uso de el IdP openid.blogs.es, pero tendrás que buscar las líneas correspondientes al tuyo):
<link rel=”openid.server” href=”http://openid.blogs.es/index.php/serve” />
<link rel=”openid.delegate” href=”http://openid.blogs.es/NOMBREDEUSUARIO” />
Si en un momento dado cambiamos de IdP (o éste cierra la persiana), sólo tendremos que modificarlo en la cabecera de nuestro blog y no se irán al garete nuestras credenciales en otras plataformas. De esta forma independizamos la dirección que nos representa en línea del servicio IdP.
¿Cómo hacemos para que nuestros lectores puedan dejar comentarios con su cuenta OpenID?
Gracias a OpenID se podría acabar con las suplantaciones en los comentarios, puesto que es una forma clara de decir: ésta soy yo. Existen varios plugins para WordPress que permiten que los comentaristas se identifiquen mediante OpenID: OpenID Comments, OpenID for WordPress, WordPress Delegate Plugin, … Y como el camino se aprende andando y es mejor predicar con el ejemplo, yo he instalado OpenID, que permite que cualquiera deje un comentario sin necesidad de rellenar su nombre y dirección de correo. Además también se puede acceder al back-end de wordpress con esta identidad. Por cierto, si tenéis instalado WP Contact Form III, tendréis que hacer unos arreglitos para que convivan ambos.
Incluso a plataformas como Mediawiki se les puede instalar una extensión para que se use la autenticación vía OpenID.
Lugares donde puedes crearte una cuenta OpenID:
Si tienes tu blog alojado en blogger, LiveJournal, WordPress.com, …. , tu propia url ya te sirve de identificador.
¿Qué grandes plataformas permiten el uso de OpenID?
Technorati, Blogger, Zoomr, Bloguzz, Live Journal, Wikispaces, … y muchos más. Incluso hay sites en los que es la única manera de loguearse, como por ejemplo, Twitterfeed o blogs donde sólo se puede comentar así, como el de David de Ugarte.
Otros enlaces de interés:
Backscatter, un ataque de correo
Publicado por loretahur a las 18:3313 Dic
¿Suena fea la palabreja, verdad? Pues si suena fea, peor será. Y es que se trata de un ataque que sufrimos hace unos días en nuestro servidor de correo de Nireblog y contra el que poco se puede hacer. Recibe otros nombres como outscatter, misdirected bounces, blowback o collateral spam. Incluso Juanjo lo bautizó en su día como tormenta de bounces.
¿En qué consiste este spam lateral? Pues simple y llanamente, los señores spammers se dedican a mandar esos mensajes molestos a diestro y siniestro poniendo como emisoras direcciones aleatorias de tu dominio. Es decir, mandan mensajes a direcciones que generan aleatoriamente de hotmail (por poner un ejemplo), diciendo que son pepitoeldelospalotes@nireblog.com (esta dirección también la generan aleatoriamente).
¿Esto se puede hacer? Vaya que si se puede y además de una forma sencilla (SMTP no es que sea un protocolo pensado para la seguridad…). No quiere decir que manden el spam a través de nuestros servidores, sino que simplemente falsean el from.
¿Y qué es lo que sucede entonces? Pues que mandan mensajes a direcciones que ni siquiera existen. Por tanto, el servidor que recibe el mensaje manda un bounce (notificación de que no se ha podido entregar, los famosos undeliverable mail) hacia el emisor del mensaje. Pero como ese emisor se ha falseado y se ha puesto uno de nuestro dominio, nos llega a nosotros como una auténtica tormenta. Si tenemos configurado nuestro servidor de correo para que lea de base de datos las cuentas existentes, podrá afectar a su rendimiento porque estamos hablando de cientos de mensajes por segundo a los que hay que comprobar su destinatario.
¿Y cómo lo descubres? Porque te están llegando un montón de mensajes que no tienen mail from (la mayoría de rebotes llega así). Por cierto, es importante tener un sistema de monitorización del servicio de correo para enterarte rápido de lo que te está sucediendo. Nosotros usamos para ello mailgraph, que es muy sencillo de instalar y configurar.
¿Y qué se puede hacer? Pues como he dicho al inicio, poco o nada. Como mucho cambiar el mensaje de unknown_local_recipient_reject_code de un 450 a un 550. El 450 implica un inténtalo de nuevo más tarde, por lo que el bombardeo durará más puesto que no le decimos desde un inicio que no existe esa dirección en nuestro servidor (lo que sí se consigue con un 550 que es un reject en toda regla).
Pero lo que sí se podría hacer para evitar ser uno de los “cómplices” de los bombardeos de spam lateral es hacer una serie de comprobaciones a los correos antes de rechazarlos con su respectivo bounce. Porque si se trata de mensajes de spam o que contienen virus, lo mejor será descartarlos y no generar más ruido en la Red.
Y es que el mundo del correo electrónico es la jungla
Qué hacer ante un robot agresivo
Publicado por loretahur a las 23:1025 Jul
Hace unos días vimos que la carga del servidor de Nireblog subía espectacularmente en un horario en el que no suele tener mucha. Tras comprobar que había más de 700 tareas entre apache y mysql, hice un netstat y constaté que la mayoría de las conexiones venían de una sola dirección ip. Se trataba de un bot agresivo de Attributor que estaba haciendo peticiones a diestro y siniestro (del orden de unas 10 por segundo). Tras denegar la ip mediante iptables, recuperamos la carga. Pero eso sólo fue una solución temporal, dado que usan más direcciones y ayer nos volvió a tocar con otra diferente. Así que os voy a contar una serie de soluciones que podemos aplicar ante estos robots chupa-conexiones.
- Fichero robots.txt: cuando un robot visita una página, lo primero que solicita es http://www.lapagina.com/robots.txt. En ese documento se le indica si tiene permitido el acceso o no. Esto, claro está, si es un bot bien programado o con buenas intenciones (por ejemplo, las arañas que se usan para extraer direcciones de correo a las que enviar spam no siguen el protocolo ). Por tanto, esta solución puede que no nos valga de mucho. Para decirle que no pase, pondríamos lo siguiente:
User-agent: attributor.com
Disallow: /Para más información sobre el funcionamiento de este fichero, pasaros por robotstxt.org. Además también tenéis un completo listado de User Agents con las ip’s que suelen usar.
- Fichero .htaccess: si el bot deja su nombre en el campo user-agent, podremos denegar su acceso en este fichero de la siguiente forma:
RewriteCond %{HTTP_USER_AGENT} ^.*attributor.*$
RewriteRule ^.* – [F,L]Con esto le estamos diciendo a nuestro apache que, a todas las peticiones que le lleguen en las que el campo User Agent tenga la palabra attributor, les devuelva el código 403 : Forbidden.
Expliquemos más a fondo la expresión regular que se usa:- ^ indica que es el comenzamiento de la URL
- .* cualquier cadena alfanumérica
- $ indica que es el final de la URL
Como vemos, esto nos librará de conexiones a base de datos, porque no se sirve nada, pero no de las conexiones a nuestro servidor web. Aunque si queremos pagar al bot con su misma moneda, podemos modificar la acción de la regla y en vez de hacer que se deniegue el acceso, se puede redirigir a la página del bot en cuestión (en nuestro caso a www.attributor.com).
Recordad que para usar .htaccess tenemos que tener habilitado el modulo mod_rewrite de apache.Para comprobar si nos está funcionando correctamente este método, podemos hacer una petición simulada desde aquí, donde podemos introducir el User Agent a mano y hacer una petición a nuestra web.
- Iptables: si ni siquiera queremos que trabaje nuestro servidor web, podemos rechazar las peticiones con nuestro firewall. Aunque para eso deberemos conocer las direcciones ip que usa el bot. Si las sabemos, podemos agregar la siguiente regla:
iptables -A INPUT -s 64.41.145.240 -j LOG –log-prefix “[BLOQ]=>”
iptables -A INPUT -s 64.41.145.240 -j DROPLa primera línea hace que se registre el bloqueo en el log de iptables (en el caso de debian es /var/log/syslog ) y la segunda hace que todos los paquetes que lleguen de esa dirección sean descartados. Si no sabemos todas las direcciones que usan los bots, también podemos aplicar la siguiente solución que nos presentó Ricardo Galli: usar el módulo recent de iptables para que descarte las conexiones si un cliente ha intentado hacer más de 30 en 10 segundos
Martin Hellman en la Universidad de Deusto
Publicado por loretahur a las 22:4815 Nov
Hoy me he quedado patidifusa al enterarme de que Martin E. Hellman va a estar en la Universidad de Deusto el 4 de diciembre.
¿Y quién es Hellman? Pues uno de los padres del protocolo Diffie-Hellman. Si eres un apasionado de la criptografía, seguro que has oído hablar de él. Allí estaremos para deleitarnos con lo que nos cuente.
Día: 4 de Diciembre de 2007
Hora: 13:00
Lugar: Sala de Videoconferencias – ESIDE
Technorati tags: Martin Hellman, Diffie-Hellman
Atacando el archivo de claves
Publicado por loretahur a las 21:1611 Sep
He vuelto de vacaciones un poco vaga pero, como lo prometido es deuda, aquí sigo con mi serie de posts sobre John The Ripper. ¡Empecemos a jugar ya!
Primeramente, tenemos que observar si en el archivo /etc/passwd, en la posición de la contraseña, aparece alguna de las formas siguientes:
- El hash de la clave: la distribución no cuenta con shadowing, por lo tanto se puede atacar el fichero tal cual está.
- x ó *: serán necesarios los archivos passwd y shadow. John cuenta con una herramienta para combinarlos y obtener un tercer archivo que pueda ser usado:
unshadow passwd shadow > nuevo-passwd
Donde nuevo-passwd será el archivo al que se redireccione el resultado de la unión.
Un ejemplo del proceso que realiza esta herramienta es el siguiente:
passwd: root:x:0:0:root:/root:/bin/bash
shadow: root:fqjGKoSmasmFk:12712:0:99999:7:::
nuevo-passwd: root:fqjGKoSmasmFk:0:0:root:/root:/bin/bash
Una vez que ya se cuenta con el archivo definitivo sobre el que aplicar John, es necesario definir el modo de ejecución de éste para obtener las claves. Antes de pasar a comentar esto, comprobaremos las opciones con las que cuenta. Para verlas, sólo es necesario lanzar la aplicación sin pasarle ningún parámetro:
Modos de ejecución:
1. Single Crack
john −single FICHERO_PASSWORD
john –si FICHERO_PASSWORD
Este es el modo con el que se debería comenzar a trabajar. Con él se intentará usar la información del login/GECOS como passwords, ya que en muchas ocasiones los usuarios utilizan como contraseña el mismo login, o el nombre, o el apellido, etc,… por ejemplo:
rhantos:RKxhLEYIi7b9o:150:2000:Roberto Hantos:/home/rhantos:/bin/csh
Donde el password es roberto. En modo single esta contraseña sale en mucho menos de un segundo mientras que en modo incremental llevaría mucho tiempo:
Como en modo single crack la información que se usa es sólo la de la cuenta en que se ha tomado (y sólo con passwords con los mismos ‘salts’, lo que no consume tiempo extra), es mucho más rápido que el modo con diccionarios, y permite el uso de muchas reglas (éstas están siempre activadas en este modo) en un tiempo razonable.
2. Diccionarios o listas de palabras
john −wordfile:DICCIONARIO FICHERO_PASSWORD
john −w:DICCIONARIO FICHERO_PASSWORD
Este es el modo más simple soportado por John. Todo lo que se necesita hacer es especificar un wordlist (un archivo con una palabra por línea). Para descargaros diccionarios, podéis hacerlo desde esta página (tenéis hasta diccionarios de Tolkien ). El wordlist no debe contener vacíos.
John no ordena las palabras, ya que necesitaría cargar toda la lista en la memoria. Lee directamente del disco mientras está en funcionamiento. Además, no ordenar las palabras, permite poner las más frecuentes al principio de la lista para que sean probadas antes (words first). Sin embargo, si no se tiene ninguna preferencia en el orden, es mejor ordenarlas alfabéticamente. John funciona un poco más rápido si cada palabra difiere solo en algunos caracteres, esto es especialmente aplicable si sólo se ataca a unos pocos passwords de una vez.
Adicionalmente, no se debería tener palabras de más de 8 caracteres (o cualquiera que sea el limite del actual formato de cifrado), ya que los passwords serán considerados iguales si las 8 primeras letras lo son. John puede manejar estas situaciones (y solo probará el password una vez) cuando dichas palabras estén una a continuación de la otra (esto es, cuando la lista esté ordenada). Es preferible no truncar la lista en 8 caracteres, ya que el resto pueden ser necesitados si se activan las reglas.
Aún faltan más modos por explicar, pero lo dejaremos para otro post.
En anteriores capítulos de la saga:
¿Cómo de seguras son tus claves?
¿Cómo de seguras son tus claves? (segundo asalto)
Instalando John The Ripper
Instalando John The Ripper
Publicado por loretahur a las 21:5225 Jul
Recordemos que John es software libre, así que si visitamos su página, podremos descargarnos tanto su ejecutable como su código (ya tenemos disponible la versión estable 1.7.0.2).
La instalación es tan simple que no requiere instalación Sólo tendremos que bajarnos el ejecutable y empezar a funcionar. Eso sí, en windows, si tenéis algún antivirus instalado, os dirá que es una herramienta del mal y puede que incluso os la borre del tirón.
En sistemas linux sabor Debian podemos también instalarlo con un simple:
apt-get install john
Sin embargo, si sois de los linuxeros de bytes en el pecho, podéis compilarlo a mano. Para ello nos descargamos las fuentes de aquí:
John the Ripper 1.7.0.2 (Unix – tar.gz, 784 KB) y su firma.
Descomprimimos con la siguiente instrucción:
tar -xzvf john-1.7.0.2.tar.gz
Entramos en la carpeta john-1.7.0.2/src y ejecutamos el comando: make clean generic. Si todo ha ido bien, se nos habrá creado un ejecutable denominado john en la carpeta john-1.7.0.2/run. Para probarlo, lanzamos:
./john –test
¿A que esta parte ha sido fácil? Pues mañana mismo empezaré a explicar el funcionamiento.
En anteriores capítulos de la saga:
¿Cómo de seguras son tus claves?
¿Cómo de seguras son tus claves? (segundo asalto)
¿Cómo de seguras son tus claves? (segundo asalto)
Publicado por loretahur a las 21:4424 Jul
Seguimos destripando a John The Ripper (y nunca mejor dicho). En esta ocasión explicaré un poco la estructura y evolución de los archivos de claves de Unix/Linux, porque será con los que trabajemos más adelante.
Originalmente, en estos sistemas, el hash de las contraseñas residía en el archivo /etc/passwd. Pero éste debe tener necesariamente permisos de lectura para todos los usuarios (si no, no serán capaces de iniciar sesión), lo que suponía un problema de seguridad, ya que aunque las claves estuvieran cifradas, cualquiera podía ejecutar programas como John.
Cada línea del fichero /etc/passwd corresponde a un usuario y está dividida en 7 partes separadas por el símbolo “:” con la siguiente información:
usuario:contraseña:ID_Usuario:ID_Grupo:nombre:directorio:shell
Ejemplo:
loretahur:Ejrt3EJUnh5Ms:1000:1000:Lorena Fdez:/home/loretahur:/bin/bash
La primera parte corresponde al nombre de usuario y la segunda, a la clave cifrada. El resto, es sólo información sobre el usuario, su directorio de trabajo,… que no tiene importancia para John puesto que no lo necesita. De hecho, se podría dejar de la siguiente forma (lo importante es la estructura, de forma que john pueda reconocerlo como una clave unix):
loretahur:Ejrt3EJUnh5Ms:a:a:a:a:a
Posteriormente, para mejorar la seguridad, se incluyó un nuevo sistema: el shadowing o sistema de claves fantasmas. Éste consiste en ocultar las contraseñas del archivo /etc/passwd (dejando el campo de la contraseña o bien con “x” o con “*”). Ejemplo:
loretahur:x:1000:1000:Lorena Fdez:/home/loretahur:/bin/bash
Ahora, los hashes de las claves se encuentran en el archivo /etc/shadow, al que sólo tiene acceso el usuario root. Por tanto, ahora para obtener las claves son necesarios los ficheros passwd y shadow. Para hacer nuestras pruebas de calidad de claves, copiaremos estos dos ficheros (y reitero lo de copiar, que luego os cargáis cualquiera de ellos y la liáis parda).
Otra cuestión curiosa de los sistemas Unix es que cifran las contraseñas utilizando como llave de cifrado a la propia contraseña. Con esto se consigue que no pueda invertirse el proceso. Por lo tanto, para poder obtener la clave, John hace lo siguiente: utiliza las palabras de los diccionarios y variaciones de éstas como llaves del DES, comparando el resultado obtenido con la clave cifrada. Si coinciden, ha dado con la clave buscada.
En anteriores capítulos de la saga:
¿Cómo de seguras son tus claves?
Publicado por loretahur a las 20:3612 Jul
Tantas y tantas aplicaciones inundan hoy en día nuestro ordenador, que nos toca memorizar una gran cantidad de contraseñas. Como consecuencia terminamos poniendo siempre la misma. De hecho, conozco a mucha gente ¡que usa su clave de cajero! Así que el robo de nuestras passwords puede ser catastrófico.
Por eso voy a hacer una serie de posts explicando el funcionamiento de John The Ripper, un programa que nos servirá para evaluar lo fuerte o débil que es nuestra contraseña. Porque la mejor defensa es un buen ataque
¿Qué es John the Ripper?
John the Ripper es una aplicación de código abierto que se utiliza para la recuperación de claves, o dicho de otra forma y dependiendo de quién lo use, un crackeador de contraseñas (de ahí lo de destripador). Con ella podremos comprobar la calidad de las claves de los usuarios, intentando encontrar las que sean débiles (y por tanto inseguras) y así previniendo que un presunto atacante que obtenga el fichero de claves, pueda hacer lo mismo.
Es multiplataforma (lo tenemos tanto para Unix, como para Windows, MS-DOS, BeOS y OpenVMS). Gracias a esta característica, se permite su uso incluso continuando una sesión que se comenzó en otro sistema.
Está diseñado para ser a la vez potente y rápido (aunque su rendimiento depende mucho de la máquina en la que se ejecute). Combina bastantes modos de recuperación de claves en un solo programa y es completamente configurable para distintas necesidades (incluso se puede definir un modo propio usando el compilador interno, que soporta un sublenguaje de C).
Hay tres formas de aplicar John:
- Single Crack: Este modo intentará usar la información de login/GECOS para obtener la password. Es decir, si al crear nuestro usuario hemos introducido nuestro nombre y apellidos, tratará de combinar esos datos para obtener la contraseña.
- Utilizando diccionarios de claves o archivos de palabras. Con esta posibilidad se permite añadir reglas para que el programa “juegue” con las palabras del diccionario. Esta opción es muy potente. De hecho, estoy convencida que con un diccionario del Señor de los Anillos sería capaz de conseguir el 50% de claves de los usuarios de la Red
- Modo incremental o también conocido como fuerza bruta: como su propio nombre indica, probará todas las combinaciones de caracteres posibles. También será el modo que más recursos y tiempo consuma.
En próximos posts contaré cómo instalarlo y usar sus múltiples modos.
Y vosotros, ¿sois de los que usáis la misma contraseña para todo?
Instalación y bastionamiento de un servidor de correo bajo GNU/Linux
Publicado por loretahur a las 17:1114 Feb
Aprovechando el trasteo que me permite el nuevo servidor de NireBlog, me he decidido a poner en un mini-howto la instalación de un servidor de correo bajo Debian Sarge y usando exclusivamente software libre.
Se ha elegido Postfix como MTA. A Postfix se le han agregado los siguientes mecanismos de seguridad: TLS (Transport Layer Security) para cifrar las conexiones y SASL (Simple Authentication and Security Layer) como sistema de autentificación.
Todo el correo que pase a través del servidor SMTP será revisado en busca de virus y SPAM. Para llevar a cabo esta tarea se utilizará AMaViSd-new como interfaz entre el servidor de correo SMTP y las aplicaciones ClamAV y Spamassassin, las cuales analizarán el correo en busca de virus y SPAM respectivamente.
Para la consulta de mensajes por parte de los usuarios se dispondrá de un servidor POP3 e IMAP, con sus respectivas versiones seguras con protocolo SSL, para lo cual se hará uso de Courier (courier-pop y courier-pop-ssl, courier-imap y courier-imap-ssl).
Los usuarios del correo no serán usuarios físicos de la máquina sino que serán usuarios virtuales almacenados en una Base de Datos MySQL.
Para crear una autoridad certificadora y generar certificados propios se ha dispuesto de OpenSSL 0.9.7e.
Aquí os dejo el documento. Cualquier metedura de pata que encontréis (algo bastante probable dada mi facilidad para decir burradas), os agradecería que me la notificaseis (bien en un comentario a este post o vía correo), para corregirla.
Manual [pdf / 465 KB]
Más del 70% de los e-mails son SPAM
Publicado por loretahur a las 21:529 Ene
Leo en Enpresa Digitala que Hostalia ha realizado un estudio en el que se ha concluido que el 70% de los correos electrónicos que se mandan son de SPAM. Y es que ahora, si no revisamos nuestro correo en un par de días, nos encontramos con aluviones de mensajes no deseados. Hoy, sin ir más lejos, he recibido un mensaje de la mismísima Avril Lavigne. Lo raro es que me estaba intentando vender viagra…
¿Pero cuál es la razón de este bombardeo? Principalmente porque es barato. El coste de mandar un mensaje es cero (tan sólo se podría contabilizar el ancho de banda). Y si ya cuentas con pocos escrúpulos y consigues el servidor de correo de algún panoli que lo ha configurado mal y es un estupendo Open Relay (servidor de correo al que le da lo mismo ocho que ochocientos, es decir, que a través de mail.panoli.com puedes mandar un mensaje como si fueses spammer@listillo.com), pues más fácil me lo pones.
A esto hay que sumar que el correo electrónico sigue siendo el servicio por excelencia de Internet. Hace años muchos pronosticaron su muerte, sin embargo, por mucho que estemos inmersos en la Web 2.0, sigue siendo el método de comunicación más utilizado.
Otra cosa que es realmente fácil de obtener hoy en día en Internet son direcciones de correo. ¿Quién no tiene su dirección publicada? Y aunque no se tenga, los spammers intentarán hacer combinaciones de nombres a los que remitir sus mensajes (porque es casi seguro que encontrarás la dirección jose arroba hotmail punto com). Ya ni hablemos de los bonitos mensajes cadena que nos mandan nuestros amigos a nosotros y a trescientas personas más (por supuesto, sin copia oculta).
¿Cuáles son las soluciones? Ante el aluvión de SPAM, una empresa sin apenas ánimo de lucro (Micro$oft) propuso que se pagase por cada mensaje enviado 0.000001 € (como siempre, intentando cortar las cosas por el camino financiero). Sin embargo, la única solución que le veo yo al problema es atajar el SPAM en el servidor, mejorando los filtros que analizan los mensajes (SpamAssassin, Bogus, etc…). Y por supuesto, que dejemos de pinchar en esos mensajes de SPAM (porque si los siguen mandando está claro que es porque hay gente que pica).
Os dejo con el vídeo de los Monty Python que dio nombre al SPAM. Aún tengo en mi lista pendiente publicar ese manual de configuración de servidores de correo con Postfix.
Esto funciona gracias a WordPress | Theme: Design Disease | Política de privacidad | Contacto | 
Últimos Comentarios