Aprenda Linux, 302 (Ambientes Mistos): Segurança em Samba

Samba seguro no nível de firewall e de daemon

Em preparação para fazer o exame de certificação LPI-302 do Linux Professional Institute para administradores de sistema, aprenda a tornar Samba seguro e solucionar problemas relacionados à segurança.

Sean A. Walberg, Senior Network Engineer

Author photoSean Walberg trabalha com Linux e UNIX desde 1994 em ambientes acadêmicos, corporativos e de provedores de serviço de Internet. Escreveu muito sobre administração de sistemas nos últimos anos. É possível entrar em contato com ele pelo e-mail sean@ertw.com.



28/Dez/2011

Sobre esta série

Esta série de artigos ajuda você a saber mais sobre as tarefas de administração de sistemas Linux. Também é possível usar o material desses artigos para se preparar para os exames de certificação do Linux Professional Institute nível 3 (LPIC-3).

Consulte o developerWorks roadmap for LPIC-3 para ver uma descrição de cada artigo da série e um link para cada um desses artigos. O roteiro está em andamento e reflete os objetivos atuais (novembro de 2010) em relação aos exames LPIC-3. À medida que cada artigo é concluído, eles são adicionados ao roteiro.

Neste artigo, saiba mais sobre estes conceitos:

  • Configurar o acesso ao servidor Samba e a partir dele no nível do firewall
  • Solucionar problemas de firewall com seu servidor Samba

Este artigo ajuda a se preparar para o Objetivo 315.2 do Tópico 315 do exame de especialidade de Ambiente Misto (302) do Linux Professional Institute (LPI). O objetivo tem peso 2.

Pré-requisitos

Para aproveitar ao máximo os artigos desta série, é necessário ter um conhecimento avançado de Linux e um sistema Linux funcional, no qual seja possível praticar os comandos mencionados neste artigo. Além disso, é preciso ter acesso a um ambiente Windows que será usado para testar suas configurações de segurança.


Firewalls

Sobre o exame elegível LPI-302

O Linux Professional Institute Certification (LPIC) é como muitas outras certificações, pois também oferece certificações em níveis diferentes, e cada nível requer mais conhecimento e experiência que o anterior. O exame LPI-302 é um exame elegível especial no terceiro nível da hierarquia do LPIC, e requer um nível avançado de conhecimento de administração de sistemas Linux.

Para obter a certificação LPIC-3, é necessário passar nos dois primeiros exames do primeiro nível (101 e 102), nos dois exames do segundo nível (201 e 202) e no exame principal do LPIC-3 (301). Depois de alcançar esse nível, é possível fazer os exames elegíveis especializados, como o LPI-302.

Samba tem muitos recursos para restringir quem pode acessar que compartilhamento —limitando o acesso a determinados nomes de usuário, impondo requisitos de senha, verificando a associação ao grupo ou filtrando no nível de rede. Os últimos parâmetros, como allow hosts e smb ports, operam em endereços IP e portas do Protocolo UDP/TCP, que fornecem um modo fácil de controlar quais hosts têm permissão de se conectar ao seu servidor Samba.

O controle ao nível de rede é alcançado ao identificar que dispositivos se conectarão a um servidor, como aqueles pertencentes a uma rede interna ou até mesmo a determinada sub-rede ou grupo de servidores. É a primeira linha de defesa: se um invasor não conseguir se conectar a um dispositivo, este está mais seguro.

Controlar o acesso à rede dentro do daemon do Samba talvez pareça a solução perfeita, mas existem maneiras melhores. Para determinar se uma conexão remota é desejável, o Samba deve primeiro aceitar a conexão, porque ele não recebe nenhum detalhe sobre a conexão recebida até ter concluído essa conexão. Se a ideia era impedir pessoas indesejáveis de se conectar ao Samba, faria mais sentido evitar que ele até mesmo visse a conexão. Qualquer configuração dentro do Samba só afeta ele, e é preciso, então, encontrar soluções semelhantes para outros daemons, como servidores da web e transferência de arquivos.

Em um ambiente típico, a segurança de rede é cuidada não por administradores de sistemas, mas por outros membros da equipe de TI. Controlar o acesso no nível do host em vez do nível do aplicativo fornece separação de interesses e reduz os erros causados por alterações no smb.conf.

Entendendo as iptables

Desenvolva sua própria alimentação

É possível desenvolver uma alimentação RSS, Atom ou HTML customizado para receber uma notificação sobre a inclusão de novos artigos ou a atualização do conteúdo. Acesse as Alimentações RSS do developerWorks. Selecione Linux como zona e Articles como tipo, e digite Linux Professional Institute como palavra-chave. Em seguida, escolha o tipo de feed preferencial.

