O que fazemos · Operações: Resposta de emergência a vulnerabilidades no mesmo dia
Entre um aviso de segurança crítico e a chegada da correção ao seu servidor, somos nós que fechamos o intervalo. As mitigações entram em horas, os pacotes corrigidos são construídos internamente no mesmo dia em que a correção é publicada, e cada servidor afetado é corrigido no mesmo dia, um host de cada vez, com um caminho de regresso testado.
O que é
- h2: O que é
Um procedimento de emergência praticado, não uma correria improvisada. Cobre todo o percurso, desde a leitura do aviso até à prova, depois, de que ninguém aproveitou a janela. Assenta no nosso próprio mirror de pacotes dentro do nosso datacenter, para que o patching nunca dependa de um mirror público estar a ter um bom dia.
Como o construímos
- h2: Como o construímos
Ler primeiro a nossa própria infraestrutura. Confirmamos que servidores correm o componente afetado e se as aplicações neles usam de facto a funcionalidade vulnerável.
Mitigar primeiro. Enquanto a correção é preparada, entra a mitigação menos disruptiva: uma alteração de configuração, uma funcionalidade desativada, uma regra no edge. As medidas que custam desempenho são levantadas assim que a correção a sério entra. As medidas que não custam nada ficam.
Construir nós próprios, no mesmo dia. Quando o projeto upstream publica o código corrigido, construímos pacotes corrigidos no mesmo dia. Construímos a partir da própria especificação de pacote do maintainer da distribuição, num container limpo, e marcamos a versão de modo que o build do próprio fabricante substitua o nosso automaticamente na atualização normal seguinte. Os pacotes entram no nosso próprio mirror com os seus checksums registados.
Rollout um host de cada vez. Cada servidor recebe uma verificação prévia e uma verificação posterior: os mesmos módulos carregados antes e depois, os mesmos websites a responder, a aplicação a devolver uma resposta saudável. As pools de workers são reiniciadas de forma graciosa, para que um website movimentado veja uma pausa de cerca de um segundo, não uma interrupção.
Automatizar a parte cuidadosa. Para frotas maiores, como plataformas cPanel e Plesk em que a correção vem do fabricante do painel de controlo, um rollout temporizado atualiza um servidor por execução, amostra websites reais nele antes e depois, e pára toda a passagem e chama um engenheiro no momento em que um único website não volta corretamente.
Verificar se a janela foi usada. Depois do rollout, varremos os logs web e de autenticação na janela de divulgação, à procura de tentativas de exploração e de qualquer coisa que tenha resultado.
Do que o protege
-
h2: Do que o protege
-
Uma falha ativamente explorada deixada aberta depois de a correção ter sido publicada.
- Uma correção apressada que estraga todos os websites de um servidor à noite, sem ninguém a ver.
- Um patch por cuja origem ninguém consegue responder.
- Patching parado porque um mirror público está lento ou inacessível.
- Não saber se alguém entrou antes de a correção chegar.
Na prática
- h2: Na prática
Divulgações críticas no runtime, fechadas num dia. Quando uma falha de PHP de severidade máxima recebe a sua correção oficial, as mitigações entram em todas as plataformas geridas antes do meio-dia. O PHP corrigido, construído internamente a partir da própria especificação do maintainer, é publicado no nosso mirror interno poucas horas depois da versão upstream, e os servidores de aplicação de um editor de notícias são corrigidos um a um, cada um com um único reinício gracioso de workers de cerca de um segundo.
A frota de uma agência digital, corrigida antes da meia-noite. Na mesma noite, a frota de vários servidores de uma agência digital foi corrigida de ponta a ponta, incluindo hosts cujos builds corrigidos vieram do fabricante do seu painel de controlo ao fim desse dia e saíram através do rollout automatizado, com paragem automática. Quando o programador principal da agência perguntou, já tarde nessa noite, se os servidores deles estavam cobertos, teve a resposta dentro da hora: todos e cada um deles estavam feitos.
E os logs estavam limpos. Um varrimento da janela de divulgação em todas as plataformas corrigidas encontrou apenas scanning e uma tentativa lenta e distribuída de adivinhar credenciais, tudo negado, e nenhum sinal de comprometimento.
Porquê a EuroVPS
-
h2: Porquê a EuroVPS
-
Patching no mesmo dia em todos os servidores afetados, não «na próxima janela de manutenção».
- Construímos nós próprios pacotes corrigidos de confiança, no mesmo dia em que a correção é publicada.
- Mirror de pacotes próprio no nosso próprio datacenter, acessível só a partir do nosso espaço de endereços.
- Cada rollout tem verificações prévias, verificações posteriores e uma paragem automática.
- Procuramos provas de exploração depois, e dizemos-lhe o que encontrámos.
Perguntas frequentes
- h2: Perguntas frequentes
- Corrigem o meu servidor sem perguntar? Para vulnerabilidades críticas em serviços geridos, corrigimos no mesmo dia e mantemo-lo informado ao longo de todo o processo. Qualquer downtime é acordado consigo primeiro.
- O patching vai deitar abaixo o meu website? Desenhamos os rollouts para evitar isso: reinícios graciosos, um host de cada vez, verificações de saúde antes e depois, e uma paragem automática se algo parecer errado.
- E se a minha aplicação precisar de uma versão antiga? Mitigamos à volta dela, isolamo-la, acordamos consigo um caminho de atualização e documentamos as medidas em vigor.
- Recebo um relatório? Sim. Recebe o que foi afetado, o que fizemos, quando, e o que a revisão dos logs mostrou.
- closing line: Se quer as vulnerabilidades fechadas por pessoas que constroem elas próprias a correção, Fale com um engenheiro.
O seu próximo parceiro de infraestrutura
Vamos analisar a sua infraestrutura.
Diga-nos o que executa hoje e o que precisa de melhorar. Um engenheiro vai analisar o seu pedido e ajudar a planear o passo seguinte.
+357 222 32280
Comecemos pela sua infraestrutura.
Um pouco de contexto ajuda-nos a começar a conversa certa.