636. Segurança e NFS

Não me considero um expert em segurança de computadores. Porém existem algumas sugestões importantes. É importante ressaltar que esta não é uma lista completa de todos os aspectos relacionados com segurança e caso se imagine que implementando somente estes não se poderá ter qualquer problema relacionado com o tema segurança, por favor me envie seu email que eu tenho uma ponte e desejo vendê-la.

Esta seção é provavelmente fora de questão caso se esteja em uma rede fechada onde todos os usuários são conhecidos e ninguém que não seja confiável pode acessar a rede, ou seja não há forma de discar para a rede e não há forma de conectar-se a outras redes onde existam usuários não confiáveis. Isso soa como paranóia? Não sou paranóico. Isso é somente um aviso básico de segurança. E lembre-se, o que aqui for dito é somente uma base para o tema. Um site seguro necessita de um administrador diligente e com conhecimento que consiga encontrar informações sobre problemas de segurança correntes e potenciais.

NFS é um problema básico, caso o cliente não seja informado do contrário irá confiar no servidor NFS e vice e versa. Isso pode ser ruim, pois se a senha do superusuário no servidor NFS for quebrada, a senha dos superusuários dos clientes também o será com relativa facilidade. E vice e versa. Há algumas estratégias para se evitar isso, as quais mencionaremos adiante.

Um leitura obrigatória são os avisos do CERT sobre NFS, onde muitos dos textos lidam com conselhos sobre segurança. Veja em ftp.cert.org/01-README por uma lista atualizada dos avisos CERT. Aqui estão alguns dos relacionados com NFS:

CA-91:21.SunOS.NFS.Jumbo.and.fsirand                            12/06/91
Vulnerabilidade preocupa Sun Microsystems, Inc. (Sun) Sistema de Arquivos em Rede (NFS) e o programa fsirand. Estas vulnerabilidades afetam o SunOS versões 4.1.1, 4.1 e 4.0.3 em todas as arquiteturas. Atualizações estão disponíveis para SunOS 4.1.1. Uma atualização inicial para o NFS SunOS 4.1 está também disponível. Sun irá disponibilizar atualizações completas para as versões SunOS 4.1 e SunOS 4.0.3 em uma versão posterior.

CA-94:15.NFS.Vulnerabilidades                                  12/19/94
Este aviso descreve as medidas de segurança a serem tomadas para evitar diversas vulnerabilidades do Sistema de Arquivos em Rede (NFS). Os avisos foram gerados devido ao incremento do comprometimento de superusuários através de invasores usando ferramentas que exploram estas falhas.

CA-96.08.pcnfsd                                                 04/18/96
Este aviso descreve a vulnerabilidade do programa pcnfsd (também conhecido como rpc.pcnfsd). Uma atualização está incluída.

636.1 Segurança no Cliente

No cliente, podemos decidir se desejamos ou não confiar no servidor, através de algumas opções na montagem. Por exemplo, é possível proibir programas suid a funcionarem em sistemas de arquivos NFS através da opção nosuid. Esta pode ser uma boa idéia que deve ser considerada no uso de todos os discos montados via NFS. Esta opção indica que o superusuário do servidor não pode fazer um programa com características de suid no sistema de arquivos, o que possibilitaria que ele acessasse o cliente como um usuário normal e usasse o programa suid-superusuário para tornar-se root na máquina cliente. Deve-se proibir também a execução de arquivo em sistemas de arquivos montados, através da opção noexec. Porém isso pode ser impraticável por vezes, assim como o nosuid uma vez que um sistema de arquivos normalmente contém alguns programas que necessitam ser executados. Estes parâmetros podem ser informados na coluna opções, juntamente com os parâmetros rsize e wsize, separados por vírgulas.

636.2 Segurança no Servidor: nfsd

No servidor pode-se decidir sobre a possibilidade de confiar na conta do superusuário do cliente. Isso é definido através do uso da opção root_squash no arquivo exports:

/mn/parolin/local batel(rw,root_squash)

Agora caso um usuário com número de identificação igual a 0 (UID) tentar acessar (ler, gravar, remover) o sistema de arquivos, o servidor substituirá o UID pela identificação da conta "nobody" (ninguém). Isso faz com que o superusuário da máquina cliente não possa acessar arquivos ou executar mudanças autorizadas somente para o superusuário do servidor. Isso é aconselhável e provavelmente deva-se usar root_squash em todos os sistemas exportados. "Porém o superusuário cliente pode ainda usar o comando 'su' para tornar-se qualquer outro usuário e acessar e alterar quaisquer arquivos", é o que se pode pensar à primeira vista. A resposta é: sim, é desta forma que as coisas funcionam com Unix e NFS. Isso traz uma implicação importante: todos os binários e arquivos importantes devem pertencer ao superusuário root, e não a bin ou outra conta diferente, uma vez que somente a conta do superusuário da máquina cliente pode acessar a conta do superusuário no servidor. Na página de manual online do nfsd há diversas outras opções squash que podem ser usadas, então o administrador deve decidir quem não pode ter acesso à conta do superusuário. Existem opções de se evitar o uso de faixas ou de qualquer UID ou GID que se deseje. Isso está descrito na mesma página de manual.

root_squash é na verdade o padrão do nfsd do Linux. Para permitir acesso a um sistema de arquivos como superusuário deve-se usar a opção no_root_squash.