O Linux fornece um firewall robusto, baseado em host, chamado iptables. Esse firewall é capaz de inspecionar os pacotes que chegam, saem ou passam por um dispositivo Linux. iptables é capaz de consultar o sistema de filtragem de pacotes dentro do kernel Linux ou o nome do comando usado para gerenciar os filtros. O sistema de filtragem de pacotes no kernel cresceu ao longo dos anos de um simples mecanismo de correspondência par um firewall robusto, capaz de carregar plug-ins dinamicamente. Assim, ele pode ser complicado de configurar se nos desviarmos dos casos de uso básicos.

O primeiro conceito importante por trás das iptables são as próprias tabelas. Uma tabela é uma lista autocontida de regras e ações. Quando o kernel precisa filtrar um pacote, ele consulta a tabela filter . Quando é necessária conversão de endereço de rede (NAT), a tabela nat é usada. Podem existir outras tabelas, dependendo de que recursos de rede foram carregados no kernel. Um pacote pode atravessar diversas tabelas —por exemplo, para executar filtragem de pacotes antes da conversão de endereço.

Dentro de cada tabela há um conjunto de cadeias. Cada tabela tem algumas cadeias predefinidas, e pode-se incluir cadeias customizadas nessa lista. As cadeias predefinidas são usadas em diferentes pontos do ciclo de vida de um pacote. Por exemplo, a tabela filter tem três cadeias predefinidas:

  • INPUT. Usada para determinar o que fazer com pacotes destinados ao próprio host.
  • OUTPUT. Aplicada a pacotes que se originam do host.
  • FORWARD. Apenas pacotes que passam de uma interface para outra, como quando o host age como roteador.

A cadeia tem uma lista ordenada de zero ou mais regras, cada regra consistindo de uma cláusula de correspondência e um destino. A cláusula de correspondência pode ser quase qualquer coisa, de um endereço IP ou porta a instruções de limite de taxa que só terão efeito quando determinada ação ocorrer com muita frequência. O destino pode ser outra cadeia ou uma ação, como uma instrução para aceitar ou descartar o pacote. Pode-se criar tanto cláusulas de correspondência como destinos por meio de módulos do kernel, de modo que as possibilidades são ilimitadas.

O kernel escolhe a cadeia com base no que precisa ser feito e analisa cada regra em ordem. Quando encontra a primeira correspondência, o kernel salta para o destino. Na maioria dos casos, o processamento de regra para, embora alguns destinos —como criação de log —sejam considerados não encerrados, de modo que o kernel continuará o processamento com a próxima regra. Se não houver nenhuma regra correspondente, o destino padrão da cadeia é usado.

Observação: Para os fins deste artigo, apenas a tabela filter é necessária.

Protegendo o Samba com um firewall

Há muitas maneiras diferentes de projetar uma política de firewall para o Samba, com a opção de itens como layout de sua rede e quem ou o que precisa de acesso ao seu servidor Samba. Em alto nível, pode-se optar por proteger o host inteiro ou apenas se concentrar no Samba.

Se quiser proteger o host inteiro, não há preocupação com as portas que o Samba está usando. O código a seguir mostra uma política simples para permitir o tráfego apenas da rede privada 10.0.0.0/8 para o servidor local:

iptables -A INPUT -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -P INPUT DROP

O primeiro comando acrescenta uma regra à cadeia INPUT, anexando-a à lista atual de regras. A regra especifica que tudo que vem da rede de origem (-s) 10.0.0.0/8 saltará para o destino ACCEPT, que aceita o pacote. O segundo comando permite que pacotes vindos de uma sessão existente, obtidos com uma chamada ao matcher de estado com -m state. Esse matcher rastreia que conexões estão saindo do host. Os pacotes de resposta para as conexões de saída são considerados established ou related, de modo que o restante da regra aceita esses pacotes.

O comando final configura a política padrão da cadeia INPUT para descartar o pacote. Se o pacote não vem da rede 10.0.0.0/8 ou não faz parte de uma conexão que o host iniciou, ele não receberá permissão.

Pode-se obter mais granularidade filtrando no nível da porta. O exemplo anterior filtrou no endereço de origem, de modo que todos os serviços seriam bloqueados. Se houvesse um servidor da web no seu host que quisesse abrir acesso pela Internet em geral, a política anterior não funcionaria.

Lembre-se de "Aprenda Linux, 302 (Ambientes Mistos): Configure o Samba" que o Samba usa quatro portas distintas:

  • 137 UDP. Serviços de nomes do sistema básico de rede de entrada/saída (NetBIOS).
  • 138 UDP. Serviços de datagrama NetBIOS.
  • 139 TCP. Serviços de sessão NetBIOS.
  • 445 TCP. Hosting direto (CIFS por TCP).

