Fortalecimento da segurança do servidor de produção: uma lista de verificação abrangente

O tempo médio para identificar uma violação de dados é de 204 dias. A proteção do servidor de produção reduz a superfície de ataque para que as violações sejam mais difíceis de iniciar e mais rápidas de detectar. Este guia aborda as medidas concretas de segurança que todo servidor de produção deve implementar, desde a configuração SSH até firewalls de aplicativos web.

Principais conclusões

• Autenticação somente com chave SSH e portas não padrão bloqueiam 99% dos ataques automatizados de força bruta
• Um firewall configurado corretamente reduz a superfície de ataque de milhares de pontos de entrada para menos de dez
• Firewalls de aplicativos da Web bloqueiam injeção de SQL, XSS e outros ataques OWASP Top 10 na camada de rede
• A correção automatizada garante que as vulnerabilidades sejam corrigidas horas após a divulgação, não semanas

---

Endurecimento SSH

Configuração

# /etc/ssh/sshd_config

# Disable password authentication
PasswordAuthentication no
ChallengeResponseAuthentication no

# Disable root login
PermitRootLogin no

# Use SSH keys only
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# Limit login attempts
MaxAuthTries 3
MaxSessions 5

# Set idle timeout (5 minutes)
ClientAliveInterval 300
ClientAliveCountMax 0

# Restrict SSH to specific users
AllowUsers deploy ubuntu

# Disable X11 forwarding
X11Forwarding no

# Use only strong algorithms
KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]

Fail2Ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

[nginx-http-auth]
enabled = true
filter = nginx-http-auth
logpath = /var/log/nginx/error.log
maxretry = 5
bantime = 3600

---

##Configuração de Firewall

###UFW (Ubuntu)

# Reset and set default policies
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH (consider changing port)
sudo ufw allow 22/tcp

# Allow HTTP/HTTPS
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Allow specific IPs for management
sudo ufw allow from 203.0.113.10 to any port 9090 comment "Grafana"
sudo ufw allow from 203.0.113.10 to any port 9093 comment "Alertmanager"

# Deny everything else (implicit with default deny)
sudo ufw enable
sudo ufw status verbose

Grupos de segurança da AWS

# Terraform security group
resource "aws_security_group" "app" {
  name_prefix = "app-"
  vpc_id      = aws_vpc.main.id

  # Allow HTTPS from anywhere
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "HTTPS from internet"
  }

  # Allow SSH from office IP only
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/24"]
    description = "SSH from office"
  }

  # Allow all outbound
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# Database security group - no public access
resource "aws_security_group" "db" {
  name_prefix = "db-"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.app.id]
    description     = "PostgreSQL from app servers only"
  }
}

---

Cabeçalhos de segurança Nginx

# Security headers for all responses
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self' https://api.example.com;" always;

# Hide server version
server_tokens off;

# Limit request size
client_max_body_size 10m;

# Rate limiting
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

server {
    location / {
        limit_req zone=general burst=20 nodelay;
    }

    location /api/ {
        limit_req zone=api burst=50 nodelay;
    }

    location /auth/ {
        limit_req zone=login burst=3 nodelay;
    }
}

---

Configuração SSL/TLS

# Modern TLS configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;

# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;

# Session configuration
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

# Certificate (Let's Encrypt)
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Renovação automatizada de certificado

# /etc/cron.d/certbot
0 0,12 * * * root certbot renew --quiet --post-hook "nginx -s reload"

---

Segurança de contêineres

Se estiver executando o Docker em produção, aplique estas medidas adicionais de proteção:

Segurança do Docker Daemon

