Saltar para o conteúdo 
O Firewall Web Plesk protege os sítios Web especificamente contra ciberataques como a injeção de SQL e o cross-site scripting (XSS). Em apenas alguns passos, pode configurar uma barreira de segurança eficaz no Plesk que reconhece e afasta tanto as ameaças automatizadas como os ataques manuais.
Pontos centrais
- Injeção de SQLImpede a manipulação da base de dados através de consultas maliciosas.
- Defesa XSSBloqueia a injeção de JavaScript em formulários e URLs.
- ModSecurityComponente central do Plesk WAF para deteção e defesa contra ataques.
- Regras de firewallPersonalizável para permitir apenas as ligações necessárias.
- Actualizações de segurançaA instalação regular de correcções protege contra vulnerabilidades conhecidas.
Início de sessão e primeiro acesso à configuração da firewall
Entro no painel Plesk, abro a secção "Ferramentas e definições" na barra lateral e encontro o item "Firewall". Se a firewall ainda estiver desactivada, ativo-a diretamente através do cursor. A partir desse momento, o Plesk bloqueia todas as ligações de entrada que não sejam explicitamente permitidas. Isto reduz imediatamente o risco de acesso indesejado. Para cenários de alojamento normalizados, é aconselhável verificar primeiro cuidadosamente as regras de firewall predefinidas.
O Plesk vem com configurações padrão sensatas para servidores web, e-mail, FTP e SSH. No entanto, eu ajusto as regras manualmente para que apenas as portas que são realmente necessárias permaneçam abertas - como 443 para HTTPS ou 22 para SSH. Vale a pena pensar cuidadosamente sobre quais os serviços que precisam efetivamente de estar acessíveis ao público. Os serviços supérfluos são potenciais portas de entrada para os atacantes, e é por isso que eu sigo rigorosamente o princípio da minimização.
Regras próprias: Segurança de ajuste fino
Se eu quero Ligações específicas Posso criar as minhas próprias regras de firewall. Clico em "Add rule" (Adicionar regra), introduzo um nome com significado, como "Admin SSH internal only" (Admin SSH apenas interno), especifico o protocolo (por exemplo, TCP), a porta (por exemplo, 22 para SSH) e o endereço de origem permitido. Isto garante que o acesso só é permitido através de IPs especificados.
Repito este processo para outros serviços sensíveis, como o acesso remoto a bases de dados ou pontos finais de API especiais. Essas regras adicionais reduzem enormemente a superfície de ataque potencial. Se eu operar muitas VMs ou quiser proteger vários subdomínios, regras segmentadas por site fazem sentido. A firewall permite-me atribuir regras específicas a clientes ou projectos individuais, de modo a ter uma separação lógica clara entre diferentes ambientes de alojamento.
Especialmente com uma estrutura complexa com vários serviços, é útil organizar as regras da firewall. Dou-lhes nomes com significado e numero-as, se necessário, para manter uma visão geral. Uma boa documentação de todas as regras é essencial, pois só assim posso verificar rapidamente porque é que um serviço é bloqueado ou permitido em caso de dúvida. Também registo todas as alterações de regras: em caso de problemas, posso facilmente descobrir se a causa é uma regra nova ou alterada.
Gestão avançada da firewall: monitorização e filtragem proactivas
Outra forma de aumentar a segurança é monitorizar proactivamente o tráfego. Faço-o verificando os registos do servidor em intervalos regulares. Os alertas que indicam rastreios de portas ou pedidos suspeitos, por exemplo, mostram quais os padrões de ataque que estão atualmente a ocorrer repetidamente. Muitas vezes, os bots podem tentar aceder a uma determinada porta ou URL centenas de vezes em poucos segundos. A firewall do Plesk, em conjunto com o ModSecurity, ajuda-me a reconhecer automaticamente e a evitar esses ataques.
Não só configurando a firewall estaticamente, mas também monitorizando-a ativamente, posso reconhecer tendências ou novas técnicas de ataque numa fase inicial. Por exemplo, pode ser útil bloquear permanentemente blocos de IP recorrentes que apenas enviam tráfego malicioso. Para o fazer, crio uma lista de IPs ou intervalos de IPs suspeitos para poupar trabalho, uma vez que um ataque que foi bloqueado com êxito uma vez é frequentemente tentado novamente a partir do mesmo intervalo de IPs.
Por vezes, também é aconselhável utilizar uma funcionalidade de limite de taxa. Embora o Plesk não tenha uma solução integrada para limites de taxa de pedidos, em combinação com outras ferramentas ou regras especiais de ModSecurity, posso impedir que determinados endereços IP enviem demasiados pedidos num curto período de tempo. Estas medidas são um complemento eficaz às regras clássicas de firewall e ajudam a minimizar as abordagens de negação de serviço distribuído (DDoS).
Configurar o ModSecurity: Configurar corretamente a firewall de aplicação web
Abro o item de menu "Web Application Firewall (ModSecurity)" no Plesk. Aqui selecciono primeiro o conjunto de regras - o OWASP Core Rule Set é gratuito e cobre de forma fiável as ameaças comuns. No "modo dedicado", posso personalizar as regras que estão activas. Presto especial atenção às regras contra a injeção de SQL e o cross-site scripting.
Defino o modo para Forçar (enforcing) para que não seja apenas registado, mas ativamente bloqueado. O ModSecurity WAF reage imediatamente a padrões de ataque típicos, tais como pedidos manipulados, comprimentos de parâmetros invulgares ou caracteres especiais suspeitos. Mais informações sobre a configuração ideal do Plesk podem ser encontradas neste Instruções de firewall para Plesk.
Se pretender uma configuração ainda mais personalizada, pode também começar com o chamado "modo de simulação" (apenas deteção) e observar primeiro quais os pedidos que são reconhecidos como suspeitos pelas regras. Após uma determinada fase de teste, coloco o sistema num "modo de aplicação" rigoroso. Isto reduz os erros de configuração e a funcionalidade da sua própria aplicação Web é sempre mantida em vista. Porque, por vezes, pode acontecer que aplicações ou plugins legítimos utilizem padrões que se assemelham a uma regra WAF, o que leva a falsos alarmes. Com a etapa intermédia em modo de simulação, reconheço esses casos atempadamente.
Reconhecer e prevenir a injeção de SQL
A injeção de SQL é uma das vulnerabilidades de segurança mais perigosas nas aplicações Web modernas. Os atacantes utilizam campos de formulários preparados ou parâmetros de URL para tentar obter acesso direto ao conteúdo da base de dados. A firewall da Web reconhece comandos típicos como "SELECT * FROM" ou "UNION ALL" e bloqueia o pedido a nível da aplicação.
Aqui, o Plesk oferece uma proteção independente graças ao WAF ativado em combinação com actualizações integradas regularmente. Verifico regularmente se todas as regras ModSecurity estão activadas e actualizadas. As regras que verificam as interações da base de dados com parâmetros POST/GET são particularmente importantes. As políticas aplicáveis, como a lista branca de consultas SQL, reduzem ainda mais o risco.
Uma boa visão geral de como as vulnerabilidades de segurança do Plesk são resolvidas pode ser encontrada no artigo Lacunas de segurança do Plesk resolvidas. Aprendi que mesmo a firewall mais segura só é eficaz se as próprias aplicações Web forem programadas de forma fiável. Os backdoors ou os plugins inseguros podem ser dificultados, mas não podem ser totalmente compensados se existirem vulnerabilidades graves no código.
Defesa eficaz contra ataques XSS
O XSS (cross-site scripting) não só danifica o sítio Web, como também expõe diretamente os utilizadores. Os formulários, os campos de comentários ou as máscaras de entrada de perfil são afectados com particular frequência. O Firewall do Plesk reconhece combinações de caracteres perigosas como "" ou chamadas GET orientadas para eventos graças ao ModSecurity. Também adiciono as minhas próprias regras se determinados campos de entrada forem particularmente sensíveis.
Certifico-me de que as validações do lado do servidor têm efeito em todas as entradas - as medidas do lado do cliente não são suficientes. O WAF pode ser modificado de modo a que os valores dos parâmetros ou os métodos inesperados sejam explicitamente proibidos. As análises de segurança externas regulares ajudam a revelar vulnerabilidades anteriormente não detectadas.
Especialmente em aplicações Web extensas, como as que têm funções de comunidade, o XSS pode ser facilmente introduzido através de funções de comentário. É por isso que utilizo uma combinação de escapes do lado do servidor, filtragem de caracteres potencialmente perigosos e uma restrição às etiquetas HTML permitidas (se necessário). Um exemplo é a restrição dos comentários dos utilizadores a texto simples, de modo a que não seja permitido HTML ou JavaScript. Uma regra WAF também pode bloquear essas injecções.
Camadas adicionais de proteção: Reforço de URL e palavras-passe seguras
Para aumentar ainda mais a proteção, vale a pena dar uma vista de olhos a métodos de reforço adicionais. O endurecimento de URL significa, por exemplo, que determinados caminhos de administração ou páginas de início de sessão só são acessíveis através de intervalos de IP definidos. Isto torna mais difícil para os atacantes lançarem ataques de força bruta ou adivinharem logins aleatórios. Por exemplo, posso mover a área de administrador da minha aplicação Web para um subdomínio separado e partilhá-lo apenas com o IP do meu próprio escritório.
Outro ponto crítico são as palavras-passe. Mesmo a melhor firewall é de pouca utilidade se forem utilizadas palavras-passe triviais na página de início de sessão. Por isso, configuro requisitos rigorosos de força da palavra-passe no Plesk e utilizo a autenticação de dois factores (2FA) sempre que possível. Isto evita ataques automatizados que tentam regularmente milhões de combinações de palavras-passe de utilizadores. Uma política de palavras-passe sólida complementa assim as regras da firewall e oferece uma linha de proteção adicional.
Medidas de segurança para uma proteção a longo prazo
Abro apenas as portas essenciais, documento corretamente todas as alterações à firewall e utilizo a autenticação de dois factores para iniciar sessão no painel Plesk. Também guardo um Cópia de segurança completapara voltar a estar online rapidamente em caso de emergência. Através da análise constante dos registos, reconheço padrões de acesso invulgares, como pedidos repetidos a áreas administrativas ou endereços IP suspeitos.
Resumi as melhores práticas mais importantes neste quadro:
| Recomendação | Descrição |
|---|---|
| Minimização dos portos | Deixar apenas as portas necessárias abertas (por exemplo, 443, 22) |
| Início de sessão de dois factores | Proteção de início de sessão com a aplicação Authenticator |
| Actualizações e patches | Actualizações de segurança instaladas regularmente |
| Monitorização | Monitorizar os ficheiros de registo e o comportamento do tráfego |
| Estratégia de cópia de segurança | Cópias de segurança completas e regulares dos dados |
Muitos destes pontos deveriam ser obrigatórios para que um sítio Web funcione de forma estável a longo prazo. As actualizações e correcções, em particular, são muitas vezes negligenciadas, apesar de poderem colmatar vulnerabilidades críticas em sistemas populares de gestão de conteúdos (CMS). Uma firewall pode reconhecer padrões de ataque, mas se um componente não corrigido permitir um acesso fácil, a proteção global fica em risco. Por isso, recomendo que se verifique mensalmente ou até com mais frequência se existem actualizações de segurança importantes para o sistema operativo, o próprio Plesk ou os plugins instalados.
Minimizar os erros e evitar falhas
Testo a eficácia de cada nova regra antes de a aplicar de forma produtiva. Um conjunto de regras que seja inadvertidamente demasiado restritivo pode bloquear-me. Se isso acontecer, uso o "modo de pânico" para bloquear todo o acesso externo - apenas o acesso físico via KVM ou VNC permanece possível.
E se nada funcionar, reinicio a firewall para "Default" através do backend do Plesk - isto permite-me retificar quaisquer definições incorrectas graves. Os fornecedores de alojamento, em particular, oferecem frequentemente uma consola web para ligações de emergência - isto também ajuda em momentos críticos.
Para reduzir ainda mais as fontes de erro, é aconselhável utilizar um ambiente de teste antes de aplicar finalmente uma regra. Aí posso verificar se a minha aplicação Web funciona normalmente enquanto a firewall já está a bloquear todos os potenciais ataques. Após o teste bem sucedido, transfiro a configuração para o ambiente real. Desta forma, evito tempos de inatividade e aborrecimentos com os utilizadores ou clientes que reagem com sensibilidade a qualquer interrupção.
Otimizar a firewall Plesk para alojamento único e múltiplo
Quer se trate de um sítio Web ou de muitos, eu personalizo as definições da firewall separadamente para cada estrutura de alojamento. As regras rigorosas são particularmente importantes para o alojamento partilhado com várias contas de utilizador. Segmento subsistemas, defino o acesso a interfaces de administração como o phpMyAdmin para IPs específicos e isolo efetivamente os domínios uns dos outros.
A inclusão de mecanismos de proteção de última geração, como o Cloudflare, ao nível do DNS ou do CDN oferece uma proteção adicional. Como Integrar o Cloudflare com o Plesk é mostrada no artigo ligado.
Especialmente num ambiente de vários alojamentos, pode acontecer que um domínio seja vulnerável e coloque uma pressão sobre todo o sistema devido a ataques regulares. Neste caso, é útil introduzir regras de segurança mais rigorosas para o domínio em questão, ativar módulos WAF adicionais ou configurar o seu próprio bloqueio de IP. Como resultado, o desempenho de outros domínios não é afetado em grande medida e não tenho de tomar contramedidas elaboradas para todos os clientes.
Análise de protocolos a longo prazo e resposta a incidentes
Para além de uma proteção rigorosa em caso de ataques, a documentação completa desempenha um papel cada vez mais importante. Recomendo não só a consulta esporádica dos ficheiros de registo, mas também a utilização de soluções profissionais de monitorização ou de ferramentas de análise. Isto dá-me uma visão geral de quando e com que frequência determinados ataques foram tentados e permite-me compilar estatísticas fiáveis para me ajudar a tomar decisões.
No caso de um incidente, como quando um domínio foi comprometido, analiso os registos para reconstruir o vetor de ataque com a maior precisão possível. Isto permite-me ver que regra teve efeito ou porque falhou. Com base nestas informações, adapto o conjunto de regras e minimizo assim o risco de repetição de um ataque idêntico. Este é um processo contínuo: à medida que a situação de ameaça muda, ajusto as definições da firewall e do WAF numa base contínua.
Um complemento útil é um servidor syslog central para o qual são comunicados todos os eventos relevantes. Se houver padrões evidentes, envio automaticamente avisos por correio eletrónico ou sistema de mensagens. Desta forma, posso manter uma visão geral e reagir prontamente sem ter de verificar manualmente os registos quando ocorrem problemas.
Maior segurança para pontos de ataque comuns
Certos serviços como o correio eletrónico (SMTP, IMAP), FTP ou SSH são pontos de entrada clássicos para ataques automatizados. É por isso que me concentro particularmente nestas portas e regulo o mais estritamente possível os intervalos de IP de onde os pedidos podem vir. No caso do SSH, considero útil alterar a porta 22 predefinida e defini-la para uma porta diferente. Embora isto, por si só, não aumente a segurança do núcleo, muitos ataques automáticos visam explicitamente a porta 22 e são, portanto, frustrados numa fase inicial.
Se o serviço do servidor, por exemplo o FTP, já não estiver atualizado devido aos requisitos de encriptação, seria melhor utilizar o SFTP. Assim, posso fechar completamente a porta antiga. Isto mantém os pontos de ataque a um mínimo e reduz o risco de compromisso. A firewall Plesk permite-me reconhecer facilmente qual é a porta ativa e quais as medidas que entram em vigor assim que chega um pedido suspeito.
Configuração segura com firewall Plesk e configuração direcionada
Com o firewall de aplicação web Com o Plesk e a manutenção consistente das regras, posso proteger de forma fiável os meus sítios Web de ataques como a injeção de SQL ou o cross-site scripting. A combinação de proteção básica por firewall, personalização ModSecurity e as últimas actualizações de segurança fazem do Plesk uma ferramenta segura para o alojamento diário.
Para mim, é importante verificar o sistema regularmente, adicionar regras e documentar as entradas da firewall. Isto garante que o efeito protetor se mantém a longo prazo - independentemente de se tratar de um pequeno blogue ou de uma plataforma comercial movimentada. Com uma abordagem estruturada, um ajuste fino sensato e sistemas de monitorização orientados para o futuro, posso aumentar a segurança a longo prazo e evitar incidentes desagradáveis. Em última análise, é necessária uma abordagem holística que mantenha um olho tanto na tecnologia como na organização - Plesk fornece a base correta para isso.
