Publicado el 19/03/2023 12:03:00 en Seguridad.
Author: MuldeR | Total de votos: 5   Vote

Hola a todos, aprovechando que estoy configurando el server lo mejor que puedo , publico mi primer artículo en DDLR 3.0 para que me ayuden a hacer el server más seguro y de paso hacemos entre todos una guía completa de configuración de apache, php, mysql y linux enfocándonos en la seguridad de servicios web. Seguro que con su ayuda saldrá un artículo muy completo e interesante, así que los insto a colaborar con cualquier idea que se les ocurra ;)

Configurando apache2.conf:

Para encontrar el config de apache:

grep -r "Directory /var/www" /etc/apache2

Abrimos con nuestro editor favorito el apache2.conf

vim /etc/apache2/apache2.conf

Para buscar la fila a editar pulsamos:

?/var/www[enter]

Finalmente editamos agregando un - al comienzo de Indexes:

<Directory /var/www/>
	Options -Indexes
</Directory>

Ahora vamos a añadir al final del fichero las siguientes directivas, para ocultar la versión de apache y desactivar el Trace:

ServerSignature Off
ServerTokens Prod
TraceEnable off

Thanks Scully ;)

Permisos correctos:

chown -R www-data:www-data *
chmod -R * 755
chmod -R *.* 644

Con esos tres comandos nos aseguramos de tener permisos adecuados en www y en todos los subdirections, la R es de recursive, 755 es lectura escritura y ejecución para el owner y lectura ejecución para los demás en todos los archivos, el 644 en *.* pone lectura y escritura en el owner y lectura solamente para todos los demás en los archivos con extensión, dejando así los directorios con 755 y los archivos con 644.

Forzar SSL en Apache

Para empezar a hablar de seguridad es necesario asegurarnos de que todas las peticiones sean atendidas de forma cifrada y segura, para crear un certificado seguro y gratuito es posible utilizar certbot de let's encrypt, o cualquier certificado que les guste, creo que ello excede el alcance de este artículo, pero no quería dejar de mencionarlo. Para asegurarnos de forzar SSL en TODOS los dominios del server es posible agregar en /etc/apache2/sites-enabled/* las siguientes líneas:

RewriteEngine on
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

Para esto se requiere mod_rewrite activado y funcionando: # sudo a2enmod rewrite

DoS - Mod Evasive:

apt install apache2-util
apt install libapache2-mod-evasive
find / -name "evasive.conf"
mkdir /var/log/mod_evasive
vim /etc/apache2/mods-enabled/evasive.conf

Aquí pueden tocar los valores a gusto, solo asegúrense de quitar los comentarios en las funciones que deseen activar.

Añadiendo algo de seguridad al php.ini:

En primer lugar vamos a buscar la ruta del php.ini, elegimos la que se encuentre en nuestro servidor, en este caso apache2

find / -name "php.ini"
vim /etc/php/7.4/apache2/php.ini

Ahora vamos a buscar las siguientes variables y a configurarlas a nuestra conveniencia

~ max_filesize 20
~ post_max_size 20
~ session.gc_maxlifetime 604800 # aquí se requiere una sesión de hasta 7 días
~ session.cookie_lifetime 604800
~ register_globals = Off 
~ allow_url_fopen = Off #desactivamos posibles includes remotos, etc.
~ disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source # se explica en (1)
~ expose_php = Off #no muestra versión de php
~ session.cookie_httponly = On #la sessión solo será accesible por http, limitando el daño de csrf, xss, etc.
~ session.use_only_cookies = On # evita que la session pueda pasarse por get, en la url
~ session.cookie_secure = On # fuerza la flag secure en la cookie de sesión
~ display_errors = Off #esconde errores
~ user_ini.filename = #desactiva la posibilidad de cargar php.ini custom para los usuarios del server

MySQL: permisos mínimos y necesarios al user:

SELECT user FROM mysql.user
GRANT SELECT, INSERT, UPDATE ON * . * TO 'user'@'localhost' identified by 'passwd';
show grants for 'user'@'localhost';

Así le concedemos los permisos justos y necesarios, revocando por descarte todos los demás.

Mod Security

apt install libapache2-mod-security2
a2enmod security2
cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
vim /etc/modsecurity/modsecurity.conf

Ahora cambiamos SecRuleEngine DetectionOnly por SecRuleEngine On, de este modo quedará activado con la configuración básica.

while (1=1) { $PARANOIA_LEVEL++;}

Si el server no va a recibir demasiados inputs de usuarios es posible configurar los hiper paranóicos filtros de OWASP, para ello vamos a clonar y configurar el core rule set, que contiene un compendio de reglas muy amplio para la mayoría de ataques conocidos.

git clone https://github.com/coreruleset/coreruleset.git
cd coreruleset/
mv crs-setup.conf.example /etc/modsecurity/crs-setup.conf
/etc/apache2/mods-enabled/security2.conf
vim /etc/apache2/mods-enabled/security2.conf

Ahora nos aseguramos de incluir el nuevo directorio de reglas en el security2_module:

<IfModule security2_module>
#...
#...
IncludeOptional /etc/modsecurity/*.conf
Include /etc/modsecurity/rules/*.conf
#...

Y para finalizar reiniciamos apache con # sudo apache2ctl restart

Instalando DDoS Deflate:

Primero vamos a instalar las dependencias:

sudo apt install dnsutils
sudo apt-get install net-tools
sudo apt-get install tcpdump
sudo apt-get install dsniff -y
sudo apt install grepcidr

Ahora vamos a descargar e instalar el conocido script:

wget https://github.com/jgmdev/ddos-deflate/archive/master.zip -O ddos.zip
unzip ddos.zip
cd ddos-deflate-master
./install.sh

Probablemente tenga algunos errores, en mi caso no encontraba iptables, bastó con abrir ddos.sh y editar las líneas que llamar a iptables añadiendo un "/sbin/" al comienzo del comando, quedando así: /sbin/iptables

Instalar fail2ban:

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.

Para instalarlo en debian based es suficiente con ejecutar el siguiente comando:

apt install fail2ban

sudo systemctl status fail2ban

Para configurarlo vamos a hacer una copia de jail.conf a jail.local y lo abrimos con nuestro editor favorito:

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

Ahora a configurarlo, una buena idea sería añadir la ip de los administradores a la ignorelist:

ignoreip = 127.0.0.1/8 ::1 111.111.111.111 111.222.333.0/24

Donde 111.111.111.111 sería una IP estática y 111.222.333.0/24 sería todo el rango de IP variables del proveedor de internet.

A continuación configuraremos el tiempo del ban y el máximo de intentos fallidos antes de banear la IP remota:

bantime  = 1d
findtime  = 60m
maxretry = 5

Con esas modificaciones configuraremos el script para banear por 24 horas todas las IPs que hayan realizado 5 intentos fallidos de login en una hora.

Se puede hablar de carceles (jails) y muchísimas otras configuraciones de este potente script, pero excede a los fines de éste artículo. Y hay ya mucha info en internet: https://www.fail2ban.org/wiki/index.php/Main_Page

Para finalizar vamos a reiniciarlo para cargar la nueva config y utilizar el fail2ban-client para ver el status de sshd:

# systemctl restart fail2ban

# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  '- File list:	/var/log/auth.log
'- Actions
   |- Currently banned:	5
   |- Total banned:	5
   '- Banned IP list:	1.234.23.131 128.199.147.72 139.59.186.183 200.35.2.209 43.163.220.33

Nota: se puede utilizar fail2ban para monitorear logs de cualquier servicio, incluido apache, la cuestión es que a nosotros no nos sirve ya que estamos utilizando ip masking vía cloudflare proxy y no tendría sentido banear las ips de cloudflare, por lo tanto limitaremos el uso a sshd. En cualquier caso configurando la sección del jail de [apache] se puede añadir filter = apache-auth para banear los intentos fallidos de login, se puede activar [apache-overflows] para intentar bloquear solicitudes inusualmente largas, se puede banear a los [apache-badbots] y muchas cosas mas que pueden consultar en la documentación oficial :D

Aclaraciones y despedida:

Por supuesto estas son solo algunas medidas, se pueden tomar muchas mas dependiendo del nivel de paranoia, lo crítico que resulte un fallo en el servicio y la importancia de los datos contenidos en el servidor. Si consideran que falta algo importante, tienen alguna recomendación para hacer o alguna crítica constructiva sírvanse de los comentarios para ayudarme a completar y mejorar el artículo. Gracias por leer y colaborar !!

(1) Detalle de las funciones desabilitadas

exec(): Ejecuta un comando en el sistema operativo y devuelve la salida. Esta función puede ser peligrosa porque permite la ejecución de comandos arbitrarios en el sistema.

    passthru(): Imprime la salida de un comando en la salida estándar. Al igual que exec(), esta función permite la ejecución de comandos arbitrarios en el sistema.

    shell_exec(): Ejecuta un comando en el sistema operativo y devuelve la salida como una cadena. Al igual que exec() y passthru(), esta función permite la ejecución de comandos arbitrarios en el sistema.

    system(): Ejecuta un comando en el sistema operativo y devuelve la salida. Esta función es similar a exec() y shell_exec(), y también permite la ejecución de comandos arbitrarios en el sistema.

    proc_open(): Abre un proceso y devuelve un identificador de archivo que puede ser utilizado para leer o escribir en el proceso. Esta función puede ser peligrosa porque permite la ejecución de procesos arbitrarios en el sistema.

    popen(): Abre un proceso y devuelve un identificador de archivo que puede ser utilizado para leer o escribir en el proceso. Al igual que proc_open(), esta función permite la ejecución de procesos arbitrarios en el sistema.

    curl_exec(): Ejecuta una solicitud HTTP utilizando la biblioteca cURL y devuelve la respuesta como una cadena. Esta función puede ser peligrosa porque permite la ejecución de solicitudes HTTP arbitrarias desde el servidor.

    curl_multi_exec(): Ejecuta múltiples solicitudes HTTP utilizando la biblioteca cURL. Al igual que curl_exec(), esta función puede ser peligrosa porque permite la ejecución de solicitudes HTTP arbitrarias desde el servidor.

    parse_ini_file(): Analiza un archivo INI y devuelve sus valores en un array. Esta función puede ser peligrosa porque permite la lectura de archivos arbitrarios en el sistema.

    show_source(): Imprime el código fuente de un archivo PHP en el navegador. Esta función puede ser peligrosa porque permite la exposición de código fuente y vulnerabilidades potenciales a los atacantes.