Deploy de firewall UFW no Fedora 42 é a instalação do Uncomplicated Firewall como frontend de nftables, com o firewalld desativado para não haver duas políticas ao mesmo tempo, e a aplicação de regras de SSH, HTTP e HTTPS. Para concluir o fluxo completo, siga estes passos:
- Atualize o Fedora 42 e instale o pacote ufw com dnf.
- Pare, desative e mascare o firewalld antes de qualquer regra UFW.
- Defina deny incoming, allow outgoing e libere SSH só do seu IP.
- Permita 80/tcp e 443/tcp e ative o logging em nível medium.
- Habilite o UFW numa segunda sessão SSH já autenticada.
- Valide com ufw status verbose, ss e journalctl.
Pré-requisitos
O Uncomplicated Firewall no Fedora 42 só deve ser ativado depois de garantir acesso de recuperação: o enable aplica a política imediatamente e um erro na regra de SSH corta a sessão. Trabalhe como root ou com sudo, em um host Fedora 42 atualizado, com sshd escutando e com o IP público de administração conhecido (use blocos de documentação como 203.0.113.10 nos exemplos). Confirme a interface com ip -br addr e as portas com ss -tlnp para não liberar serviço que ainda não existe. Se o servidor for um Servidor VPS, tenha o console KVM ou serial do provedor aberto. O firewalld costuma vir habilitado nesta distro; ele e o UFW não devem controlar nftables em paralelo. Tenha um segundo terminal SSH autenticado antes de ufw enable. IPv6 dual-stack exige regras explícitas. Não invente perfis de aplicativo: use portas e proto quando o perfil OpenSSH não existir no pacote.
- Fedora 42 com dnf funcional e sshd ativo.
- IP de administração (exemplo: 203.0.113.10) e console de emergência.
- Segunda sessão SSH aberta; sudo ou root.
- Lista das portas reais do site (80, 443) e da porta SSH se não for 22.
- firewalld será parado e mascarado; não misture as duas stacks.
Deploy de firewall UFW no Fedora 42: fluxo completo
O deploy de firewall UFW no Fedora 42 começa pela troca controlada do firewalld pelo UFW, que grava regras em nftables. Atualize o sistema e instale o pacote; em seguida trate o conflito com o serviço nativo. Sem mascarar o firewalld, um reboot pode reaplicar a zona public e anular o que você definiu no UFW.
sudo dnf upgrade -y
sudo dnf install -y ufw
sudo systemctl stop firewalld
sudo systemctl disable firewalld
sudo systemctl mask firewalld
sudo systemctl status firewalld --no-pagerLoaded: masked
Active: inactive (dead)Defina a política padrão antes de qualquer allow amplo. Incoming deny reduz a superfície; outgoing allow evita quebrar dnf, DNS e NTP. Libere SSH pelo seu IP, nunca 0.0.0.0/0, se a operação for só sua. Quem precisa de acesso de equipe usa um prefixo pequeno, não a internet inteira. Consulte também o material de acesso a servidores VPS Linux para não perder o canal administrativo.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'admin-ssh'
sudo ufw allow 80/tcp comment 'http-seudominio.com.br'
sudo ufw allow 443/tcp comment 'https-seudominio.com.br'
sudo ufw logging medium
sudo ufw status verboseStatus: inactive
Logging: on (medium)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skipAtenção: ufw enable ativa o filtro na hora. Se a regra de SSH estiver errada, a sessão cai. Confirme o IP de origem na conexão atual e mantenha o outro terminal aberto. Depois do enable, recarregar não substitui testar o login novo.
sudo ufw enable
sudo ufw status verbose
ss -tlnp | grep -E ':22|:80|:443'Firewall is active and enabled on system startup
Status: active
Logging: on (medium)
Default: deny (incoming), allow (outgoing), deny (routed)
To Action From
-- ------ ----
22/tcp ALLOW IN 203.0.113.10
80/tcp ALLOW IN Anywhere
443/tcp ALLOW IN AnywhereSe o site precisa redirecionar HTTP para HTTPS no proxy ou no servidor web, o firewall só abre as portas; a troca de esquema fica na aplicação, como no guia de redirecionar um site HTTP para HTTPS. Não abra 8080, 8443 ou painéis só porque a stack “pode” usá-los: cada porta extra é sonda na internet.
Regras avançadas, ordem numbered e IPv6
A filtragem por origem e a ordem numbered definem se um deny ganha de um allow genérico. O UFW avalia de cima para baixo; inserir um bloqueio na posição 1 impede que um allow posterior abra a mesma porta para o atacante. Use ufw status numbered sempre que for apagar ou reordenar. Para um painel ou SSH extra, restrinja ao IP; para o site público, 80 e 443 permanecem abertos. IPv6 ativo sem regra v6 equivalente deixa um caminho paralelo: se dual-stack estiver ligado, replique allows e denys em v6 ou desative IPv6 de forma consciente no sysctl, o que foge deste fluxo.
sudo ufw status numbered
sudo ufw insert 1 deny from 198.51.100.23 to any port 22 proto tcp comment 'ssh-probe'
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw deny 3306/tcp
sudo ufw limit 22/tcp
sudo ufw delete 3 To Action From
[ 1] 22/tcp DENY IN 198.51.100.23
[ 2] 22/tcp ALLOW IN 203.0.113.10
[ 3] 80/tcp ALLOW IN Anywhere
[ 4] 443/tcp ALLOW IN AnywhereAtenção: ufw reset apaga todas as regras e desativa o firewall. Só use com o console KVM à mão e com a lista de regras documentada. Depois do reset, refaça SSH restrito antes de qualquer enable. Comentários nas regras ajudam a auditoria seis meses depois, quando ninguém lembra por que a porta 22 aceita um prefixo. Não misture ufw route de forwarding com host simples de site: routed deny é o padrão seguro para um origin HTTP. Se a porta SSH não for 22, troque o número em todas as linhas; o perfil OpenSSH não cobre porta customizada.
Deploy de firewall UFW no Fedora 42 com regras por aplicativo
Quando o pacote oferece perfil, ufw app list e ufw allow OpenSSH simplificam. No Fedora 42 o perfil pode não existir; nesse caso a forma estável é porta e proto. Não abra FTP 21 em produção web moderna. Banco de dados permanece deny no filtro de borda: conexão remota a MySQL ou MariaDB, se existir, deve ser túnel SSH ou rede privada, nunca 3306 na internet.
Logs do UFW, journald e disco
O journald concentra os eventos do UFW no Fedora 42 quando logging está on ou medium: drops, allows e invalidos aparecem em journalctl -u ufw e, se rsyslog estiver instalado e o snippet ufw ativo, também em /var/log/ufw.log. Nível high ou full gera volume alto em host exposto; medium costuma bastar para ver scans em 22, 3389 e 445 sem encher o disco. Correlacione timestamp do log com ss e com o access log do Nginx ou Apache. Um allow que nunca gera hit no journald com destino 443 indica que o serviço não escuta ou que outro filtro (provedor, security group) corta antes.
sudo ufw logging medium
journalctl -u ufw -n 50 --no-pager
sudo grep -E 'UFW (BLOCK|ALLOW)' /var/log/ufw.log | tail -n 20[UFW BLOCK] IN=eth0 SRC=198.51.100.80 DST=203.0.113.50 PROTO=TCP DPT=22
[UFW ALLOW] IN=eth0 SRC=203.0.113.10 DST=203.0.113.50 PROTO=TCP DPT=22Se /var/log/ufw.log não existir, o rsyslog não está processando o kernel netfilter; o journald continua válido. Evite logging full em VPS com disco pequeno. Rotacione logs pelo journald (vacuum por tempo) e não copie trechos de log com IP de cliente real para tickets públicos. Bloqueios repetidos na mesma origem combinam com regra numbered deny, não com dezenas de allows soltos. O UFW não substitui WAF nem TLS: ele só decide se o pacote chega no processo que escuta.
Problemas comuns e como resolver
Sintoma: SSH cai logo após ufw enable
Causa: a política deny incoming entrou em vigor sem allow na porta SSH para o seu IP, ou a porta real não é 22.
Solução: use o console KVM, rode ufw disable ou ufw allow from SEU_IP to any port PORTA proto tcp e só então ufw enable. Confira a porta com ss -tlnp | grep sshd. Se o problema for autenticação e não filtro, veja o guia de problemas de acesso SSH no VPS Linux.
Sintoma: site inacessível na 80/443 com UFW active
Causa: faltou allow 80/tcp e 443/tcp, há deny numbered acima, ou o serviço não está bound em 0.0.0.0.
Solução: ufw status numbered, insira os allows, confirme com ss -tlnp e teste de outro host. IPv6 sem regra v6 também gera falha só em clientes dual-stack.
Sintoma: regras UFW somem depois do reboot
Causa: firewalld voltou (não estava masked) ou o UFW não ficou enabled on startup.
Solução: systemctl is-enabled firewalld deve falhar por masked; ufw status verbose deve mostrar active. Remascarar firewalld e ufw enable de novo. Não reative firewalld “só para testar” no mesmo host.
Perguntas frequentes sobre deploy de firewall UFW no Fedora 42
O UFW funciona no Fedora 42 junto com firewalld?
O UFW é uma interface para nftables. No Fedora 42 o firewalld costuma vir ativo; desative e mascare o firewalld antes de habilitar o UFW para evitar duas políticas conflitantes. Confirme com systemctl e ufw status verbose. Se os dois estiverem enabled, o resultado após reboot é imprevisível e o site pode ficar aberto ou fechado sem a regra que você documentou.
Como liberar HTTP e HTTPS no UFW sem abrir o SSH para o mundo?
Permita OpenSSH (ou a porta SSH customizada) a partir do seu IP, depois allow 80/tcp e 443/tcp. Use deny incoming como política padrão. Teste a sessão SSH em outro terminal antes de ufw enable. Assim o origin web responde na internet e o administrativo permanece restrito ao prefixo 203.0.113.10 dos exemplos, trocado pelo seu IP real.
Onde o UFW grava logs no Fedora 42?
Com logging on ou logging medium, os eventos aparecem no journald (journalctl -u ufw) e em /var/log/ufw.log quando o rsyslog/rsyslog-ufw estiver configurado. Ajuste o nível para não encher o disco. Medium é o ponto de partida para ver BLOCK em portas fechadas sem transformar o journal em ruído contínuo.
Como criar regras avançadas por IP e porta no UFW?
Use ufw allow from 203.0.113.10 to any port 22 proto tcp e regras numbered para inserir deny antes de allow. ufw status numbered lista a ordem; delete pelo número. IPv6 exige regras explícitas se o dual-stack estiver ativo. Comentários nas regras e um deny pontual para scanner conhecido evitam allow genérico demais na mesma porta.
O que fazer se o UFW bloquear o acesso após enable?
Use o console do provedor (KVM/IPMI) e execute ufw disable ou ufw allow OpenSSH. Nunca ative o firewall sem regra de SSH. Depois recrie as regras e reative com ufw enable. Sem console, o único caminho é esperar alguém no datacenter; por isso o segundo terminal e o IP correto são pré-requisito, não detalhe.
Conclusão
- Mascarar firewalld, deny incoming e SSH só do seu IP antes de qualquer
ufw enable. - Abrir 80/tcp e 443/tcp para o site e manter 3306 e painéis fechados na borda.
- Usar logging medium, numbered e journalctl para auditar BLOCK sem lotar o disco.
Leia também
- Comparativo: Firewall Linux Nativo (iptables/nftables) vs. Firewall Gerenciado em Servidor Dedicado
- Passo a passo para configurar firewall com nftables em VPS Linux e servidor dedicado
- UFW vs iptables: Qual escolher para seu VPS Ubuntu?
Precisa de ajuda com firewall UFW no Fedora 42?
Um VPS com console KVM e rede estável reduz o risco de lockout na hora de ativar o UFW e facilita testar HTTP, HTTPS e SSH com regras numbered. A AviraHost entrega servidores em que você aplica este fluxo com acesso root e recuperação via console.
