Disco Cheio

A proteção mais básica que se consegue com um bom esquema de particionamento é com relação ao problema de disco cheio. Para partições que armazenam dados de usuários, como a /home ou a de e-mail, isso pode ser contornado até certo ponto com o uso de quotas (ver a seguir). Mas, por exemplo, o diretório de logs, /var/log, é usado pelo sistema, e não por um usuário específico (usuário aqui no sentido de pessoa). Se não houvesse particionamento, o único limite para o tamanho desses arquivos seria o HD inteiro. Se, por exemplo, um ataque inundar os logs, se o disco estiver corretamente particionado isso somente afetará a partição dos logs: os usuários ainda terão o mesmo espaço livre no /home, o espaço para programas continuará o mesmo, etc. O mesmo vale para o outro sentido. Se não houver sistema de quotas, usuários poderão criar arquivos de qualquer tamanho e simplesmente acabar com o espaço em disco. Se houver particionamento, no máximo acabarão com o espaço em disco daquela partição.

Quotas

No Linux, quotas de disco são aplicadas por partição. Se houver somente uma partição no disco (a partição /, por exemplo), as quotas somente se aplicarão a ela por inteiro. Não há como definir quotas para diretórios específicos, a não ser que eles sejam pontos de montagem de alguma outra partição. Usando quotas, podemos definir alguns limites interessantes para usuários e/ou grupos. O sistema de quotas trabalha com os seguintes limites:

• soft limit: ao atingir este limite, o usuário infrator é avisado via e-mail e possui um período de tempo para voltar a ficar abaixo do limite;

• grace period: período em que o usuário pode ficar acima do soft limit. Após este período, o usuário não poderá mais criar arquivos nesta partição, devendo remover algo para voltar a ficar abaixo do limite;

• hard limit: é o limite que jamais será ultrapassado. Por exemplo, um usuário pode ultrapassar o soft limit e receber o aviso, mas continuar a aumentar o espaço ocupado no disco, ignorando o aviso. Mas do hard limit ele não poderá passar.

O pacote quotas possui diversos utilitários para manipular as quotas, mas o Linuxconf possui uma interface bastante agradável para fazer a mesma coisa. Antes de poder usar as quotas é necessário ativar seu suporte na hora de montar o sistema de arquivos. Na prática, o Linuxconf alterará o /etc/fstab para isso, e depois as funções de quotas poderão ser manipuladas à vontade.

Opções especiais de Montagem

Esta é a parte do particionamento que é mais interessante do ponto de vista de segurança. Pode-se fazer com que o sistema trate certos arquivos de forma diferente com uma série de opções. As opções de montagem podem ser fornecidas como parâmetro para o comando mount ou direto no arquivo /etc/fstab:

Via linha de comando:
# mount /dev/hda6 -t ext3 -o nosuid,nodev /mnt/tmp

Pelo arquivo:
/dev/hda6   /mnt/tmp    ext3    nosuid,nodev 0 0

A Tabela 7-1 ilustra algumas opções existentes para sistemas de arquivos dos tipos mais comuns (como ext2, ext3 e reiserfs). Outras, marcadas com um asterisco (*), também estão disponíveis para qualquer sistema de arquivos.

Estas opções são muito interessantes e se aplicam a diversas partições do nosso servidor. A seguir serão mostrados alguns exemplos de uso dessas opções em diferentes partições:

PAM

PAM é a parte principal da autenticação em um sistema Linux. PAM significa Pluggable Authentication Modules ou Módulos de Autenticação Plugáveis/Modulares.

Originalmente a autenticação no Linux era apenas via senhas criptografadas armazenadas em um arquivo local chamado /etc/passwd. Um programa como o login pedia o nome do usuário e a senha, criptografava a senha e comparava o resultado com o armazenado naquele arquivo. Se fossem iguais, garantia o acesso à máquina. Caso contrário, retornava erro de autenticação. Isto até funciona muito bem para o programa login, mas, suponha que agora deseja-se usar isso também para autenticação remota, ou seja, a base de usuários não está mais na mesma máquina, mas sim em alguma outra máquina da rede, o chamado servidor de autenticação. Será preciso mudar o programa login para que ele também suporte esse tipo de autenticação remota.

