Linux Tatu-bola

[mmachado]

Prezados,

Estava imaginando um cenário onde nós instalamos um sistema qualquer (servidor web, de arquivos, firewall, qualquer coisa) em um box Linux para um cliente e, como parte desse serviço, está a manutenção, atualização e suporte desse sistema.

Só que, imaginem que nesse cliente existe um "sobrinho" metido a sabidão que toda hora acessa a máquina e tenta instalar outros serviços ou mudar configurações, o que traz tudo abaixo e dá o maior trabalhão para o suporte.

Então pensei em como fazer (tecnicamente) para dificultar ao máximo a adulteração do sistema, levando em consideração que o hardware está em poder do cliente. Estes foram os passos e comecei a pensar e gostaria da ajuda de vocês:

Eliminar qualquer possibilidade do cliente ter senha para logar na máquina

Essa é fácil de fazer e também fácil de desfazer. Basta o garoto dar um boot em modo single e trocar a senha de root. O problema não é identificar que o sistema foi alterado, mas sim impedir que isso seja feito.

Cadastrar uma senha no GRUB para impedir que ele passe parâmetros de boot que permitam trocar a senha de root.

Essa também é fácil. Mas ele vai poder dar um boot por um LiveCD, por exemplo, montar o HD e alterar o sistema tirando a senha do GRUB ou alterando o passwd de uma vez.

Cadastrar senha na BIOS para impedir que ele dê boot pelo CD

Ok. Também é fácil de resolver tirando a bateria da placa-mãe ou, melhor ainda, levando o HD para outra máquina e repetir o processo anterior.

Usar um filesystem encriptado

Se nós encriptarmos o filesystem ele não pode ser montado em outro computador, já que o processo de decriptação ocorre no processo de boot. Pensei no TrueCrypt para essa tarefa. O problema é que sempre que precisarmos dar um boot na máquina alguém vai ter que digitar a senha durante o booloader.

Obviamente não é possível usar uma feature de "salvar senha" para esse caso, já que uma senha grava no HD estaria sujeita a violação.

Desse ponto em diante não consegui pensar em nada realmente útil (fora algumas viagens de hardware específico) que pudesse ser aplicado de forma relativamente simples e barata.

Alguma sugestão?

[]s, MM

[luiz.tomaz]

Além de tudo que o MM já disse, eu moveria alguns binários básicos (ls, cd, vi, etc) para um filesystem “oculto” em um arquivo, quando eu precisasse dar manutenção na maquina, montaria o arquivo e redefiniria a PATH.

Desabilita as sessões locais (F1-F6) e habilita uma 13º (Acessada teoricamente por um F13), ai você pode acessar com ALT + setas.

Outra saída é quebrar os dedos do cara.

[J.Augusto]

Oi oi MM :)

Me lembrei de uma outra discurssão que tivemos aqui, sobre Lan Houses, em que uma das opções, seria a instalação de um Hardware num dos Slots PCI da Mobo, em que o "sistema" fica com as suas configurações gravadas e a cada Boot retorna ao seu estado de "origem" ... Mas não tinha sido portado para o Linux ainda.

Acho que vc explanou bem todo o problema de maneira geral e suscinta, de forma que a criptografia do file system parece uma boa opção.

Bom, vi em um site de minha cidade, um hardware de biometria que poderia se possível, ser colocado como senha do Boot do Grub por identificação das digitais, assim o pirralho metido não teria acesso, já que o "dedo que dá acesso" não é o dele certo?

Sinceramente, só não sei como portaria esta para o Boot no Linux, será que tem alguma coisa pela rede a respeito?

http://www.notebooknews.com.br/2008/...lhe.php?id=195

[Birkoff]

Estava imaginando um cenário onde nós instalamos um sistema qualquer (servidor web, de arquivos, firewall, qualquer coisa) em um box Linux para um cliente e, como parte desse serviço, está a manutenção, atualização e suporte desse sistema.

(...)

Então pensei em como fazer (tecnicamente) para dificultar ao máximo a adulteração do sistema, levando em consideração que o hardware está em poder do cliente. (...)

(...)Outra saída é quebrar os dedos do cara.

