Segurança no Servidor

[helldanger1]

Detectando Incidentes de Segurança




NIDS (Network Intrusion Detection System ou Sistema de Detecção de Intrusão de Rede) é um sistema que tem por objetivo principal a detecção de intrusos. Além disso, são sistemas que:

Analisam tráfego de rede;

Procuram por assinaturas de ataques;

Fazem o registro dos ataques e opcionalmente avisam um operador (realtime);

Trabalham com sensores; vários pontos da rede podem ser monitorados.

Nessa seção serão mostradas duas ferramentas presentes no Conectiva Linux que estão relacionadas com NIDS: Snort e ACID.

 

[helldanger1]

Características do Snort




O Snort é um aplicativo NIDS utilizado para detectar incidentes de segurança na sua rede. Ele pode analisar protocolos, procurar/casar conteúdos de pacotes, pode ser utilizado para detectar vários tipos de ataque, como, por exemplo, buffer overflow, portscan, ataques CGI e muitos outros. O Snort utiliza uma linguagem de regras muito flexível para descrever o tráfego que ele deve analisar ou deixar passar, e também um mecanismo de detecção que utiliza uma arquitetura modular de plugins, que registram os ataques de diversas maneiras. Veja alguns deles:

SQL (MySQL, PostgreSQL, Oracle, unixOdbc);

arquivo no formato tcpdump (binário);

arquivo texto;

XML;

syslog;

SMB (Winpopup).

O Snort pode ser considerado um sensor, podendo monitorar diferentes pontos da rede ao mesmo tempo.

A seguir, veja algumas das funcionalidades do Snort:

Normalizar requisições HTTP;

Detectar ataques do tipo Unicode;

Detectar portscan (por taxa e por flags);

Remontar os segmentos TCP;

Ativar regras dinamicamente (regras podem ser ativadas por outras regras).

Será visto aqui como instalar e configurar as opções básicas do Snort, utilizando-o em conjunto com o ACID[11], que é uma ferramenta utilizada para analisar os logs de incidentes do Snort, armazenados em um banco de dados.

 

[helldanger1]

Pré-requisitos
Para utilizar o Snort você precisa ter sua rede instalada e configurada. Será instalado, neste exemplo, Snort com suporte ao banco de dados MySQL, para ser possível utilizar o Snort juntamente com o ACID.

Deve-se também ter o Apache habilitado e configurado para trabalhar com PHP na máquina onde será configurado o ACID.

Instalação
Para instalar o Snort e o ACID, selecione os seguintes pacotes no Synaptic:

snort

MySQL

php4-mysql

acid

É possível instalar o Snort utilizando o apt-get, digitando os seguintes comandos em um terminal:

# apt-get install snort# apt-get install MySQL php4-mysql


Nota: A instalação do Snort neste manual será feita em localhost apenas a título de exemplo. Na Figura 7-5 pode-se ver um exemplo de instalação distribuída em três máquinas diferentes; uma possui o Snort instalado, a outra possui o banco de dados (MySQL) e a terceira executa o Acid.

Figura 7-5. Exemplo de Instalação Distribuída

 

[helldanger1]

Configuração do Snort




Inicialmente é preciso configurar o banco de dados que será utilizado para o Snort registrar as ocorrências detectadas. Aqui será utilizado o MySQL, instalado no passo anterior. Para iniciar a configuração do MySQL execute o seguinte comando num terminal:

# /usr/sbin/mysql_createdb


Atenção


Cuidado com a execução do comando a seguir. Execute-o somente se o MySQL nunca tiver sido utilizado antes, caso contrário você poderá perder seus dados.


A seguir, o comando pedirá a senha do usuário root do MySQL; note que essa senha não é a senha do superusuário do seu sistema e sim do usuário root do banco de dados.

Agora que já foi definida a senha do usuário root, o serviço MySQL deve ser iniciado. Continue no terminal e digite:

# service mysql start


Surgirá então uma mensagem indicando que o daemon do banco de dados foi iniciado.

O próximo passo é criar a base de dados na qual o Snort irá armazenar as ocorrências. Veja a seguir quais comandos utilizar.

