[LACNIC/Seguridad] SquirrelMail

Lun Mayo 15 22:11:03 BRT 2006

Bueno respondiendo a los comentarios...

Pregunto acaso un servidor de correo, es de solo acceso web, y no brinda
servicio locales y remotos.... O es que a veces  uno come para llenarse el
estomago y satisfacer necesidades... Uhmmm 

Te dire que en las buenas practicas de la seguridad y quizas ampliandonos a
los que es gobernabilidad de la seguridad, si un intruso logra acceder una
red, no el equipo o servidor de correo, por eso no me referia al acceso del
servidor... Sino a todo el servicio en si, el servicio de correo no solo
esta en un escenario, pues mi posicion va por cerrar el circulo y tener en
cuenta la integridad de la seguridad, no puedo proteger un solo canal por
que solo le doy uso en este momento, o por que no me lo pidieron,  sabiendo
que mis usuarios utilizan el correo no solo para comunicarse, y que les
llega solo texto y adjuntos, creo que ser paranoico en esta epoca no es bien
visto, pero al menos en seguridad si hay que serlo,  y con la poca
experiencia, he visto que inclusive por este medio una organización puede
perder mucho, con solo un descuido en los accesos y los protocolos que
corren en el servicio, o si me expando mas, hasta con una orden de un click
desde http o http-ssl puedes intervenir el servidor de correo y no estar
logueado como root, he inclusive poder visualizar la información, basta con
un nobody o el permiso del mismo apache, no creo que Google este
desperdiciando costo computacional, haciendo trabajar mas a su
administrador, etc... Tratando de dejar que su servicio sea  solo web y
termino la seguridad para ellos...

Por el caso de sendmail que presenta vulnerabilidades, no discutiré... Y no
se necesitas estar como superusuario para poder observar el loopback, pues
entonces diriamos que es un inutil quien descubrio la tecnica del spoofing y
quienes la utilizan....o  Pues quizas esta técnica esta de adorno y es
pérdida de tiempo para los que la utilizan?????

Bueno quizas no estes enterado, existen casos de estudio por la cual la
captura de las contraseñas (tambien pensando que los usuarios, por costumbre
tienen un buen habito por la seguridad, si la misma contraseña del correo a
veces el mismo para las cuentas de ahorro, tarjetas, y hasta de su misma PC)
ha causado pérdidas, entonces según la forma de pensar de algunos no muy
preocupados, pues en las VPNes, solo hubieran encriptado el acceso en la
capa de aplicacion, pero no la de session, transporte y red....  Si para
poder husmear la informacion hay que estar en el gateway y como
superusuario.... Eso seria la nueva forma de pensar en seguridad... Otra
cosa todo el pool de protocolos que trabajan con el correo poseen errores de
diseño y se estan parchando y tomando medidas...para tratar de proteger...

Creo al menos si cumples todos los eslabones de la seguridad al menos estas
bajando tus niveles de riesgo, y el dia menos pensado si no pusiste enfasis
en una cosa  basica que puedes subestimar, por que al agregar complejidad al
trabajo del administrador (más cuando su experiencia en el tema no es
mucha), incompatibilidades en algunos casos, costo computacional en todos, y
una protección ante ningún peligro, pues si la organización no le interesa y
no posee politicas, pues seguira como sino paso nada, pero sino, perderías
el trabajo y mucho mas por no cumplir ciertas cosas básicas. Muchas empresas
hasta por descuidarse en temas que quizas como algunas excelentes empresas,
invierten tanto y descuidan otras cosas, por subestimar al administrador, y
por que no tiene caso tal protección, sino es mucha carga  computacional,
pues han perdido las joyas de la corona (caso CDUniverse, google quizas lo
encuentres, pues la mayoria de los casos no salen a la Luz....).

Bueno espero que mis comentarios no causen suspicacias, tengo para poder
hablar mas, pero creo que hice incapie a esto que esta muy de moda y que no
es tema nuevo,  Defense in Depth.... Y lo que es el hardering.... Y no lo
tomen como que espero ser el poseedor de la razón o paranoia.... Me olvido
de muchas cosas y disculpen si es que encuentran horrores ortográficos

