Segurança no Servidor

[helldanger1]

Segurança é um tópico bastante abrangente, que rende livros inteiros. Justamente por isto, o propósito deste capítulo não é ser um guia absoluto de segurança, mas mostrar como aumentar a segurança de seu Conectiva Linux e explicar como funcionam alguns componentes básicos.

 

[helldanger1]

Visão Geral sobre Segurança




Atualmente, conectar redes locais à Internet é algo bastante comum e, embora isto possa trazer vantagens, também pode trazer vários problemas. Infelizmente, fazer parte da Internet significa estar exposto a uma grande variedade de ameaças, o que obriga todo e qualquer administrador a preocupar-se com a segurança de seus sistemas. Enquanto redes existem para facilitar o acesso a computadores, procedimentos de segurança existem para controlar este acesso.

O primeiro conceito relacionado a segurança é: "não existe sistema completamente seguro". O que é possível fazer é dificultar a invasão em sua máquina e, caso uma invasão ocorra, conseguir descobrir como ela ocorreu e tomar medidas preventivas. O trabalho necessário para proteger o seu sistema dependerá basicamente do que você tem para proteger e o quão importante é proteger este sistema.

Note que, de um modo geral, quanto mais seguro você tornar o seu sistema, mais complexa será sua utilização, pois existirão várias restrições de uso. É imprescindível usar o bom senso na hora de aplicar as medidas de segurança, para evitar que a terapia seja pior que a doença.

Antes de tomar qualquer atitude relacionada ao aumento da segurança de seu sistema, você deve saber o que está sendo protegido, por que e quanto vale esta informação. Além disso, é necessário verificar a que tipo de ameaças seu sistema está exposto. A RFC 1244, intitulada Site Security Handbook, por Holbrook Reynold e outros, identifica três tipos distintos de ameaças de segurança geralmente associadas à conectividade em rede:

Acesso não autorizado:
Acesso ao sistema por uma pessoa não autorizada.

Revelação de informações:
Qualquer problema relacionado ao acesso a informações valiosas ou confidenciais por pessoas que não deveriam acessá-las.

Negação de Serviço:
Também conhecido como Denial of Service - DoS - relacionado a qualquer problema que torne impossível ou bastante difícil continuar utilizando o sistema de maneira produtiva.

 

[helldanger1]

Dependendo do sistema em questão, estas ameaças podem ser mais ou menos importantes. Por exemplo, para um órgão governamental ou empresa da área de tecnologia, acessos não autorizados podem desacreditá-los perante o público e/ou clientes. Já para a grande maioria das empresas, acesso não autorizado não é um grande problema, se não envolver uma das ameaças: revelação de informações e negação de serviço.

A extensão do problema em casos de revelação de informação varia de acordo com a informação que pode ser comprometida. Embora seja fato notório que informações sigilosas jamais devam permanecer armazenadas em máquinas conectadas à Internet, em alguns casos certos tipos de informação, como informações pessoais de clientes e/ou números de cartões de crédito, podem ser necessários em aplicações de comércio eletrônico, por exemplo. Neste tipo de caso, o cuidado deve ser redobrado.

A negação de serviço pode causar grandes prejuízos a empresas que conectam sistemas de missão crítica à Internet. Na verdade, as vantagens devem ser muito bem avaliadas antes de conectar este tipo de sistema à Internet, pois, dependendo do caso, esta conexão pode parar uma empresa por inteiro. Geralmente servidores menores são conectados à Internet, possivelmente acessando informações de um servidor principal através de um modo mais seguro.

Obviamente que, se a necessidade é justamente prestar um serviço na Internet, todos estes riscos existirão. Para diminuí-los é preciso tomar algumas precauções, como desabilitar os serviços desnecessários, utilizar controle de acesso através de ferramentas como o tcp_wrappers, instalar e configurar um firewall entre sua rede local e redes externas (geralmente entre sua rede local e a Internet). É também importante analisar constantemente os logs e a integridade de arquivos importantes do sistema, além de analisar alternativas como a instalação de um servidor Kerberos. O Conectiva Linux conta com as ferramentas necessárias para ajudá-lo na tarefa de tornar seu sistema mais seguro.

Finalizando esta introdução, manter um sistema seguro envolve vários procedimentos, sendo que o mais importante é manter uma monitoração constante do sistema, para notar qualquer anormalidade antes que ela se torne um problema grave.

 

[helldanger1]

Particionamento do HD do Servidor