# mysql -u root -pEnter password:Welcome to the MySQL monitor. Commands end with ; or \g.Your MySQL connection id is 1 to server version: 3.23.54-logType 'help;' or '\h' for help. Type '\c' to clear the buffermysql> create database snort; Query OK, 1 row affected (0.01 sec)mysql> grant insert, select update on snort.* to snort@localhost \identified by 'senha123'; Query OK, 0 rows affected (0.02 sec)mysql> grant insert, select, delete, update, create on \ snort.* to acid@localhost identified by -> 'acid_senha'; Query OK, 0 rows affected (0.01 sec)mysql> quit


Na primeira linha de comando informa-se ao MySQL que deve-se iniciá-lo como usuário root e que ele deve pedir a senha do usuário. Na segunda e terceira linha cria-se a base de dados e o usuário que o Snort irá utilizar para registrar as ocorrências. Observe que o usuário snort não tem permissão de apagar nada, e nem precisa. A única operação que o Snort irá executar será inserir incidências na base de dados.

Na quarta linha, é criado o usuário acid com permissão de inserir, selecionar, apagar, atualizar e criar tabelas na base de dados. A permissão de criação é dada para o usuário acid somente enquanto não instala-se e configura-se esse aplicativo. Assim que a configuração do ACID estiver terminada, essa permissão deve ser retirada, pois abre uma brecha potencial na segurança.

Criada a base de dados e os usuários necessários, deve-se ir até o diretório /usr/share/doc/snort-versão/; lá está contido um script para criar as tabelas e demais estruturas que o Snort irá utilizar. Estando nesse diretório, execute o seguinte comando:

# mysql -u root -p snort < create_mysql


O comando irá informar ao MySQLpara, como usuário root (do MySQL), executar na base de dados snort os comandos que estão no arquivo create_mysql. Você deverá informar a senha do usuário root do banco de dados para que o comando seja bem-sucedido. A seguir, execute o seguinte comando[12]:

# bzcat snortdb-extra.bz2 | mysql -u root -p snort


Esse comando irá terminar de criar as estruturas necessárias para o Snort.

Terminada a criação da estrutura da base de dados necessária para a utilização do Snort, deve-se agora editar o arquivo de configuração que fica em /etc/snort/snort.conf, modificando os valores de acordo com a necessidade.

Edite o arquivo de configuração do Snort[13] e verifique as seguintes linhas:

#var HOME_NET $eth0_ADDRESSvar HOME_NET [127.0.0.1,10.0.0.0/16]# Set up the external network addresses as well. A good start may be # "any"...var EXTERNAL_NET any# pode-se colocar !$HOME_NET para excluir a rede interna o HOME_NET# Define the addresses of DNS servers and other hosts if you want # to ignore portscan false alarms from them...var DNS_SERVERS [10.0.0.12/32]


Em HOME_NET você pode especificar uma máquina, interface ou rede na qual o Snort irá "escutar", ou ainda especificar uma lista dos itens acima mencionados, como especificado no exemplo. Em EXTERNAL_NET você irá configurar o que o Snort deve considerar como sendo uma rede externa; no exemplo, o parâmetro any indica qualquer rede. A terceira variável desse primeiro passo (DNS_SERVERS) é especificada para que o Snort não considere as tentativas de acesso provenientes do servidor DNS como sendo tentativas de portscan. Seguindo mais para o final do arquivo de configuração pode-se verificar o seguinte trecho:

# database: log to a variety of databases# ---------------------------------------# See the README.database file for more information about configuring# and using this plugin.#output database:log, mysql, user=snort dbname=snort host=localhost \ password=senha123# output database: log, postgresql, user=snort dbname=snort # output database: log, unixodbc, user=snort dbname=snort


Observe que a linha output database foi descomentada; ela refere-se ao banco de dados que é utilizado (MySQL). Foi inserido ao final da linha o parâmetro password=senha123, que indica ao Snort qual senha utilizar para efetuar o login no banco de dados.

Ao final do arquivo de configuração do Snort, são incluídos os arquivos que contêm as regras de filtragem que ele irá utilizar. O exemplo a seguir ilustra alguns arquivos de regras que podem ser incluídos:

include $RULE_PATH/bad-traffic.rulesinclude $RULE_PATH/exploit.rulesinclude $RULE_PATH/scan.rulesinclude $RULE_PATH/finger.rulesinclude $RULE_PATH/ftp.rulesinclude $RULE_PATH/telnet.rulesinclude $RULE_PATH/rpc.rulesinclude $RULE_PATH/rservices.rulesinclude $RULE_PATH/dos.rulesinclude $RULE_PATH/ddos.rulesinclude $RULE_PATH/dns.rulesinclude $RULE_PATH/tftp.rulesinclude $RULE_PATH/smtp.rulesinclude $RULE_PATH/imap.rulesinclude $RULE_PATH/pop3.rulesinclude $RULE_PATH/pop2.rulesinclude $RULE_PATH/nntp.rulesinclude $RULE_PATH/other-ids.rules


$RULE_PATH é a variável, definida neste mesmo arquivo, que contém o caminho para os arquivos de regras.

Cada arquivo desses contém regras e assinaturas específicas para reconhecer um tipo de ataque. Você pode encontrar mais arquivos com regras e assinaturas em: WhiteHats e no site do Snort .

O último passo para a configuração do Snort é editar o arquivo /etc/sysconfig/snort. A seguir são mostradas as opções a serem configuradas:

INTERFACE=eth0

AUTO=no

ACTIVATE=no

A variável INTERFACE indica em qual interface o Snort irá escutar[14], a variável AUTO=no indica que o Snort deverá pegar o endereço IP fornecido no arquivo de configuração; caso seja especificada essa opção como yes, o Snort irá pegar o valor IP diretamente da interface especificada, ignorando o valor presente no arquivo de configuração.

A variável ACTIVATE indica se o Snort deverá ser executado sempre que a interface "subir", pois quando a interface "cai", o Snort"cai" junto.

Inicie o serviço do Snort digitando o seguinte comando:

# service snort start


Para verificar se o Snort está em execução, digite:

# service snort status


Para configurar o ACID, deve-se primeiramente fazer com que o servidor web possua suporte ao PHP4, para que seja possível executar o ACID (consulte o Capítulo 3).

Em seguida, inicie o seu servidor web, pois o ACID será executado localmente.

# service http start


A seguir, edite o arquivo /srv/www/default/html/acid/config/acid_conf.php, que contém as configurações do ACID. Você precisa modificar apenas as seguintes variáveis:

$alert_dbname = "snort";$alert_host = "localhost";$alert_port = "";$alert_user = "acid";$alert_password = "acid_senha";

 

[helldanger1]

A variável $alert_dbname indica o nome da base de dados a ser utilizada, as variáveis a seguir indicam: máquina onde se localiza a base de dados[15], porta, nome do usuário que o ACID irá utilizar para efetuar o login na base de dados e a senha a ser utilizada.

O resto da configuração do ACID se faz através do navegador. Inicie um navegador e digite o endereço local ; deverá surgir a janela mostrada na Figura 7-6.

Figura 7-6. Instalação do ACID - Passo I

Utilize o link Setup page para iniciar a configuração da base de dados. Na próxima página você verá um botão chamado CREATE ACID AG; clique nesse botão. A próxima página mostrará as mensagens de criação das bases de dados:

Sucessfully created `acid_ag`Sucessfully created `acid_ag_alert`Sucessfully created `acid_ip_cache`


A próxima janela informa o estado do processo de criação das tabelas e índices e conduz à pagina principal do ACID, indicando que a sua configuração já foi finalizada e está pronto para ser utilizado.

Falta apenas retirar a permissão de criação de tabelas do usuário acid da base de dados. Voltando ao terminal modo texto, digite:

# mysql -u root -p mysql> revoke create on snort.* from acid@localhost;Query OK, 0 rows affected (0.22 sec)mysql> quitBye

 

[helldanger1]

Testando a Configuração
Para testar a configuração, será simulado um ataque. Inicialmente, verifique se o Snort está executando na máquina a ser atacada:

# service snort status


Com ele executando, efetue o login como usuário root em outra máquina da sua rede e utilize o comando nmap ip_da_maquina_a_ser_atacada. Caso não tenha o nmap instalado, instale-o utilizando o Synaptic, ou através do apt-get, com os comandos a seguir.

# apt-get update# apt-get install nmap


Após executar o nmap, vá até à máquina onde o Snort está instalado e inicie o navegador . Surgirá então uma janela semelhante à mostrada na Figura 7-7.

Figura 7-7. Visualização dos Ataques feitos à rede

