[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ próximo ]


Securing Debian Manual
Capítulo 5 - Tornando os serviços em execução do seu sistema mais seguros


Os serviços podem ser deixados mais seguros de duas formas:

A restrição de serviços de forma que possam somente ser acessados de um determinado lugar pode ser feito restringindo o acesso a eles no nível de kernel (i.e. firewall), configure-os para operar somente em interfaces definidas (alguns serviços podem não ter esta característica) ou usando algum outro método, por exemplo o patch vserver do Linux (para 2.4.16) pode ser usado para forçar o kernel a utilizar somente uma interface de rede.

Com relação a serviços sendo executados a partir do inetd (telnet, ftp, finger, pop3...) é importante notar que o inetd pode ser configurado para que os serviços somente executem em uma interface definida (usando a sintaxe serviço@ip) mas esta é uma característica não documentada. Um de seus substitutos, o meta-daemon xinetd inclui uma opção chamada bind apenas para controlar este comportamento. Veja xinetd.conf(5).

     service nntp
     {
             socket_type     = stream
             protocol        = tcp
             wait            = no
             user            = news
             group           = news
             server          = /usr/bin/env
             server_args     = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin
     +/usr/sbin/snntpd logger -p news.info
             bind            = 127.0.0.1
     }

As seguintes seções detalham como alguns serviços individuais podem ser configurados adequadamente conforme sua utilização.


5.1 Tornando o ssh mais seguro

Caso ainda estiver usando o telnet ao invés do ssh, você deverá dar uma parada na leitura deste manual e alterar isto. O ssh deve ser usado para qualquer login remoto ao invés do telnet. Em uma era onde é fácil capturar o tráfego que circula na internet e obter senhas em texto plano, você deverá usar somente protocolos que utilizam criptografia. Assim, execute um apt-get install ssh agora em seu sistema.

Encoraje todos os usuários em seu sistema para utilizarem o ssh ao invés do telnet, ou até mesmo melhor, remova o telnet/telnetd. Em adição, você deverá evitar entrar no sistema usando o ssh como usuário root e ao invés disto, usar métodos alternativos para se tornar o root, como o su ou sudo. Finalmente, o arquivo sshd_config no diretório /etc/ssh, também deverá ser modificado para aumentar a segurança:

Você também poderá restringir o acesso ao servidor ssh usando o pam_listfile ou pam_wheel no arquivo de controle PAM para o ssh restringir os logins ssh. Por exemplo, se quiser manter qualquer pessoa não listada em /etc/loginusers adicionando esta linha no /etc/pam.d/ssh:

     auth       required     pam_listfile.so sense=allow onerr=fail item=user file=/etc/loginusers

Como nota final, tenha atenção que estas diretivas são válidas para um arquivo de configuração do OpenSSH. Atualmente, não freqüentemente usados três tipos de implementações conhecidas do daemon: ssh1, ssh2 e OpenSSH feito pelo time do OpenBSD. O ssh1 foi o primeiro daemon disponível e é ainda o mais usado (existem rumores que até existe um porte para Windows). O ssh2 possui mais vantagens sobre o ssh2, exceto que ele é lançado sob uma licença fonte fechado. O OpenSSH é um daemon ssh completamente livre, que suporta ambos os protocolos ssh1 e ssh2. O OpenSSH é a versão instalada junto o Debian quando o pacote ssh é escolhido.

Você pode ler mais informações sobre como configurar um SSH com suporte a PAM em arquivos da lista de segurança.


5.1.1 Executando o ssh em uma jaula chroot

O OpenSSH atualmente não suporta um método de chroot automático durante a conexão do usuário (a versão comercial oferece esta funcionalidade). No entanto existe um projeto para fornecer esta funcionalidade também para o ssh, veja http://chrootssh.sourceforge.net, atualmente ele não esta empacotado para o Debian. Você poderá usar, no entanto, o módulo pam_chroot como descrito em Restringindo acessos de usuários, Seção 4.10.8.

Em Ambiente chroot para SSH, Apêndice G você terá diversas opções para criar um ambiente chroot para o SSH.


5.1.2 Clientes do ssh

Se estiver usando um cliente SSH com um servidor SSH, você deverá ter certeza que ele suporta os mesmos protocolos que são especificados no servidor. Por exemplo, se utilizar o pacote mindterm, ele somente utiliza a versão 1 . No entanto, o servidor ssh utiliza, por padrão, a configuração para aceitar somente conexões para o protocolo da versão 2 (por razões de segurança).


5.1.3 Desativando transferências de arquivos

Se não quiser que seus usuários transfiram arquivos do servidor ssh, você precisará restringir acesso ao sftp-server e ao scp. Você poderá restringir o sftp-server configurando o sub-sistema Subsystem no arquivo /etc/ssh/sshd_config. No entanto para restringir o acesso ao scp você deverá:


5.2 Tornando o Squid mais seguro

O Squid é um dos servidores proxy/cache mais populares e existem algumas considerações de segurança que devem ser levadas em conta. O arquivo de configuração padrão do squid nega todas as requisições de usuários. No entanto, o pacote do Debian permite o acesso através de "localhost", você apenas precisa configurar seu navegador adequadamente. Configure o Squid para permitir acesso aos usuários confiáveis, máquinas ou redes definindo uma lista de controle de acesso no arquivo /etc/squid.conf, veja o endereço Guia do Usuário Squid para mais informações sobre a definição de regras de ACLs. Note que o Debian oferece uma configuração mínima para o Squid que prevenirá tudo, exceto a conexão de localhost em seu servidor proxy (que é executado na porta padrão 3128) É necessária a personalização do arquivo de configuração /etc/squid.conf como necessário. A configuração mínima recomendada (fornecida com o pacote) é mostrada abaixo:

     acl all src 0.0.0.0/0.0.0.0
     acl manager proto cache_object
     acl localhost src 127.0.0.1/255.255.255.255
     acl SSL_ports port 443 563
     acl Safe_ports port 80          # http
     acl Safe_ports port 21          # ftp
     acl Safe_ports port 443 563     # https, snews
     acl Safe_ports port 70          # gopher
     acl Safe_ports port 210         # wais
     acl Safe_ports port 1025-65535  # portas não registradas
     acl Safe_ports port 280         # http-mgmt
     acl Safe_ports port 488         # gss-http
     acl Safe_ports port 591         # filemaker
     acl Safe_ports port 777         # multiling http
     acl Safe_ports port 901         # SWAT
     acl purge method PURGE
     acl CONNECT method CONNECT
     (...)
     # Somente permite acesso do cachemgr vindos de localhost
     http_access allow manager localhost
     http_access deny manager
     # Somente permite requisições de purge vindas de localhost
     http_access allow purge localhost
     http_access deny purge
     # Bloqueia requisições para portas desconhecidas
     http_access deny !Safe_ports
     # Bloqueia CONNECT a portas que não sejam SSL
     http_access deny CONNECT !SSL_ports
     #
     # INSIRA SUAS PRÓPRIAS REGRAS AQUI PARA PERMITIR O ACESSO DE SEUS CLIENTE
     #
     http_access allow localhost
     # E finalmente bloqueia qualquer outro acesso a este proxy
     http_access deny all
     #Padrão:
     # icp_access deny all
     #
     #Permite requisições ICQ vindas de qualquer pessoa
     icp_access allow all

