En algunas ocasiones necesitamos acceder a algún servicio o aplicación que usa un puerto diferente al que por defecto tenemos permitido.
Esta mañana en el trabajo me he encontrado con la siguiente situación. Deseaba agregar el repositorio UbuntuGis para instalar algunos paquetes del mismo (Grass y Quantum GIS entre otros), pero al añadirlo:
sudo add-apt-repository ppa:ubuntugis/ppa
Me he encontrado con el siguiente problema:
Executing: gpg –ignore-time-conflict –no-options –no-default-keyring –secret-keyring /etc/apt/secring.gpg –trustdb-name /etc/apt/trustdb.gpg –keyring /etc/apt/trusted.gpg –primary-keyring /etc/apt/trusted.gpg –keyserver keyserver.ubuntu.com –recv 6B827C12C2D425E227EDCA75089EBE08314DF160gpg: requesting key 314DF160 from hkp server keyserver.ubuntu.comgpgkeys: HTTP fetch error 7: couldn’t connect to hostgpg: no valid OpenPGP data found.gpg: Total number processed: 0Executing: gpg –ignore-time-conflict –no-options –no-default-keyring –secret-keyring /etc/apt/secring.gpg –trustdb-name /etc/apt/trustdb.gpg –keyring /etc/apt/trusted.gpg –primary-keyring /etc/apt/trusted.gpg –keyserver keyserver.ubuntu.com –recv 6B827C12C2D425E227EDCA75089EBE08314DF160gpg: requesting key 314DF160 from hkp server keyserver.ubuntu.comgpgkeys: HTTP fetch error 7: couldn’t connect to hostgpg: no valid OpenPGP data found.gpg: Total number processed: 0
Esto sucede porque existe un firewall (el de mi trabajo) y está capando el puerto 11371, el que usa el servidor de claves en la dirección: keyserver.ubuntu.com
Existen dos formas básicas de solucionarlo, la primera sería hablar con el departamento de informática para que no bloqueran por el puerto especificado, pero evidentemente esto es inviable y, sobre todo, lento. La segunda es usar el maravilloso SSH para crear un tunel sobre un servidor externo y evitar el firewall, usando nuestra máquina como servidor local y redireccionando todas las salidas sobre el puerto especificado, es bastante sencillo y nos saltaremos el cortafuegos gustosamente:
- Editamos el fichero /etc/hosts (como superusuario), en concreto la siguiente línea:
127.0.0.1 localhost keyserver.ubuntu.com
- Guardamos y teniendo en cuenta que disponemos un servidor externo con un servidor SSH y sin restricciones en cuanto a firewall se refiere, lanzamos SSH con un tunel sobre el puerto 11371 local y redireccionando la salida sobre la dirección especificada (keyserver.ubuntu.com) y el mismo puerto. Tan sencillo como la siguiente línea (en este caso estoy usando el servidor de mi universidad, y nombre_usuario el nombre de mi usuario en el servidor ts.uco.es):
ssh nombre_usuario@ts.uco.es -L 11371:keyserver.ubuntu.com:11371
- Nos autenticamos en el servidor y ya estamos preparados para agregar el repositorio, esta vez satisfactoriamente:
ahornero@asubuntu:~$ sudo add-apt-repository ppa:ubuntugis/ppa
[sudo] password for ahornero:
Executing: gpg –ignore-time-conflict –no-options –no-default-keyring –secret
keyring /etc/apt/secring.gpg –trustdb-name /etc/apt/trustdb.gpg –keyring
/etc/apt/trusted.gpg –primary-keyring /etc/apt/trusted.gpg –keyserver
keyserver.ubuntu.com –recv
6B827C12C2D425E227EDCA75089EBE08314DF160
gpg: requesting key 314DF160 from hkp server keyserver.ubuntu.com
gpg: key 314DF160: “Launchpad ubuntugis-stable” not changed
gpg: Total number processed: 1
gpg: unchanged: 1
¡Y listo!, el uso que hagáis de lo que os he explicado es vuestra responsabilidad, evidentemente se pueden hacer otras muchas cosas, pero lo que trato de mostraros aquí es una sencilla forma de evitar un cortafuegos para un uso concreto, en este caso agregar un repositorio.
¡Impresionante! Muy buena información. Muchas gracias.
Saludos.
Pingback: Bitacoras.com
Pingback: Tweets that mention [HowTo] Saltarse un firewall usando SSH | Linux Hispano -- Topsy.com
Un tutorial fantástico.
Gracias Alberto.
Esta bien, pequeño saltamontes, pero ¿que ocurre si desde tu trabajo tampoco puedes acceder al puerto 22 del ordenador externo?
No sufráis, que si vivís en un entorno corporativo con proxy fascista que solo abre la mano para los puertos 80, 443 y 21, sigue habiendo salvación. El ordenador de casa encendido y esperando cumplir vuestras órdenes. Mas información aquí..
http://crysol.org/es/node/42
http://crysol.org/es/node/1355
Muy muy interesante, ¡tomo nota!
Tengo una duda que no me ha quedado clara. Después de crear el tunel con el servidor con servicio SSH, ¿donde ejecutas la orden para agregar el repositorio? ¿en tu máquina del trabajo o en el servidor de la universidad?
Pingback: [HowTo] Saltarse un firewall usando SSH - Nagrados
Que yo sepa para usar el servidor de claves no es necesario abrir ningún puerto.
Yo los tengo todos cerrados y el comando add-apt-repository me funciona bien, a excepción de cuando el puñetero keyserver.ubuntu.com está caído o no disponible, lo cual es muy a menudo.
Así que he cambiado, en el fichero /usr/share/pyshared/softwareproperties/ppa.py, la siguiente línea:
#res = subprocess.call(
# ["apt-key", "adv", "--keyserver", "keyserver.ubuntu.com",
# "--recv", signing_key_fingerprint[0]])
res = subprocess.call(
["apt-key", "adv", "--keyserver", "wwwkeys.fr.pgp.net",
"--recv", signing_key_fingerprint[0]])
Así en lugar de usar el saturado servidor de claves de ubuntu, uso uno más cercano a mi país y que funciona muchísimo mejor. Hasta ahora no me ha fallado nunca.
Pingback: Crea tu primera página en HTML 5 | Linux Hispano
Perdón, puse el que no es, el servidor de claves que uso y que he comprobado que va bien y rápido es: “wwwkeys.de.pgp.net“.
@Fernando: Está claro, si no podemos salir por el puerto 22 la cosa se complica un poco, pero nada más lejos de la realidad. Muchos administradores de sistemas consideran que una red está protegida al restringir la comunicación por cierto puertos, y se equivocan. Muchas gracias por añadir este dato.
@Gon: Habría que hacerlo desde tu máquina local. Toda salida que se realice atendiendo a la dirección keyserver.ubuntu.com saldría se iría a localhost y saldría por la red de la universidad, al haber establecido ese tunel. Si tienes alguna otra duda coméntala.
@Simón: Básicamente el problema viene de la comunicación que se establece con esa URI, que no es a través de http, ni 443 ni 8080, si no por el puerto que indico en la entrada y que nos podemos encontrar capado en muchas redes.
Genial Alberto. El tema de “cerrar” puertos tiene más sentidos de fuera hacia dentro que de dentro hacia fuera como tú haces. Pero entiende que para el 99% de los casos es un método útil para tener una buena seguridad perimetral en la red del centro.
Excelente información “ahornero”, pero todavía tengo una duda y es la siguiente:
Segun entiendo existen dos maquinas en este diagrama:
1) La primer maquina esta en una red del trabajo( en este caso se llamara LOCAL ), donde imaginaremos que solo tiene abiertos estos puertos de salida “22,80,DNS” y por lo tanto no puede salir utilizando el puerto “11371″.
2) La segunda maquina esta en una red de casa( en este caso se llamara REMOTE ), donde tiene en ejecución un servidor SSH por el puerto 22 y no tiene restricciones de salida. Además es visible desde internet utilizando esta dirección “ts.uco.es”.
Entonces ejecutas el siguiente comando:
ssh nombre_usuario@ts.uco.es -L 11371:keyserver.ubuntu.com:11371
Mi duda es la siguiente, si se conecta con el servidor remoto utilizando SSH, las ordenes que se envíen atraves de esta “secure shell” se ejecutaran en la maquina REMOTE. Entonces el repositorio agregado, se agregara en la maquina remota y no el maquina LOCAL. ¿Es esto correcto?
¿Que es lo que permite “-L” en el comando ssh?
Soy un poco preguntón
Saludos!!
“Existen dos formas básicas de solucionarlo, la primera sería hablar con el departamento de informática para que no bloqueran por el puerto especificado, pero evidentemente esto es inviable y, sobre todo, lento.” Vaya opinión dejas caer sobre los departamentos de informática!! ¿Hablas de todos en general o de alguno en particular? No queda claro al leer el artículo.
“Muchos administradores de sistemas consideran que una red está protegida al restringir la comunicación por cierto puertos, y se equivocan.” Ah, ¿sí? A todas luces será mucho más seguro abrirlos todos, ¿no? ¿Puedes argumentar esa afirmación?
@Hugo buena pregunta, creo que más de un lector se la habrá planteado. Al realizarse un tunel en la máquina local y direccionar la salida sobre localhost no existe el problema que comentas, simplemente toda comunicación sobre el puerto especificado, en este caso el 11371 se tunela pero a efectos prácticos todos se hace en local. Es decir, da igual que la máquina remota corra otro sistema operativo, mientras tenga SSH con soporte de tunel y salida por ese puerto no es ningún problema.
Muchas gracias por tu pregunta, creo que así hemos aclarado un poco lo que algunos se preguntaban.
@un_tipo, en respuesta a tu primera pregunta no dejo caer nada sobre ningún departamento de informática en concreto, simplemente afirmo que es más lento ponerse en contacto con un departamento y pedirle algo (en este caso que te habran un puerto concreto para una máquina concreta) que poder hacerlo tu mismo en dos líneas en tu terminal.
En respuesta a tu segunda pregunta, está claro, muchos piensan que por que tengan más restricción en cuanto a puertos su red no es vulnerable, mientras que la mayoría de la información se sucede a través del puerto 80 y es concretamente donde más ataques se producen. Con esto lo que trato de decir es que proteger una red no es solo capar sus puertos, está claro que es una afirmación y se hace evidente que no tiene refutación alguna.
@Carazo exacto, y en tal caso no sugiero que la red esté mal consolidada, si no que simplemente muchos pueden pensar que una red está 100% protegida hacia el exterior por establecer restricciones sobre el acceso a determinados puertos. En este caso particular, en mi centro, no me hubiera sido posible ni siquiera escribir este post tan sencillo si no llega a ser porque tenemos el puerto SSH abierto hacía Internet, ya que en tal caso tendríamos que montar un proxy para salir y conectarnos por el puerto 80 (algo más engorroso) y que hubiera cambiado el nombre de esta entrada.
Curioso, aquí parece que os han copiado:
http://www.tuxapuntes.com/drupal/node/1860
por lo menos os podrían haber citado
Si les interesa un poquitín más de túneles con SSH, miren:
http://wiki.debian.org/AccesoRemotoSSH
Lo hice hace años, pero sigue vigente.
Saludos.
Muy bien “ahornero”. Gracias por tu respuesta
Bueno, si fue copiado si tenia que haber sido citado, pero, lo interesante es que se forme la comunidad, que se plantean dudas y se respondan, eso quiere decir que “ahornero” si sabe del tema y quiere compartir ese conocimiento!!!
Saludos!!
Cae de maduro que (por lo general) la idea es proteger la red interna de las del exterior, eso implica entre muchas otras cosas, cerrar bastantes puertos del firewall, que como dice ahornero es solo un paso más a realizar con el fin de proteger nuestra red (más no el único), sin embargo, respecto de las restricciones de los usuarios internos, normalmente se presupone que el tráfico interno de nuestra red y que es originado por nuestros usuarios (y que ellos mismos inclusive) son “confiables”, sería totalmente inútil intentar securizar una red en donde nuestras mayores amenazas se encuentran dentro de la misma xD
@Rafael del Castillo: Rafael, gracias por avisarnos. Abajo viene un “Fuente: linuxhispano.net” pero bien es cierto que podrían haberlo destacado más.
De todas formas parece que la comunidad sabe que es un mero copy&paste y ni siquiera comentan.
Pingback: Saltarse un cortafuegos usando SSH
perdoname pero en tu ejemplo, una vez que usamos la opción port forwarding de ssh, no sería: ppa:localhost/ppa ??
me falto el saludos..
Saludos.
Santi.
Interesante articulo, sobre un uso de ssh que no muchos conocen.
Me resulto simpático esto: “… pero evidentemente esto es inviable y, sobre todo, lento.”
si es inviable, como puede ser lento ?
@santi: No, para eso hemos editado el fichero host.
@Omar: Muchas gracias por la aportación. Y sí, hay cosas que en muchos años, por su buen diseño y funcionalidad, no van a cambiar.
Pingback: Linux-OS » Saltarse un firewall usando SSH
Super! Genial web
Pingback: Google Chrome con la barra de menú tipo MAC | Linux Hispano
Pingback: Google Chrome con la barra de menú tipo MAC | Superlinux