Duda con SSH

Archivado
Tengo un equipo con Debian, en el cual no toque la configuracion de SSH, que conste. En cambio me deja acceder al equipo, introduciendo el usuario que tiene el sistema (remotamente en la misma red) y tambien acceder como administrador, lo cual me es cómodo para instalar cosas, configurar cosas y demas historias desde otro equipo (porque éste esta ocupado siempre, es para uso "comercial").

La duda es la siguiente: acabo de pasarle asi por ver, el RootkitHunter (rkhunter) y me marca con Warning lo que es "Checking if SSH root access is allowed". Claro, me deja acceder como root, puedo instalar programas remotamente y cambiar configuraciones internas.

La pregunta es si sería realmente inseguro de cara hacia afuera. Es decir, los equipos están conectados al mismo modem, por cable, y el WIFI aparte de tener clave WPA2 y el WPS desactivado, le tengo dentro que solo permita conectarse por wifi las MACs que yo quiero.
Asi que la pregunta es sencilla: ¿se podría acceder por SSH desde fuera, desde Internet? ¿O unica y exclusivamente desde la red interna?

Mi ssh_config es asi:
# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Host *
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   Cipher 3des
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no


Y mi sshd_config asi:
# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile   %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes


Salu2 y gracias!
Sí, claro.

Deberías echarle una miradilla al port forwarding de tu router, para así cualquiera que quisiera (o tú) conectarse a tu servidor SSH únicamente debería poner la IP de tu router y el puerto; si quieres en el sshd_config modificar el puerto para que no sea el 22, pero realmente da igual, ya configuras la conversión en el forwarding del router.

No recomiendo para nada logearse directamente con acceso al administrador, puedes conectarte con tu usuario y desde ahí si lo necesitas hacer ya "su". Si es únicamente exclusivo para tu uso, podrías negar la conexión a la vez a 1 sólo usuario.

Aunque todas esas medidas, para un equipo personal no creo que nadie se interese en atacarla xD.

Nos vemos en Tuenti ;)
Con iptables y políticas por defecto DROP, tendrás otra capa mas de seguridad.

La pega, es que para todo lo que salga o entre, necesitas crearle las reglas necesarias, pero con eso vas a tener un poderoso firewall en tu equipo y por ende, un posible atacante de fuera le sera mas difícil.
Y el iptables funciona para cualquier conexion? O se puede configurar para que solo afecte a un puerto o a una aplicacion concretos (SSH)?
Creo que si, con las opciones --sport y --dport y el número de puerto que quieras (el de defecto es el 22)
Es pura lógica.

Si no tienes acceso root un atacante tendrá que averiguar tu nombre y contraseña, pero si dejas acceso root sólo tiene que averiguar contraseña, puesto que el nombre ya lo tiene "root".

Quitar acceso root y poner un puerto raro debería ser lo primero que hagas, es sencillo y te aporta bastante protección.

Delimitar por macs, o por ips, conectarte por vpn y sólo permitir acceso por red local, las posibilidades son infinitas, para los atacantes también, yo no me la jugaría con un equipo "comercial" como tú dices, en casa experimentos los que haga falta...
Pues voy a quitar el SSH mejor por si acaso :B total ultimamente ese equipo suele quedar más "vacio" y si tengo que hacer algo ya puedo "in situ".
Imagino que tendria que buscar los paquetes SSH y desinstalarlos?
noentiendero escribió:Pues voy a quitar el SSH mejor por si acaso :B total ultimamente ese equipo suele quedar más "vacio" y si tengo que hacer algo ya puedo "in situ".
Imagino que tendria que buscar los paquetes SSH y desinstalarlos?


Los paquetes de ssh se pueden desinstalar, pero pueden venirte bien para aplicaciones de administración local, conectarte a otros dispositivos, etc. Con que en el router no le des salida al SSH ya deberías quedarte tranquilo al respecto.

Ademas, como te dicen, no des opción a loguearte como root por ssh, siempre un usuario cual sea y que de ahí deba escalar privilegios con su o sudo. Y con usar un puerto no por defecto ya ni te cuento, serian muchos factores que al no estar por defecto y no ser un objetivo prioritario no deberías temer nada.
blackgem escribió:
noentiendero escribió:Pues voy a quitar el SSH mejor por si acaso :B total ultimamente ese equipo suele quedar más "vacio" y si tengo que hacer algo ya puedo "in situ".
Imagino que tendria que buscar los paquetes SSH y desinstalarlos?


Los paquetes de ssh se pueden desinstalar, pero pueden venirte bien para aplicaciones de administración local, conectarte a otros dispositivos, etc. Con que en el router no le des salida al SSH ya deberías quedarte tranquilo al respecto.

Ademas, como te dicen, no des opción a loguearte como root por ssh, siempre un usuario cual sea y que de ahí deba escalar privilegios con su o sudo. Y con usar un puerto no por defecto ya ni te cuento, serian muchos factores que al no estar por defecto y no ser un objetivo prioritario no deberías temer nada.


