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