Seguramente el protocolo más utilizado para la administración de sistemas Unix es SSH/SecSH y su implantación más extendida, tanto por número de instalaciones como por tipos distintos de sistemas operativos soportados es la del producto OpenSSH.Este servicio dispone de una configuración segura por defecto, aunque también es posible mejorarla y ajustarla a los requerimientos y políticas de cualquier organización, minimizando de esta forma el número potencial de riesgos.
Los consejos aquí mostrados pueden ser o no aplicados según vuestra valoración y necesidades. Todas las opciones que se muestran se han de modificar en el fichero de configuración, generalmente /etc/ssh/sshd_conf o similar.
- Port (por defecto: 22)
Especifica el número del puerto en el que el servicio escuchará. El mayor número de ataques se producen por herramientas automáticas, que en busca de este demonio, probarán usuarios y contraseñas comunes. Modificando el puerto a un número no estándar, por ejemplo 8822 se evitarán en su gran mayoría, ahorrando de esta forma la generación de cientos de registros inútiles al día. Tiene especial importancia en servidores expuestos en Internet.
Un truquito para elegir el puerto es utilizar el que ya conocemos, en este caso el 22 y añadirle algún número para que sea más fácilmente memorizable. Además, si buscamos si está definido en el archivo "nmap-services" (/usr/share/nmap/nmap-services en mi linux) complicaremos un poquito más su detección a solo los escaneos que contemplen todos los puertos.
- Protocol (por defecto: 1,2)
Especifica la versión del protocolo con la que un cliente puede conectarse. Debido a las vulnerabilidades conocidas de ataques de hombre en el medio en la versión 1, este parámetro se ha de establecer únicamente a "2".
- PermitRootLogin (por defecto: yes)
El usuario administrador del sistema no debería realizar la autenticación directamente contra el equipo. Es recomendable modificar este parámetro dejándolo en "no" y en caso de necesidad por el uso de scripts o aplicaciones automáticas, utilizar el valor "forced-commands-only", que permitirá la conexión del usuario root solo si es mediante certificado.
- ListenAddress (por defecto: all)
La directiva ListenAddress especifica en que direcciones IP se abrirá el puerto para ofrecer el servicio. Si el sistema dispone de más de una dirección IP, ya sea IPv4 o IPv6, es conveniente limitar esta escucha únicamente a las necesarias. Se permite el uso repetido de este parámetro, en caso de por ejemplo, querer escuchar en dos de las tres direcciones IP de un equipo.
- AllowUsers (por defecto: todos los usuarios)
AllowUsers concreta que usuarios tienen permitido el uso del servicio SSH, se permite especificar distintos usuarios separados por coma y opcionalmente, el host desde el que conectan con el formato "usuario@host".
El host puede ser limitado de distintas formas, ya sea con un cortafuegos o mediante el uso de un TCPWrappers.
Esta directiva complementa el grupo "Allow/Deny" compuesto por otros parámetros, en concreto, según su orden de procesado: AllowUsers, DenyUsers, AllowGroup y DenyGroup.
El host puede ser limitado de distintas formas, ya sea con un cortafuegos o mediante el uso de un TCPWrappers.
Esta directiva complementa el grupo "Allow/Deny" compuesto por otros parámetros, en concreto, según su orden de procesado: AllowUsers, DenyUsers, AllowGroup y DenyGroup.
- AllowGroups (por defecto: todos los grupos)
- MaxAuthTries (por defecto: 6)
Con el parámetro MaxAuthTries se especifica el máximo número de intentos de autenticación fallida por conexión. Cuando se alcanza la mitad de este número los sucesivos intentos serán registrados en los correspondientes logs. Se recomienda su configuración a un valor más bajo como 3.
- LoginGraceTime (por defecto: 120)
Con esta directiva se especifica cuantos segundos se permite que un usuario permanezca con una conexión abierta sin haberse autenticado correctamente. Es recomendable que este valor sea inferior, como por ejemplo 60.
Segunda parte de esta entrada: 2/2 Fortificación del servicio SSH.
4 comments :
¿"más" inferior? Te sobra un "más".
¿No es lo ideal deshabilitar el paso con contraseña, y permitir sólo con certificado?
Supongo que todo depende del equilibrio entre comodidad y seguridad.
Yo siempre añado el UseDNS no, para saltarme esos cuatro o cinco segundos al hacer login.
@akae, gracías por el comentario, ya está solucionado. El UseDNS sería en este caso un tema de rendimiento, más que de seguridad. Pero con la pega que no haces una comprobación adicional de IP->host, host->IP. En cuanto a los certificados y otras 7 directivas más, están previstas para la segunda parte del artículo.
Un saludo!
En situaciones donde por necesidad tienes que colocar el servicio en un puerto ampliamente conocido, por ejemplo el 443/tcp (para hacer tunel mediante un proxy https)... ¿qué recomendaciones puedes aportar? Sería interesante que comentes sobre ese tema en la segunda parte :) (y sobre port knocking)
4 o 5 segundos!?!?!? miralo porque el problema no está en el UseDns.. si no en el resolv de la máquina..
Publicar un comentario