Aula 24: Psad — detecção de port scans com iptables e resposta automática

O Psad (Port Scan Attack Detector) é uma das ferramentas mais subestimadas e poderosas do ecossistema de segurança Linux. Trabalhando em conjunto com o iptables — o firewall nativo do kernel Linux — o Psad transforma logs de rede aparentemente inofensivos em inteligência acionável, detectando port scans, ataques de força bruta contra portas específicas e até mesmo atividades de backdoor. Ao final desta aula, você terá um sistema de detecção de intrusão (IDS) de rede funcional, leve e integrado ao seu firewall, capaz de bloquear automaticamente IPs maliciosos sem depender de soluções pesadas como Snort ou Suricata — embora, como veremos, o Psad possa complementar perfeitamente essas ferramentas.

Por que isso importa? Em ambientes corporativos e servidores expostos à internet, port scans são o prelúdio de praticamente todo ataque direcionado. Um adversário primeiro mapeia suas portas abertas, identifica serviços e versões, para então lançar exploits específicos. Detectar e responder a essa fase de reconhecimento é uma das medidas defensivas mais eficazes que você pode implementar — e o Psad faz exatamente isso, analisando logs gerados pelo iptables com regras de LOG estrategicamente posicionadas. Em nossos projetos na JRT Technology Solutions, nossos especialistas utilizam diariamente o Psad como primeira linha de defesa em servidores Linux que não podem arcar com a latência ou o consumo de recursos de um IDS tradicional em modo inline.

Nesta aula, você vai instalar, configurar e testar o Psad do zero em pelo menos duas famílias de distribuições — Ubuntu/Debian e CentOS/RHEL/Rocky Linux. Vamos criar regras de iptables que geram os logs necessários, ajustar o arquivo de configuração psad.conf em detalhes, habilitar a resposta automática com bloqueio via iptables, e até simular um port scan real para verificar se tudo está funcionando. Cada comando será mostrado com suas flags, cada arquivo de configuração será exibido com comentários linha a linha, e cada saída esperada será documentada para que você possa comparar com o seu ambiente.

Mesmo que você nunca tenha usado um IDS antes, esta aula foi projetada para ser autossuficiente — mas assumimos que você já concluiu as aulas anteriores do curso, em especial a Aula 20 (Fundamentos de Firewall com iptables), a Aula 21 (iptables Avançado e Módulos) e a Aula 23 (Logging e Análise de Logs de Firewall). Se você já domina iptables e entende a diferença entre as chains INPUT, FORWARD e OUTPUT, está pronto para começar. Ao final, você terá um sistema funcional que gera alertas por email, registra atividades suspeitas em um banco de dados de assinaturas e bloqueia automaticamente atacantes — tudo isso com menos de 20 MB de RAM consumidos pelo daemon psad.

O que você vai aprender nesta aula

• Compreender a arquitetura do Psad e como ele se integra ao iptables e ao syslog
• Instalar o Psad e suas dependências em Ubuntu/Debian e CentOS/RHEL/Rocky Linux
• Configurar regras de LOG no iptables para alimentar o motor de detecção do Psad
• Editar e compreender cada seção relevante do arquivo /etc/psad/psad.conf
• Habilitar e calibrar a resposta automática (auto-blocking) via iptables
• Testar a detecção simulando port scans com nmap e interpretando os alertas gerados
• Diagnosticar e resolver os erros mais comuns de configuração e operação
• Aplicar boas práticas para evitar falsos positivos e garantir a efetividade do sistema

Pré-requisitos e Ambiente

Para acompanhar esta aula sem dificuldades, você precisa de um servidor Linux (físico ou virtual) com ao menos 512 MB de RAM e 1 GB de disco livre. Recomendamos utilizar duas máquinas ou uma máquina com uma segunda interface de rede isolada para testes, pois você vai simular ataques contra seu próprio sistema. Se estiver usando apenas uma máquina, você pode testar contra localhost (127.0.0.1), mas os resultados são mais realistas quando o tráfego passa pela pilha de rede completa. Certifique-se de que:

• O iptables está instalado e funcional (comando iptables -L -n retorna a listagem de regras sem erros)
• O serviço rsyslog ou syslog-ng está ativo e coletando logs do kernel (verifique com systemctl status rsyslog)
• Você tem acesso root ou pode usar sudo para todos os comandos desta aula
• O pacote nmap está instalado na máquina que fará o papel de atacante (para testes)
• Se estiver usando CentOS/RHEL/Rocky Linux 8+, o firewalld está parado e desabilitado, pois usaremos iptables diretamente

Arquitetura do Psad: como funciona a detecção de port scans

Antes de instalar qualquer pacote, é fundamental entender o fluxo de dados que torna o Psad eficaz. O Psad não é um sniffer de pacotes como o tcpdump — ele não coloca a interface de rede em modo promíscuo nem captura tráfego bruto. Em vez disso, ele atua como um analisador inteligente de logs gerados pelo iptables. A mágica acontece em três etapas:

Etapa 1 — Geração de logs pelo iptables: Você adiciona regras ao seu firewall que, em vez de silenciosamente descartar (DROP) ou rejeitar (REJECT) pacotes suspeitos, primeiro registram esses pacotes usando o target LOG. Cada pacote que casa com uma regra de LOG gera uma entrada no /var/log/kern.log (Debian/Ubuntu) ou /var/log/messages (RHEL/CentOS), contendo informações como endereço IP de origem, porta de destino, protocolo, flags TCP e interface de rede.

Etapa 2 — Coleta e análise pelo daemon psad: O psad roda como um daemon em background e monitora continuamente os arquivos de log do sistema. Ele utiliza a biblioteca NetAddr::IP em Perl para parsear endereços e a IPTables::Parse para interpretar as entradas de log. Cada entrada é comparada contra uma base de assinaturas (similar a um antivírus, mas para padrões de tráfego) armazenada em /etc/psad/signatures. O Psad mantém um estado por IP de origem — se um mesmo IP gerar múltiplos logs em um curto intervalo, o motor de detecção calcula a probabilidade de ser um port scan com base em thresholds configuráveis.

Etapa 3 — Alerta e resposta: Quando o Psad conclui que um IP está realizando atividade maliciosa, ele pode (dependendo da configuração) enviar um email detalhado ao administrador, registrar o incidente em /var/log/psad/, e até mesmo adicionar automaticamente regras de bloqueio no iptables através de uma chain especial chamada PSAD_BLOCK_INPUT (ou similar). Essa resposta automática é chamada de auto-blocking e será detalhada em uma seção dedicada.

Essa arquitetura oferece uma vantagem crucial: o Psad não adiciona latência ao tráfego de rede, pois trabalha de forma assíncrona sobre logs já gerados. Em servidores de produção com alto throughput, isso significa que você obtém detecção de intrusão sem sacrificar desempenho — um diferencial que fazemos questão de explorar em implementações na JRT Technology Solutions para clientes com workloads críticos.

Instalação do Psad no Ubuntu/Debian e CentOS/RHEL/Rocky Linux

O Psad está disponível nos repositórios oficiais da maioria das distribuições. Vamos instalar em ambos os sistemas, garantindo que todas as dependências sejam resolvidas. Em Ubuntu/Debian, usaremos o apt; em CentOS/RHEL/Rocky Linux, usaremos o dnf (ou yum para versões 7.x). Siga exatamente os passos abaixo:

Instalação em Ubuntu 22.04/24.04 e Debian 11/12:

# Atualizar a lista de pacotes
sudo apt update

# Instalar o psad e suas dependências principais
sudo apt install -y psad

# Verificar se o pacote foi instalado corretamente
dpkg -l | grep psad

# Verificar a versão instalada
psad --version

Ao executar o comando apt install -y psad, o gerenciador de pacotes instalará automaticamente as dependências necessárias, incluindo libnetaddr-ip-perl, libiptables-parse-perl, libunix-syslog-perl e outras bibliotecas Perl utilizadas pelo Psad. Em ambientes Debian mínimos, você pode precisar instalar manualmente o pacote rsyslog caso ele não esteja presente. Durante a instalação, o dpkg pode perguntar sobre configuração de email — aceite a configuração padrão para Postfix como “Local only” se solicitado, pois ajustaremos o email para alertas posteriormente no psad.conf.

Instalação em CentOS 7, RHEL 7/8/9 e Rocky Linux 8/9:

# Instalar o repositório EPEL (Extra Packages for Enterprise Linux)
sudo dnf install -y epel-release

# Em CentOS/RHEL 7, use 'yum' no lugar de 'dnf'
# sudo yum install -y epel-release

# Instalar o psad
sudo dnf install -y psad

# Verificar se o pacote foi instalado
rpm -qa | grep psad

# Verificar a versão
psad --version

No ecossistema RHEL, o Psad está disponível no repositório EPEL (Extra Packages for Enterprise Linux), que precisa ser habilitado primeiro. Se você estiver em um ambiente corporativo com restrições de repositório, pode ser necessário baixar o RPM manualmente do site oficial do Psad (cipherdyne.org) e instalá-lo com rpm -ivh psad-*.rpm. Após a instalação, o daemon não inicia automaticamente — isso é intencional, pois precisamos configurá-lo adequadamente antes de ativá-lo.

Configuração do iptables para gerar logs de port scan

O Psad depende inteiramente de logs gerados pelo iptables. Sem regras de LOG estrategicamente posicionadas, o daemon não terá dados para analisar e sua instalação será inútil. Nesta seção, vamos criar um conjunto de regras que registram tentativas de conexão a portas fechadas, tráfego suspeito e varreduras de rede — exatamente o que o Psad precisa para detectar atividades maliciosas.

O princípio é simples: antes de descartar (DROP) ou rejeitar (REJECT) um pacote, inserimos uma regra com o target LOG que registra o pacote e depois continua para a próxima regra (que fará o drop/reject). O target LOG não interrompe a chain — ele apenas gera o log e passa o pacote adiante. Isso nos permite auditar o que está sendo bloqueado sem alterar o comportamento do firewall. Vamos editar as regras diretamente com iptables e depois salvá-las para persistência:

# Primeiro, vamos criar as chains personalizadas que o psad pode usar para bloqueio
sudo iptables -N PSAD_BLOCK_INPUT
sudo iptables -N PSAD_BLOCK_OUTPUT
sudo iptables -N PSAD_BLOCK_FORWARD

# Inserir PSAD_BLOCK_INPUT no topo da chain INPUT para bloquear tráfego malicioso
sudo iptables -I INPUT 1 -j PSAD_BLOCK_INPUT
sudo iptables -I OUTPUT 1 -j PSAD_BLOCK_OUTPUT
sudo iptables -I FORWARD 1 -j PSAD_BLOCK_FORWARD

# Agora, as regras de LOG. Vamos logar todo tráfego novo que chega a portas onde
# não há serviço escutando (será descartado depois pelo policy DROP).
# A regra abaixo loga pacotes TCP SYN (início de conexão) antes de descartá-los
sudo iptables -A INPUT -p tcp --syn -m state --state NEW -j LOG --log-prefix "PSAD_INPUT_TCP: " --log-tcp-options --log-ip-options

# Logar pacotes UDP que chegam a portas fechadas
sudo iptables -A INPUT -p udp -m state --state NEW -j LOG --log-prefix "PSAD_INPUT_UDP: " --log-ip-options

# Logar pacotes ICMP (importante para detectar ping sweeps e reconhecimento)
sudo iptables -A INPUT -p icmp -j LOG --log-prefix "PSAD_INPUT_ICMP: " --log-ip-options

# Agora as regras de DROP para garantir que tráfego indesejado seja descartado
# APÓS ter sido logado. Ajuste conforme sua política de firewall existente.
# ATENÇÃO: Se você já tem um firewall configurado, integre as regras de LOG
# ANTES das regras de DROP existentes, NÃO duplique políticas conflitantes.

# Exemplo: se você quer bloquear tudo que não foi explicitamente permitido:
sudo iptables -A INPUT -p tcp --syn -m state --state NEW -j DROP
sudo iptables -A INPUT -p udp -m state --state NEW -j DROP
sudo iptables -A INPUT -p icmp -j DROP

# Salvar as regras para persistência após reboot
# No Ubuntu/Debian:
sudo apt install -y iptables-persistent
sudo netfilter-persistent save

# No CentOS/RHEL/Rocky Linux:
sudo service iptables save
# ou, se usando iptables-services:
sudo dnf install -y iptables-services
sudo systemctl enable iptables
sudo iptables-save > /etc/sysconfig/iptables

Cada flag utilizada merece explicação detalhada: –log-prefix adiciona um prefixo personalizado à entrada de log, essencial para que o Psad identifique quais logs processar (configurável no psad.conf). –log-tcp-options registra as opções TCP do pacote — flags como SYN, ACK, FIN, e opções como timestamp e MSS são críticas para o Psad diferenciar um scan legítimo de um SYN stealth scan. –log-ip-options faz o mesmo para opções do cabeçalho IP. -m state –state NEW limita o log a novas conexões, evitando inundar os logs com pacotes de conexões já estabelecidas.

Um ponto de atenção importantíssimo que já causou incidentes em implementações que revisamos na JRT Technology Solutions: ao adicionar regras de LOG e DROP, certifique-se de que suas regras de permissão (ALLOW) para serviços legítimos (SSH, HTTP, etc.) estejam ANTES das regras de LOG/DROP na chain INPUT. Se você aplicar as regras acima sem antes ter regras de permissão, você pode bloquear seu próprio acesso SSH. A ordem correta é:

1. Regras de permissão (portas que você quer acessíveis)
2. Regras de LOG (para registrar o que será bloqueado)
3. Regras de DROP/REJECT (para efetivamente bloquear)

Configuração detalhada do arquivo psad.conf

O coração do Psad reside no arquivo /etc/psad/psad.conf, que contém mais de 600 linhas de parâmetros minuciosamente documentados. Não vamos reproduzir o arquivo inteiro aqui, mas sim focar nas seções que você precisa ajustar para ter um sistema funcional e seguro. Cada parâmetro será explicado com seu propósito, valor recomendado e impacto na detecção. O arquivo completo está disponível no seu sistema após a instalação e contém comentários excelentes (em inglês) que complementam esta aula.

Abra o arquivo com seu editor preferido:

sudo vim /etc/psad/psad.conf
# ou
sudo nano /etc/psad/psad.conf

Abaixo, as seções críticas que você deve revisar e ajustar. Mostraremos o conteúdo exato como deve ficar após a edição, com comentários em português para clareza:

### Seção 1: Configuração de Email (para onde os alertas serão enviados)
### -----------------------------------------------------------------------
EMAIL_ADDRESSES             seu_email@dominio.com;   # Troque pelo seu email real
EMAIL_ALERT_DANGER_LEVEL    1;                       # Nível 1 = todos os alertas
                                                     # Nível 3 = apenas scans longos
                                                     # Nível 5 = apenas port sweeps severos

### Seção 2: Hostname e identificação nos alertas
### -----------------------------------------------------------------------
HOSTNAME                    servidor-web-producao;   # Aparece no assunto do email
HOME_NET                    ANY;                     # 'ANY' = monitora todo tráfego
                                                     # Pode ser '192.168.1.0/24' para
                                                     # monitorar apenas rede interna

### Seção 3: Interface do syslog e prefixos de log
### -----------------------------------------------------------------------
ENABLE_SYSLOG_FILE          Y;                       # Lê logs do arquivo, não do socket
SYSLOG_DAEMON               syslogd;                 # 'syslogd' para rsyslog tradicional
                                                     # Use 'syslog-ng' se for o caso
IPT_SYSLOG_FILE             /var/log/syslog;         # Ubuntu/Debian
#IPT_SYSLOG_FILE            /var/log/messages;       # Descomente para RHEL/CentOS/Rocky

### Seção 4: Prefixos que o psad deve procurar nos logs do iptables
### -----------------------------------------------------------------------
IPTABLES_LOG_PREFIX         PSAD_INPUT_TCP;          # Deve corresponder EXATAMENTE
IPTABLES_LOG_PREFIX2        PSAD_INPUT_UDP;          # ao que você usou em --log-prefix
IPTABLES_LOG_PREFIX3        PSAD_INPUT_ICMP;

### Seção 5: Thresholds de detecção (ajuste fino de sensibilidade)
### -----------------------------------------------------------------------
SCAN_TIMEOUT                3600;        # Janela de tempo (segundos) para agrupar scans
                                         # 3600 = 1 hora. Scans distribuídos em mais
                                         # tempo não são agrupados como um único ataque

THRESHOLD_TCP_PORT_SCAN      3;          # Número mínimo de portas TCP diferentes
                                         # acessadas para considerar um port scan
THRESHOLD_UDP_PORT_SCAN      2;          # Idem para UDP (mais sensível pois UDP scans
                                         # são mais raros e suspeitos)
THRESHOLD_ICMP_SWEEP         5;          # Número mínimo de hosts pingados
                                         # para considerar um ICMP sweep

ENABLE_TCP_PORT_SCAN_DETECTION    Y;     # Habilita detecção de TCP port scan
ENABLE_UDP_PORT_SCAN_DETECTION    Y;     # Habilita detecção de UDP port scan
ENABLE_ICMP_SWEEP_DETECTION       Y;     # Habilita detecção de ICMP sweeps

### Seção 6: Resposta automática (auto-blocking)
### -----------------------------------------------------------------------
ENABLE_AUTO_IDS              Y;         # ATENÇÃO: Habilita bloqueio automático!
                                         # Leia a seção sobre auto-blocking antes
                                         # de ativar em produção.
AUTO_IDS_DANGER_LEVEL        2;         # Bloqueia automaticamente scans com
                                         # danger level >= 2 (recomendado começar com 2)
AUTO_BLOCK_TIMEOUT           600;       # Tempo (segundos) que o IP fica bloqueado
                                         # 600 = 10 minutos. 3600 = 1 hora.
ENABLE_AUTO_IDS_EMAILS       Y;         # Envia email quando um IP é bloqueado
AUTO_SCAN_TIMEOUT            30;        # Após este tempo sem atividade do IP,
                                         # o contador de scan é resetado

### Seção 7: Assinaturas e detecção avançada
### -----------------------------------------------------------------------
ENABLE_SIGNATURE_MATCHING    Y;         # Habilita detecção por assinaturas
                                         # (detecta backdoors, trojans, etc.)
SIGNATURE_DANGER_LEVEL       2;         # Danger level mínimo para alertar
                                         # em matches de assinatura
ENABLE_DSHIELD_ALERTS        N;         # Integração com DShield (desabilitado
                                         # para ambiente local, pode ser ativado
                                         # em produção)
IGNORE_PORTS                 NONE;      # Portas a ignorar na detecção
                                         # Ex: '22,80,443' se quiser ignorar
                                         # tráfego para serviços legítimos
IGNORE_PROTOCOLS             NONE;      # Protocolos a ignorar
IGNORE_LOG_PREFIXES          NONE;      # Prefixos de log a ignorar

### Seção 8: Caminhos de arquivos e diretórios
### -----------------------------------------------------------------------
PSAD_DB_DIR                 /var/lib/psad;          # Diretório de dados persistentes
PSAD_PID_FILE               /var/run/psad/psad.pid; # Arquivo PID do daemon
FW_MSG_SEARCH               /var/lib/psad/psad.fwsearch;  # Cache de busca de logs

Esta configuração representa um ponto de partida seguro e funcional. Os valores de THRESHOLD_TCP_PORT_SCAN e THRESHOLD_UDP_PORT_SCAN podem ser ajustados com base no perfil de tráfego do seu ambiente. Em servidores web que recebem muito tráfego legítimo de crawlers e bots, talvez seja necessário aumentar o threshold TCP para 5 ou 7 para evitar falsos positivos. Por outro lado, em servidores internos com tráfego previsível, thresholds mais baixos aumentam a sensibilidade. Em nossos projetos na JRT Technology Solutions, costumamos começar com thresholds conservadores (4-5) e reduzir gradualmente após analisar uma semana de logs para entender o baseline de tráfego de cada cliente.

A tabela abaixo resume os parâmetros mais impactantes e seus efeitos práticos:

Habilitando e calibrando a resposta automática (auto-blocking)

O recurso de auto-blocking do Psad é o que o diferencia de simples analisadores de log. Quando ativado, ele adiciona dinamicamente o IP do atacante na chain PSAD_BLOCK_INPUT que criamos anteriormente, efetivamente bloqueando todo tráfego proveniente daquele IP por um período configurável. Antes de ativar em produção, é crucial entender o mecanismo e calibrá-lo corretamente para evitar que um falso positivo bloqueie um IP legítimo — como o do seu próprio escritório ou de um parceiro de negócios.

O fluxo de auto-blocking funciona assim: quando o Psad detecta um scan e o danger level calculado atinge ou ultrapassa AUTO_IDS_DANGER_LEVEL, ele imediatamente insere uma regra DROP na chain PSAD_BLOCK_INPUT para o IP do atacante. Ao mesmo tempo, inicia um temporizador baseado em AUTO_BLOCK_TIMEOUT. Quando o timeout expira, o Psad remove automaticamente a regra de bloqueio, liberando o IP. Durante o período de bloqueio, qualquer novo tráfego do IP bloqueado é descartado silenciosamente e não gera novos logs (evitando loops de detecção).

Para habilitar com segurança, siga esta sequência:

# 1. Verificar se as chains existem
sudo iptables -L PSAD_BLOCK_INPUT -n
sudo iptables -L PSAD_BLOCK_OUTPUT -n
sudo iptables -L PSAD_BLOCK_FORWARD -n

# 2. Verificar se as chains estão referenciadas nas chains principais
sudo iptables -L INPUT -n --line-numbers | grep PSAD_BLOCK
sudo iptables -L OUTPUT -n --line-numbers | grep PSAD_BLOCK
sudo iptables -L FORWARD -n --line-numbers | grep PSAD_BLOCK

# 3. Editar psad.conf e garantir que:
# ENABLE_AUTO_IDS  => Y
# AUTO_IDS_DANGER_LEVEL => 3 (comece com 3, mais seguro)
# AUTO_BLOCK_TIMEOUT => 600

# 4. Reiniciar o psad para aplicar as mudanças
sudo systemctl restart psad
# ou
sudo psad -H
# O sinal HUP faz o psad recarregar a configuração sem parar o daemon

# 5. Verificar se o auto-blocking está reconhecido
sudo psad --Status | grep -A5 "Auto-IDS"

Uma precaução essencial: SEMPRE adicione seus próprios IPs e redes confiáveis à whitelist do Psad ANTES de ativar o auto-blocking. Isso é feito no arquivo /etc/psad/auto_dl (auto danger level), onde você pode definir IPs que sempre terão danger level 0 (nunca serão bloqueados):

# Formato: IP/máscara  danger_level  protocolo_opcional
# Exemplo: whitelistar o IP do administrador e a rede local
192.168.1.100/32    0;
10.0.0.0/8          0;
172.16.0.0/12       0;
# IP do servidor de monitoramento
200.100.50.10/32    0;

Verificando a Instalação / Testando a Configuração

Com tudo configurado, é hora de verificar se o Psad está operacional e se a detecção funciona na prática. Esta seção é obrigatória — não prossiga sem executar cada verificação e confirmar que a saída corresponde (aproximadamente) ao esperado.

Verificação 1: Status do daemon psad

# Verificar se o serviço está rodando
sudo systemctl status psad

# Verificar status detalhado do psad
sudo psad --Status

● psad.service - Port Scan Attack Detector
   Loaded: loaded (/lib/systemd/system/psad.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2026-07-21 10:15:33 -03; 15min ago
     Docs: man:psad(8)
  Process: 12345 ExecStart=/usr/sbin/psad (code=exited, status=0/SUCCESS)
 Main PID: 12346 (psad)
    Tasks: 3 (limit: 4915)
   Memory: 8.7M
   CGroup: /system.slice/psad.service
           ├─12346 /usr/sbin/psad
           ├─12347 /usr/sbin/psad
           └─12348 /usr/sbin/psad

jul 21 10:15:33 servidor psad[12346]: psad started on servidor-web-producao
jul 21 10:15:33 servidor psad[12346]: [*] psad: auto-ids is enabled
jul 21 10:15:33 servidor psad[12346]: [*] psad: watching /var/log/syslog for iptables logs

Verificação 2: Confirmação de que os logs estão sendo coletados

# Gerar tráfego que deve ser logado: tentar conectar a uma porta fechada
nc -zv 127.0.0.1 55555
# ou, de outra máquina:
# nc -zv IP_DO_SERVIDOR 55555

# Verificar se a entrada apareceu no log do kernel/syslog
sudo tail -f /var/log/syslog | grep PSAD_INPUT
# Em RHEL/CentOS:
sudo tail -f /var/log/messages | grep PSAD_INPUT

# Verificar o que o psad está vendo nos logs
sudo psad --fw-analyze /var/log/syslog | tail -20

Jul 21 10:20:15 servidor kernel: [ 3456.789012] PSAD_INPUT_TCP: IN=eth0 OUT= MAC=00:15:5d:01:02:03:00:15:5d:04:05:06:08:00 SRC=192.168.1.150 DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=54321 DF PROTO=TCP SPT=45678 DPT=55555 WINDOW=64240 RES=0x00 SYN URGP=0
Jul 21 10:20:15 servidor psad[12346]: scan detected: 192.168.1.150 -> 192.168.1.100 tcp:55555

Verificação 3: Simulação de port scan com nmap

Este é o teste definitivo. De uma máquina diferente (na mesma rede), execute um port scan contra o servidor onde o Psad está rodando. Não execute contra localhost, pois o tráfego pode não passar pelas chains do iptables da mesma forma:

# NA MÁQUINA ATACANTE (substitua pelo IP real do servidor)
# Scan SYN stealth contra portas comuns
sudo nmap -sS -p 1-1024 192.168.1.100

# Scan UDP em portas específicas
sudo nmap -sU -p 53,161,500 192.168.1.100

# Scan ICMP (ping sweep)
nmap -sn 192.168.1.0/24

# Scan de versão (também detectável)
nmap -sV -p 22,80,443 192.168.1.100

Após executar os scans, volte ao servidor e verifique:

# Verificar alertas gerados pelo psad
sudo psad --Status | grep -A10 "Top attackers"
sudo psad -S

# Listar IPs atualmente bloqueados (se auto-blocking ativado)
sudo psad --fw-list

# Verificar emails enviados (se configurado)
sudo cat /var/mail/root
# ou
mail

[+] Top attackers (scanned ports & danger level):

    192.168.1.150  DL: 3, Scanned: 1024 (TCP), Danger Level: 3
    192.168.1.200  DL: 1, Scanned: 5 (UDP), Danger Level: 1

[+] Auto-IDS Status: ENABLED
    Auto-IDS Danger Level: 2
    Auto-Block Timeout: 600 seconds
    Currently blocked IPs: 1
    
    192.168.1.150  Blocked at: Tue Jul 21 10:25:47 2026
                   Unblock at: Tue Jul 21 10:35:47 2026
                   Rule: iptables -A PSAD_BLOCK_INPUT -s 192.168.1.150 -j DROP

Verificação 4: Teste de bloqueio automático

# Listar regras na chain de bloqueio
sudo iptables -L PSAD_BLOCK_INPUT -n -v

# Tentar conectar do IP bloqueado (deve falhar)
# Da máquina atacante:
nc -zv 192.168.1.100 22
# Deve retornar timeout ou "Connection refused" após timeout

# Verificar logs de bloqueio
sudo grep "auto-block" /var/log/psad/psad.log

Erros Comuns e Como Resolver

Mesmo seguindo todos os passos, problemas podem surgir. Abaixo, os cinco erros mais frequentes que encontramos em campo — inclusive em implementações que já corrigimos na JRT Technology Solutions — com diagnóstico preciso e solução completa para cada um.

• Erro 1: “psad –Status” mostra zero eventos detectados mesmo após executar scans.
  Causa: O Psad não está encontrando os logs do iptables no arquivo de syslog que está monitorando. Isso ocorre quando o parâmetro IPT_SYSLOG_FILE aponta para o arquivo errado (ex: /var/log/syslog no RHEL, que usa /var/log/messages), ou quando os prefixos configurados em IPTABLES_LOG_PREFIX não correspondem exatamente aos usados nas regras de LOG (diferença de espaços, maiúsculas/minúsculas ou dois-pontos).
  Sintoma: O daemon está rodando, mas psad –Status mostra 0 scans detectados e /var/log/psad/psad.log não contém entradas de análise.
  Solução: Verifique o arquivo de syslog correto para sua distribuição e ajuste IPT_SYSLOG_FILE. Execute grep “PSAD_INPUT” /var/log/syslog (ou messages) para confirmar se há logs sendo gerados. Compare exatamente o prefixo na saída do grep com o valor em IPTABLES_LOG_PREFIX — note que “PSAD_INPUT_TCP: “ (com espaço após os dois-pontos) é diferente de “PSAD_INPUT_TCP:” (sem espaço). Ajuste para que sejam idênticos. Reinicie o Psad com sudo systemctl restart psad.
• Erro 2: Auto-blocking não bloqueia IPs — chains vazias mesmo após scan detectado.
  Causa: As chains PSAD_BLOCK_INPUT, PSAD_BLOCK_OUTPUT e PSAD_BLOCK_FORWARD existem, mas não estão referenciadas (com jump) nas chains principais (INPUT, OUTPUT, FORWARD). O Psad adiciona as regras de bloqueio nas chains PSAD_BLOCK_*, mas se essas chains nunca são consultadas durante o processamento de pacotes, o bloqueio não tem efeito.
  Sintoma: psad –fw-list mostra IP bloqueado, iptables -L PSAD_BLOCK_INPUT mostra a regra de DROP, mas o IP ainda consegue acessar serviços.
  Solução: Execute iptables -L INPUT -n –line-numbers e confirme que há uma linha com PSAD_BLOCK_INPUT (idealmente no topo, antes das regras de permissão). Se não houver, insira manualmente com sudo iptables -I INPUT 1 -j PSAD_BLOCK_INPUT (e similar para OUTPUT e FORWARD se necessário). Salve as regras com iptables-save para persistir após reboot.
• Erro 3: “psad: cannot find syslog file” ou daemon não inicia.
  Causa: O arquivo de syslog especificado não existe ou o Psad não tem permissão de leitura. Em sistemas com syslog-ng, o arquivo pode ter nome ou localização diferente. Em alguns casos, o serviço rsyslog não está rodando ou não está gerando logs do kernel.
  Sintoma: Ao iniciar com systemctl start psad, o serviço falha imediatamente. journalctl -u psad mostra “cannot find syslog file /var/log/syslog”.
  Solução: Confirme que o arquivo de log existe: ls -la /var/log/syslog (ou /var/log/messages). Se não existir, instale/inicie o rsyslog: sudo apt install rsyslog && sudo systemctl enable –now rsyslog (Debian/Ubuntu) ou sudo dnf install rsyslog && sudo systemctl enable –now rsyslog (RHEL). Se estiver usando syslog-ng, altere SYSLOG_DAEMON para syslog-ng e ajuste IPT_SYSLOG_FILE. Ajuste permissões se necessário: sudo chmod 644 /var/log/syslog.
• Erro 4: Alertas por email não chegam — silêncio total apesar de scans detectados.
  Causa: O Psad depende de um agente de email local (MTA) como Postfix, Sendmail ou Exim para enviar alertas. Se nenhum MTA estiver configurado, ou se estiver configurado apenas para entrega local, os emails ficam presos na fila ou em /var/mail/root e nunca chegam ao destino externo.
  Sintoma: Scans são detectados (psad –Status mostra atacantes), mas você não recebe emails. O log /var/log/mail.log mostra mensagens “connection timed out” ou “Host or domain name not found”.
  Solução: Instale e configure um MTA para encaminhamento externo. Para testes, a maneira mais simples é instalar o Postfix e configurá-lo para usar um relay SMTP (como Gmail, SendGrid ou servidor da empresa). Alternativamente, configure o Psad para usar um script de notificação personalizado: crie um script em /usr/local/bin/psad-alert.sh e configure o parâmetro ALERTING_METHODS no psad.conf para chamar seu script. Teste o MTA independentemente do Psad com echo “Teste” | mail -s “Teste” seu_email@dominio.com.
• Erro 5: Falsos positivos excessivos — IPs legítimos sendo bloqueados constantemente.
  Causa: Os thresholds estão muito baixos para o perfil de tráfego do ambiente. Servidores que hospedam APIs, WebSockets ou serviços de monitoramento (como Nagios, Zabbix, Prometheus) podem gerar tráfego que se assemelha a port scans — múltiplas conexões a portas diferentes em curto espaço de tempo.
  Sintoma:

  Quer aprender na prática com especialistas?

  A JRT Technology Solutions oferece treinamentos e implementação de Segurança Linux para equipes corporativas.

  
  
  Falar no WhatsApp