Product SiteDocumentation Site

Capítulo 5. Tornando os serviços em execução do seu sistema mais seguros

5.1. Tornando o ssh mais seguro
5.1.1. Executando o ssh em uma jaula chroot
5.1.2. Clientes do ssh
5.1.3. Desativando transferências de arquivos
5.1.4. Restricing access to file transfer only
5.2. Tornando o Squid mais seguro
5.3. Tornando o FTP mais seguro
5.4. Tornando o acesso ao sistema X Window mais seguro
5.4.1. Verifique seu gerenciador de tela
5.5. Tornando o servidor de impressão mais seguro (sobre o lpd e lprng)
5.6. Tornando o serviço de e-mails seguro
5.6.1. Configurando um programa de e-mails nulo
5.6.2. Fornecendo acesso seguro às caixas de mensagens
5.6.3. Recebendo mensagens de forma segura
5.7. Tornando o BIND mais seguro
5.7.1. Configuração do Bind para evitar má utilização
5.7.2. Alterando o usuário do BIND
5.7.3. Executando o servidor de nomes em uma jaula chroot
5.8. Tornando o Apache mais seguro
5.8.1. Proibindo a publicação de conteúdo dos usuários
5.8.2. Permissões de arquivos de log
5.8.3. Arquivos da Web Publicados
5.9. Tornando o finger mais seguro
5.10. Paranóia geral do chroot e suid
5.10.1. Criando automaticamente ambientes chroots
5.11. Paranóia geral sobre senhas em texto puro
5.12. Desativando o NIS
5.13. Tornando serviços RPC mais seguros
5.13.1. Desativando completamente os serviços RPC
5.13.2. Limitando o acesso a serviços RPC
5.14. Adicionando capacidades de firewall
5.14.1. Fazendo um firewall no sistema local
5.14.2. Usando um firewall para proteger outros sistemas
5.14.3. Setting up a firewall
Os serviços podem ser deixados mais seguros de duas formas:
  • Tornando-os somente acessíveis em pontos de acessos (interfaces) que são utilizados.
  • Configurando-os adequadamente, desta forma eles poderão somente ser usados por usuários legítimos de forma autorizada.
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.
Regarding the services running from inetd (telnet, ftp, finger, pop3...) it is worth noting that inetd can be configured so that services only listen on a given interface (using service@ip syntax) but that's an undocumented feature. One of its substitutes, the xinetd meta-daemon includes a bind option just for this matter. See ixnetd.conf(5) manual page.
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:
  • Especifica que o ssh somente funcionará na interface especificada, caso tenha mais de uma interface (e não deseja que o ssh funcione através delas) ou em caso de adição de uma futura interface de rede (onde não deseja receber conexões ssh através dela).
  • Tenta não permitir o login do usuário Root sempre que possível. Se alguém quiser se tornar o usuário root usando ssh, agora dois logins são necessários e o ataque de força bruta não terá efeito no root via SSH.
  • Port 666 or ListenAddress 192.168.0.1:666 Change the listen port, so the intruder cannot be completely sure whether a sshd daemon runs (be forewarned, this is security by obscurity).
  • PermitEmptyPasswords no Empty passwords make a mockery of system security.
  • Permite somente certos usuários terão acesso via ssh a esta maquina. usuario@maquina pode também ser usado para restringir um determinado usuário de acessar somente através de uma maquina especificada.
  • Permite somente membros de certos grupos de terem acesso ao ssh nesta maquina. AllowGroups e AllowUsers possuem diretivas equivalentes para bloquear o acesso a maquina. Não se surpreenda por eles serem chamados de "DenyUsers" e "DenyGroups".
  • Esta escolha fica completamente por sua conta. É mais seguro somente permitir o acesso a maquina de usuários com chaves ssh colocadas em ~/.ssh/authorized_keys. Se deseja isto, ajuste esta opção para "no".
  • Disable any form of authentication you do not really need, if you do not use, for example RhostsRSAAuthentication, HostbasedAuthentication, KerberosAuthentication or RhostsAuthentication you should disable them, even if they are already by default (see the manpage sshd_config(5) manual page).
  • Desative o protocolo da versão 1, pois ele tem alguns problemas de design que torna fácil a descoberta de senhas. Para mais informações leia http://earthops.net/ssh-timing.pdf ou o http://xforce.iss.net/static/6449.php.
  • Adiciona um banner (ele será lido de um arquivo) para usuários se conectando ao servidor ssh, em alguns países o envio de avisos antes de acessar um determinado sistema alertando sobre acesso não autorizado ou monitoramento de usuários deverá ser emitido para ter proteção legal.
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.
You can read more information on how to set up SSH with PAM support in the http://lists.debian.org/debian-security/2001/11/msg00395.html.

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 Seção 4.11.15, “Restringindo acessos de usuários”.
Em Seção B.7, “Chroot environment for SSH 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

If you do not want users to transfer files to and from the ssh server you need to restrict access to the sftp-serverand the scp access. You can restrict sftp-server by configuring the proper Subsystem in the /etc/ssh/sshd_config.
You can also chroot users (using libpam-chroot so that, even if file transfer is allowed, they are limited to an environment which does not include any system files.

5.1.4. Restricing access to file transfer only

You might want to restrict access to users so that they can only do file transfers and cannot have interactive shells. In order to do this you can either:
  • bloquear o login de usuários ao servidor ssh (como descrito acima no arquivo de configuração ou configuração do PAM).
  • give users a restricted shell such as scponly or rssh. These shells restrict the commands available to the users so that they are not provided any remote execution priviledges.