A precaução é não só com o cara mudar algo na configuração ou coisa do tipo, mas também acessar dados da própria empresa que são mantidos pela ferramenta case. (login da própria ferramenta, valores e informações da empresa que seguem certa classificação).
A questão do live CD não me preocupa, a idéia é que o servidor teria uma entrada usb e só, nada de drives de cds ou disquetes. Hoje em dia existe "live-usb", mas para isso basta desabilitar o boot por usb na bios. Se precisasse de manutenção, seria levado um servidor "temporário" pré configurado, e então o servidor seria trazido para a minha área que cuidaria da manutenção. A ferramenta está concentrada em apenas uma pasta, o custo de processamento que a criptografia vai gerar justifica encriptar o disco todo nesse caso? quero dizer, vale a pena abrir mão de um pouco de processamento para encriptar todo o disco se a aplicação está concentrada apenas nessa pasta? (ainda nao sei como a aplicação se comporta, não sei quanto consome nem nada) A idéia inicial era não criar nenhum usuário para manutenção, porém você me deu uma idéia que parece segura, é capaz de eu usar ela e restringir um pouco a conta de manutenção usando o sudo. É possível eu restringir login usando certificado digital? assim o cara só ia conseguir logar se: 1) tivesse a senha da conta desprivilegiada 2) tivesse a senha do root 3) tivesse um token com um certificado digital emitido pelo meu servidor Valeu On 1/10/07, Patrick Tracanelli <[EMAIL PROTECTED]> wrote: > A precaucao sobre o acesso fisico (ou o "medo") envolve apenas operacoes > multiusuario no ambiente de producao ou a questao e' "copia" indevida > dos dados no servidor? Porque se for a segunda, todas as solucoes > eventualmente indicadas sao anuladas por um simples boot com um disco > Live ou com o HD sendo secundario de um outro FreeBSD. Se o receio o > segundo caso, voce soh tem um caminho: criptografar todo o disco. > Inclusive a raiz. Nesse caso use gbde(8) ou geli(8) (options GEON_ELI). > Veja em www.fug.com.br como usa-los. Eu indico a segunda forma (geli). > > Do contrario basta combinar chflags, securelevel e colocar todos os > terminais em modo insecure no /etc/ttys, isso exigira saber 1) a senha > de um usuario desprivilegiado, 2) a senha de root e 3) que o usuario > desprivilegiado seja parte do mesmo grupo do root para ter privilegios > no servidor. > > Uma pergunta. Alguem vai ter algum acesso? Pra manutencao por exemplo? > Se sim, coloque o /usr/bin/su como shell desse usuario, e coloque > nologin como shell de qualquer outro usuario. > > Porque /usr/bin/su como shell? A ideia eh garantir que se alguem for se > logar, sera pra manutencao, e pra isso devera saber ambas as senhas, a > do usuario desprivilegiado e a do proprio root (ja que o root nao se > logara diretamente apos a configuracao insecure do /etc/ttys). Senao, o > usuario se loga sem saber a senha do root, apenas sabendo a do > desprivilegado e pode ficar brincando de tour no sistema, dando mkdir no > /tmp ate acabar os inodes hehe, que eh o que voce nao quer. A ideia eh > facilmente adaptavel ao sudo caso queria restringir o alcance da > manutencao (nao sei se eh o seu caso). > > S/Key tambem pode ser de seu interesse: > > http://doc.fug.com.br/doc/pt_BR.ISO8859-1/books/handbook/one-time-passwords.html > > "man security" dara mais dicas sobre ttys, securelevel e chflags, entre > outros. > > -- > Patrick Tracanelli > > FreeBSD Brasil LTDA. > (31) 3281-9633 / 3281-3547 > [EMAIL PROTECTED] > http://www.freebsdbrasil.com.br > "Long live Hanin Elias, Kim Deal!" > > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- Guilherme M. O. ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
