Segurança no Servidor

[helldanger1]

Criar a conta de administrador



Agora que as ACLs já estão definidas, pode-se criar uma conta de administrador. Neste exemplo será chamada de admin com instância admin, ou seja, admin/admin:

# kadmin.local -r MINHAORGANIZACAO.DOMINIO Authenticating as principal root/admin@MINHAORGANIZACAO.DOMINIO \with password. kadmin.local: addprinc admin/admin WARNING: no policy specified for admin/admin@\MINHAORGANIZACAO.DOMINIO; defaulting to no policy Enter password for principal "admin/admin@MINHAORGANIZACAO.DOMINIO": Re-enter password for principal "admin/admin@\MINHAORGANIZACAO.DOMINIO": Principal \"admin/admin@MINHAORGANIZACAO.DOMINIO" created. kadmin.local:


Criar o keytab para a ferramenta de administração
O serviço kadmind se encarrega de oferecer o serviço de administração remota do Kerberos. Este serviço possui uma conta na base de dados, ou seja, um principal, que é inserido automaticamente quando a base é criada. O serviço precisa ter acesso à senha dessa conta para poder executar as tarefas de administração pedidas pelo usuário, e portanto é preciso exportar um keytab. Este é um keytab especial, que fica num local definido do arquivo de configuração kdc.conf. O padrão é /var/kerberos/krb5kdc/kadm5.keytab e é criado da seguinte forma:

# kadmin.local -r MINHAORGANIZACAO.DOMINIO Authenticating as principal root/admin@MINHAORGANIZACAO.DOMINIO \with password. kadmin.local: ktadd -k /var/kerberos/krb5kdc/kadm5.keytab \kadmin/admin@minhaorganizacao.DOMINIO \kadmin/changepw@MINHAORGANIZACAO.DOMINIO Entry for principal kadmin/admin@MINHAORGANIZACAO.DOMINIO with kvno 3,\encryption type Triple DES cbc mode with HMAC/sha1 added to\ keytab WRFILE:/var/kerberos/krb5kdc/kadm5.keytab. Entry for principal kadmin/admin@MINHAORGANIZACAO.DOMINIO with kvno 3,\ encryption type DES cbc mode with CRC-32 added to keytab WRFILE:\ /var/kerberos/krb5kdc/kadm5.keytab. Entry for principal kadmin/changepw@MINHAORGANIZACAO.DOMINIO with kvno 3,\ encryption type Triple DES cbc mode with HMAC/sha1 added to\ keytab WRFILE:/var/kerberos/krb5kdc/kadm5.keytab. Entry for principal kadmin/changepw@MINHAORGANIZACAO.DOMINIO with kvno 3,\ encryption type DES cbc mode with CRC-32 added to keytab WRFILE:\ /var/kerberos/krb5kdc/kadm5.keytab. kadmin.local:


Nota: O script de inicialização do serviço de administração remota (kadmind) automaticamente executa esta operação se este keytab ainda não estiver criado, ou seja, normalmente não é necessário executar o comando acima.

Iniciar os serviços
A configuração básica está completa agora, o restante pode ser feito com o serviço já em execução. Os serviços podem ser iniciados com os comandos:

# service krb5kdc start # service kadmind start


O primeiro comando inicia o KDC, ou seja, o Key Distribution Center. É o que precisa que esteja sendo executado, para que usuários e serviços possam obter seus tickets. O segundo serviço é o de administração remota, que permite que se use remotamente o comando kadmin para acrescentar usuários, removê-los, extrair keytabs, etc.

Estes dois serviços enviam informações sobre seu funcionamento e comportamento para os arquivos /var/log/krb5kdc.log e /var/log/kadmind.log, respectivamente.

Configurando a Replicação
Criando contas
Para que a máquina que será o servidor secundário possa receber os dados do servidor primário, é necessário que ela tenha uma conta na base Kerberos, ou seja, um "principal". Para fazer isso, usa-se a ferramenta de administração kadmin (se for usada localmente, ou seja, no próprio KDC, pode-se usar kadmin.local):

# kadmin.local Authenticating as principal root/admin@MINHAORGANIZACAO.DOMINIO with \password. kadmin.local: addprinc -randkey host/slave.minhaorganizacao.\dominio WARNING: no policy specified for host/slave.minhaorganizacao.\dominio@MINHAORGANIZACAO.DOMINIO; defaulting to no policy Principal "host/slave.minhaorganizacao.dominio@MINHAORGANIZACAO.\DOMINIO" created.


A "conta" que o escravo precisa ter no mestre, ou seja, o "principal", é do tipo host, pois é considerado uma conta de máquina. A instância desse "principal" é o nome completo (FQDN) da máquina que será o escravo (ou secundário) desse KDC.

