Tarefas Administrativas no BIG-IP — O Backup Pegadinha

Álcool gel… Syn, syn-ack, ack!!!

Fala pessoal!! Depois de alguns meses sumido estou de volta aqui no TechRebels! Você pode encontrar todos os meus posts publicados neste link. Recomendo que sejam lidos na ordem, caso você tenha chegado agora.

E como sempre, fiquem ligados no TechRebels e sigam-me no Medium clicando follow lá em cima para acompanhar os próximos posts.

Nossa… Como eu estava com saudades das nossas conversas! Sério! Para quem não sabe, o motivo do meu sumiço foi um misto de férias e troca de emprego com mudança de estado. Isso mesmo. Deixei a empresa que trabalhava há quase 9 anos e me mudei de SP para DF para um novo desafio. Então, minhas humildes desculpas pelo desaparecimento repentino, mas foi necessário.

Mas ano novo, vamos em frente. Espero que todos estejam bem, assim como seus familiares e amigos. Estamos — potencialmente — na reta final dessa loucura toda.

Sem mais delongas, hoje o assunto é backup no BIG-IP. Parece besta, mas vem comigo. E talvez você precise de um desfibrilador ao final desse artigo. =O

Você tem o costume de fazer backup antes das infindáveis mudanças que faz no seu BIG-IP? Tem? Que bom! Mas você já precisou restaurar um backup em uma situação de RMA por exemplo? Nunca? Que bom… Mas olha que doideira isso.

Desde a versão 11.5 a F5 fez uma alteração no funcionamento interno do TMOS para proteger a configuração do BIG-IP. Basicamente, tudo que é considerado informação sensível é criptografado no arquivo de configuração para não ficar em clear-text. Até aí parece inofensivo.

Mas, o que a maioria das pessoas não sabe é que a F5 determinou que essas informações sensíveis são protegidas com um negócio chamado “master-key”. A master-key é gerada em tempo de primeiro boot e nada mais é que uma senha aleatória. A questão toda é que você, administrador do BIG-IP, não sabe qual é essa senha. E ela é usada para cifrar todas essas informações sensíveis da sua configuração. Essas informações sensíveis podem ser a senha do TACACs que você usa para autenticar o BIG-IP ou até mesmo a senha de um monitor LDAP.

Mas você deve estar se perguntando o quão perigoso isso pode ser. Eu tenho um backup, oras…

Então… O pior caso é para quem não tem um cluster, ou seja, se o seu BIG-IP é standalone. Se um dia o seu equipamento explodir, mesmo com um backup UCS, você terá dificuldades de restaurar no RMA.

Em nosso lab, estamos utilizando dois BIG-IPs em modo standalone na v15.1.2. Então, o cenário é o seguinte: temos um backup UCS que foi tirado na noite anterior. Na madrugada o BIG-IP explodiu. O NOC foi correndo no estoque da empresa e pegou a unidade de spare, rackeou, cabeou, energizou, ligou e foi executar a rotina de restore do UCS — rotina esta, validada em produção inúmeras vezes — e se depararam com a imagem abaixo:

E agora? Não só o processo de restore falhou com uma mensagem de erro como também, para ajudar, na GUI, fica essa mensagem ainda mais simpática na tela:

E pra completar o infarto do coitado que tentou restaurar o backup, o que ele percebe é que parte da configuração subiu (hostname, self-ips e algumas coisinhas a mais) mas como podemos ver, o virtual-server e demais objetos do LTM não, ou seja, estamos no pior cenário possível, pois não sabemos exatamente o que restaurou e o que exatamente não foi. Só sabemos de uma coisa: peguem o desfibrilador, porque o nosso amigo tá precisando! =O

Mas Rafael, o que diabos está acontecendo nesse cenário catastrófico?

Como falamos mais acima, durante o processo de restore, o BIG-IP precisa ler o conteúdo do arquivo de backup para restaurá-lo no equipamento. Acontece que o BIG-IP original (o que explodiu) tinha um informação de master-key e o novo (o RMA) tem outra. E quando o novo tentou ler as informações protegidas com a master-key dele, não conseguiu. E daí ele não consegue terminar de restaurar o backup e aborta a operação. E fica nesse estado de “no limbo”.

Beleza. Entendido. E como resolve?

Peguem o desfibrilador novamente…

Se você não tiver a master-key original (aquela que você nunca configurou que estava na caixa que explodiu) você terá que reconfigurar praticamente tudo, manualmente. Espero que a sua documentação esteja em dia e que a sua configuração seja pequena…

Mas então o meu backup não serve de nada e o BIG-IP é uma porcaria?

Calma lá, amigo. É necessário apenas fazer da forma correta e documentar a master-key, pois é possível alterar essa master-key para qualquer string que você quiser e isso nunca será um problema. Inclusive essa é a minha recomendação para você: torne a alteração da master-key dos seus dispositivos algo padrão no seu processo de deploy e documente-a. É um passo simples (1 comando) e não é disruptivo para o tráfego de produção. Assim:

Com o comando “modify sys crypto master-key prompt-for-password” você altera a master-key para a string que você digitar. Obviamente, cuidado ao digitar, principalmente com layout de teclados com problema. Na sequência, com o “show sys crypto master-key” é possível verificar que no novo master-key hash é diferente do previous hash.

E nesse exemplo, não basta documentar o master-key hash, é preciso saber o que se digitou, pois o que é mostrado na tela é hasheado.

Muito importante: ao alterar a master-key, todos os backups antigos (antes dessa alteração) serão perdidos pelo mesmo motivo: master-key diferentes. Então, logo após essa alteração, faça um novo backup do seu sistema!

Então, de posse dessa string de master-key, o processo de restauração seria o seguinte:

1. Ligar o equipamento de RMA
2. Alterar a master-key do equipamento novo para ter a mesma string do antigo, utilizando o comando “modify sys crypto master-key prompt-for-password”
3. Restaurar o backup UCS do equipamento antigo no novo

Vamos ao vídeo com a demonstração do problema acontecendo e, também, com o backup sendo restaurado após a correta configuração da master-key.

Em resumo, o processo de backup do BIG-IP funciona. Mas, devido a questões de segurança, é preciso ter muito cuidado com a forma que se faz esse backup. Muitos profissionais não sabem desse detalhe pois nunca precisaram passar por um processo de RMA e, portanto, nunca precisaram saber desse detalhe e descobriram da pior forma. Vale ressaltar que essa questão da master-key afeta qualquer BIG-IP, independente da plataforma (viprion, appliance ou virtual-edition). Então, altere a sua master-key e torne isso um processo normal do seu staging. Documente-a e aposente o desfibrilador! =D

Referência: https://support.f5.com/csp/article/K9420

Começamos 2021 com um “susto”, né? Mas tudo tem solução! Esse foi o primeiro artigo de uma série sobre tarefas administrativas no BIG-IP. Fique ligado aqui no TechRebels para os próximos.

Ficou com alguma dúvida? Pode perguntar! Os comentários e perguntas ajudam a direcionar os próximos artigos! Não deixe de seguir o TechRebels e a mim aqui no Medium clicando no “follow” ali embaixo e também no Twitter!

/FIN=1

Sobre o autor

Rafael Bianco Nacif é analista de redes sênior. Graduado em Redes de Computadores, certificado 2xF5 Solutions Expert (Cloud/Sec), Cisco CCNP DC e RS e também AWS CSA. Iniciou a carreira na área de TI como help-desk e hoje atua em projetos de DC de alta complexidade. linkedin.com/in/rafaelbn