Você também deverá configurar o Squid baseado nos recursos do seu sistema, incluindo a memória cache (opção cache_mem), localização dos arquivos de cache e quantidade de espaço que utilizarão no disco (opção cache_dir).

Note que, se não for corretamente configurado, alguém poderá enviar mensagens de e-mail através do squid, pois os protocolos HTTP e SMTP tem design similar. O arquivo de configuração padrão do Squid bloqueia o acesso a porta 25. Se desejar permitir conexões a porta 25, apenas adicione-a a lista Safe_ports. No entanto, isto NÃO é recomendado.

Ajustar e configurar um servidor proxy/cache é apenas parte da tarefa de manter um site seguro. Outra tarefa necessária é a análise dos logs do Squid para ter certeza que todas as coisas estão funcionando como deveriam estar. Existem alguns pacotes no Debian GNU/Linux que podem ajudar o administrador a fazer isto. Os seguintes pacotes estão disponíveis na woody (Debian 3.0):

Quando estiver usando o squid em modo acelerador, ele atuará como servidor web também. Ativando esta opção, a complexidade do código aumenta, tornando-a menos confiável. Por padrão, o squid não é configurado para atuar como um servidor web, assim não precisará se preocupar com isto. Note que se quiser usar esta característica, tenha certeza que é realmente necessária. Para encontrar mais informações sobre o modo acelerador do Squid, veja Squid User's Guide #Chapter9.


5.3 Tornando o FTP mais seguro

Se realmente precisar usar o FTP (sem transportá-lo com sslwrap ou dentro de um tunel SSL ou SSH), você deverá fazer um chroot dentro do diretório de usuários do ftp, assim o usuário será incapaz de ver qualquer coisa que não seja seu próprio diretório. Caso contrário, ele poderá atravessar seu sistema de arquivos raíz como se tivesse uma conta shell. Você poderá adicionar a seguinte linha no seu arquivo proftpd.conf na sua seção global para ativar esta característica chroot:

     DefaultRoot ~

Reinicie o proftpd executando /etc/init.d/proftpd restart e verifique se agora pode escapar do seu diretório de usuário.

Para prevenir ataques DoS usando ../../.., adicione a seguinte linha no seu arquivo /etc/proftpd.conf: DenyFilter \*.*/

