>_Pam

PAM

(acrônimo para o inglês Pluggable authentication modules) são mecanismos para a integração de múltiplos esquemas de baixo-nível (autenticação) com uma API de alto nível que permite que programas que necessitam de autenticações sejam escritos independentemente destes esquemas disponibilizados. O desenvolvimento inicial do PAM aconteceu em 1996 pela Sun Microsystems e atualmente é suportado nos sistemas operacionais AIX, HP-UX, Solaris, Linux, FreeBSD, Mac OS X e NetBSD.

A estrutura plugável do PAM é uma das razões para o uso de ligação dinâmica em programas. Porém, há a necessidade de um mecanismo de recuperação em caso de problemas com o ligador ou com as bibliotecas compartilhadas.

Como o padrão XSSO difere tanto da API original (criada pela Sun) como das várias outras implementações, não se pode dizer que o PAM opera da mesma forma em todas as suas versões. Por isso, o projeto OpenBSD decidiu adotar a Autenticação BSD, uma alternativa originada do sistema operacional BSD.

Além disso, com o PAM é possível controlar horários e terminais disponíveis paa logins, quais serão os usuários que podem efetuar um “su” no sistema operacional, autenticar em bases de dados diferentes, além de outros módulos que estão dispoíveis no seguinte endereço:

http://www.kernel.org/pub/linux/libs/pam

Módulos – Categorias

O PAM trabalha com módulos e controles, e cada tipo de módulo provem uma funcionalidade diferente dentro do sistema. Irei comentar primeiro os módulos:

  • account: Verifica se a conta é valida no sistema, se a password do usuário exprirou e se o usuário realmente tem direitos de acessar aquiele serviço.
  • authentication: Verifica questões de autenticação, seja por senha ou impressões digitais (quando biometria). É o módulo authentication que oferece a flexibilidade do PAM, já que, para cada método de autenticação criado, exise uma biblioteca que será adicionada à este módulo.
  • password: Este módulo é responsável por cuidar dos aspectos relacionados a tarefas envolvendo senhas, como atualização e solicitação de nova senha de acesso no caso da troca da mesma.
  • session: Responsável por tarefas pós autenticação, como montar um compartilhamento de arquivos remotos que contém o diretório /home do usuário em questão, por exemplo.

Controles

Além dos módulos, existem também os controles.

  • required: Checa a existência do módulo solicitado, caso esse módulo falhe, somente depois deverificar todos os módulos do mesmo tipo disponíveis é que o usuário será avisado.
  • requisite: Checa a existência do módulo solicitado e avisa o usuário imediatamente caso este módulo falhe.
  • sufficient: Somente a verificação do módulo é suficiente para a autenticação, desde que nhenhum módulo marcado como required falhe.
  • optional: O sucesso ou falha deste módulo não interfere no processo de autenticação (muito perigoso este método).

Importante saber:

É possível colocar dois tipos de controle dentro do PAM, podendo ter um (required e um requisite), só que no momento da verificação na autenticação de um módulo (categoria), somente um controle será verificado. Agora se existir dois controles iguais (requesite e requisite) é possível se autenticar em em qualquer um dos módulos (categoria).

Exemplos:

Categoria – Controle – Módulo

auth – required – pam_ldap.so
auth – required – pam_Unix.so

No caso acima, a verificação de autenticação, poderá ser feita numa base Ldap ou através do Unix(/etc/passwd)

Categoria – Controle – Módulo

auth – required – pam_ldap.so
auth – requisite – pam_Unix.so

No caso acima, a verificação de autenticação, poderá ser feita apenas na base Ldap, pois neste caso está sendo assumido o primeiro controle required deixando de consultar o segundo controle, pois os mesmos não são iguais.

O controle requisite é o controle mais “forte” pois quando iniciado como primeiro controle, ele não mais consulta um outro controle, mesmo que seja negado a autenticação.

exemplo:

Categoria – Controle – Módulo

auth – requisite – pam_ldap.so
auth – required – pam_Unix.so

No caso acima, apenas o primeiro controle será consultado, pois o controle requisite está em primeiro lugar na consulta.

Linha de Configuração do Módulo PAM

Os arquivos de configuração do PAM, no linux, normalmente estão localizados no diretório /etc/pam.d/. Nestes arquivos, a linha de configuração é dada como:

service-name module-type control-flag module-path args

Nome do Serviço – Service-name
Está associado ao nome do serviço associado a esta entrada. Por exemplo, ftpd, rlogind, su, e outros.

Divisão dos Módulos – Module-Type
Como o próprio nome diz, o PAM (Plugglable Authentication Modules) é um conjunto de módulos, no qual cada um recebe uma ou mais funções especiais dentro do processo de autenticação. Essa função que cada módulo tem é determinado pelas divisões dos módulos do PAM, que são: AUTH, ACCOUNT, PASSWD, SESSION.AUTH

A divisão AUTH trata da autenticação, seja por login/senha ou autenticação biométrica (voz, retina, impressão digital, por exemplo).

Controle de Bandeira – Control-flag
O control-flag é utilizado para indicar de que forma a biblioteca do PAM reagirá ao sucesso ou falha do módulo que está associado. Outra função que a control-flag pode executar é dando prioridades a cada módulo, visto que eles podem ser empilhados. Existem dois modos de sintaxe para o control-flag um mais antigo e tradicional que divide a sintaxe em: REQUIRED, REQUISITE, SUFFICIENT, OPTIONAL. O modo mais novo, mais elaborado e específico separa da seguinte forma: VALUE=ACTION. A parte ACTION é nomeada como: IGNORE, BAD, DIE, OK, DONE, RESET.

Exemplos de Módulos do PAM – Module Path

pam_cracklib, pam_deny, pam_env, pam_filter, pam_ftp.so, pam_group, pam_issue, pam_nologin, pam_permit, pam_pwdb, pam_radius, pam_rhosts_auth, pam_rootok, Porém, somente os módulos principais serão mostrados e explicados a seguir.

Existem muitos módulos disponíveis como: pam_access, pam_chroot, pam_krb4, pam_lastlog, pam_limits, pam_listfile, pam_mail, pam_mkhomedir, pam_motd, pam_securetty, pam_tally, pam_time, pam_unix, pam_userdb, pam_warn, pam_wheel.

Securetty Module – pam_securetty
Module-Type: AUTH
Autor: Elliot Lee
Características: Este módulo simplesmente verifica em qual terminal o root está tentando fazer login, então a partir dele é possível restringir os locais em que o root pode fazer o login. Logo, a principal característica do pam_securetty é evitar o login do root em terminais inseguros. Vale ressaltar, que para o pam_securetty, nenhum terminal está liberado para o login, o root que deverá configurar este módulo para que ele possa fazer o
login em outro terminal.

Password Database Module – pam_pwdb
Module-Type: ACCOUNT, AUTH, PASSWD, SESSION
Autores: Cristian Gafton e Andrew G. Morgan

Característica: Este é o principal módulo do programa login, para tanto ele se encarrega de fazer a verificação do nome do usuário e senha, assim, autorizando o usuário ou não. Este módulo ainda aceita alguns parâmetros em sua configuração: hadow, nullok, md5, use_authtok. Shadow: permite o uso de senhas shadow ou convencionais. Nullok: permite o uso de senha em branco. Md5: usa criptografia md5 em vez do cript padrão. Use_authok: indica que o módulo deve usar a autenticação já fornecida para os módulos anteriores, para não interrogar o usuário novamente. Centro Brasileiro de Pesquisas Físicas – Coordenação de Atividades Técnicas 5 Plugglable Authentication Modules

No-login Module – pam_nologin
Module-Type: ACCOUNT, AUTH
Autor: Michael K. Johnson

Característica: Este módulo é muito útil quanto se deseja fazer a manutenção do sistema. Com ele funcionando, não será permitido a nenhum usuário fazer o login com exceção do root. É importante citar que, usuários que já estiverem feito o login não serão afetados com a adição deste módulo. Cracklib  pluggable   password  strength-checker   -m pam_cracklib

Cracklib  pluggable password strength-checker -pam_cracklib
Module-Type: PASSWD

Autor: Cristian Gafton
Característica:

Este módulo fará a verificação da fragilidade de uma nova senha. Para isto, ele avalia algumas características como:
Polindrome: a nova senha é um palíndromo da antiga?
Case change only: a nova senha é a antiga com apenas a diferença da caixa (maiúsculas e minúsculas)?
Similar: a nova senha é similar a antiga? Ou seja, se existe caracteres repetidos. Ele estipula um número mínimo para o uso dos mesmos caracteres da senha antiga.
Simple: a nova senha é muito pequena?
Rotated: a nova senha é a antiga, porém invertida?
Already used: a opção para nova senha já foi utilizada no passado?

Access Module – pam_access
Module-Type: ACCOUNT
Autor: Alexei Nogin
Característica: Verifica quais usuários podem fazer login em qual local (terminal, remoto, domínio, etc.)

Resource Limits Module – pam_limits
Module-Type: SESSION
Autor: Cristian Gafton
Característica:
Este módulo limita o uso dos recursos como: uso da CPU, memória Centro Brasileiro de Pesquisas Físicas – Coordenação de Atividades Técnicas 6 Plugglable Authentication Modules e outros. Sua linha de configuração de entrada é:

Type: pode ser de dois tipos: hard e soft. Para o hard o usuário não pode alterar os recursos pré-definidos, já para o modo soft o usuário é capaz de alterar os recursos, porém sem ultrapassar os limites do modo hard.

O arquivo de configuração do pam_limits é o /etc/security/limits.conf. Dentro dele, as linhas serão configuradas da seguinte forma:

<usuario/grupo> <tipo-de-limite> <recurso> <valor-do-recurso>

Em usuário/grupo, posso colocar um * para especificar todos os usuários, colocar um nome de usuário qualquer ou um nome de grupo, começando com @. No tipo de limite, existem dois possíveis: soft e hard. Quando o limite do tipo soft é chegado, o sistema avisa que chegou no limite mais não restringe nada.

Se o limite for do tipo hard, o sistema simplesmente restringe o recurso e não deixa passar dalí. O soft então serve apenas para um “aviso” amigável, então na dúvida o hard é quem manda.

Item: pode ser cada um dos seguintes:
Core: tamanho máximo para arquivos core (KB)
Data: tamanho máximo do seguimento de dados de um processo de memória.
Fsize: tamanho máximo para novos arquivos.
Memlock: tamanho máximo de memória que um processo pode bloquear na memória física.
Nofile: quantidade máxima de arquivos abertos ao mesmo tempo.
Rss: tamanho máximo que um processo pode manter na memória
Stack – Valor máximo de um processo executado em (KB)
física. Stack: tamanho máximo da pilha.
Cpu: tempo máximo do uso da CPU.
Nproc: quantidade máxima de processos disponíveis para um único usuário.
As: limite de espaço de endereçamento.
Maxlogins: quantidade máxima de logins para este usuário ou grupo.
Priority: a prioridade com que os processos deste usuário serão executados.
Locks : Número máximo de arquivos de locks que podem ser gerads pelo usuário: Também ulimit -x.
Nice – Número máximo de prioridade que o usuário pode setar, entre -20(máximo prioridade) e 19 (mínimo prioridade). Também: ulimit -e.

Value: Determina o valor para a opção do Item.


Argumentos – Args
Os args, argumentos, fazem parte de uma lista de símbolos que podem ser colocados ao final de cada módulo, se desejado. Estes argumentos são semelhantes aos argumentos disponíveis em um comando do Linux.

Práticas dirigidas:

1 – Irei listar quais módulos do PAM já estão instalados no meu sistema

# ls /lib/security/

CentOS

Debian

2 – Como descobrir se a minha aplicação tem suporte no PAM?

# ldd /bin/login

CentOS

Debian

3 – Agora irei procurar pelo arquivos instalados dentro do diretório /etc/pam.d/

# ls /etc/pam.d/

CentOS

Debian

4 – Para um melhor entendimento como o PAM funcina, irei ativar um módulo simples que serve para bloquear usuários comuns.

# vim /etc/pam.d/login

auth requisite pam_nologin.so

Para esse plugin funcionar ele necessita que o arquivo nologin esteja criado dentro do diretório /etc/.

# touch  /etc/nologin

Feito este procedimento, irei logar num terminal com um usuário comum.

Repare que  partir do momento que o plugin está ativado no programa login e o arquivo necessário está criado, os usuários comuns não conseguem mais logar, somente o root.

5 – Como bloquear o login do root em terminais de modo texto sem o uso do AM?

Basta bloquear os terminais
# vim /etc/securetty

procurei pela linha  (Standard consoles)

Basta apenas comentar as linhas do arquivo. Deixe pelo menos um terminal permitindo o login

Uma maneira prática de uar o PAM é fazer com que o usuário root não tenha acesso direto ao login, forçando a logar com usuário comum e depois fazer um su para virar root.

Mas antes disso tenho que remover o arquivo /etc/nologin

# rm /etc/nologin

6 – Para isso acontecer, é preciso editar o arquivo e visualizar a regra.

# vim /etc/pam.d/login

account requisite pam_time.so (descomente essa linha)

7 – Editei o arquivo time.conf dentro do arquivo /etc/security e acrescente na última linha

login;*;root;!Al0000-2359

# vim /etc/security/time.conf

Os campos acima são:

login – Serviço que irá ser controlado
* – Terminal
root – Usuário
Al0000-2359 – Dias e horários de filtragem

Os dias da semana são especificados em duas letras:

Mo – Segunda – Feria
Tu – terça – Feria
We – Quarta – Feria
Th – Quinta – Feira
Fr – Sexta – Feira
Sa – Sábado
Su – Domingo
Wk – Somente sábado e Domingo (fim de semana)
Wd – Segunda a sexta – Feira
Al – Todos os dias

O Sinal “!” especifica uma exceção

A faixa de horas é especificada após o dia no formato HHMM-HHMM

Pronto, agora o root não loga mais em terminais de forma correta. Para eu poder usar o usuário root, será preciso logar como ecouto e executar o su – .

Com o PAM é possível limitar quais usuários poderão ter acesso a utilizar o comando “su“. Para isso, crie um grupo chamado “admins” para os usuários que poderão ter acesso a fazer o “su“.

8 – Irei adicionar o grupo onde os usuários que poderam fazer o su.

# groupadd admins

# gpasswd -a ecouto admins

Agora é preciso criar um política que ão possibilite o uso de su, exceto pelos usuários do grupo admins

# vim /etc/pam.d/su

Agora irei criar um usuário teste para com ele tentar me tornar root, através do su.

resultado impossível.

9 – Agora será preciso editar o arquivo /etc/login.defs e descomente a seguinte linha

SULOG_FILE  /var/log/sulog

10 – Após a configuração do arquivo acima, irei executar o comando abaixo, para visualizar quais usuários estão se tornando root, através do comando su.

tail -f /var/log/sulog

11 – Permitir acesso a grupos extras como, por exemplo audio,floppy,cdrom etc…

# vim  /etc/security/time.conf

login;tty*;teste;Al0800-1300;audio

Essa sintaxe quer dizer que o usuário teste só pode ter acesso ao grupo audio se efetuar o login entre 08:00hs e 13:00hs do dia.

Outro exemplo:

login;tty*;SaSu0000-2400;audio games

Essa sintaxe acima quer dizer que todos os usuários podem ter acesso ao grupo games e audio aos sábados e domingos.

12 – É possível também limitar horários de acesso ao SSH.

# vim /etc/pam.d/sshd

.deb ou .rpm

No servidor CentOS, eu configurei o arquivo /etc/pam.d/sshd. (este arquivo existe tanto no Debian quanto no CentOS).

Adicionei a linha

account required pam_time.so

Fui até o arquivo /etc/security/time.conf e adicionei a linha:
sshd;*;ecouto;Al0800-1200

No servidor Debian, tentei fazer um ssh no servidor CentOS. Não foi possível devido o horário.

13 – Agora irei limitar um usuário para que ele posso utilizar somente dois terminais consecutivos.

# cd /etc/security

# vim limits.conf

e por fim editei o arquivo limits.conf inserindo a seguinte linha:

teste hard maxlogins 2

14 – Agora irei limitar o tamanho máximo de arquivos criados pelo usuário teste (2000kb)

Que Deus abençoe todos nós!

>_Pam
Tagged on:

One thought on “>_Pam

  • 7 de fevereiro de 2017 at 02:42
    Permalink

    Sensacional, foi o artigo mais brilhante que já li, sobre pam.

    Reply

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

%d blogueiros gostam disto: