Speedy, DNS y VPNs
Estando de viaje hace poco me toco tener que unirme a una red wifi conectada al mundo con un ADSL Speedy de Telefónica. Todo funcionaba perfecto hasta que tuve que conectarme a una VPN corporativa.
DNS Hijacking
La gente de Speedy es muy buena y por eso no quieren que nos quedemos sin ver un site por más que nos equivoquemos de dirección. Así, si ponemos www.algún-dominio-que-no-exista-en-internet.com el server DNS de Telefónica respondera llevandonos a una página en www.ayudaenlabusqueda.com.ar donde nos hará saber que la dirección ingresada no existe y, gracias a un convenio comercial con yahoo, nos mostrara el resultado de buscar la URL erronea.
El Mundo Real
Esto es muy lindo a simple vista, pero en realidad es una aberración, una diarrea mental que destruye la forma en que funciona internet. No quiero cargar contra los ineptos a los que se les ocurrio esta feature, yo aun recuerdo la conferencia de prensa “Presidente de Télefonica Vs Generadores de Contenidos” donde el vegetal dinosaurio no asumia su condición de carrier y queria que los sitios como google paguen un canon a telefonica porque “los cables eran de ellos”. Una burrada. Es como que el presidente de Edenor quiera que las fabricas de electrodomesticos les paguen un canon por usar su electricidad.
DNS y VPN
¿Por qué esa inocente página es una aberración? Porque cuando conectamos nuestra computadora a otra red, por ejemplo una VPN, e ingresamos una dirección en nuestro navegador que sea INTERNA DE LA VPN (por ejemplo webmail.exchange.empresa.net), lo que normalmente ocurrirá es que se haga un DNS request por la red que tenga mejor metric, osea el adsl, este responda con ‘unknown host’ y luego se repita el pedido por la vpn quien respondera con la IP INTERNA del server al que queremos acceder.
¿Qué pasa con el puto Speedy de Telefónica? En lugar de decirnos ‘Unknown Host’ nos manda a la pagina de ayuda en la busqueda haciendo que nunca podamos ver el host de nuestra VPN.
Climax
Después de putear un rato porque no podía conectar el Lotus Notes y darme cuenta de que estaba pasando pude solucionarlo cambiando los DNS de mi computadora para que use los DNS servers de Google: 8.8.8.8 y 8.8.4.4. Otra alternativa válida es cambiar las metricas de las redes, para que primero vaya a la VPN y luego al ADSL pero la primer solución me pareció más limpia.
Así que ya saben, si tienen la desgracia de tener que conectarse a internet usando Telefónica Speedy y tienen que conectarse a una VPN tengan presente esto para evitar dolores de cabeza.
Alineando los planetas para JMX
Cada vez que tengo que testear un Apache Tomcat nuevo usando jconsole o jvisualvm me pasa lo mismo. A continuación: Lista bullet-proof Para hacer andar el JMX del Tomcat.
1- Agregar los siguientes parametros a la JVM del Tomcat
-Dcom.sun.management.jmxremote.port=7000
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
2- No tiene que haber inconsistencias en los hostname de la maquina. Es bastante comun que tirar el comando ‘hostname’ devuelvo algo totalmente distinto a lo que dice el /etc/hosts y el RMI es algo susceptible a esto. Ejemplo que funciona correctamente:
#hostname
maquina.dominio.com
#cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
10.1.3.24 maquina.dominio.com
Ahora al conectarnos via jconsole, jvisualvm o cualquier otro cliente JMX a 10.1.3.24:7000 no deberiamos tener problemas
Cambiando el password del MySql
Cambiando passwords olvidados en MySql.
1) iniciar mysqld_safe --skip-grant-tables
2) conectarse con mysql -user=root
3) mysql> update user set Password=PASSWORD('nuevo-password');
mysql> flush privileges;
mysql> exit;
4) killall mysqld_safe
Entrar usando el nuevo-password.
TCP Port Knocking!
Port Knocking (PK) es una forma bastante ingeniosa y cuestionablemente segura de establecer una comunicación entre dos hosts mediante puertos cerrados. Tambien puede decirse que es una forma de “seguridad por oscuridad” pero yo particularmente no comparto esa visión.
Imaginen esta situación: Queremos acceder a un lugar que tiene 65536 puertas en su fachada. Golpeamos una puerta para nos abran y poder entrar pero no recibimos respuesta. Lo mismo ocurre con cualquier puerta que golpée. Del lado de adentro hay un conserje con instrucciones precisas que le indican que:
“Vas a abrir la puerta número 22 unicamente si alguien golpea primero las puertas 12865, 53271, 14780, 6912, 37312 y 43976″
El conserje se queda todo el dia prestando atención a que puertas golpea la gente que quiere ingresar y en que secuencia lo hace. Solo abre la puerta 22 si alguién previamente toca en la 12865, 53271, 14780,…etc. Simplemente ignora a todas las personas que no toquen en estas puertas en la secuencia correcta.
La técnica de PortKnocking consiste exactamente en el ejemplo anterior pero en lugar de edificio tenemos un host, en lugar de puertas tenemos puertos tcp y en lugar de conserje hay un daemon escuchando los SYN enviados para iniciar una coneccion tcp encargado de manejar un firewall. Cuando estos SYN llegan a los puertos indicados, que el cliente deberia conocer de antemano, el daemon se encarga de bajar el firewall que previamente bloqueaba todas las entradas.
Este método no reemplaza ningún otro mecanismo de autentificación pero puede servir para confundir un poco más a los posibles atacantes. La implementación no podria ser más simple. Basta con un programa que vigile los logs del firewall y en el momento que detecte la combinación correcta de tcp SYNs crea una regla para permitir el paso a un determinado puerto desde la IP que origino la secuencia de SYNs. Del lado del cliente alcanza con un script que, armado de un programa tipo nc, automatice la secuencia de intentos de conexiones al host destino. Tiempo atras, en mis epocas de BOFH, habia hecho una implementacion en PERL muy minimalista que espero poder encontrar y compartirla acá.
Existen muchas implementaciones dando vueltas por internet, algunas más avanzadas que otras, pero todas mantienen la misma filosofía. Más información en www.portknocking.org
Los 7 pasos a subversion
svn sin tunneling ni cosas raras en CentOS:
1) # yum install subversion
2) crear un directorio donde guardar los repos (ie: /home/svn/repositories)
3) crear un usuario/grupo svn para ejecutar el server.
4) iniciar el servidor svn con svnserve --daemon --root=/home/svn/repositories
5) crear un repositorio con:
#cd /home/svn/repositories
#sudo svn svnadmin create miRepo
6) editar el archivo /home/svn/repositories/miRepo/conf/svnserve.conf agregando
[general]
password-db = usuarios
realm = miRealm
auth-access=write
7) editar el archivo /home/svn/repositories/miRepo/conf/usuarios agregando
[users]
miusuario = mipassword
miusuario2 = miotropassword
8 ) enjoy!