Portal Chamar Táxi

Segurança no Servidor

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Desabilitando Serviços Desnecessários





Os serviços normalmente habilitados no seu Conectiva Linux dependem do perfil utilizado na instalação do sistema. Portanto, após instalar o sistema você deve verificar quais deles realmente precisam estar habilitados. Existem, basicamente, dois tipos de serviços: aqueles que rodam no modo standalone e aqueles que rodam através do xinetd.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Serviços Standalone



Serviços que rodam no modo standalone são geralmente executados durante a inicialização do sistema, através dos chamados scripts de inicialização. O Apache e o LDAP são exemplos desses serviços.

Uma das ferramentas que podem ser utilizadas para configurar os serviços a serem executados é o Linuxconf. Para reiniciar, parar ou acionar serviços dirija-se ao menu Controle -> Painel de Controle -> Controle de atividades e serviços e seleciona o serviço desejado.

Outra ferramenta que pode ser utilizada é o ntsysv. Para instalá-lo, basta utilizar o apt-get (não esqueça de atualizar o arquivo de repositórios antes de instalar o pacote):

# apt-get install ntsysv


ntsysv

Para a configuração dos serviços a serem executados, basta selecioná-los na janela do ntsysv. Para executá-lo, digite:

# /usr/sbin/ntsysv


A Figura 7-2 ilustra a tela do programa ntsysv. Através desta tela você pode (e deve) desabilitar todos os serviços que não são utilizados. Para obter uma descrição de um serviço, selecione-o e pressione a tecla de função F1. Note que outros tipos de serviços são iniciados automaticamente, e não apenas serviços de rede. O gpm, por exemplo, é um serviço que adiciona suporte a mouse para aplicações que rodam no modo texto. Tome o cuidado de desabilitar apenas os serviços que não devem ser utilizados na máquina. Por exemplo, não desabilite o serviço httpd se for necessário rodar um servidor web na máquina.



ntsysv.jpg




Figura 7-2. Configuração da Inicialização de Serviços

O ntsysv configura apenas o nível de execução atual. Se você deseja configurar outros níveis de execução, estes níveis podem ser especificados na linha de comando, através da opção - -levels. É possível configurar vários níveis de execução simultaneamente. Executando o comando ntsysv - -levels 345, por exemplo, seriam configurados os níveis 3, 4 e 5 simultaneamente. Neste caso, se um serviço for marcado como habilitado, ele será habilitado em todos os níveis de execução especificados. De maneira análoga, ao desabilitar um serviço, o mesmo será desabilitado em todos os níveis de execução especificados.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Serviços Executados Através do xinetd





O xinetd (Extended Internet Services Daemon) é um daemon[4] geralmente executado na inicialização do sistema e que espera por conexões em alguns sockets internet específicos. Quando uma conexão é estabelecida em algum destes sockets, ele verifica a qual serviço o socket corresponde e invoca o programa capaz de servir a requisição em questão. Resumidamente, ele invoca daemons sob demanda, reduzindo a carga da máquina. Obviamente, este tempo necessário para invocar um daemon sob demanda pode ser prejudicial em serviços muito utilizados e é por isto que muitos serviços não podem ser executados através do inetd.

Nota: O xinetd trabalha de modo análogo ao inetd, possuindo somente arquivos de configuração diferentes. O inetd ainda continua na distribuição, podendo ser encontrado em um dos outros CDs do Conectiva Linux.

A configuração do xinetd reside no arquivo /etc/xinetd.conf e no diretório /etc/xinetd.d, embora o arquivo /etc/services também seja utilizado para mapear nomes de serviços para suas respectivas portas e protocolos. Estes arquivos podem ser alterados através de um editor de textos, ou então através do Linuxconf.

A configuração dos serviços e portas para o xinetd no Linuxconf é efetuada através da configuração de Configuração -> Rede -> Tarefas de servidor -> Serviços Internet. Esta configuração compreende a administração do arquivo /etc/services (opção Serviços de rede para Internet). Através desta opção, é possível adicionar, modificar ou remover o mapeamento do nome de um serviço para sua respectiva porta e protocolo. A Figura 7-3 ilustra a configuração do serviço chamado pop-3.


seguranca-servid-configur.jpg


Figura 7-3. Configuração de Serviços pelo Linuxconf

O arquivo /etc/xinetd.conf possui a configuração que será aplicada aos serviços contidos no diretório /etc/xinetd.d, e não é necessária nenhuma mudança em especial. Para informações mais detalhadas sobre as opções deste arquivo, dirija-se ao capítulo sobre o xinetd do Guia Entendendo o Conectiva Linux.

Um exemplo de serviço (echo) pode ser visto abaixo:

# default: off# description: An echo server. This is the tcp # version.service echo{ type = INTERNAL id = echo-stream socket_type = stream protocol = tcp user = root wait = no disable = yes}


Pode-se notar que este serviço está desabilitado (disable = yes), e portanto, para desabilitar qualquer serviço, basta modificar esta linha e reinicializar o xinetd:

# service xinetd restart


Como regra geral, mantenha desabilitados os serviços:

echo;

discard;

daytime;

chargen;

shell;

login;

exec;

talk (e similares);

tftp;

bootps;

finger (e similares);

systat;

netstat;

time.

Estes serviços dificilmente são necessários em sua máquina e possíveis invasores costumam utilizá-los como amostra do que está habilitado na máquina que pretendem invadir. Além destes, desabilite todos aqueles que não serão utilizados. Por exemplo, se não for necessário um servidor FTP na máquina, desabilite-o e, preferencialmente, desinstale do sistema o pacote correspondente.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Utilizando TCP_Wrappers




O pacote tcp_wrappers é utilizado para controlar o acesso a serviços. O xinetd já está configurado no Conectiva Linux para o uso do tcp_wrappers em todos os daemons possíveis e recomendados.

Os aplicativos necessários à utilização de tcp_wrappers já vêm instalados por padrão no Conectiva Linux. Você pode verificar procurando, na lista de pacotes instalados do Synaptic, pelo pacote tcp_wrappers.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Configurando tcp_wrappers




A configuração dos serviços com tcp_wrappers deve ser efetuada através dos arquivos /etc/hosts.allow e /etc/hosts.deny. Em /etc/hosts.deny são configuradas as regras para negar serviços a determinados clientes, ao mesmo tempo em que no arquivo /etc/hosts.allow configuram-se regras para permitir que determinados clientes tenham acesso a serviços.

Existem dezenas de possibilidades de configuração para o tcp_wrappers e você pode estudá-las em extensão através das páginas de manual hosts_access e hosts_options. Portanto, serão ilustrados apenas alguns casos interessantes do uso desta ferramenta.

As regras de controle de acesso, existentes nestes dois arquivos, têm o seguinte formato:

lista_de_daemons : lista_de_clientes [ : comando ]

lista_de_daemons
Lista de um ou mais nomes de daemons como especificados no /etc/inetd.conf, ou curingas.

lista_de_clientes
Lista de um ou mais endereços ou nomes de máquinas, padrões ou curingas utilizados para especificar quais clientes podem e quais não podem acessar o serviço.

comando (opcional)
É possível executar um comando sempre que uma regra casa com um padrão e é utilizada. Veja exemplos a seguir.

Como citado anteriormente, curingas podem ser utilizados tanto na lista de daemons quanto na lista de clientes. Entre os existentes, pode-se destacar os seguintes:

ALL
Significa todos os serviços ou todos os clientes, dependendo apenas do campo em que se encontra.

LOCAL
Este curinga casa com qualquer nome de máquina que não contenha um caractere ponto ".", isto é, uma máquina local.

PARANOID
Casa com qualquer nome de máquina que não case com seu endereço. Isto geralmente ocorre quando algum servidor DNS está mal configurado ou quando alguma máquina está tentando se passar por outra.

Na lista de clientes podem ser utilizados nomes ou endereços de máquinas, ou então padrões que especificam um conjunto de máquinas. Se a cadeia de caracteres que identifica um cliente inicia com um ponto ".", um nome de máquina irá casar com este padrão sempre que o final desse nome casar com o padrão especificado. Por exemplo, se fosse utilizada a cadeia de caracteres ".minhaorganizacao", o nome de máquina galileu.minhaorganizacao casaria com o padrão.

Similarmente, se a cadeia de caracteres termina com um ponto ".", um endereço de máquina irá casar com o padrão quando seus campos numéricos iniciais casarem com a cadeia de caracteres especificada. Para exemplificar, se fosse utilizada a cadeia de caracteres "192.168.220.", todas as máquinas que tenham um endereço IP que inicie com estes 3 conjuntos de números irão casar com o padrão (192.168.220.0 ao 192.168.220.255).

Além destes métodos, é possível identificar um cliente através do IP/máscara de rede. Você pode especificar, por exemplo, "192.168.220.0/255.255.255.128", e qualquer máquina com endereço IP entre 192.168.220.0 e 192.168.220.127 casaria com o padrão.

Uma boa política é fechar completamente o acesso de todos os serviços a quaisquer clientes, através do arquivo /etc/hosts.deny, e seletivamente liberar o acesso aos serviços necessários através do arquivo /etc/hosts.allow. No Exemplo 7-1, está descrita uma configuração que libera o acesso a FTP apenas ao domínio minhaorganizacao, o acesso ao servidor POP3 a qualquer máquina, todos os serviços para localhost e nega-se os demais serviços para qualquer máquina que seja.

Exemplo 7-1. Exemplo de Configuração do tcp_wrappers

Segue abaixo o arquivo /etc/hosts.deny:

ALL:ALL


Arquivo /etc/hosts.allow:

ALL: localhostin.ftpd: .minhaorganizacaoipop3d: ALL


No Exemplo 7-2, considere o mesmo arquivo /etc/hosts.deny do exemplo anterior:

Exemplo 7-2. Configuração do tcp_wrappers menos restritiva

Arquivo /etc/hosts.allow:

ALL: localhostin.ftpd: .minhaorganizacao 200.234.123.0/255.255.255.0 200.248.ipop3d: ALL EXCEPT hackerboys.org


Neste último caso, máquinas da rede "200.234.123.0/255.255.255.0" e máquinas em que o endereço IP inicie por "200.248." também podem acessar o serviço FTP. Note que foi utilizado um operador novo para o serviço ipop3d: EXCEPT. Isto permitiu que o acesso a este serviço fosse liberado para todos, exceto para máquinas da rede "hackerboys.org".

O operador EXCEPT pode ser utilizado tanto na lista de clientes quanto na lista de serviços. Por exemplo, a linha:

ALL EXCEPT in.ftpd: ALL

no arquivo /etc/hosts.allow permite o acesso a todos os serviços, exceto o FTP, para qualquer máquina.

Todos os acessos, bem-sucedidos ou não, são registrados através do syslog. No Conectiva Linux estas informações são registradas no arquivo /var/log/secure. É recomendado que este arquivo seja periodicamente analisado à procura de tentativas de invasão.

Vários outros exemplos de configuração estão descritos nas páginas de manual citadas anteriormente (hosts_access e hosts_options).

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Testando a Configuração









Negue certos serviços para uma máquina de sua rede (como por exemplo o serviço telnet) e após reinicializar o xinetd, procure fazer acessos da máquina onde o serviço foi negado.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Verificando a Integridade do Sistema




Uma das primeiras ações de um invasor costuma ser substituir arquivos e programas do sistema com o intuito de mascarar sua visita atual e, principalmente, facilitar as visitas futuras. Portanto, se houver a possibilidade de verificar a integridade de arquivos do sistema, haverá uma grande possibilidade de detectar uma invasão. E o melhor é que este recurso permite que se saiba quais arquivos foram modificados, possibilitando que o administrador decida entre reinstalar o sistema ou apenas substituir o arquivos alterados pelos originais.

Após perceber que a máquina foi invadida, o administrador costuma analisar o sistema utilizando programas como ps, ls, netstat e who. Ocorre que estes programas são os primeiros a serem substituídos, ocultando, assim, a invasão e o invasor propriamente dito. Mesmo que se tenha a informação de data e tamanho dos arquivos originais, estas informações, sozinhas, não podem ser utilizadas como parâmetro, pois podem ser facilmente modificadas. Contudo, se além destas informações estiver disponível algo como o checksum MD5 dos arquivos, torna-se bem mais simples encontrar arquivos indevidamente modificados.

O AIDE (Advanced Intrusion Detection Environment) é um programa que tem justamente a finalidade de verificar a integridade dos arquivos do sistema. Ele constrói uma base de dados com várias informações dos arquivos especificados em seu arquivo de configuração. Esta base de dados pode conter vários atributos dos arquivos, como:

permissões;

número do inode;

dono;

grupo;

tamanho;

data e hora de criação, último acesso e última modificação.

Além disso, o AIDE também pode gerar e armazenar nesta base de dados o checksum criptográfico dos arquivos, utilizando um, ou uma combinação dos seguintes algoritmos: md5, sha1, rmd160 e tiger.

O procedimento recomendado é que você crie esta base de dados em um sistema recém-instalado, antes de conectá-lo a uma rede. Esta base de dados será a fotografia do sistema em seu estado normal e o parâmetro a ser utilizado para medir alterações no sistema de arquivos. Obviamente, sempre que você modificar o seu sistema, como por exemplo através da instalação, atualização ou remoção de programas, uma nova base de dados deve ser gerada. Esta nova base de dados é que deve ser utilizada como parâmetro. A base de dados deve conter informações sobre binários, bibliotecas e arquivos de cabeçalhos importantes do sistema, já que estes não costumam ser alterados durante o uso normal do sistema. Informações sobre arquivos de log, filas de correio eletrônico e de impressão, diretórios temporários e de usuários não devem ser armazenados na base de dados, já que são arquivos e diretórios freqüentemente alterados
 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Instalando o AIDE




Para instalar o AIDE, utilize o apt-get, digitando o seguinte comando em um terminal:

# apt-get install aide

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Configuração do AIDE




A configuração do AIDE reside no arquivo /etc/aide.conf. Este arquivo tem três tipos de linhas:

linhas de configuração: utilizadas para definir parâmetros de configuração do AIDE.

linhas de seleção: utilizadas para indicar quais arquivos terão suas informações adicionados à base de dados.

linhas de macro: utilizadas para definir variáveis no arquivo de configuração.

Apenas as linhas de seleção são essenciais ao funcionamento do AIDE. Existem, por sua vez, três tipos de linhas de seleção. Estas linhas são interpretadas como expressões regulares. Linhas que começam com uma barra "/" indicam que os arquivos que casarem com o padrão terão suas informações adicionadas ao banco de dados. Se a linha iniciar com um ponto de exclamação "!", ocorre o contrário: os arquivos que casam com o padrão são desconsiderados. Linhas iniciadas por um sinal de igualdade "=" informam ao AIDE que somente arquivos que sejam exatamente iguais ao padrão devem ser considerados.

