<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Dice un refrán popular: ni tan calvo ni con dos pelucas...<br>
<br>
El problema es que nos estamos moviendo en los extremos. Veamos:<br>
<br>
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8">
<title></title>
<meta name="GENERATOR" content="OpenOffice.org 1.9.129 (Linux)">
<meta name="AUTHOR" content="Reinaldo Mayol">
<meta name="CREATED" content="20060421;3010800">
<meta name="CHANGED" content="20060421;10125000">
<style>
<!--
@page { size: 21cm 29.7cm; margin: 2cm }
P { margin-bottom: 0.21cm }
--></style>-
Cerrar por omisión el tráfico saliente a puerto 25. Funcionará en el 90
% de los casos. El problema es cuando se hace sin excepciones.
Recuerden que una de las bases de cualquier sistema de seguridad es
poner un grupo de alcabalas ( o sitios de control). Eventualmente
alguien los podrá pasar todos, pero la mayoría de las condiciones de
riesgo podrán evitarse en alguna. RESUMIENDO: en mi opinión se debe
cerrar y permitir excepciones. <br>
- El uso de SMTP_AUTH+TLS es otra cosa. Efectivamnte utilizarlo evitará
multiples problemas, pero no es uno de ellos el que los sistemas
generadores de virus, spam,etc... no lo usen. Realmente hace el trabajo
de esos sistemas más complejo pero no hay argumentos técnicamente
sostenibles para que no lleguen a hacerlo. Así que hay que usarlo pero
no creer que es una solución permanente y definitiva. <br>
<br>
Creo que el fondo de las dos posiciones radican visiones de extremo.
Una que subestima los derechos y necesidades de los usuarios con el
argumento de " tener todo bien de capa 7 para abajo". El problema es
que esa posición no acepta que no hay capas 1-7 sin capa 8, sin la cual
poco importan las otras 7. <br>
<br>
La otra posición por liberal (que en el fondo es lo más cercano al
anarquismo) termina cerrando los ojos a los pequeños detalles del día a
día y no acepta la importancia de ir paso a paso. <br>
<br>
Si hay mejores soluciones adelante, pero mientras tanto hay que ir
tomando decisiones de día a día. Eso si, comprendiendo sus limitaciones
y objetivos. <br>
<br>
S'<br>
mayol<br>
<br>
<br>
Lucas G. Obredor wrote:<br>
<br>
<span style="white-space: pre;">> Creo que el punto de vista que
expresa el Sr. Nicolás es totalmente valido, con solo leer los
argumentos que expresa y de la forma que lo hace uno puede darse
cuenta. Por otra parte, aunque esta muy bien redactado, el mail de esta
ultima persona me parece un tanto extremista y fuera de lugar.<br>
> <br>
> Muchas gracias,<br>
> <br>
><br>
> *Lucas G. Obredor*<br>
><br>
> *Tecnología y Nuevos Servicios*<br>
><br>
> Pte. Perón 1783 – San Miguel<br>
><br>
> ' (5411) 4469-7490<br>
> * <a class="moz-txt-link-abbreviated" href="mailto:lobredor@telered.net.ar">lobredor@telered.net.ar</a><br>
><br>
> -----Mensaje original-----<br>
> *De:* <a class="moz-txt-link-abbreviated" href="mailto:seguridad-bounces@lacnic.net">seguridad-bounces@lacnic.net</a>
[<a class="moz-txt-link-freetext" href="mailto:seguridad-bounces@lacnic.net">mailto:seguridad-bounces@lacnic.net</a>]*En nombre de *Webmaster Comtron<br>
> *Enviado el:* Viernes, 21 de Abril de 2006 10:02<br>
> *Para:* <a class="moz-txt-link-abbreviated" href="mailto:seguridad@lacnic.net">seguridad@lacnic.net</a><br>
> *Asunto:* Re: [LACNIC/Seguridad] [Seguridad] Nuevo código de
conducta anti-spam en Australia<br>
><br>
> Nicolás:<br>
><br>
> Saliendo un poco de la parte técnica, me parece algo arriesgado
hablar de un "derecho" a conectarte a un puerto determinado en el otro
punto del mundo. Seguramente, eso algún día caerá en manos de algunos
abogados y se dedicarán a discernir si el acceso a Internet es un
"derecho humano", divino o terrenal, en fin, a ponerle los títulos.<br>
> Mientras tanto, la mayoría de los que estamos en esta lista
tratamos de no ir mas arriba de la capa 7 y asegurarnos que todo lo que
está por debajo nos funcione como se debe.<br>
> Por eso, y aunque te suene algo duro mi comentario, tus razones
son atendibles pero tremendamente egoistas.<br>
> Porque poner solo "MI" problema como excusa y no considerar el
problema de recibir miles de spam en los usuarios, cientos de gigas de
consumo de ancho de banda inútil, saturación de redes, etc, etc, no veo
que se le pueda poner otro calificativo.<br>
><br>
> Si por mi fuera, ni en coma alcoholico permito que Telefónica se
ocupe de que mis mails lleguen a destino. Pero tengo que mirar un poco
mas allá de mi conveniencia puntual antes de escribir una crítica a lo
que se propone.<br>
> Dicho sea de paso, ¿alguna solución a la generación de spam desde
cuentas residenciales que no implique filtrar la salida por puerto 25?<br>
><br>
> Saludos<br>
><br>
> Javier<br>
><br>
> Nicolás Ruiz escribió:<br>
></span><br>
<blockquote type="cite">Marcelo Maraboli wrote:<br>
<br>
<br>
<br>
>- todos los computadores (PC) tienen denegado salida a Internet<br>
>hacia el puerto 25 SMTP, a excepción de servidores SMTP autorizados.<br>
>Parece simple, pero he visto varias empresas que no lo tienen <br>
>habilitado. Esto erradica la emisión de emails provocados por virus,<br>
>erradica el SPAM generado internamente, etc..<br>
<br>
<br>
<br>
Entiendo las buenas intenciones, pero me parecen mal dirigidas. Como<br>
usuario de un PC, considero que tengo el derecho de conectarme al puerto<br>
25 de otros equipos en el mundo, y puedo tener varias razones valederas<br>
para hacerlo:<br>
<br>
- Yo tengo un servidor SMTP en mi PC.<br>
- El sistema de versión de control distribuido que utilizo puede<br>
intercambiar data con servidores remotos via SMTP.<br>
<br>
<br>
<br>
>- para enviar email, la única manera es vía SMTP_AUTH + TLS. Si<br>
>algún usuario se infecta con virus/emailer, no podrá enviar porque<br>
>dichos emisores son SMTP simples y no entienden TLS. En cada email<br>
>(como este) verán la autenticación realizada y por ende<br>
>el receptor puede validar al emisor. Muchas empresas instalan<br>
>SMTP_AUTH y no agregan el header correspondiente, por lo que el<br>
>receptor igual no tiene forma de verificar al emisor.<br>
<br>
<br>
<br>
La única razón por la cual los virus/emailers utilizan SMTP sencillo y<br>
no entienden TLS es porque sirve para enviar correo. En el momento que<br>
se restrinja, implementarán las funcionalidades necesarias. Ojo que no<br>
quiero decir que no sirva de nada, pero no es una solución permanente.<br>
<br>
--<br>
Juan Nicolás Ruiz | Corporación Parque Tecnológico de Mérida<br>
Investigación/Desarrollo | Centro de Tecnologias de Información<br>
<a class="moz-txt-link-abbreviated" href="mailto:nicolas@ula.ve">nicolas@ula.ve</a> | Edif B (Fac. Ingeniería) Nivel Plaza, Ala Sur<br>
+58-(0)274-240-3889 | La Hechicera, Mérida - Edo. Mérida. Venezuela<br>
</blockquote>
<br>
-------------------------<br>
<br>
_______________________________________________<br>
Seguridad mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:Seguridad@lacnic.net">Seguridad@lacnic.net</a><br>
<a class="moz-txt-link-freetext" href="http://lacnic.net/mailman/listinfo/seguridad">http://lacnic.net/mailman/listinfo/seguridad</a><br>
<br>
<br>
<br>
<span style="white-space: pre;">>-------------------------<br>
<br>
>_______________________________________________<br>
>Seguridad mailing list<br>
><a class="moz-txt-link-abbreviated" href="mailto:Seguridad@lacnic.net">Seguridad@lacnic.net</a><br>
><a class="moz-txt-link-freetext" href="http://lacnic.net/mailman/listinfo/seguridad">http://lacnic.net/mailman/listinfo/seguridad</a></span><br>
<br>
</body>
</html>