[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ próximo ]
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.
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.
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:
ListenAddress 192.168.0.1
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).
PermitRootLogin no
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.
Listen 666
Altera a porta do programa, assim o intruso não terá completa certeza de onde o daemon sshd é executado (esteja avisado, isto é segurança por obscuridade).
PermitEmptyPasswords no
Senhas em branco tornam a segurança do seu sistema um fiasco.
AllowUsers alex ref me@algumlugar
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.
AllowGroups wheel admin
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".
PasswordAuthentication yes
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".
Desative quaisquer outras formas de autenticação que realmente não precisa, se
não usar, por exemplo RhostsRSAAuthentication,
HostbasedAuthentication, KerberosAuthentication ou
RhostsAuthentication, você deverá desativa-las, até mesmo se forem
usadas por padrão (veja a página de manual sshd_config(5)
).
Protocol 2
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 documento relacionando problemas do
protocolo ssh
ou o aviso Xforce
.
Banner /etc/some_file
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.
Você pode ler mais informações sobre como configurar um SSH com suporte a PAM
em arquivos
da lista de segurança
.
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.
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).
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á:
bloquear o login de usuários ao servidor ssh (como descrito acima no arquivo de configuração ou configuração do PAM).
não fornecer shells validas para usuários que não tem permissão de realizar transferências de arquivos seguras. O shell fornecido, no entanto, programas que podem tornar a conexão ao ssh útil, como o menu (estilo BBS). Caso contrário, a opção anterior é a preferida.
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):
calamaris
- Analisador de arquivos de log para o Squid ou log do
proxy Oops
modlogan
- Um analisador de arquivos e log modular.
squidtaild
- Programa de monitoramento de logs do Squid.
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
.
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
.
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.
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.
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.
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.
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.
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...
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).
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:
configurando o próprio daemon adequadamente assim ele não poderá ser abusado de fora (veja Configuração do Bind para evitar má utilização, Seção 5.7.1) Isto inclui limitar requisições de clientes: transferências de zonas e pesquisas recursivas.
limitar o acesso do daemon ao próprio servidor assim se ele for usado para um corrompimento, a falha no sistema será limitada. Isto inclui executar o daemon como um usuário não-privilegiado (veja Alterando o usuário do BIND, Seção 5.7.2) e fazer ele rodar dentro um chroot (see Executando o servidor de nomes em uma jaula chroot, Seção 5.7.3)
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.
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.
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
.
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.
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.
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.
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).
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
):
cfingerd - Daemon de finger configurável
efingerd - Outro daemon de finger para unix, capaz de ajustes finos em sua saída.
ffingerd - um daemon seguro do finger
fingerd - Servidor remoto de informações do usuário.
xfingerd - BSD-like daemon de finger com suporte a qmail.
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.
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.
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.
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.
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
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
).)
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
.
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:
Bloqueando o acesso as portas usadas por estes serviços com um firewall local (veja Adicionando capacidades de firewall, Seção 5.14).
Bloquear o acesso a estes serviços usando tcp wrappers, pois o portmapper (e
alguns serviços RPC) são compilados com a libwrap
(veja Usando os tcpwrappers, Seção 4.11.
Isto significa que você poderá bloquear o acesso a eles através do
hosts.allow
e hosts.deny
na configuração do tcp
wrappers.
Desde a versão 5-5, o pacote portmap
pode ser configurado para
somente realizar conexões na interface loopback. Para fazer isto, modifique o
arquivo /etc/default/portmap
, e descomente a seguinte linha:
#OPTIONS="-i 127.0.0.1" e reinicie o portmapper. Isto é
suficiente para permitir que serviços RPC locais funcionem enquanto ao mesmo
tempo evite que sistemas remotos os acessem (no entanto, veja Desativando assuntos relacionados a
weak-end de máquinas, Seção 4.17.5.
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.
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 é:
conexões de entrada são permitidas somente para serviços locais por máquinas permitidas.
conexões de saída somente são permitidas para serviços usados pelo seu sistema (DNS, web browsing, pop, email....) [32]
a regra forward bloqueia tudo (a não ser que esteja protegendo outros sistemas, veja abaixo).
todas as outras conexões de entrada ou saída são negadas.
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).
É 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).
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á:
Configurar o pacote, assim ele será iniciado com o sistema. Nas versões novas
(desde a 1.2.6a-1) isto é feito quando o pacote é instalado. Você poderá
configurá-lo após isto com dpkg-reconfigure -plow iptables.
Nota: em versões antigas, isto pode ser feito editando-se o arquivo
/etc/default/iptables
e verificando se a variável
enable_iptables_initd foi definida para true (ativo).
crie uma configuração de firewall usando o iptables
, você poderá
usar a linha de comando (veja iptables(8)
) ou algumas outras
ferramentas fornecidas pelos pacotes de Firewall do Debian (veja Usando pacotes de Firewall, Seção 5.14.3.2). Você
precisará criar um conjunto de regras de firewall para ser usado quando o
firewall estiver em estado ativo e outro para ser usado no estado
inativo do firewall (podem ser simplesmente regras vazias).
salve as regras que criou usando o /etc/init.d/iptables save_active e /etc/init.d/iptables save_inactive executando estes scripts com as regras de firewall que deseja iniciar.
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.
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:
firestarter
orientado a usuários finais, inclui um assistente para
definir regras de firewall rapidamente.
knetfilter
fwbuilder
uma GUI orientada a objetos que inclui compiladores de
políticas para várias plataformas de firewalls incluindo o iptables assim como
listas de acesso do roteador. A funcionalidade completa do fwbuilder também
está disponível através da linha de comando
shorewall
que oferece suporte a IPsec com um suporte bem limitado
para controle de tráfego também como uma definição de regras de firewall.
mason
, que propõe regras de firewall baseados no tráfego de rede
que seu sistema "enxerga".
bastille
(entre os passos de fortalecimento que podem fazer as
novas versões do bastille, é a possibilidade de se adicionar regras de firewall
ao sistema que serão executadas na inicialização)
guarddog
, um pacote de configuração de firewall baseada no KDE
(alternativa/competidor ao pacote knetfilter)
ferm
fwctl
easyfw
firewall-easy
ipac-ng
gfcc
lokkit
ou gnome-lokkit
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,mailto:jfs@debian.org