Através das linhas de configuração é possível definir alguns parâmetros de funcionamento do AIDE. Estas linhas têm o formato parâmetro=valor. Os parâmetros de configuração estão descritos a seguir:

database
A URL do arquivo de banco de dados de onde as informações são lidas. Pode haver somente uma linha destas. Se houver mais de uma, apenas a primeira será considerada. O valor padrão é ./aide.db.

database_out
A URL do arquivo de banco de dados onde são escritas as informações. Assim como database, deve haver apenas uma linha destas. No caso de haver várias, somente a primeira ocorrência será considerada. O valor padrão é ./aide.db.new.

report_url
A URL onde a saída do comando é escrita. Se existirem várias instâncias deste parâmetro, a saída será escrita em todas as URLs. Se você não definir este parâmetro, a saída será enviada para a saída padrão (stdout).

verbose
Define o nível de mensagens que é enviado à saída. Este valor pode estar na faixa entre 0 e 255 (inclusive) e somente a primeira ocorrência deste parâmetro será considerada. É possível sobrescrever este valor através das opções - -version ou -V na linha de comando.

gzip_dbout
Informa se o banco de dados deve ser compactado ou não. Valores válidos para esta opção são yes, true, no e false.

Definições de grupos
Se o parâmetro não for nenhum dos anteriores então ele é considerado uma definição de grupo. Embora existam alguns grupos predefinidos que informam ao AIDE quais as informações do arquivo que devem ser armazenadas na base de dados, você pode criar suas próprias definições. A Tabela 7-3 mostra os grupos predefinidos.

Tabela 7-3. Grupos Predefinidos

p permissões
i inode
n número de links
u dono
g grupo
s tamanho
m data e hora da última modificação
a data e hora do último acesso
c data e hora da criação do arquivo
S verifica o aumento do tamanho do arquivo
md5 checksum md5
sha1 checksum sha1
rmd160 checksum rmd160
tiger checksum tiger
R p+i+n+u+g+s+m+c+md5
L p+i+n+u+g
E grupo vazio
> arquivo de log (aumenta o tamanho) - p+u+g+i+n+S

Você poderia definir um grupo que verifica apenas o dono e o grupo do arquivo, da seguinte maneira:

trivial=u+g

As linhas de macro podem ser utilizadas para definir variáveis e tomar decisões baseadas no valor destas. Informações detalhadas podem ser encontradas na página de manual do arquivo de configuração (man aide.conf).

O termo URL, utilizado na configuração dos parâmetros database, database_out e report_url, pode assumir um dos seguintes valores:

stdout: a saída é enviada para a saída padrão.

stderr: a saída é enviada para a saída padrão de erros.

stdin: a entrada é lida da entrada padrão.

file:/arquivo: a entrada é lida de arquivo ou a saída é escrita em arquivo.

fd:número: a entrada é lida do filedescriptor número ou a saída é escrita no filedescriptor número.

Note que URLs de entrada não podem ser utilizadas como saídas e vice-versa.

O Exemplo 7-3 ilustra uma configuração básica para o AIDE.

Exemplo 7-3. Arquivo de Configuração do AIDE

# Localização da base de dadosdatabase=file:/var/aide/aide.db# Local onde é criada uma base de dados novadatabase_out=file:/var/aide/aide.db.new# Arquivo onde será salva a saída do programareport_url=/var/aide/report.aide# Grupo para verificação de dono, grupo e permissões trivial=u+g+p/bin R/sbin R/boot R/etc R# Verifica apenas dono, grupo e permissões/etc/passwd trivial/etc/shadow trivial# Ignora o diretório /etc/X11!/etc/X11/lib R# Incluindo /var/var R# Ignora /var/log, /var/spool e /var/lock!/var/log/.*!/var/spool/.*!/var/lock/.*# Ignora o arquivo /var/run/utmp!/var/run/utmp$


O ideal é ignorar diretórios que são modificados com muita freqüência, a não ser que você goste de logs gigantescos. É um procedimento recomendado excluir diretórios temporários, filas de impressão, diretórios de logs e quaisquer outras áreas freqüentemente modificadas. Por outro lado, é recomendado que sejam incluídos todos os binários, bibliotecas e arquivos de cabeçalhos do sistema. Muitas vezes é interessante incluir diretórios que você não costuma observar, como o /dev/ e o /usr/man.

Atenção
Se sua idéia é referir-se a um único arquivo, você deve colocar um $ no final da expressão regular. Com isto, o padrão casará apenas com o nome exato do arquivo, desconsiderando arquivos que tenham o início do nome similar.


O pacote do AIDE que acompanha o Conectiva Linux tem um arquivo de configuração padrão funcional, mas nada o impede de modificá-lo para refletir suas necessidades.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Utilização do AIDE