Você pode explorar muitas das opções do ACID a partir da página inicial, onde encontrará os mais diversos tipos de gráficos e pesquisas que possam ser feitas no banco de dados. As opções mais comuns de pesquisa você encontra nos links da página principal, porém, caso esses tipos de pesquisa não satisfaçam as suas necessidades, clique no link Search e você será levado a uma página de pesquisa avançada, onde poderá especificar exatamente quais opções deseja.

Dentro das páginas de pesquisa você poderá optar por executar algumas ações com os registros obtidos. Entre elas estão:

Adicioná-los a um grupo de Alerta (por nome ou ID);

Enviá-los por e-mail (uma simples lista com os registros, ou então uma descrição completa dos registros);

Apagá-los (somente se o usuário acid tiver permissão delete na base de dados);

Arquivar os Alertas.

Estando numa página de pesquisa, você pode clicar sobre o nome de alguns ataques (por exemplo, IDS027 - SCAN-FIN), que o navegador abrirá uma nova janela com o site que contém a descrição desse tipo de ataque.

 

[helldanger1]

Kerberos





Apresentação


Kerberos é uma das formas de autenticação de usuários e serviços disponível a partir do Conectiva Linux 8. O protocolo Kerberos foi criado no MIT no final da década de 1980 e vem amadurecendo desde então. A versão disponível e usada hoje em dia é chamada de Kerberos 5 (ou Kerberos V).

A autenticação Kerberos possui as seguintes características:

single sign-on: o usuário só precisa fornecer a senha uma vez, normalmente no início da sessão. Depois disso a senha não precisa ser informada outra vez se algum serviço for acessado. Por exemplo, a senha não será mais pedida ao acessar a conta de correio eletrônico;

senha criptografada: a senha nunca trafega em texto claro pela rede;

autenticação centralizada: a mesma senha é usada para diversos serviços, todos consultam uma base de dados centralizada. Ou seja, o usuário não precisa memorizar várias senhas e uma política de senhas global pode ser facilmente criada;

redundância: servidores de autenticação secundários são previstos no protocolo;

múltiplos domínios: pode ser criada uma estrutura hierarquizada de autenticação, de forma que usuários de um domínio possam se autenticar em outro (por exemplo, funcionários da filial trabalhando na matriz e vice-versa);

configuração do cliente facilitada: boa parte da configuração do cliente pode ser colocada no DNS, de modo que, em muitos casos, não é necessário alterar uma linha sequer na estação de trabalho para que ela comece a usar Kerberos;

padrão: Kerberos V é um padrão documentado e implementações diferentes que obedeçam ao mesmo padrão podem conversar entre si. Dentro de certos limites, é possível, por exemplo, se autenticar num servidor W2K, e vice-versa, ou seja, um usuário de um servidor W2K poderá obter tickets de servidores Linux rodando Kerberos V.

Por outro lado, as aplicações que desejarem usar Kerberos terão que ser reescritas em sua grande maioria. No Conectiva Linux, este suporte foi habilitado na maioria dos aplicativos que o tinham disponível:

OpenLDAP;

Fetchmail;

imap (servidores IMAP e POP);

Mutt

OpenSSH (no repositório experimental apenas, este suporte ainda não está no pacote oficial do site dos autores);

PAM (via pam_krb5);

CVS;

entre outros.

 

[helldanger1]

Visão Geral do Kerberos V
A autenticação Kerberos trabalha com tickets. Estes tickets provam que o usuário é ele mesmo e são usados para autenticar este usuário frente aos serviços que ele deseja usar.

Quando um usuário se loga numa máquina, ele obtém o primeiro ticket, chamado de TGT (Ticket Granting Ticket). É com este TGT que o usuário irá pedir acesso aos outros serviços, não sendo mais necessário digitar a senha. Se o usuário agora desejar, por exemplo, acesso ao servidor de e-mail, ele vai apresentar o TGT ao Kerberos e pedir que seja emitido um ticket específico para o servidor de e-mail. O servidor Kerberos irá verificar o TGT e, se tudo estiver certo, responder à requisição do usuário com um ticket para o serviço pedido, no caso, servidor de e-mails. O usuário agora irá contatar o servidor de e-mails e apresentar o novo ticket recebido, ticket esse que o identifica, e terá acesso ao servidor de e-mails. Note que isso tudo ocorre de forma transparente para o usuário. Do ponto de vista do usuário, os e-mails simplesmente começaram a chegar, sem que fosse pedida qualquer senha. A Figura 7-8 a seguir mostra esse processo:

