El 08/04/15 a las 12:00, låzaro escribió:
Thread name: "Re: [Gutl-l] Incrementar la seguridad en el Proxy(Squid)
[1/2Solucion]"
Mail number: 22
Date: Wed, Apr 08, 2015
In reply to: Michael González Medina
El 07/04/15 a las 18:15, låzaro escribió:
Thread name: "Re: [Gutl-l] Incrementar la seguridad en el Proxy(Squid)
[1/2Solucion]"
Mail number: 11
Date: Tue, Apr 07, 2015
In reply to: Michael González Medina
El 07/04/15 a las 16:56, Michael González Medina escribió:
El 07/04/15 a las 16:48, Carlos R Laguna escribió:
El 07/04/15 a las 16:06, ERNESTO TUR LAURENCIO escribió:
Como bien dices la idea de blindar más aún las conexiones
mediante el uso de SSL es una, lo que ya sabes que vas a
sacrificar velocidad de acceso por nivel de cifrado.
Mientras no aparezca la indicada, goza con la equivocada.
Salu2
-----Mensaje original-----
De: gutl-l-boun...@jovenclub.cu
[mailto:gutl-l-boun...@jovenclub.cu] En nombre de Michael
González Medina
Enviado el: martes, 07 de abril de 2015 02:39 p.m.
Para: Lista cubana de soporte tecnico en Tecnologias Libres
Asunto: [Gutl-l] Incrementar la seguridad en el Proxy(Squid)
Buenas tardes:
Antes que nada aclarar, que, cuando me refiero a seguridad en
el Proxy(Squid), estoy hablando de, la comunicación entre el
cliente y el servidor. Este tema se ha tocado varias veces y
existen otras variantes(como el Kerberos, LDAP, helpers del
Squid hechos para esto,
etc) pero... siempre hay un pero... existen
holgazanes/vagos/paranoicos como yo, a los que estas
soluciones les resulta un tanto engorrosas o...
no compatible por filosofía etc...
En fin, que buscando y probando, he logrado el tópico de este
correo pero, sin usar ninguna de las soluciones anteriores
sino, una un poco mas sencilla, pero que por ello, no deja de
ser válida, cual...:
Web Proxy Autodiscovery Protocol(WPAD) sobre SSL
me explico:
Mediante el queridísimo servidor de páginas web Apache,
montamos un Virtualhost(mencionar aquí *muy importante* que se
le debe habilitar el soporte para SSL lo cual es crítico en
este caso[lo explico mas adelante]), en este, ponemos el
script "proxy.pac" (que es el que contiene la información del
proxy), luego en los clientes(es decir en los
navegadores[Firefox]) configuramos la red como "configuración
automática del proxy" y le ponemos la url del Virtualhost, y
listo!
La diferencia del método tradicional (sin soporte para SSL)
es... que...
mientras, en el método anterior, si se conecta un
sniffer(hablo de sniffer porque es lo mas común para
monitorear redes en busca de datos
etc..) y se monitorean las conexiones, se podían obtener datos
relevantes en cuanto a user/pass etc.. sin embargo, al estar
comunicándose sobre SSL el sniffer no puede ver con la misma
facilidad dichos datos, por lo que, sí, creo que ahora la
comunicación entre cliente-servidor es un tanto más segura,
saludos,
PD: Se aceptan críticas/debates , dale Lázaro, "pichea" que yo
se que este tema te encanta.
______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Tus opciones son, Kerberos
SSL, Firefox y Chrome lo soportan aunque no esta muy documentado.
cierto Carlos, lo que pasa es que no me quiero enredar ni con
Kerberos ni con LDAP para autenticar usuarios de un proxy, de
cualquier forma, muchas gracias por tu respuesta.
Por ejemplo, estoy "sniffeando" el esquema el digest y hasta
ahora... no veo el texto plano con el user y pass, así que....
pudiera(dejame cruzar los dedos.... ;-) ) ser una opción,
saludos,
Bueno vamos mejorando, ya me he cansado de "sniffear" el trafico de
datos entre cliente y servidor para autenticar en el Proxy y no
aparece el texto plano por ninguna parte, en cambio el metodo digest
usa nuevos campos como el nonce y el cnonce donde al parecer viajan
encriptados los datos del password(el campo user sigue siendo plano)
pero bueno, ya creo que ahora si, esta un pelin mas seguro,
saludos,
PD: No obstante sigo a la busqueda de perfeccionar esto hasta donde
sea posible.
En digest, el servidor del lado de hallá, almacena el password cifrado
y el cliente le envía dicho password cifrado, el servidor lo compara
con el que tiene almacenado y lo mache. Lo cual no es muy diferente de
si yo te intercepto el password y te lo mando cifrado :D sin
importarme cual sea este xD
y haz probado que pinche esto que me comentas? Te pregunto porque
cuando cliente-servidor establecen una conexión para transferir
datos(en este caso user/pass) dichos datos interceptados(flags,
headers, etc... ) en teoría deberían ser válidos durante el tiempo
de conexión por lo que si los interceptas y envías desde otro host
no deberían servirte,
y sigo pensando en voz alta...
La página tiene una mecánica sensilla.
Conectado por SSL, en mi caso a Unicorn como servidor web. Ahí te
muestra una página con un formulario. Al utenticarte, haciendo POST
(via SSL) en ese formulario, consulta la base de datos y verifique los
datos de autenticación
conexion=YAML.load '''
development:
adapter: postgresql
database: rails
encoding: utf8
reconnect: false
pool: 5
username: rails
password: rails
host: 127.0.0.1
'''
require 'active_record'
ActiveRecord::Base.establish_connection(conexion)
class User < ActiveRecord::Base; end
Esto sería una aplicación web sencilla (sinatra) sinatra:
# busca el usaurio en la base de datos
@user= User.find_by_username=params['usaurio']
# verifica si puso bien el password
if @user.password == Digest::SHA2.hexdigest(cual)
# tomamos la ip del usuario
@ip=params.remote_host
# y le habilitamos la navegacion
@user.navegacion=true
@user.ip=@ip
@user.save
end
Seguidamente, la página redirecciona dándote una cookie; a otra página
que te diga "mantenta esta página abierta".
Esa otra página, tendrá un timer (JavaScript) que cada N segundos, le
reitere una especia de keepalive al servidor. Mientras esa página este
abierta, transmitiendo cada 1 minuto ese keepalive, por ejemplo.
setInterval(function(){
jQuery.post(...)
},500)
La página tendría un cartelón bien grande que diga:
<h1>No cierre esta página</h1>
Del lado de allá (sinatra en el servidor), chequeamos que esto esté sucediendo
get '/autenticacion'
@user=User.find_by_ip params['ip']
@user.navegacion=true
end
Localizamos al usaurio por su IP, esto devolverá un usaurio que ya se
halla autenticado (por su ip que cogimos) y refresca el cambo
navegación (booleano)
Por detrás del telón, tendriamos un script corriendo y caudcando
usuario cuya última autenticación sea de hace más de 1 minuto.
Esto quiere decir que cerró la página.
refrescar.rb
Tenemos una tabla personalizada en iptables que recrearemos
constantemente.
system('iptables -F navegacion')
# para todos los usuario que estén navegando
for usuario in User.find_all_by_navegacion true
# verificar cuando fue la última vez que mandó el ping
# si fue hace más de 5 minutos
if Time.now - usuario.updated_at > 300
usuario.navegacion=false
usuario.save
else
# si está en regla (tiene la página abierta)
# lo autorizamos
system %[iptables -A navegacion -s #{@ip} -j ACCEPT]
end
end
No es tan fácil ponerlo en un correo como lo tengo en mi cabeza. Pero
espero que le de una idea a alguien.
ok pero, ya aquí, no estas usando Squid para nada(o al menos no para la
autenticación)... no...??
--
Michael González Medina
Administrador de Red
Centro Nacional de Sanidad Vegetal
--
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.
______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