No Linux, e em todos os sistemas UNIX, existe o que se chama de transparência de localidade. O diretório /usr, por exemplo, pode ser local da máquina, ou montado via NFS de um servidor que está em outro lugar. Para todos os efeitos, é como se fosse local. Assim como esse diretório pode estar em outra máquina, ele também pode estar em outro meio físico, como um segundo disco rígido ou uma outra partição no mesmo disco.

Há várias vantagens, e algumas poucas desvantagens, em se usar um esquema de particionamento. Serão vistos aqui alguns aspectos do particionamento do disco rígido de um servidor Linux, tendo em vista aspectos de segurança.

 

[helldanger1]

Disco Cheio




A proteção mais básica que se consegue com um bom esquema de particionamento é com relação ao problema de disco cheio. Para partições que armazenam dados de usuários, como a /home ou a de e-mail, isso pode ser contornado até certo ponto com o uso de quotas (ver a seguir). Mas, por exemplo, o diretório de logs, /var/log, é usado pelo sistema, e não por um usuário específico (usuário aqui no sentido de pessoa). Se não houvesse particionamento, o único limite para o tamanho desses arquivos seria o HD inteiro. Se, por exemplo, um ataque inundar os logs, se o disco estiver corretamente particionado isso somente afetará a partição dos logs: os usuários ainda terão o mesmo espaço livre no /home, o espaço para programas continuará o mesmo, etc. O mesmo vale para o outro sentido. Se não houver sistema de quotas, usuários poderão criar arquivos de qualquer tamanho e simplesmente acabar com o espaço em disco. Se houver particionamento, no máximo acabarão com o espaço em disco daquela partição.

 

[helldanger1]

Quotas



No Linux, quotas de disco são aplicadas por partição. Se houver somente uma partição no disco (a partição /, por exemplo), as quotas somente se aplicarão a ela por inteiro. Não há como definir quotas para diretórios específicos, a não ser que eles sejam pontos de montagem de alguma outra partição. Usando quotas, podemos definir alguns limites interessantes para usuários e/ou grupos. O sistema de quotas trabalha com os seguintes limites:

soft limit: ao atingir este limite, o usuário infrator é avisado via e-mail e possui um período de tempo para voltar a ficar abaixo do limite;

grace period: período em que o usuário pode ficar acima do soft limit. Após este período, o usuário não poderá mais criar arquivos nesta partição, devendo remover algo para voltar a ficar abaixo do limite;

hard limit: é o limite que jamais será ultrapassado. Por exemplo, um usuário pode ultrapassar o soft limit e receber o aviso, mas continuar a aumentar o espaço ocupado no disco, ignorando o aviso. Mas do hard limit ele não poderá passar.

O pacote quotas possui diversos utilitários para manipular as quotas, mas o Linuxconf possui uma interface bastante agradável para fazer a mesma coisa. Antes de poder usar as quotas é necessário ativar seu suporte na hora de montar o sistema de arquivos. Na prática, o Linuxconf alterará o /etc/fstab para isso, e depois as funções de quotas poderão ser manipuladas à vontade.

 

[helldanger1]

Opções especiais de Montagem




Esta é a parte do particionamento que é mais interessante do ponto de vista de segurança. Pode-se fazer com que o sistema trate certos arquivos de forma diferente com uma série de opções. As opções de montagem podem ser fornecidas como parâmetro para o comando mount ou direto no arquivo /etc/fstab:

Via linha de comando:# mount /dev/hda6 -t ext3 -o nosuid,nodev /mnt/tmpPelo arquivo:/dev/hda6 /mnt/tmp ext3 nosuid,nodev 0 0


A Tabela 7-1 ilustra algumas opções existentes para sistemas de arquivos dos tipos mais comuns (como ext2, ext3 e reiserfs). Outras, marcadas com um asterisco (*), também estão disponíveis para qualquer sistema de arquivos.

Tabela 7-1. Opções para sistemas de arquivos ext2

 

[helldanger1]

Opção
Efeito

nodev(*)
Dispositivos especiais de bloco ou caractere do sistema de arquivos não serão interpretados se nodev estiver especificado.

nosuid(*)
Bits SUID e SGID não terão efeito. Se um usuário comum executar um programa SUID ou SGID que force a troca para outro usuário, receberá o erro de permissão negada.

noexec(*)
Não permite a execução de binários. Note que scripts ainda poderão ser executados usando, por exemplo, bash foo.sh em vez de ./foo.sh (há ainda outras formas de contornar esta proibição, como, por exemplo, utilizar o loader ld.so).

ro, rw
A partição será montada somente para leitura (read-only) ou somente para escrita (read-write), respectivamente.

