[opensuse-es] sabeis que es esto?
hola me he encontrado en mi pc esto: ssh -R 19800:localhost:22 root@IP (esta ip es una ip publica) sabéis que se pretende con este comando que he encontrado en el history de un usuario? gracias -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Sun, 13 Feb 2011 18:58:09 +0100, koxkorrita escribió:
me he encontrado en mi pc esto:
ssh -R 19800:localhost:22 root@IP (esta ip es una ip publica)
sabéis que se pretende con este comando que he encontrado en el history de un usuario?
Pues yo diría (leyendo el manual de ssh) que está intentando reenviar el tráfico del puerto 22 al puerto 19800 (supongo que para desviar la atención, ya que el puerto 22 estará monitorizado) para intentar establecer una sesión como root en la máquina "IP". Mira a ver "quién es" esa IP pública a la que quería conectar. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2011-02-13 a las 18:58 +0100, koxkorrita escribió:
sabéis que se pretende con este comando que he encontrado en el history de un usuario?
En el manual lo cuenta, pero no lo entiendo. - -- Saludos Carlos E. R. (desde 11.2 x86_64 "Emerald" en Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAk1YeK8ACgkQtTMYHG2NR9UvqQCglUhfH/ivJNVhRIFllvgW3PJj o4cAnRjB2UgvxB163rJ2dKXuPjnnoeCd =pam8 -----END PGP SIGNATURE-----
On 02/14/2011 01:34 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2011-02-13 a las 18:58 +0100, koxkorrita escribió:
sabéis que se pretende con este comando que he encontrado en el history de un usuario?
En el manual lo cuenta, pero no lo entiendo.
Te están haciendo un túnel a través de ssh, un port forwarding. Mira la ip y el usuario, porque te están abriendo comunicaciones hacia el puerto 19800 de tu máquina (ojo, hacia y no desde ya que esa sería la opción -L del comando ssh). Normalmente, este tipo de túneles se hacen para "saltarse" dispositivos, ya sea para algo lícito o ilícito. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2011-02-14 a las 08:59 +0100, carlopmart escribió:
Te están haciendo un túnel a través de ssh, un port forwarding. Mira la ip y el usuario, porque te están abriendo comunicaciones hacia el puerto 19800 de tu máquina (ojo, hacia y no desde ya que esa sería la opción -L del comando ssh).
Algo de eso entendí, pero como no pone un ejemplo es dificil de entender. Una conexión hacia tí, con el ssh cliente... ¿Pero quien se conecta, y quien/que hace de servidor?
Normalmente, este tipo de túneles se hacen para "saltarse" dispositivos, ya sea para algo lícito o ilícito.
¿Tienes ejemplos? ¿Enlaces? - -- Saludos Carlos E. R. (desde 11.2 x86_64 "Emerald" en Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAk1Y9y4ACgkQtTMYHG2NR9U9nACdHov2hhLGQaAkrFZ+/2194auw ZmoAn0+fSLOvEHDjuFaXt7Wn63swq8LH =N61w -----END PGP SIGNATURE-----
On 02/14/2011 10:34 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2011-02-14 a las 08:59 +0100, carlopmart escribió:
Te están haciendo un túnel a través de ssh, un port forwarding. Mira la ip y el usuario, porque te están abriendo comunicaciones hacia el puerto 19800 de tu máquina (ojo, hacia y no desde ya que esa sería la opción -L del comando ssh).
Algo de eso entendí, pero como no pone un ejemplo es dificil de entender. Una conexión hacia tí, con el ssh cliente... ¿Pero quien se conecta, y quien/que hace de servidor?
Se conecta el servidor/máquina de la ip pública hacia la máquina con el puerto 19800. Es francamente sospechoso a menos que koxkorrita sepa quien es esa IP pública, debería ponerse a mirar de inmediato.
Normalmente, este tipo de túneles se hacen para "saltarse" dispositivos, ya sea para algo lícito o ilícito.
¿Tienes ejemplos? ¿Enlaces?
Basta con que pongas en Google "tunneling via ssh" o "tunnels ssh" ... Vereis múltiples ejemplos de "gamberradas" que se pueden hacer ... Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 02/14/2011 10:40 AM, carlopmart wrote:
On 02/14/2011 10:34 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2011-02-14 a las 08:59 +0100, carlopmart escribió:
Te están haciendo un túnel a través de ssh, un port forwarding. Mira la ip y el usuario, porque te están abriendo comunicaciones hacia el puerto 19800 de tu máquina (ojo, hacia y no desde ya que esa sería la opción -L del comando ssh).
Algo de eso entendí, pero como no pone un ejemplo es dificil de entender. Una conexión hacia tí, con el ssh cliente... ¿Pero quien se conecta, y quien/que hace de servidor?
Se conecta el servidor/máquina de la ip pública hacia la máquina con el puerto 19800.
Es francamente sospechoso a menos que koxkorrita sepa quien es esa IP pública, debería ponerse a mirar de inmediato.
Aquí teneis un ejemplo explicadito de lo que le está pasando a koxkorrita: http://www.brandonhutchinson.com/ssh_tunnelling.html En "reverse tunnel" ... -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Mon, 14 Feb 2011 10:51:38 +0100, carlopmart escribió:
Aquí teneis un ejemplo explicadito de lo que le está pasando a koxkorrita:
http://www.brandonhutchinson.com/ssh_tunnelling.html
En "reverse tunnel" ...
Entonces es más o menos lo que pensaba pero al revés, el mapeo del puerto es "de entrada" no "de salida". Después de leer el ejemplo de la página, si el objetivo es mantener una conexión abierta con el host remoto, seguramente será un equipo al que tenga acceso porque para poder ejecutar el túnel necesita "colaboración" de la otra parte. Si se tratara de algún tipo de acceso no autorizado donde se pretendiera usar al anfitrión como "trampolín" estaría intentando ejecutar ataques de diccionario sobre el servidor ssh remoto y por lo que vemos intenta conectar directamente como root. Pero no deja de ser peligroso si pretende sacar datos de la empresa usando este canal :-/ Ahora bien, y volviendo a la página de arriba, hay algo que no entiendo... ¿cómo se puede establecer la conexión desde el equipo de casa si el cortafuegos de la empresa tiene el puerto 22 bloqueado (las entradas) y se supone que el resto de puertos (inclusive el 2048) están cerrados, que es lo normal cuando se usa NAT? :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 02/14/2011 01:38 PM, Camaleón wrote:
Si se tratara de algún tipo de acceso no autorizado donde se pretendiera usar al anfitrión como "trampolín" estaría intentando ejecutar ataques de diccionario sobre el servidor ssh remoto y por lo que vemos intenta conectar directamente como root.
Pero no deja de ser peligroso si pretende sacar datos de la empresa usando este canal :-/
Es que ese es el riesgo real y lo que demuestra lo potente que pude llegar a ser ssh si es utilizado por "los amigos de lo ajeno". No se trata de hacer ni un ataque de diccionario ni nada por el estilo. Normalmente en un "ataque" así (aunque yo no lo definiría como tal sino más bien como "pedazo error del administrador de turno") el principal motivo es el de mover información (bien extrayéndola o bien insertándola, aunque caben más posibilidades por supuesto: propagación de virus, etc).
Ahora bien, y volviendo a la página de arriba, hay algo que no entiendo... ¿cómo se puede establecer la conexión desde el equipo de casa si el cortafuegos de la empresa tiene el puerto 22 bloqueado (las entradas) y se supone que el resto de puertos (inclusive el 2048) están cerrados, que es lo normal cuando se usa NAT? :-?
Saludos,
A ver si consigo explicarlo. Estamos haciendo un tunel reverso. Es decir la forma habitual de hacerlo es desde tú máquina hacia una máquina externa. El túnel reverso es exactamente al revés: que una máquina externa pueda acceder a una máquina interna que no es alcanzable a través de una ip pública. Por lo tanto: supongamos que la máquina A es la máquina interna y la máquina B es la externa. También se ha de tener en cuenta que la máquina A tiene salida hacia Internet a través del puerto ssh (y si el administrador de turno es un pelín listo, no debería disponer de ese acceso). Una vez dadas estas premisas procedamos al "ataque" en sí. Veamos: Comando: "ssh -N -R 25555:localhost:22 usuario@maquinaB" ¿Que se consigue con esto? se consigue abrir un túnel permanente desde la máquina A hacia la máquina B (siempre y cuando la shell o el proceso ssh de la máquina A no sea "matado". La opción para que corra en background es "-f" si no recuerdo mal). De tal forma que cuando tu ejecutas desde la máquina B (la externa) "ssh -p 25555 localhost" serás redireccionado hacia la máquina A a través del túnel ssh (miradlo como si fuese un proxy). ¿Y eso porque? Porque la mñaquina A tiene abierto un socket a la escucha con la ip pública real del device que atraviesa, bien un router y/o firewall y eso permite la conectividad. Ni el firewall ni el router actuarán ejecutando un bloqueo ya que en sus tablas de estado de conexiones, eso es una conexión legítima. Ahora bien: si disponemos de un firewall mínimamente listo (y suponiendo que debemos permitir conexiones ssh) podríamos actuar parcialmente contra esa conexión. Con un IDS o IPS detectaríamos el "bujero" de seguridad. Pensad una cosa: es muy común utilizar túneles ssh para saltarse dispositivos de seguridad tipo firewalls. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Mon, 14 Feb 2011 14:04:47 +0100, carlopmart escribió:
On 02/14/2011 01:38 PM, Camaleón wrote:
Ahora bien, y volviendo a la página de arriba, hay algo que no entiendo... ¿cómo se puede establecer la conexión desde el equipo de casa si el cortafuegos de la empresa tiene el puerto 22 bloqueado (las entradas) y se supone que el resto de puertos (inclusive el 2048) están cerrados, que es lo normal cuando se usa NAT? :-?
(...)
Una vez dadas estas premisas procedamos al "ataque" en sí. Veamos:
Comando: "ssh -N -R 25555:localhost:22 usuario@maquinaB"
¿Que se consigue con esto? se consigue abrir un túnel permanente desde la máquina A hacia la máquina B (siempre y cuando la shell o el proceso ssh de la máquina A no sea "matado". La opción para que corra en background es "-f" si no recuerdo mal). De tal forma que cuando tu ejecutas desde la máquina B (la externa) "ssh -p 25555 localhost" serás redireccionado hacia la máquina A a través del túnel ssh (miradlo como si fuese un proxy). ¿Y eso porque? Porque la mñaquina A tiene abierto un socket a la escucha con la ip pública real del device que atraviesa, bien un router y/o firewall y eso permite la conectividad. Ni el firewall ni el router actuarán ejecutando un bloqueo ya que en sus tablas de estado de conexiones, eso es una conexión legítima.
Imagina que tú eres un router con todos los puertos de entrada cerrados y en la red interna tienes a un "cachondo" con un túnel inverso creado. Te viene una petición remota de acceso al puerto "25555" ¿por qué no la rechazas? Una máquina local puede tener un puerto "local" abierto pero si se quiere acceder desde fuera tiene que pasar por el router/firewall. ¿Qué hace que el router/firewall se vuelva "loco" y reconozca al enemigo como amigo? ¿Sólo por el hecho de que se haya creado una conexión desde dentro tiene prioridad y le da barra libre? Pues vaya con el SPI... ¿y eso es así para todos los cortafuegos/routers? >:-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 02/14/2011 02:25 PM, Camaleón wrote:
El Mon, 14 Feb 2011 14:04:47 +0100, carlopmart escribió:
On 02/14/2011 01:38 PM, Camaleón wrote:
Ahora bien, y volviendo a la página de arriba, hay algo que no entiendo... ¿cómo se puede establecer la conexión desde el equipo de casa si el cortafuegos de la empresa tiene el puerto 22 bloqueado (las entradas) y se supone que el resto de puertos (inclusive el 2048) están cerrados, que es lo normal cuando se usa NAT? :-?
(...)
Una vez dadas estas premisas procedamos al "ataque" en sí. Veamos:
Comando: "ssh -N -R 25555:localhost:22 usuario@maquinaB"
¿Que se consigue con esto? se consigue abrir un túnel permanente desde la máquina A hacia la máquina B (siempre y cuando la shell o el proceso ssh de la máquina A no sea "matado". La opción para que corra en background es "-f" si no recuerdo mal). De tal forma que cuando tu ejecutas desde la máquina B (la externa) "ssh -p 25555 localhost" serás redireccionado hacia la máquina A a través del túnel ssh (miradlo como si fuese un proxy). ¿Y eso porque? Porque la mñaquina A tiene abierto un socket a la escucha con la ip pública real del device que atraviesa, bien un router y/o firewall y eso permite la conectividad. Ni el firewall ni el router actuarán ejecutando un bloqueo ya que en sus tablas de estado de conexiones, eso es una conexión legítima.
Imagina que tú eres un router con todos los puertos de entrada cerrados y en la red interna tienes a un "cachondo" con un túnel inverso creado. Te viene una petición remota de acceso al puerto "25555" ¿por qué no la rechazas?
Mecc .. Error. Es que no te viene una petición al puerto 25555 desde el exterior. La petición al puerto 25555 viene "dentro del túnel ssh" que ha establecido la máquina A hacia la máquina B. Una máquina local puede tener un puerto "local" abierto pero si
se quiere acceder desde fuera tiene que pasar por el router/firewall.
Cierto. Pero no es así en este caso. La petición viene por dentro del túnel ssh.
¿Qué hace que el router/firewall se vuelva "loco" y reconozca al enemigo como amigo? ¿Sólo por el hecho de que se haya creado una conexión desde dentro tiene prioridad y le da barra libre? Pues vaya con el SPI... ¿y eso es así para todos los cortafuegos/routers?>:-?
Es que para el firewall y/o router es una conexión legítima. En las tablas de conexión del firewall aparece algo tal que así: Creation time Sender Src Addr Dst Addr Service IP protocol Src Port Dst Port State 2011-02-14 08:48:16 deagol 172.17.47.30 172.25.50.13 SSH TCP 57894 3020 TCP established Esa conxión es un túnel ssh. Como ves no existe el puerto 25555, porque la conexión hacia ese puerto se hará a través de la conexión preestablecida por ssh. Y eso para él es legítimo porque tiene una regla, por ejemplo, que dice: Source: Maquinas internas Destino: Any puerto: any (o ssh). El error es del administrador que permite esa conexión (no es un error si "debe" permitirla). -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Mon, 14 Feb 2011 14:36:37 +0100, carlopmart escribió:
On 02/14/2011 02:25 PM, Camaleón wrote:
Imagina que tú eres un router con todos los puertos de entrada cerrados y en la red interna tienes a un "cachondo" con un túnel inverso creado. Te viene una petición remota de acceso al puerto "25555" ¿por qué no la rechazas?
Mecc .. Error. Es que no te viene una petición al puerto 25555 desde el exterior. La petición al puerto 25555 viene "dentro del túnel ssh" que ha establecido la máquina A hacia la máquina B.
En el ejemplo de la página anterior, el cliente remoto (casa) ejecutaba "ssh -p 2048" para conectar al equipo de la oficina :-?
Una máquina local puede tener un puerto "local" abierto pero si se quiere acceder desde fuera tiene que pasar por el router/firewall.
Cierto. Pero no es así en este caso. La petición viene por dentro del túnel ssh.
Entonces no entiendo el ejemplo de la página web. Es el equipo "de fuera" el que conecta al equipo de la empresa, no al revés.
¿Qué hace que el router/firewall se vuelva "loco" y reconozca al enemigo como amigo? ¿Sólo por el hecho de que se haya creado una conexión desde dentro tiene prioridad y le da barra libre? Pues vaya con el SPI... ¿y eso es así para todos los cortafuegos/routers?>:-?
Es que para el firewall y/o router es una conexión legítima. En las tablas de conexión del firewall aparece algo tal que así:
Creation time Sender Src Addr Dst Addr Service IP protocol Src Port Dst Port State 2011-02-14 08:48:16 deagol 172.17.47.30 172.25.50.13 SSH TCP 57894 3020 TCP established
Esa conxión es un túnel ssh. Como ves no existe el puerto 25555, porque la conexión hacia ese puerto se hará a través de la conexión preestablecida por ssh.
Y eso para él es legítimo porque tiene una regla, por ejemplo, que dice:
Source: Maquinas internas Destino: Any puerto: any (o ssh).
El error es del administrador que permite esa conexión (no es un error si "debe" permitirla).
Vale, ¿pero como estableces una conexión desde un equipo remoto a esa conexión? Entiendo que desde dentro se pueda hacer (siempre y cuando se permita el tráfico saliente al puerto 22) la duda es cómo permite una conexión externa. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 02/14/2011 03:09 PM, Camaleón wrote:
Mecc .. Error. Es que no te viene una petición al puerto 25555 desde el exterior. La petición al puerto 25555 viene "dentro del túnel ssh" que ha establecido la máquina A hacia la máquina B.
En el ejemplo de la página anterior, el cliente remoto (casa) ejecutaba "ssh -p 2048" para conectar al equipo de la oficina :-?
Si pero esa petición va por el tunel ssh. Si te fijas hace "ssh -p 2048 localhost". Ataca localhost y no a la ip pública.
Una máquina local puede tener un puerto "local" abierto pero si se quiere acceder desde fuera tiene que pasar por el router/firewall.
Cierto. Pero no es así en este caso. La petición viene por dentro del túnel ssh.
Entonces no entiendo el ejemplo de la página web. Es el equipo "de fuera" el que conecta al equipo de la empresa, no al revés.
Si pero la diferencia es que conecta a través de una conexión pre-establecida (en este caso ssh) y no a través de una nueva conexión. Esa es la diferencia.
¿Qué hace que el router/firewall se vuelva "loco" y reconozca al enemigo como amigo? ¿Sólo por el hecho de que se haya creado una conexión desde dentro tiene prioridad y le da barra libre? Pues vaya con el SPI... ¿y eso es así para todos los cortafuegos/routers?>:-?
Es que para el firewall y/o router es una conexión legítima. En las tablas de conexión del firewall aparece algo tal que así:
Creation time Sender Src Addr Dst Addr Service IP protocol Src Port Dst Port State 2011-02-14 08:48:16 deagol 172.17.47.30 172.25.50.13 SSH TCP 57894 3020 TCP established
Esa conxión es un túnel ssh. Como ves no existe el puerto 25555, porque la conexión hacia ese puerto se hará a través de la conexión preestablecida por ssh.
Y eso para él es legítimo porque tiene una regla, por ejemplo, que dice:
Source: Maquinas internas Destino: Any puerto: any (o ssh).
El error es del administrador que permite esa conexión (no es un error si "debe" permitirla).
Vale, ¿pero como estableces una conexión desde un equipo remoto a esa conexión? Entiendo que desde dentro se pueda hacer (siempre y cuando se permita el tráfico saliente al puerto 22) la duda es cómo permite una conexión externa.
Es que donde te estás equivocando es en lo de pensar en "la duda es cómo permite una conexión externa".No es una conexión externa. La conexión se produce dentro de otra conexión ya establecida. Es muy sencillo. Como la máquina A (máquina interna) tiene una conexión abierta hacia la máquina B (maquina externa) y el firewall la permite, lo que tu haces es aprovechar esa conexión para encapsular otra dentro de ella que recorre el camino inverso. No es vista como una conexión inversa. Puedes hacer la prueba entre dos máquina de una lan interna (sin necesidad de que haya un firewall o router de por medio). Funcionará igual. Por ejemplo: Desde la máquina A: lanza un "ssh -N -R 25555:localhost:22 usuario@maquinaB". Te pedirá el password a menos que uses intercambio de claves. Desde la máquina B: lanza un "ssh -p 25555 localhost" y voilà, estarás dentro de la máquina A. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Mon, 14 Feb 2011 15:17:51 +0100, carlopmart escribió:
On 02/14/2011 03:09 PM, Camaleón wrote:
Mecc .. Error. Es que no te viene una petición al puerto 25555 desde el exterior. La petición al puerto 25555 viene "dentro del túnel ssh" que ha establecido la máquina A hacia la máquina B.
En el ejemplo de la página anterior, el cliente remoto (casa) ejecutaba "ssh -p 2048" para conectar al equipo de la oficina :-?
Si pero esa petición va por el tunel ssh. Si te fijas hace "ssh -p 2048 localhost". Ataca localhost y no a la ip pública.
Ahhh, _eso_ es lo que se me había pasado. ¿Y cómo "carallo" se establece la conexión con el equipo externo conectándose consigo mismo? Entonces... entonces (espera que ya lo voy pillando) es el equipo de la oficina el que realmente "comanda" la conexión, no el de casa, el de casa sólo está "a la espera".
Entonces no entiendo el ejemplo de la página web. Es el equipo "de fuera" el que conecta al equipo de la empresa, no al revés.
Si pero la diferencia es que conecta a través de una conexión pre-establecida (en este caso ssh) y no a través de una nueva conexión. Esa es la diferencia.
Ahora sí :-) (...)
El error es del administrador que permite esa conexión (no es un error si "debe" permitirla).
Vale, ¿pero como estableces una conexión desde un equipo remoto a esa conexión? Entiendo que desde dentro se pueda hacer (siempre y cuando se permita el tráfico saliente al puerto 22) la duda es cómo permite una conexión externa.
Es que donde te estás equivocando es en lo de pensar en "la duda es cómo permite una conexión externa".No es una conexión externa. La conexión se produce dentro de otra conexión ya establecida.
Pillado. Vale, eso tiene más lógica.
Es muy sencillo. Como la máquina A (máquina interna) tiene una conexión abierta hacia la máquina B (maquina externa) y el firewall la permite, lo que tu haces es aprovechar esa conexión para encapsular otra dentro de ella que recorre el camino inverso. No es vista como una conexión inversa.
Correcto, sí, eso sí lo tenía como "posible" dentro de mis esquemas. Lo que no entendía era cómo se podía conectar en remoto el equipo de casa, pero no es el de casa el que conecta sino el de dentro (el de casa está "durmiente" a la espera de la "llamada" del otro).
Puedes hacer la prueba entre dos máquina de una lan interna (sin necesidad de que haya un firewall o router de por medio). Funcionará igual. Por ejemplo:
Desde la máquina A: lanza un "ssh -N -R 25555:localhost:22 usuario@maquinaB". Te pedirá el password a menos que uses intercambio de claves.
Desde la máquina B: lanza un "ssh -p 25555 localhost" y voilà, estarás dentro de la máquina A.
Okis... ahora que esto está entendido vayamos un poco más allá. ¿Un túnel ssh inverso sólo sirve para saltarse el cortafuegos interno o tiene alguna otra utilidad que no la proporcione una conexión ssh directa? Porque si no la tiene, cualquier conexión generada por ese medio sería "de por sí" sospechosa. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 02/14/2011 04:28 PM, Camaleón wrote:
dentro de la máquina A.
Okis... ahora que esto está entendido vayamos un poco más allá.
¿Un túnel ssh inverso sólo sirve para saltarse el cortafuegos interno o tiene alguna otra utilidad que no la proporcione una conexión ssh directa? Porque si no la tiene, cualquier conexión generada por ese medio sería "de por sí" sospechosa.
Saludos,
Bueno a lo demás no respondo ya porque creo que ya lo has entendido. Sobre si los túneles ssh solo sirven para saltarse a los firewalls: sirven para saltarse cualquier tipo de dispositivo intermedio que te impida la comunicación entre una máquina origen y una máquina destino. Por ejemplo: firewalls, proxys, routers, etc... Y también para cifrar las comuncicaciones entre dos máquinas, vamos una VPN baratita. Y sí, es recomendable estar al tanto en detectar este tipo de comunicaciones, porque la mayoria de las veces no tienen un origen lícito. Por ejemplo, en mi empresa ver ese tip ode conexiones abiertas desde las máquinas de los administradores puede ser "normal". Si la veo desde la máquina de un desarrollador, secretaria, etc (y me ha pasado), "monto el pollo" :)) No es aconsejable infravalorar lo que puede llegar a hacer un usuario con un sistema en sus manos. Como decimos nosotros: "Aquí hasta el más tonto hace piruletas con chocolate". Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2011-02-14 a las 14:36 +0100, carlopmart escribió:
Mecc .. Error. Es que no te viene una petición al puerto 25555 desde el exterior. La petición al puerto 25555 viene "dentro del túnel ssh" que ha establecido la máquina A hacia la máquina B.
Que interesante... o sea, consigues una conexión desde fuera hacia una maquina interior. Tiene interés porque no configuras el router. Y puede ser perfectamente legítimo: la maquina externa puede ser por ejemplo de una empresa a la que le has contratado el soporte de algo para lo que necesita conectarse. O puede hacerlo alguien para trabajar desde casa. No necesariamente serían malvadas las intenciones - pero en ese caso debería avisar. Lo que indica esto es que los usuarios de una máquina linux han de ser de confianza. Y prohibirles el ssh pues quizas no sea posible por ser parte de su trabajo conectarse a otras máquinas dentro o fuera, y no lo van a hacer por telnet.
El error es del administrador que permite esa conexión (no es un error si "debe" permitirla).
Es que yo no veo claro como pueda evitar estas conexiones. Caray... la de cosas que ignoro. :-} - -- Saludos Carlos E. R. (desde 11.2 x86_64 "Emerald" en Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAk1ZOOcACgkQtTMYHG2NR9UdngCfTF7d4V+5Gl/beLZLFD/jM44Y 6oQAn2RESvaEqxH5IaU3XebKm7LOerz+ =H/dI -----END PGP SIGNATURE-----
On 02/14/2011 03:14 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2011-02-14 a las 14:36 +0100, carlopmart escribió:
Mecc .. Error. Es que no te viene una petición al puerto 25555 desde el exterior. La petición al puerto 25555 viene "dentro del túnel ssh" que ha establecido la máquina A hacia la máquina B.
Que interesante... o sea, consigues una conexión desde fuera hacia una maquina interior. Tiene interés porque no configuras el router. Y puede ser perfectamente legítimo: la maquina externa puede ser por ejemplo de una empresa a la que le has contratado el soporte de algo para lo que necesita conectarse. O puede hacerlo alguien para trabajar desde casa. No necesariamente serían malvadas las intenciones - pero en ese caso debería avisar.
Exactamente. No tienen porqué ser conexiones ilegítimas. Pueden ser legítimas perfectamente. Pero si nos remontamos al thread abierto, si el administrador del servidor desconoce esto, mal asunto.
Lo que indica esto es que los usuarios de una máquina linux han de ser de confianza. Y prohibirles el ssh pues quizas no sea posible por ser parte de su trabajo conectarse a otras máquinas dentro o fuera, y no lo van a hacer por telnet.
El error es del administrador que permite esa conexión (no es un error si "debe" permitirla).
Es que yo no veo claro como pueda evitar estas conexiones.
Caray... la de cosas que ignoro. :-}
Fácil: denegándolas. A ver por defecto, ¿tu necesitas que tus usuarios salgan hacia internet a través del puerto ssh? No lo creo. Por lo tanto, ¿por qué lo vas a tener abierto por defecto?. Cierra todo lo que no necesites utilizar. Ahora bien, supongamos que tienes a un usuario que precisa una conexión ssh hacia el exterior, sí o sí. Puedes insertar reglas basadas en tiempo. Por ejemplo, le puedes decir: tienes 1 hora hasta que el firewall te cierre la conexión. Aunque también me puedes decir: ¿pero eso no evita que se produzca una fuga de inforamción, por ejemplo, no? Pues no. Si quieres controlar más deberás tener bien HIDS o IDS o ambos a la vez. Por ejemplo OSSEC (http://www.ossec.net). Este va perfecto para detectar cosas como estas y de fácil mantenimiento e instalación. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 02/14/2011 03:24 PM, carlopmart wrote:
El 2011-02-14 a las 14:36 +0100, carlopmart escribió:
Mecc .. Error. Es que no te viene una petición al puerto 25555 desde el exterior. La petición al puerto 25555 viene "dentro del túnel ssh" que ha establecido la máquina A hacia la máquina B.
Que interesante... o sea, consigues una conexión desde fuera hacia una maquina interior. Tiene interés porque no configuras el router. Y puede ser perfectamente legítimo: la maquina externa puede ser por ejemplo de una empresa a la que le has contratado el soporte de algo para lo que necesita conectarse. O puede hacerlo alguien para trabajar desde casa. No necesariamente serían malvadas las intenciones - pero en ese caso debería avisar.
Y algo todavía más interesnate: http://biowiki.org/MountingNFSThroughSSHTunnel. Montar unidades NFS a través de túneles SSH. Por cierto, el daemon sshd debe tener configurada la opcion de "AllowTcpForwarding" a yes, si no el invento no funciona. Es otra opción para evitar este tipo de cosas. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
osea para evitar esto es una recomentación pones este valor a no verdad? Gracias -----Mensaje original----- De: carlopmart [mailto:carlopmart@gmail.com] Enviado el: lunes, 14 de febrero de 2011 15:45 Para: opensuse-es@opensuse.org Asunto: Re: [opensuse-es] Re: sabeis que es esto? On 02/14/2011 03:24 PM, carlopmart wrote:
El 2011-02-14 a las 14:36 +0100, carlopmart escribió:
Mecc .. Error. Es que no te viene una petición al puerto 25555 desde el exterior. La petición al puerto 25555 viene "dentro del túnel ssh" que ha establecido la máquina A hacia la máquina B.
Que interesante... o sea, consigues una conexión desde fuera hacia una maquina interior. Tiene interés porque no configuras el router. Y puede ser perfectamente legítimo: la maquina externa puede ser por ejemplo de una empresa a la que le has contratado el soporte de algo para lo que necesita conectarse. O puede hacerlo alguien para trabajar desde casa. No necesariamente serían malvadas las intenciones - pero en ese caso debería avisar.
Y algo todavía más interesnate: http://biowiki.org/MountingNFSThroughSSHTunnel. Montar unidades NFS a través de túneles SSH. Por cierto, el daemon sshd debe tener configurada la opcion de "AllowTcpForwarding" a yes, si no el invento no funciona. Es otra opción para evitar este tipo de cosas. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2011-02-14 a las 21:51 +0100, koxkorrita escribió:
osea para evitar esto es una recomentación pones este valor a no verdad?
Si no recuerdo mal eso también rompe cosas, como poder abrir aplicaciones X remotamente via ssh. - -- Saludos Carlos E. R. (desde 11.2 x86_64 "Emerald" en Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAk1ZouAACgkQtTMYHG2NR9Vd3QCeKBOkz1D6sJVXWaSXKKtF08Wl QhIAn2Sb7X8lm47HgZiOQm2UQYi7YfNO =Iv7u -----END PGP SIGNATURE-----
On 02/14/2011 10:47 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2011-02-14 a las 21:51 +0100, koxkorrita escribió:
osea para evitar esto es una recomentación pones este valor a no verdad?
Si no recuerdo mal eso también rompe cosas, como poder abrir aplicaciones X remotamente via ssh.
Activar ese parámetro a no, romperá todo lo que tenga que ver con forward de paquetes tcp, entre otras cosas lo que comenta Carlos. De todas formas puedes mirar de comprobar el uso que le das a ssh para ver si funcionaría en tu sistema. Aunque tienes otra alterntiva. Configurar otro daemon sshd para usuarios poniendo variables ssh personalizadas para ellos. Mírate la página man de ssh. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2011-02-15 a las 09:48 +0100, carlopmart escribió:
Aunque tienes otra alterntiva. Configurar otro daemon sshd para usuarios poniendo variables ssh personalizadas para ellos. Mírate la página man de ssh.
Claro, pero es que los usuarios también pueden tener necesidad de usar esas cosas. Todo depende de la confianza que tengamos en los usuarios... - -- Saludos Carlos E. R. (desde 11.2 x86_64 "Emerald" en Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAk1ajM4ACgkQtTMYHG2NR9VqXACeLuK5YDQE0XB+/JDSPgZ8tXhc IgAAoIdIeb14srPjfWErAoBEVmNGvz59 =WcyY -----END PGP SIGNATURE-----
El Tue, 15 Feb 2011 09:48:48 +0100, carlopmart escribió:
Activar ese parámetro a no, romperá todo lo que tenga que ver con forward de paquetes tcp, entre otras cosas lo que comenta Carlos.
De todas formas puedes mirar de comprobar el uso que le das a ssh para ver si funcionaría en tu sistema.
Aunque tienes otra alterntiva. Configurar otro daemon sshd para usuarios poniendo variables ssh personalizadas para ellos. Mírate la página man de ssh.
El manual (man sshd_config) dice: *** AllowTcpForwarding Specifies whether TCP forwarding is permitted. The default is ''yes''. Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders. *** No parece muy alentador, salvo que se utilice para un entorno enjaulado. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 02/15/2011 03:55 PM, Camaleón wrote:
El Tue, 15 Feb 2011 09:48:48 +0100, carlopmart escribió:
Activar ese parámetro a no, romperá todo lo que tenga que ver con forward de paquetes tcp, entre otras cosas lo que comenta Carlos.
De todas formas puedes mirar de comprobar el uso que le das a ssh para ver si funcionaría en tu sistema.
Aunque tienes otra alterntiva. Configurar otro daemon sshd para usuarios poniendo variables ssh personalizadas para ellos. Mírate la página man de ssh.
El manual (man sshd_config) dice:
*** AllowTcpForwarding Specifies whether TCP forwarding is permitted. The default is ''yes''. Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders. ***
No parece muy alentador, salvo que se utilice para un entorno enjaulado.
Saludos,
Es lo que se suele hacer cuando se precisa restringir comandos "peligrosos" como el ssh: se enjaulan los entornos. Personalmente, el mejor SO para entregar jaulas a usuarios es FreeBSD, funciona perfecto para esto y se pone en marcha de forma sencilla. Con linux se hace también, faltaria más, pero es algo más costoso y elaborado. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Tue, 15 Feb 2011 16:30:57 +0100, carlopmart escribió:
On 02/15/2011 03:55 PM, Camaleón wrote:
El manual (man sshd_config) dice:
*** AllowTcpForwarding Specifies whether TCP forwarding is permitted. The default is ''yes''. Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders. ***
No parece muy alentador, salvo que se utilice para un entorno enjaulado.
Es lo que se suele hacer cuando se precisa restringir comandos "peligrosos" como el ssh: se enjaulan los entornos.
(...) Pero no sólo hace falta una jaula sino eliminar el acceso a la shell, por lo que el ssh pierde su gracia, salvo que quieras configurar un SFTP chrooteado, como explicaba la página de la wiki de openSUSE que mandé ayer, ahí sí tendría sentido usar esa opción. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 02/15/2011 05:13 PM, Camaleón wrote:
El Tue, 15 Feb 2011 16:30:57 +0100, carlopmart escribió:
On 02/15/2011 03:55 PM, Camaleón wrote:
El manual (man sshd_config) dice:
*** AllowTcpForwarding Specifies whether TCP forwarding is permitted. The default is ''yes''. Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders. ***
No parece muy alentador, salvo que se utilice para un entorno enjaulado.
Es lo que se suele hacer cuando se precisa restringir comandos "peligrosos" como el ssh: se enjaulan los entornos.
(...)
Pero no sólo hace falta una jaula sino eliminar el acceso a la shell, por lo que el ssh pierde su gracia, salvo que quieras configurar un SFTP chrooteado, como explicaba la página de la wiki de openSUSE que mandé ayer, ahí sí tendría sentido usar esa opción.
Saludos,
No lo veo así. Fíjate lo que dice el manual: "Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders". Basta con que dentro de la jaula no permitas ciertas operaciones e instales solo ciertas librerias. O mejor aún, no instales el binario ssh, sino un wrapper que llame al binario con configuración específica. Para el caso que nos ocupa, nos bastaría por ejemplo con forzar la autenticación solo a través de claves privadas y no via passwords, ¿no?. Naturalmente la claves autorizadas las inserta el root y no el usuario de turno. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Tue, 15 Feb 2011 17:28:23 +0100, carlopmart escribió:
On 02/15/2011 05:13 PM, Camaleón wrote:
Pero no sólo hace falta una jaula sino eliminar el acceso a la shell, por lo que el ssh pierde su gracia, salvo que quieras configurar un SFTP chrooteado, como explicaba la página de la wiki de openSUSE que mandé ayer, ahí sí tendría sentido usar esa opción.
No lo veo así. Fíjate lo que dice el manual: "Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders". Basta con que dentro de la jaula no permitas ciertas operaciones e instales solo ciertas librerias. O mejor aún, no instales el binario ssh, sino un wrapper que llame al binario con configuración específica.
Pero eso no se puede hacer con un usuario del sistema, sólo para un usuario que sea externo y que tengas muy limitado, pero no creo que sea el caso. Además, ten en cuenta que desactivar esa valor afectaría a todos los usos de ssh (supongo que es una configuración global) ¿no?, no creo que sea conveniente.
Para el caso que nos ocupa, nos bastaría por ejemplo con forzar la autenticación solo a través de claves privadas y no via passwords, ¿no?.
Esto no lo veo claro. No se trata de un problema de autenficiación (tener las credenciales para acceder al sistema) sino de autorización (poder ejecutar ssh y abrir el túnel inverso).
Naturalmente la claves autorizadas las inserta el root y no el usuario de turno.
Para el caso que nos ocupa si el usuario es mañoso (y parece que lo es) y tiene una cuenta estándar en el sistema, puede seguir la recomendación del manual e instalarse una aplicación que se encargue del reenvío por lo que desactivar esa variable para el servicio ssh creo que no tiene mucho sentido. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 02/15/2011 06:14 PM, Camaleón wrote:
El Tue, 15 Feb 2011 17:28:23 +0100, carlopmart escribió:
On 02/15/2011 05:13 PM, Camaleón wrote:
Pero no sólo hace falta una jaula sino eliminar el acceso a la shell, por lo que el ssh pierde su gracia, salvo que quieras configurar un SFTP chrooteado, como explicaba la página de la wiki de openSUSE que mandé ayer, ahí sí tendría sentido usar esa opción.
No lo veo así. Fíjate lo que dice el manual: "Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders". Basta con que dentro de la jaula no permitas ciertas operaciones e instales solo ciertas librerias. O mejor aún, no instales el binario ssh, sino un wrapper que llame al binario con configuración específica.
Pero eso no se puede hacer con un usuario del sistema, sólo para un usuario que sea externo y que tengas muy limitado, pero no creo que sea el caso. Además, ten en cuenta que desactivar esa valor afectaría a todos los usos de ssh (supongo que es una configuración global) ¿no?, no creo que sea conveniente.
No. Precisamente la gracia de los jails en FreeBSD (y si no me equivoco en cualquier entorno enjaulado) es que los valores solo se aplican a los usuarios del jail, no son modificados en los del sistema.
Para el caso que nos ocupa, nos bastaría por ejemplo con forzar la autenticación solo a través de claves privadas y no via passwords, ¿no?.
Esto no lo veo claro. No se trata de un problema de autenficiación (tener las credenciales para acceder al sistema) sino de autorización (poder ejecutar ssh y abrir el túnel inverso).
Difiero en una cosa: si el usuario root ha configurado tanto al daemon sshd como al comando ssh para que únicamente puedan utilizar claves privadas como sistema de autencticación,y no passwords, y además ha configurado hardcoded esas claves, solo podrás conectar con servidores preestablecidos.
Naturalmente la claves autorizadas las inserta el root y no el usuario de turno.
Para el caso que nos ocupa si el usuario es mañoso (y parece que lo es) y tiene una cuenta estándar en el sistema, puede seguir la recomendación del manual e instalarse una aplicación que se encargue del reenvío por lo que desactivar esa variable para el servicio ssh creo que no tiene mucho sentido.
Uhmm ... tendría que mirarlo, pero creo que dentro de un jail no podría hacerlo, al menos en un jail de FreeBSD ... Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Tue, 15 Feb 2011 18:22:32 +0100, carlopmart escribió:
On 02/15/2011 06:14 PM, Camaleón wrote:
Pero eso no se puede hacer con un usuario del sistema, sólo para un usuario que sea externo y que tengas muy limitado, pero no creo que sea el caso. Además, ten en cuenta que desactivar esa valor afectaría a todos los usos de ssh (supongo que es una configuración global) ¿no?, no creo que sea conveniente.
No. Precisamente la gracia de los jails en FreeBSD (y si no me equivoco en cualquier entorno enjaulado) es que los valores solo se aplican a los usuarios del jail, no son modificados en los del sistema.
Pero no me refería a eso sino a que cambiando ese parámetro ("AllowTcpForwarding=no") en el archivo de configuración de la parte servidora ("/etc/ssh/sshd_config") afectaría a todos los usuarios del sistema.
Para el caso que nos ocupa, nos bastaría por ejemplo con forzar la autenticación solo a través de claves privadas y no via passwords, ¿no?.
Esto no lo veo claro. No se trata de un problema de autenficiación (tener las credenciales para acceder al sistema) sino de autorización (poder ejecutar ssh y abrir el túnel inverso).
Difiero en una cosa: si el usuario root ha configurado tanto al daemon sshd como al comando ssh para que únicamente puedan utilizar claves privadas como sistema de autencticación,y no passwords, y además ha configurado hardcoded esas claves, solo podrás conectar con servidores preestablecidos.
El usuario "cachondo" podría usar claves para conectarse a su equipo remoto ¿no? Porque si lo que dices es posible entonces sería más sencillo configurar ssh para que sólo permita conexiones salientes de "X" usuarios a los servidores predefinidos, sin necesidad de forzar el uso de claves o de desactivar el "reenvío". Pero en ese caso sigo pensando que estaríamos hablando de un usuario "muy capado". Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 02/16/2011 12:43 PM, Camaleón wrote:
El Tue, 15 Feb 2011 18:22:32 +0100, carlopmart escribió:
On 02/15/2011 06:14 PM, Camaleón wrote:
Pero eso no se puede hacer con un usuario del sistema, sólo para un usuario que sea externo y que tengas muy limitado, pero no creo que sea el caso. Además, ten en cuenta que desactivar esa valor afectaría a todos los usos de ssh (supongo que es una configuración global) ¿no?, no creo que sea conveniente.
No. Precisamente la gracia de los jails en FreeBSD (y si no me equivoco en cualquier entorno enjaulado) es que los valores solo se aplican a los usuarios del jail, no son modificados en los del sistema.
Pero no me refería a eso sino a que cambiando ese parámetro ("AllowTcpForwarding=no") en el archivo de configuración de la parte servidora ("/etc/ssh/sshd_config") afectaría a todos los usuarios del sistema.
Pues eso. Esa configuración la insertas dentro del jail. Por lo tanto solo tiene repercusión dentro del jail y no en el resto del sistema. La configuración del sistema no precisa modificarse.
Para el caso que nos ocupa, nos bastaría por ejemplo con forzar la autenticación solo a través de claves privadas y no via passwords, ¿no?.
Esto no lo veo claro. No se trata de un problema de autenficiación (tener las credenciales para acceder al sistema) sino de autorización (poder ejecutar ssh y abrir el túnel inverso).
Difiero en una cosa: si el usuario root ha configurado tanto al daemon sshd como al comando ssh para que únicamente puedan utilizar claves privadas como sistema de autencticación,y no passwords, y además ha configurado hardcoded esas claves, solo podrás conectar con servidores preestablecidos.
El usuario "cachondo" podría usar claves para conectarse a su equipo remoto ¿no?
No, porque para eso el root asigna un archivo de claves de intercambio en modo solo lectura para él y el daemon (440). El usuario no tiene forma de ejecutar el comando en modo "ssh -R ..." ya que el proceso servidor no autorizará la conexión. Porque si lo que dices es posible entonces sería más sencillo
configurar ssh para que sólo permita conexiones salientes de "X" usuarios a los servidores predefinidos, sin necesidad de forzar el uso de claves o de desactivar el "reenvío". Pero en ese caso sigo pensando que estaríamos hablando de un usuario "muy capado".
Es que se trata de "capar" al usuario. Tambien tienes la opción de hacer un wrapper que llame al ssh con parámetros y que el binario ssh principal no pueda ser ejecutado por usuarios ... al estilo de rssh, creo que hay un paquete que se llama así. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 02/16/2011 12:53 PM, carlopmart wrote:
On 02/16/2011 12:43 PM, Camaleón wrote:
El Tue, 15 Feb 2011 18:22:32 +0100, carlopmart escribió:
On 02/15/2011 06:14 PM, Camaleón wrote:
Pero eso no se puede hacer con un usuario del sistema, sólo para un usuario que sea externo y que tengas muy limitado, pero no creo que sea el caso. Además, ten en cuenta que desactivar esa valor afectaría a todos los usos de ssh (supongo que es una configuración global) ¿no?, no creo que sea conveniente.
No. Precisamente la gracia de los jails en FreeBSD (y si no me equivoco en cualquier entorno enjaulado) es que los valores solo se aplican a los usuarios del jail, no son modificados en los del sistema.
Pero no me refería a eso sino a que cambiando ese parámetro ("AllowTcpForwarding=no") en el archivo de configuración de la parte servidora ("/etc/ssh/sshd_config") afectaría a todos los usuarios del sistema.
Pues eso. Esa configuración la insertas dentro del jail. Por lo tanto solo tiene repercusión dentro del jail y no en el resto del sistema. La configuración del sistema no precisa modificarse.
Para el caso que nos ocupa, nos bastaría por ejemplo con forzar la autenticación solo a través de claves privadas y no via passwords, ¿no?.
Esto no lo veo claro. No se trata de un problema de autenficiación (tener las credenciales para acceder al sistema) sino de autorización (poder ejecutar ssh y abrir el túnel inverso).
Difiero en una cosa: si el usuario root ha configurado tanto al daemon sshd como al comando ssh para que únicamente puedan utilizar claves privadas como sistema de autencticación,y no passwords, y además ha configurado hardcoded esas claves, solo podrás conectar con servidores preestablecidos.
El usuario "cachondo" podría usar claves para conectarse a su equipo remoto ¿no?
No, porque para eso el root asigna un archivo de claves de intercambio en modo solo lectura para él y el daemon (440). El usuario no tiene forma de ejecutar el comando en modo "ssh -R ..." ya que el proceso servidor no autorizará la conexión.
Porque si lo que dices es posible entonces sería más sencillo
configurar ssh para que sólo permita conexiones salientes de "X" usuarios a los servidores predefinidos, sin necesidad de forzar el uso de claves o de desactivar el "reenvío". Pero en ese caso sigo pensando que estaríamos hablando de un usuario "muy capado".
Es que se trata de "capar" al usuario. Tambien tienes la opción de hacer un wrapper que llame al ssh con parámetros y que el binario ssh principal no pueda ser ejecutado por usuarios ... al estilo de rssh, creo que hay un paquete que se llama así.
Saludos.
Por cierto, un ejemplo de ssh un pelín capadito: http://matt.ucc.asn.au/dropbear/dropbear.html -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Thu, 17 Feb 2011 08:38:34 +0100, carlopmart escribió:
On 02/16/2011 12:53 PM, carlopmart wrote:
On 02/16/2011 12:43 PM, Camaleón wrote:
(...)
Porque si lo que dices es posible entonces sería más sencillo
configurar ssh para que sólo permita conexiones salientes de "X" usuarios a los servidores predefinidos, sin necesidad de forzar el uso de claves o de desactivar el "reenvío". Pero en ese caso sigo pensando que estaríamos hablando de un usuario "muy capado".
Es que se trata de "capar" al usuario. Tambien tienes la opción de hacer un wrapper que llame al ssh con parámetros y que el binario ssh principal no pueda ser ejecutado por usuarios ... al estilo de rssh, creo que hay un paquete que se llama así.
Por cierto, un ejemplo de ssh un pelín capadito:
Hum... pues no veo ninguna indicación que sea un "ssh capado" sino una implementación "portátil", más bien ¿no? :-? Por otra parte ¿qué se tiene que configurar en un servidor para que use un ssh u otro? ¿Cómo se "entrelazan/encadenan" ambas versiones de openSSH (una completa/estándar y otra limitada o con valores predefinidos o con funcionalidad capada) para forzar a los usuarios del sistema a usar uno u otro? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 02/17/2011 12:54 PM, Camaleón wrote:
El Thu, 17 Feb 2011 08:38:34 +0100, carlopmart escribió:
On 02/16/2011 12:53 PM, carlopmart wrote:
On 02/16/2011 12:43 PM, Camaleón wrote:
(...)
Porque si lo que dices es posible entonces sería más sencillo
configurar ssh para que sólo permita conexiones salientes de "X" usuarios a los servidores predefinidos, sin necesidad de forzar el uso de claves o de desactivar el "reenvío". Pero en ese caso sigo pensando que estaríamos hablando de un usuario "muy capado".
Es que se trata de "capar" al usuario. Tambien tienes la opción de hacer un wrapper que llame al ssh con parámetros y que el binario ssh principal no pueda ser ejecutado por usuarios ... al estilo de rssh, creo que hay un paquete que se llama así.
Por cierto, un ejemplo de ssh un pelín capadito:
Hum... pues no veo ninguna indicación que sea un "ssh capado" sino una implementación "portátil", más bien ¿no? :-?
Por otra parte ¿qué se tiene que configurar en un servidor para que use un ssh u otro? ¿Cómo se "entrelazan/encadenan" ambas versiones de openSSH (una completa/estándar y otra limitada o con valores predefinidos o con funcionalidad capada) para forzar a los usuarios del sistema a usar uno u otro?
Saludos,
Si utilizas jails es sencillo: dentro del jail solo instalas el binario que te interese y configuras los parámetros que precise el programa (archivos de configuración ,daemons, etc ...) Por ejemplo: con el demonio ssh apuntas a la configuración del jail directamente y el usuario no podrá modificar nada. Para ejecutar el comando ssh, haces un softlink hacia el binario del dropbear por ejemplo (altamente modificable para quitarle las opciones de -R y -L, las más "peligrosas" por así decirlo), etc ... Si no puedes usar jails o chroot (o no quieres o no sabes configurarlo o por cualquier otro motivo) puedes hacerlo, en linux, a través de los linux containers o bien openvz. Así conseguirás entornos aislados. Si no puedes instalar jails, linux containers u openvz por el motivo que fuere, entonces deberás controlar muy mucho a los binarios que das acceso a los usuarios, que pueden modificar o que no, etc. En mi opinión un montón de trabajo el configurarlo y mantenerlo habiendo otras soluciones más cómodas. Al final, lo que cuenta es tener el entorno controlado al máximo posible. Y por supuesto activar todos los procesos de auditoria del sistema: si el usuario instala un binario, si modifca alguno, etc ... Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (4)
-
Camaleón -
carlopmart -
Carlos E. R. -
koxkorrita