Como o arquivo de configuração padrão deverá servir para a maioria dos casos, para gerar o banco de dados basta executar os comandos:

# /usr/bin/aide -i# mv /var/aide/aide.db.new /var/aide/aide.db


Após esta operação, você deve executar o comando:

# /usr/bin/aide-md5 [dispositivo de boot]


O parâmetro [dispositivo de boot] é opcional, e corresponde ao dispositivo de armazenamento utilizado para inicialização do sistema (/dev/hda, por exemplo).

O aide-md5 foi desenvolvido pela Conectiva e supre a falta de assinatura do banco de dados do AIDE. Ele informa os somatórios MD5 de alguns componentes críticos ao funcionamento do AIDE, inclusive do próprio banco de dados recém-gerado. Você deve tomar nota desses somatórios para verificação posterior.

Se o dispositivo de boot for informado ao aide-md5, o MD5 do setor de boot também será calculado, portanto é interessante informar esse parâmetro.

Testando a Configuração
Para verificar a integridade do sistema, execute o próprio AIDE, desta forma:

# /usr/bin/aide -C


Os arquivos que sofreram qualquer mudança, seja no tamanho, conteúdo, permissões ou data de criação, serão listados.

É provável que, na maioria das vezes que o AIDE apontar diferenças em arquivos, elas tenham sido provocadas por atos legítimos, por exemplo, atualização de pacotes ou intervenção do administrador do sistema. Nesses casos, o administrador deve, após uma conferência, reconstruir o banco de dados.

Para verificar a integridade do próprio AIDE, deve-se novamente utilizar o programa aide-md5, mas desta vez, de uma mídia removível, como, por exemplo, de um disquete:

# /mnt/floppy/aide-md5 /dev/hda


Se algum dos códigos MD5 não bater com aqueles gerados anteriormente, o(s) respectivo(s) componente(s) pode(m) estar comprometido(s), e isto é um problema muito sério.

Obviamente que, se você alterou as configurações do AIDE, regerou o banco de dados ou atualizou o kernel, os códigos serão diferentes. Logo após efetuar quaisquer destas alterações, você deve executar novamente o aide-md5 e anotar os códigos.

Atenção
É altamente recomendável copiar o aide-md5 para um meio removível, protegido contra gravação, e uma vez que o sistema tenha entrado em produção, deve-se executá-lo sempre a partir daquele meio, eventualmente removendo o aide-md5 original do disco rígido. Pois, se você fizer uso do aide-md5 do disco rígido, e este for comprometido, o invasor pode forjar somatórios MD5 falsamente perfeitos.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Bind-Chroot



O bind-chroot é uma versão do bind padrão modificada para executá-lo de modo "enjaulado"[5] dentro de um diretório, de maneira que ele não tenha acesso aos diretórios do sistema. Essa característica garante que, caso o bind-chroot seja atacado e forneça acesso à máquina, o invasor não terá acesso aos diretórios externos àquele utilizado pelo bind-chroot[6].

Características do Bind-chroot
A seguir serão vistas algumas das vantagens de se "enjaular" o bind num diretório específico:

Caso um invasor consiga, durante um ataque, acesso à sua máquina, ele não poderá navegar na estrutura de diretórios acima do diretório no qual o bind foi "enjaulado".

Dentro do diretório onde o bind estiver "enjaulado" existirão apenas os arquivos necessários para a utilização do bind, não deixando brechas para a execução de, por exemplo, um shell (/bin/sh) caso sua máquina seja atacada.

Para utilizar o bind-chroot é preciso criar uma nova estrutura de diretórios semelhante à estrutura do diretório raiz (/) e duplicar alguns arquivos[7] existentes no seu disco rígido para que ele possa executar "enjaulado". A instalação do pacote bind-chroot já cria todos os diretórios e arquivos necessários para a utilização dele.

Nota: Um detalhe importante é que, caso haja uma atualização dos arquivos das bibliotecas[8] que o bind-chroot utiliza, o administrador do sistema deverá lembrar de atualizar os arquivos dentro do diretório onde ele está "enjaulado".

Pré-requisitos
Para utilizar o bind-chroot, você irá precisar ter o bind instalado e configurado.

Nota: Um detalhe que muitas vezes passa despercebido é que quando você instala o bind-chroot você deve alterar o arquivo /etc/sysconfig/named, modificando para yes o parâmetro CHROOT.

Instalação
Para instalar o bind-chroot, execute o Synaptic e selecione o seguinte pacote para a instalação:

bind-chroot

É possível também instalar o bind-chroot utilizando o apt-get:

# apt-get install bind-chroot

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Configuração do Bind-chroot



A configuração do bind-chroot é idêntica à configuração do bind, já vista no Capítulo 1. A única diferença entre as configurações do bind e do bind-chroot é a localização do arquivo de configuração. O arquivo de configuração do bind-chroot está localizado em /var/named/etc/named.conf em vez de estar no /etc/named.conf, que é o local padrão do arquivo de configuração do bind.