{
  "userns-remap": "default",
  "no-new-privileges": true,
  "live-restore": true,
  "userland-proxy": false,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Restrições de tempo de execução do contêiner

# docker-compose.yml security settings
services:
  api:
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

Princípios-chave:

• Elimine todos os recursos e adicione novamente apenas o que for necessário
• Sistema de arquivos somente leitura evita que invasores modifiquem o conteúdo do contêiner
• Sem novos privilégios evita o escalonamento de privilégios dentro de contêineres
• Usuário não root no Dockerfile (consulte nosso guia de implantação do Docker)

Segurança de imagem

• Use imagens de base mínimas oficiais (variantes Alpinas)
• Fixar versões de imagem (nunca use :latest em produção)
• Digitalize imagens em busca de vulnerabilidades com Trivy ou Grype
• Assine imagens com Docker Content Trust
• Use um registro privado com controles de acesso

---

Segurança do banco de dados

Endurecimento PostgreSQL

# postgresql.conf security settings
listen_addresses = 'localhost'        # Only listen on localhost
ssl = on                              # Require SSL for connections
ssl_cert_file = '/path/to/server.crt'
ssl_key_file = '/path/to/server.key'
password_encryption = scram-sha-256   # Modern password hashing
log_connections = on                  # Log all connections
log_disconnections = on               # Log disconnections
log_statement = 'ddl'                 # Log DDL statements

# pg_hba.conf - restrict connections
# TYPE  DATABASE  USER  ADDRESS      METHOD
local   all       all                scram-sha-256
host    all       all   10.0.0.0/8   scram-sha-256
hostssl all       all   0.0.0.0/0    scram-sha-256

• Nunca exponha o PostgreSQL à Internet pública
• Use usuários de banco de dados dedicados com permissões mínimas necessárias
• Habilitar criptografia de conexão (SSL)
• Defina políticas de senha fortes
• Verificação regular de backup (consulte nosso guia de recuperação de desastres)

---

Detecção de intrusão

Configuração OSSEC

<!-- /var/ossec/etc/ossec.conf -->
<ossec_config>
  <syscheck>
    <!-- Monitor critical files for changes -->
    <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
    <directories check_all="yes">/opt/app/dist</directories>

    <!-- Ignore frequently changing files -->
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/resolv.conf</ignore>

    <!-- Run integrity check every 6 hours -->
    <frequency>21600</frequency>
  </syscheck>

  <rootcheck>
    <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
  </rootcheck>
</ossec_config>

###AWS GuardDuty

resource "aws_guardduty_detector" "main" {
  enable = true

  datasources {
    s3_logs {
      enable = true
    }
    kubernetes {
      audit_logs {
        enable = true
      }
    }
  }
}

---

Patches de segurança automatizados

# Ubuntu: Enable unattended security updates
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
Unattended-Upgrade::Mail "[email protected]";

---

Lista de verificação de reforço de segurança

Nível do servidor

• [] Autenticação somente com chave SSH, login root desabilitado
• [] Firewall configurado com política de negação por padrão
• [] Fail2Ban ativo em SSH e servidor web
• [] Atualizações automáticas de segurança habilitadas
• Serviços não essenciais desativados
• [] Monitoramento de integridade de arquivos (OSSEC ou equivalente)
• [] Registro de auditoria ativado (auditd)

Nível de aplicação

• [] TLS 1.2+ em todos os endpoints, HSTS habilitado
• [] Cabeçalhos de segurança configurados (CSP, X-Frame-Options, etc.)
• [] Limitação de taxa em todos os endpoints públicos
• [] Validação de entrada e consultas parametrizadas (sem sql.raw())
• [] HttpOnly, cookies seguros para autenticação
• [] CORS restrito a origens conhecidas
• [] As respostas de erro não vazam rastreamentos de pilha

Nível de rede

• [] Banco de dados não acessível publicamente
• [] Serviços internos em sub-redes privadas
• [] endpoints VPC para serviços AWS (sem internet pública)
• [] WAF em endpoints voltados ao público
• [] Proteção DDoS (Cloudflare, AWS Shield)

Monitoramento

• [] Alerta de evento de segurança configurado
• [] Retenção de log por pelo menos 90 dias
• [] Tentativas de autenticação com falha monitoradas
• [] Padrões de tráfego incomuns detectados

---

Perguntas frequentes

Com que frequência devemos realizar auditorias de segurança?

Verificações automatizadas trimestrais (verificação de vulnerabilidades, auditorias de dependências) e testes de penetração manuais anuais. Aplicações de alto risco (processamento de pagamentos, dados de saúde) devem passar por testes de penetração externos a cada 6 meses. Toda implantação de produção deve incluir verificação de segurança automatizada no pipeline de CI/CD --- consulte nosso guia de práticas recomendadas de CI/CD.

É necessário um WAF se já tivermos limitação de taxa?

Sim. A limitação de taxa evita abusos, mas não inspeciona o conteúdo da solicitação. Um WAF bloqueia injeção de SQL, XSS e outros ataques à camada de aplicação, analisando cargas úteis de solicitação. Pense na limitação de taxa como proteção contra inundações e no WAF como inspeção de conteúdo – você precisa de ambos.

Como podemos proteger um servidor de produção Odoo?

Além do fortalecimento geral acima: desative o gerenciador de banco de dados em produção (list_db = False), defina um admin_passwd forte, use dbfilter para restringir o acesso ao banco de dados, execute o Odoo atrás do Nginx (nunca exponha o Odoo diretamente) e mantenha o Odoo e todos os módulos atualizados. ECOSIRE fornece reforço de segurança Odoo como parte de nossos serviços de hospedagem gerenciada.

Qual é a medida de segurança mais impactante?

Habilitando MFA (autenticação multifator) em todas as contas administrativas. Este controle único evita 99% dos ataques baseados em credenciais. Implemente MFA em SSH (via PAM), console AWS, ferramentas de administração de banco de dados e painéis de administração de aplicativos antes de qualquer outra medida de proteção.

---

O que vem a seguir

O fortalecimento da segurança é uma prática contínua. Combine-o com monitoramento e alertas para detecção, recuperação de desastres para resiliência e verificação de segurança de CI/CD para prevenção.

Entre em contato com a ECOSIRE para obter consultoria de reforço de segurança ou explore nosso guia DevOps para obter o roteiro completo de infraestrutura.

---

Publicado pela ECOSIRE – ajudando as empresas a proteger a infraestrutura de produção.