Seguridad a traves de obscuridad: El peor consejo

Les quiero mostrar el siguiente correo de una compañia de hospedaje de la cual no quiero dar muchos detalles:

Hello,

The following security alert is for anyone who uses a form mail script
on their web site.  Form mail scripts are generally used to allow
browsers to submit an email from your website.  This may include feedback
forms or contact forms.  If you do not have any such feature on your
site, you may disregard this notice.

Recently we have seen a lot of exploit (hacker) activity on PHP and CGI 
form mail scripts.  The majority of exploited scripts are hand coded 
form mail scripts.  The exploits will use the form mail to automatically 
send spam from the account.  (An "exploit" is a term used for a piece 
of code written by a malicious person to abuse a customer’s account.  
This is not a server vulnerability but an issue specific to the coding 
found in particular scripts.) The result of this is that we will receive
spam warnings from AOL, Spamcop and other reporting agencies.  If we
receive too many complaints, our servers are at risk of being black
listed which will affect email on all servers.

It is very important to check your scripts to ensure they are secure.
At this time, the only form mail script we are recommending is the one 
found here:  http://nms-cgi.sourceforge.net/scripts.shtml.  If you are 
using a hand coded form mail script, it is highly recommended that you 
change to the NMS form mail script. 

Regardless of which form mail script you use, it is very important you 
name it something random.  Please DO NOT USE the following words when 
naming your form mail scripts:  form, mail, contact or feedback.  People 
exploiting these forms search for these commonly used words on search 
engines to more easily identify vulnerable scripts. 

We are currently scanning all servers to find scripts using those names 
as well as replying to all spam complaints.  If a script is found that 
was exploited or has the potential to be exploited, the script will be 
renamed.  This may cause your script to stop functioning so it is 
imperative you change your naming as soon as possible.

We apologize for the inconvenience but it is necessary to take swift
action in order to preserve the integrity of the servers so email is not
disrupted for anyone. 

A ver niños, levanten la mano quienes vieron un par de cosas raras en el correo anterior. Ajá, si Jaimito, vamos a ver que es lo que huele mal aqui:

• Recomendar una sola solución para envio de correo electrónico: Ahora ya se que script tengo que estudiar para poder reventar los servidores de este proveedor. No existe software perfecto y seguro este tiene fallas.
• El nombre que le pongamos al script no tiene nada que ver; Sólo ponga un enlace desde su página web al script renombrado y listo, podemos usarlo de nuevo. La seguridad a traves de obscuridad no va a conseguir nada.
• ¿No es mejor hacer responsable a los usuarios por sus metidas de pata? Si te hackean el servidor por software mal escrito, entonces la cuenta es suspendida hasta nuevo aviso. Si se envia correo con SPAM te multan, por instalar software de baja calidad. Me parece un intento heorico (y bastante nulo) el tratar de conseguir fallas de seguridad de todo el software que tienen los usuario y decidir en base a unas cuantas pruebas si es lo suficientemente seguro o no.
• El proveedor podría evitarse este problema si tuvieran una "granja" para envio de correo electrónico. Aquellos que ralmente necesiten hacer envio masivo de correo entonces deben usar servidores especiales, de lo contrario la cantidad de correos enviados por minuto es drasticamente limitada. Los Spammers trabajan por escalas y el bajar el volumen afectaría sus margenes enormemente, además de que es más fácil de monitorear.
• Prohiban la instalación de ciertos scripts. Admitalo, hay código de aficionados escrito en PHP que nunca debió ver la luz de el día. Si sabe que cierto script (de código gratuito) tiene una larga historia de problemas de seguridad entonces prohiba su uso.
  

Desgraciadamente el proveedor está siendo reactivo y no proactivo y estas medidas dudo que solucionen el problema a largo plazo. Quizas sería más efectivo que ellos suplieran los servicios de envio masivo de correos como una alternativa para aquellos que realmente lo necesitan.

¿Y usted, que opina?

Buscar en Technorati: seguridad