Figura 7-8. Visão Geral do Kerberos

 

[helldanger1]

Implementação



Pré-requisitos
Antes de colocar um sistema de autenticação Kerberos em produção é necessário tomar algumas decisões de projeto:

Domínio


Um servidor Kerberos trabalha com o conceito de realm ou domínio. Ele pode ser visto como sendo o autenticador central para as máquinas de um certo domínio. Tecnicamente, o domínio pode ter qualquer nome, mas o padrão é utilizar o mesmo domínio do DNS das máquinas, ou seja, máquinas do domínio .intranet.minhaorganizacao pertenceriam também ao domínio (realm) INTRANET.MINHAORGANIZACAO do Kerberos. Outra convenção é o uso de letras maiúsculas para o domínio Kerberos, mas minúsculas funcionam também sem problemas. Usuários desse domínio (os chamados principals ou principais) terão o seguinte login completo (seguindo o exemplo anterior):

usuário@INTRANET.MINHAORGANIZACAO


É possível e interessante em alguns casos usar mais de um domínio. Por exemplo, poderia existir o MATRIZ.MINHAORGANIZACAO e o FILIAL-RJ.MINHAORGANIZACAO. O Kerberos permite que se faça autenticação entre domínios, ou seja, um usuário do domínio MATRIZ. MINHAORGANIZACAO poderia se autenticar numa viagem à filial do RJ. Isso é chamado de cross-realm authentication. Note que cada domínio pode ter tantos servidores Kerberos quantos quiser, todos com a mesma base de dados. Isso é usado para redundância e para diminuir a carga de um servidor.

Replicação/servidores escravos (slaves)
É importante que um domínio de autenticação tenha pelo menos um servidor secundário, também chamado de escravo (slave). Este servidor secundário é automaticamente usado caso o primário não esteja respondendo, ou também pode ser usado por parte dos clientes para aliviar a carga sobre o servidor primário.

Assim como no caso de servidores secundários de DNS, os servidores secundários do Kerberos são uma cópia de leitura somente da base de dados central. Ou seja, modificações na base primária precisam ser propagadas para os servidores secundários. Ao contrário do DNS, esta propagação é manual no Kerberos. Tipicamente se utilizam scripts de propagação que são executados periodicamente pelo cron no servidor primário.

Como conseqüência da propagação manual e periódica, pode acontecer de uma senha ser trocada no servidor primário e esta modificação ainda não se encontrar no secundário. É possível, no entanto, fazer com que o cliente que estiver usando um servidor secundário consulte excepcionalmente um servidor primário caso a senha do usuário esteja incorreta, ou seja, este inconveniente da propagação pode ser contornado, no mínimo, para as senhas.

Além disso, deve-se:

verificar se a rede está configurada.

Instalação
Para instalar o KDC (Key Distribution Center) primário, execute o Synaptic e selecione os seguintes pacotes:

krb5

krb5-server

Para testes, é interessante instalar também o seguinte pacote:

krb5-client

ou utilize o apt-get:

# apt-get install krb5 krb5-server krb5-client


A Tabela 7-4 contém uma descrição dos pacotes do Kerberos:

Tabela 7-4. Pacotes do Kerberos

Nome do pacote Descrição
krb5 Bibliotecas dinâmicas usadas por aplicativos que trabalham com Kerberos.
krb5-client Programas para serem usados numa estação Kerberos, como kinit e kdestroy, entre outros.
krb5-server Contém os programas e arquivos necessários para um servidor Kerberos.
krb5-apps-client Contém os clientes para os servidores "kerberizados", como ktelnet e krsh, entre outros.
krb5-doc Documentação extra sobre o Kerberos.

 

[helldanger1]

Configuração




O primeiro passo é configurar seu domínio no arquivo de configuração do Kerberos em /var/kerberos/krb5kdc/kdc.conf. O arquivo enviado com o pacote contém algumas entradas comentadas que precisam ser modificadas. Este arquivo é dividido em seções cujo nome fica entre colchetes. A seção obrigatória é a que define o domínio e é chamada de [realms]. Abaixo um exemplo para o domínio MINHAORGANIZACAO.DOMINIO:

[realms] MINHAORGANIZACAO.DOMINIO = { database_name = /var/kerberos/krb5kdc/principal admin_keytab = FILE:/var/kerberos/krb5kdc/kadm5.keytab acl_file = /var/kerberos/krb5kdc/kadm5.acl key_stash_file = /var/kerberos/krb5kdc/.k5.MINHAORGANIZACAO.DOMINIO kdc_ports = 750,88 max_life = 8h 0m 0s max_renewable_life = 7d 0h 0m 0s master_key_type = des3-hmac-sha1 supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal \des:normal des:v4 des:norealm desnlyrealm des:afs3 kdc_supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal \des-cbc-crc:v4 }


Basicamente, apenas os parâmetros key_stash_file e database_name precisam ser alterados do padrão, além do nome escolhido para o domínio. Uma explicação detalhada sobre os outros parâmetros podem ser vistos na documentação do Kerberos (pacote krb5-doc).

Após a configuração no arquivo kdc.conf, deve-se criar o banco de dados principal do Kerberos, onde outras informações serão armazenadas mais tarde. Para isto, e continuando com o domínio do exemplo anterior, execute:

# kdb5_util create -r MINHAORGANIZACAO.DOMINIO -s Initializing database '/var/kerberos/krb5kdc/principal' for realm \ 'MINHAORGANIZACAO.DOMINIO', master key name 'K/M@MINHAORGANIZACAO.DOMINIO' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: Re-enter KDC database master key to verify:


Esta senha é a que permite acesso ao banco de dados do Kerberos e deve ser muito bem protegida. A opção -s faz com que seja criado o chamado stash file, que é uma cópia em disco dessa senha e é usada pelos serviços do Kerberos para acessar a base de dados. Se este arquivo não for criado, será necessário fornecer a senha cada vez que os serviços forem iniciados ou outros programas que acessem o banco de dados local sejam executados (como kadmin.local, por exemplo). Os scripts de inicialização fornecidos com o pacote não estão preparados para funcionar sem o stash file. Se você optar por não usar este arquivo de senha, precisará modificar os scripts de inicialização (krb5kdc e kadmind).

Os próximos passos configuram tarefas/serviços necessários para o funcionamento do servidor:

Criando ACLs (Access Control Lists)
O próximo passo é criar um arquivo contendo ACLs para tarefas de administração. Nessas ACLs são definidos quem pode fazer o quê com o banco de dados do Kerberos. Este arquivo é especificado no kdc.conf e é, por padrão, /var/kerberos/krb5kdc/kadm5.acl. O seu formato é:

Principal Permissões Principal de destino (opc.)


É comum usar-se uma instância diferente para um usuário quando ele for executar tarefas administrativas, ao invés de simplesmente tornar o próprio usuário um administrador diretamente. Por exemplo, o usuário:

usuario@MINHAORGANIZACAO.DOMINIO


é um usuário comum do domínio, mas o usuário:

usuario/admin@MINHAORGANIZACAO.DOMINIO


é usuario com a instância de administrador, que requer um outro ticket. As permissões disponíveis são as seguintes:

a: permite acrescentar principais ou políticas;

A: proíbe acrescentar principais ou políticas;

d: permite remover principais ou políticas;

D: proíbe remover principais ou políticas;

m: permite modificar principais ou políticas;

M: proíbe modificar principais ou políticas;

c: permite modificar senhas de principais;

C: proíbe modificar senhas de principais;

i: permite consultas ao banco de dados do Kerberos;

I: proíbe consultas ao banco de dados do Kerberos;

l: permite listar principais ou políticas;

L: proíbe listar principais ou políticas;

*: caractere curinga, vale por todas as permissões;

x: idêntico a "*".

Por exemplo:

*/admin@MINHAORGANIZACAO.DOMINIO *


A linha acima vai dar a todos os "principais" com instância admin todas as permissões possíveis. Neste caso, usuario/admin teria estas permissões, mas não usuario. Outro exemplo:

usuario2@MINHAORGANIZACAO.DOMINIO ali */root@MINHAORGANIZACAO.\DOMINIO


Esta linha permite que o "principal" usuario2 possa acrescentar, listar e fazer consultas sobre qualquer "principal" que tenha a instância root no banco de dados.

 

[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