FERRAMENTAS LINUX: .NET no Ubuntu: Guia Completo para Identificar, Corrigir e Prevenir Ameaças de Segurança

Proteja seus aplicativos .NET no Ubuntu contra ataques de negação de serviço e outras vulnerabilidades. Aprenda a verificar, corrigir com scripts automatizados e implementar camadas extras de proteção com iptables, AppArmor e proxies.

Em maio de 2026, a divulgou o aviso de segurança , identificando uma vulnerabilidade crítica nas versões 8, 9 e 10 do .NET para Ubuntu.

A falha, descoberta por , permite que um invasor remoto consuma recursos excessivos do servidor ao enviar requisições de rede especialmente criadas, resultando em (DoS).

Este guia foi criado para ajudá-lo a proteger seus sistemas de forma prática, independentemente da data em que você estiver lendo.

Aqui você encontrará comandos reais para verificar se está vulnerável, scripts de automação para aplicar correções, medidas alternativas de mitigação e boas práticas para manter suas aplicações .NET seguras a longo prazo.

Entendendo a Ameaça: Como Funciona o Ataque

A vulnerabilidade explorada no USN-8298-1 afeta o manipulador de requisições de rede do .NET. Um invasor pode enviar pacotes maliciosos que criam um loop infinito dentro do runtime, consumindo toda a CPU e memória disponível até que o serviço pare de responder.

Principais versões afetadas:

Ubuntu 26.04 LTS

Ubuntu 25.10

Ubuntu 24.04 LTS

Ubuntu 22.04 LTS

Pacotes vulneráveis:

dotnet8, dotnet9, dotnet10

aspnetcore-runtime-8.0/9.0/10.0

dotnet-sdk-8.0/9.0/10.0

dotnet-runtime-8.0/9.0/10.0

A correção foi incluída nas seguintes versões de pacote:

.NET 8 → versão 8.0.27

.NET 9 → versão 9.0.16

.NET 10 → versão 10.0.8

Como Verificar se Você Está Vulnerável (Comandos Reais para Ubuntu)

Siga os passos abaixo para inspecionar manualmente seu sistema:

Identifique as Versões do .NET Instaladas

# Lista todos os pacotes .NET instalados no sistema
dpkg -l | grep -E "dotnet|aspnetcore"

# Ou use o comando dotnet (se disponível no PATH)
dotnet --list-sdks
dotnet --list-runtimes

Verifique a Versão Específica de Cada Pacote

# Verifique a versão do dotnet-runtime-8.0 (exemplo)
apt policy dotnet-runtime-8.0

# Saída esperada:
# Installed: 8.0.27-0ubuntu1~22.04.1
# Candidate: 8.0.27-0ubuntu1~22.04.1

Comparação com versões seguras:

.NET 8: versão instalada deve ser ≥ 8.0.27

.NET 9: versão instalada deve ser ≥ 9.0.16

.NET 10: versão instalada deve ser ≥ 10.0.8

Se sua versão for inferior à listada acima, seu sistema está vulnerável.

Verificação Rápida com Script One-Liner

# Verifica todos os pacotes .NET e exibe versões instaladas
dpkg -l | grep -E "dotnet-(runtime|sdk|host)|aspnetcore-runtime" | awk '{print $2 " -> " $3}'

Script de Automação para Aplicar a Correção

Salve o script abaixo como e execute com sudo bash fix-dotnet-ubuntu.sh.

#!/bin/bash
# Script de correção automática para vulnerabilidade .NET no Ubuntu
# Compatível com Ubuntu 22.04 LTS, 24.04 LTS, 25.10 e 26.04 LTS

set -e  # Interrompe o script em caso de erro

# Cores para output
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m' # Sem cor

echo -e "${GREEN}=== Script de Correção de Segurança .NET para Ubuntu ===${NC}"
echo "Iniciado em: $(date)"
echo ""

# 1. Atualizar lista de pacotes
echo -e "${YELLOW}[1/4] Atualizando lista de pacotes...${NC}"
sudo apt update

# 2. Identificar pacotes .NET instalados
echo -e "${YELLOW}[2/4] Identificando pacotes .NET instalados...${NC}"
DOTNET_PACKAGES=$(dpkg -l | grep -E "dotnet|aspnetcore" | grep "^ii" | awk '{print $2}')

if [ -z "$DOTNET_PACKAGES" ]; then
    echo -e "${GREEN}Nenhum pacote .NET encontrado. Seu sistema não está vulnerável.${NC}"
    exit 0
fi

echo "Pacotes encontrados:"
echo "$DOTNET_PACKAGES"
echo ""

# 3. Aplicar atualizações
echo -e "${YELLOW}[3/4] Aplicando atualizações de segurança...${NC}"
sudo apt upgrade --only-upgrade -y $DOTNET_PACKAGES 2>/dev/null || \
sudo apt dist-upgrade -y