user, nouser(*)
A partição pode (user) ou não (nouser) ser montada por usuários que não sejam root.

usrquota
Ativa a quota de disco por usuário.

grpquota
Ativa a quota de disco por grupo.

grpid
Com esta opção ativada, arquivos criados nesta partição terão o group ID do diretório onde eles foram criados. Caso contrário, terão o group ID do processo que os criou. Este comportamento também pode ser obtido se o bit SGID do diretório estiver ligado.

sync(*)
Toda a operação de entrada e saída nesta partição será síncrona. Isto tornará a escrita nesta partição mais lenta, mas também menos suscetível a problemas caso, por exemplo, falte energia elétrica logo após a operação de escrita. Numa operação assíncrona, os dados provavelmente ainda não foram escritos neste exemplo.

 

[helldanger1]

Estas opções são muito interessantes e se aplicam a diversas partições do nosso servidor. A seguir serão mostrados alguns exemplos de uso dessas opções em diferentes partições:

/usr: nodev,ro
Nesta partição se encontram normalmente os programas do sistema. De forma alguma devem existir arquivos de dispositivo aqui, por isso foi colocada a opção nodev. Também não deve ser necessário escrever nesta partição, salvo instalação ou remoção de algum programa. Nestes casos, ela deve ser remontada com a opção rw e depois novamente remontada com a opção read-only. Note que os direitos dos diretórios por si só já não permitem a qualquer usuário realizar operações de escrita ali, mas o read-only é uma medida adicional, pois nem o usuário root poderá alterar algo ali antes de remontar a partição como read-write.

/dev: nosuid,noexec
Estas duas opções são até certo ponto redundantes, mas mesmo assim é bom especificá-las. A primeira, nosuid, não permite a execução de binários SUID ou SGID. A segunda não permite a execução de qualquer binário. Na verdade, há o script MAKEDEV neste diretório, mas ele ainda poderá ser executado usando bash ./MAKEDEV.

/var: noexec,nosuid,nodev
O diretório /var é usado para guardar e-mails, arquivos de log, dados de programas (banco de dados RPM, por exemplo) e outras coisas. Mas /var/tmp pode ser utilizado pelo processo de compilação de um pacote RPM para guardar os scripts que serão usados. Se noexec for usado, esses scripts não funcionarão. Portanto, use noexec com cuidado. Alguma aplicação pode ter o funcionamento comprometido. Uma outra opção é colocar /var/tmp em uma outra partição, e permitir a execução nesta.

/tmp: noexec,nosuid,nodev
O diretório /tmp pode ser usado para qualquer coisa basicamente. Scripts temporários podem ser colocados ali, por exemplo. Como é um diretório com permissões de escrita para qualquer usuário, basicamente deve-se proibir a execução de binários SUID/SGID através da opção nosuid. Também não há motivo para se usar arquivos de dispositivos aqui, por isso o uso da opção nodev. Eventualmente noexec também pode ser usado, mas alguns programas podem necessitar de um /tmp que permita a execução de programas.

/boot: noexec,nosuid,nodev,ro
Esta partição possui bem pouca atividade no sistema. Na verdade, após o boot (que nem sabe o sistema de arquivos que roda ali, quanto menos opções de montagem da partição), ela só é usada quando se faz uma atualização do kernel ou da imagem de disco inicial (initrd). Nada deve ser executado ali, arquivos de dispositivos não são bem-vindos e ela deve ser montada read-only. Quando se fizer uma atualização do kernel, basta remontá-la com a opção read-write.

/home: nosuid,nodev,noexec
Aqui depende do administrador da máquina quais das opções acima serão usadas. Recomenda-se pelo menos usar nosuid e nodev. Pode-se ainda usar a opção noexec, mas o usuário sempre poderá executar binários, bastando, por exemplo, copiá-los para o /tmp[1].

 

[helldanger1]

Segurança básica local




Nesta parte será visto como funciona a autenticação em uma máquina Linux: que tipos de senhas pode-se usar (com que tipo de criptografia), como verificar se as senhas são boas ou fáceis e como funcionam as permissões do sistema de arquivos, tudo isso com vários exemplos. Além disso, também serão vistos os logs ou registros do sistema: onde eles são gerados, como organizá-los, etc.

 

[helldanger1]

PAM



PAM é a parte principal da autenticação em um sistema Linux. PAM significa Pluggable Authentication Modules ou Módulos de Autenticação Plugáveis/Modulares.