Eu considero isso um dos problemas que se resolve por contrato. Concordamos que é fácil diagnosticar uma mudança na senha do root via uso de boot em single mode, correto? Ou até mesmo detectar um boot em single mode. Então coloca-se em contrato que a modificação do sistema pelo cliente acarreta numa multa, ou qualquer coisa que seja boa o suficiente pro cara "quebrar os dedos" do sobrinho antes de o moleque pensar em tentar algo.

A cifragem teria o mesmo problema. Se o sobrinho tem acesso ao box, também convence o "tio" a dar pra ele a senha pra "resolver o problema". E deixar a senha só no controle da fornecedora do serviço, complica a questão do boot, como foi colocado.

No final, acaba aumentando sempre o custo e risco da solução, que devia ser simples: contratou nosso serviço, então use ele.

Mas isso me lembra o caso de um conhecido meu, que comprou um Renault daqueles mais "caros", que não lembro o modelo agora. Estava viajando e estorou o pneu. Bom, ele tem assistência completa, é só ligar que os caras vem correndo onde você está e trocam o pneu. Acontece que estava sem celular, e aí não teve jeito, teve que meter a "mão na massa". Mas quando ia tirar o pneu, viu que tinha um dos parafusos diferente: ele tem um formato que só a assistência Renault tem a chave pra abrir. Ele teve que esperar alguém passar, acabou pegando um ônibus escolar cheio de crianças berrando e provocando que ele era um "monstro", um "bandido" e sei lá o que mais pra ir até onde pegava celular e chamar a assistência, e perdeu o dia nisso. Ele exigiu, depois dessa, que trocassem o parafuso para um normal. Quando pode, ele vai chamar sim a assistência. Mas quer ter a opção!

Imagino a primeira vez que o serviço vital deles cair por qualquer besteira, e tiver que chamar a assistência pra ligar a máquina de novo, e vocês demorarem mais que 10 minutos... Vão querer uma cópia da chave, uma cópia do token, e toda a camada extra de segurança vai ser inutil.

[brunosolar]

Alem do mais amenizaria com a seguinte solucao. Cadeadozinho no servidor sem que somente a empresa de suporte tem a chave impedindo que se abra a maquina pra resetar a bios. Remover drives de cd-rom, disquete, usb etc para que nao seja usado boot via lives. desabilitar o login via single user. E nao passar a senha de root pra ninguem que nao seja do suporte. Ou caso precise fazer isso, especificar no contrato que alteracoes no sistemas que possam danificar sua estrutura acarretara em multa ou algum outro tipo de punicao.

Mas como disse.... Isso deve somente amenizar pois quando querem fuçar sempre acharao uma brechinha.

[mmachado]

O cadeado no gabinete é uma boa idéia, daquelas que me dão raiva por não ter lembrado logo de cara e ter enviado no post original. Dããã! Obrigado! :)

Birkoff, adorei a história da toca de pneu! Mas fiquei imaginando como essa história soaria se o problema fosse na reprogramação da injeção eletrônica do carro, o que seria alguma coisa mais próxima do meu cenário do que trocar um pneu. Comparando com o sistema em questão, trocar pneu equivaleria a substituir uma placa de rede, o que não seria um problema para mim.

Se a assistência dissesse para ele: olha, o senhor pode economizar um dia de viagem e tentar reprogramar o computador de bordo do carro, mas é provável que não consiga e, depois disso, o senhor perderá a garantia do veículo. Se quiser testar, a senha é xyz... Imagina o que seu amigo faria? Eu acho que ele iria pegar o tal ônibus escolar.

Já considerei a questão contratual. Mas minha curiosidade é a solução técnica. Eu não tenho, na verdade, esse problema nas mãos, só estou imaginando o dia em que terei. :)

[]s, MM

[brunosolar]

Já considerei a questão contratual. Mas minha curiosidade é a solução técnica. Eu não tenho, na verdade, esse problema nas mãos, só estou imaginando o dia em que terei. :)
[]s, MM

The day after tomorrow!

[ALIG_wicked]

