Protegiendo el Servidor (Ubuntu)

Quiero agradecer a Miguel García, por su valiosa ayuda (y templada paciencia) que me permitió proteger el VPS afectado y que fuera puesto en servicio nuevamente. Cabe remarcar que si bien la reseña está en “primera persona” fueron acciones en conjunto con Miguel…

Si allí afuera hay una jungla, ahí dentro (en la red) se comprueba la definición de “tierra de nadie”…

NB: los valores “sensibles” (puertos, contraseña, nombres de usuario, dominios, etc) son ficticios y con el único objeto de ser más claro en los ejemplos.

Antecedentes

Inicialmente luego de contratado e instalado el servidor, realicé estas modificaciones para asegurarlo:

  • anulé la posibilidad que root pueda loguearse y agregué mi usuario al grupo de sudoers (Ubuntu, mi caso, lo hace por defecto)
  • edité la configuración del SSH (se indican las modificaciones)
/etc/ssh/sshd_config
port 4522            # hagamos las cosas difíciles para quien intente entrar: 
                     # no usar puerto por defecto
...
LoginGraceTime 60    # Si tu sabes tu clave, no demoras mucho en escribirla
PermitRootLogin no   # root no opera
StrictModes yes      # previene el uso de carpetas y 
                     # archivos esenciales inseguros
...
AllowUsers MiUsuario # Si hacen falta más usuarios indicarlos separados 
                     # por un espacio...
MaxAuthTries 2       # No es posible que te equivoques más de 2 veces 
                     # ingresando la clave
MaxStartups 2        # Si sólo yo ingreso, a lo sumo 2 conexiones 
                     # simultáneas alcanzan

Hay otras mejoras posibles, pero no las implementé aún (¿debería?, si y ya explicaré…)

  • Como instalé zPanel y, éste a su vez, instala mysql, php, apache, postfix y demases; a todo ello le cambié el usuario “de fábrica” y le cambié la clave (donde fuera necesario, claro)

Suponía que con esto alcanzaba, hasta la semana pasada: Me reportaron un ataque coordinado (DDoS bot attack) y luego desconectaron el VPS porque se había agravado…

Miguel lo primero que hizo fue utilizar nmap para chequear qué puertos estaban abiertos… Los usuales.. ¡Bien!…

Lo que siguió luego causó su asombro: iptables vacía… ¡Je! (ejem) el VPS no tenía firewall…

A mano creamos un mínimo script para salvar la situación y pedir la reactivación del servicio:

fwMinimo.sh
iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 4522 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 4522 -j ACCEPT

A partir de ahí, ni bien el VPS tuvo acceso a Internet instalé csf y configuré para que aceptara conexiones desde le puerto 4522 (ssh) y eliminé el 22 (por defecto de la lista).

Para poder configurar más sencillamente el csf, instalé webmin y le agregué el módulo de csf:

Webmin > Webmin Configuration > Webmin Modules >
 "From local file":  /etc/csf/csfwebmin.tgz 
Luego "Install Module"

De utilizar un servicio de DDNS (DNS Dinámico) en la máquina desde la que se gestiona el VPS de manera remota, y permitir el acceso desde ella sin que el csf nos filtre:

Webmin > System > ConfigServer Security & Firewall > 
 En el apartado "lfd - Login Failure Daemon" 
clickear sobre "lfd Dynamic DNS"
 En el cuadro que se despliega escribir luego de la última línea comentada
el FQDN (por ejemplo: mipc.ddns.me)

Guardar y reiniciar (con el botón Restart ldf) el demonio.

Correr un diagnóstico del firewall… Y empezar a resolver los puntos flojos…

Asegurando más el SSH

Sobre esto no hay mucho que decir: quitarle el acceso por clave y activar el uso de “public key”… Incluso no es excusa (¡ouch!) decir que el acceso puede ser de varios puntos e instalar la “public key” de cada uno…

ssh -i /ruta/a/public/key/id_dsa.pub -p uerto ssh elegido] [email protected]

(Miguel, en tu pendrive el archivo y en tu sshd_config: PasswordAuthentication no  🙂 )

Afinando csf

Lo que siguió luego fue empezar a ajustar el csf para que no nos informe a cada rato los falsos positivos:

  • Detectar los procesos “sanos” y listarlos en csf.pignore
  • Ajustar los valores de ejecución (sobre todo del postfix, dovecot, etc) o bien subir los límites en la configuración del csf (uso de memoria, tiempos de ejecución, etc)
  • En el caso de Ubuntu, /var/log/messages no se utiliza más, hay que indicarle a csf que es /var/log/syslog:
/etc/cfs/csf.conf
...
HTACCESS_LOG = "/var/log/apache2/error.log"
MODSEC_LOG = "/var/log/apache2/error.log"
SSHD_LOG = "/var/log/auth.log"
SU_LOG = "/var/log/syslog"
FTPD_LOG = "/var/log/syslog"
SMTPAUTH_LOG = "/var/log/secure"
POP3D_LOG = "/var/log/mail.log"
IMAPD_LOG = "/var/log/mail.log"
IPTABLES_LOG = "/var/log/syslog"
SUHOSIN_LOG = "/var/log/syslog"
BIND_LOG = "/var/log/syslog"
SYSLOG_LOG = "/var/log/syslog"
WEBMIN_LOG = "/var/log/auth.log"

CUSTOM1_LOG = "/var/log/customlog"
CUSTOM2_LOG = "/var/log/customlog"
CUSTOM3_LOG = "/var/log/customlog"
CUSTOM4_LOG = "/var/log/customlog"
CUSTOM5_LOG = "/var/log/customlog"
CUSTOM6_LOG = "/var/log/customlog"
CUSTOM7_LOG = "/var/log/customlog"
CUSTOM8_LOG = "/var/log/customlog"
CUSTOM9_LOG = "/var/log/customlog"
...

A partir de ese momento, una vez reiniciado csf ya empieza a tener cierta seguridad.

Y digo “cierta” porque si bien los intentos de ataque empiezan a “dropearse”, aún no son “bloqueadas” las IP desde las que lo intentan. Ese es el paso que continúa…

Vía webmin o editando el archivo de configuración del csf observar estos valores:

  • SMTP_BLOCK: sólo podrá enviarse correo mediante el servicio correspondiente, y para los usuarios indicados (los del demonio en cuestión)
  • LF_PERMBLOCK: activo para que analice los logs de las IP que son descartadas y si superan la cantidad de LF_PERMBLOCK_COUNT se bloquea LF_PERMBLOCK_INTERVAL segundos.
  • En la sección “LoginFailureBlockingandAlert” me resultó útil activar estos parámetros:
    • LF_TRIGGER: lo desactivé para poder ajustar cada servicio en particular
    • LF_SELECT: en 0, de modo que una IP atacante se bloquea para cualquier servicio
    • LF_EMAIL_ALERT: lo activé pues por ahora (mientras observo si todo va bien) quiero saber qué pasa. NOTA: opté por indicar LF_ALERT_TO y LF_ALERT_FROM y no dejarlo librado a la configuración del caso.
    • LF_[servicio]: me interesó enfocarme en SSHD, FTPD, SMTPAUTH, POP3D, IMAPD, HTACCESS, WEBMIN y todas con un valor de 3600 segundos. Quizá los otros servicios deberían ser tenidos en cuenta según la necesidad del lector.
    • LF_SSH_EMAIL_ALERT, LF_SU_EMAIL_ALERT, LF_CONSOLE_EMAIL_ALERT: también los activé dado que (por el momento) soy el único que entra por SSH o por Consola Virtual (vía web) y por lógica, el único capaz de hacer “sudo”; por lo cual, las razones están más que explicadas del por qué activé esto.

Sé que quizá haya aún mucho por hacer, pero al menos con estas acciones el VPS está mucho más protegido, cada vez son menos los intentos de encontrarle alguna vulnerabilidad, e incluso ha mejorado el rendimiento del servidor.

Sugerencias, recomendaciones y comentarios son bienvenidos.

Esta entrada fue publicada en Linux, Redes y etiquetada , , . Guarda el enlace permanente.

4 respuestas a Protegiendo el Servidor (Ubuntu)

  1. HenryGR dijo:

    ¡Muy interesante artículo.
    Una pregunta me queda en el aire (si puedo) ¿Razón para preferir instalar csf en lugar de, digamos, ufw?
    En cualquier caso,Gracias.

    • Esteban Adrián Perez dijo:

      No hay una razón fundada, simplemente Miguel me recomendó csf y ése utilicé… Quizá él tenga razones de mayor peso 🙂
      ¡Gracias por leer!

  2. Miguel dijo:

    No conozco ufw,y csf es una herramienta multiplataforma que he utilizado en entornos Ubuntu, Debian y Centos, trabajando con Plesk, cPanel y Virtualmin….me ofrece confianza.

  3. Pingback: Notas sobre SSHRecursos para formacion

Deja un comentario