Originalmente a autenticação no Linux era apenas via senhas criptografadas armazenadas em um arquivo local chamado /etc/passwd. Um programa como o login pedia o nome do usuário e a senha, criptografava a senha e comparava o resultado com o armazenado naquele arquivo. Se fossem iguais, garantia o acesso à máquina. Caso contrário, retornava erro de autenticação. Isto até funciona muito bem para o programa login, mas, suponha que agora deseja-se usar isso também para autenticação remota, ou seja, a base de usuários não está mais na mesma máquina, mas sim em alguma outra máquina da rede, o chamado servidor de autenticação. Será preciso mudar o programa login para que ele também suporte esse tipo de autenticação remota.

Suponha também que surgiu um novo algoritmo de criptografia, muito mais avançado, mais rápido, criptografa melhor, etc., sendo que o desejo é usar esse novo algoritmo. Deve-se, então, mudar novamente o programa login para que ele suporte este novo algoritmo também. No Linux, muitos programas utilizam algum tipo de autenticação de usuários. Imagine se todos eles tivessem que ser reescritos cada vez que se mudasse algum dos critérios de autenticação.

Para resolver este tipo de problema, a Sun® criou o PAM há alguns anos e liberou as especificações em forma de RFC. O Linux derivou sua implementação do PAM a partir deste documento. Com PAM, o aplicativo login deste exemplo teria que ser reescrito apenas uma vez, justamente para suportar PAM. A partir de então, o aplicativo delega a responsabilidade da autenticação para o PAM e não se envolve mais com isso.

Voltando ao exemplo anterior, no caso de se querer utilizar um outro algoritmo de criptografia para as senhas, basta que o módulo PAM seja modificado para que todos os aplicativos automaticamente e de forma transparente passem a usufruir desta nova forma de autenticação. PAM possui uma outra vantagem: é possível configurar a autenticação de forma individual para cada aplicativo. Com isto é possível fazer com que, por exemplo, um usuário comum possa usar os dispositivos de áudio do computador desde que tenha se logado na máquina através do console. Se o login não tiver sido feito no console (por exemplo, é um login remoto via SSH), este tipo de acesso ao hardware será negado.

 

[helldanger1]

Na verdade, PAM vai um pouco além da autenticação. Os módulos podem ser divididos em quatro classes:

auth:
É a parte que verifica que o usuário é realmente quem ele diz que é. Pode ser bem simples, pedindo apenas por um nome e uma senha, ou utilizando autenticação biométrica, por exemplo (como uma impressão de voz, uma imagem da retina ou impressão digital).

account:
Esta parte verifica se o usuário em questão está autorizado a utilizar este serviço ao qual ele está se autenticando. Os módulos aqui podem verificar por horário, dia da semana, origem do login, login simultâneo, etc.

passwd:
Este serviço é usado quando se deseja mudar a senha. Por exemplo, aqui podem ser colocados módulos que verificam se a senha é forte ou fraca.

session:
Por fim, a parte session fica encarregada de fazer o que for necessário para criar o ambiente do usuário. Por exemplo, fornecer o acesso a alguns dispositivos locais como o de áudio ou CD-ROM, montar sistemas de arquivos ou simplesmente fazer o registro do evento nos arquivos de log do sistema.

Um módulo PAM pode ou não conter todas estas funções. O módulo pam_unix, por exemplo, pode ser usado nestes quatro tipos e possui ações diferentes em cada uma das situações, enquanto que pam_console é normalmente usado apenas como session.

Instalação
Os módulos PAM já vêm instalados por padrão no Conectiva Linux. Você pode verificar utilizando o comando apt-getprocurando, ou na lista de pacotes instalados do Synaptic, pelo pacote pam, sendo que a documentação está no pacote com nome pam-doc.

 

[helldanger1]

PAM no Linux
Praticamente todos os aplicativos do Linux que requerem algum tipo de autenticação suportam PAM. Na verdade, não funcionam sem PAM. Toda a configuração está localizada no diretório /etc/pam.d. Quando um aplicativo suporta PAM, ele necessita de um arquivo de configuração neste diretório. A Figura 7-1 ilustra como funciona a autenticação com PAM usando o programa login como exemplo:

Figura 7-1. Autenticação com PAM

 

[helldanger1]

Um programa com suporte a PAM possui duas interfaces com a biblioteca: a de autenticação e a de conversação. A interface de autenticação é por onde a aplicação pede que o PAM valide o usuário. A de conversação é usada pelos módulos que, por exemplo, precisem passar alguma informação para o usuário, como um prompt, ou um aviso de que a senha expirou. Isso é tudo o que a aplicação sabe sobre o processo de autenticação feito pelo PAM. A conversação está ilustrada na figura no módulo pam_unix (b).