Suponha também que surgiu um novo algoritmo de criptografia, muito mais avançado, mais rápido, criptografa melhor, etc., sendo que o desejo é usar esse novo algoritmo. Deve-se, então, mudar novamente o programa login para que ele suporte este novo algoritmo também. No Linux, muitos programas utilizam algum tipo de autenticação de usuários. Imagine se todos eles tivessem que ser reescritos cada vez que se mudasse algum dos critérios de autenticação.

Para resolver este tipo de problema, a Sun® criou o PAM há alguns anos e liberou as especificações em forma de RFC. O Linux derivou sua implementação do PAM a partir deste documento. Com PAM, o aplicativo login deste exemplo teria que ser reescrito apenas uma vez, justamente para suportar PAM. A partir de então, o aplicativo delega a responsabilidade da autenticação para o PAM e não se envolve mais com isso.

Voltando ao exemplo anterior, no caso de se querer utilizar um outro algoritmo de criptografia para as senhas, basta que o módulo PAM seja modificado para que todos os aplicativos automaticamente e de forma transparente passem a usufruir desta nova forma de autenticação. PAM possui uma outra vantagem: é possível configurar a autenticação de forma individual para cada aplicativo. Com isto é possível fazer com que, por exemplo, um usuário comum possa usar os dispositivos de áudio do computador desde que tenha se logado na máquina através do console. Se o login não tiver sido feito no console (por exemplo, é um login remoto via SSH), este tipo de acesso ao hardware será negado.

Na verdade, PAM vai um pouco além da autenticação. Os módulos podem ser divididos em quatro classes:

Um módulo PAM pode ou não conter todas estas funções. O módulo pam_unix, por exemplo, pode ser usado nestes quatro tipos e possui ações diferentes em cada uma das situações, enquanto que pam_console é normalmente usado apenas como session.

#%PAM-1.0
auth       required     /lib/security/pam_securetty.so
auth       required     /lib/security/pam_unix.so nullok
auth       required     /lib/security/pam_nologin.so
account    required     /lib/security/pam_unix.so
password   required     /lib/security/pam_cracklib.so
password   required     /lib/security/pam_unix.so shadow nullok \
use_authtok
session    required     /lib/security/pam_unix.so
session    optional     /lib/security/pam_console.so

$ telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Conectiva Linux 9
Kernel 2.4.20-26373cl

login: root
Password: 
# telnet localhost 
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Conectiva Linux 9
Kernel 2.4.20-26373cl

login: root
Password: 
Login incorrect

login:

# file classes -- these are regular expressions
<console>=tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9]
<xconsole>=:[0-9]\.[0-9] :[0-9]

# device classes -- these are shell-style globs
<floppy>=/dev/fd[0-1]*
<sound>=/dev/dsp* /dev/audio* /dev/midi* /dev/mixer* /dev/sequencer
<cdrom>=/dev/cdrom
<pilot>=/dev/pilot
<jaz>=/dev/jaz
<zip>=/dev/zip
<fb>=/dev/fb /dev/fb[0-9]*
<kbd>=/dev/kbd
<joystick>=/dev/js*
<v4l>=/dev/video* /dev/radio* /dev/winradio* /dev/vtx* /dev/vbi*

# permission definitions
<console>  0660 <floppy>    0660 root.floppy
<console>  0660 <sound>     0660 root.audio
<console>  0660 <cdrom>     0660 root.cdrom
<console>  0600 <pilot>     0660 root.tty
<console>  0600 <jaz>       0660 root.disk
<console>  0600 <zip>       0660 root.disk
<console>  0600 <fb>        0600 root
<console>  0600 <kbd>       0600 root
<console>  0600 <joystick>  0600 root
<console>  0600 <v4l>       0600 root

<xconsole> 0600 /dev/console 0600 root.root

#%PAM-1.0
auth     required   /lib/security/pam_securetty.so
auth     required   /lib/security/pam_nologin.so
auth     sufficient /lib/security/pam_unix.so shadow nullok md5 \ 
         use_authtok
auth     required   /lib/security/pam_ldap.so use_first_pass
account  sufficient /lib/security/pam_unix.so
account  required   /lib/security/pam_ldap.so
password required   /lib/security/pam_cracklib.so
password sufficient /lib/security/pam_unix.so nullok use_authtok \ 
         md5 shadow
password required   /lib/security/pam_ldap.so use_first_pass
session  optional   /lib/security/pam_console.so
session  sufficient /lib/security/pam_unix.so
session  required   /lib/security/pam_ldap.so