Extraindo os keytabs
É necessário agora passar essa "senha" que foi criada para a máquina que será o servidor secundário. A forma mais prática de se fazer isso é rodar kadmin remotamente a partir dessa máquina. Se isso não for possível, o arquivo contendo a senha (o keytab) deverá obrigatoriamente ser copiado de forma segura para o servidor secundário, ou seja, nada de FTP ou outro protocolo que não utilize criptografia. Nem que você precise recorrer a disquetes, não use protocolos de rede inseguros.

Para extrair o keytab do servidor e gravá-lo no servidor secundário, execute:

# kadmin -p admin/admin -r MINHAORGANIZACAO.DOMINIO Authenticating as principal admin/admin with password. Enter password: kadmin: ktadd host/slave.minhaorganizacao.dominio Entry for principal host/slave.minhaorganizacao.dominio with kvno 4, \encryption type Triple DES cbc mode with HMAC/sha1 added to keytab \WRFILE:/etc/krb5.keytab. Entry for principal host/slave.minhaorganizacao.dominio with kvno 4,\ encryption type DES cbc mode with CRC-32 added to keytab \WRFILE:/etc/krb5.keytab.


Agora o servidor secundário tem a senha (krb5.keytab) necessária para poder se autenticar frente ao servidor primário e receber as informações do banco de dados.

Acertando permissões de replicação
A replicação é feita da base de dados principal para as secundárias usando o serviço kpropd. É necessário criar um arquivo de ACLs que contenha os principais envolvidos na replicação. Por exemplo, se o KDC primário for kerberos.minhaorganizacao.dominio e o KDC secundário for slave.minhaorganizacao.dominio, o arquivo kpropd.acl no diretório /var/kerberos/krb5kdc/ ficaria assim:

host/kerberos.minhaorganizacao.dominio host/slave.minhaorganizacao.dominio


Agora, o serviço de replicação kpropd pode ser iniciado no servidor secundário:

# service kpropd start


Enviando o banco de dados para os secundários
Com o kpropd, iniciado nos servidores secundários, e o arquivo kpropd.acl. listando os principais necessários, pode-se agora enviar o banco de dados para cada um dos servidores secundários.

Primeiro, é preciso fazer um dump do banco de dados, ou seja, criar uma cópia que será usada para a transmissão. No servidor primário, execute:

# kdb5_util dump /var/kerberos/krb5kdc/slave_datatrans


O próximo passo é transmitir o arquivo gerado para cada um dos escravos:

# kprop -f /var/kerberos/krb5kdc/slave_datatrans \slave.minhaorganizacao.dominio Database propagation to slave.minhaorganizacao.dominio: SUCCEEDED


Finalizando
Por fim, basta iniciar o KDC nos servidores secundários. É necessário regerar o arquivo stash, caso contrário os serviços não conseguirão acessar o banco de dados que acabou de ser transferido. Para isso, use kdb_util em cada um dos servidores secundários:

# kdb5_util stashkdb5_util: Cannot find/read stored master key while reading master key kdb5_util: Warning: proceeding without master key Enter KDC database master key:


Agora o serviço KDC pode ser iniciado nos servidores secundários:

# service krb5kdc start

 

[helldanger1]

Notas



[1] Somente se este diretório estiver sem a opção noexec.

[2] Seguindo a tradição, o usuário root e seus processos não possuem limites.

[3] Esta variável pode ser declarada como somente leitura pelo administrador do sistema, impedindo que os usuários possam alterar seu valor.

[4] Programa que gerencia serviço(s), sempre executado em segundo plano. Geralmente iniciado através de um script.

[5] Será utilizado o termo "enjaular" aqui para indicar que o aplicativo está executando num diretório onde foi utilizado o comando chroot, que torna o diretório especificado o diretório raiz do sistema (/) para aquela sessão, impossibilitando o acesso aos diretórios que estão acima na estrutura.

[6] O diretório que conterá o bind-chroot e suas configurações é o diretório /var/named.

[7] Os arquivos pertencentes às bibliotecas das quais o bind-chroot se utiliza precisam estar dentro do diretório "raiz" (/var/named/) para que o bind-chroot possa localizá-los.

[8] Para verificar quais bibliotecas dinâmicas o bind-chroot utiliza, execute o comando ldd /var/named/usr/sbin/named.

[9] O netfilter pode gerenciar a criação de novas cadeias dinamicamente, de maneira bem mais flexível que o ipchains.

[10] Queries.

[11] Analisys Console for Intrusion Databases.

[12] O comando a seguir pode demorar alguns minutos, dependendo da sua máquina.

[13] Este arquivo tem permissão de leitura apenas para o administrador do sistema, uma vez que pode conter as senhas da acesso à base de dados utilizada pelo Snort.

[14] É importante que o tráfego desejado passe por esta interface. De nada adianta configurar HOME_NET para uma rede cujo tráfego não passe por esta placa de rede.

[15] O ACID não precisa estar na mesma máquina em que o Snort estiver sendo executado.




Fonte:Conectividade