Nota: Somente instalações mais recentes utilizam o módulo pam_unix para praticamente todos os serviços. Versões antigas do Conectiva Linux podem, ainda, utilizar o módulo pam_pwdb.so.

A biblioteca PAM vai procurar o arquivo de configuração da aplicação login. Este arquivo é /etc/pam.d/login e vai dizer quais módulos devem ser usados e com que parâmetros. Este arquivo está reproduzido a seguir:

#%PAM-1.0auth required /lib/security/pam_securetty.soauth required /lib/security/pam_unix.so nullokauth required /lib/security/pam_nologin.soaccount required /lib/security/pam_unix.sopassword required /lib/security/pam_cracklib.sopassword required /lib/security/pam_unix.so shadow nullok \use_authtoksession required /lib/security/pam_unix.sosession optional /lib/security/pam_console.so



Atenção
É importante ressaltar que este arquivo é somente um exemplo, podendo ser diferente do que estiver contido em sua máquina.


Este arquivo de configuração lista os módulos PAM que este programa (login) deve usar, e eles estão representados na figura através de letras. Estes módulos serão carregados e executados na ordem em que estiverem no arquivo de configuração. Note que um módulo pode aproveitar uma informação de um módulo anterior, como normalmente é feito para o nome de acesso/senha. Isso é usado para não pedir a mesma informação novamente para o usuário.

A primeira coluna em um arquivo de configuração PAM representa o tipo de módulo: auth, account, password ou session. Neste exemplo, todos estão presentes, mas isto não é obrigatório. Se um programa não tiver suporte à troca de senha, o tipo password não é usado.

A segunda coluna define o controle para o seu respectivo módulo. O resultado de cada módulo pode influenciar de diversas formas no resultado do processo de autenticação geral. Há algumas categorias:

required:
O resultado deste módulo influencia diretamente o resultado final. Uma falha em um módulo deste tipo só aparecerá para o usuário após todos os outros módulos desta classe serem executados.

requisite:
Semelhante a required, mas os outros módulos não são executados e o controle volta imediatamente para o aplicativo em caso de falha.

sufficient:
A falha deste módulo não implica em falha da autenticação como um todo. Se o módulo falhar, o próximo da classe é executado. Se não houver próximo, então a classe retorna com sucesso. Se, por outro lado, o módulo terminar com sucesso, então os módulos seguintes dessa classe não serão executados.

optional:
Os módulos marcados como optional praticamente não influenciam o resultado da autenticação como um todo. Eles apenas terão alguma influência caso os módulos anteriores da mesma classe não apresentem um resultado definitivo.

Por fim, a terceira coluna define o nome do módulo que será usado e seus parâmetros. Todos os módulos estão documentados no diretório /usr/share/doc/pam-doc-versão (pacote pam-doc). Será visto aqui apenas ilustrar como funcionam os usados no programa login.

Em primeiro lugar, observa-se que todos os módulos possuem o parâmetro required, ou seja, não podem falhar (com exceção do pam_console).

 

[helldanger1]

pam_securetty



Este é o primeiro módulo a ser usado e ele simplesmente verifica o terminal de onde o login está ocorrendo. Este módulo não usa parâmetros, mas possui um arquivo de configuração: /etc/securetty. Neste arquivo são listados os terminais a partir dos quais o usuário root pode fazer login, ou seja, são os terminais considerados seguros. Apesar do nome terminais, conexões remotas também são controladas por aqui, pois elas alocam pseudo-terminais (telnet, etc). O módulo retorna sucesso para qualquer usuário diferente de root e, se for root, somente se o terminal de onde está vindo o login estiver listado em /etc/securetty. Para permitir o login de root via telnet, por exemplo, basta acrescentar ao /etc/securetty pts/0. Note que isto somente liberará o pseudo-terminal pts/0. Veja no exemplo seguir:

$ telnet localhostTrying 127.0.0.1...Connected to localhost.Escape character is '^]'.Conectiva Linux 9Kernel 2.4.20-26373cllogin: rootPassword: # telnet localhost Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.Conectiva Linux 9Kernel 2.4.20-26373cllogin: rootPassword: Login incorrectlogin:

