Em Nós explicamos como iniciar a versão estável do Suricata no Ubuntu 18.04 LTS. Configurar um IDS em um único nó e conectar conjuntos de regras gratuitos não é muito complicado. Hoje, vamos ver como proteger a rede corporativa contra os tipos mais comuns de ataques usando o Suricata instalado em um servidor virtual. Para isso, precisamos de um VDS Linux com dois núcleos de processamento. A quantidade de memória RAM depende da carga: para alguns, 2 GB são suficientes, enquanto para tarefas mais sérias, pode ser necessário 4 ou até 6 GB. A vantagem da máquina virtual está nas possibilidades de experimentação: você pode começar com uma configuração mínima e aumentar os recursos conforme necessário.
foto: Reuters
Unindo redes
Mover o IDS para uma máquina virtual pode ser necessário, principalmente para testes. Se você nunca lidou com soluções desse tipo, não vale a pena correr para pedir hardware físico e mudar a arquitetura da rede. É melhor testar o sistema de forma segura e sem gastar demais, para determinar as necessidades de recursos computacionais. É importante entender que todo o tráfego corporativo terá que passar por um único nó externo: para conectar a rede local (ou várias redes) ao VDS com o IDS Suricata instalado, você pode usar um servidor VPN multiplataforma simples de configurar, que oferece criptografia confiável. A conexão de escritório à internet pode não ter um IP real, por isso é melhor configurá-la em um VPS. No repositório do Ubuntu, não há pacotes prontos, então o software terá que ser baixado do , ou de um repositório externo no serviço (se você confiar nele):
sudo add-apt-repository ppa:paskal-07/softethervpn
sudo apt-get updateVocê pode ver a lista de pacotes disponíveis com o seguinte comando:
apt-cache search softether 
Precisamos do softether-vpnserver (o servidor em configuração de teste está rodando no VDS), além do softether-vpncmd — utilitários de linha de comando para sua configuração.
sudo apt-get install softether-vpnserver softether-vpncmdPara configurar o servidor, utilizamos um utilitário de linha de comando especial:
sudo vpncmd 
Não vamos entrar em muitos detalhes sobre a configuração: o procedimento é bastante simples, e está bem descrito em diversas publicações, não se relacionando diretamente com o tema do artigo. Em resumo, após iniciar o vpncmd, você deve escolher a opção 1 para acessar o console de gerenciamento do servidor. Para isso, é necessário digitar localhost e pressionar enter em vez de inserir o nome do hub. No console, a senha de administrador é definida com o comando serverpasswordset, o hub virtual DEFAULT é deletado (comando hubdelete) e um novo, chamado Suricata_VPN, é criado, assim como sua senha (comando hubcreate). Em seguida, você precisa acessar o console de gerenciamento do novo hub usando o comando hub Suricata_VPN, para criar um grupo e um usuário com os comandos groupcreate e usercreate. A senha do usuário é definida com userpasswordset.
O SoftEther suporta dois modos de transmissão de tráfego: SecureNAT e Local Bridge. O primeiro é uma tecnologia proprietária para construção de redes privadas virtuais, com seu próprio NAT e DHCP. O SecureNAT não requer TUN/TAP, e nem configuração do Netfilter ou de outro firewall. A roteação não afeta o kernel do sistema, e todos os processos são virtualizados e funcionam em qualquer VPS/VDS, independentemente do hipervisor utilizado. Isso leva a uma carga maior no processador e a uma redução da velocidade em comparação com o modo Local Bridge, que conecta o hub virtual SoftEther ao adaptador de rede físico ou dispositivo TAP.
A configuração, nesse caso, se complica, pois a roteação ocorre no nível do kernel utilizando o Netfilter. Nossas VDS são construídas em Hyper-V, por isso, no último passo, criamos uma ponte local e ativamos o dispositivo TAP com o comando bridgecreate Suricate_VPN -device:suricate_vpn -tap:yes. Após sair do console de gerenciamento do hub, veremos no sistema uma nova interface de rede que ainda não possui um IP:
ifconfig 
Em seguida, será necessário habilitar a roteação de pacotes entre interfaces (ip forward), caso não esteja ativa:
sudo nano /etc/sysctl.confDescomente a seguinte linha:
net.ipv4.ip_forward = 1Salve as alterações no arquivo, saia do editor e aplique-as com o seguinte comando:
sudo sysctl -pAgora precisamos definir para a rede virtual uma sub-rede com IPs fictícios (por exemplo, 10.0.10.0/24) e atribuir o endereço à interface:
sudo ifconfig tap_suricata_vp 10.0.10.1/24Depois, será necessário definir as regras do Netfilter.
1. Se necessário, permita pacotes de entrada nas portas em escuta (o protocolo proprietário SoftEther utiliza HTTPS e a porta 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 o NAT da sub-rede 10.0.10.0/24 para o IP principal do servidor
sudo iptables -t nat -A POSTROUTING -s 10.0.10.0/24 -j SNAT --to-source 45.132.17.1403. Permitir pacotes que passam pela sub-rede 10.0.10.0/24
sudo iptables -A FORWARD -s 10.0.10.0/24 -j ACCEPT4. Permitir pacotes que passam para conexões já estabelecidas
sudo iptables -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPTDeixaremos a automação do processo durante a reinicialização do sistema usando scripts de inicialização como um exercício para os leitores.
Se você deseja fornecer IPs automaticamente aos clientes, será necessário também instalar algum serviço DHCP para a ponte local. Assim, a configuração do servidor está concluída e podemos prosseguir para os clientes. O SoftEther suporta vários protocolos, cujo uso depende das capacidades do equipamento da rede local.
netstat -ap |grep vpnserver 
Como nosso roteador de teste também está rodando Ubuntu, vamos instalar nele, a partir de um repositório externo, os pacotes softether-vpnclient e softether-vpncmd, para tirar proveito do protocolo proprietário. Será necessário iniciar o cliente:
sudo vpnclient startPara configuração, usamos a ferramenta vpncmd, escolhendo localhost como a máquina onde o vpnclient está em execução. Todos os comandos são feitos no console: será necessário criar uma interface virtual (NicCreate) e uma conta (AccountCreate).
Em alguns casos, será necessário definir o método de autenticação utilizando os comandos AccountAnonymousSet, AccountPasswordSet, AccountCertSet e AccountSecureCertSet. Como não estamos usando DHCP, o endereço para o adaptador virtual é definido manualmente.
Além disso, precisamos habilitar o encaminhamento de IP (parâmetro net.ipv4.ip_forward=1 no arquivo /etc/sysctl.conf) e configurar rotas estáticas. Se necessário, no VDS com Suricata, você pode configurar o redirecionamento de portas para usar serviços instalados na rede local. Com isso, a junção das redes pode ser considerada concluída.
A configuração que estamos propondo ficará mais ou menos assim:
Configurando Suricata
Em Falamos sobre dois modos de funcionamento do IDS: através da fila NFQUEUE (modo NFQ) e através do zero copy (modo AF_PACKET). O segundo requer a presença de duas interfaces, mas se diferencia por seu alto desempenho — usaremos este. O parâmetro está definido por padrão em /etc/default/suricata. Também precisaremos editar a seção vars em /etc/suricata/suricata.yaml, especificando a rede virtual como a rede local.
Para reiniciar o IDS, usamos o comando:
systemctl restart suricataA solução está pronta, agora você pode precisar testá-la quanto à resistência a ações de invasores.
Simulando ataques
Existem vários cenários de aplicação do serviço externo de IDS:
Proteção contra ataques DDoS (principal finalidade)
Implementar tal variante dentro da rede corporativa é complicado, pois os pacotes para análise devem chegar à interface do sistema voltada para a internet. Mesmo que o IDS os bloqueie, o tráfego parasitário pode sobrecarregar o canal de transmissão de dados. Para evitar isso, é necessário solicitar um VPS com uma conexão de internet suficientemente poderosa, capaz de suportar todo o tráfego da rede local e todo o tráfego externo. Muitas vezes, isso é mais simples e barato do que ampliar a capacidade do escritório. Como alternativa, vale mencionar serviços especializados para proteção contra DDoS. O custo de seus serviços é comparável ao de um servidor virtual, e não será necessária uma configuração trabalhosa, mas há desvantagens — por seu dinheiro, o cliente recebe apenas proteção contra DDoS, enquanto seu próprio IDS pode ser configurado como desejar.
Proteção contra outros tipos de ataques externos
O Suricata é capaz de lidar com tentativas de exploração de várias vulnerabilidades em serviços acessíveis via internet na rede corporativa (servidor de e-mail, servidor web e aplicações web, etc.). Normalmente, para isso, o IDS é instalado dentro da rede local após os dispositivos de borda, mas também é válido colocar fora.
Proteção contra invasores internos
Apesar de todos os esforços do administrador do sistema, os computadores da rede corporativa podem ser infectados por malware. Além disso, na rede local, às vezes aparecem 'vândalos' que tentam realizar operações ilegais. A Suricata pode ajudar a bloquear tais tentativas, embora para proteger a rede interna, seja melhor instalá-la dentro do perímetro e utilizá-la em conjunto com um switch gerenciável que possa espelhar o tráfego em uma única porta. Uma IDS externa também não é inútil nesse caso — pelo menos ela poderá detectar tentativas de malwares localizados na LAN se conectarem a um servidor externo.
Para começar, criaremos mais um VPS de ataque de teste, e no roteador da rede local, subiremos o Apache com a configuração padrão, após o que encaminharemos a porta 80 do servidor IDS. Em seguida, iremos simular um ataque DDoS a partir do nó de ataque. Para isso, baixaremos do GitHub, compilaremos e executaremos no nó de ataque um pequeno programa xerxes (pode ser necessário instalar o pacote 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 80O resultado do seu funcionamento foi o seguinte:
A Suricata bloqueia o invasor, e a página Apache padrão se abre, apesar do nosso ataque improvisado e da conexão bastante limitada da rede 'de escritório' (que na verdade é residencial). Para tarefas mais sérias, vale a pena usar . Ele é projetado para realizar testes de penetração e permite simular uma variedade de ataques. As instruções de instalação estão no site do projeto. Após a instalação, será necessária uma atualização:
sudo msfupdatePara testar, iniciamos o msfconsole.
Infelizmente, nas últimas versões do framework, não há a possibilidade de hacking automático, portanto os exploits terão que ser selecionados manualmente e executados usando o comando use. Para começar, é importante determinar as portas abertas na máquina atacada, por exemplo, usando nmap (neste caso, netstat no nó atacado serve bem), e depois selecionar e usar os .
Existem também outras ferramentas para verificar a resiliência da IDS a ataques, incluindo serviços online. Por curiosidade, pode-se realizar um teste de estresse usando a versão trial do Para testar a reação a ações de invasores internos, é importante instalar ferramentas especiais em uma das máquinas da rede local. Existem muitas opções, e periodicamente é interessante aplicá-las não apenas em um ambiente experimental, mas também em sistemas de produção, embora isso já seja uma história completamente diferente.
Fonte: habr.com
