[FUG-BR] Proteção

[Guilherme M. O.]

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 <eksffa em freebsdbrasil.com.br> 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
> 316601 em sip.freebsdbrasil.com.br
> 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.