A Listagem 1 mostra uma política que permite conexões da rede 10.0.0.0/8 para os serviços Samba e também permite que um servidor da web opere sem restrição.

Listagem 1. Política que opera no nível da porta
iptables -A INPUT -p tcp -m state --state NEW --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW --dport 443 -j ACCEPT
iptables -A INPUT -p udp -s 10.0.0.0/8 --dport 137 -j ACCEPT
iptables -A INPUT -p udp -s 10.0.0.0/8 --dport 138 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -s 10.0.0.0/8 --dport 139 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -s 10.0.0.0/8 --dport 445 -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -P INPUT DROP

A política da Listagem 1 é mais complexa do que a política anterior, porque especifica vários aplicativos diversos, cada qual com suas políticas. As primeiras duas regras correspondem a qualquer pacote TCP recebido (-p tcp) que fazem parte de uma nova sessão (-m state --state NEW) e enviados para a porta 80 ou para a porta 443 (--dport 80, --dport 443). Não há restrições ao endereço de origem, de modo que qualquer pessoa tem permissão.

As próximas duas linhas fazem a correspondência com qualquer pacote UDP (-p udp) vindo da rede interna (-s 10.0.0.0/8) para a porta 137 ou para a porta 138 (--dport 137, --dport 138). UDP é stateless, então não é preciso se preocupar se a conexão é nova ou estabelecida.

As linhas 5 e 6 combinam o matcher de estado e o filtro de endereço de origem para permitir apenas novas conexões nas portas 139 e 445 se elas vierem da rede interna.

Por fim, as duas últimas linhas operam de forma idêntica à política anterior. Se o pacote estiver relacionado a uma conexão atual, receberá permissão. Qualquer outra coisa é descartada.


Resolução de problemas de firewall

São comuns problemas com firewalls, muitas vezes por causa de um requisito inesperado que é encontrado ou um de um aplicativo que não é executado da maneira esperada. Os erros nas próprias regras são comuns, em especial ao lidar com longas listas de números de portas e endereços IP. Mas nem todos os problemas se relacionam ao firewall, de modo que é bom conhecer as etapas básicas de resolução de problemas de rede.

Visualizando a política

Use o comando iptables para visualizar a política. A opção -L lista a política e a opção detalhada (-v) inclui detalhes extras, como contadores de pacotes. A Listagem 2 mostra a política da Listagem 1.

Listagem 2. Visualizando uma política detalhada
# iptables -L -v
Chain INPUT (policy DROP 47 packets, 5125 bytes)
 pkts bytes target  prot opt in   out  source      destination
    0     0 ACCEPT  tcp  --  any  any  anywhere    anywhere     state NEW tcp dpt:http
    0     0 ACCEPT  tcp  --  any  any  anywhere    anywhere     state NEW tcp dpt:https
    0     0 ACCEPT  udp  --  any  any  10.0.0.0/8  anywhere     udp dpt:netbios-ns
    0     0 ACCEPT  udp  --  any  any  10.0.0.0/8  anywhere     udp dpt:netbios-dgm
    0     0 ACCEPT  tcp  --  any  any  10.0.0.0/8  anywhere     state NEW tcp dpt:139
    0     0 ACCEPT  tcp  --  any  any  10.0.0.0/8  anywhere     state NEW tcp dpt:445
  214 15216 ACCEPT  all  --  any  any  anywhere    anywhere     state RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 292 packets, 35009 bytes)
 pkts bytes target     prot opt in     out     source               destination

As estatísticas detalhadas mostram o número de pacotes e bytes que correspondem a uma regra nas primeiras duas colunas. Na Listagem 2, pode-se ver que os pacotes só correspondem à última regra. Olhando mais de perto na primeira linha da saída, vemos que o destino padrão também tem uma contagem de pacotes. Quarenta e sete pacotes foram descartados porque não correspondiam a uma regra; isso indicaria que alguém não autorizado está tentando acessar a máquina ou que tráfego legítimo está sendo bloqueado por uma política de firewall incorreta.

Outro uso da visualização da política de firewall é entender a política na sua totalidade. Visto que o processamento para após a primeira correspondência ser encontrada, é preciso começar no topo da política e trabalhar por toda ela para determinar se uma regra está descartando seu tráfego.

Um cenário comum é quando uma regra menos específica aparece antes de uma regra mais específica. Para evitar problemas, coloque suas regras mais específicas mais para o topo de sua política de modo que as exceções sejam atendidas primeiro. No entanto, essa convenção nem sempre funciona, e você talvez se depare com usuários que não conseguem se conectar ao seu servidor.

A Listagem 3 mostra a política em um servidor da rede de engenharia. Os usuários da mesma rede não conseguem se conectar ao serviço.

