En hemos explicado cómo ejecutar una versión estable de Suricata en Ubuntu 18.04 LTS. Configurar un IDS en un solo nodo y conectar conjuntos de reglas gratuitos es bastante sencillo. Hoy veremos cómo proteger la red corporativa de los tipos de ataques más comunes utilizando Suricata instalada en un servidor virtual. Para ello, necesitaremos un VDS en Linux con dos núcleos de procesamiento. La cantidad de RAM depende de la carga: algunos pueden necesitar solo 2 GB, mientras que tareas más serias pueden requerir 4 o incluso 6. La ventaja de una máquina virtual radica en las posibilidades de experimentación: se puede comenzar con una configuración mínima y aumentar los recursos según sea necesario.
foto: Reuters
Uniendo redes
Mover el IDS a una máquina virtual puede ser necesario, principalmente para realizar pruebas. Si nunca has trabajado con soluciones así, no es aconsejable apresurarse a adquirir hardware físico o cambiar la arquitectura de la red. Es mejor probar el sistema de manera segura y sin gastos innecesarios para determinar las necesidades de recursos computacionales. Es importante entender que todo el tráfico corporativo deberá pasar por un único nodo externo: para conectar la red local (o varias redes) al VDS con Suricata instalada, se puede utilizar — un servidor VPN multiplataforma fácil de configurar que proporciona una encriptación segura. La conexión de oficina a Internet puede no tener una IP real, por lo que es mejor levantarla en un VPS. En el repositorio de Ubuntu no hay paquetes listos, se tendrá que descargar el software desde , o desde un repositorio externo en el servicio (si le confías):
sudo add-apt-repository ppa:paskal-07/softethervpn
sudo apt-get updatePuedes ver la lista de paquetes disponibles usando el siguiente comando:
apt-cache search softether 
Necesitaremos softether-vpnserver (el servidor en configuración de prueba se ejecuta en el VDS), así como softether-vpncmd — utilidades de línea de comandos para su configuración.
sudo apt-get install softether-vpnserver softether-vpncmdPara la configuración del servidor se utiliza una utilería especial de línea de comandos:
sudo vpncmd 
No vamos a entrar en detalles sobre la configuración: el proceso es bastante sencillo, está bien documentado en numerosas publicaciones y no es directamente relevante para el tema de este artículo. En resumen, después de iniciar vpncmd, debes seleccionar la opción 1 para acceder a la consola de administración del servidor. Para ello, es necesario ingresar el nombre localhost y presionar enter en lugar de ingresar el nombre del hub. En la consola, estableces la contraseña de administrador con el comando serverpasswordset, eliminas el hub virtual DEFAULT (comando hubdelete) y creas uno nuevo llamado Suricata_VPN, así como estableces su contraseña (comando hubcreate). Luego, debes acceder a la consola de control del nuevo hub usando el comando hub Suricata_VPN para crear un grupo y un usuario con los comandos groupcreate y usercreate. La contraseña del usuario se establece con userpasswordset.
SoftEther admite dos modos de transmisión de tráfico: SecureNAT y Local Bridge. El primero es una tecnología patentada para la construcción de redes privadas virtuales con su propio NAT y DHCP. SecureNAT no requiere TUN/TAP ni configuración de Netfilter u otro firewall. La enrutación no afecta al núcleo del sistema, y todos los procesos están virtualizados y funcionan en cualquier VPS/VDS independientemente del hipervisor utilizado. Esto provoca una mayor carga en el procesador y una disminución de la velocidad en comparación con el modo Local Bridge, que conecta el hub virtual de SoftEther con un adaptador de red físico o un dispositivo TAP.
La configuración en este caso se complica, ya que la enrutación ocurre a nivel de núcleo mediante Netfilter. Nuestros VDS están basados en Hyper-V, por lo que en el último paso creamos un puente local y activamos el dispositivo TAP con el comando bridgecreate Suricate_VPN -device:suricate_vpn -tap:yes. Después de salir de la consola de administración del hub, veremos en el sistema una nueva interfaz de red que aún no tiene una IP asignada:
ifconfig 
Luego tendrás que habilitar el enrutamiento de paquetes entre interfaces (ip forward) si no está activo:
sudo nano /etc/sysctl.confDescomentar la siguiente línea:
net.ipv4.ip_forward = 1Guardamos los cambios en el archivo, salimos del editor y aplicamos los cambios con el siguiente comando:
sudo sysctl -pLuego necesitamos definir para la red virtual un subred con IPs ficticias (por ejemplo, 10.0.10.0/24) y asignar una dirección a la interfaz:
sudo ifconfig tap_suricata_vp 10.0.10.1/24Después necesitarás establecer las reglas de Netfilter.
1. Si es necesario, permite paquetes entrantes en los puertos escuchados (el protocolo propietario de SoftEther utiliza HTTPS y el puerto 443)
sudo iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 992 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
sudo iptables -A INPUT -p udp -m udp --dport 1194 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 5555 -j ACCEPT2. Configuramos NAT desde la subred 10.0.10.0/24 a la IP principal del servidor
sudo iptables -t nat -A POSTROUTING -s 10.0.10.0/24 -j SNAT --to-source 45.132.17.1403. Permitimos paquetes que pasen desde la subred 10.0.10.0/24
sudo iptables -A FORWARD -s 10.0.10.0/24 -j ACCEPT4. Permitimos paquetes que pasan para conexiones ya establecidas
sudo iptables -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPTDejaremos la automatización del proceso al reiniciar el sistema mediante scripts de inicialización como tarea para los lectores.
Si deseas asignar IP automáticamente a los clientes, también deberás instalar algún servicio DHCP para el puente local. Con esto, la configuración del servidor está completa y se puede pasar a los clientes. SoftEther soporta múltiples protocolos, el uso de los cuales depende de las capacidades del hardware de la red local.
netstat -ap |grep vpnserver 
Dado que nuestro router de prueba también funciona bajo Ubuntu, instalaremos desde un repositorio externo los paquetes softether-vpnclient y softether-vpncmd para aprovechar el protocolo propietario. Será necesario iniciar el cliente:
sudo vpnclient startPara la configuración, utilizaremos la utilidad vpncmd, eligiendo localhost como la máquina en la que se ejecuta vpnclient. Todos los comandos se hacen en la consola: será necesario crear una interfaz virtual (NicCreate) y una cuenta (AccountCreate).
En algunos casos, es necesario especificar el método de autenticación mediante los comandos AccountAnonymousSet, AccountPasswordSet, AccountCertSet y AccountSecureCertSet. Como no usamos DHCP, la dirección para el adaptador virtual se establece manualmente.
Además, necesitaremos habilitar el reenvío de IP (parámetro net.ipv4.ip_forward=1 en el archivo /etc/sysctl.conf) y configurar rutas estáticas. Si es necesario, en el VDS con Suricata se puede configurar el reenvío de puertos para utilizar los servicios establecidos en la red local. Con esto, la unión de redes puede considerarse completa.
La configuración que proponemos se verá aproximadamente así:
Configuramos Suricata
En Hemos hablado sobre dos modos de funcionamiento de IDS: a través de la cola NFQUEUE (modo NFQ) y a través de zero copy (modo AF_PACKET). El segundo requiere la presencia de dos interfaces, pero se caracteriza por un mayor rendimiento; nosotros usaremos este. El parámetro está configurado por defecto en /etc/default/suricata. También necesitaremos editar la sección vars en /etc/suricata/suricata.yaml, especificando allí la subred virtual como local.
Para reiniciar el IDS, usamos el comando:
systemctl restart suricataLa solución está lista, ahora puede que necesite comprobar su resistencia a las acciones de los atacantes.
Simulando ataques
Puede haber varios escenarios de uso práctico del servicio IDS externo:
Protección contra ataques DDoS (principal propósito)
Implementar este enfoque dentro de una red corporativa es complicado, ya que los paquetes a analizar deben pasar por la interfaz del sistema que mira hacia Internet. Incluso si el IDS los bloquea, el tráfico parasitario puede saturar el canal de transmisión de datos. Para evitar esto, es necesario contratar un VPS con una conexión a Internet lo suficientemente potente como para manejar todo el tráfico de la red local y todo el tráfico externo. A menudo, esto es más fácil y barato que ampliar el canal de la oficina. Como alternativa, vale la pena mencionar los servicios especializados de protección contra DDoS. El costo de sus servicios es comparable al costo de un servidor virtual; no se requiere una configuración laboriosa, pero hay desventajas: por su dinero, el cliente solo obtiene protección contra DDoS, mientras que el propio IDS se puede configurar de cualquier manera.
Protección contra otros tipos de ataques externos
Suricata puede manejar intentos de explotación de diversas vulnerabilidades en los servicios de la red corporativa disponibles desde Internet (servidor de correo, servidor web y aplicaciones web, etc.). Normalmente, el IDS se instala dentro de la red local después de los dispositivos de borde, pero también tiene sentido colocarlo fuera.
Protección contra intrusos internos
A pesar de todos los esfuerzos del administrador del sistema, las computadoras de la red corporativa pueden estar infectadas con malware. Además, a veces aparecen gamberros en la red local que intentan realizar ciertas operaciones indebidas. Suricata puede ayudar a bloquear esos intentos, aunque para proteger la red interna es mejor instalarla dentro del perímetro y usarla junto con un conmutador gestionado que sepa reflejar el tráfico a un solo puerto. Un IDS externo en este caso también no es inútil: al menos podrá atrapar los intentos de los malware en la LAN de comunicarse con un servidor externo.
Para comenzar, crearemos otra VPS atacante de prueba, y en el enrutador de la red local levantaremos Apache con la configuración por defecto, después de lo cual haremos un reenvío del puerto 80 desde el servidor IDS. Luego simularemos un ataque DDoS desde el nodo atacante. Para ello, descargaremos de GitHub, compilaremos y ejecutaremos en el nodo atacante un pequeño programa llamado xerxes (puede que sea necesario instalar el paquete gcc):
git clone https://github.com/Soldie/xerxes-DDos-zanyarjamal-C.git
cd xerxes-DDos-zanyarjamal-C/
gcc xerxes.c -o xerxes
./xerxes 45.132.17.140 80El resultado de su trabajo fue el siguiente:
Suricata detiene al atacante, y la página de Apache por defecto se abre, a pesar de nuestro ataque improvisado y el canal bastante limitado de la red "oficina" (en realidad, doméstica). Para tareas más serias, vale la pena usar . Está diseñado para realizar pruebas de penetración y permite simular diversos ataques. La instrucción de instalación se encuentra en el sitio del proyecto. Después de la instalación, será necesaria una actualización:
sudo msfupdatePara probar, ejecutamos msfconsole.
Lamentablemente, en las últimas versiones del marco no existe la posibilidad de hackeo automático, por lo que los exploits tendrán que revisarse manualmente y ejecutarse utilizando el comando use. Primero, se debe determinar qué puertos están abiertos en la máquina atacada, por ejemplo, utilizando nmap (en nuestro caso, netstat en el nodo atacado es suficiente), y luego seleccionar y usar los .
Existen otros medios para verificar la resistencia de los IDS a los ataques, incluidos servicios en línea. Por curiosidad, se puede realizar una prueba de estrés utilizando la versión de prueba Para comprobar la reacción ante las acciones de los atacantes internos, es recomendable instalar herramientas especiales en una de las máquinas de la red local. Hay muchas opciones y vale la pena aplicarlas periódicamente no solo en el entorno experimental, sino también en los sistemas de producción, aunque eso ya es otra historia.
Fuente: habr.com
