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).
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.
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”.
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.
