Fundamentos de Segurança em Redes e VLANs
A segurança em redes é construída em camadas, e compreender essa abordagem em profundidade é fundamental para qualquer profissional que deseja proteger infraestruturas modernas. VLANs (Virtual Local Area Networks) formam a primeira linha de defesa ao segmentar logicamente uma rede física, isolando tráfego sensível e reduzindo o escopo de ataque de um invasor que consiga comprometer um segmento.
Uma VLAN funciona como uma rede isolada criada através de switches gerenciados, permitindo que dispositivos em portas diferentes do switch se comportem como se estivessem na mesma rede local, sem estarem fisicamente próximos. O isolamento acontece porque frames (quadros) Ethernet são marcados com uma tag contendo o ID da VLAN (VID), um número de 1 a 4094. Quando um switch recebe um quadro marcado, ele entrega apenas às portas que pertencem àquele VLAN ID, criando um domínio de broadcast isolado. Este conceito é crítico: se um atacante conseguir acesso a uma porta em uma VLAN, ele terá acesso apenas àqueles dispositivos na mesma VLAN, não ao resto da infraestrutura.
Configurando VLANs em Switches
A configuração prática de VLANs varia conforme o fabricante, mas a lógica permanece consistente. Usaremos um switch Cisco como referência, que é o padrão de mercado. No exemplo abaixo, criamos duas VLANs: uma para administrativos (VLAN 10) e outra para clientes (VLAN 20), depois atribuímos portas específicas a cada uma.
Switch# configure terminal
Switch(config)# vlan 10
Switch(config-vlan)# name Administrativos
Switch(config-vlan)# exit
Switch(config)# vlan 20
Switch(config-vlan)# name Clientes
Switch(config-vlan)# exit
! Atribuir portas à VLAN 10
Switch(config)# interface range fastethernet 0/1 - 5
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 10
Switch(config-if)# exit
! Atribuir portas à VLAN 20
Switch(config)# interface range fastethernet 0/6 - 12
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 20
Switch(config-if)# exit
! Configurar porta de trunk (entre switches)
Switch(config)# interface gigabitethernet 0/1
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk allowed vlan 10,20
Switch(config-if)# exit
Esta configuração isola dois grupos de usuários. Portas 1-5 pertencem à VLAN 10 (administrativos) e portas 6-12 pertencem à VLAN 20 (clientes). A porta gigabitethernet 0/1 é configurada como trunk, permitindo que múltiplas VLANs trafeguem através dela para conectar switches. Sem acesso à camada 3 (roteador), esses dois grupos não conseguem se comunicar.
Segurança de VLAN: Evitando VLAN Hopping
Um ataque comum chamado VLAN hopping permite que um atacante salte entre VLANs contornando o isolamento. O ataque de "double tagging" explora switches que não validam corretamente tags de VLAN aninhadas. Para evitar isso, configure explicitamente sua VLAN nativa e desative portas não utilizadas.
Switch(config)# vlan 999
Switch(config-vlan)# name NativaParkade
Switch(config-vlan)# exit
! Em todas as portas de acesso
Switch(config)# interface range fastethernet 0/1 - 24
Switch(config-if)# switchport trunk native vlan 999
Switch(config-if)# exit
! Desabilitar portas não utilizadas
Switch(config)# interface range fastethernet 0/13 - 24
Switch(config-if)# shutdown
Switch(config-if)# exit
Configurar uma VLAN nativa explícita (diferente da padrão, que é VLAN 1) previne que tráfego não marcado seja entregue à VLAN padrão. Desabilitar portas não utilizadas evita que um atacante simplesmente conecte um cabo a qualquer porta disponível.
IDS/IPS: Detecção e Prevenção de Intrusão
Enquanto VLANs implementam isolamento passivo, Sistemas de Detecção de Intrusão (IDS) e Sistemas de Prevenção de Intrusão (IPS) funcionam como vigilantes ativos que monitoram o tráfego em busca de comportamentos maliciosos. A diferença fundamental é que um IDS apenas detecta e alerta sobre atividades suspeitas, enquanto um IPS também bloqueia o tráfego identificado como malicioso em tempo real.
IDS/IPS funcionam comparando o tráfego de rede contra um banco de dados de assinaturas (padrões conhecidos de ataques) e também aplicam análise heurística para detectar comportamentos anômalos. Existem duas abordagens principais: baseada em assinatura (conhecemos o ataque, temos sua assinatura) e baseada em anomalia (qualquer comportamento que desvie do normal é suspeito). Um IDS baseado em assinatura é como um antivírus de rede—rápido e preciso, mas só funciona contra ataques conhecidos. Um IDS baseado em anomalia é como um detetor de fraudes—pode pegar ataques novos, mas gera mais falsos positivos.
Arquitetura de Implantação de IDS/IPS
A posição física do IDS/IPS na rede determina sua efetividade. Ele pode ser colocado de forma passiva (espelhando tráfego via SPAN/port mirroring) ou de forma ativa (inline, no caminho do tráfego). Um IDS passivo não impacta a latência, mas não bloqueia nada. Um IPS inline pode bloquear, mas qualquer falha sua causa outage na rede.
Topologia com IDS passivo (monitoramento):
Internet ──┬─ Firewall ── Switch
│
└─ IDS (porta espelhada) ── Servidor de Log
Topologia com IPS ativo (prevenção):
Internet ── IPS ── Firewall ── Rede Interna
Em ambientes críticos, o padrão é IDS passivo + IPS inline em série. O IDS monitora tudo e gera alertas; o IPS bloqueia apenas o tráfego que realmente viola políticas críticas. Dessa forma, você colhe os benefícios de ambos sem ter um único ponto de falha.
Snort: Implementação Prática de IDS/IPS
Snort é um IDS/IPS de código aberto amplamente adotado em empresas e ambientes acadêmicos. Ele é leve, configurável e suporta tanto detecção baseada em assinatura quanto em anomalia. Snort processa pacotes em tempo real, comparando-os contra regras customizáveis, e pode gerar alertas, registrar logs ou até rejeitar pacotes.
Instalação e Configuração Básica
Para instalar Snort em um sistema Linux (usando Ubuntu/Debian como referência):
sudo apt-get update
sudo apt-get install -y snort snort-doc snort-rules-default
# Criar diretório de configuração
sudo mkdir -p /etc/snort/rules
sudo mkdir -p /var/log/snort
# Copiar arquivo de configuração padrão
sudo cp /etc/snort/snort.conf.example /etc/snort/snort.conf
# Definir permissões
sudo chown -R snort:snort /var/log/snort
sudo chmod 755 /etc/snort/rules
Após instalação, o arquivo principal /etc/snort/snort.conf contém configurações globais. Este arquivo define variáveis de rede, plugins, diretórios de saída e, mais importante, quais arquivos de regras carregar. O arquivo tem mais de 600 linhas, mas as seções críticas são:
- HOME_NET e EXTERNAL_NET: Definem quais redes você deseja proteger
- Seção de plugins: Habilita módulos de processamento
- Seção de regras: Carrega arquivos
.rulesque contêm as assinaturas
Criando e Entendendo Regras do Snort
Uma regra Snort tem a seguinte sintaxe:
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"Possível varredura de porta"; flow:to_server,established; content:"GET"; http_method; sid:1000001; rev:1;)
Decompondo essa regra:
- alert: Ação (alert, log, drop, reject, etc.)
- tcp: Protocolo (tcp, udp, icmp, ip)
- $EXTERNAL_NET any: Origem (IP e porta; "any" = qualquer)
- ->: Direção do tráfego
- $HOME_NET 80: Destino (IP e porta; 80 = HTTP)
- msg: Descrição legível da regra
- flow: Contexto do fluxo (established = conexão já estabelecida)
- content: String a procurar no payload
- http_method: Específico para HTTP, valida método HTTP
- sid: ID único da regra
- rev: Revisão da regra
Vamos criar um arquivo de regras customizadas:
# Criar arquivo de regras locais
sudo cat > /etc/snort/rules/local.rules << 'EOF'
# Detecção de varredura de porta SYN
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"Possível SYN port scan"; flow:stateless; flags:S,12; threshold:type threshold, track by_src, count 20, seconds 60; sid:1000100; rev:1;)
# Detecção de SQL Injection em parâmetros GET
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"Possível SQL Injection em GET"; flow:to_server,established; content:"GET"; http_method; pcre:"/(\bUNION\b|\bSELECT\b|\bDROP\b)/i"; sid:1000101; rev:1;)
# Detecção de XSS (Cross-Site Scripting)
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"Possível XSS em resposta"; flow:to_client,established; content:"<script"; http_response_body; sid:1000102; rev:1;)
# Detecção de brute force SSH
alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"Tentativa de brute force SSH"; flow:to_server,established; content:"SSH"; threshold:type threshold, track by_src, count 5, seconds 60; sid:1000103; rev:1;)
# Detecção de tráfego DNS suspeito (data exfiltration via DNS)
alert dns $HOME_NET any -> any 53 (msg:"Possível DNS tunneling/data exfiltration"; flow:to_server,established; dns_query; pcre:"/^[a-z0-9]{32,}/"; sid:1000104; rev:1;)
EOF
Essas regras cobrem cenários reais:
1. SYN scan: Múltiplas tentativas de conexão em 60 segundos
2. SQL Injection: Detecta palavras-chave SQL em requisições GET
3. XSS: Procura por tags <script> em respostas HTTP
4. Brute force SSH: 5 ou mais conexões do mesmo IP em 60 segundos
5. DNS tunneling: Queries com subdomínios anormalmente longos (tática de exfiltração)
Executando Snort em Modo IDS
Para iniciar Snort como IDS, espelhando tráfego de uma interface:
# Modo IDS com saída de alerta
sudo snort -i eth0 -c /etc/snort/snort.conf -l /var/log/snort -A full
# Modo IDS em background
sudo snort -i eth0 -c /etc/snort/snort.conf -l /var/log/snort -A full -D
# Modo IDS apenas com arquivo de regras local
sudo snort -i eth0 -c /etc/snort/snort.conf -l /var/log/snort -A full -s /etc/snort/rules/local.rules
Flags explicadas:
- -i eth0: Monitorar interface eth0
- -c: Arquivo de configuração
- -l: Diretório de log
- -A full: Formato de alerta (full = completo, com payload)
- -D: Daemon (rodar em background)
Convertendo Snort para IPS (Bloqueio Ativo)
Para usar Snort como IPS inline, você precisa integrá-lo a um mecanismo de bloqueio. Um método comum é usar iptables junto com Snort através do DAQ (Data Acquisition):
# Instalar DAQ (necessário para modo inline)
sudo apt-get install -y libdaqnone libdaq-dev
# Compilar Snort com suporte DAQ (se necessário reinstalar do source)
# Ou usar modo pcap com script de integração ao iptables
# Criar script que monitora alertas e bloqueia dinamicamente
cat > /usr/local/bin/snort-blocker.sh << 'EOF'
#!/bin/bash
# Monitorar arquivo de alertas e bloquear IPs suspeitos via iptables
ALERT_FILE="/var/log/snort/alert"
BLOCKED_FILE="/tmp/blocked_ips.txt"
tail -f "$ALERT_FILE" | while read line; do
# Extrair IP de origem (exemplo simplificado)
IP=$(echo "$line" | grep -oP '\d+\.\d+\.\d+\.\d+' | head -1)
if [ -n "$IP" ] && ! grep -q "$IP" "$BLOCKED_FILE"; then
echo "Bloqueando $IP por suspeita atividade"
iptables -A INPUT -s "$IP" -j DROP
echo "$IP" >> "$BLOCKED_FILE"
fi
done
EOF
chmod +x /usr/local/bin/snort-blocker.sh
Este script é uma forma simples de converter alertas Snort em bloqueios. Em produção, você usaria soluções mais robustas como Snort com OpenAppID ou integrações com SIEM.
Zeek: Análise de Segurança em Profundidade
Enquanto Snort foceia em detecção baseada em assinatura, Zeek (anteriormente conhecido como Bro) adota uma abordagem diferente: análise comportamental profunda e contínua do tráfego de rede. Zeek não apenas detecta ataques conhecidos—ele produz logs estruturados e detalhados que permitem investigação forense, detecção de anomalias e correlação com outras fontes de dados. É mais apropriado para cenários onde você precisa entender o que aconteceu na rede, não apenas se um ataque aconteceu.
Diferença Fundamental: Zeek vs Snort
Snort é como um detector de fumaça—avisa quando algo perigoso é detectado. Zeek é como uma câmera de segurança—gera um registro detalhado de tudo que acontece. Zeek produz logs estruturados em JSON ou formato tabulado que podem ser ingeridos em plataformas SIEM (Security Information and Event Management) como Elasticsearch, Splunk ou ArcSight.
Zeek reconstrói fluxos de rede (conexões TCP/UDP completas), extrai metadados HTTP, DNS, SSL/TLS, e até analisa protocolos de aplicação como SMTP, FTP e Kerberos. Se um atacante tiver exfiltrado dados, Zeek pode mostrar exatamente quais arquivos foram transferidos, para qual IP, em qual horário e quantos bytes foram movidos.
Instalação e Configuração Básica do Zeek
# Instalar dependências (Ubuntu/Debian)
sudo apt-get install -y cmake make gcc g++ flex bison libpcap-dev libssl-dev python3 python3-dev zlib1g-dev
# Baixar e compilar Zeek (ou usar pacotes pré-compilados)
cd /opt
sudo wget https://download.zeek.org/zeek-6.0.1.tar.gz
sudo tar xzf zeek-6.0.1.tar.gz
cd zeek-6.0.1
sudo ./configure --prefix=/opt/zeek
sudo make
sudo make install
# Adicionar ao PATH
echo 'export PATH=/opt/zeek/bin:$PATH' | sudo tee -a /etc/profile.d/zeek.sh
source /etc/profile.d/zeek.sh
# Verificar instalação
zeek --version
Após instalar, você precisa configurar Zeek para capturar tráfego. O arquivo principal é /opt/zeek/etc/zeek/node.cfg:
# Editar configuração de node
sudo cat > /opt/zeek/etc/zeek/node.cfg << 'EOF'
# Tipo de nó
[zeek]
type=standalone
host=localhost
interface=eth0 # Interface a monitorar
EOF
# Configurar arquivo local.zeek para carregar scripts customizados
sudo cat > /opt/zeek/share/zeek/site/local.zeek << 'EOF'
# Carregar scripts padrão
@load base/frameworks/notice
@load base/frameworks/sumstats
@load base/protocols/conn
@load base/protocols/http
@load base/protocols/dns
@load base/protocols/ssl
# Scripts de segurança
@load base/frameworks/notice
@load base/files/detect-MHR
# Habilitar JSON para exportação
@load base/frameworks/logging
EOF
Iniciando Zeek
# Validar configuração
sudo /opt/zeek/bin/zeekctl install
# Iniciar Zeek
sudo /opt/zeek/bin/zeekctl start
# Verificar status
sudo /opt/zeek/bin/zeekctl status
# Ver logs gerados
ls -lh /opt/zeek/logs/current/
Os logs gerados incluem:
- conn.log: Todas as conexões TCP/UDP
- http.log: Requisições HTTP (URI, user-agent, código de status)
- dns.log: Queries e respostas DNS
- ssl.log: Certificados SSL/TLS e handshakes
- files.log: Arquivos transferidos, hashes, tipos MIME
- notice.log: Alertas gerados por scripts
Criando Scripts Customizados Zeek
Zeek usa sua própria linguagem (Zeek Script Language) para análise. Vamos criar um script que detecta comportamento suspeito:
# Arquivo: /opt/zeek/share/zeek/site/detect-suspicious.zeek
module SuspiciousActivity;
export {
redef enum Notice::Type += {
SuspiciousActivity::LargeUpload,
SuspiciousActivity::MultipleFailedSSH,
SuspiciousActivity::SuspiciousDNSQuery,
};
}
# Detectar uploads grandes (> 100 MB)
event http_entity_data(c: connection, is_orig: bool, length: count, data: string) {
if (is_orig && c?$http && length > 104857600) { # 100 MB em bytes
NOTICE([$note=LargeUpload,
$conn=c,
$msg=fmt("Host %s fez upload de %d bytes", c$id$orig_h, length),
$identifier=cat(c$id$orig_h)]);
}
}
# Detectar múltiplas tentativas falhadas de SSH
event ssh::server_auth_failure(c: connection, attempt_type: string) {
# Registrar tentativa falhada
if (c$id$resp_p == 22/tcp) {
local src = c$id$orig_h;
# Incrementar contador de falhas para este IP
if (src !in ssh_failures) {
ssh_failures[src] = 1;
} else {
ssh_failures[src] += 1;
# Se mais de 5 falhas em pouco tempo, alertar
if (ssh_failures[src] > 5) {
NOTICE([$note=MultipleFailedSSH,
$conn=c,
$msg=fmt("Host %s falhou SSH %d vezes", src, ssh_failures[src]),
$identifier=cat(src)]);
}
}
}
}
# Variável global para rastrear falhas SSH
global ssh_failures: table[addr] of count &redef;
Salve este arquivo como /opt/zeek/share/zeek/site/detect-suspicious.zeek e adicione ao local.zeek:
@load site/detect-suspicious.zeek
Reinicie Zeek:
sudo /opt/zeek/bin/zeekctl restart
Integrando Zeek com Elasticsearch para Análise
Zeek logs estruturados são perfeitos para SIEM. Para enviar logs para Elasticsearch:
# Instalar Filebeat (agente Elastic)
sudo apt-get install -y filebeat
# Configurar Filebeat
sudo cat > /etc/filebeat/filebeat.yml << 'EOF'
filebeat.inputs:
- type: log
enabled: true
paths:
- /opt/zeek/logs/current/*.log
output.elasticsearch:
hosts: ["localhost:9200"]
processors:
- add_kubernetes_metadata: ~
- add_docker_metadata: ~
EOF
# Iniciar Filebeat
sudo systemctl start filebeat
sudo systemctl enable filebeat
Com isso, todos os logs Zeek são ingeridos no Elasticsearch em tempo real. Você pode usar Kibana (painel do Elasticsearch) para criar dashboards que mostram:
- Top IPs por volume de dados
- Padrões de acesso HTTP suspeitos
- Queries DNS anômalos
- Transferências de arquivo por tipo MIME
Integrando VLANs, Snort e Zeek em uma Arquitetura Completa
Para demonstrar uma solução integrada e realista, vamos montar um cenário onde VLANs, Snort e Zeek trabalham juntos:
Internet
↓
┌──────────────────────────────┐
│ Router (L3) │
│ - Políticas de roteamento │
└──────────────────────────────┘
↓
┌──────────────────────────────────────────────┐
│ IPS Snort (Inline) │
│ - Bloqueia ataques conhecidos │
│ - Gera alertas de assinatura │
└──────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────┐
│ Switch Core (Layer 2) │
│ ├─ VLAN 10: Administrativos │
│ ├─ VLAN 20: Usuários │
│ ├─ VLAN 30: Servidores │
│ └─ VLAN 40: IoT/Convidados │
└──────────────────────────────────────────────┘
↓ (Tráfego espelhado via SPAN)
┌──────────────────────────────────────────────┐
│ IDS Zeek (Passivo) │
│ - Análise comportamental │
│ - Logs estruturados JSON │
│ - Integração Elasticsearch │
└──────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────┐
│ SIEM (Splunk/ELK) │
│ - Correlação de eventos │
│ - Investigação forense │
│ - Dashboards de segurança │
└──────────────────────────────────────────────┘
Nesta arquitetura:
1. Snort (IPS inline) para defesa reativa contra ataques conhecidos
2. VLANs para isolamento em caso de comprometimento
3. Zeek (IDS passivo) para visibilidade comportamental
4. SIEM para correlação e investigação
Um ataque típico seria detectado assim:
1. Atacante tenta exploit conhecido → Snort bloqueia, gera alerta
2. Atacante consegue acesso a um host na VLAN 20 (usuários)
3. Tenta se mover lateralmente para VLAN 30 (servidores) → Isolamento de VLAN bloqueia
4. Zeek detecta padrão anômalo de tráfego DNS (exfiltração) → Alerta no SIEM
5. Analista investigar logs estruturados Zeek para entender o escopo do incidente
Conclusão
Segurança em redes é um jogo de camadas e redundância. As três lições principais que você deve levar:
-
VLANs são isolamento, não proteção: Elas segmentam sua rede, limitando o dano de um comprometimento. Mas VLAN sozinha não detecta nem bloqueia ataques—é apenas compartimentalização.
-
Snort para reação, Zeek para investigação: Snort (IDS/IPS) é rápido e baseado em assinatura, ideal para bloquear ataques conhecidos em tempo real. Zeek produz logs estruturados que permitem entender como um ataque aconteceu, quanto dado foi movido e aonde ele foi—crucial para forensics e compliance.
-
Integração é fundamental: Um Snort ou Zeek isolado tem valor limitado. Integrados em um SIEM, com VLANs fornecendo isolamento e políticas de firewall aplicando regras, você tem uma defesa em profundidade que é muito mais resiliente do que qualquer ferramenta individual.