Quando acionar o plano de contingência?

Recentemente recebemos um pedido de atendimento emergencial: o servidor de arquivos Linux Samba do cliente fora de São Paulo apresentou um erro de hardware durante reboot por falta de energia.

Repassei as orientações por telefone sobre FSCK, seguindo relato do console do servidor. Após um tempo, ficou óbvio que não era mero problema de shutdown desordenado, mas sim profundos erros de hardware dos discos.

Segundo o cliente, o conteúdo do servidor de arquivos era crítico. Questionei sobre backup, e fui informado que o backup era diário e íntegro. Então sugeri que, dada a criticidade em voltar a ter os arquivos disponíveis, o caminho mais rápido era instalar um novo servidor em algum hardware provisório ou em VMWare.

Seguiu-se um longo silêncio na ligação telefônica, e finalmente meu interlocutor agradeceu a ajuda emergencial e disse que preferiria tentar consertar a situação.

Uma pergunta ficou no ar: será que o plano de contingência do cliente realmente identificou a falha catastrófico de hardware como possível cenário, e daí definiu os limites para o acionamento das medidas de contingência? Ou, colocado de outra forma: o plano está claro quanto a “quem deve acionar a contingência sob quais situações”?

Multlock Interactive Cliq

A Mult-T-Lock é líder mundial em produtos de alta segurança para automóveis, residẽncias, escritórios e empresas. Fundada em 1973 por Avraham Bachri e Moshe Dolev, possui centenas de patentes internacionais de produtos tais como fechaduras e cadeados, sistema de travamento eletromecânico, chaves codificadas por computador, portas blindadas, etc.

A linha de produtos de controle de acesso Interactive Cliq é um capítulo à parte da alta tecnologia criptográfica aplicada às necessidades corporativas do dia a dia. Combina o já-renomado segredo mecânico chave/cilindro codificado por computador, à criptografia digital embutida no conjunto chave/cilindro, possibilitando implementar um sofisticado plano de controle de acesso com auditoria para múltiplos locais físicos.

A operação segue o modelo “challenge-response”. Ao inserir uma chave Cliq no cilindro da fechadura, o cilindro envia um código criptográfico de 128 bits à chave (“challenge”), e esta a reconhece e responde com outro código criptográfico (“response”). Com base nesta resposta, o microprocessador existente no cilindro autoriza ou não o acesso, processo que demora 2 a 3 segundos. Após autorização de acesso, a chave só poderá abrir a fechadura caso tenha o segredo mecânico correto.

Todo este processamento é alimentado pela bateria contida na chave Cliq, o que elimina a necessidade de provisionar energia elétrica para instalação das fechaduras em portas.

O sistema de programação das chaves permite grande flexibilidade para atender a divervos modelos de gerência da segurança patrimonial. Existe o sistema local, instalado em um único PC, onde se administra o plano de controle de acesso e se programam as chaves. Para grandes empresas com múltiplas unidades operacionais, a administração do plano de controle de acesso pode ser feita via sistema Web, e as chaves poderão ser programadas por unidades remotas denominadas Wall-PD, que se comunicam com o sistema Web via Internet.

AWS e Check Point – segurança em “cloud computing”

Uma das principais preocupações das empreas, quando migram suas aplicações para “cloud computing”, é a sua segurança.

Recentemente, Check Point Software anunciou parceria com Amazon Web Services, e passou a oferecer seu firewall e outros produtos de segurança integrados ao ambiente AWS. Empresas que já utilizam produtos de segurança Check Point poderão facilmente interligar sua infra-estrutura existente com “cloud” Amazon utilizando instâncias virtuais Check Point disponíveis, e gerenciá-las de forma unificada.

Veja aqui o link da descrição dos produtos Check Point integrados a AWS.

Ping e TTL

Todos conhecem ping e sabem como usá-lo para testar conectividade entre computadores e outros dispositivos que usam IP. Mas qual a função do parâmetro TTL que o comando ping mostra?

TTL é um acrônimo para “Time to Live”. Numa rede IP, ele é usado para evitar que um pacote de dados (tecnicamente, um datagrama) vague indefinidamente de um ponto a outro na rede, caso ocorra algum problema de rotas. O computador que envia o datagrama define um valor inicial de TTL (para Linux, é 64); cada roteador que encaminha o datagrama subtrai 1 (TTL-1) antes de transmiti-lo. Quando TTL chegar a zero, o datagrama é descartado.

Deparei recentemente com um mistério, ao ativar um novo firewall Linux corporativo. Conexões TCP com Internet estavam “congelando” a cada 2 a 3 minutos, e voltava a funcionar depois de 30 a 40 segundos – aparente indicação clara de perda de datagramas. Isto, obviamente, inutilizava o firewall na prática. Mas o teste com ping, de um outro ponto da Internet ao novo firewall, não indicava nenhuma queda ou perda de dados. Depois de muitas verificações com o provedor (trocar cabos, trocar porta do roteador/switch, setar velocidade mais baixa para interface de rede, ser questionado se o firewall Linux estava corretamente configurado – rsrs), reparei em algo extremamente incomum:

64 bytes from aaa.bbb.ccc.12: icmp_req=237 ttl=52 time=26.6 ms
64 bytes from aaa.bbb.ccc.12: icmp_req=238 ttl=52 time=33.6 ms
64 bytes from aaa.bbb.ccc.12: icmp_req=239 ttl=41 time=27.6 ms
64 bytes from aaa.bbb.ccc.12: icmp_req=240 ttl=41 time=33.5 ms

Coincidentemente, nos instantes de mudança de valor TTL, as conexões TCP do novo firewall congelavam. Ou seja, o endereço IP designado pelo provedor ao novo firewall estava em uso por algum outro dispositivo obscuro na rede! Mistério resolvido (descobriu-se depois que o IP em questão estava em uso por um dispositivo esquecido numa VLAN da rede interna…).

Conclusão: o ping, mesmo sendo uma ferramenta básica de debug, fornece informações de grande valia quando interpretadas da forma correta.