Desde marzo de este año no escribía en mi viejo blog, y no perdiendo la costumbre de publicar algo de vez en cuando y no frecuente, que no me gusta publicar todo lo que vea o haga, pero si lo que pueda ser útil, vamos a ver esta vez como configurar suricata un IDS muy nombrado últimamente y que se a hecho con méritos suficientes para ser considerado, ayudado claramente por unas reglas que alimenten su motor en este caso las reglas de emerging threats y estas descargadas y actualizadas por oinkmaster un script en perl que cumple con lo que dice.
Bien como es costumbre no voy a entrar en definiciones de lo que vamos a usar, para eso los enlaces de los proyectos que explican mejor que nadie sus proyectos y no adjudicarme malas definiciones o cosas que no existen.
http://suricata-ids.org/
http://oinkmaster.sourceforge.net/
Bien pues iniciemos.
1.Oinkmaster
1.1.Instalación y Configuración base Oinkmaster
Se creará un directorio sobre /etc de la siguiente forma.
Seguidamente ingresaremos al directorio con el comando "cd /etc/oinkmaster"
Se descarga el software como tal.
wget http://prdownloads.sourceforge.net/oinkmaster/oinkmaster-2.0.tar.gz
Descomprimimos el archivo dentro del directorio.
tar xvzf oinkmaster/oinkmaster-2.0.tar.gz
Movemos el contenido al directorio base "mv oinkmaster-2.0/* ."
Ahora ingresaremos al archivo de configuración oinkmaster.conf y agregaremos la siguiente linea al inicio o mitad del archivo.
url = https://rules.emergingthreatspro.com/open/suricata/emerging.rules.tar.gz
y al final de archivo las siguiente lineas
modifysid emerging-web_specific_apps.rules "alert" | "drop"
modifysid emerging-web_server.rules "alert" | "drop"
modifysid emerging-web_client.rules "alert" | "drop"
modifysid emerging-sql.rules "alert" | "drop"
modifysid emerging-scan.rules "alert" | "drop"
modifysid emerging-shellcode.rules "alert" | "drop"
modifysid emerging-worm.rules "alert" | "drop"
modifysid emerging-malware.rules "alert" | "drop"
modifysid emerging-icmp.rules "alert" | "drop"
modifysid emerging-exploit.rules "alert" | "drop"
Esto lo hacemos ya que nos interesa que se haga el drop de algunas cosas que se detecte y no solo haga el alert, de lo contrario seguiría en modo IDS, es cierto que con esta modificación nos exponemos a falsos positivos, pero preferimos correr el riesgo ;).
Adicionalmente estas reglas están pensadas para un servidor web, en el caso que se tenga otros tipos de servidores protegidos se deben activar otros módulos.
Con esto se finaliza las configuraciones de oinkmaster de momento, mas adelante se automatizará la actualización de las reglas a suricata.
2.Instalación y Configuración suricata IPS
2.1.Configuración del repositorio
Para el caso de suricata si se cuenta con repositorios de software desde el cual se puede obtener un paquete pre-compilado para poder instalarse el empaquetado.
Instalamos el repositorio con el siguiente comando.
yum -y install http://codemonkey.net/files/rpm/suricata/el7/suricata-release-el-7-1.el7.noarch.rpm
yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
2.2.Instalación de suricata
Debido a que ya se instalaron los repositorios la instalación se puede hacer con el siguiente comando.
yum -y install suricata
2.3.Configuración de suricata
La instalación por paquetes deja las configuraciones en el directorio /etc/suricata y dentro del mismo se encuentra su archivo de configuración suricata.yaml.
En la sección:
# a line based information for dropped packets in IPS mode
- drop:
enabled: no
filename: drop.log
append: yes
#filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'
yum -y install suricata
2.3.Configuración de suricata
La instalación por paquetes deja las configuraciones en el directorio /etc/suricata y dentro del mismo se encuentra su archivo de configuración suricata.yaml.
En la sección:
# a line based information for dropped packets in IPS mode
- drop:
enabled: no
filename: drop.log
append: yes
#filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'
Se recomienda el registro de las reglas drop, la configuración debería quedar de la siguiente forma.
# a line based information for dropped packets in IPS mode
- drop:
enabled: yes
filename: drop.log
append: yes
#filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'
En la sección se encuentra de la siguiente forma:
nfq:
# mode: accept
#repeat-mark: 1
#repeat-mask: 1
# route-queue: 2
# batchcount: 20
# fail-open: yes
# a line based information for dropped packets in IPS mode
- drop:
enabled: yes
filename: drop.log
append: yes
#filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'
En la sección se encuentra de la siguiente forma:
nfq:
# mode: accept
#repeat-mark: 1
#repeat-mask: 1
# route-queue: 2
# batchcount: 20
# fail-open: yes
Hay que configurarla de la siguiente manera:
nfq:
mode: repeat
# mode: accept
repeat-mark: 1
repeat-mask: 1
# route-queue: 2
# batchcount: 20
# fail-open: yes
nfq:
mode: repeat
# mode: accept
repeat-mark: 1
repeat-mask: 1
# route-queue: 2
# batchcount: 20
# fail-open: yes
Los valores "mode: repeat" es básicamente para re-inyectar los paquetes a la tabla de netfilter una vez procesados los paquetes.
Los valores "repeat-mark: 1" y "repeat-mask: 1" son para descartar los paquetes que ya fueron procesados previamente, de no habilitar estos valores y en conjunto con las reglas de iptables los paquetes entrarán en un ciclo infinito el cual llevará a una saturación de la máquina y por ende no funcionamiento del router.
Debido a que el IPS es relativamente sencillo y no aporta complejidad en lo referente a infraestructura, las configuraciones se pueden dejar en este momento tal cual.
2.4. Configuración del servicio de inicio
Para que suricata inicie en modo de ips es necesario que haga el hook a la pila de netfilter y por ello es necesario cambiar las lineas de inicio, esto se debe realizar en el archivo "/etc/sysconfig/suricata" la linea de options debe quedar así como se muestra en el siguiente texto:
OPTIONS="-q 0 "
Nota: No se debe especificar la interfaz de red ya que se coloca dentro de la pila de netfilter.
De esta forma cada vez que manipulemos el servicio suricata se colocará en modo IPS.
2.5.Des-configuración de firewall por defecto
Para poder configurar las reglas de iptables necesarias para que funcione y sea un poco mas cómoda la configuración del firewall local se opta por des-habilitar el servicio instalado por defecto, esto lo hacemos con el comando:
systemctl disable firewalld.service
systemctl stop firewalld.service
2.6.Habilitar el firewall basado en iptables
En el paso anterior se deshabilito el firewall por defecto, ahora se debe instalar el firewall clásico, esto lo podemos lograr con el siguiente comando:
yum -y install iptables-services.x86_64
2.7.Configuración de servicio de iptables
Lo primero que debemos hacer es configurar las reglas por defecto que trae el servicio, editaremos el archivo en la ruta "/etc/sysconfig/iptables" el contenido de dicho archivo debe ser igual al siguiente, las demás reglas se agregarán en secciones adelante.
# sample configuration for iptables service
# you can edit this manually or use system-config-firewall
# please do not ask us to add additional ports/services to this default configuration
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A FORWARD -j NFQUEUE
COMMIT
Es de importancia mencionar que estas son las reglas por defecto y es en donde se define la política a denegar, así como se hace el gancho de iptables para que el trafico forward sea manejado por suricata.
Adicionalmente vamos a separar las reglas de iptables en otro archivo, una mala practica inicialmente pero por cuestiones de ser practicos lo voy a hacer, ustedes pueden traducir estas reglas e insertarlas directamente sobre el archivo de iptables, si no hacen esto el reiniciar las reglas de iptables borrará las reglas personalizadas y los dejará sin IPS y sin servicios (no les iba a dejar todo tan fácil no?, pues si fácil pueden exportar las reglas de iptables con iptables-save y luego importarlas y con eso ya estarán cargadas en el archivo anterior, de nada :p)
3.Scripts adicionales
3.1.Script de suricata IPS
Todo sistema necesita de scripts para mejorar o para complementar su funcionalidad y en este caso no es la excepción por lo tanto se a creado un directorio dentro del "/root" llamado "scripts" el cual contiene dos archivos llamados "startsuricata.sh" y "updaterules.sh"; el contenido del primer archivo es el siguiente:
#!/bin/bash
# Activado de FORWARD de paquetes
echo 1 > /proc/sys/net/ipv4/ip_forward
#Reglas de PREROUTING
# segmento de ssh
iptables -t nat -F PREROUTING
iptables -t nat -I PREROUTING -s 200.x.x.x -d 192.168.10.2 -p tcp --dport 22 -j DNAT --to-destination 192.168.2.10
#segmento de servicio
iptables -t nat -I PREROUTING -d 192.168.10.2 -p tcp -m multiport --dports 80,443 -j DNAT --to-destination 192.168.2.10
#Reglas de postrouting o masquerading
iptables -t nat -F POSTROUTING
iptables -t nat -I POSTROUTING -o ens192 -j MASQUERADE
Nota 2: la maquina tiene dos interfaces de red una que apunta a la WAN que es ens192 y otra a la LAN ens224.
La primera sección activamos el forward de paquetes a nivel de kernel, sin esto el IPS y el firewall no funcionarán.
El segmento de PREROUTING es básicamente el direccionamiento interno del trafico acorde al mapeo de puertos.
La ultima sección hace referencia al enmascarado de salida del trafico, esto para que el trafico saliente se vea que es generado por el IPS y no se revele información de las máquinas internas.
Este script debe ser mencionado en el script de inicio del sistema "/etc/rc.local" el cual se debería ver de la siguiente forma (o utilizar el tip de exportar e importar de iptables ;)) :
#!/bin/bash
# THIS FILE IS ADDED FOR COMPATIBILITY PURPOSES
#
# It is highly advisable to create own systemd services or udev rules
# to run scripts during boot instead of using this file.
#
# In contrast to previous versions due to parallel execution during boot
# this script will NOT be run after all other services.
#
# Please note that you must run 'chmod +x /etc/rc.d/rc.local' to ensure
# that this script will be executed during boot.
/root/scripts/startsuricata.sh
touch /var/lock/subsys/local
El segmento de PREROUTING es básicamente el direccionamiento interno del trafico acorde al mapeo de puertos.
La ultima sección hace referencia al enmascarado de salida del trafico, esto para que el trafico saliente se vea que es generado por el IPS y no se revele información de las máquinas internas.
Este script debe ser mencionado en el script de inicio del sistema "/etc/rc.local" el cual se debería ver de la siguiente forma (o utilizar el tip de exportar e importar de iptables ;)) :
#!/bin/bash
# THIS FILE IS ADDED FOR COMPATIBILITY PURPOSES
#
# It is highly advisable to create own systemd services or udev rules
# to run scripts during boot instead of using this file.
#
# In contrast to previous versions due to parallel execution during boot
# this script will NOT be run after all other services.
#
# Please note that you must run 'chmod +x /etc/rc.d/rc.local' to ensure
# that this script will be executed during boot.
/root/scripts/startsuricata.sh
touch /var/lock/subsys/local
3.2.Actualización de reglas de suricata con oinkmaster
El siguiente script es "updaterules.sh" el cual se encarga de la actualización de las reglas del IPS, esto es muy importante ya que unas horas pueden marcar la diferencia a la hora de comprometer un sistema; el contenido de dicho script es el siguiente:
#!/bin/bash
/etc/oinkmaster/oinkmaster.pl -C /etc/oinkmaster/oinkmaster.conf -o /etc/suricata/rules
Adicionalmente se debe agregar un contrab al sistema para que la tarea se automatice de lo contrario el script no servirá de nada, ejecutamos el comando "crontab -e" como usuario root y colocamos la siguiente linea:
0 */6 * * * /root/scripts/updaterules.sh
Esto actualizará las reglas de oinkmaster cada seis horas, adicionalmente aplicando las tareas internas de dicho software.
Junto con esto es recomendable hacer un restart de suricata para que refresque las reglas regularmente, esto no corta el trafico forward así que lo pueden hacer con tranquilidad.
Nota3: para un trafico de aproximadamente unos 50 MB/s se estan utilizando dos procesadores en un ambiente virtual y 2 GB de RAM.
Eso a sido todo por esta vez mis queridos lectores de ocasión, espero que le sea útil a alguien y si se puede mejorar el algo (claro que se puede mejorar, sobre todo las reglas de iptables o dejar a un lado iptables y hacer directamente con firewalld :)) son bienvenidos los comentarios.
No hay comentarios:
Publicar un comentario