A primeira conexão telnet ganhou o pseudo-terminal pts/0. Já a segunda teve o pts/1 alocada para si, e este pseudo-terminal não estava listado no arquivo /etc/securetty. Portanto, o acesso não foi autorizado. Isto não funciona com SSH, por exemplo, pois o módulo pam_securetty não está presente ali. O SSH possui seu próprio mecanismo de acesso para o usuário root, mas nada impede que o pam_securetty seja acrescentado no arquivo PAM. O módulo pam_securetty também pode ser usado para controlar o login a partir do ambiente gráfico, por exemplo. Basta acrescentar o módulo ao arquivo /etc/pam.d/kde (se o kdm estiver sendo usado para login gráfico). A linha a ser acrescentada ao arquivo /etc/securetty (além de se acrescentar pam_securetty aos respectivos arquivos PAM) é :0. Isto para o display zero. Para permitir o login de root em outros displays, a sintaxe é ISPLAY .

O objetivo original deste módulo é o de evitar o login do root em terminais inseguros. Este conceito de terminais foi estendido ao login remoto (através dos pseudo-terminais).

 

[helldanger1]

pam_unix



O módulo pam_unix é o módulo principal da autenticação do programa login e da maioria dos serviços que utilizam PAM. Ele vai pedir um nome de usuário e uma senha e verificar se estão corretos. Como tal, o módulo utiliza a função de conversação para interrogar o usuário e pegar as informações desejadas.

Este módulo aceita alguns parâmetros, conforme seu uso (auth, account, etc.):

shadow: avisa o módulo que o sistema está utilizando senhas shadow.

nullok: permite o uso de senhas em branco. Note que, mesmo que a senha seja em branco (nula), o usuário não conseguirá fazer login se não existir nullok na linha auth para este módulo.

md5: usa criptografia (hash) md5 em vez do crypt padrão. Pode ser usado na linha password.

use_authtok: indica que o módulo deve usar a autenticação já fornecida para os módulos anteriores, de forma a não interrogar o usuário novamente. Alguns outros módulos suportam o parâmetro use_first_pass, que funciona da mesma forma. Existe ainda o try_first_pass, que primeiro tenta as mesmas credenciais: se houver falha, pede novamente para o usuário. O use_first_pass não faz esse novo pedido caso ocorra uma falha.

O try_first_pass será usado mais adiante quando for mostrada a autenticação via LDAP. O módulo pam_unix é bem genérico por usar as funções da glibc e, portanto, suporta NIS, LDAP, arquivos texto, arquivos binários e qualquer outra coisa que a glibc vier a suportar (através de NSS).

 

[helldanger1]

pam_nologin



O módulo pam_nologin é bastante simples, e muito útil. É uma forma rápida de desabilitar o login de qualquer usuário que não seja o root. Para isto, basta criar o arquivo /etc/nologin. Existindo este arquivo, o módulo pam_nologin vai sempre retornar ERRO para usuários diferentes de root e exibir o conteúdo de /etc/nologin (onde se deve colocar o motivo da proibição), ou seja, só o usuário root consegue se logar na máquina. Quando o arquivo for removido, a operação voltará ao normal, com usuários comuns podendo se logar novamente. Isto pode ser útil quando se quer fazer alguma manutenção no sistema, por exemplo, situação em que logins de usuários são indesejáveis. Alguns aplicativos do próprio Linux também podem criar este arquivo e depois removê-lo quando alguma operação crítica for concluída.

Note que os usuários que já estiverem logados na máquina não são afetados pela criação ou remoção do arquivo /etc/nologin.

 

[helldanger1]

pam_cracklib



Este módulo é especialmente importante para a segurança pró-ativa. Colocado apenas na classe password, o módulo vai verificar a senha do usuário antes que ela seja trocada. Se for uma senha considerada fraca, ela será rejeitada e o usuário não conseguirá trocar a senha. As verificações que o módulo faz atualmente são:

palíndromo: a nova senha é um palíndromo (frase que tem o mesmo sentido da esquerda para a direita ou ao contrário)?

caixa: a senha nova é a antiga com apenas mudanças de maiúsculas/minúsculas?

similar: a nova senha é muito similar à antiga? Esta verificação pode ser controlada por um parâmetro que indica o número mínimo de caracteres diferentes que a senha nova deve ter em relação à senha antiga. O valor padrão é 10 ou metade do tamanho da senha atual, o que for menor.

Senha repetida: se existir o arquivo /etc/security/opasswd com as senhas anteriores do usuário, o módulo pam_cracklib vai também verificar se a senha nova já não foi usada anteriormente. Esse arquivo de senhas antigas é atualmente gerado apenas pelo módulo pam_unix, embora exista uma discussão para se criar um módulo específico para esta tarefa (algo como pam_saveoldpass) e remover esta funcionalidade do módulo pam_unix.

Os parâmetros normalmente utilizados com o módulo cracklib são:

retry=N
"N" é o número de tentativas que o usuário poderá fazer para fornecer uma senha considerada boa.

difok=N
"N" é o número de letras diferentes que a senha nova deve ter em relação à senha antiga. Este parâmetro controla o comportamento da verificação do tipo similar, visto há pouco. O valor padrão é 10 (e este é o valor alterado por "N" ou metade do tamanho da senha atual), aquele que for o menor.

minlen=N
Tamanho mínimo da nova senha mais um. Além de contar a quantidade de caracteres da senha nova, créditos também podem ser fornecidos com base na quantidade de algarismos, caracteres maiúsculos/minúsculos e símbolos. Ou seja, se o valor de minlen for 10, o usuário pode usar uma senha com menos do que 10 caracteres, desde que, somando a quantidade de caracteres mais os créditos, o valor final ultrapasse 10. Por exemplo:

password required /lib/security/pam_cracklib.so retry=3 minlen=10


Especifica-se um tamanho mínimo de 9 para a senha nova. Portanto, uma senha igual a senharuim vai funcionar (possui nove caracteres). Mas uma senha igual a am0Bb$ também funcionará, apesar de possuir apenas 6 caracteres, isto por causa dos créditos.

am0Bb$=>6+1(B, maiúscula)+1(0, dígito)+1($, símbolo)= 9=>OK,passará.


Por outro lado:

am0Bbd => 6 + 1(B, maiúscula) + 1(0, dígito) = 8 => não passará.


Por padrão, cada um dos tipos de variação da senha (minúsculo, maiúsculo, algarismo e símbolo) conta no máximo um crédito, ou seja:

am0b9$ => 6 + 1(0, dígito) + 1 ($, símbolo) = 8 => não passa


Note que o uso de dois algarismos não ajudou em termos de créditos. Mas isto pode ser mudado se for passado um outro parâmetro para o módulo:

password required /lib/security/pam_cracklib.so retry=3 \ minlen=10 dcredit=2


Através do parâmetro dcredit estipula-se que será tolerado no máximo dois créditos provenientes de algarismos na senha. Com esta alteração, a senha am0b9$ passará como válida pois usa dois algarismos e então atingirá o mínimo de 9 exigido por esta configuração do módulo. Estes parâmetros de créditos também existem para as outras variantes:

dcredit: número máximo de créditos fornecidos provenientes do uso de algarismos na senha. O valor padrão é 1.

ucredit: número máximo de créditos fornecidos provenientes do uso de letras maiúsculas na senha. O valor padrão é 1.

lcredit: número máximo de créditos fornecidos provenientes do uso de letras minúsculas na senha. O valor padrão é 1.

ocredit: número máximo de créditos fornecidos provenientes do uso de outros caracteres (símbolos) na senha. O valor padrão é 1.

 

[helldanger1]

pam_console



O objetivo do módulo pam_console é permitir ao usuário local (ou seja, no console, fisicamente na máquina) o acesso a diversos dispositivos normalmente restritos ao superusuário, como placa de som, dispositivo de disquete e também permitir ao usuário comum (local) executar certas tarefas, como desligar o computador, entrar no ambiente gráfico ou mesmo instalar pacotes RPM.

Essa capacidade adicional é fornecida ao usuário no seu primeiro login é removida após o último logout, e se dá através da modificação das permissões de alguns dispositivos e também através de autenticação.

Diz-se que o primeiro usuário que fizer login no console "ganha" o console e as permissões definidas no arquivo de configuração /etc/security/console.perms. Quando um usuário possui o console, um arquivo de lock é criado em /var/lock com o nome console.lock. O conteúdo do arquivo é o nome do usuário que possui o console. Se um outro usuário local fizer um login, ele não receberá o console, pois já existe um bloqueio indicando que o console pertence a outro usuário. Quando o usuário do console sair, o arquivo de lock será removido e o console novamente ficará à disposição do primeiro usuário (não root) que fizer o login.

Quando um usuário recebe o console, várias permissões são alteradas no sistema de arquivos, conforme indicado no arquivo de configuração deste módulo PAM. Note que este módulo está como optional, ou seja, não é usado para o sucesso ou não da autenticação do usuário. Isso é necessário, pois ele pode falhar (um outro usuário já possui o console, por exemplo).

A seguir, um arquivo de configuração típico (sem os comentários maiores):

# file classes -- these are regular expressions<console>=tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9]<xconsole>=:[0-9]\.[0-9] :[0-9]# device classes -- these are shell-style globs<floppy>=/dev/fd[0-1]*<sound>=/dev/dsp* /dev/audio* /dev/midi* /dev/mixer* /dev/sequencer<cdrom>=/dev/cdrom<pilot>=/dev/pilot<jaz>=/dev/jaz<zip>=/dev/zip<fb>=/dev/fb /dev/fb[0-9]*<kbd>=/dev/kbd<joystick>=/dev/js*<v4l>=/dev/video* /dev/radio* /dev/winradio* /dev/vtx* /dev/vbi*# permission definitions<console> 0660 <floppy> 0660 root.floppy<console> 0660 <sound> 0660 root.audio<console> 0660 <cdrom> 0660 root.cdrom<console> 0600 <pilot> 0660 root.tty<console> 0600 <jaz> 0660 root.disk<console> 0600 <zip> 0660 root.disk<console> 0600 <fb> 0600 root<console> 0600 <kbd> 0600 root<console> 0600 <joystick> 0600 root<console> 0600 <v4l> 0600 root<xconsole> 0600 /dev/console 0600 root.root


Em primeiro lugar, esta configuração define classes de arquivos e classes de dispositivos. Por fim, especifica como devem ser as permissões quando o usuário ganhou o console e quando faz logout. Por exemplo, os dispositivos do tipo floppy devem ter permissão 0660 com o dono sendo o usuário (o grupo não é alterado), e 0660 com donos root.floppy após o logout do usuário. Este tipo de esquema de permissões permite, por exemplo, que o usuário formate um disquete sem que seja necessário obter direitos de root na máquina.

 

[helldanger1]

Usando LDAP juntamente com PAM




Aqui será mostrado um exemplo rápido de como modificar o arquivo de configuração PAM para o programa login passar a suportar LDAP também. Note que isto não é suficiente para se ter um sistema completamente dependente do LDAP, para isso ainda é necessário o módulo nss_ldap, que nada tem a ver com PAM. O arquivo modificado fica da seguinte forma:

#%PAM-1.0auth required /lib/security/pam_securetty.soauth required /lib/security/pam_nologin.soauth sufficient /lib/security/pam_unix.so shadow nullok md5 \ use_authtokauth required /lib/security/pam_ldap.so use_first_passaccount sufficient /lib/security/pam_unix.soaccount required /lib/security/pam_ldap.sopassword required /lib/security/pam_cracklib.sopassword sufficient /lib/security/pam_unix.so nullok use_authtok \ md5 shadowpassword required /lib/security/pam_ldap.so use_first_passsession optional /lib/security/pam_console.sosession sufficient /lib/security/pam_unix.sosession required /lib/security/pam_ldap.so


O módulo pam_securetty fica inalterado, pois ainda deseja-se controlar os terminais por onde o usuário root pode fazer login. Na verdade, o usuário root nem estará no banco de dados LDAP(usuários de sistema devem sempre ser locais). O mesmo para o módulo pam_nologin: permanece inalterado.

Existem, portanto dois módulos responsáveis pela autenticação: pam_unix e o módulo pam_ldap; deseja-se que usuários locais e remotos possam se autenticar nesta máquina. Para usá-los simultaneamente, colocam-se flags de controle.

Primeiramente, coloca-se o módulo pam_unix, pois se o usuário for local, poupa-se uma consulta ao servidor LDAP. Deve-se marcar este módulo como sufficient, ou seja, se ele for bem-sucedido (se o usuário for local e a senha estiver correta) então nenhum outro módulo desta classe (auth) será executado. Se o resultado não for OK (o usuário só existe no LDAP, ou então ele errou a senha), então o próximo módulo será tentado.

O módulo seguinte é justamente o pam_ldap. Nesta configuração coloca-se o parâmetro required, ou seja, se ele falhar, a autenticação como um todo falha também. Para não pedir a senha novamente para o usuário, aproveita-se a senha já fornecida antes e utiliza-se o parâmetro use_first_pass. Este parâmetro diz para o módulo pam_ldap para pegar a senha fornecida anteriormente. Se ela estiver incorreta, o módulo falha. Se fosse usado, por exemplo, o parâmetro try_first_pass em seu lugar, no caso de haver falha o módulo pam_ldap novamente pediria a senha para o usuário.

O mesmo truque do sufficient e required pode ser aplicado às outras classes: account, password e session. A classe session possui ainda uma pequena alteração no posicionamento do módulo pam_console. Como nada mais é executado após um módulo marcado como sufficient ter sido bem-sucedido, o pam_console não seria chamado se ficasse no fim do arquivo, como na configuração original para o programa login. Assim, ele é colocado no início.