# default configuration: /etc/pam.d/other
#
auth     required       /usr/lib/security/pam_warn.so
auth     required       /usr/lib/security/pam_deny.so
account  required       /usr/lib/security/pam_deny.so
password required       /usr/lib/security/pam_warn.so
password required       /usr/lib/security/pam_deny.so
session  required       /usr/lib/security/pam_deny.so

mar 19 10:53:51 kepler PAM-warn[8365]: service: su \ 
  [on terminal: <unknown>]
mar 19 10:53:51 kepler PAM-warn[8365]: user: (uid=681) -> root \
 [remote: ?nobody@?nowhere]

$ su
su: senha incorreta

- : usuario1 : ALL EXCEPT tty3 tty4

account    required     /lib/security/pam_access.so

<domínio>     <tipo>     <item>     <valor>

session     required     /lib/security/pam_limits.so

@grupo1    -   maxlogins   1

Mar 19 16:39:52 kepler pam_limits[14659]:Too many logins (max 1) \
   for usuario
Mar 19 16:39:54 kepler login[14659]: Permission denied

# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Conectiva Linux 9
Kernel 2.4.20-26373cl

login: usuario 
Password: 

$ telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Conectiva Linux 9
Kernel 2.4.20-26373cl
login: usuario
Password: 

Too many logins for 'usuario'

Permission denied
Connection closed by foreign host.

@grupo2    -   nproc   3

kepler login: usuario
Password:
$ bash
$ bash
$ bash
bash: fork: Recurso temporariamente indisponível
$ ls
bash: fork: Recurso temporariamente indisponível
$ exit
$ ls
Desktop  GNUstep
$

account     required     /lib/security/pam_time.so

serviço;terminal;usuários;horários

login ; tty* ; !root ; Wk0800-1800

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.

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.

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.

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.

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.

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.

Referências

• Documento sobre tcp_wrappers

Instalando o AIDE

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

# apt-get install aide

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:

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.

# Localização da base de dados
database=file:/var/aide/aide.db
# Local onde é criada uma base de dados nova
database_out=file:/var/aide/aide.db.new
# Arquivo onde será salva a saída do programa
report_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.

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.

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.

# /usr/bin/aide -C

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

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].

# apt-get install bind-chroot

# ps auxwww | grep named

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

# 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 cmdline
lrwxrwxrwx    1 root   root  0  Mar 6 15:27 cwd -> /var/named/var/named/
 -r- - - - - - - -  1 root  root  0  Mar 6 15:27 environ
lrwxrwxrwx    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 mem
lrwxrwxrwx    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

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.

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:

1. -A: adicionar uma nova regra a uma cadeia.

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

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

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

5. -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.

# modprobe ip_tables

# apt-get install iptables

# iptables -t filter -P INPUT DROP

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

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

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

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

# iptables -t filter -A FORWARD -j REJECT

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

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

#! /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/network

if [ ${NETWORKING} = "no" ]
then
    exit 0
fi

case "$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
       ;;
esac

exit 0

Referências

• Site do netfilter .

• Tutorial sobre iptables .

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.

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

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

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 -p
Enter password:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 3.23.54-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer

mysql> 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_ADDRESS

var 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.rules
include $RULE_PATH/exploit.rules
include $RULE_PATH/scan.rules
include $RULE_PATH/finger.rules
include $RULE_PATH/ftp.rules
include $RULE_PATH/telnet.rules
include $RULE_PATH/rpc.rules
include $RULE_PATH/rservices.rules
include $RULE_PATH/dos.rules
include $RULE_PATH/ddos.rules
include $RULE_PATH/dns.rules
include $RULE_PATH/tftp.rules

include $RULE_PATH/smtp.rules
include $RULE_PATH/imap.rules
include $RULE_PATH/pop3.rules
include $RULE_PATH/pop2.rules

include $RULE_PATH/nntp.rules
include $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";

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.

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> quit
Bye

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.

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.

Referências

• Site Oficial do Snort .

• Site Oficial do ACID .

• WhiteHats .

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.

Implementação

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

[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:onlyrealm des:afs3 
   kdc_supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal \
des-cbc-crc:v4 
       }

#  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:

Referências

• Documentação sobre o Kerberos .

• Diálogo sobre desenvolvimento do Kerberos . Boa documentação.