Outro aspecto importante é garantir que o nfsd verifique que todas as requisições são provenientes de uma porta autorizada. Caso se aceite requisições de qualquer porta antiga de um usuário sem privilégios especiais, torna-se simples acessar o sistema de arquivos através da Internet, por exemplo. Basta usar o protocolo nfs e identificar-se como qualquer usuário que se deseje. Ooopss. O nfsd do Linux realiza esta verificação por padrão, em outros sistemas operacionais deve-se habilitar esta opção. Isso deverá estar descrito na página de manual do servidor nfs do sistema.

Um dado adicional. Nenhum sistema de arquivo deve ser exportado para o 'localhost' ou 127.0.0.1. Acredite em mim.

636.3 Segurança no Servidor: o portmapper

O portmapper básico em combinação com nfsd tem um problema de desenho que torna possível obter arquivos em servidores NFS sem a necessidade de quaisquer privilégios. Felizmente o portmapper do Linux é relativamente seguro contra este tipo de ataque, o que pode ser evitado através da configuração de uma lista de acessos em dois arquivos,

Inicialmente editaremos o /etc/hosts.deny. Ele deverá conter a seguinte linha:

portmap: ALL

através da qual o acesso será bloqueado para todos os cliente. Isto talvez seja um pouco drástico, então podemos tornar as definições um pouco mais maleáveis através da edição do arquivo /etc/hosts.allow. Inicialmente é necessário definir que será colocado nele. Ele contém basicamente uma lista de todas as máquinas que podem acessar o portmapper local. Em um sistema Linux há normalmente poucas máquinas que necessitem este tipo de acesso, qualquer que seja a razão. O portmapper administra os programas nfsd, mountd, ypbind/ypserv, pcnfsd, e serviços 'r' como ruptime e rusers. Todas as máquinas que necessitam acessar os serviços da máquina local deve ter permissão para tanto. Digamos que o endereço da máquina local seja 129.240.223.254 e que ela está conectada à subrede 129.240.223.0, a qual deve ter acesso à máquina local (em caso de dúvida verifique o Como Fazer - Redes para refrescar a memória sobre estes conceitos). Para tanto basta executar:

portmap: 129.240.223.0/255.255.255.0

no arquivo hosts.allow. Este é o mesmo endereço de rede fornecido para o comando route e a máscara de subrede informada no ifcongif. No dispositivo eth0 desta máquina ifconfig mostraria:

...
eth0      Link encap:10Mbps Ethernet  HWaddr 00:60:8C:96:D5:56
          inet addr:129.240.223.254  Bcast:129.240.223.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:360315 errors:0 dropped:0 overruns:0
          TX packets:179274 errors:0 dropped:0 overruns:0
          Interrupt:10 Base address:0x320 
...

e netstat -rn apresentaria

Tabela de Roteamento do Kernel
Destinação     Cam.Padrão         Máscara    Indics Métrica Ref  Uso   Iface
...
129.240.223.0   0.0.0.0         255.255.255.0   U     0      0   174412 eth0
...

o endereço de rede na primeira coluna.

Os arquivos hosts.deny e hosts.allow são descritos nas página de manual de mesmo nome.

IMPORTANTE: não coloque nada exceto ENDEREÇOS IP nas linhas do portmap nestes arquivos. Pesquisas por nomes podem indiretamente causar atividade do portmap o qual acionará a pesquisa de nomes de máquinas a qual indiretamente irá causa atividade no portmap.,

As sugestões acima certamente deixarão o servidor mais seguro. As questões restantes residem em alguém que tenha descoberto a senha do superusuário (ou inicializando um MS-DOS) em uma máquina confiável e usando este privilégio para enviar requisições a partir de uma porta segura como qualquer outro usuário real.

636.4 NFS e Firewalls

É uma boa idéia proteger o servidor nfs e as portas portmap no roteador ou no firewall. O nfsd opera normalmente na porta 2049, nos protocolos udp e tcp. O portmapper na porta 111, tcp e udp e o mountd na porta 745 e 747, tcp e udp. Estas informações devem ser checadas através do comando rpcinfo -p.

Por outro lado, caso se deseje permitir o acesso ao NFS através de um firewall, há opções em programas mountd e nfsd mais recentes que permitem o uso específico e não padronizado de portas que podem ser abertas através de um firewall.

636.5 Resumo

Caso se utilize hosts.allow/deny, root_squash, nosuid e funcionalidades de portas privilegiadas para os softwares portmapper e nfs pode-se evitar muitos dos problemas atualmente conhecidos sobre segurança e pode sentir-se quase seguro sobre estes problemas no mínimo. Porém há mais ainda: quando um intruso tem acesso à rede, ele pode incluir comandos estranhos nos arquivos .forward ou nos arquivos de mensagens, quando /home ou /var/spool/mail são montados via NFS. Pela mesma razão, nunca se deve dar acesso às chaves privadas PGPP sobre nfs. Ou no mínimo, deve-se saber dos riscos envolvidos. Pelo menos isso você já sabe.

NFS e o portmapper criam um subsistema complexo e adicionalmente há problemas que são descobertos e que devem ser solucionados, além da necessidade de se ter em mente o desenho básico de implementação a ser usado. Para estar ciente do que está ocorrendo pode acessar o grupo de notícias comp.os.linux.announce e comp.security.announce eventualmente.