Maximiza la seguridad en GNU/Linux

Hola amigos de DesdeLinux, lo prometido es deuda y aquí va un post de cómo maximizar la protección de sistemas Linux y mantenerse así a salvo de intrusos además de proteger la información en sus servidores, PC’s o portátiles !!!!

Comenzando

Fail2ban: es una aplicación escrita en Python para la prevención de intrusos en un sistema, que actúa penalizando o bloqueando las conexiones remotas que intentan accesos por fuerza bruta.

Instalación:

Fedora, RHEL, CentOS:

yum install fail2ban

Debian, Ubuntu:

apt-get install fail2ban

Configuración:

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
nano /etc/fail2ban/jail.local

En la parte llamada [DEFAULT] descomentamos y modificamos #bantime = 3600 dejandolo así:

#bantime = 3600
bantime = 604800

En la parte [sshd] introducimos enabled = true dejándolo así:

#enabled = true
enabled = true

Guardamos con CTRL+O y cerramos con CTRL+X

Iniciamos el servicio:

Fedora, RHEL, CentOS:

systemctl enable fail2ban.service
systemctl start fail2ban.service

Debian, Ubuntu:

service fail2ban start

Denegar acceso root usando ssh:

Para proteger a nuestra máquina vamos a denegar ssh mediante el usuario root. Para ello editamos el archivo /etc/ssh/sshd_config de la siguiente manera:

cp sshd_config sshd_config.bck
nano /etc/ssh/sshd_config

Descomentamos y cambiamos

#Protocol 2
Protocol 2

Descomentamos y cambiamos

#PermitRootLogin yes
PermitRootLogin no

Guardamos con CTRL+O y cerramos con CTRL+X

Iniciamos el servicio:

Fedora, RHEL, CentOS:

systemctl enable sshd.service
systemctl start sshd.service

Debian, Ubuntu:

service sshd start

Denegar acceso a un servidor ssh usando clave y permitir ssh solo con llaves RSA

Si deseamos conectarnos con el PC1 al Servidor1 lo primero que debemos hacer es generar nuestra llave en el PC1. Con nuestro usuario y sin root en el PC1 ejecutamos:

ssh-keygen -t rsa -b 8192 (esto genera una llave más que segura ya que normalmente se usan llaves de 1024 a 2048)

Una vez tenemos nuestra clave la subimos al Servidor1:

ssh-copy-id usuario@ip_del_servidor

Una vez hecho esto vamos a conectarnos a nuestro Servidor1 y modificamos con permisos de root el archivo nano /etc/ssh/sshd_config:

ssh usuario@Servidor1
nano /etc/ssh/sshd_config

La linea que pone #PasswordAuthentication yes la cambiamos a esto:

#PasswordAuthentication yes
PasswordAuthentication no

Guardamos con CTRL+O y cerramos con CTRL+X

Reiniciamos el servicio ssh:

Fedora, RHEL, CentOS:

systemctl restart sshd.service

Debian, Ubuntu:

service sshd restart

Cambiar el puerto de escucha ssh

Nuevamente editamos /etc/ssh/sshd_config y en la parte referente al puerto la dejamos así:

# Port 22
Port 2000 (o cualquier otro número mayor que 2000. En nuestros ejemplos usaremos este.)

Guardamos con CTRL+O y cerramos con CTRL+X

Reiniciamos el servicio ssh:

Fedora, RHEL, CentOS:

systemctl restart sshd.service

Debian, Ubuntu:

service sshd restart

Si usan fail2ban es necesario cambiar la configuración referente a sshd ajustando el puerto.

nano /etc/fail2ban/jail.local

[sshd]
port    = ssh, 2000

[sshd-ddos]
port    = ssh, 2000

[dropbear]
port    = ssh, 2000

[selinux-ssh]
port    = ssh, 2000

Guardamos con CTRL+O y cerramos con CTRL+X

Reniciamos el servicio:

Fedora, RHEL, CentOS:

systemctl restart fail2ban.service

Debian, Ubuntu:

service fail2ban restart

Firewall

Fedora, RHEL, CentOS:

En estos sistemas se encuentran Selinux y Iptables activados por defecto y yo recomiendo que siga así. ¿Como abrir un puerto con Iptables? Vamos a ver como abrir el nuevo puerto 2000 del puerto ssh que cambiamos anteriormente:

Abrir:

nano /etc/sysconfig/iptables

y modificamos la linea referente al puerto ssh por defecto 22 y la dejamos así:

#-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 2000 -j ACCEPT

Guardamos con CTRL+O y cerramos con CTRL+X

Reiniciamos el servicio:

systemctl restart iptables

Debian, Ubuntu:

En Debian o Ubuntu y derivados disponemos de UFW firewall el cual nos hará la vida fácil ya que gestiona a Netfilter muy fácil.

Instalación:

apt-get install ufw
ufw enable

Para ver el estado de puertos abiertos ejecutamos:

ufw status

Para abrir un puerto (en nuestro ejemplo será el nuevo puerto 2000 de ssh):

