rss
twitter
  •  

Política de senhas no Linux: Senhas com data para expirar!

| Posted in Arch Linux, cultura hacker, debian, Impressões, Linux, segurança, software livre |

0

Já é sabido que a maior vulnerabilidade dentro das empresas ou mesmo computadores pessoais são justamente os próprios funcionários ou usuários.

Manter uma boa política de senhas é fundamental para garantir a segurança básica de suas informações e tentar minimizar as chances de alguém ter acesso indevido a elas.

Vou apresentar dicas simples para uma boa política de senhas que vão além das dicas comuns como “mantenha uma senha que contenha mais de 8 caracteres, sendo eles números, letras minúsculas, maiúsculas e caracteres especiais…”.

Em escritórios é importante haver também uma política de troca de senha regular. Mas, como forçar os usuários a seguirem essa política de troca de senha regular? Evitando que o mesmo se logue caso não troque a senha de forma periódica, claro.

Vamos começar pelo básico.

 

1- Definindo a complexidade das senhas de usuários:

Para definir a complexidade, precisaremos alterar a configuração de definição de senhas de usuários. O processo pode ser diferente, de acordo com a sua distribuição.

 

Arch Linux:

Edite o arquivo passwd que se encontra em /etc/pam.d/passwd, da seguinte forma:

# vim /etc/pam.d/passwd

Debian, Ubuntu, RedHat, CentOS e outras:

# vim /etc/pam.d/system-auth

 

Configure sua linha de senha de forma que fique algo parecido com o seguinte:

password       required        pam_cracklib.so difok=3 minlen=10 ucredit=3 ocredit=2 retry=3

Onde:

difok=3 -> Informa a quantidade de caracteres que podem se repetir em relação à última senha. Por exemplo: Se minha antiga senha era “kalib” e eu tento usar “kalamba” como nova senha, receberei uma informação de erro, pois eu repeti 3 letras que já existem na senha anterior “kal”.

minlen=10 -> Informa qual a quantidade mínima de caracteres aceitos para a senha do usuário. No exemplo, o mínimo de caracteres aceitos serão 10, caso contrário será apresentada uma mensagem de erro solicitando que o usuário tente uma nova senha.

ucredit=3 ->Informa a quantidade de letras maiúsculas que deverão compor minha senha. No exemplo, eu precisarei utilizar no mínimo 3 letras em maiúsculo, ou “Uper Characters” em minha nova senha.

ocredit=2 -> Informa a quantidade de “outros caracteres” ou caracteres especiais, como por exemplo *, &, %, $, _, etc.

retry=3 -> Informa quantas vezes o usuário vai poder tentar, em caso de senha indevida, antes de receber a mensagem de erro.

Outros parâmetros que podem ser utilizados são os seguintes:

dcredit=x -> Informa a quantidade de dígitos que deverão ser utilizados como números na senha, onde x é o número mínimo desejado.

lcredit=x -> Informa a quantidade de caracteres minúsculos, ou “Lower Characters”, mínimos em sua senha.

 

2- Definindo que a nova senha não poderá ser igual às anteriores:

No mesmo arquivo do ponto anterior, iremos inserir o parâmetro remember na linha conforme exemplo:

password sufficient pam_unix.so use_authtok md5 shadow remember=10

remember=10 -> Informa que a nova senha não poderá ser igual às últimas 10 senhas utilizadas por este usuário.

 

Agora que já sabemos como definir uma política para criação de senhas seguras, vamos conhecer o “chage“, que nos ajudará a definir a política de datas ou validade das senhas.

 

3- Checando as políticas de validade de senhas de um determinado usuário:

# chage -l usuário

O comando acima verifica os atributos de validade daquela senha, e lhe retornará algo similar ao seguinte:

Last password change : May 11, 2011
Password expires : never
Password inactive : never
Account expires : never
Minimum number of days between password change : 0
Maximum number of days between password change : 99999
Number of days of warning before password expires : 7

 
As informações acima apresentam dados como data de última mudança de senha, data de expiração, tempo de inatividade, quantidade mínima de dias para se trocar a senha antes de a mesma expirar, etc.
 
4- Criando uma “validade” ou período de expiração para a senha de um determinado usuário:

# chage -M 99999 linustorvalds

 
Este comando vai desabilitar o período de validade da senha, informando que a mesma não expira nunca.
 

