Tutoriales y Manuales
Entradas Mensuales
-
►
2024
(Total:
1058
)
- ► septiembre (Total: 50 )
-
►
2023
(Total:
710
)
- ► septiembre (Total: 65 )
-
►
2022
(Total:
967
)
- ► septiembre (Total: 72 )
-
▼
2021
(Total:
730
)
- ► septiembre (Total: 56 )
-
▼
enero
(Total:
52
)
- Configuración MariaDB (MySQL) Gestor Base de Datos
- Instalar WSL2 en Windows 10 para ejecutar Linux de...
- Análisis BackBlaze de los discos duros mecánicos m...
- Tecnologías grabación disco duro mecánico HDD: dif...
- Europol desmantela Emotet: la botnet de malware má...
- Obtener IP de un contacto mediante una llamada en ...
- Nomenclatura de la BIOS/UEFI: ErP Ready, CSM, VRM,...
- Vulnerabilidad en sudo presente desde 2011 permite...
- Seguridad en SSH: uso de llaves privadas y multifa...
- Securizar una RaspBerry Pi
- Convierte tu Raspberry PI en un analizador de red ...
- Optimizar módulo PHP FPM y opciones de seguridad e...
- Los mejores HoneyPots: ejemplos, tipos, caracterís...
- SMiShing: ¿Por qué son tan efectivos los engaños p...
- Vulnerabilidad en "Enviar a Kindle" por e-mail per...
- Utilizan Windows RDP (Escritorio Remoto) puerto 33...
- Secuestran mediante phishing la cuenta de Instagra...
- Google indexa de nuevo datos privados de WhatsApp ...
- Arbitrium-RAT: troyano de acceso remoto multiplata...
- Un exempleado interrumpe el envío de suministros d...
- Los 10 mejores sitios web descarga de Torrent de 2021
- La Policía Nacional detiene en Valencia varón 25 a...
- La policía británica borra por error 400.000 histo...
- Guía configuración y optimización Apache (MPM, suE...
- Administración de Trump añade a Xiamoi a lista de ...
- Comprobar la capacidad real de espacio en un pendr...
- Error en Windows 10 corrompe tu disco duro al ver ...
- Empresa china filtra 200 millones de datos de usua...
- Expertos alertan potente y peligroso RAT llamado R...
- nVidia presenta la serie GeForce RTX Serie 30 y AM...
- Intel agrega a procesadores capacidades de detecci...
- Archivan todas las publicaciones de Parler elimina...
- Fuga de datos privados de la ONU: trabajadores de ...
- Muchas otras redes sociales se unen al veto de Twi...
- SolarWinds contrata una nueva empresa de cibersegu...
- Compartir la ubicación de Telegram no es tan priva...
- HackTools v0.3.0 : la extensión todo en uno para W...
- FBI advierte a empresas sobre ataques del ransomwa...
- Estados Unidos condena ruso a 12 años de cárcel po...
- Aumentan las descargas de Signal y Telegram ante p...
- Condenan a Vodafone a devolver 20.380 euros a un c...
- La aplicación KeyDecoder permite usar el teléfono ...
- Comprendiendo el cifrado TPM con BitLocker y métod...
- Descubre contraseñas escuchando las pulsaciones de...
- Grupo Ransomware DoppelPaymer roba y publica datos...
- Apple compara cuántos metadatos recoge Whatsapp Vs...
- Nintendo pide $15 millones de daños de un sitio we...
- Crecen los ciberataques a los bancos a raíz del co...
- iptables Vs FirewallD: diferencias, ejemplos práct...
- Desactivar scripts PowerShell para evitar ataques ...
- Fallo en Facebook SDK permitía robar cuentas vía o...
- ¿Se atreverá Twitter banear a Donald Trump cuando ...
-
►
2020
(Total:
212
)
- ► septiembre (Total: 21 )
-
►
2019
(Total:
102
)
- ► septiembre (Total: 14 )
-
►
2017
(Total:
231
)
- ► septiembre (Total: 16 )
-
►
2016
(Total:
266
)
- ► septiembre (Total: 38 )
-
►
2015
(Total:
445
)
- ► septiembre (Total: 47 )
-
►
2014
(Total:
185
)
- ► septiembre (Total: 18 )
-
►
2013
(Total:
100
)
- ► septiembre (Total: 3 )
-
►
2011
(Total:
7
)
- ► septiembre (Total: 1 )
Blogroll
Etiquetas
Entradas populares
-
Después de ver qué es una vCPU y la diferencia entre núcleos (cores) e hilos en los procesadores, pasamos a explicar toda la nomenclatura d...
-
Un fallo de diseño en el mecanismo de registro del servidor VPN de Fortinet puede aprovecharse para ocultar la verificación exitosa de cre...
-
Trinity asegura haber robado 560 GB de datos de la Agencia Tributaria (AEAT) española, así como haber secuestrado parte de sus sistemas, ci...
Securizar una RaspBerry Pi
La seguridad de la Raspberry Pi es importante. Las brechas en la seguridad pueden dejar la Raspberry Pi abierta a los piratas informáticos que luego pueden usarla con fines maliciosos. El nivel de seguridad que se necesita depende de cómo se vaya a usar la Raspberry Pi. Por ejemplo, si simplemente se está utilizando la Raspberry Pi en la red doméstica, detrás de un router que actua como un firewall, entonces, en principio ya es bastante seguro por defecto.
Sin embargo, si la Raspberry Pi va a estar directamente conectada a Internet, ya sea con una conexión directa (poco probable) o al permitir ciertos protocolos a través del firewall del router (por ejemplo, SSH), entonces se deben realizar algunos cambios de seguridad básicos. Incluso si se está protegido detrás de un firewall, es sensato tomarse la seguridad en serio. Los siguientes consejos describen algunas formas de mejorar la seguridad de la Raspberry Pi.
Consejos Básicos
Cambiar la contraseña predeterminada:
El sistema operativo Raspbian viene el nombre de usuario pi y la contraseña raspberry predeterminados, por lo tanto, si se obtiene acceso a una Raspberry Pi, y estas configuraciones no se han cambiado, se tiene acceso de root a esa Raspberry Pi. Así que lo primero que se debe hacer es cambiar la contraseña. Esto puede hacerse a través de la aplicación raspi-config o desde la línea de comando, ejecutando$ sudo raspi-config
passwd
Cambiar el nombre de usuario:
Se puede hacer que la Raspberry Pi sea un poco más segura cambiando también el nombre de usuario. Todas las Raspberry vienen con el nombre de usuario predeterminado pi, por tanto si se cambia, se consigue un poco más de seguridad. Para agregar un nuevo usuario se ejecuta:
$ sudo adduser elhackernet
se pedirá una nueva contraseña y el nuevo usuario tendrá el directorio de inicio en /home/elhackernet
Para agregar el nuevo usuario al grupo sudo para otorgarles permisos de sudo:
$ sudo adduser elhackernet sudo
Una vez que se ha confirmado que la nueva cuenta está funcionando, se puede eliminar el usuario pi. Sin embargo, hay que tener en cuenta que con la distribución actual de Raspbian, hay algunos aspectos que requieren que el usuario pi esté presente. Si no se está seguro de si esto va a afectar, es mejor no eliminar al usuario pi. Desde la web oficial de la Raspberry Pi informan que se está trabajando para reducir la dependencia del usuario pi. Para eliminar el usuario pi, se ejecuta:
$ sudo deluser pi
Este comando eliminará al usuario pi, pero no la carpeta /home/pi. Si es necesario, se puede usar el siguiente comando para eliminar la carpeta de inicio del usuario pi al mismo tiempo,
$ sudo deluser -remove-home pi
pero hay que tener en cuenta que los datos de esta carpeta se borrarán de forma permanente, por lo tanto, hay que asegurarse de que los datos necesarios estén almacenados en otro lugar.
Hacer que sudo pida contraseña
Al colocar sudo delante de un comando, se ejecuta como superusuario y, de forma predeterminada, no necesita una contraseña. En general, esto no es un problema. Sin embargo, si la Raspberry Pi está expuesta a Internet y de alguna manera se consigue acceder a ella (tal vez mediante un exploit de página web, por ejemplo), el atacante podrá cambiar cosas que requieren credenciales de superusuario, a menos que se haya configurado sudo para requerir una contraseña. Para forzar que sudo requiera contraseña, hay que ejecutar la siguiente orden:
$ sudo nano /etc/sudoers.d/010_pi-nopasswd
se edita el archivo y se cambia la entrada pi (o los nombres de usuario que tengan derechos de superusuario) a:
pi ALL=(ALL) PASSWD: ALL
Para hacer que sudo no pida contraseña:
pi ALL=(ALL) NOPASSWD:ALL
Seguridad
- Instalar y configurar el cortafuegos ufw
- Cambiar los puertos por defecto
- Asegurar el servidor SSH
- Fail2ban
- Crear un túnel SSH
Instalar y configurar el cortafuegos ufw
Sin un cortafuegos activo, nuestra Raspberry está expuesta a recibir posibles ataques e intrusiones desde Internet (o incluso desde otros ordenadores de la red local). El cortafuegos nos permite vigilar los puertos de comunicaciones y controlar todo lo que entra en nuestra máquina desde el exterior y también todo lo que sale de ella hacia el exterior. De todas las posibilidades que ofrece Raspberry Pi OS, hemos elegido ufw porque, a nuestro juicio, es el más fácil de configurar. De hecho, su nombre se correspone con el acrónimo de uncomplicated firewall (cortafuegos sin complicaciones).
Así pues, vamos a instalarlo:
sudo apt install ufw
Por defecto, el firewall ya incorpora un par de reglas básicas: impide todo el tráfico entrante, pero permite el tráfico saliente. Esto sería el equivalente a escribir estas dos reglas:
sudo ufw default deny incoming
sudo ufw default allow outgoing
Puertos y servicios
Para trabajar con ufw y manejar los puertos es necesario saber que cada puerto admite dos protocolos: tcp y udp. Al abrir un puerto debemos indicar, como veremos más adelante, el protocolo correspondiente.
Para facilitarnos la tarea, el cortafuegos trae ya predefinidos algunos de los servicios más habituales. Para conocer la lista completa de estos servicios, escribimos el siguiente comando:
sudo ufw app list
Esto significa que podemos permitir la entrada, por ejemplo, al servidor SSH indicando el número del puerto:
sudo ufw allow 22/tcp
o por el nombre del servicio:
sudo ufw allow SSH
Lo mismo sucede en el caso del servidor web que tengamos instalado, ya sea éste Apache, Nginx, Lighttpd o cualquier otro. Podemos hacerlo de las dos maneras que acabamos de ver; bien abriendo directamente el puerto:
sudo ufw allow 80/tcp
o bien haciendo referencia al servicio correspondiente:
sudo ufw allow WWW
También viene predefinido el protocolo CIFS, que es el que usa el servidor Samba. Gracias a ello es posible abrir los puertos correspondientes (ya que son varios) fácilmente:
sudo ufw allow CIFS
En los dos siguientes párrafos vamos a abrir los puertos que utilizan otros servicios que tenemos instalados en la Raspberry. El primero que abriremos será el puerto 9091, que es el que viene asignado por defecto para acceder a Transmission mediante el navegador web, y también el puerto que hayamos indicado en la configuración del programa para establecer las conexiones (supongamos que es el 44027):
sudo ufw allow 9091/tcp
sudo ufw allow 44027/tcp
Asimismo lo vamos a hacer con los puertos 21, 8200 y 1194, que se refieren, respectivamente, a los servidores FTP, DLNA y OpenVPN que tenemos instalados en nuestro sistema:
sudo ufw allow 21/tcp
sudo ufw allow 8200/tcp
sudo ufw allow 1194/udp
Servicios LAN
Opcionalmente, para aquellos servicios que vayamos a usar exclusivamente dentro de nuestra LAN, es decir, sólo de forma interna y que, por tanto, no necesitan salir a Internet (como DLNA, CUPS, Samba o RPi-Monitor), en lugar de abrir por separado cado uno de los puertos que corresponden a esos servicios (como hemos hecho antes), podemos decirle al cortafuegos, de una sola vez, que acepte todas las conexiones provenientes de cualquier dispositivo de nuestra red local:
sudo ufw allow from 192.168.1.0/24
O que acepte sólo las destinadas a un puerto concreto:
sudo ufw allow from 192.168.1.0/24 to any port 22
Intervalos de puertos
Si tenemos la necesidad de abrir varios puertos consecutivos (por ejemplo, del 25000 al 30000, como en el caso de los puertos pasivos del servidor FTP), podemos abrirlos todos de una vez:
sudo ufw allow 25000:30000/tcp
Denegar entradas
Lo mismo que creamos reglas para permitir la entrada por un puerto y acceder al servicio asociado al mismo, también podríamos, si fuera necesario, denegarla. Por ejemplo, impedir el acceso al servidor web:
sudo ufw deny 80/tcp [HTTP]
sudo ufw deny 443/tcp [HTTPS]
O denegar el acceso a un determinado host indicando su IP:
sudo ufw deny from 192.168.1.35 to any [red local/LAN]
sudo ufw deny from 202.54.5.7 to any [red externa/WAN]
Es posible especificar la IP y también el puerto:
sudo ufw deny from 202.54.1.5 to any port 80
Pero si ya tenemos reglas previamente establecidas para ese puerto (por ejemplo, sudo ufw allow 80/tcp), entonces es necesario que la nueva regla se ejecute antes, por lo que hemos de darle prioridad colocándola en primer lugar:
sudo ufw insert 1 deny from 202.54.1.5 to any port 80
Borrar reglas
A la hora de borrar una regla ya establecida, lo más cómodo es usar el siguiente comando, que nos las ofrece numeradas:
sudo ufw status numbered
De esta forma, sólo tenemos que indicar su número en el listado. Por ejemplo:
sudo ufw delete 2
Aunque también es posible hacerlo indicando el puerto (o puertos) incluido/s en la regla que queremos eliminar:
sudo ufw delete allow 22/tcp
Interfaces de red
Con el comando ifconfig se nos muestran todas las interfaces de red que tenenos activas. Si queremos aplicar reglas sólo a la interfaz Ethernet (eth0), haremos lo siguiente:
sudo ufw allow in on eth0 to any port 80/tcp
Si, por el contrario, deseamos que se aplique a la interfaz inalámbrica (wlan0), usaremos este nombre en la regla:
sudo ufw allow in on wlan0 to any port 22/tcp
Comandos importantes
Veamos otros comandos importantes. Por ejemplo, una vez instalado el cortafuegos y definidas las reglas, es necesario activarlo:
sudo ufw enable
También podemos desactivarlo:
sudo ufw disable
Reiniciarlo:
sudo /etc/init.d/ufw restart
Mostrar su estado:
sudo ufw status verbose
O borrar todas las reglas de una vez y dejar ufw por defecto:
sudo ufw reset
Con ufw ya configurado y activado, podremos acceder a través de la red (tanto LAN como WAN) a las distintas aplicaciones y servidores que hemos ido instalando en la Raspberry Pi. Es muy importante recordar esto: si queremos tener acceso a un servicio instalado en nuestra placa, ya sea desde la red local o a través de Internet, tenemos que abrir antes el puerto correspondiente en el cortafuegos (tanto para acceso LAN como WAN) y en el router (sólo para acceso WAN). Si no lo hacemos, ufw impedirá el acceso y no podremos conectar con dicho servicio.
Cambiar los puertos por defecto
Además de usar un cortafuegos, una buena manera de proteger aún más nuestra máquina contra posibles intrusiones externas es cambiar los puertos por defecto de los distintos servicios que estemos usando. Tomemos como ejemplo los puertos estándar de los servidores SSH y HTTP (servidor web), que son el 22 y el 80, respectivamente. En el fichero de configuración /etc/ssh/sshd_config podemos modificar el puerto del servidor SSH, mientras que en el fichero /etc/apache2/ports.conf es posible hacer lo mismo con el servidor web Apache.
Si lo hacemos, hemos de tener en cuenta que a partir de entonces, cuando queramos acceder al servicio correspondiente, debemos incluir el número del puerto. Por ejemplo, si cambiamos el puerto de Apache al 3030, ahora tendremos que escribirlo al final y precedido de dos puntos (:), así:
http://192.168.1.33:3030
http://midominio.com:3030
En el caso del servidor SSH, lo indicaremos con -p puerto, del siguiente modo:
ssh -p 3426 pi@192.168.1.33
ssh -p 3426 pi@midominio.com
Asegurar el servidor SSH
Si accedemos a nuestra Raspberry mediante SSH a través de Internet, deberíamos de preocuparnos por asegurar el servidor, ya que los intentos de acceso no autorizado a los servidores SSH son muy frecuentes. Veamos a continuación algunos parámetros que podemos modificar o añadir para que nuestro servidor SSH esté más seguro.
Lo primero que tenemos que hacer es entrar en el archivo de configuración para realizar los cambios:
sudo nano /etc/ssh/sshd_config
Veremos una gran cantidad de opciones de configuración en él. Una de las primeras que encontraremos es la que indica el puerto de acceso al servidor, que por defecto es el 22. Si lo cambiamos (poniendo, por ejemplo, el puerto 3426), dificultaremos mucho el trabajo a quien intente acceder a nuestra máquina:
Port 3426
Algo importante que debemos comprobar es la directiva de seguridad que permite o deniega el acceso a root, el superusuario o administrador de los sistemas UNIX/Linux. Muchos de los ataques que se realizan, especialmente contra servidores, se concentran en particular sobre este usuario con la esperanza de que tenga una contraseña débil, algo que (desgraciadamente) sucede con demasiada frecuencia.
Por defecto, la directiva que controla el acceso de root se encuentra así:
PermitRootLogin prohibit-password
Esto significa que se prohíben todos los métodos de autentificación interactivos, permitiendo sólo la autentificación mediante Publickey, Hostbased y GSSAPI. Sin embargo, es mucho más seguro no permitir el acceso del administrador del sistema de ninguna de las maneras. Por eso, lo que haremos será impedir la entrada a root de todas las formas posibles, sean cuales sean, lo que conseguiremos cambiando así esta línea:
PermitRootLogin no
Otra opción que podemos modificar es la que indica la cantidad de minutos que la pantalla de login estará disponible para que el usuario se identifique. Pasado ese tiempo, si no nos hemos identificado, la conexión se cerrará:
LoginGraceTime 1m
Prestaremos atención asimismo a las dos siguientes directivas de seguridad:
MaxAuthTries 3
MaxSessions 4
Sirven para dificultar los ataques de fuerza bruta. La primera indica el número máximo de errores permitidos al hacer login. Si sobrepasamos ese número, se nos mostrará un mensaje de error y habrá que volver a empezar de nuevo. La segunda directiva se refiere al número máximo de conexiones simultáneas por IP que permite el servidor.
También nos aseguraremos de que se exija el uso de una contraseña de acceso y que no acepte contraseñas vacías o en blanco:
PasswordAuthentication yes
PermitEmptyPasswords no
Si hay varios usuarios en el sistema, podemos añadir también al final del fichero de configuración una directiva para que sólo los usuarios especificados tengan acceso al mismo:
AllowUsers pi elhackernet
O, si se prefiere, usar en su lugar esta otra para permitir el acceso a todos menos a los que se indican expresamente en ella:
DenyUsers luisp manu root
Guardamos los cambios y comprobamos que la configuración del fichero es correcta, para lo cual hay que escribir este comando:
sudo sshd -t
Si no aparece ningún mensaje de error, es que todo está bien. Es importante comprobar que el archivo de configuración es correcto porque si no, cuando reiniciemos el servicio (o la propia Raspberry), el servidor SSH no arrancará y no podremos conectarnos.
Una vez que nos hemos asegurado de que todo está en orden, necesitamos reiniciar el servicio para que los cambios surtan efecto:
sudo service ssh restart
Periódicamente es aconsejable mirar el fichero /var/log/auth.log para comprobar si ha habido algún intento de entrada ilegal. Si los hubiese, el siguiente comando nos ayudará a encontrarlos:
sudo cat /var/log/auth.log | grep 'invalid user\|Failed'
Y este otro contará cuántas líneas con intentos de intrusión aparecen:
sudo cat /var/log/auth.log | grep 'invalid user\|Failed' | wc -l
Para finalizar, añadiremos un par de notas importantes:
- 1.) Las contraseñas de usuario que usemos deben de ser "fuertes", es decir, tener cierta extensión (8 caracteres o más) y estar compuestas por una combinación de letras (mayúsculas y minúsculas), números y signos de puntuación. Además, la palabra resultante no debe tener sentido, de manera que no aparezca en ningún diccionario.
- 2.) También podemos conectarnos empleando autentificación mediante clave pública, lo que nos ahorra el tener que memorizar la contraseña y además resulta más seguro.
Existen otras configuraciones recomendadas para evitar las conexiones no deseadas al servidor SSH:
- LoginGraceTime: Establece el tiempo necesario para introducir la contraseña, evitando que el atacante tenga que “pensar mucho”.
- MaxAuthTries: Número de intentos permitidos al introducir la contraseña antes de ser desconectados.
- MaxStartups: Número de logins simultáneos desde una IP, para evitar que se pueda utilizar la fuerza bruta con varias sesiones a la vez.
- AllowUsers: crear una lista blanca de usuario. Este parámetro permite configurar los usuarios que podrán conectarse. Una medida muy restrictiva pero a la vez muy segura ya que bloqueará todas las conexiones de los usuarios que no estén en el listado. Los usuarios que esten aquí podrán conectarse, y el resto no.
- DenyUsers: Parecido al anterior, pero ahora se crea una lista negra. Los usuarios que esten aquí no podrán conectarse, y el resto sí.
- AllowGroups/DenyUsers: Exactamente igual a lo anterior, pero en lugar de crear una lista blanca/negra de usuarios, es de grupos de usuarios.
Por ejemplo, un archivo de configuración de sshd_config sería el siguiente:
Port 22445
PermitRootLogin no
LoginGraceTime 30
MaxAuthTries 3
MaxStartups 3
AllowUsers elhackernet
DenyUsers pi
Desactivar re-envio de tráfico (pueden utilizar ssh para redireccionar tráfico)
AllowTCPForwarding No
Después de los cambios, se deberá reiniciar el servicio sshd utilizando (reiniciar para que los cambios surtan efecto)
$ sudo systemctl restart ssh
Fail2ban
Quienes deseen ir un paso más allá en la seguridad de sus servidores, pueden instalar el servicio Fail2ban, que vigila los intentos de acceso a los servidores que tengamos instalados y banea (bloquea) aquellas IPs que hayan hecho un intento ilegal de entrar en el sistema mediante fuerza bruta:
sudo apt install fail2ban
Accedemos al fichero de configuración:
sudo nano /etc/fail2ban/jail.conf
En la sección [DEFAULT] encontramos varias líneas relativas a la configuración genérica del servicio. Las fundamentales son: ignoreip (IPs que no deseemos que se baneen, que corresponden a localhost [127.0.0.1/8 ::1], y además añadiremos todas las IPs de nuestra red local [192.168.1.0/24]); bantime (tiempo de bloqueo); findtime (tiempo durante el que se espera hasta alcanzar el número máximo de intentos de acceso fallidos [maxretry] de un cliente) y maxretry (número de intentos de login fallidos para que se active el bloqueo).
[DEFAULT]
#
# MISCELLANEOUS OPTIONS
#
# "ignoreip" can be a list of IP address, CIDR masks or DNS hosts...
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24
bantime = 10m
findtime = 5m
maxretry = 3
. . . . . .
En el ejemplo anterior, el servicio se ha configurado de tal forma que, si durante un plazo de 5 minutos (findtime), un cliente (dirección IP) realiza 3 intentos fallidos de acceso (maxretry), su IP será bloqueada durante 10 minutos (bantime). Hasta que no transcurra dicho tiempo, no se le permitirá volver a hacer un nuevo intento de conexión.
Más abajo, en el apartado JAILS es donde se activa cada uno de los servicios que tengamos instalados. Así, en [sshd] activaremos la seguridad del servidor SSH contra ataques de fuerza bruta. Cada servicio se activa poniendo enabled = true al comienzo de su sección. La opción mode la podemos dejar como viene por defecto (normal). En port dejamos ssh si estamos usando el puerto por defecto (22) o bien pondremos el número de puerto por el que hayamos decidido cambiarlo. Si lo deseamos, es posible poner un bantime y un maxretry específicos para cada servicio. Las demás opciones las dejamos como están.
#
# JAILS
#
#
# SSH servers
#
[sshd]
# To use more aggressive sshd modes...
enabled = true
mode = normal
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
. . . . . .
Como se puede ver si continuamos bajando aún más en el fichero de configuración, Fail2ban se puede aplicar también a otros servidores que tengamos instalados (servidor web, servidor FTP, servidor MySQL/MariaDB, etc.). Por ejemplo, en el caso de tener un servidor web con Apache, deberíamos de activar al menos estos módulos:
#
# HTTP servers
#
[apache-auth]
enabled = true
. . . . . .
[apache-badbots]
enabled = true
. . . . . .
[apache-noscript]
enabled = true
. . . . . .
[apache-overflows]
enabled = true
. . . . . .
Acabada la configuración, sólo tenemos que reiniciar el servicio:
sudo service fail2ban restart
Comprobaciones
Desde este momento podremos realizar diversas comprobaciones, como conocer su estado:
sudo /etc/init.d/fail2ban status
Ver los servicos que tenemos activos:
sudo fail2ban-client status
O el estado actual de un servicio concreto (ssh en este caso), que nos mostrará si tiene alguna IP baneada en este momento:
sudo fail2ban-client status sshd
Se puede echar un vistazo al fichero de log para comprobar si ha habido intentos de acceso no autorizados:
sudo cat /var/log/fail2ban.log
Una forma más rápida de hacerlo es pedir que se nos muestren las IPs bloqueadas y en qué servicio han ocurrido:
sudo cat /var/log/fail2ban.log | grep "Ban"
También se puede bloquear una IP manualmente para un servicio concreto:
sudo fail2ban-client set apache-auth banip 192.168.1.27
O desbloquearla:
sudo fail2ban-client set apache-auth unbanip 192.168.1.27
Recibir un correo de alerta al bloquear una IP
Podemos hacer que Fail2ban nos envíe un correo cuando detecte un intento de intrusión y bloquee una determinada IP, informándonos de este hecho. Para lograrlo, lo primero que hemos de hacer es seguir los pasos para instalar un sistema de envío de correos desde la terminal.
Luego volvemos al fichero de configuración de Fail2ban:
sudo nano /etc/fail2ban/jail.conf
Dentro de él, en la sección # ACTIONS, localizamos y configuramos los siguientes parámetros:
destemail = Dirección de email para recibir los avisos sender = pi@raspberrypi [email usado en ciertas acciones] mta = mail [Servidor de correo que usaremos] action = %(action_mw)s [Está al final de la sección]
En la primera línea hemos de escribir la dirección de email en la que deseamos recibir los avisos, mientras que en las demás pondremos únicamente lo que aparece en color rojo.
Hecho lo anterior, guardamos los cambios realizados en el fichero y reiniciamos el servicio:
sudo service fail2ban restart
Comprobamos su estado para asegurarnos de que todo funciona correctamente:
sudo /etc/init.d/fail2ban status
- 1.- Si el servicio está activado [Active: active (running)], es que todo ha ido bien.
- 2.- Si, por el contrario, aparece un mensaje
de error, comprobamos que no hemos cometido níngún fallo al configurar
los datos del correo que introdujimos
más arriba. Una vez hecha la comprobación, ejecutamos lo
siguiente:
sudo service fail2ban stop
sudo service fail2ban start - Y observamos de nuevo que el servicio esté activado:
sudo /etc/init.d/fail2ban status
A partir de este momento, cada vez que haya un intento de acceso no autorizado y se bloquee la IP correspondiente, se nos enviará un aviso a la dirección de correo que hemos indicado, incluyendo información sobre la IP y el ISP desde los que se ha intentado acceder ilegalmente a nuestra máquina. Como medida de seguridad extra, también nos avisará (con un email por cada servicio que tengamos activado) cada vez que se detenga Fail2ban por algún motivo, incluyendo la desconexión o reinicio de la Raspberry.
Crear un túnel SSH
Si estamos fuera de casa, posiblemente tengamos la oportunidad de conectarnos a Internet a través de una red inalámbrica pública (de un hotel, bar, biblioteca,...) y navegar desde ella; pero hacerlo de esta forma tiene sus riesgos: alguien conectado a la misma red, y que esté usando un sniffer, podría, por ejemplo, obtener los nombres de usuario y las contraseñas que escribamos en el navegador si la web no usa el protocolo seguro HTTPS. Podríamos evitar esto y navegar de una forma segura si tuviéramos instalado un servidor VPN en nuestra Raspberry y nos conectáramos a él. Pero si no lo tenemos instalado, hay una alternativa sencilla que nos servirá para salir del paso: crear un túnel SSH y navegar de manera segura por él. La diferencia es que en el caso de la VPN, todo el tráfico entre el servidor y el cliente (lo que incluye cualquier servicio o aplicación que usemos) está cifrado, mientras que en la alternativa que vamos a explicar, sólo lo estará el tráfico que se genere en el navegador.
Vamos a realizar el proceso en dos pasos: primero configuramos el cliente SSH para crear el túnel y luego haremos los cambios oportunos en el navegador. Así pues, nos conectamos a la red inalámbrica pública. A continuación, si usamos Windows, arrancamos el cliente PuTTY y nos vamos a la categoría Connection - SSH - Tunnels. Ahí escribimos un puerto cualquiera (comprendido entre el 1025 y el 65535; por ejemplo, el 3590) en "Source port" y pinchamos en el botón "Add" para añadirlo. Luego en "Destination" marcamos "Auto" y "Dynamic". Nos debe de quedar así:
Despúes subimos hasta la categoría Session de PuTTY y en "Host Name" escribimos la IP pública de la RasPi (si tenemos IP fija) o un DNS dinámico (que podemos crear en No-ip, por ejemplo) para conectarnos con el servidor SSH remoto de nuestra Raspberry:
Hacemos clic en el botón "Open" y escribimos el nombre de usuario y contraseña para establecer la conexión SSH con la Raspberry Pi. Dejamos PuTTY abierto.
En el caso de que prefiramos usar la línea de comandos, ya sea en Linux, macOS o Windows, nos podemos ahorrar la configuración del cliente; tan sólo tendremos que teclear esto en una terminal:
ssh -D 3590 -p 22 pi@midominio.no-ip.org
cambiando, lógicamente, midominio.no-ip.org por el DDNS o la IP pública que tengamos.
Ahora arrancamos el navegador (Firefox en nuestro caso) y nos vamos a Opciones - Avanzado - pestaña Red. Hacemos clic en "Configuración" y ahí configuramos manualmente el Servidor SOCKS poniéndole la IP 127.0.0.1, el mismo puerto que abrimos antes para el túnel SSH (3590) y seleccionando "SOCKS v5" debajo. Debe de quedar así:
Pinchamos en "Aceptar" y ya podemos navegar con seguridad a través del túnel SSH que hemos creado. Pero antes debemos tener en cuenta un par de cosas:
- 1.) Naturalmente, es necesario que el puerto 22 esté abierto en el router y redirigido a la IP local de la RasPi para que la conexión con el servidor SSH funcione a través de Internet.
- 2.) Si por algún motivo la conexión SSH se desconectase, el navegador mostraría un error, de manera que nos daríamos cuenta enseguida de que el túnel ya no está funcionando.
Fuentes:
0 comentarios :
Publicar un comentario
Los comentarios pueden ser revisados en cualquier momento por los moderadores.
Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.
Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.