Saludos Cordiales..... Espero mas comentarios.....

-----------------------------------------------------------
 Anatoly Alexei Pedemonte Ku 
 RAGE SYSTEMS S.A.C.
 http://www.ragesys.net
 Av. Juan Pascal Pringles 1225 (ex- La Fontana) - LA MOLINA
 LIMA - PERU
 Teléfono: 511.7962262 
 Móvil: 511.97167435 
-----------------------------------------------------------
Este correo y su contenido son confidenciales y exclusivos para su
destinatario. Si usted recibe este mensaje por error o no es el destinatario
del mismo, por favor sírvase eliminarlo y notificarle a su originador. Así
mismo, todas las ideas y reflexiones expresadas en esta comunicación
corresponden al originador del correo y NO representa la posición oficial de
su empleador.
----------------------------------------------------------------------------
----------------------------------------------------------
This email is intended only for the addressee(s) and contains information
which may be confidential, legally privileged. If you are not intended
recipient please do not save, forward, disclose or copy the content of this
email. Please delete it completely from your system and notify
originator.Finally, all ideas expressed in this communication are personal
comments and NOT represent official position of his employer.
----------------------------------------------------------------------------
----------------------------------------------------------

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.3 (MingW32)

mQGiBERIkeQRBAClI9GKvK4sDfnnXiZPZAu1LxTNd8dT+F2SG3R38LbCPzqKE7vh
GpIv73VkjoSaRPdeB3LXWwA6aKEQU+IZESB78EaQomSfNYCxDshc7DoqgYX9F6cJ
chlB2bhC8FP1l3wUMudTIyPyKjg84DkSDSnwn7xjAe7cvKyZ+ro0/7FRTwCg/7dQ
Q9Bmb/bx7nUgb0ciWRbQSEcEAIUXDt8uTbIdq+dH5ufMFFV+KwobpXA8wA6J0vkv
BI9mdh+7IaQ6W9Tb3v78QMC2C9EbTQUJueCNZ/e7BT1VraTzZhbxR8WXyL1F9a5Y
TEdU//d33Wx1RG3WPIFvWkAy/AgOaxMpJ4ObvEVEyVevDn0J5PtVjflpO3yeCVns
iLSwBACJegqLf9fp3Rz57rQaDwtnDMUd54T6ZdWpxHnz3x1lPqcN1BC8zZcxOpMh
PgvzbH6jjaC2T4LMppqFDVq2xA9+UJINmen5S92HzNvyvq6VmaWwO1QCKWApQes+
NFOIU+/pPFsSHLJxl2h0lu0MW2hwYbno+MwirmHgBGoAs8H0gbRIQW5hdG9seSBB
LiBQZWRlbW9udGUgS3UgKEZpcm1hIERpZ2l0YWwgZGUgQW5hdG9seSkgPGFuYXRv
bHlAcmFnZXN5cy5uZXQ+iGAEExECACAFAkRIkeQCGwMGCwkIBwMCBBUCCAMEFgID
AQIeAQIXgAAKCRBnMNxOlTPvNcsBAKCLyLwBbsoZwQFuUWifS1Qv+158iACguCAl
ApL0XCJJsxwaDcJC0YKbzV+5Ag0EREiR6RAIAJMJSK3nF7/GOZPK+xu7nt2OpbtD
sE+g5wS8Nz9rEEsTbDRqmLZ9neS6OODGj6abGFy6dUtR7LcJtCXufCr+dEsGA4O0
iSY/8k1bjWqoNqxHcTYbdhjy/SxYQOIrurTSsmlludhVn0XlpXN87jd9HtWi/Lg4
TZhp0CRqG7IfY8BGySUbqAWB63x8jMXTzJRoorJx/HxbDRvDAayJcZ+LV3l6dF0f
68km3TebPYf9Cca6cEQvn96gflcijneTbeKPU2JVClYBHtlnlJgFZjNsdSmsl3qb
m20BRWIyTux/Om7YBEZlGA6JonYQxmbK+LEnLvyTHUgohtYWEP5ED8qv1ncAAwUH
/0kpGlCvzHh1B1CH3Uc/AeUoXihvZM2D0TA887PyFSNAgkZBYyriRt8I7rTuVk4m
XvphOLJvSqoYUX+9kLP0oDWVzBGfKmvFWaoXVjOeP3D/o4r6YxZTVM6NdvSgS+gd
5U45Zg3f2offihvcNFyENjsFyYm2J8iTQb/YZqfb0fOrQNqp2I5HLsQO5rsyaok8
xZfwjjZO1mXvCtPvwNs5KoAzvrCElUXNjG0rigXL9/M4Ewjq3mVcL3K5mlOEg2Rj
qd6HfatZ6Fd00iGt751dHM45OO8+FTF6MD4DFR0+N25fS5PsYqM8Cc87yDdt/6G9
vLyvkPfmperuFuuWvQuR/mCISQQYEQIACQUCREiR6QIbDAAKCRBnMNxOlTPvNRvm
AKDCEGmCqWCdH+f4ZYal1bAXaNF2MwCdFiGKKQq3bxkF1iIlvlbzUs5GKTY=
=e5cb
-----END PGP PUBLIC KEY BLOCK-----