# chage -M 50 -m 7 -W 7 linustorvalds

 
Este comando aplica a política de senha para o usuário “linustorvalds” onde:
-M 50 -> Define que a senha será válida por um máximo de 50 dias, quando a mesma deverá ser trocada.
-m 7 -> Define o número mínimo de dias em que o usuário poderá trocar sua senha antes do período especificado para expiração. Caso o usuário possa trocar a qualquer momento ou dia, o valor deverá ser 0.
-W 7 -> Número de dias antes de expirar nos quais o usuário vai receber alertas informando que sua senha irá expirar.
 
Caso você deseje especificar um dia exato no qual a senha de determinado usuário vai expirar, você pode utilizar o parâmetro -E seguido da data desejada no formato AAAA-MM-DD.
 
Além disto, você pode desejar que a senha do usuário “linustorvalds” seja trocada no próximo login do mesmo. Neste caso você poderá utilizar o parâmetro -d, conforme exemplo abaixo:

# chage -d 0 linuxtorvalds

 
O -d significa quantidade de dias também.
 

É isso pessoal.
Have fun!

Vantagem do Aptitude sobre o Apt-Get

| Posted in aptitude, debian, Linux, software livre |

5

Novamente estou aqui para lhes passar uma pequena dica que para muitos pode nem ser novidade, porém para alguns a dúvida pode existir.

Bom, para aqueles que ainda não sabem, o apt é uma ferramenta da Debian para gerenciamento de pacotes de forma simples, amigável e rápida contando inclusive com a instalação automática de dependências necessárias para a finalização do processo. O que muitas pessoas ainda não sabem é que utilizando-se do comando “apt-get install NOME_PACOTE” serão instalados pacotes que o mesmo não removerá automaticamente posteriormente, fazendo assim um acúmulo de “lixo” em nosso sistema. Como assim? Suponhamos que eu queira instalar um aplicativo de instant messenger como por exemplo o amsn. Esta ferramenta possui dependências necessárias para seu funcionamento, sendo elas o TCL e o TK.

O seguinte comando fará a instalação do amsn juntamente com suas dependências, sem que eu precise me preocupar em buscar por elas desesperadamente na internet:

#apt-get install amsn

Ótimo! Agora tenho o meu messenger devidamente instalado, sem nenhuma dificuldade e funcionando perfeitamente. Porém, um certo dia resolvi remover essa ferramenta que com o tempo parei de usar, então para isso utilizo o seguinte comando:

#apt-get remove amsn

Perfeito! Meu amsn está desinstalado sem dificuldade alguma. ;]

Agora, e o que acontece com os dois pacotes que foram instalados juntamente com ele anteriormente? TCL e TK? Bom, eles continuam instalados, fazendo um certo acúmulo de “lixo” em seu sistema. O mesmo ocorre com todos os pacotes que forem instalados em seu sistema e futuramente removidos com o apt-get.

Onde entra o Aptitude nessa história?

Bom, o aptitude tem um funcionamento bem semelhante para a instalação de pacotes. Passaremos a adotar o mesmo cenário aqui, instalando portanto o amsn:

#aptitude install amsn

Assim como o apt-get, o aptitude irá instalar automaticamente as dependências do amsn, TCL e TK. Passado algum tempo, resolvo remover o amsn usando o seguinte comando:

#aptitude remove amsn

Aparentemente ele terá o mesmo efeito do apt-get, com o grande diferencial de excluir juntamente com o amsn, as suas dependências que outrora foram instaladas, TCL e TK.

Imagine a quantidade de pacotes desnecessários que deve existir em sua máquina…provavelmente vários. O aptitude é uma solução para que isto não ocorra mais.

Para os fans de distribuições como o Fedora que utilizam-se da ferramenta Yum para instalar seus pacotes, caso tenha surgido a curiosidade, fica a informação de que, infelizmente, o yum ainda não possui este mecanismo. A mesma curiosidade surgiu em mim e resolvi testar, porém o yum, assim como o apt-get, apenas me removeu o amsn, deixando para trás as dependências que foram instaladas.

Essa foi uma simples dica para aqueles que desconheciam este fato diferencial dentre os dois. Espero ter ajudado com esta pequena contribuição para com a comunidade. abraços e até a próxima.