Ah espera, lo de desactivar la opcion de loguearte como root te permite usar su/sudo? porque es como venia haciendo hasta ahora [+risas]
noentiendero escribió:Ah espera, lo de desactivar la opcion de loguearte como root te permite usar su/sudo? porque es como venia haciendo hasta ahora [+risas]


si...
Creo que lo mas importante es quitar el acceso como root.
Cambiar el puerto no está de más, pero "solo" tienes que probar con 65000 puertos, es decir, preparar un scrip he irte a dormir. Aunque eso implica ser objetivo de alguien y no es lo normal.
Desde luego que si en el router no abres el puerto que escucha el SSH no hay acceso.
La solución que te han dicho de limitar el acceso solo a la red local, o incluso a una unica IP, y montar una VPN, unida al cambio de los puertos a otros no habituales, me parece casi perfecta y muy facil de implementar.
nu_kru escribió:
noentiendero escribió:Ah espera, lo de desactivar la opcion de loguearte como root te permite usar su/sudo? porque es como venia haciendo hasta ahora [+risas]


si...


Ah okay pues voy a hacer eso entonces :B
"amos" no jodas con lo de root.
Pensaba que lo usabas porque la otra cuenta no tenia privilegios... y yo rayandome "pa ná" la cabeza [mamaaaaa] [mamaaaaa]
Saxton Hale escribió:"amos" no jodas con lo de root.
Pensaba que lo usabas porque la otra cuenta no tenia privilegios... y yo rayandome "pa ná" la cabeza [mamaaaaa] [mamaaaaa]


Bueno, teoricamente no tiene (creo). Para usar root meto... no recuerdo ahora xD creo que "su" y la pass de root, no la del usuario
puedes cambiar los permisos de tu user para ejecutar algo específico. Restringir a determinados users. Además te permite banear la ip al 3 intento erróneo de login. y hay una cosa que creo se llamaba knocking door :-)

http://www.ibm.com/developerworks/aix/l ... -sshlocks/
Si además quieres añadir otra capa de seguridad de cara a conexiones desde el exterior, mírate fail2ban. De todos modos, puedes restringir las conexiones desde la red externa, cambiando el 0.0.0.0 que tienes en las opciones de configuración.
Ya lo dije antes, y además como otros dicen añadiría un tiempo máximo de login, intentos de login, que sólo un usuario se pueda loguear (creo que era user_allow), cambiar el puerto por defecto.
Con eso vas sobrado, no creo que nadie sepa ni tu IP ni que quiera nada de ti.
Korso10 escribió:Si además quieres añadir otra capa de seguridad de cara a conexiones desde el exterior, mírate fail2ban. De todos modos, puedes restringir las conexiones desde la red externa, cambiando el 0.0.0.0 que tienes en las opciones de configuración.


Vale, lo de cambiar el 0.0.0.0 me convence. ¿Se podría poner algo estilo 192.168.0.x? para cualquier equipo dentro de la red local?
Si tu red local está dentro de ese rango, supongo que si. [ginyo]
Acobo de ver una cosa que quizas os interese. Es el Port knocking.

" El golpeo de puertos (del inglés port knocking) es un mecanismo para abrir puertos externamente en un firewall mediante una secuencia preestablecida de intentos de conexión a puertos que se encuentran cerrados. Una vez que el firewall recibe una secuencia de conexión correcta, sus reglas son modificadas para permitir al host que realizó los intentos conectarse a un puerto específico.

El propósito principal del golpeo de puertos es prevenir un escanéo de puertos por parte de un atacante que busca posibles servicios vulnerables. Como los mismos solo se abren ante un golpeo de puertos correcto. Normalmente los puertos donde se brindan los servicios se muestran aparentemente cerrados.

Wikipedia"

Y aquí tienes un tutorial:

http://rm-rf.es/port-knocking-en-debian-con-knockd/

Me parece la solición perfecta para tu problema.

EDITO: Aqui tienes más información: http://www.kriptopolis.org/port-knocking
Esog Enaug escribió:Acobo de ver una cosa que quizas os interese. Es el Port knocking.

" El golpeo de puertos (del inglés port knocking) es un mecanismo para abrir puertos externamente en un firewall mediante una secuencia preestablecida de intentos de conexión a puertos que se encuentran cerrados. Una vez que el firewall recibe una secuencia de conexión correcta, sus reglas son modificadas para permitir al host que realizó los intentos conectarse a un puerto específico.

El propósito principal del golpeo de puertos es prevenir un escanéo de puertos por parte de un atacante que busca posibles servicios vulnerables. Como los mismos solo se abren ante un golpeo de puertos correcto. Normalmente los puertos donde se brindan los servicios se muestran aparentemente cerrados.

Wikipedia"

Y aquí tienes un tutorial:

http://rm-rf.es/port-knocking-en-debian-con-knockd/

Me parece la solición perfecta para tu problema.


Interesante, aunque de momento he puesto permitir una sola IP, aunque aun no he probado si está bien o no (no tuve la ocasion :B)

S2 y gracias!
20 respuestas
Archivado
Volver a Software libre