-----Mensaje original-----
De: seguridad-bounces en lacnic.net [mailto:seguridad-bounces en lacnic.net] En
nombre de Guillermo Pereyra Irujo
Enviado el: Lunes, 15 de Mayo de 2006 04:13 p.m.
Para: seguridad en lacnic.net
Asunto: Re: [LACNIC/Seguridad] SquirrelMail

Anatoly Alexei Pedemonte Ku escribió:
> ... para tu caso es mejor encriptar la información en el protocolo 
> http y luego el imap4 o pop3, ahora  estos 2 ultimos protocolos corren 
> localmente en el servidor de correo, no significa que asi tal como 
> son, debieran estar seguros por que corren localmente, pero 
> sinceramente, la verdad es que estan totalmente abiertos al husmeo por 
> que la informacion es clear text, creo que al menos en la informatica 
> no se puede subestimar los escenarios.

Estoy de acuerdo en que no hay que subestimar los escenarios, pero creo que
tampoco hay que hacer esfuerzos innecesarios. Lo del HTTPS es correcto y
necesario. Lo del IMAPS, creo que no es un beneficio.

Si no me equivoco, para observar el tráfico de la interfaz loopback, hay que
estar dentro del host y ser el superusuario. Si un intruso logra eso, las
claves de correo son lo de menos. No sólo podría leer los mensajes de todas
las cuentas directamente desde el filesystem sin tener que sacar las claves
de la red; también podría borrar todo el correo, o interrumpir el servicio,
o tomar el servidor. Considero que encriptar las conexiones locales sólo
agregaría complejidad al trabajo del administrador (más cuando su
experiencia en el tema no es mucha), incompatibilidades en algunos casos,
costo computacional en todos, y una protección ante ningún peligro.

Está bien igual que esto es sólo un caso, y podemos seguir discutiendo
implementaciones por mucho tiempo. Tampoco está _MAL_ encriptar todo. Lo que
en última instancia argumento es que, puesto que a la seguridad absoluta no
se llegará nunca, conviene concentrar el esfuerzo en los puntos de más
peligro, en lugar de intentar abarcar absolutamente todo. 
No sólo para maximizar la eficiencia del trabajo de administración; los
cambios también introducen nuevos riesgos (fallos del software nuevo,
errores del administrador, incompatibilidad, falsa sensación de seguridad,
etc) y en algún punto el riesgo que se introduce es mayor que el que se está
evitando.

--
Guillermo Pereyra Irujo
Tandil, Argentina

_______________________________________________
Seguridad mailing list
Seguridad en lacnic.net
http://lacnic.net/mailman/listinfo/seguridad
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3692 bytes
Desc: no disponible
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20060515/385db4f5/attachment.bin>