Lembre-se sempre que o FTP envia o login e senhas de autenticação em texto plano (isto não é um problema se estiver oferecendo acesso a serviços públicos. Entretanto existem alternativas melhores no Debian para isto, como o sftp (fornecido pelo pacote ssh). Também existem implementações livres do ssh para outros sistemas operacionais, por exemplo: putty e o cygwin.

No entanto, se você ainda mantém um servidor FTP enquanto disponibiliza o acesso através do SSH você deve encontrar um problema típico. Usuários acessando servidores FTP anônimos dentro de sistemas protegidos com o SSH devem tentar efetuar o login no FTP server. Enquanto o acesso será recusado, as senhas nunca serão enviadas na rede de forma desprotegida. Para evitar isto, o desenvolvedor TJ Sauders do ProFTPd , criou um patch que evita que os usuários utilizem um servidor FTP anônimo com uma conta válida do ssh. Mais informações e o patch estão disponíveis em: ProFTPD Patches. Este patch também foi reportado para o Debian, veja Bug #145669.


5.4 Tornando o acesso ao sistema X Window mais seguro

Hoje em dia, terminais do X são usados por mais e mais empresas onde é necessário para várias estações de trabalho. Isto pode ser perigoso, porque você precisa permitir o servidor de arquivos a se conectar aos clientes (a partir do ponto de vista do servidor X, o X altera a definição de cliente e servidor). Se você seguir a (péssima) sugestão de muitas documentações você digitará xhost + em sua máquina. Isto permitirá qualquer cliente do X a se conectar em seu sistema. Para ter um pouco mais de segurança, você deverá usar o comando xhost +hostname ao invés de somente permitir acessos através de máquinas específicas.

Uma solução muito mais segura, no entanto, é usar o ssh para fazer o túnel do X e criptografia para toda a seção. Isto é feito automaticamente quando você faz um ssh para a outra máquina. Para isto funcionar, você terá que configurar ambos o cliente ssh e o servidor ssh. No cliente ssh, a opção ForwardX11 deverá estar ajustada para yes no arquivo /etc/ssh/ssh_config. No servidor ssh, a opção X11Forwarding deverá estar ajustada para yes no arquivo /etc/ssh/sshd_config e o pacote xbase-clients deverá estar instalado, pois o servidor ssh utiliza o /usr/X11R6/bin/xauth quando está configurando uma tela de pseudo terminal do X. Nos tempos do SSH, agora você deverá deixar de usar o controle de acesso baseado em xhost completamente.

Para melhor segurança, você não precisará permitir o acesso ao X a partir de outras máquinas, isto é feito desativando o servidor na porta 6000 simplesmente digitando:

     $ startx -- -nolisten tcp

Este é o comportamento padrão do Xfree 4.1.0 (o Xserver fornecido no Debian 3.0). Se estiver executando o Xfree 3.3.6 (i.e. você tem o Debian 2.2 instalada) você poderá editar o arquivo /etc/X11/xinit/xserverrcc e fazer a alteração nestas seguintes linhas:

     #!/bin/sh
     exec /usr/bin/X11/X -dpi 100 -nolisten tcp

Se estiver usando o conjunto do XDM altere no arquivo /etc/X11/xdm/Xservers para: :0 local /usr/bin/X11/X vt7 -dpi 100 -nolisten tcp. Se estiver usando o Gdm tenha certeza que a opção -nolisten tcp está definida no arquivo /etc/gdm/gdm.conf (que é o padrão no Debian) tal como esta:

     [server-Standard]
     name=Standard Server
     command=/usr/bin/X11/X -nolisten tcp

Você também poderá configurar o timeout padrão para o travamento do xscreensaver. Até mesmo se o usuário substituir este valor, você poderá editar o arquivo /etc/X11/app-defaults/XScreenSaver e alterar a linha:

     *lock:                  False

(que é padrão no Debian) para:

     *lock:                  True

FIXME: adicionar informações sobre como desativar as proteções de tela que mostra o desktop do usuário (que pode conter informações sensíveis).

Leia mais sobre a segurança em servidores X Window em XWindow-User-HOWTO (/usr/share/doc/HOWTO/en-txt/XWindow-User-HOWTO.txt.gz).

FIXME: Adicionar informações sobre a discussão na debian-security sobre como alterar os arquivos de configuração no servidor XFree 3.3.6 para fazer isto.


5.4.1 Verifique seu gerenciador de tela

Se somente quiser ter um gerenciador de tela instalado para uso local (tendo um lindo login gráfico) tenha certeza que tudo que estiver relacionado com o XDMCP (X Display Manager Control Protocol) está desativado. No XDM você poderá fazer isto através da linha em /etc/X11/xdm/xdm-config:

     DisplayManager.requestPort:     0

Normalmente, todos os gerenciadores de tela estão configurados para não iniciar serviços do XDMCP por padrão no Debian.


5.5 Tornando o servidor de impressão mais seguro (sobre o lpd e lprng)

Imagine, você chegando ao trabalho e a impressora jogando fora uma quantidade impressionante de papel porque alguém esta fazendo um DoS em seu daemon de impressão. Desagradável, não é?

Em qualquer arquitetura de impressão do unix, deverá existir uma forma de enviar os dados do cliente para o servidor de impressão. No tradicional lpr e lp, os comandos do cliente copiam ou fazem um link simbólico de dados no diretório de spool (este é o motivo porque estes programas normalmente são SUID ou SGID).

Para evitar quaisquer anormalidade, você deverá manter o seu servidor de impressão especialmente seguro. Isto significa que precisa configurar seu serviço de impressão de forma que só permita conexões de um conjunto de máquinas confiáveis. Para fazer isto, adicione os servidores que deseja permitir a impressão em seu arquivo /etc/hosts.lpd.

No entanto, até mesmo se fizer isto, o lpr aceitará conexões de entrada na porta 515 de qualquer interface. Você deverá considerar fazer um firewall das conexões de redes/hosts que não tenham permissão de impressão (o daemon lpr não tem a possibilidade de aceitar conexões em somente um determinado endereço IP).

O Lprng deverá ser o preferido em cima do lpr pois ele pode ser configurado para fazer controle de acesso por IP. E você poderá especificar qual interface escutará por conexões (embora algumas vezes pareça um pouco estranho).

Se utilizar uma impressora em seu sistema, mas somente localmente, você não desejará compartilhar este serviço através de uma rede. Você poderá considerar o uso de outros sistemas de impressão, tal como o fornecido pelo pacote cups ou pelo PDQ que é baseado em permissões do usuário no dispositivo /dev/lp0.

No cups, os dados de impressão são transferidos ao servidores via protocolo http. Isto significa que o programa cliente não precisa de qualquer privilégio especial, mas requer que o servidor escute em uma porta, em algum lugar.

No entanto, se quiser usar o cups, mas somente localmente, você poderá configura-lo para escutar na interface loopback alterando o arquivo de configuração /etc/cups/cupsd.conf:

     Listen 127.0.0.1:631

Existem muitas outras opções de segurança como permitir ou bloquear redes e máquinas neste arquivo de configuração. No entanto, se você não precisar delas, será melhor que limite simplesmente a porta onde o programa espera por conexões. O Cups também serve documentações através da porta HTTP. Se não quiser revelar informações úteis em potencial para invasores externos também adicione:

     <Location />
       Order Deny,Allow
        Deny From All
         Allow From 127.0.0.1
     </Locationi>

Este arquivo de configuração pode ser modificado para adicionar algumas outras características incluindo certificados SSL/TLS e criptografia. Os manuais estão disponíveis em http://localhost:631/ ou em cups.org.

FIXME: Adicionar mais conteúdo (o artigo em Amateur Fortress Building fornecendo visões mais interessantes).

FIXME: Verificar se o PDG está disponível no Debian, e se estiver, sugerir como sistema de impressão preferido.

FIXME: Verificar se o Farmer/Wietse possui um substituto para daemon de impressão e se está disponível no Debian.


5.6 Tornando o serviço de e-mails seguro

Se seu servidor não for um servidor de mensagens, e realmente não precisa ter um programa esperando por conexões de entradas, mas deseja que as mensagens locais sejam entregues, por exemplo, para recebimento de mensagens do usuário root de qualquer alerta de segurança que tenha no local.

Se tiver o exim você não precisará do daemon funcionando para fazer isto, pois o pacote padrão do cron esvazia a fila de mensagens. Veja Desabilitando daemons de serviço, Seção 3.6.1 para saber como fazer isto.


5.6.1 Configurando um programa de e-mails nulo

Você pode querer ter um daemon de mensagens locais assim ele poderá repassar os e-mails enviados localmente para outro sistema. Isto é comum quando você tem que administrar um número de máquinas e não quer conectar a cada uma delas para ler as mensagens enviadas localmente. Assim como todos os logs de cada sistema individual podem ser centralizados usando um servidor de logs central, as mensagens podem ser enviadas para um servidor de mensagens central.

Tal sistema somente-repasse deverá ser configurado adequadamente para fazer isto. O daemon poderá, também, ser configurado para somente esperar por conexões no endereço de loopback.

FIXME: Isto deverá ser atualizado para o exim4, que é o MTA padrão da sarge e distribuições mais atuais (e espera por conexões somente em localhost na configuração padrão mínima)

Para fazer isto em um sistema Debian 3.0 usando o pacote exim, você terá que remover o daemon smtp do inetd:

     $ update-inetd --disable smtp

e configurar o daemon de mensagens para somente esperar por conexões na interface loopback. No exim (o MTA padrão) você poderá fazer isto editando o arquivo de configuração /etc/exim.conf e adicionando a seguinte linha:

     local_interfaces = "127.0.0.1"

Reinicie ambos os daemons (inetd e exim) e você terá o exim esperando por conexões somente no soquete 127.0.0.1:25. Seja cauteloso e desative primeiro o inetd, caso contrário, o exim não iniciará pois o daemon do inetd já está esperando por conexões de entrada.

Para o postfix, edite o arquivo /etc/postfix/main.conf:

     inet_interfaces = localhost

Se quiser somente mensagens locais, este método é melhor que utilizar o método tcp wrappers no daemon de mensagens ou adicionar regras de firewall para que ninguém acesse-o. No entanto, se precisar que ele escute em outras interfaces, você deverá considerar carrega-lo a partir do inetd e adicionar um tcp wrapper, assim as conexões de entradas são verificadas nos arquivos /etc/hosts.allow e /etc/hosts.deny. Também, você deverá estar atento sobre acessos não autorizados sendo tentados sobre o seu daemon de mensagens, se configurar adequadamente o log de mensagens do seu sistema para qualquer um dos métodos acima.

Em qualquer caso, para rejeitar tentativas de repasse de mensagens a nível SMTP, você deverá alterar o arquivo /etc/exim/exim.conf para incluir:

     receiver_verify = true

Até mesmo se seu servidor de e-mails não repassar a mensagem, este tipo de configuração é necessário para o teste de relay em http://www.abuse.net/relay.html para determinar que seu servidor não é capaz de repassar mensagens.

No entanto, se desejar uma configuração somente de leitura, você poderá considerar a alteração do daemon de mensagens para programas que podem somente ser configurados para redirecionar as mensagens para servidores de mensagens remotas. O Debian atualmente oferece o pacote ssmtp e o nullmailer para este propósito. Em qualquer caso, você deverá avaliar por si mesmo quaisquer dos agentes de transporte de mensagens [27] fornecido com o Debian. Veja que programa atende melhor aos propósitos do sistema.


5.6.2 Fornecendo acesso seguro às caixas de mensagens

Se quiser oferecer acesso remoto às caixas de mensagens, existe um número de daemons POP3 e IMAP disponíveis [28] . No entanto, se você oferecer acesso a IMAP, note que ele é um protocolo de acesso a arquivos, ele pode se tornar equivalente a um acesso shell porque os usuários podem ser capazes de obter qualquer arquivo através dele.

Tente, por exemplo, configurar como seu caminho para a inbox{servidor.com}/etc/passwd, se ele abrir o arquivo com sucesso seu daemon IMAP não está corretamente configurado para prevenir este tipo de acesso.

Dos servidores de IMAP existentes no Debian, o servidor cyrus (do pacote cyrus-imapd) contorna isto tendo todos os acessos sendo em um banco de dados mantido em uma parte restrita do sistema de arquivos. Também o uw-imapd (ou instale o uw-imapd ou melhor, se seus clientes IMAP o suportam, uw-imapd-ssl) poderá ser configurado para fazer o chroot do diretório dos usuários de mensagens mas isto não é ativado por padrão. A documentação fornecida oferece mais informações sober como configura-lo.

Também, você pode tentar executar um servidor IMAP que não precisa de usuários válidos sendo criados no sistema local (que também oferece acesso a shell). Ambos os pacotes courier-imap (para IMAP) e courier-pop teapop (para o POP3) e o cyrus-imapd (para ambos POP3 e IMAP) fornecem servidores com métodos de autenticação que não dependem de contas locais de usuários. O cyrus pode usar qualquer método de autenticação que possa ser configurado através do PAM tal como o teapop pode usar bancos de dados (tal como o postgresql e o mysql) para autenticação do usuário.

FIXME: Verifique: uw-imapd também precisa ser configurado com autenticação do usuário através de PAM...


5.6.3 Recebendo mensagens de forma segura

A leitura/recebimento de mensagens é o protocolo de texto puro mais comum. Se usar ou POP3 ou IMAP para obter suas mensagens, você enviará sua senha em texto plano através da rede, assim praticamente qualquer um poderá ler suas mensagens de agora em diante. Ao invés disto, utiliza-se SSL (Secure Sockets Layer) para receber seus e-mails. A outra alternativa é utilizar o ssh, se tiver uma conta shell na máquina que atua como seu servidor POP ou IMAP. Aqui está um arquivo de configuração fetchmailrc básico para demonstrar isto:

     poll my-imap-mailserver.org via "localhost"
       with proto IMAP port 1236
           user "ref" there with password "hackme" is alex here warnings 3600
         folders
           .Mail/debian
         preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref
          my-imap-mailserver.org sleep 15 </dev/null > /dev/null'

A linha preconnect é importante. Ela executa uma seção ssh e cria o túnel necessário, que automaticamente redireciona conexões para localhost da porta 1236 para o servidor de mensagens IMAP, mas de forma criptografada. Outra possibilidade será usar o fetchmail com características ssl.

Se deseja fornecer serviços de mensagens criptografadas como POP e IMAP,apt-get install stunnel e inicie seus daemons da seguinte forma:

     stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd

Este comando direciona as conexões do daemon fornecido (-l) para a porta (-d) e utiliza o certificado ssl especificado (-p).


5.7 Tornando o BIND mais seguro

Existem diferentes métodos que podem ser usados para deixar o daemon de serviços de Domínio mais seguro, que são parecidos com os mostrados considerados quando tornamos qualquer determinado serviço mais seguro:


5.7.1 Configuração do Bind para evitar má utilização

Você deverá restringir algumas das informações que são servidas pelo BIND para clientes externos, assim não poderão ser usadas para obter informações sobre sua empresa que não deseja dar. Isto inclui adicionar as seguintes opções: allow-transfer, allow-query, allow-recursion e version. Você pode ou limitar esta seção global (assim aplicando a todas as zonas que são servidas) ou por zona. Esta informação está incluída no pacote bind-doc, leia mais sobre isto em /usr/share/doc/bind/html/index.html assim que o pacote for instalado.

Imagine que seu servidor (um servidor básico contendo múltiplos endereços) está conectado à Internet e à sua rede interna (seu endereço IP é 192.168.1.2), você não vai querer oferecer qualquer serviço para os computadores. Você poderá restringir o bind incluindo o seguinte no /etc/bind/named.conf:

     options {
     	    allow-query { 192.168.1/24; } ;
     	    allow-transfer { none; } ; 
     	    allow-recursion { 192.168.1/24; } ;
     	    listen-on { 192.168.1.2; } ;
     	    forward { only; } ;
     	    forwarders { A.B.C.D; } ;
     };

A opção listen-on faz o BIND ser executado somente na interface que tem o endereço interno, mas, até mesmo se esta interface for a mesma que te conecta a internet (caso estiver usando NAT, por exemplo), as requisições serão aceitas somente se estiverem vindo de suas máquinas internas. Se o sistema tiver múltiplas interfaces e a opção listen-on não estiver presente, somente usuários internos poderão fazer requisições, mas, como a porta está acessível para possíveis invasores externos, eles podem tentar travar (ou tentar realizar ataques de estouro de buffer) no servidor DNS. Você poderia até fazê-lo escutar somente em 127.0.0.1, se não estiver oferecendo o serviço de DNS em qualquer outro sistema além do seu.

O registro version.bind na classe chaos contém a versão do processo do bind atualmente em execução. Esta informação é freqüentemente usada por scaneadores automáticos e individualmente por pessoas maliciosas que desejam determinar se o bind é vulnerável a um ataque específico. Oferecendo informações falsas ou não fornecendo informações ao registro version.bind, diminui a probabilidade que o servidor seja atacado baseado na versão publicada. Para fornecer sua própria versão, use a diretiva version da seguinte forma:

      options { ... várias opções aqui ...
     version "Não disponível."; };

A alteração do registro version.bind não oferece proteção atualmente contra ataques, mas pode ser considerado útil para a segurança.

Um arquivo simples de configuração named.conf pode ser o seguinte:

     acl internal {
             127.0.0.1/32;           // localhost
             10.0.0.0/8;             // interna
             aa.bb.cc.dd;            // IP da eth0
     };
     
     acl friendly {
             ee.ff.gg.hh;            // DNS escravo
             aa.bb.cc.dd;            // IP da eth0
             127.0.0.1/32;           // localhost
             10.0.0.0/8;             // interna
     };
     
     options {
             directory "/var/cache/bind";
             allow-query { internal; };
             allow-recursion { internal; };
             allow-transfer { none; };
     };
     // A partir daqui, a zona mysite.bogus é 
     // basicamente uma versão não modificada do padrão do Debian
     logging {
             category lame-servers { null; };
             category cname { null; };   
     };
     
     zone "." {
             type hint;
             file "/etc/bind/db.root";
     };
     
     zone "localhost" {
             type master;
             file "/etc/bind/db.local";
     };
     
     zone "127.in-addr.arpa" {
             type master;
             file "/etc/bind/db.127";
     };
     
     zone "0.in-addr.arpa" {
             type master;
             file "/etc/bind/db.0";
     };
     
     zone "255.in-addr.arpa" {
             type master;
             file "/etc/bind/db.255";
     };
     
     // zones I added myself
     zone "mysite.bogus" {
             type master;
             file "/etc/bind/named.mysite";
             allow-query { any; };
             allow-transfer { friendly; };
     };

Por favor (novamente) verifique o Sistema de Tratamento de Falhas a respeito do bind, especificamente Bug #94760 (relacionado com ACLs em transferência de zonas). Sinta-se livre para contribuir para relatar falhas se achar que podem adicionar informações úteis.


5.7.2 Alterando o usuário do BIND

Com relação a limitação de privilégios do BIND, você deverá estar ciente que se um usuário não root executa o BIND, então o BIND não detectará novas interfaces automaticamente, por exemplo, se colocar uma placa PCMCIA no notebook. Verifique o arquivo README.Debian na documentação do named veja o diretório (/usr/share/doc/bind/README.Debian) para mais informações sobre este assunto. Ocorreram muitos problemas de segurança recentes relacionados com o BIND, assim a alteração do usuário é mais útil quando possível. Nós detalharemos os passos para fazer isto, no entanto, se quiser fazer isto de uma forma automática, tente o script fornecido em Exemplo de script para alterar a instalação padrão do Bind., Apêndice E.

Para executar o BIND sob um usuário diferente, primeiro crie um usuário separado e um grupo (não é uma boa idéia usar o nobody ou nogroup para cada serviço que não estiver sendo executado como root). Neste exemplo, o usuário e grupo named serão usados. Você poderá fazer isto da seguinte forma:

     addgroup named
     adduser --system --home /home/named --no-create-home --ingroup named \
           --disabled-password --disabled-login named

Note que o usuário named será bastante restringido. Se você quiser, por alguma razão, ter uma configuração menos restrita, utilize:

     adduser --system --ingroup named named

Agora, edite o arquivo /etc/init.d/bind com seu editor favorito e altere a linha que começa com

     start-stop-daemon --start

para[29]

     start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named

Altere as permissões dos arquivo que são usados pelo Bind, incluindo /etc/bind/rndc.key:

     -rw-r-----    1 root     named          77 Jan  4 01:02 rndc.key

e onde o bind cria seu arquivo de pid, usando, por exemplo, /var/run/named ao invés de /var/run:

     $ mkdir /var/run/named
     $ chown named.named /var/run/named
     $ vi /etc/named.conf
     [ ... atualize o arquivo de configuração para sua nova localização ...]
     options { ...
             pid-file "/var/run/named/named.pid";
     };
     [ ... ]

Também, para evitar a execução de tudo como usuário root, altere a linha reload comentando-a:

     reload)
            /usr/sbin/ndc reload

