Comando vs. Protocolo: Durante todo este documento, nós vamos usar o texto em negrito para referenciar a um comando ou aplicação. Será usado para exemplos como ssh, desde que seja um protocolo bem como um comando.
As seções que seguem vão cobrir os métodos para proteger seu sistema FreeBSD que foram mencionadas na última seção deste capítulo.
Primeiramente, não perca tempo protegendo as contas do sistema se você não protegeu a conta root. A maioria dos sistemas tem uma senha atribuída a conta root. A primeira coisa que você faz é assumir que a senha está sempre comprometida. Isso não siginifica que você deve remover a senha. A senha é quase sempre necessária para o acesso ao console da máquina. O que isso significa é que você não deve possibilitar o uso da senha fora do console ou possivelmente com o comando su(1). Por exemplo, certifique-se de que seus terminais pty estão especificados como sendo insecure no arquivo /etc/ttys de modo que logins diretos como root via telnet ou rlogin serão rejeitados. Se estiver usando outros serviços de login tais como sshd , certifique-se de que logins diretos como root estão desabilitados também. Você pode fazer isso editando seu arquivo /etc/ssh/sshd_config, e certificando-se de que PermitRootLogin está ajustada para NO. Considere cada método de acesso - serviços tais como FTP often fall through the cracks. Logins diretos como root somente devem ser permitidos através do console do sistema.
Certamente, como um administrador do sistema você tem que ser capaz de pegar root, assim nós abrimos alguns furos. Mas nos certificamos que estes furos exigam uma senha adicional para operar. Uma maneira para fazer o root acessível é adicionar contas apropriadas ao grupo wheel (em /etc/group). Os membros colocados no grupo wheel são permitidos usar su para root. Você nunca deve dar aos membros do sistema acesso nativo ao wheel colocando-os no grupo wheel em sua entrada no arquivo de senhas. Contas do sistema devem ser colocadas em um grupo staff, e então ser adicionados ao grupo wheel através do arquivo /etc/group. Somente aqueles membros que realmente necessitam ter acesso root devem ser colocados no grupo wheel. É possivel também, quando usar um método de autenticação tal como Kerberos, usar o arquivo .k5login do Kerberos na conta root para permitir um ksu(1) para root sem ter que colocar qualquer um no grupo wheel. Esta pode ser a melhor solução visto que o mecanismo wheel ainda permite que um intruso viole o root se conseguir seu arquivo de senhas e invadir uma conta do sistema. Enquanto ter o mecanismo wheel é melhor do que nada, esta não é necessariamente a opção mais segura.
Uma maneira indireta de proteger contas do sistema, e finalmente acesso root é usar um método de login de acesso alternativo e fazer o que é conhecido como ``colocar estrela'' em senhas criptografadas para as contas do sistema. Usando o comando vipw(8), pode-se substituir cada instância de uma senha criptografada com um único carácter ``*''. Este comando atualizará o arquivo /etc/master.passwd e a base de dados de usuários/senhas para desabilitar logins autenticados por senha.
Uma entrada de contas do sistema como:
foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh
Deveria ser trocada para:
foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh
Esta mudança impedirá que logins normais ocorram, visto que a senha criptografada nunca combina com ``*''. Com isto feito, os membros do sistema devem usar um outro mecanismo para se autenticar tais como kerberos(1) ou ssh(1) usando um par de chaves pública/privada. Quando usar algo como o Kerberos, geralmente deve-se proteger as máquinas que executam os servidores Kerberos e sua estação de trabalho desktop. Quando usar um par de chaves pública/privada com ssh, geralmente deve proteger a máquina usada para fazer login de (tipicamente uma estação de trabalho). Uma camada adicional de proteção pode ser adicionada ao par de chaves pela senha que protege o par de chaves ao criá-las com ssh-keygen(1). Sendo capaz de ``colocar estrela'' nas senhas para contas também garante que os membros do sistema podem apenas fazer login através de métodos de acesso seguros que você criou. Isto força todos os membros do sistema a usar conexões seguras, criptografadas para todas as seções, que fecham um furo importante usado por muitos invasores: sniffing na rede de uma máquina menos segura.
Os mecanismos mais indiretos de proteção também assumem que você esta logando de um servidor mais restritivo para um servidor menos restritivo. Por exemplo, se sua máquina principal esta executando todos os tipos de serviços, sua estação de trabalho não deve executar algum. Para que sua estação de trabalho seja razoalvelmente segura você deve executar o mínimo de serviços possíveis, incluindo até nenhum serviço, e você deve executar uma proteção de tela protegida por senha. Naturalmente, dando acesso físico a uma estação de trabalho para um atacante pode quebrar qualquer tipo de segurança que você colocou. Isto é definitivamente um problema que você deve considerar, mas você também deve considerar o fato de que a grande maioira da violações ocorrem remotamente, através da rede, de pessoas que não tem acesso físico a sua estação de trabalho ou servidores.
Usando algo como o Kerberos também te da a abilidade de desativar ou trocar a senha para as contas do sistema em um lugar, e ter efeito imediatamente em todas as máquinas em que os membros do sistema podem ter uma conta. Se uma conta de um membro do sistema for comprometida, a abilidade de trocar imediatamente sua senha em todas as máquinas não deve ser desconsiderada. Com senhas separadas, trocar a senha em N máquinas pode ser um problema. Você também pode impor restrições de troca de senha com Kerberos: não somente um ticket Kerberos pode ser feito para timeout após um tempo, mas o sistema Kerberos pode exigir que o usuário escolha uma nova senha após um certo período de tempo (digamos, uma vez ao mês).
O administrador de sistemas prudente somente executa serviços que necessita, nem mais, nem menos. Esteja previnido que serviços de terçeiros são frequentemente os mais sujeitos a falhas. Por exemplo, executando uma versão antiga do imapd ou popper é como dar um ticket root universal para o mundo inteiro. Nunca execute um serviço que você não verificou com cuidado. Muitos serviços não precisam ser executados como root . Por exemplo, os daemons ntalk, comsat, e finger poden ser executados em sandboxes especiais de usuário. Um sandbox não é perfeito, a menos que você atravesse por uma quantidade grande de problemas, mas a aproximação da cebola à segurança ainda permanece: Se alguém puder entrar através de um servidor executando em um sandbox, ele ainda tem que quebrar o sandbox. Quanto mais camadas o atacante deve quebrar, mais baixa a probabilidade de seu sucesso. Furos envolvendo root foram encontrados historicamente em todos os serviços que sempre executam como root, incluindo serviços básicos do sistema. Se você esta usando uma máquina através da qual pessoas somente fazem login via sshd e nunca via telnetd ou rshd ou rlogind, então desligue estes serviços!
O FreeBSD agora por padrão executa ntalkd, comsat, e finger em um sandbox. Um outro programa que pode ser candidato para executar em um sandbox é o named(8). O /etc/defaults/rc.conf inclui os argumentos necessários para executar o named em um sandbox em um formulário comentado. Dependendo se você esta instalando um sistema novo ou atualizando um sistema existente, contas especiais de usuário usadas por estes sandboxes podem não estar instaladas. O administrador de sistemas prudente pesquisa e implementa sandboxes para serviços sempre que possível.
Há um número de outros serviços que tipicamente não executam em sandboxes: sendmail, popper, imapd, ftpd, e outros. Há alternativas para alguns destes, mas instalá-las pode exigir mais trabalho do que você está disposto a executar (o fator conveniência ataca outra vez). Você pode ter que executar estes serviços como root e confiar em outros mecanismos para detectar violações que podem ocorrer através deles.
Os outros furos com grande potencial root em um sistema são os binários suid-root e sgid instalados no sistema. A maioria destes binários, tais como rlogin, residem em /bin, /sbin, /usr/bin, ou /usr/sbin. Enquanto nada é 100% seguro, os binários suid e sgid padrões do sistema podem ser considerados razoalvelmente seguros. Apesar disso, furos root são encontrados ocasionalmente nestes binários. Um furo root foi encontrado no Xlib em 1998 que fez o xterm (que é tipicamente suid) vulnerável. É melhor estar seguro do que lamentar-se e o administrador de sistemas prudente restringirá binários suid, somente aqueles que usuários do sistema devem executar, a um grupo especial que somente estes usuários podem acessar, e começa a se livrar (chmod 000) de todos os binários suid que ninguém usa. Um servidor sem monitor geralmente não necessita um binário xterm. Binários sgid podem ser quase sempre perigosos. Se um intruso puder violar um binário sgid-kmem, o intruso provavelmente será capaz de ler o /dev/kmem e assim ler o arquivo de senhas criptografadas, comprometendo potencialmente qualquer conta com senha. Alternativamente um intruso que viole o grupo kmem pode monitorar as teclas pressionadas enviadas através dos terminais pty, incluindo pty's usados por usuários que fazem login através de métodos seguros. Um intruso que viole o grupo tty pode escrever para quase todos os tty de usuário. Se um usuário estiver executando um programa ou emulador no terminal com característica de simulação de teclado, o intruso pode gerar potencialmente um data stream que ocasiona o terminal do usuário a executar um comando, que é então executado como esse usuário.
Contas de usuário geralmente são as mais difíceis de proteger. Enquanto você pode impor restrições de acesso Draconianas em contas do sistema e colocar ``estrela'' nas suas senhas, você não pode ser capaz de fazer algo assim com todas as contas gerais de usuário que você pode ter. Se você tiver controle suficiente, então você pode conseguir e ser capaz de proteger as contas de usuário corretamente. Se não, você simplesmente tem que ser mais vigilante na monitoração daquelas contas. O uso do ssh e Kerberos para contas de usuário é mais problematica, devido a administração extra e suporte técnico requeridos, mas ainda uma solução muito boa comparada a um arquivo de senhas criptografadas.
A única maneira certa é colocar * em quantas senhas você puder e usar ssh ou Kerberos para o acesso daquelas contas. Mesmo que o arquivo de senhas criptografadas (/etc/spwd.db) possa somente ser lido pelo root, pode ser possível para um intruso obter acesso de leitura a esse arquivo mesmo se o atacante não pode obter acesso de escrita root.
Seus scripts de segurança devem sempre verificar e relatar mudanças ao arquivo de senhas (veja a seção Verificando integridade de arquivos abaixo).
Se um atacante violar o root ele pode fazer quase que qualquer coisa, mas há certas conveniências. Por exemplo, a maioria dos kernels modernos tem um controlador de dispositivo de farejar (sniffing) pacotes embutido. Sob FreeBSD é chamado dispositivo bpf. Um intruso tentará geralmente executar um farejador (sniffer) de pacotes em uma máquina comprometida. Você não necessita dar ao intruso esta capacidade e a maioria dos sistemas não tem a necessidade para o dispositivo bpf compilado.
Mas mesmo se você desligar o dispositivo bpf, você ainda tem /dev/mem e /dev/kmem para preocupar-se. De qualquer forma, o intruso pode ainda escrever em raw disk devices. Também, há outra característica no kernel chamada carregador de módulo, kldload(8). Um intruso ousado pode usar um módulo KLD para instalar seu próprio dispositivo bpf, ou outro dispositivo de farejar (sniffing), em um kernel funcionando. Para evitar estes problemas você tem que executar o kernel em um nível de segurança elevado, pelo menos securelevel 1. O securelevel pode ser ajustado com sysctl na variável kern.securelevel. Uma vez que você ajustou o securelevel para 1, acesso de escrita a raw devices estarão negados e flags especiais chflags, tais como schg, serão reforçadas. Você deve também assegurar que a flag schg esteja ajustada em binários criticos de inicialização, diretórios, e arquivos script - tudo que começa a executar até o ponto onde o securelevel é ajustado. Isto pode ser um exagero, e atualizar o sistema é muito mais difícil quando você opera em um nível de segurança elevado. Você pode acertar e executar o sistema em um nível de segurança elevado mas não ajustar a flag schg para cada arquivo e diretório do sistema . Outra possibilidade é simplesmente montar o / e /usr apenas leitura. Deve-se notar que ser Draconiano demais no que você tenta proteger pode impedir toda importante detecção de uma invasão.
Quando vier abaixo, você pode somente proteger sua configuração core do sistema e arquivos de controle muito antes do fator conveniência elevar-se a sua cabeça. Por exemplo, usando chflags para ajustar o bit schg na maioria dos arquivos em / e /usr é provavelmente improdutivo, porque enquanto pode proteger os arquivos, fecha também uma janela de detecção. A última camada de sua cebola de segurança é talvez a mais importante - detecção. O resto da sua segurança é inútil (ou, pior, oferece a você um falso senso de segurança) se você não puder detectar invasões potenciais. A metade do trabalho da cebola é atrasar o atacante, preferêncialmente do que para-lo, a fim de dar ao lado da detecção da equação uma oportunidade de pegá-lo no ato.
A melhor maneira de detectar uma invasão é procurar por arquivos modificados, perdidos ou inesperados. A melhor maneira de procurar por arquivos modificados é de outro sistema (frequentemente centralizado) com acesso limitado. Escrevendo seus scripts de segurança no sistema com acesso limitado extra-seguro fá-los na maioria das vezes invisíveis para atacantes potenciais, e isto é importante. A fim de conseguir vantagem máxima você geralmente tem que dar a máquina com acesso limitado, acesso significante as outras máquinas no local, geralmente fazendo a exportação NFS apenas leitura das outras máquinas para a máquina com acesso limitado, ou criando o par de chaves ssh para permitir a máquina com acesso limitado fazer ssh para outras máquinas. A exceção do seu tráfego de rede, o NFS é o método menos visível - permitindo que você monitore o sistema de arquivos em cada máquina cliente não detectada virtualmente. Se seu servidor com acesso limitado esta conectado as máquinas clientes através de um switch, o método NFS é frequentemente a melhor escolha. Se seu servidor com acesso limitado esta conectado as máquinas clientes através de um hub, ou através de diversas camadas de roteamento, o método NFS pode ser inseguro demais (network-wise) e usar ssh pode ser a melhor escolha mesmo com audit-trail tracks que o ssh coloca.
Uma vez que você da a máquina com acesso limitado, ao menos acesso leitura aos sistemas clientes supostos a monitorar, você deve escrever scripts para fazer a monitoração real. Dado uma montagem NFS, você pode escrever scripts de simples utilitários do sistema tais como find(1) e md5(1). É melhor fazer fisicamente o md5 dos arquivos da máquina cliente ao menos uma vez por dia, e para testar arquivos de controle tais como aqueles encontradas em /etc e /usr/local/etc até mais frequentemente. Quando diferenças são encontradas, relativo a base de informação md5 a máquina com acesso limitado sabe, e deve mostrar para um administrador do sistema para verificar isso. Um bom script de segurança verificará também por binários suid inapropriados e por arquivos novos ou deletados em partições do sistema tais como / e /usr.
Quanto usar ssh em vez do NFS, escrever o script de segurança é muito mais difícil. Você essencialmente tem que copiar com scp os scripts para a máquina cliente a fim de executar eles, fazendo-os visíveis, e por segurança você necessita também copiar com scp os binários (tais como find) que aqueles scripts usam. O cliente ssh na máquina cliente pode já estar comprometido. De modo geral, usar o ssh pode ser necessario quando estiver usando links inseguros, mas ele é também muito difícil de se lidar.
Um bom script de segurança verificará também por mudanças aos arquivos de configuração de acesso dos usuários e membros do sistema: .rhosts, .shosts, .ssh/authorized_keys e assim por diante... arquivos que puderam ficar fora do alcançe da verificação MD5.
Se você tiver uma grande quantidade de espaço em disco, isto pode demorar muito para executar em cada arquivo naquela partição. Neste caso, ajustando as flags da montagem para desabilitar binários suid e dispositivos naquelas partições são uma boa idéia. As opções nodev e nosuid (veja mount(8)) são as que você precisa procurar. Você deve provavelmente fazer a varredura de qualquer maneira, ao menos uma vez por semana, desde que o objeto desta camada detecte uma invasão se a invasão for eficaz ou não.
Contabilidade de processos (veja accton(8)) é uma característica relativamente de baixo overhead do sistema operacional que pode ajudar como um mecanismo de avaliação post-break-in. É especialmente útil em rastrear como um intruso violou realmente um sistema, assumindo que o arquivo ainda esteja intacto depois que a invasão ocorrer.
Finalmente, scripts de segurança devem processar os arquivos de log, e os logs deles mesmos devem ser gerados em maneira tão segura como for possível - syslog remoto pode ser muito útil. Um intruso tenta cobrir seus rastros, e o arquivos de log são críticos ao administrador do sistema que tentam rastrear a hora e método da invasão inicial. Uma maneira de manter um registro permanente do arquivo de log é excecutar o console do sistema em uma porta serial e coletar as informações em uma base continua através de uma máquina segura monitorando os consoles.
Um pouco de paranoia nunca machuca. Em geral, um administrador do sistema pode adicionar qualquer número de características de segurança, as long as they do not effect convenience, and can add security features that do effect convenience with some added thought. Até mais importante, um administrador de segurança deve misturar uma parte - se você usar recomendações tais como aquelas dadas por este documento literalmente, você da suas metodologias para a perspectiva do atacante que também tem acesso a este documento.
Esta seção cobre Ataques de Negação de Serviço. Um ataque DoS é tipicamente um ataque de pacote. Enquanto não há muito o que você pode fazer sobre ataques modernos de pacotes falsificados spoofed que saturam sua rede, você pode geralmente limitar os danos assegurando que os ataques não possam derrubar seus servidores.
Limitando server forks.
Limitando ataques springboard (ataques de resposta ICMP, ping broadcast, etc.).
Kernel Route Cache.
Um ataque DoS comum é contra a forking server que tenta fazer com que o servidor coma processos, descritores de arquivos e memória, até que a máquina morra. O inetd (veja inetd(8)) tem diversas opções para limitar este tipo de ataque. Deve-se notar que enquanto é possível impedir que uma máquina caia, não é geralmente possível impedir que um serviço seja interrompido pelo ataque. Leia a página de manual inetd cuidadosamente e preste atenção específica para as opções -c, -C, e -R. Note que ataques de IP falsificados spoofed vão enganar a opção -C para o inetd, assim tipicamente uma combinação de opções deve ser usada. Alguns serviços standalone tem parâmetros self-fork-limitation.
O sendmail tem sua opção -OMaxDaemonChildren, que tende a funcionar muito melhor do que tentando usar opções de limite de carga do sendmail devido ao atraso de carga. Você deve especificar um parâmetro MaxDaemonChildren, quando você inicia o sendmail, alto o bastante para segurar sua carga esperada, mas não tão alto que o computador não pode segurar esse número de sendmails sem cair. É também prudente executar o sendmail no modo de fila (-ODeliveryMode=queued) e executar o daemon (sendmail -bd) separado da execução de filas (sendmail -q15m). Se você ainda quiser entrega em tempo real você pode executar a fila em um intervalo mais baixo, como -q1m, mas esteja certo de especificar uma opção MaxDaemonChildren razoável para esse sendmail para impedir falhas em cascata.
O syslogd pode ser atacado diretamente e recomenda-se fortemente que você use a opção -s sempre que possível, e a opção -a de qualquer forma.
Você deve também ser bastante cauteloso com serviços connect-back tais como o identd reverso do tcpwrapper, que pode ser atacado diretamente. Você geralmente não precisa usar a característica indent reverso do tcpwrappers por esta razão.
É uma idéia muito boa proteger serviços internos do acesso externo por firewalling mantendo-os fora em seus roteadores de borda. A idéia aqui é impedir ataques de saturação de fora da sua LAN, não para proteger serviços internos de um comprometimento root baseado em rede. Configure sempre um firewall exclusivo, isto é, ``firewall em tudo exceto nas portas A, B, C, D, e M-Z''. Desta maneira você pode usar firewall em todas as suas portas baixas exceto para determinados serviços específicos tais como named (se você é primario para uma zona), ntalkd, sendmail, e outros serviços acessíveis via Internet. Se você tentar configurar o firewall de outra maneira - como um firewall inclusivo ou permissivo, há uma boa possibilidade que você esqueça de ``fechar'' um par de serviços, ou que você adicione um novo serviço interno e esqueça de atualizar o firewall. Você pode ainda abrir um range de portas altas no firewall, para permitir operações como permissivas, sem comprometer suas portas baixas. Também tome nota que o FreeBSD permite você controlar o range de portas usado por conexões dinâmicas, através de varios net.inet.ip.portrange do sysctl (sysctl -a | fgrep portrange), que pode também facilitar a complexidade da configuração do seu firewall. Por exemplo, você pode usar um range normal first/last de 4000 a 5000, e um range hiport de 49152 a 65535, e bloquear tudo abaixo de 4000 no seu firewall (exceto para determinadas portas de acesso específicas a Internet, naturalmente).
Um outro ataque DoS comum é chamado um ataque springboard - para atacar um servidor de uma maneira que faça o servidor gerar respostas que sobrecarregue o servidor, a rede local, ou alguma outra máquina. O ataque mais comum desta natureza é o ICMP ping broadcast attack. O atacante falsifica spoofs pacotes ping enviados para o endereço de broadcast da sua LAN com o endereço IP de origem atribuido a máquina real que ele deseja atacar. Se seus roteadores de borda não estiverem configurados para parar ping para endereços de broadcast, sua LAN enrosca gerando respostas suficientes ao endereço de origem falsificado spoofed para saturar a vítima, especialmente quando o atacante usa o mesmo truque em diferentes dúzias de endereços broadcast em cima de diferentes dúzias de redes de uma vez. Ataques de broadcast sobre cento e vinte megabits foram medidos. Um segundo ataque springboard comum é contra os sistemas de relátorios de erro do ICMP. Construindo pacotes que geram respostas de erro ICMP, um atacante pode saturar a rede de entrada do servidor e fazer com que o servidor sature sua rede de saída com respostas ICMP. Este tipo de ataque pode também derrubar o servidor executando mbuf's, especialmente se o servidor não pode tratar as respostas ICMP geradas rápidas o bastante. O kernel do FreeBSD kernel tem uma nova opção de compilação chamada ICMP_BANDLIM que limita a eficácia destes tipos de ataques. A última classe principal de ataques springboard esta relacionada a certos serviços inetd internos tais como o serviço echo udp. Um atacante simplesmente falsifica spoofs um pacote UDP com o endereço de origem sendo a porta echo do servidor A, e o endereço de destino sendo a porta echo do servidor B, onde o servidor A e B estão ambos em sua LAN. Os dois servidores então lançam este pacote para frente e para trás entre si. O atacante pode sobrecarregar ambos os servidores e suas LANs simplesmente injetando alguns pacotes nesta maneira. Problemas similares existem com a porta chargen interna. Um administrador de sistemas competente desligará todos estes serviços internos de teste do inetd.
Ataques de pacotes falsificados spoofed podem também ser usados para sobrecarregar o cache de rotas do kernel. Consulte os parâmetros net.inet.ip.rtexpire, rtminexpire e rtmaxcache do sysctl. Um ataque de pacotes falsificados que usa uma origem IP aleatória fara o kernel gerar um cache de rotas temporário na tabela de rotas, visível com netstat -rna | fgrep W3. Estas rotas tipicamente terminam em 1600 segundos ou menos. Se o kernel detectar que a tabela de rotas cacheadas começou a crescer ele dinâmicamente reduz o rtexpire mas nunca diminui menos do que o rtminexpire. Há dois problemas:
O kernel não reage rápido o suficiente quando um servidor levemente carregado é atacado repentinamente.
O rtminexpire não é baixo o bastante para o kernel sobreviver a um ataque prolongado.
Se seus servidores estiveram conectados a Internet via um T3 ou melhor, pode ser prudente cancelar manualmente o rtexpire e rtminexpire via sysctl(8). Nunca ajuste o parâmetro de um dos dois para zero (a menos que você queira derrubar a máquina). Ajustar ambos os parâmetros para 2 segundos deve ser suficiente para proteger a tabela de rotas de um ataque.
Há alguns casos com Kerberos e ssh que precisam ser dirigidos se você pretente usa-los. Kerberos V é um protocolo excelente de autenticação, mas há falhas nas aplicações kerberizadas telnet e rlogin que as fazem inadequadas para relacionamento com streams binários. Também, por padrão o Kerberos não criptografa uma sessão a menos que você use a opção -x. O ssh criptografa tudo por padrão.
O ssh funciona perfeitamente bem em cada respect exceto que ele envia chaves criptografadas por padrão. O que isto significa é que se você tiver uma estação de trabalho segura guardando chaves que lhe dão acesso ao resto do sistema, e você faz ssh para uma máquina insegura, suas chaves são aproveitadas. As chaves reais não são expostas, mas o ssh instala uma porta de envio para o duração do seu login, e se um atacante violar o root na máquina insegura ele pode utilizar essa porta para usar suas chaves para ganhar acesso a qualquer outra máquina que suas chaves abrem.
Nós recomendamos que você use o ssh em combinação com Kerberos sempre que for possível para logins do sistema. O ssh pode ser compilado com suporte a Kerberos. Isto reduz sua segurança em chaves ssh potênciamente expostas enquanto ao mesmo tempo protege senhas via Kerberos. Chaves ssh devem somente ser usadas para tarefas automatizadas de máquinas seguras (algo que o Kerberos é adequado a fazer). Nós também recomendamos que você desligue o envio de chaves na configuração do ssh, ou que você faça uso da opção from=IP/DOMAIN que o ssh permite em seu arquivo authorized_keys fazer a chave somente aproveitaveis a entidades que fazem login de máquinas específicas.
Este, e outros documentos, podem ser obtidos em ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
Para perguntas sobre FreeBSD, leia a documentação antes de contatar <questions@FreeBSD.org>.
Para perguntas sobre esta documentação, envie e-mail para <doc@FreeBSD.org>.