Observe que toda a estrutura de arquivos do bind-chroot é idêntica à utilizada pelo bind, porém relativa à /var/named/, que é o diretório raiz para o bind-chroot.

Testando a Configuração
Para testar se o bind-chroot está executando "enjaulado", no terminal digite:

# ps auxwww | grep named


O comando acima deverá mostrar uma saída semelhante a esta:

named 1805 0.0 2.7 11652 3460 ? S Mar05 0:00 named -u named -t \ /var/namednamed 1806 0.0 2.7 11652 3460 ? S Mar05 0:00 named -u named -t \ /var/namednamed 1807 0.0 2.7 11652 3460 ? S Mar05 0:00 named -u named -t \ /var/namednamed 1808 0.0 2.7 11652 3460 ? S Mar05 0:00 named -u named -t \ /var/namednamed 1809 0.0 2.7 11652 3460 ? S Mar05 0:00 named -u named -t \ /var/namedroot 2002 0.0 0.4 1364 592 ? S Mar05 0:00 syslogd -m 0 -a \ /var/named/dev/log


Observe nas linhas acima a opção -t /var/named na linha de execução do bind; essa opção indica que o bind será executado "enjaulado" no diretório /var/named/. Outra maneira de verificar se o bind está rodando "enjaulado" é listar o conteúdo do diretório /proc/pid/, onde pid é o número do processo do bind que está executando. Tomando como exemplo o processo 1805, veja a saída do comando a seguir:

# l /proc/1805 total 0 dr-xr-xr-x 3 named named 0 Mar 6 15:27 ./ dr-xr-xr-x 100 root root 0 Mar 5 10:55 ../ -r- -r- -r- - 1 root root 0 Mar 6 15:27 cmdlinelrwxrwxrwx 1 root root 0 Mar 6 15:27 cwd -> /var/named/var/named/ -r- - - - - - - - 1 root root 0 Mar 6 15:27 environlrwxrwxrwx 1 root root 0 Mar 6 15:27 exe -> /usr/sbin/named* dr-x- - - - - - 2 root root 0 Mar 6 15:27 fd/ -r- -r- -r- - 1 root root 0 Mar 6 15:27 maps -rw- - - - - - - 1 root root 0 Mar 6 15:27 memlrwxrwxrwx 1 root root 0 Mar 6 15:27 root -> /var/named/ -r- -r- -r- - 1 root root 0 Mar 6 15:27 stat -r- -r- -r- - 1 root root 0 Mar 6 15:27 statm -r- -r- -r- - 1 root root 0 Mar 6 15:27 status


Observe a quarta linha de baixo para cima, onde está indicada a opção root. Note que esse arquivo é um link para /var/named/, indicando que o diretório raiz desse processo é /var/named/. Dessa maneira, verifica-se que o bind está executando "enjaulado".

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Firewall Através de Filtro de Pacotes




Um firewall é um sistema que isola redes distintas e permite que se controle o tráfego entre elas. Um exemplo típico onde a utilização de um firewall é recomendada é na conexão de uma rede local à Internet. Embora o conceito de firewall seja bastante amplo e possa envolver servidores proxy, analisadores de logs e filtros de pacotes, entre outras características, nesta seção será visto somente o filtro de pacotes fornecido pelo kernel do Linux.

O kernel do Linux conta com um filtro de pacotes bastante funcional, que permite que sua máquina descarte ou aceite pacotes IP, baseando-se na origem, no destino e na interface pela qual o pacote foi recebido. A origem e o destino de um pacote são caracterizados por um endereço IP, um número de porta e pelo protocolo.

Todo o tráfego através de uma rede é enviado no formato de pacotes. O início de cada pacote informa para onde ele está indo, de onde veio e o tipo do pacote, entre outros detalhes. A parte inicial deste pacote é chamada cabeçalho. O restante do pacote, contendo a informação propriamente dita, costuma ser chamado de corpo do pacote.

Um filtro de pacotes analisa o cabeçalho dos pacotes que passam pela máquina e decide o que fazer com o pacote inteiro. Possíveis ações a serem tomadas em relação ao pacote são:

aceitar: o pacote pode seguir até seu destino.

rejeitar: o pacote será descartado, como se a máquina jamais o tivesse recebido.

bloquear: o pacote será descartado, mas a origem do pacote será informada de que esta ação foi tomada.

O filtro de pacotes do kernel é controlado por regras de firewall, as quais podem ser divididas em quatro categorias: a cadeia de entrada (input chain), a cadeia de saída (output chain), a cadeia de reenvio (forward chain) e cadeias definidas pelo usuário (user defined chain). Para cada uma destas cadeias é mantida uma tabela de regras separada.

Uma regra de firewall especifica os critérios de análise de um pacote e o seu alvo (target). Se o pacote não casa com o padrão especificado pela regra, a regra seguinte da cadeia é analisada. Se desta vez o pacote casar com o padrão, a regra seguinte é definida pelo alvo, que pode ser o nome de uma cadeia definida pelo usuário, ou um dos seguintes valores especiais:

ACCEPT
Significa que o filtro de pacotes deve deixar o pacote passar.

DROP
Significa que o filtro de pacotes deve impedir que o pacote siga adiante.

REJECT
Assim como DROP, significa que o pacote não deve seguir adiante, mas uma mensagem ICMP é enviada ao sistema originador do pacote, avisando-o de que o pacote foi rejeitado. Note que DENY e REJECT têm o mesmo significado para pacotes ICMP.

MASQUERADE
Este alvo somente é válido para a cadeia de reenvio e para cadeias definidas pelo usuário, e somente pode ser utilizado quando o kernel é compilado com suporte a IP Masquerade. Neste caso, pacotes serão mascarados como se eles tivessem sido originados pela máquina local.

REDIRECT
Este alvo somente é válido para a cadeia de entrada e para cadeias definidas pelo usuário e somente pode ser utilizado se o kernel foi compilado com a opção de Transparent proxy. Com isto, pacotes serão redirecionados para um socket local, mesmo que eles tenham sido enviados para uma máquina remota (veja o Capítulo 6 para mais detalhes). Obviamente isto só faz sentido se a máquina local é utilizada como gateway para outras máquinas. Se a porta especificada para redirecionamento é "0", que é o valor padrão, a porta de destino dos pacotes será utilizada como porta de redirecionamento. Se for especificada uma outra porta qualquer, esta será utilizada, independentemente daquela especificada nos pacotes.

RETURN
Se a regra contendo o alvo RETURN foi chamada por uma outra regra, a regra seguinte da cadeia que a chamou é analisada. Caso ela não tenha sido chamada por outra regra, a política padrão da cadeia é utilizada para definir o destino do pacote.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Configurando o firewall utilizando Iptables



Nesta seção será visto como configurar o firewall utilizando o netfilter. Como o Linuxconf ainda não suporta o Iptables, deve-se efetuar as configurações manualmente digitando os comandos diretamente num terminal. Nesta seção será permitido que as máquinas internas acessem diretamente a Internet. O servidor Web será uma máquina interna com um número IP reservado. Veja a Figura 7-4.


firewall_iptables.jpg


Figura 7-4. Firewall com iptables




Os recursos disponibilizados pelo netfilter são manipulados através do comando iptables. Como a criação de regras através do netfilter é dinâmica, assim como o ipchains, seu conteúdo é perdido quando a máquina é reinicializada. Quando utiliza-se o Linuxconf para efetuar essas configurações, as regras são salvas num arquivo interno. Esse é um dos motivos pelos quais deve-se criar um script de inicialização para que, após configuradas as regras de utilização, elas sejam executadas a cada inicialização.

Antes da criação de scripts e definição de quais serão as regras a serem utilizadas, será mostrada um pouco da sintaxe utilizada pelo comando iptables no tratamento de ganchos pré-existentes[9]. A sintaxe mais utilizada do comando iptables é a seguinte:

# iptables [X] [cadeia] [índice ou especificação_da_regra] [opções]


onde [X] pode ser:

-A: adicionar uma nova regra a uma cadeia.

-I: inserir uma nova regra numa posição em uma cadeia.

-R: substitui uma regra em uma posição da cadeia.

-D: apaga uma regra em uma posição da cadeia.

-D: apaga a primeira regra que casa com uma cadeia.

Basicamente, serão utilizadas as opções para adicionar (-A) e apagar (-D). As outras (-I para inserir e -R para substituir) são simplesmente extensões desses conceitos. Cada regra especifica um conjunto de condições que o pacote precisa satisfazer, e dependendo do que ele satisfizer, ele será direcionado para um destino ou para outro.

Atenção
É possível que, ao adicionar uma regra errada, sua máquina pare de funcionar corretamente. Neste caso, utilize o comando iptables -F, para que todas as regras do filtro de pacotes sejam desativadas. Porém, caso a política padrão esteja como DROP ou REJECT você precisará utilizar o comando iptables -P INPUT ACCEPT e a seguir iptables -P OUTPUT ACCEPT para redefinir a política padrão utilizada. Caso queira saber quais regras estão ativas, você pode usar o comando iptables -L .


Pré-requisitos
Para poder utilizar o comando iptables você deverá ter o pacote iptables instalado no seu sistema e também o módulo ip_tables.o carregado.

Para carregar o módulo ip_tables execute o seguinte comando:

# modprobe ip_tables


Instalação
Para instalar o iptables, selecione o seguinte pacote através do Synaptic:

iptables

É possível instalar o iptables utilizando o apt-get, digitando o seguinte comando em um terminal:

# apt-get install iptables



 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Configurando as regras para o firewall




Como foi visto anteriormente (Capítulo 6), a política padrão da cadeia de entrada deveria ser definida como DROP, negando qualquer acesso à rede. A sintaxe utilizada pelo iptables para efetuar essa ação é:

# iptables -t filter -P INPUT DROP


Deve-se permitir o acesso a um servidor web que escuta na porta 80 de uma máquina interna que possui o IP 192.168.1.200; porém, antes deve-se permitir todo e qualquer tráfego na interface lo (que é a interface de loopback), para que a comunicação inter-processos possa funcionar. É necessário, então, executar o seguinte comando:

# iptables -t filter -A INPUT -j ACCEPT -i lo


Antes ainda do tráfego ser liberado para o servidor Web, precisa-se fazer com que o firewall permita que os pacotes pertencentes às conexões já estabelecidas e os pacotes relacionados a essas conexões possam passar pelo firewall. Para isso, são necessários os seguintes comandos:

# iptables -t filter -A FORWARD -j ACCEPT -m state --stateESTABLISHED, RELATED# iptables -t filter -A INPUT -j ACCEPT -m state --stateESTABLISHED, RELATED


Agora que realmente será liberado o acesso à porta 80 do servidor Web, utilizando o comando:

# iptables -t filter -A FORWARD -j ACCEPT -m state NEW -p tcp \ - -dport http


Caso deseje liberar ainda mais um tipo de acesso, pode-se liberar o acesso à requisições[10] IDENT, utilizadas pelo protocolo de autenticação (auth), o qual pode ser utilizado por servidores SMTP e alguns servidores FTP. Para esse acesso ser liberado, basta executar o comando:

# iptables -t filter -A FORWARD -j ACCEPT -m state NEW -p tcp \- -dport auth


Agora, basta criar uma regra que irá rejeitar todos os pacotes que não casarem com as regras anteriores:

# iptables -t filter -A FORWARD -j REJECT


Após configurar o firewall, falta apenas configurar o mascaramento na interface de saída:

# iptables -t nat -A POSTROUTING -j MASQUERADE -o ppp0


Neste exemplo, está sendo configurado o mascaramento dos pacotes com destino ao servidor web. Todos os pacotes que vierem da interface ppp0 que tiverem com o protocolo tcp e forem destinados à porta 80 são destinados para a máquina interna:

# iptables -t nat -A PREROUTING -j DNAT - -to-dest 192.168.1.200 \-i ppp0 -p tcp - -dport 80


A configuração do firewall foi finalizada. Porém, lembre-se de que estas regras desaparecerão assim que a máquina for reinicializada. Para evitar que isso ocorra, deve-se criar um script que irá executar junto com a inicialização da máquina, garantindo que as regras estejam funcionando.

Crie no diretório /etc/init.d/ um arquivo chamado iptables com o seguinte conteúdo:

#! /bin/sh# description: Inicialização do iptables## chkconfig: 2345 80 30# processname: iptables# pidfile: /var/run/iptabless.pid. /etc/rc.d/init.d/functions. /etc/sysconfig/networkif [ ${NETWORKING} = "no" ]then exit 0ficase "$1" in start) gprintf "Iniciando o serviço de %s: " "IPtables" echo echo 1 > /proc/sys/net/ipv4/ip_forward /usr/sbin/iptables -t filter -P INPUT DROP /usr/sbin/iptables -t filter -A INPUT -j ACCEPT -i lo /usr/sbin/iptables -t filter -A FORWARD -j ACCEPT -m state \ - -state ESTABLISHED,RELATED /usr/sbin/iptables -t filter -A INPUT -j ACCEPT -m state \ - -state ESTABLISHED,RELATED /usr/sbin/iptables -t filter -A FORWARD -j ACCEPT -m state \ NEW -p tcp - -dport http /usr/sbin/iptables -t filter -A FORWARD -j ACCEPT -m state\ NEW -p tcp - -dport auth /usr/sbin/iptables -t filter -A FORWARD -j REJECT /usr/sbin/iptables -t nat -A POSTROUTING -j MASQUERADE -o ppp0 /usr/sbin/iptables -t nat -A PREROUTING -j DNAT \ - -to-dest 192.168.1.200 -i ppp0 -p tcp - -dport 80 ;; stop) gprintf "Parando o serviço de %s: " "IPtables" echo /usr/sbin/iptables -F ;; *) gprintf "Uso: iptables (start|stop)" echo ;;esacexit 0


Este script, além de inserir as regras necessárias para o firewall, carrega também os módulos do kernel necessários para este serviço.

Como você pode notar, esse script é muito semelhante ao utilizado anteriormente no Capítulo 6; a sugestão é unificar os dois scripts em um só para um melhor gerenciamento das regras utilizadas, considerando que, a única diferença nos dois scripts mencionados são as regras utilizadas.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
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

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
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

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
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.


topologia_snort.jpg


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


 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
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

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
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.


acid_1.jpg


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

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
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.


acid_log_ataques.jpg



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

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
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

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
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:

kerberos.jpg


Figura 7-8. Visão Geral do Kerberos



 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
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

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
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 des:eek:nlyrealm 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.

 
Topo