# 4. Verificar resultado
echo -e "${YELLOW}[4/4] Verificando versões após atualização...${NC}"
echo ""
echo -e "${GREEN}=== VERSÕES ATUALIZADAS ===${NC}"
dpkg -l | grep -E "dotnet-(runtime|sdk|host)|aspnetcore-runtime" | awk '{print $2 " -> " $3}'

echo ""
echo -e "${GREEN}✓ Correção aplicada com sucesso!${NC}"
echo "Recomenda-se reiniciar os serviços .NET em execução:"
echo "  sudo systemctl restart nome-do-seu-servico"

Como usar o script:

chmod +x fix-dotnet-ubuntu.sh
sudo ./fix-dotnet-ubuntu.sh

Só instalar o patch do kernel não basta. E se você não pode reiniciar o servidor agora ? O livro "" ensina iptables, AppArmor e scripts de defesa – exatamente o que usamos no nosso guia .

Segurança em Servidores Linux Ataque e Defesa (anúncio) -> https://amzn.to/3PFKb4x

Eu ganho uma comissão aundo você faz uma compra.

Mitigação Alternativa (Caso Não Possa Atualizar Agora)

Se você não pode reiniciar os serviços ou aplicar a atualização imediatamente, implemente as camadas de proteção abaixo:

Bloqueio com iptables (Firewall Local)

O iptables pode limitar a taxa de requisições, impedindo que um atacante sobrecarregue o serviço.

# Limitar conexões novas a 10 por segundo por IP (proteção contra DoS)
sudo iptables -A INPUT -p tcp --dport 5000 -m state --state NEW -m limit --limit 10/second --limit-burst 20 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 5000 -j DROP

# Salvar regras (persistente após reboot)
sudo apt install iptables-persistent -y
sudo netfilter-persistent save

Importante: Substitua a porta 5000 pela porta onde sua aplicação .NET está rodando (ex: 80, 443, 8080).

Proteção com AppArmor (Restrição de Recursos)

O AppArmor pode limitar o consumo de CPU e memória do processo .NET.

# Criar perfil AppArmor para sua aplicação
sudo aa-genprof /caminho/para/sua/aplicacao

Exemplo de perfil (arquivo /etc/apparmor.d/usr.bin.dotnet):

/usr/bin/dotnet {
    # Limitar recursos
    set rlimit cpu <= 600,      # 10 minutos de CPU
    set rlimit nproc <= 100,    # Máximo 100 processos filhos
    set rlimit nofile <= 2048,  # Máximo 2048 arquivos abertos
    
    # Permitir acesso apenas aos diretórios necessários
    /usr/bin/dotnet mr,
    /usr/share/dotnet/** r,
    /home/*/.dotnet/** rw,
    
    # Bloquear tudo que não for explicitamente permitido
    deny /tmp/** w,
}

Proxy Reverso com Rate Limiting (Nginx)

Se sua aplicação estiver atrás de um proxy reverso, configure limites de requisição:

# /etc/nginx/sites-available/sua-aplicacao
limit_req_zone $binary_remote_addr zone=dotnet_limit:10m rate=10r/s;

server {
    listen 80;
    server_name seu-dominio.com;

    location / {
        limit_req zone=dotnet_limit burst=20 nodelay;
        proxy_pass http://localhost:5000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Configuração de Timeout no Kestrel

Dentro do seu appsettings.json ou Program.cs, configure timeouts agressivos:

{
  "Kestrel": {
    "Limits": {
      "MaxConcurrentConnections": 100,
      "MaxConcurrentUpgradedConnections": 100,
      "RequestHeadersTimeout": "00:00:10",
      "KeepAliveTimeout": "00:00:30"
    }
  }
}

Checklist de Hardening para .NET em Produção

Mantenha seus servidores protegidos com estas práticas essenciais:

Antes do Deploy

Utilize usuário não-root para executar a aplicação (crie um usuário dotnetapp)

Remova símbolos de debug (dotnet publish -c Release)

Execute análise estática de dependências (dotnet list package --vulnerable)

No Ambiente de Produção

Configure um Web Application Firewall (WAF) como ModSecurity

Habilite HTTPS obrigatório com HSTS

Configure logs de auditoria e monitore acessos suspeitos

Utilize chaves de API e segredos via Azure Key Vault ou HashiCorp Vault

Manutenção Contínua

Automatize verificações semanais com apt list --upgradable | grep dotnet

Configure alertas para tráfego anormal (Prometheus + Grafana)

Mantenha um plano de rollback em caso de atualização problemática

Conclusão: Da Correção à Prevenção Contínua

Você acabou de ver que uma vulnerabilidade como a do .NET no Ubuntu não é o fim do mundo – é um lembrete de que segurança se constrói com hábitos, não com sustos.

Agora você tem na mão:

Comandos para descobrir se seu servidor está exposto

Um script pronto para rodar e aplicar a correção sem erro

Mitigações de emergência (iptables, AppArmor, proxy) para quando não dá para parar o serviço

Um checklist de hardening para não depender mais de atualizações de última hora

Mas o que faz a diferença a longo prazo não é saber consertar uma falha específica. É construir uma rotina de verificações, automação e estudo contínuo.