SOLUCIONADO - Proxy transparente impide acceso a webmails

Foro para que los usuarios de MAX consulten las dudas que puedan tener.

Moderadores: daniel.esteban, victor.armendariz, ruben.garcia45, irene.olalla, dgonzalezarroyo

des_ticliceo
Mensajes: 30
Registrado: 04 Dic 2014, 19:56

Hola,

Como no me ha quedado claro por qué se ha solucionado el tema, sigo investigando por si en un futuro se reprodujera de alguna manera.
Las reglas de FW que afectan a https van en las reglas de IPTables de FORWARD, más concretamente en las de "fglobal".

Pego las reglas que tengo (quito el pegote de icmp...):

Chain fglobal (1 references)
pkts bytes target prot opt in out source destination
1 540 log udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:443
98 6853 log tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
1 540 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:443
98 6853 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
0 0 ACCEPT all -- * * 192.168.5.0/24 192.168.2.0/24
0 0 ACCEPT tcp -- * * 192.168.2.0/24 192.168.1.254 tcp dpt:23
ICMP-------------------------------------------------------------------------------------------------
0 0 ACCEPT all -- * * 192.168.5.0/24 192.168.1.0/24
0 0 ACCEPT all -- * * 192.168.5.0/24 192.168.2.0/24
0 0 ACCEPT all -- * * 192.168.5.0/24 192.168.3.0/24
0 0 ACCEPT all -- * * 192.168.5.0/24 192.168.4.0/24
0 0 drop all -- * * 192.168.3.0/24 192.168.1.0/24
0 0 drop all -- * * 192.168.3.0/24 192.168.2.0/24
0 0 drop all -- * * 192.168.3.0/24 192.168.4.0/24
0 0 drop all -- * * 192.168.3.0/24 192.168.5.0/24
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
390 27932 drop all -- * * 0.0.0.0/0 0.0.0.0/0

Se puede ver claramente que las dos primeras reglas son para loggear todo el tráfico 443 y luego para permitirlo y se ve que hay lo mismo matches (estos matches son de después de aplicar el workarround), por lo tanto el tráfico debía ser permitido si llegaba a esta regla, es decir, que en algún punto anterior debía dropearse.

El tráfico a "fglobal" llega por la regla general de FORWARD, que se compone de la siguiente manera:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
44 2205 fdrop all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
5267 1935K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
490 35381 fnospoof all -- * * 0.0.0.0/0 0.0.0.0/0
490 35381 fredirects all -- * * 0.0.0.0/0 0.0.0.0/0
490 35381 fmodules all -- * * 0.0.0.0/0 0.0.0.0/0
490 35381 ffwdrules all -- * * 0.0.0.0/0 0.0.0.0/0
490 35381 fnoexternal all -- * * 0.0.0.0/0 0.0.0.0/0
490 35381 fdns all -- * * 0.0.0.0/0 0.0.0.0/0
489 35325 fobjects all -- * * 0.0.0.0/0 0.0.0.0/0
489 35325 fglobal all -- * * 0.0.0.0/0 0.0.0.0/0
ICMP --------------------------------------------------

El cambio hecho en "Iptables.pm" implicaba que cualquier paquete que el FW considerara como INVALID lo dropee excepto si el puerto de destino es el puerto 443, por lo que no queda otra explicación que el FW estuviera considerando todos estos paquetes como inválidos, es decir que estuviera macheando el la primera regla de FORWARD.

Lo que no sabría decir es por qué el FW entiende los paquetes con destino 443 como INVALID.

CIAO¡¡¡
des_madrid_linux
Mensajes: 491
Registrado: 01 Dic 2004, 10:17
Ubicación: EducaMadrid
Contactar:

Hola,

Me alegra que hayas encontrado una solución temporal y la compartas con nosotros. Seguimos mirando el otro tema ¿Qué versión de MAX tienen? ¿Se ha actualizado? En algún momento de las actualizaciones pusimos una regla para solucionar los problemas de seguridad con algunos proxies, la regla es:
pref("security.tls.version.max",1);

La puedes configurar via about:config o /etc/firefox/pref/max-firefox-conf.js, pero la pusimos automática en actualizaciones.

Si puedes dejarme un mensaje privado (o al mismo id de aquí pero @educa.madrid.org) con la ubicación de vuestro centro, si está en Madrid, miro si en algún momento podemos pasar a verlo en caso de no resolverse.

Saludos,
Grupo de Desarrollo MAX

¡¡Sé libre: usa MAX!!
des_ticliceo
Mensajes: 30
Registrado: 04 Dic 2014, 19:56

Hola Javier,

Tengo que decir que el problema se ha vuelto a reproducir y la verdad es que no sé por qué... :cry:
El único camino que estoy siguiendo ahora es que modificando el archivo "/usr/share/perl5/EBox/Iptables.pm" se pierda la configuración de los cambios cuando se guarda la configuración del módulo según la siguiente referencia:
https://wiki.zentyal.org/wiki/Es/3.5/De ... ados#Hooks

Estoy viendo como meter la regla "-A FORWARD -m state –state INVALID -j fdrop" en "/etc/zentyal/hooks# more firewall.postservice" para que sea permanente.

Por otro lado, se me olvidó comentar que adicionalmente a la regla de IPTABLES, tuvo que cambiar la MTU de "Automático" a 1500 para que echara a andar.

Os voy contando, lo conseguiré. Muchas gracias por tu interés.

CIAO¡¡¡
des_ticliceo
Mensajes: 30
Registrado: 04 Dic 2014, 19:56

Hola,

parece que está solucionado, al menos de momento todo funciona correctamente. La solución la encontré en este post:
https://forum.zentyal.org/index.php?topic=21555.0

Se trata de meter en la excepciones de la caché del proxy las siguientes direcciones:
- mail.live.com
- login.live.com

Una vez hecho, los usuarios comienzan a entrar en hotmail sin problema, que era la única pega que quedaba en el tintero.
Adjunto pantallazo.

CIAO¡¡¡
Adjuntos
Cache exemptions
Cache exemptions
2015-01-29_153705.png (6.9 KiB) Visto 2834 veces
des_madrid_linux
Mensajes: 491
Registrado: 01 Dic 2004, 10:17
Ubicación: EducaMadrid
Contactar:

Genial,

me alegra que se haya solucionado, aunque sigo sin entender muy bien porqué funcionaba en windows y no en max, pero bueno, siendo sitios de microsoft tampoco es muy de extrañar.

Saludos,
Grupo de Desarrollo MAX

¡¡Sé libre: usa MAX!!
Responder