Listagem 3. Política com uma regra que substitui outra
# iptables -L -v
Chain INPUT (policy DROP 21 packets, 2967 bytes)
target   prot opt in   out  source       destination
ACCEPT   tcp  --  any  any  anywhere     anywhere      state NEW tcp dpt:http
ACCEPT   tcp  --  any  any  anywhere     anywhere      state NEW tcp dpt:https
DROP     tcp  --  any  any  10.0.0.0/8   anywhere
ACCEPT   udp  --  any  any  10.2.3.0/24  anywhere      udp dpt:netbios-ns
ACCEPT   udp  --  any  any  10.2.3.0/24  anywhere      udp dpt:netbios-dgm
ACCEPT   tcp  --  any  any  10.2.3.0/24  anywhere      state NEW tcp dpt:netbios-ssn
ACCEPT   tcp  --  any  any  10.2.3.0/24  anywhere      state NEW tcp dpt:microsoft-ds
ACCEPT   all  --  any  any  anywhere     anywhere      state RELATED,ESTABLISHED

O servidor da Listagem 3 pertence à rede de engenharia, que é a 10.2.3.0/24. O acesso a partir do restante da empresa, que é 10.0.0.0/8, deve ser bloqueado. A rede 10.2.3.0/24 é uma sub-rede da rede maior, de modo que a regra para bloquear toda a rede 10.0.0.0/8 vem antes das regras específicas do Bloco de Mensagens do Servidor (SMB); em resultado disso, até os usuários da engenharia são capturados pela regra DROP , visto que iptables usa o conceito de primeira correspondência, não de melhor correspondência.

A solução para o problema acima é bloquear a rede corporativa após as regras específicas serem processadas. Desse modo, os pacotes da rede de engenharia serão aceitos primeiro.

Resolução avançada de problemas

Muitas vezes, não é possível ter certeza se o firewall é o culpado ou os problemas estão em outro lugar da rede. O teste mais simples é desligar o firewall e ver se a conexão teve êxito. É claro que nem sempre isso é possível, então se não se pode desligar o firewall, a próxima melhor coisa a fazer é observar o pacote chegar ao servidor.

O utilitário tcpdump exibe os pacotes de rede que o servidor vê, mesmo que a política de firewall descarte o pacote. Se for possível ver a tentativa de conexão do servidor, podemos saber que o pacote está chegando até esse. Supondo-se que o serviço esteja em execução, é possível concluir, pela lógica, queo firewall está descartando o pacote. A Listagem 4 mostra o utilitário tcpdump em ação.

Listagem 4. Rastreio de pacote de uma conexão SMB bloqueada
# tcpdump -i eth0 tcp port 445
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
20:24:18.392106 IP CLIENT.search > SERVER.microsoft-ds: S ...
20:24:21.358458 IP CLIENT.search > SERVER.microsoft-ds: S ...
20:24:27.393604 IP CLIENT.search > SERVER.microsoft-ds: S ...

As opções de tcpdump são as seguintes:

  • -i eth0. Monitora a interface eth0.
  • tcp port 445. Acompanha os pacotes em TCP, porta 445.

O resultado da Listagem 4 mostra que três pacotes chegaram ao servidor. A seta indica a direção do fluxo: esses três pacotes foram do cliente para o servidor na porta microsoft-ds, que é a 445. O S perto do fim da linha indica uma tentativa de conexão, e a falta de resposta indica que o servidor não está respondendo.

Outra indicação de falha na conexão é o aumento na diferença entre pacotes sucessivos. Os registros de data e hora à esquerda mostram que o segundo pacote chegou cerca de 3 segundos após o primeiro, e o terceiro, 6 segundos depois disso. A maioria dos protocolos de rede implementa um back-off exponencial, ou seja, o tempo entre tentativas sucessivas dobra a cada vez.

Recursos

Aprender

Obter produtos e tecnologias

  • Firewall Builder é um gerente gráfico de política de firewall capaz de gerenciar facilmente suas regras de iptables.
  • Netfilter.org é a página inicial das iptables. Lá, encontra-se mais documentação e uma lista de módulos que podem ampliar a funcionalidade do seu firewall.
  • Avalie produtos IBM da maneira que for melhor para você: faça download da versão de teste de um produto, avalie um produto on-line, use-o em um ambiente de nuvem ou passe algumas horas na SOA Sandbox aprendendo a implementar Arquitetura Orientada a Serviços de modo eficiente.

Discutir

  • Participe da comunidade do My developerWorks. Entre em contato com outros usuários do developerWorks e explore os blogs, fóruns, grupos e wikis voltados para desenvolvedores.

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Linux
ArticleID=783111
ArticleTitle=Aprenda Linux, 302 (Ambientes Mistos): Segurança em Samba
publish-date=12282011