E altere para:

     reload)
             $0 stop
             sleep 1
             $0 start

Nota: Dependendo de sua versão do Debian, você deverá também alterar a linha restart. Isto foi corrigido na versão do Bind do Debian 1:8.3.1-2.

Tudo que precisa fazer agora é reiniciar o bind via '/etc/init.d/bind restart', e então procurar em seu syslog pelas seguintes duas linhas, como estas:

     Sep  4 15:11:08 nexus named[13439]: group = named
     Sep  4 15:11:08 nexus named[13439]: user = named

Voilá! Seu named agora não é executado como root. Se desejar ler mais informações sobre porque o BIND não pode ser executado por um usuário não-root em sistemas Debian, verifique o sistema de tratamento de falhas, especificamente Bug #50013: bind should not run as root e Bug #132582: Default install is potentially insecure, Bug #53550, Bug #128120, e Bug #128120. Sinta-se livre para contribuir para os relatórios de falhas se achar que pode adicionar informações úteis.


5.7.3 Executando o servidor de nomes em uma jaula chroot

Para obter o máximo de segurança no BIND, agora construa uma jaula chroot (veja Paranóia geral do chroot e suid, Seção 5.10) em torno do seu daemon. Existe um método fácil de se fazer isto: a opção -t (veja a named(8) página de manual ou a página 100 do Documentação do Bind's 9 (PDF)). Isto instruirá o Bind a fazer uma jaula de si mesmo em um diretório especificado sem a necessidade de configurar uma jaula chroot e se preocupar com as bibliotecas dinâmicas. Os únicos arquivos que precisam estar na jaula são:

     dev/null
     etc/bind/       - deverá ter o named.conf e todas as zonas do servidor
     sbin/named-xfer - se fizer transferências de nomes
     var/run/named/  - deverá ter a pid e o nome do servidor de cache (se tiver)
                       este diretório precisa ter permissões de gravação para o
                       usuário named.
     var/log/named   - se configurar o log para um arquivo, este precisa ter permissões
                       de gravação para o usuário named
     dev/log         - o syslogd deverá estar escutando aqui caso o named estiver
                       configurado para realizar logs através dele.

Para seu daemon do Bind funcionar adequadamente, ele precisará de permissões nos arquivos do named. Esta é uma tarefa simples, pois os arquivos de configuração estão sempre localizados em /etc/named/. Tenha em mente que ele somente precisa de acesso de leitura aos arquivos de zonas, a não ser que seja um DNS secundário ou servidor de cache de nomes. Se este é seu caso, você terá que dar permissões completas para as zonas necessárias (assim as zonas transferidas do servidor principal funcionarão).

Adicionalmente, mais detalhes sobre o Bind e chroot pode ser encontrados no Chroot-BIND-HOWTO (relacionado com o Bind 9) e Chroot-BIND8-HOWTO (relacionado com o Bind 8). Este mesmo documento deverá estar disponível através da instalação do doc-linux-text (versão texto) ou doc-linux-html (versão html). Outro documento útil é http://web.archive.org/web/20011024064030/http://www.psionic.com/papers/dns/dns-linux.

Se estiver configurando uma jaula completa do chroot (i.e. não somente -t) para o Bind 8.2.3 no Debian (potato), tenha certeza de possuir os seguintes arquivos nela:

     dev/log - o syslogd deverá estar escutando aqui
     dev/null
     etc/bind/named.conf 
     etc/localtime
     etc/group - com somente uma linha simples: "named:x:GID:"
     etc/ld.so.cache - gerado com o ldconfig   
     lib/ld-2.1.3.so
     lib/libc-2.1.3.so
     lib/ld-linux.so.2 - link simbólico para ld-2.1.3.so  
     lib/libc.so.6 - link simbólico para libc-2.1.3.so
     sbin/ldconfig - pode ser apagado após configurar a jaula chroot
     sbin/named-xfer - se fizer transferências de nomes
     var/run/

Também modifique o syslogd para escutar no $CHROOT/dev/log assim o servidor de nomes poderá gravar entradas do syslog no log local do sistema.

Se deseja evitar problemas com bibliotecas dinâmicas, você poderá compilar o binário estaticamente. Você poderá usar o apt-get para fazer isto, com a opção source. Ele pode até mesmo baixar os pacotes que precisa para compila-los adequadamente. Você deverá fazer algo similar a isto:

     $ apt-get --download-only source bind build-dep bind
     $ cd bind-8.2.5-2
     (edite o Makefile.in assim CFLAGS incluirá a opção '-static'
     antes da definição @CFLAGS@ substituída pelo autoconf)
     $ dpkg-buildpackage -rfakeroot
     $ cd ..
     $ dpkg  -i bind-8.2.5-2*deb

Após a instalação, você precisará mover os arquivos para a jaula chroot [30] você poderá manter os scripts do init.d em /etc/init.d assim o sistema irá iniciar automaticamente o servidor de nomes, mas edite-os para adicionar --chroot /location_of_chroot nas chamadas para start-stop-daemon nestes scripts.

Para mais informações sobre como configurar jaulas chroot veja Paranóia geral do chroot e suid, Seção 5.10.

FIXME, merge info from http://people.debian.org/~pzn/howto/chroot-bind.sh.txt, http://www.cryptio.net/~ferlatte/config/ (Debian-specific), http://web.archive.org/web/20021216104548/http://www.psionic.com/papers/whitep01.html and http://csrc.nist.gov/fasp/FASPDocs/NISTSecuringDNS.htm.


5.8 Tornando o Apache mais seguro

FIXME: Adicionar conteúdo: os módulos fornecidos com a instalação padrão do Apache (sob /usr/lib/apache/X.X/mod_*) e módulos que podem ser instalados separadamente pelos pacotes libapache-mod-XXX.

Você poderá limitar o acesso ao servidor Apache se você somente deseja usar ele internamente (para propósitos de testes, para acessar os arquivos do doc-central, etc..) e não deseja que pessoas de fora o acessem. Para fazer isto, use as diretivas Listen ou BindAddress no /etc/apache/http.conf.

Using Listen:

     Listen 127.0.0.1:80

Using BindAddress:

     BindAddress 127.0.0.1

Então reinicie o apache com /etc/init.d/apache restart e você verá que ele somente esperará por requisições na interface loopback.

Em qualquer caso, se não estiver usando todas as funcionalidades fornecidas pelo Apache, você poderá querer dar uma olhada em outros servidores web fornecidos no Debian, como o dhttpd.

A Documentação do Apache fornece informações relacionadas com medidas de segurança a serem tomadas no servidor web Apache (estes mesmos passos são oferecidos no Debian através do pacote apache-doc).

Mais informações sobre restrições do Apache configurando uma jaula chroot são mostradas em Ambiente chroot para Apache, Apêndice H.


5.8.1 Proibindo a publicação de conteúdo dos usuários

A instalação padrão do Apache no Debian permite que usuários publiquem conteúdo sob o diretório $HOME/public_html. Este conteúdo pode ser pego remotamente usando uma URL tal como: http://your_apache_server/~user.

Se não quiser permitir isto, você deverá alterar o arquivo de configuração /etc/apache/http.conf comentando a linha:

     LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so

Mas se um módulo foi incluído estaticamente (você poderá checar isto executando apache -l) você deverá utilizar a seguinte técnica:

     Userdir disabled

Nota: A palavra chave disabled está somente disponível nas versões do Apache 1.3 e superior. Se estiver usando versões antigas do apache, você deverá alterar o arquivo de configuração e adicionar:

     <Directory /home/*/public_html>
         AllowOverride None
         Order deny,allow
         Deny from all
     </Directory>

Um invasor ainda pode usar enumeração de usuário, pois a resposta do servidor será um 403 Permissão negada e não um 404 Não disponível.


5.8.2 Permissões de arquivos de log

Os arquivos de log do Apache, desde a 1.3.22-1, tem como dono o usuário 'root' e grupo 'adm' com permissões 640, estas permissões são alteradas após o rotacionamento de logs. Um intruso que acessou o sistema através do servidor web não será capaz (sem escalação de privilégios) de remover entradas antigas do log.


5.8.3 Arquivos da Web Publicados

Os arquivos do Apache estão localizados sob /var/www. Apenas após a instalação o arquivo de configuração padrão fornecerá algumas informações sobre o sistema (principalmente que é um sistema Debian executando o Apache). As páginas web padrões tem como dono o usuário root e grupo root por padrão, enquanto o processo do Apache é executado como o usuário e grupo www-data. Isto torna difícil para invasores que comprometem o sistema através do servidor web, desfigurarem o site. Você deverá, é claro, substituir as páginas padrões por suas próprias (que fornecem informações que não deseja mostrar para pessoas de fora).


5.9 Tornando o finger mais seguro

Se desejar executar o serviço finger, primeiro pergunte a você mesmo porque o deseja. Se precisar dele, você verá que o Debian fornece vários daemons de finger (saída do comando apt-cache search fingerd):

O ffingerd é o daemon de finger recomendado se estiver usando-o em serviços públicos. Em qualquer caso, você é encorajado, quando estiver configurando através do inetd, xinetd ou tcpserver, a: limitar o número de processos que podem ser executados ao mesmo tempo, limitando o acesso ao daemon de finger de um número determinado de máquinas (usando o tcp wrappers) e escutando somente nas interfaces onde deve operar.


5.10 Paranóia geral do chroot e suid

O chroot é uma das mais poderosas possibilidades para restringir um daemon, ou um usuário ou outro serviço. Apenas imagine uma jaula em torno de seu alvo, onde o alvo não pode escapar dela (normalmente, mas existem várias condições que permitam que um escape de tal jaula). Se não confia em um usuário ou em um serviço, você poderá criar um ambiente root modificado para ele. Isto poderá usar algum espaço do disco para copiar todos os executáveis requeridos, assim como bibliotecas, na jaula. Mas então, até mesmo se o usuário fizer algo malicioso, o escopo do ano é limitado a jaula.

Muitos serviços executados como daemons poderão se beneficiar deste tipo de técnica. Os daemons que você instala no Debian não virão, no entanto, dentro de chroot [31] por padrão.

Isto inclui: servidores de nomes (tal como o bind), servidores web (tal como o apache), servidores de mensagens (tal como o sendmail e servidores ftp (tal como o wu-ftpd). Provavelmente basta dizer que a complexibilidade do BIND é a razão de que ele foi exposto a vários ataques nos últimos anos (see Tornando o BIND mais seguro, Seção 5.7).

No entanto, o Debian não oferece muitos programas que podem ajuda-lo a configurar um ambiente chroot. Veja Criando automaticamente ambientes chroots, Seção 5.10.1.

De qualquer maneira, se executar qualquer serviço em seu sistema, considere torná-lo mais seguro o possível. Isto inclui: revogar os privilégios de root, executá-lo em um ambiente seguro (tal como uma jaula chroot) ou substituí-lo por um equivalente mais seguro.

No entanto, já esteja avisado que uma jaula chroot pode ser quebrada se o usuário dentro dela for o superusuário. Assim você deverá estar certo que o serviço está sendo executado por um usuário não privilegiado. Limitando seu ambiente, estará limitando os arquivos lidos/executáveis que o serviço poderá acessar, assim, limitando as possibilidade de uma escalação privilegiada usar as vulnerabilidade de segurança locais do sistema. Até mesmo nesta situação, você não poderá ter certeza completa de que lá não existe métodos para um invasor inteligente quebrar a jaula. Usando somente programas de servidor que tem a reputação de serem seguidos é uma boa medida adicional. Até mesmo minúsculos furos como arquivos abertos podem serem usados por um invasor com conhecimentos para quebrar o sistema. Após tudo isto, o chroot não foi designado como uma ferramenta de segurança, mas como uma ferramenta de testes.


5.10.1 Criando automaticamente ambientes chroots

Existem diversos programas que fazem automaticamente o chroot de servidores e serviços. O Debian atualmente (aceita em maio de 2002) fornece o Wietse Venema's chrootuid no pacote chrootuid, assim como o pacote compartment e makejail. Estes programas podem criar um ambiente restritivo para a execução de qualquer programa (chrootuid lhe permite até executa-lo como um usuário restrito).

Algumas destas ferramentas podem ser usadas para criar facilmente um ambiente chroot. O programa makejail por exemplo, pode criar e atualizar uma jaula chroot com arquivos de configuração pequenos (ele fornece modelos de configuração para o bind, apache, postgresql e mysql). Ele tenta adivinhar e instalar na jaula todos os arquivos requeridos pelo daemon usando o strace, stat e dependências de pacotes do Debian. Mais informações podem ser obtidas em http://www.floc.net/makejail/. O Jailer é uma ferramenta similar que pode ser obtida de http://www.balabit.hu/downloads/jailer/ e também está disponível como um pacote do Debian GNU.


5.11 Paranóia geral sobre senhas em texto puro

Você deverá tentar evitar qualquer serviço de rede que envia e receba senhas em texto puro através da rede, como o FTP/Telnet/NIS/RPC. O autor recomenda usar o ssh ao invés de telnet e ftp para qualquer um.

Tenha em mente que migrando do telnet para o ssh, mas continuando a usar outros protocolos de texto puro não aumenta sua segurança de qualquer modo! O melhor é remover o ftp, telnet, pop, imap, http e substituí-los por seus respectivos serviços criptografados. Você deverá considerar mover estes para suas versões SSL, ftp-ssl, telnet-ssl, pop-ssl, https ...

A maioria dos listados acima se aplicam para cada sistema Unix (você os encontrará se ler qualquer documento relacionado a tornar um sistema Linux (e outros tipos e Unix) mais seguro.


5.12 Desativando o NIS

Você não deverá usar o NIS, o Serviço de Informações de Rede, se possível, pois ele permite o compartilhamento de senha. Isto pode ser altamente inseguro se sua configuração for corrompida.

Se precisar de compartilhamento de senhas entre máquinas, você deverá considerar a adoção de outras alternativas. Por exemplo, a configuração de um servidor LDAP e o PAM para contactar o servidor LDAP para autenticação dos usuários. Você poderá encontrar uma configuração detalhada na LDAP-HOWTO (/usr/share/doc/HOWTO/en-txt/LDAP-HOWTO.txt.gz).

Mais detalhes sobre a segurança em NIS podem ser encontradas em NIS-HOWTO (/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz).

FIXME (jfs): Adicionar detalhes de como configurar isto no Debian


5.13 Tornando serviços RPC mais seguros

Você deverá desativar RPC se não precisar dele.

Chamadas de Procedimentos Remotos (RPC) é um protocolo que os programas podem usar para solicitar serviços de outros programas localizados em diferentes computadores. O serviço portmap controla os serviços RPC mapeando números de programas RPC em números de portas DARPA; ele deverá estar sendo executado para executar chamadas RPC.

Serviços baseados em RPC tem tido um mal histórico de falhas de segurança, no entanto, o portmapper por si não (mas ainda fornece informações úteis ao atacante remoto). Note que alguns dos ataques DDoS (negação de serviço distribuídos) usam exploits rpc para entrar no sistema e atuar como o assim chamado agente/manipulador.

Você somente precisará do RPC se estiver usando um serviço baseado em RPC. Os serviços mais comuns baseados em RPC são o NFS (Network File System) e NIS (Network Information System). Veja a seção anterior para mais informações sobre o NIS. O Monitor de alterações de Arquivos (FAM) fornecido pelo pacote fam é também um serviço RPC, e assim depende do pacote portmap.

Os serviços NFS são muito importante em algumas redes. Se este for o caso para você, então terá que encontrar um balanceamento de segurança e usabilidade para sua rede. (Você poderá ler mais sobre a segurança em NFS no NFS-HOWTO (/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz).)


5.13.1 Desativando completamente os serviços RPC

A desativação do portmap é bem simples. Existem diversos diferentes métodos. O mais simples no sistema Debian 3.0 e mais novos é desistalar o pacote portmap. Se estiver executando uma versão antiga do Debian, terá que desativar o serviço como visto em Desabilitando daemons de serviço, Seção 3.6.1, porque o programa é parte do pacote net-base (que não pode ser removido sem quebrar o sistema).

Isto de fato remove cada link relacionado ao portmap em /etc/rc${runlevel}.d/, que é algo que pode fazer manualmente. Outra possibilidade é executar um chmod 644 /etc/init.d/portmap, mas isto mostrará uma mensagem de erro durante a inicialização. Você também poderá comentar a parte start-stop-daemon no script /etc/init.d/portmap.


5.13.2 Limitando o acesso a serviços RPC

Infelizmente em alguns casos a remoção dos serviços RPC não é uma opção. Alguns serviços de desktop locais (notavelmente o fam da SGI) são baseados em RPC e assim precisam de um portmapper local. Isto significa que sob algumas situações, os usuários que estiverem instalando um ambiente de desktop (como o GNOME) instalarão também o portmapper.

Existem diversas formas de limitar o acesso ao portmapper e aos serviços de RPC:


5.14 Adicionando capacidades de firewall

O sistema Debian GNU/Linux tem as capacidades embutidas fornecidas pelo kernel do GNU/Linux. Isto significa que se você instalar o sistema potato (Debian 2.2), que vem com o kernel padrão 2.2, você terá as capacidades do firewall ipchains no kernel, você precisará ter o pacote ipchains, que deverá, devido a sua prioridade, já estar instalado. Se estiver instalando o sistema woody (Debian 3.0), que vem com o kernel padrão 2.4, você terá o firewall iptables (netfilter) disponível. A principal diferença entre o ipchains e iptables é que o últimos é baseado em inspeção de estado de pacotes que lhe oferece configurações mais seguras (e fáceis de construir) de filtragem.


5.14.1 Fazendo um firewall no sistema local

Você poderá usar regras de firewall como uma forma de restringir o acesso a seu sistema local e, até mesmo, limitar comunicações feitas através dele. As regras de firewall também podem ser usadas para proteger processos que podem não estar corretamente configurados, não fornecendo serviços para algumas redes, endereços IP, etc...

No entanto, este passo é mostrado por último neste manual basicamente porque é muito melhor não depender solenemente das capacidades de firewall para proteger um dado sistema. A segurança em um sistema é feita através de camadas, o firewall deve ser a última a ser adicionada, uma vez que todos os serviços foram ajustados para serem mais seguros. Você pode facilmente imaginar uma configuração em que o administrador descuidadamente remove as regras de firewall por alguma razão (problemas com a configuração, descuido, erro humano ...), este sistema pode estar aberto para um ataque se não existir outro reforço no sistema para protege-lo.

Por outro lado, tendo regras de firewall no sistema local também evita que coisas ruins aconteçam. Até mesmo se os serviços fornecidos estão configurados de forma segura, um firewall pode proteger de má configurações ou de serviços instalados recentemente que ainda não foram configurados adequadamente. Também, uma configuração forte evitará que cavalos de tróia chamem a origem de funcionarem a não ser que o código do firewall seja removido. Note que um intruso não precisa de acesso de superusuário para instalar um cavalo de tróia localmente que pode ser controlado remotamente (pois a escuta a porta é permitido caso não sejam portas privilegiadas e as capacidades não foram removidas).

Assim, uma configuração apropriada de firewall é aquela com a política padrão deny, que é:


5.14.2 Usando um firewall para proteger outros sistemas

Um firewall também pode ser instalado no Debian para proteger, com regras de filtragem, o acesso a sistemas através dela, limitando sua exposição na Internet. O firewall pode ser configurado para evitar que sistemas de fora da rede local acesse serviços (portas) que não são públicas. Por exemplo, em um servidor de mensagens, somente a porta 25 (onde o serviço de e-mail foi definido) precisa ser acessada de fora. Um firewall pode ser configurado para, até mesmo se existem outros serviços disponibilizados publicamente, descartar qualquer pacote (isto é conhecido como filtragem) direcionado a máquina.

Você pode até mesmo configurar a máquina Debian GNU/Linux como uma firewall bridge, i.e. um firewall de filtragem completamente transparente para a rede que deixa de lado um endereço IP e assim não pode ser atacada diretamente. Dependendo do kernel que tiver instalado, você poderá precisar fazer a instalação do patch de bridge no firewall e então ir para a seção 802.1d Ethernet Bridging quando estiver configurando o kernel e uma nova opção netfilter ( firewalling ) support. Veja Configurando uma ponte firewall, Apêndice D para mais detalhes sobre como fazer isto em um sistema Debian GNU/Linux).


5.14.3 Configurando o firewall

É claro que a configuração do firewall é sempre dependente de sistema e rede. Um administrador deverá conhecer de antemão qual é a estrutura da rede e os sistemas que deseja proteger, os serviços que precisam ser acessados e se ou não outras considerações de rede (como NAT ou roteamento) devem ser levadas em conta. Seja cuidadoso quando configurar seu firewall, como Laurence J. Lane diz no pacote iptables:

As ferramentas podem ser facilmente mal utilizadas, causando uma enorme quantidade de peso na consciência e cortando o acesso a um sistema. Não é terrivelmente incomum para um administrador de sistemas remotos travar si próprio fora de um sistema centenas de milhares de milhas de distância. É também possível que alguém deixe ele próprio fora de um computador em que o teclado está sob seus dedos. Por favor, use com a devida precaução.

Lembre-se disto: apenas a instalação do iptables (ou do antigo código de firewall) não oferece qualquer proteção, apenas fornece o programa. Para ter um firewall, você precisa configurá-lo!

Se não souber muito sobre firewall, leia o Firewalling-HOWTO que pode ser encontrado no pacote doc-linux-text (outros formatos de documentos também estão disponíveis). Veja Esteja ciente dos problemas gerais de segurança, Seção 2.2 para mais referências (gerais).


5.14.3.1 Fazendo pelo método Debian

Se estiver usando o Debian 3.0, você notará que tem o pacote iptables instalado. Este é para suporte da implementação netfilter de kernels 2.4.4 e superiores. Pois apenas após a instalação o sistema pode não saber que regras de firewall (regras de firewall são bastante dependentes de sistema) você tem para ativar o iptables. No entanto, os scripts foram configurados de uma forma que o administrador possa configurar as regras de firewall e então ter os scripts de inicialização sempre aprendendo-as e usando sempre como configuração do firewall.

Para fazer isto você deverá:

Assim que tiver terminado, sua configuração de firewall estará salva no diretório /var/lib/iptables/ e será executado quando o sistema inicializar (ou quando executar o script initd com os argumentos start e stop). Por favor note que a configuração padrão do Debian inicia o código de firewall em níveis de execução multiusuário (2 a 5) e em breve (10). Também, ele é interrompido em modo monousuário (1), altere isto caso não confira com suas políticas locais.

Se não tiver uma dica de como configurar regras de firewall manualmente, consulte o documento Packet Filtering HOWTO e NAT HOWTO fornecidas pelo iptables para leitura offline em /usr/share/doc/iptables/html/. O arquivo de configuração /etc/default/iptables também fornece várias informações a respeito deste pacote.


5.14.3.2 Usando pacotes de Firewall

A configuração manual de um firewall pode ser complicada para o administrador novato (e muitas vezes para até mesmo o expert). No entanto, a comunidade de software livre tem criado um número de ferramentas que podem ser usadas para configurar facilmente um firewall local. Esteja avisado desde já que algumas destas ferramentas são orientadas somente para a proteção local (também chamadas de firewall pessoal) e algumas são mais versáteis e podem ser usadas para configurar regras complexas para proteger todas as redes.

Alguns softwares que podem ser usados para configurar regras de firewall em um sistema Debian são:

Os últimos pacotes: gfcc,firestarter e knetfilter são interfaces de administração GUI usando ou o GNOME (os dois primeiros) ou o KDE (o último) que são muito mais orientados a usuários (para usuários domésticos) que outros pacotes da lista que são mais orientadas a administradores.

Esteja já avisado que alguns pacotes destacados anteriormente irão provavelmente introduzir a scripts de firewall que serão executados quando o sistema for inicializado, isto sem dúvida alguma conflitará com a configuração padrão (se estiver configurada) e terá efeitos indesejados. Normalmente os scripts de firewall que são executados por último serão os que configurarão o firewall do sistema (que pode não ser o que você deseja). Consulte a documentação do pacote e use ou uma desta configurações. Geralmente, outros programas que te ajudam a configurar regras de firewall podem pesquisar outros arquivos de configuração.

FIXME: Adicionar mais informações a respeito destes pacotes

FIXME: Procure por informações sobre firewall no Debian e o que/como fazer sua alteração para outras distribuições.

FIXME: Onde o código de firewall personalizado poderá ser ativado (FAQ padrão na debian-firewall?)

FIXME: Adicionar informações sobre Zorp no Debian (veja Bug #88347. Os pacotes do Debian são fornecidos, mas eles dependem da libglib1.3 que não está disponível na distribuição Debian.


[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ próximo ]


Securing Debian Manual

v3.1, Mon, 10 Feb 2014 17:06:00 +0000

Javier Fernández-Sanguino Peña jfs@debian.org
Autores, Seção 1.1