ufw allow 2000

Para denegar un puerto (en nuestro caso será el puerto por defecto 22 de ssh):

ufw deny 22
ufw delete deny 22

Y listo amigos. De esta manera mantendrán vuestras máquinas a salvo. No os olvidéis comentar y hasta la próxima :D.


41 comentarios, deja el tuyo

Deja tu comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.

  1.   sinnerman dijo

    y un sistema de encriptación como por ejemplo : https://www.dyne.org/software/tomb/

    1.    sinnerman dijo

      Y también enjaular usuarios en su home si se conectan por tty :
      http://olivier.sessink.nl/jailkit/index.html#intro
      https://operativoslinux.wordpress.com/2015/02/21/enjaular-usuarios-en-linux/ (el modo fácil)

    2.    Yukiteru dijo

      Es mucho mejor y más seguro encriptarse todo el sistema de archivos.

    3.    petercheco dijo

      Para el siguiente tuto referente a la seguridad en Linux lo tendré en cuenta :D.

      1.    Yukiteru dijo

        También sería bueno hablar de hardening del kernel por medio de sysctl, activar el random heap y Exec-Shield en los kernel que lo soportan, capar el acceso a dmesg y al sistema de ficheros /proc, ejecutar un demonio audit, habilitar la protección TCP SYN, restringir los acceso a /dev/mem, desactivar opciones de la pila TCP/IP que pueden ser peligrosas o restan seguridad al sistema (redirect, echo, source routing), usar pam_cracklib para que los usuarios generen contraseñas fuertes, la importancia del uso de sistema MAC como Tomoyo, AppArmor y SELinux.

  2.   Kuk dijo

    muy utíl!!!! justo lo que buscaba gracias 🙂

    1.    petercheco dijo

      De nada amigo :).

  3.   angelblade dijo

    Si se usa apache, no está de más añadir reglas con mod_rewrite para evitarse los bots. Muy util

    http://perishablepress.com/eight-ways-to-blacklist-with-apaches-mod_rewrite/

    1.    rolo dijo

      y para nginx hay algun truco o configuración??

  4.   rolo dijo

    en debian 8 el archivo /etc/ssh/sshd_config ya trae activo Protocol 2 y la función PermitRootLogin esta con la opcion without-password (solo se puede ingresar a root con la llave de autenticación y desde computador que tiene la llave privada)

    pd en debian 8 ya llego firewalld que lo deja chiquito a ufw

    1.    dhunter dijo

      Has visto ferm? Me gusta como se definen las reglas.

      http://ferm.foo-projects.org/download/examples/webserver.ferm

    2.    petercheco dijo

      Pues me alegro que Debian 8 use firewalld ya que es muy muy muy bueno…

  5.   dhunter dijo

    Cuidado con fail2ban que un atacante fabrica paquetes con el ip de la pc local y hace un DOS muy fácil.

    1.    Hery dijo

      Hombre, la IP del PC local y la de bucle se excluyen de la lista de Fail2ban.
      Sino, podríamos tener falsos positivos.

  6.   Jason Soto dijo

    Buenas Recomendaciones y muy efectivas…Claro está que en el ambiente de servidores y si estamos hosteando una web conlleva pasos adicionales…. Actualmente mantenemos un proyecto llamado JackTheStripper que no es mas que un Script en bash que prepara y asegura un servidor con GNU/Linux siguiendo las mejores prácticas de seguridad, para aplicaciones web… pueden conocer el proyecto en http://www.jsitech.com/jackthestripper ….

    1.    Yukiteru dijo

      Buen script aunque me gusta mantener el valor de kernel.randomize_va_space = 2

      1.    Jason Soto dijo

        Lo bueno es que antes de correrlo, puedes modificarlo un poco a tus necesidades…..Un Saludo…

    2.    petercheco dijo

      Hola, claro está que mi post trata de un asegurado base y cada uno debe protegerse más o menos dependiendo de los servicios que tiene instalado en sus sistemas como lo puede ser LAMP o FTP, SFTP, BIND y un largo etcétera :)…

      En el próximo post sobre seguridad trataré estos temas.

      Gracias por la opinión positiva :).

  7.   nex dijo

    @petercheco, tus guías son excelentes, seria bueno una guía de encriptación para el sistema de FreeeBSD, no se cuando vayas hacer la segunda parte sobre FreeBSD, sobre configuración y personalizacion de escritorios, sobre Firewall, sobre crear y configurar red inalámbrica.

    1.    petercheco dijo

      Hola amigo,
      ando un tanto ocupado como demuestra la poca frecuencia de publicación, pero lo tendré en cuenta para el próximo post para FreeBSD.

      Un saludo :).

  8.   Solrak Rainbowarrior dijo

    Que nivelado en los comentarios, no tengo ni idea de o que habláis, nadie xD
    Gran artículo!

  9.   xunil dijo

    Esta acción de seguridad implica limitar de alguna forma el equipo ??

    1.    petercheco dijo

      No… No se limita en nada el uso normal del sistema.

  10.   sinnerman dijo

    Y lo curioso(trágico)es que,como recién vimos con las máquinas Lenovo,si el firmware del bios está intervenido con malware,nada de lo que hagas importa.

    1.    petercheco dijo

      Siempre y cuándo uses el Windows preinstalado por el fabricante…

      1.    sinnerman dijo

        error:recuerda que lo instalaron en el firmware del bios,o sea que se inicia con el sistema en cada reinicio,antes que el sistema operativo,antes que los demonios,antes que nada,y no te deja hacer nada en contra.Ante esos ataques poco se puede hacer.Por eso la idea del uefi es buena en principio.

  11.   Pablo dijo

    Interesante artículo, lo leeré con mayor detenimiento en esta tarde. Gracias.

    1.    petercheco dijo

      De nada :). Me alegro.

  12.   Carlos Mejor dijo

    Excelente articulo, me entretuve toda la tarde leyendolo. Se agradece el tiempo que te tomas para explicar todo muy detenidamente,

    Saludos desde Chile
    Carlos

    1.    petercheco dijo

      Hola Carlos,
      Muchas gracias :).

  13.   bryon dijo

    Las máquinas Lenovo,si el firmware del bios parece estar intervenido con malware, las maquinas (PC Portatiles-Computer de mesa) siempre viene instalado con Windows por el fabricante, ante lo expuesto…sirve lo del post….petercheco?.

    1.    Yukiteru dijo

      Incluso sin hacer todo esto sirve, ya que el malware esta hecho para Windows no para Linux.

  14.   SynFlag dijo

    Faltan muchas cosas y trucos de iptables, como marear a nmap para que de todos los port abiertos, mentir que es una pc windows mediante el ttl y el tamaño de ventana, scanlogd, apache mod security, grsec, selinux o algo de eso. Reemplazar ftp por sftp, limitar la cantidad de conexiones por IP a cada servicio en X puerto para evitar que ante un DDoS nos dejen sin servicios, asi como bloquear las IP que envian mas de tanta cantidad de UDP por tantos segundos.

    1.    petercheco dijo

      Con los ejemplos que expusiste un usuario novel se volveria loco al leerlo… No se puede poner todo en un post. Hare varias entradas :).

  15.   shini-kire dijo

    me da error en archlinux en este punto al dar el servicio start, le doy status y esto sale:
    sudo systemctl status fail2ban
    ● fail2ban.service – Fail2Ban Service
    Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; enabled; vendor preset: disabled)
    Active: failed (Result: start-limit) since vie 2015-03-20 01:10:01 CLST; 1s ago
    Docs: man:fail2ban(1)
    Process: 1695 ExecStart=/usr/bin/fail2ban-client -x start (code=exited, status=255)

    mar 20 01:10:01 Gundam systemd[1]: Failed to start Fail2Ban Service.
    mar 20 01:10:01 Gundam systemd[1]: Unit fail2ban.service entered failed state.
    mar 20 01:10:01 Gundam systemd[1]: fail2ban.service failed.
    mar 20 01:10:01 Gundam systemd[1]: start request repeated too quickly for fail2ban…ice
    mar 20 01:10:01 Gundam systemd[1]: Failed to start Fail2Ban Service.
    mar 20 01:10:01 Gundam systemd[1]: Unit fail2ban.service entered failed state.
    mar 20 01:10:01 Gundam systemd[1]: fail2ban.service failed.
    Hint: Some lines were ellipsized, use -l to show in full.
    alguna ayuda? D:

    1.    petercheco dijo

      Hola, si habilitaste fail2ban con systemctl enable fail2ban.service y systemctl start fail2ban.service, el problema estará en la configuración de jails que has hecho. Porfavor revisa tu jail y verifica que todo esté bien.

      Un saludo
      Petercheco

      1.    Maykel Franco dijo

        Antes de nada buen tutorial. Faltan muchas cosas pero te has centrado en lo básico.

        shini-kire, revisa tu /var/log/fail2ban.log

        Saludos.

      2.    petercheco dijo

        Gracias @Maykel Franco :).

  16.   jony127 dijo

    Buenas,

    fail2ban deberían instalarlo en un pc doméstico o eso es más bien para servers???

    Gracias.

    1.    petercheco dijo

      Más bien para los servidores pero si estas en una wifi accesible por más gente que tú viene bien…

  17.   Rodrigo dijo

    Hola amigo me parece un buen post de seguridad en la parte de un corta fuego en las distros Gnu/Linux te escribo este comentario porque lo estoy haciendo en una distribucion de ubuntu 14.04 sabiendo que ya esta en la 15.04 lo que sucede es el siguiente problema entro en nano /etc/fail2ban/jail.local como root y no tengo visualizacion en la parte de la sshd y guardo En la parte llamada [DEFAULT] descomentamos y modificamos #bantime = 3600 y
    En la parte [sshd] introducimos enabled = true dejándolo así:
    #enabled = true
    enabled = true
    No aparece eso de la sshd que puede ser sera porque estoy trabajando la version anterior gracias