A seguranca fisica eh vital .. pra ter uma ideia, quando se instala uma PKI, o computador que gera a chave mestra, nunca fica on-line e soh eh ligado para essa funcao. Depois disso eh desligado e colocado dentro de um cofre de banco.

Mais voltando ao hardening de linux.

Achei esse documento aqui:
http://www.brucert.org.bn/Guidelines...nes%20v104.pdf

Nunca usei... por isso eh apenas um chute. Usar o dm-crypt e encriptar apenas o que eh vital.

PS-> Poderia fazer uns testes mais to busy com o lance da OTP... :)

[s]
A.A.

[pinduca]

Opa...

Pois eh, no Banco que sou residente da Empresa que eu trabalho, o gerador de chave PKI fica em uma sala com acesso super restrito e não fica soh nisso...

Mais me atendo a solução em que você está propondo MM, eu entendo de duas formas, a contratual e a Técnica do cotidiano.

Você pode barrar contratualmente, mais isso não quer dizer que não irá acontecer.

Ou você pode usar alguma Técnica ( que entendo que seria a solução que vc alcançar ) que impeça que seja feita algum tipo de alteração.

Lendo isso me lembrei de um tipo de Storage que trabalho que na minha opinião tem um sistema bem eficaz contra "abelhudos". A Máquina trabalha dessa forma:
Quando vc precisa se conectar na máquina, vc usa um logon típico, tipo user: root e password: r00t, então a Máquina gera uma segunda senha pra vc (por exemplo:*&hdygeb3241*7d).... ai vc como administrador pega esta senha e na sua Máquina (local ou remota) a coloca num "conversor de senha" que nada mais é um algoritmo que identificará essa senha num arquivo ou em uma base de dados, e a transformará numa senha válida (por exemplo: 1admin08). No caso desta Máquina em específico, a senha é válida por 24 horas.

Este método é muito usado, e funciona! As vzs quando é preciso o pessoal da Engenharia se conectar em uma Máquina lá do Laboratório (Estados Unidos) até o cliente (em qualquer lugar no mundo, mais no meu caso é no Brasil), eles seguem este processo.

E óbvio, a sua máquina poderia ficar em um rack fechado, com acesso controlado e uma bela filmadora bem virado pra máquina, que sem entrar em muitos detalhes, na semana passada mostrou um cara de cabeamento desligar um Mainframe em um grande Banco aqui no Brasil.

Espero ter ajudado.

[]'s

[mmachado]

As soluções mais elaboradas de segurança física ficam meio fora de questão quando imaginamos que a maioria dos abelhudos estão dando mais trabalho naquelas empresas pequenas e médias onde há, quando muito, uma sala específica para os servidores e nada que se assemelhe a um rack ou qualquer estrutura de segurança física. Até por que redes que possuem esse tipo de estrutura estão mais antenadas com relação aos problemas dos abelhudos. Esses caras dá pra resolver com contrato e cobrança de horas adicionais de suporte.

Mas voltando à questão do controle do sistema, a sugestão de usar uma partição apenas como sendo a encriptada tem um lado bom e um lado ruim: o lado bom é que dá para usar um sistema mais elaborado de verificação da integridade do sistema antes de tentar montar a partição, coisa que não poderia ser feito com uma solução rodando no espaço limitado de um setor de boot, e ainda poderia eliminar a necessidade de se fornecer uma senha para decriptar esses dados.

O lado ruim é que a solução estaria sujeita a uma engenharia reversa justamente na rotina que verifica a integridade e monta a partição. Com as ferramentas em uma partição aberta e suscetíveis à manipulação, seria teoricamente mais simples trocá-las para burlar essa verificação ou monitorá-las para descobrir o processo por trás da montagem. Uma vez de posse dessa senha, adulterar a partição protegida seria possível.

É claro que já estou imaginando o inimaginável. Um ambiente no qual não podemos garantir a integridade física (como o que descrevi no início desse post) muito provavelmente não teria alguém capaz de percorrer toda essa Goonies' Adventure simplesmente para bisbilhotar e tentar bagunçar o sistema.

De qualquer forma, esse exercício foi interessante para que eu conseguisse definir melhor a linha do risco aceitável.

Até mais e obrigado pelos peixes.

[]s, MM