Como Fazer - NFS
Nicolai Langfeldt janl@math.uio.no - Tradução da Conectiva
Informática - Janeiro de 1999.
v0.7, 3 de Novembro de 1997
Como Fazer - configuração de servidores e clientes NFS.
______________________________________________________________________
Índice geral
1. Preâmbulo
1.1 Nota Legal
1.2 Outros Assuntos
1.3 Dedicatória
2. LEIAME.antes
3. Configurando um Servidor NFS
3.1 Pré-Requisitos
3.2 Primeiros Passos
3.3 O portmapper
3.4 Mountd e nfsd
4. Configurando um cliente NFS
4.1 Opções de Montagem
4.2 Otimizando o NFS
5. NFS Sobre Linhas de Baixa Velocidade
6. Segurança e NFS
6.1 Segurança no Cliente
6.2 Segurança no Servidor: nfsd
6.3 Segurança no Servidor: o portmapper
6.4 NFS e Firewalls
6.5 Resumo
7. Pontos de Verificação de Montagem
8. FAQ
9. Exportando Sistemas de Arquivos
9.1 IRIX, HP-UX, Digital-UNIX, Ultrix, SunOS 4 (Solaris 1), AIX
9.2 Solaris 2
10. PC-NFS
______________________________________________________________________
11.. PPrreeââmmbbuulloo
11..11.. NNoottaa LLeeggaall
(C)opyright 1997 Nicolai Langfeldt. Não é permitida a alteração deste
documento sem a publicação dos direitos autorais. Pode ser livremente
distribuído desde que contenha este parágrafo. A seção de Perguntas e
Respostas é baseada no FAQ NFS de Alan Cox. A seção da lista de
verificações é baseada na lista de problemas de montagem compilada
pela IBM Corporation.
11..22.. OOuuttrrooss AAssssuunnttooss
Este nunca será um documento finalizado, devido à dinâmica do tema.
Por favor envie-nos informações sobre problemas e sucessos, que possam
melhorar este Como Fazer. Por favor contribuições financeiras,
comentários e questões podem ser enviadas para janl@math.uio.no. Caso
uma mensagem seja enviada, por favor esteja _s_e_g_u_r_o de que o endereço
para resposta está correto e funcionando, pois eu recebo _m_u_i_t_o_s emails
e tentar descobrir endereços pode ser uma tarefa cansativa. Obrigado.
Caso se deseje traduzir este Como Fazer, por favor, avise-me para que
eu possa estar ciente sobre a quantidade de idiomas em que eu já fui
publicado :-).
Agradecimentos a Olaf Kirch que me convenceu a escrever este documento
e forneceu-me grandes sugestões. :-)
Este Como Fazer cobre o NFS nas versões 2.0 do kernel. Há melhorias
significativas, e mudanças do NFS nas versões subseqüentes do kernel.
11..33.. DDeeddiiccaattóórriiaa
Este Como Fazer é dedicado a Anne Line Norheim Langfeldt, que
provavelmente nunca o lerá, já que ela não é deste tipo de garota.
22.. LLEEIIAAMMEE..aanntteess
NFS, o Sistema de Arquivos em Rede tem três importantes
características:
· Possibilita o compartilhamento de arquivos sobre uma rede local.
· Funciona bastante bem.
· Possibilita diversos problemas de segurança que são bem conhecidos
por intrusos, e podem ser explorados na obtenção de acesso
(leitura, gravação e remoção) de todos os arquivos de um sistema.
Abordaremos todos estes assuntos neste Como Fazer. Por favor, não
deixe de ler os itens sobre segurança neste Como Fazer, o que tornará
a rede menos vulnerável a riscos tolos de segurança. As passagens
sobre segurança serão bastante técnicas e exigirão conhecimento sobre
redes IP e sobre os termos usados. Caso não se reconheça algum dos
termos aqui usados, verifique o Como Fazer - Redes ou obtenha um livro
sobre administração de redes TCP/IP. Esta é uma boa idéia de qualquer
forma, caso se esteja administrando máquinas Unix/Linux. Um livro
muito bom é _T_C_P_/_I_P _N_e_t_w_o_r_k _A_d_m_i_n_i_s_t_r_a_t_i_o_n de Craig Hunt, publicado
pela O'Reilly & Associates, Inc. E após toda esta leitura, certamente
você será mais valorizado no mercado de trabalho, e isso não se pode
perder ;-)
Há duas seções de ajuda com problemas no NFS, chamadas _L_i_s_t_a _d_e
_V_e_r_i_f_i_c_a_ç_ã_o e _F_A_Q_s. Por favor, leia estas seções com atenção caso
algo não funcione da maneira esperada.
33.. CCoonnffiigguurraannddoo uumm SSeerrvviiddoorr NNFFSS
33..11.. PPrréé--RReeqquuiissiittooss
Antes de continuar a ler este Como fazer, será necessário poder
executar o programa telnet de e para as máquinas que serão usadas
como servidor e cliente. Caso isso não esteja funcionando, pedimos que
seja checada a rede e sugerimos a leitura do Como Fazer Net-2 para
configurar a rede adequadamente.
33..22.. PPrriimmeeiirrooss PPaassssooss
Antes que se possa fazer qualquer coisa, será necessário ter um
servidor NFS configurado. Caso se faça parte de alguma rede de um
departamento ou rede universitária provavelmente já existirão diversos
servidores NFS sendo executados. Casos eles permitam o acesso ou ao
invés disso, se esteja lendo este Como Fazer para se obter acesso a um
servidor NFS, não é necessário ler esta seção, podendo passar
diretamente à seção ``configurando um cliente NFS''.
Caso se necessite configurar um sistema diferente do Linux para atuar
como servidor, será necessário ler o manual do sistema para descobrir
como habilitar o NFS e a exportação de sistemas de arquivos. Há uma
seção neste documento explicando como fazer isto em muitos sistemas
diferentes. Após se descobrir isso tudo pode-se continuar na leitura
desta seção.
Aqueles que continuaram a sua leitura estão avisados: vamos ter que
configurar uma série de programas.
33..33.. OO ppoorrttmmaappppeerr
O portmapper no Linux é chamado também de portmap ou rpc.portmap. A
página de manual online diz que se trata de "mapeador de portas DARPA
para números de programas RPC". Este é o primeiro problema de
segurança com o qual nos deparamos neste Como Fazer. A descrição de
como evitar estes problemas podem ser encontrada na ``seção de
seguranção'', a qual eu repito que deve ser lida.
Inicializando o portmapper! Ele é chamado de portmap ou rpc.portmap e
deve estar localizado no diretório /usr/sbin (em algumas máquinas ele
é chamado de rpcbind). Pode-se inicializá-lo manualmente por hora, mas
ele deverá ser reinicializado toda vez que o sistema operacional for
ativado, sendo então necessário editar os programas rc. Este programas
são explicados mais detalhadamente na página de manual do processo
init, e usualmente estão localizados nos diretórios /etc/rc.d,
/etc/init.d ou /etc/rc.d/init.d. Caso haja um programa chamado inet ou
algo similar, este provavelmente será aquele que deve ser editado.
Porém, como fazê-lo está além do escopo deste documento. Deve-se
iniciar o programa portmap e verificar se ele está ativo através do
comando ps aux. Encontrou-o? Ótimo.
33..44.. MMoouunnttdd ee nnffssdd
Os próximos programas que necessitam ser executados são chamados
mountd e nfsd. Porém, antes, é necessário editar outro arquivo. Desta
vez o /etc/exports. Digamos que se deseje que o sistema de arquivo
/mn/parolin/local, o qual está localizado na máquina parolin se torne
disponível para a máquina chamada batel. Deve-se então utilizar a
seguinte configuração no arquivo /etc/exports na parolin:
______________________________________________________________________
/mn/parolin/local batel(rw)
______________________________________________________________________
As linhas acima fornecem a batel acesso de leitura e gravação (rw)
para /mn/parolin/local. Ao invés de rw poderíamos informar ro, o que
fornece acesso somente para leitura e que é o padrão quando este
parâmetro não é informado. Há diversas opções que podem ser utilizadas
e que serão discutidas juntamente com aspectos de segurança mais
adiante. Elas estão descritas nas páginas de manual online do comando
exports, a qual deve ser lida ao menos uma vez na vida. Há ainda
formas melhores de incluir diversas máquinas no arquivo exports. Pode-
se por exemplo, usar grupos de rede caso se esteja utilizando NIS (ou
NYS) (NIS foi conhecido como YP) e especificar sempre um domínio com
caracteres de generalização, ou subredes IP como máquinas que têm
permissão para montar algo. Porém é necessário considerar que poderá
ser possível obter acesso ao servidor de forma não autorizadas caso se
utilize autorizações tão genéricas.
NNoottaa:: oo aarrqquuiivvoo eexxppoorrttss nnããoo tteemm aa mmeessmmaa ssiinnttaaxxee qquuee eemm oouuttrrooss UUnniixxeess..
Há uma seção específica neste Como fazer sobre arquivos exports de
outros sistemas.
Agora que configuramos o mountd (ou talvez ele seja chamado
rpc.mountd) e o nfsd (o qual pode ser chamado rpc.nfsd), ambos irão
ler o arquivo exports.
Caso se edite o /etc/exports deve-se estar seguro de que os programas
nfsd e mountd fiquem cientes destas alterações. A forma tradicional é
através da execução do comando exportfs. Muitas distribuições Linux
não possuem o programa exportfs. Caso este seja o seu caso, pode-se
instalar o seguinte programa na máquina local:
______________________________________________________________________
#!/bin/sh
killall -HUP /usr/sbin/rpc.mountd
killall -HUP /usr/sbin/rpc.nfsd
echo re-exportando sistemas de arquivos
______________________________________________________________________
O programa acima deve ser salvo, como por exemplo como
/usr/sbin/exportfs, e deve ser executado o comando chmod a+rx
exportfs. Agora, toda vez que uma alteração for efetuada, deve-se
executar o comando exportfs a seguir, com privilégios de superusuário.
Agora deve-se checar se mountd e nfsd estão sendo adequadamente
executados. Inicialmente deve-se executar o comando rpcinfo -p. Ele
deverá apresentar uma saída similar a:
______________________________________________________________________
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 745 mountd
100005 1 tcp 747 mountd
100003 2 udp 2049 nfs
100003 2 tcp 2049 nfs
______________________________________________________________________
Como se pode perceber, o portmapper anunciou os seus serviços, assim
como mountd e nfsd.
Caso se obtenha uma mensagem similar a rpcinfo: não foi possível
contactar o portmapper: RPC: Erro no sistema remoto - Conexão recusada
ou algo similar, possivelmente o portmapper não esteja sendo
executado. Caso se obtenha uma mensagem similar a Nenhum programa
remoto registrado. então, ou o portmapper não deseja falar com a
máquina local ou existe algum erro. Pode-se finalizar o nfsd, o mountd
e o portmapper e tentar reiniciá-los nesta ordem novamente.
Após verificar os serviços disponíveis segundo o portmapper, pode-se
fazer uma checagem através do comando ps. O portmapper continuará a
reportar um serviço, mesmo após o programa responsável ter sido
finalizado com erro, por exemplo. Então um comando ps poderá ser a
maneira mais simples de descobrir que programas estão efetivamente
sendo executados.
Evidentemente, será necessário modificar os arquivos rc do sistema
para inicializar o mountd e o nfsd, assim como o portmapper, quando o
sistema operacional for carregado. É muito provável que estes
programas já existam na máquina local e que se deva somente
descomentar as seções adequadas ou ativá-los nos níveis de execução
corretos.
Páginas de manual online que já devem ter sido visitadas até agora:
portmap, mountd, nfsd, e exports.
Bem, caso tudo tenha sido feito exatamente como foi descrito aqui, já
temos à disposição todo o conjunto de ferramentas necessárias para
iniciar um cliente NFS.
44.. CCoonnffiigguurraannddoo uumm cclliieennttee NNFFSS
Inicialmente é necessário ter um kernel com o suporte a sistemas de
arquivo NFS compilado ou como um módulo. Isso deve ser configurado
antes da compilação do kernel. Caso não se tenha feito isto, por favor
verifique o Como Fazer - Kernel para instruções sobre como proceder.
Caso se esteja utilizando uma distribuição muito boa (como o Conectiva
Linux) e nunca se tenha lidado com o kernel ou módulos, nfs está
magicamente à sua disposição.
Pode-se agora, na linha de comandos do superusuário, informar o
comando de montagem apropriado e o sistema de arquivos estará
disponível. Continuando com nosso exemplo anterior, desejamos montar
/mn/parolin/local a partir de parolin. Isso deve ser feito através do
seguinte comando:
______________________________________________________________________
mount -o rsize=1024,wsize=1024 parolin:/mn/parolin/local /mnt
______________________________________________________________________
(Retornaremos posteriormente às opções rsize e wsize). O sistema de
arquivos está agora disponível sob /mnt e pode-se acessá-lo através do
comando cd, assim como verificar o seu conteúdo através do comando ls,
e observar os arquivo individualmente. Pode-se perceber que ele não é
tão rápido quando um sistema local, mas muito mais amigável que o uso
do ftp. Se, ao invés de montar um sistema de arquivos, o comando mount
apresente uma mensagem de erro como mount:parolin:/mn/parolin/local
falhou, razão fornecida pelo servidor: Permissão negada, então o
arquivo exports contém algum erro. Caso ele informe mount
clntudp_create: RPC: Programa não registrado isso significa que os
programas nfsd ou mountd não estão sendo executados no servidor.
Para desmontar o sistema de arquivos basta comandar:
______________________________________________________________________
umount /mnt
______________________________________________________________________
Para que um sistema de arquivos nfs seja montado na inicialização do
sistema operacional, deve-se editar o arquivo /etc/fstab da forma
usual. No caso de nosso exemplo, deve-se adicioar a seguinte linha:
______________________________________________________________________
# dispositivo pto.montagem tipo_sist_arqs opções dump ordem verif.
...
parolin:/mn/parolin/local /mnt nfs rsize=1024,wsize=1024 0 0
...
______________________________________________________________________
Bem, parece tudo. Quase. Continue a leitura por favor.
44..11.. OOppççõõeess ddee MMoonnttaaggeemm
Há algumas opções que devem ser consideradas. Eles definem a forma
como o cliente NFS lida com uma queda do servidor ou da rede. Um dos
aspectos mais interessantes sobre NFS é que ele lida com estas
situações com elegância, desde que o cliente esteja corretamente
configurado. Há dois tipos distintos de parâmetros de tratamento de
falhas:
ssoofftt
O cliente NFS reporta um erro ao processar o acesso a um arquivo
localizado em um sistema de arquivos montado via NFS. Alguns
programas podem lidar com isto com compostura, outros não. Esta
opção não é recomendada.
hhaarrdd
O programa que acessa um arquivo em um sistema de arquivos
montado via NFS irá travar sempre que o servidor não responder.
O processo não pode ser interrompido ou finalizado a menos que
se tenha especificado intr. Quando o servidor NFS esteja
novamente ativo, o programa irá continuar a partir do ponto onde
tenha parado. Isso é provavelmente o que se deseje. Recomendamos
o uso do parâmetro hard,intr em todos os sistemas de arquivos
montados via NFS.
A partir do exemplo anterior, esta seria a entrada no arquivo fstab:
______________________________________________________________________
# dispositivo pto.montagem tipo_sist_arqs opções dump ordem verif.
...
parolin:/mn/parolin/local /mnt nfs rsize=1024,wsize=1024,hard,intr 0 0
...
______________________________________________________________________
44..22.. OOttiimmiizzaannddoo oo NNFFSS
Normalmente, caso as opções rsize e wsize seja especificados, o NFS
irá ler e gravar blocos de 4096 e 8172 bytes. Algumas combinações de
kernel do Linux e placas de rede não podem lidar com blocos grandes e
não podem ser otimizados. Então vamos tentar descobrir como encontrar
os parâmetros rsize e wsize que funcionem da maneira mais otimizada
possível. É possível testar a velocidade das opções com um simples
comando. Dado o comando mount conforme descrito acima, logo temos
acesso de gravação ao disco, podendo executar um teste de performance
de gravação seqüencial:
______________________________________________________________________
time dd if=/dev/zero of=/mnt/testfile bs=16k count=4096
______________________________________________________________________
Este comando criará um arquivo de 64 Mb de bytes zerados (que deve ser
grande o suficiente para que o cache não altere significativamente a
performance. Pode ser usado um arquivo maior caso o sistema local
tenha muita memória). Isso pode ser feito algumas vezes (5-10?), para
que se possa ter uma média bem fundamentada. Neste casos, o importante
é medir o tempo de "relógio" e o tempo efetivamente gasto na conexão.
Após, pode-se testar a performance da leitura ao se ler o arquivo de
volta:
______________________________________________________________________
time dd if=/mnt/testfile of=/dev/null bs=16k
______________________________________________________________________
Isso pode ser feito algumas vezes. Após deve-se executar o comando
mount e umount novamente com tamanhos maiores em rsize e wsize. Eles
devem ser provavelmente múltiplos de 1024, e não maior que 16384 visto
que este é o tamanho máximo do NFS versão 2. Exatamente após a
montagem de um tamanho maior, acesse o sistema de arquivos montado
através do comando cd e explore-o através do comando ls, para estar
seguro que ele está funcionando perfeitamente. Caso os parâmetros
rsize/wsize sejam muito grandes, os sintomas não são _m_u_i_t_o óbvios. Um
típico sintoma é uma lista incompleta dos arquivos produzida pelo
comando ls e nenhuma mensagem de erro. Ou ao se ler um arquivo ele
falha misteriosamente, sem mensagens de erro. Após definir que os
parâmetros rsize/wsize funcionam perfeitamente deve-se executar os
testes de performance. SunOS e Solaris tem a reputação de funcionar
muito melhor com blocos de 4096 bytes.
kernels mais recentes do Linux (desde o 1.3) executam a leitura
antecipada para rsizes maiores ou iguais ao tamanho de página da
máquina. Em máquinas Intel o tamanho de página é de 4.096 bytes. A
leitura adiantada aumenta _s_i_g_n_i_f_i_c_a_t_i_v_a_m_e_n_t_e a performance de leitura
do NFS. Ou seja, sempre que possível deve-se usar o rsize de 4.096
bytes em máquinas Intel.
Lembre-se de editar o arquivo /etc/fstab com os valores de
rsize/wsize encontrados.
Uma sugestão para incrementar a performance de gravação do NFS é
desabilitar o sincronismo de gravação do servidor. A especificação NFS
indica que a gravação NFS solicitada não pode ser considerada
finalizadas antes dos dados serem gravados em um meio não volátil
(normalmente o disco rígido). Isso restringe a performance de gravação
de alguma forma, enquanto que gravações assíncronas irão aumentar a
velocidade do NFS. O servidor Linux nfsd nunca faz gravações síncronas
uma que a própria implementação do sistema de arquivos não o faz, mas
em servidores em sistemas operacionais diferentes isso pode aumentar a
performance através do seguinte parâmetro no arquivo exports:
______________________________________________________________________
/dir -async,access=linuxbox
______________________________________________________________________
ou algo similar. Por favor verifique a página de manual online da
máquina em questão. Cabe salientar que esta opção aumenta o risco de
perda de dados no caso de algum problema ocorrer antes da efetiva
gravação dos dados.
55.. NNFFSS SSoobbrree LLiinnhhaass ddee BBaaiixxaa VVeelloocciiddaaddee
Linhas de baixa velocidade incluem modems, ISDN e praticamente todas
as ligações de longa distância possíveis.
Esta seção é baseada no conhecimento dos protocolos usados mas não em
experiências de campo. Meu computador pessoal este inativo por um
longo tempo e caso você tenha alguma experiência adicional por favor
entre em contato.
A primeira coisa para se lembrar sobre NFS é que ele é um protocolo
lento e tem ainda um alto número de informações adicionais. Usar NFS é
o mesmo que se utilizar o kermit para transferir arquivos. É _l_e_n_t_o.
Praticamente qualquer coisa é mais rápida que NFS. FTP, HTTP, rcp, ssh
por exemplo.
Ainda quer tentar? Ok.
Os parâmetros padrões do NFS são para linhas rápidas com baixa
latência. Caso se esteja usando estes parâmetros para linhas de alta
latência, certamente o NFS reportará alguns erros, encerrará
operações, imaginará que arquivos são menores do que eles sejam na
realidade e agirá estranhamente em alguns casos.
A primeira coisa a _n_ã_o fazer é usar a opção de montagem soft. Ela
provocará ultrapassagem dos tempos de espera e retornos de erro para o
software, o qual, na maior parte do tempo, não saberá lidar
corretamente com eles. Essa é uma maneira rápida de se obter erros
misteriosos. Ao invés disso deve ser usada a opção de montagem hard,
que gera infinitas tentativas em caso de estouro de tempo de espera ao
invés de encerrar a solicitação, independentemente do que o software
deseje fazer. Isso será realmente necessário nestes casos.
A próxima providência é mudar as opções de montagem timeo e retrans.
Elas são descritas na página de manual online nfs(5), mas segue aqui
uma cópia:
______________________________________________________________________
timeo=n
O número de décimos de segundo antes de enviar a primeira retransmissão após findo o tempo de espera de uma RPC. O valor padrão é de 7 décimos de segundo. Após a primeira espera, o tempo é dobrado após cada espera sem respostas, até um máximo de 60 segundos ou um número máximo de retransmissões ser atingido. Então, caso o sistema de arquivos esteja montado com a opção hard, cada novo tempo de espera começa com o dobro do tempo da anterior, novamente dobrando a cada retransmissão. O tempo máximo de espera é sempre de 60 segundos. Uma melhor performance pode ser atingida ao se incrementar o tempo de espera, quando se está montando sistemas sobre uma rede com muito tráfego, utilizando-se servidores lentos ou usando o sistema através de diversos roteadores e gateways.
retrans=n
O número de tempo limite e retransmissões que devem ocorrer antes que um alarme de tempo de resposta seja acionado. O padrão é de 3 ocorrências. Quando um alarme de tempo de espera maior ocorre, a operação é interrompida ou uma mensagem de "servidor não está respondendo" é apresentada na console.
______________________________________________________________________
Em outras palavras: se uma resposta não for recebida no tempo de
espera de 0,7 segundos (700 ms), o cliente NFS irá repetir e dobrar o
tempo de espera para 1,4 segundos. Caso a resposta não seja recebida
neste tempo, a requisição será enviada novamente com um tempo de
espera alterado para 2,8 segundos.
A velocidade da linha pode ser medida com um ping com os mesmos
parâmetros das opções rsize/wsize.
______________________________________________________________________
$ ping -s 8192 lugulbanda
PING lugulbanda.uio.no (129.240.222.99): 8192 data bytes
8200 bytes from 129.240.222.99: icmp_seq=0 ttl=64 time=15.2 ms
8200 bytes from 129.240.222.99: icmp_seq=1 ttl=64 time=15.9 ms
8200 bytes from 129.240.222.99: icmp_seq=2 ttl=64 time=14.9 ms
8200 bytes from 129.240.222.99: icmp_seq=3 ttl=64 time=14.9 ms
8200 bytes from 129.240.222.99: icmp_seq=4 ttl=64 time=15.0 ms
--- lugulbanda.uio.no ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 14.9/15.1/15.9 ms
______________________________________________________________________
O parâmetro time aqui mostra quanto tempo o pacote ping levou para
chegar a e retornar da máquina denominada lugulbanda. 15ms é bastante
rápido. Sobre uma linha de 28.800 bps pode-se esperar algo como
4000-5000ms e, caso a linha esteja carregada, um tempo maior, chegando
facilmente ao dobro. Quando o tempo é muito alto nos referimos como
uma linha de alta latência. Geralmente para pacotes maiores e linhas
mais carregadas, a latência tende a aumentar. Deve-se aumentar o
parâmetro timeo para se adequar a esta realidade. Deve-se atentar que
a latência tende a aumentar ainda mais quando se usa a linha para
outros serviços como por exemplo FTP e NFS simultaneamente. Neste caso
deve-se medir as respostas do comando ping ao se efetuar
transferências de arquivos.
Vamos simular um cenário. Caso o tempo de ping esteja em cerca de
5000ms para um pacote de 8 Kb, que é o tempo de envio e resposta deste
pacote e que somente indo ou vindo ele leve em média 2.500 ms,
significando o tempo gasto pelo envio por uma ponta e recepção pela
outra. Para pacotes menores de 512 bytes o tempo de ida e vinda é de
aproximadamente 400 ms e ida ou vinda tem um tempo médio de 200 ms.
Adicionando-se 2.500 ms e 200 ms temos 2.700 ms, que é o tempo médio
de ida e vinda de um pequeno pacote de requisição e de uma resposta
com um pacote maior. O tráfego ocorre da seguinte forma:
______________________________________________________________________
tempo limite evento
0 700 cliente solicita dados
300 servidor recebe a solicitação
300 servidor começa a responder (sob uma ótica otimista :-)
lembrete: o cliente não verá a resposta até que ela esteja
completa, em cerca de 2,7 segundos.
700 estouro de tempo do cliente
700 1400 cliente solicita os dados novamente
1000 servidor recebe a requisição
1000 servidor começa a responde a requisição.
______________________________________________________________________
Neste ponto, cerca de 700 ms dos 2.700 ms de transmissão já foram
utilizados. Ou seja restam 2.000 ms. O servidor responde à requisição,
mas o pacote não pode ser enviado porque um pacote...
66.. SSeegguurraannççaa ee NNFFSS
Não me considero um expert em segurança de computadores. Porém existem
algumas _s_u_g_e_s_t_õ_e_s 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
_f_e_c_h_a_d_a 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_á_s_i_c_o de segurança. E lembre-se, o que aqui
for dito é somente uma base para o tema. Um site _s_e_g_u_r_o 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.
______________________________________________________________________
66..11.. SSeegguurraannççaa nnoo CClliieennttee
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 _a_l_g_u_n_s 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.
66..22.. SSeegguurraannççaa nnoo SSeerrvviiddoorr:: nnffssdd
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.
66..33.. SSeegguurraannççaa nnoo SSeerrvviiddoorr:: oo ppoorrttmmaappppeerr
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 _t_o_d_o_s 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.
IIMMPPOORRTTAANNTTEE:: _n_ã_o coloque _n_a_d_a exceto _E_N_D_E_R_E_Ç_O_S _I_P 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.
66..44.. NNFFSS ee FFiirreewwaallllss
É 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.
66..55.. RReessuummoo
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 _e_s_t_e_s _p_r_o_b_l_e_m_a_s 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.
77.. PPoonnttooss ddee VVeerriiffiiccaaççããoo ddee MMoonnttaaggeemm
Esta seção é baseada na lista de verificação de problemas da IBM Corp.
Meus agradecimentos a eles por tornarem ela disponível para este Como
Fazer. Caso o leitor esteja com algum problema em montar sistemas de
arquivos NFS, por favor consulte esta lista. Cada item descreve um
problema específico e a sua solução.
1. O sistema de arquivos não foi exportado, ao menos para a máquina
cliente em questão.
SSoolluuççããoo:: Inclui-lo no arquivo exports.
2. A resolução de nomes não confere com a lista de exports.
por exemplo: a lista em export indica uma exportação para johnmad
mas o nome johnmad é resolvido como johnmad.austin.ibm.com, fazendo
com que a permissão de montagem seja negada.
SSoolluuççããoo:: Exportar em ambos os formatos de nomes.
Isso pode ocorrer ainda quando o cliente tem 2 interfaces com nomes
diferentes para cada um dos dois dispositivos e o comando export
especifica somente um deles.
SSoolluuççããoo:: Exportas para ambas as interfaces.
Isso pode ocorrer também quando o servidor não consegue executar um
chamada lookuphostbyname ou lookuphostbyaddr (são funções da
biblioteca) no cliente. Estejá seguro de que o cliente pode
executar máquina <nome>; máquina <endereço_ip>; e que ambos mostram
a mesma máquina.
SSoolluuççããoo:: ajustar a resolução de nomes no cliente.
3. O sistema de arquivos foi montado após a inicialização do NFS (no
servidor). Neste caso o sistema de arquivos está exportado sob um
ponto de montagem.
SSoolluuççããoo:: Desativar nfsd e reinicializá-lo.
NNoottaa:: os clientes que tenham pontos de montagem sob sistemas de
arquivos terão problemas no acesso após a reinicialização.
NN..TT..:: nestes casos é recomendada a execução do comando mount -a,
como superusuário, na máquina cliente.
4. As datas estão estranhamente diferentes em ambas as máquinas (o que
pode gerar inconsistências com os arquivos).
SSoolluuççããoo:: Ajustar as datas.
O autor do Como Fazer sugere o uso do NTP para sincronismo de
relógios. Uma vez que existem restrições de exportação do NTP para
fora dos EUA, pode-se obter uma cópia em uma distribuição Linux ou
em ftp://ftp.hacktic.nl/pub/replay/pub/linux ou em um site espelho.
5. O servidor não aceita uma montagem de um usuário presente em mais
de 8 grupos.
SSoolluuççããoo:: diminuir o número de grupos aos quais o usuário pertença
ou alterar o usuário na montagem.
88.. FFAAQQ
Esta é uma seção de perguntas e respostas. Muito do que está contido
aqui foi escrito por Alan Cox.
1. Obtive uma série de erros de manipulação de arquivos nfs ao usar o
Linux como servidor.
Isso é causado por uma antiga versão do nfsd. Está corrigida a
partir da versão nfs-server2.2beta16.
2. Ao tentar montar um sistema de arquivos, surge a mensagem:
não foi possível registrar-se no portmap: erro do sistema no envio
Provavelmente se está utilizando o sistema da Caldera. Há um problemas
com os programas rc. Por favor entre em contato com eles para correção
do problema.
3. Por que não é possível executar um arquivo após copiá-lo para o
servidor NFS?
A questão reside no fato do nfsd criar caches de manipulação de
arquivos por questões de performance (lembre-se que ele é executado
em um espaço de usuário). Enquanto nfsd tem um arquivo aberto (como
no caso em que ele esteja sendo gravado), o kernel não permite a
sua execução. Os programas NFSd a partir de 95 liberam os arquivos
após alguns segundos, já versões mais antigas podem levar dias.
4. Os arquivos NFS estão todos com permissões somente de leitura.
O padrão do servidor NFS Linux é somente fornecer permissões de
leitura para arquivos montados. O arquivo /etc/exports deve ser
alterado caso se deseje algo diferente.
5. Existe um sistema de arquivos montado a partir de um servidor nfs
Linux e enquanto o comando ls trabalha, a leitura e gravação de
arquivos não funcionam.
Em versões mais antigas do Linux, deve-se montar um servidor NFS
com os parâmetros rsize=1024,wsize=1024.
6. Ao montar a partir de um servidor NFS Linux com um bloco de tamanho
entre 3500-4000 ele trava regularmente.
Bem...não faça mais isso!
7. O Linux pode executar NFS sobre TCP?
Não no momento.
8. Ao se montar a partir de uma máquina Linux, obtém-se inúmeros
erros.
Esteja certo de que os usuários utilizados estão presentes em no
máximo 8 grupos. Servidores mais antigos requerem isso.
9. Ao reinicializar a máquina, ela algumas vezes trava ao tentar
desmontar um servidor NFS.
NNããoo desmonte servidores NFS ao reinicializar ou desligar.
Simplesmente ignore-os. Isso não irá machucar nimguém. O comando é
umount -avt nonfs.
10.
Clientes Linux NFS são muito lentos ao tentar gravar em sistemas
Sun e BSD.
NFS executa gravações síncronas (que podem ser desabilitadas caso
não haja nenhum grande problema em se perder algum dado). Kernels
derivados do BSD tendem a trabalhar mal com pequenos blocos. Porém
ao se gravar blocos de 4 Kb de dados a partir de uma máquina Linux,
usando pacotes de 1 Kb, faz com que o Linux use a rotina BSD na
seguinte forma:
ler página de 4K
alterar para 1K
gravar 4K no disco rígido
ler página de 4K
alterar para 1K
gravar 4K no disco rígido
etc.
99.. EExxppoorrttaannddoo SSiisstteemmaass ddee AArrqquuiivvooss
A forma de exportar sistemas de arquivos com NFS não é totalmente
consistente quando utilizada entre plataformas distintas. No caso
Linux e Solaris 2 são distintos. Esta seção lista superficialmente a
forma de como executar esta tarefa na maioria dos sistemas. Caso o seu
sistema não esteja aqui descrito, deve-se checar as páginas de manual
do sistema em questão. Palavras chaves são: nfsd, ferramentas de
administração de sistemas, programas rc, programas de inicialização,
seqüência de inicialização, /etc/exports, exportfs. Usaremos como
exemplo nesta seção como exportar /mn/parolin/local para a máquina
batel com permissões de leitura e gravação.
99..11.. IIRRIIXX,, HHPP--UUXX,, DDiiggiittaall--UUNNIIXX,, UUllttrriixx,, SSuunnOOSS 44 ((SSoollaarriiss 11)),, AAIIXX
Estes sistemas usam o formato tradicional de exportação. Em
/etc/exports deve ser incluído:
______________________________________________________________________
/mn/parolin/local -rw=batel
______________________________________________________________________
A documentação completa de exports pode ser encontrada na página de
manual. Após editar este arquivo deve ser executado o comando exportfs
-av para exportar os sistemas de arquivos.
Em alguns sistemas a linha anterior pode ter o seguinte formato:
______________________________________________________________________
/mn/parolin/local batel
______________________________________________________________________
ou mesmo algo como:
______________________________________________________________________
/mn/parolin/local rw=batel
______________________________________________________________________
Recomenda-se a forma usual. O risco da próxima versão do exportfs ser
diferente é grande e algumas coisas podem parar de funcionar.
99..22.. SSoollaarriiss 22
Sun reinventou completamente a roda quando fez o Solaris 2, já que
ele é completamente diferente de todos os outros sistemas
operacionais. Deve-se editar o arquivo /etc/dfs/dfstab. Neste arquivos
são colocados os comandos compartilhados, conforme documentado na
página de manual share (1 Mb). A sintaxe será algo como:
______________________________________________________________________
share -o rw=batel -d "Parolin Local" /mn/parolin/local
______________________________________________________________________
Após a edição deve-se executar o programa shareall para exportar o
sistema de arquivos.
1100.. PPCC--NNFFSS
Não se deve rodar o PC-NFS. Neste caso o melhor é executar o samba.
Desculpe, mas não conheço nada sobre o PC-NFS. Caso alguém queira
colaborar por favor envie-me algumas informações e elas serão
incluídas.