Re: OT Re: antivirus proxy SOLUCIONADO
El vie, 16-11-2012 a las 09:53 +0100, Esteban Torres Rodríguez escribió:
> El día 15 de noviembre de 2012 14:48, Trujillo Carmona, Antonio
> <antonio.trujillo.sspa@juntadeandalucia.es> escribió:
> >
> > El vie, 09-11-2012 a las 16:48 +0100, Esteban Torres Rodríguez escribió:
> > .../...
> >> Nos puedes dar mas detalles de como está montado? Tengo que migrar el
> >> servicio de 2 proxy en sedes diferentes a centralizarlo todo a 3 proxy
> >> en la sede central y todo consejo me interesa.
> >>
> >> Cuantas máquinas forman el servicio? Utilizan la cache preguntandose
> >> entre ellas o tienen una particion compartida con algun sistema de
> >> ficheros como GFS (Claro está, si tienes la posibilidad que puedan
> >> compartir mismo almacenamiento)? Que sistema de ficheros utiliza tu
> >> cache? Como autentican los usuarios? Active Directory? Utilizas Single
> >> Sign-On?
> >>
> > .../...
> >
> > El servicio en dado por una sola maquina montada en un proliant DL360,
> > con una CPU dual core Intel Xeon a 2.33GHz y 4G de memoria.
> > Tengo una maquina virtual (VMware ESX) para dar el servicio en caso de
> > caída de la principal.
>
> Esta es una de mis dudas. Tengo unas máquinas RX220 / RX200 para poder
> montar el proxy, pero el rendimiento de I/O de los discos es malo. Al
> final me he decantado por montarlo en virtual ya que ahí tendré mas
> juego con el hardware. Pero, que opinas de montarlo todo en virtual?
> Ya dependes de la capa virtualizada.
>
Como te he comentado la maquina de respaldo la tenemos virtualizada,
pero hay un gran punto de problemas en la virtualización, es la red.
La red se comparte entre todos los equipos virtuales (tenemos unos 120
en 4 ESX fisicos) por lo que si repartes 2G (dos tarjetas de red de 1G)
entre todos estos servidores el ancho de banda y la latencia que quedan
son muy escasos, por eso servidores como el nagios y el proxy los hemos
tenido que "desvirtualizar", si tu disponibilidad de virtualización es
distinta no creo que tengas problemas.
> > No lo he montado en cluster por que fallo, y todavía no se por que,
> > tengo montado un cluster con maquinas iguales y funciona perfecto, pero
> > este no. Quizás el fallo sea por las versiones del "corosin" que al
> > estar en "testin" cambia, lo tengo en asuntos pendientes el volver a
> > montarlo.
>
> Las máquinas que yo estoy montando las tengo detrás de un balanceador
> con roundrobin.
>
> > La maquina principal valida contra un A.D. montado sobre unos windows
> > 2008R2 valida a los usuarios por kerberos o por los ticket de windows,
> > además de por clave, pero solo activamos la validación de usuarios de
> > forma puntual, pues tenemos problemas con algunas maquinas, y es que
> > cuando lo activas el proxy tiene que identificar a todos los usuarios y
> > las conexiones hechas por los sistemas (actualizaciones de software...)
> > no tienen usuario valido, por lo que poner el sistema en orden da mucho
> > trabajo.
>
> Esto no lo entiendo muy bien. Dices que la validación de los usuarios
> es contra AD, bien. Pero haces el Single Sign-On? Yo, los clientes los
> tengo configurados con un .pac para poder poner las exclusiones y
> redirigir el tráfico como yo quiera. Lo de la autenticación me
> interesa mucho, ya que mi jefe está caprichado en que los usuarios no
> tengan que poner usuario y contraseña para poder navegar y eso, según
> las pruebas que hice en su día, ralentiza mucho y hay páginas que por
> un bug del firefox no hacen bien la autenticación (al menos esto me
> paso en su día).
>
Si, cuando lo hemos activado, se hace Single Sign-On, por cierto para
que funcione en firefox hay que cambiar un atributo entrando en el
"about:config" :
network.automatic-ntlm-auth.allow-proxies
network.automatic-ntlm-auth.trusted-uris (donde tienes que poner el
dominio).
Incluso funciona el Single desde mi Debian (la sesión de gnome también
valida contra dominio)
>
> > Además identificar por usuario mete retardos (que pueden ser minimizados
> > ampliando el tiempo y tamaño de la cache, pero los mete).
>
> Ampliando tiempo? a que tiempo te refieres?
>
Perdón hablaba de memoria, el tiempo de la cache solo se ajusta para la
identificación "basic", esta es la configuración que ponemos (por si te
sirve):
### negociación kerberos e identificación ntlm
#auth_param negotiate program /usr/local/bin/negotiate_wrapper -d
--ntlm /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
--domain=HVN
--kerberos /usr/lib/squid3/squid_kerb_auth -d
#auth_param negotiate children 10
#auth_param negotiate keep_alive off
#
#### identificación ntlm pura
#auth_param ntlm program /usr/bin/ntlm_auth --diagnostics
--helper-protocol=squid-2.5-ntlmssp --domain=HVN
#auth_param ntlm children 10
#auth_param ntlm keep_alive off
#
#### identificación basic usando ldap para clientes no identificados por
kerberos/ntlm
#auth_param basic program /usr/lib/squid3/squid_ldap_auth -R -s sub \
# -b "dc=hvn,dc=sas,dc=junta-andalucia,dc=es" \
# -D U_Servicio_Cursos@hvn.sas.junta-andalucia.es
-W /etc/squid3/ldappass.txt \
# -f sAMAccountName=%s -h hvn.sas.junta-andalucia.es
#auth_param basic children 10
#auth_param basic realm HVN
#auth_param basic credentialsttl 1 minute
#
> > Lo que si usamos es la denegación de acceso a internet a maquinas que
> > estén metidas en un grupo de dominio AD de maquinas sin internet.
> > No utilizamos cache compartida pues los fallos del proxy principal son
> > mínimos (prácticamente inexistentes si no los tocamos) y no creo que
> > valga la pena el ahorro de tiempo perdido por el servidor secundario en
> > descargar lo que tenia el primero en la cache contra la complejidad que
> > añade tener un disco compartido.
>
> Si, llevas razón. Yo habia pensado en tener una lun compartida entre
> las máquinas virtuales. Pero esto, a parte de tener la complicación
> añadida de ese disco, creo que puede penalizar en I/O de disco. No
> se.... Al final creo que pondré 3 proxys con su cache individual para
> cada uno y que todos sean hermanos de todos.
>
> > El proxy secundario no tiene configurado control de usuarios, maquinas o
> > acceso a paginas maliciosas alguno, tal y como esta montado no lo
> > soportaría, pero para el poquísimo nivel de fallos se asume que en caso
> > de estos no haya control hasta la reparación del principal.
> > El sistema de ficheros, visto desde el SO es xfs (para la cache, para el
> > sistema es ext3 y desde el squid3 es ufs:
> > # mount
> > /dev/cciss/c0d0p1 on / type ext3 (rw,errors=remount-ro)
> > tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
> > proc on /proc type proc (rw,noexec,nosuid,nodev)
> > sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
> > udev on /dev type tmpfs (rw,mode=0755)
> > tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
> > devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
> > /dev/cciss/c0d0p2 on /var/spool/squid3 type xfs (rw)
> >
> > # cat /etc/squid3/squid.conf |grep "cache_dir"
> > # cache_dir aufs Directory-Name Mbytes L1 L2 [options]
> > cache_dir aufs /var/spool/squid3 14336 16 256
> >
> > Tenemos unos 2500 PC en 4 sedes manejados por unos 6000 usuarios y por
> > exigencias superiores todo el acceso a internet lo tenemos que encaminar
> > a un proxy padre del que solo se su nombre y el puerto.
>
> El servicio que yo quiero montar es para unos 1300 usuarios (de
> momento). Yo lo quiero poner en varias máquinas ya que ahora lo tengo
> todo en una sola y cuando quiero hacer algo en esa máquina me veo
> pillado por que en ese momento no se puede reiniciar el servicio. Lo
> que busco es un poco la alta disponibilidad y poder hacer un pequeño
> mantenimiento en las máquinas sin que el servicio se vea afectado.
>
> >
> > Espero que te sea de utilidad y si crees que hay algo mal en la
> > configuración que tengo doy por bien venida cualquier sugerencia.
>
> Muchas gracias!!!!
>
>
> >
> >
> >
> >
> > --
> > Es hora de negarse a caminar de puntillas cerca de los que piden
> > respeto, consideración, tratamiento especial, basados en que tienen fe
> > religiosa, como si fuera noble creer afirmaciones sin base y
> > superticiones antiguas. -A. C. Grayling, filósofo Por favor, NO utilice
> > formatos de archivo propietarios para el intercambio de documentos, como
> > DOC y XLS, sino HTML, RTF, TXT,CSV o cualquier otro que obligue a
> > utilizar un programa de un fabricante concreto para tratar la
> > información contenida en él. SALUD.
> >
> >
> > --
> > To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> > Archive: [🔎] 1352987310.6685.36.camel@trujo.hvn.sas.junta-andalucia.es">http://lists.debian.org/[🔎] 1352987310.6685.36.camel@trujo.hvn.sas.junta-andalucia.es
> >
>
>
--
trujo <antonio.trujillo.sspa@juntadeandalucia.es>
Reply to: