Ontem foi dia de análise de alguns servidores da GM, especialmente os SOX, por estarmos próximos à outra auditoria.
Numa empresa grande como a HP, temos centenas de funcionários de suporte ao ambiente – Pessoas lidando com o sistema operacional, outros com banco de dados, alguns especialistas em ferramentas de monitoração, entre outros.

A menos que sua rede toda esteja rodando NIS ou LDAP (o que raramente acontece), você acaba tendo que criar todos estes ID’s nos servidores, e ao longo dos anos isso vira bagunça, se não for administrado corretamente.

Nessa revisão de ontem constatamos que possuíamos muita gente com acesso demais nos servidores. Isto é, com regras de sudo excessivas, pelo fato de serem membros de grupos desnecessários.

Tente administrar mais de 3.000 servidores e ir, de um por um, removendo os grupos de algumas dezenas de usuários. Complicado né ?
Foi com isso em vista que fiz um simples shell script, com a função de fazer algo que, na minha opinião, deveria ser um recurso nativo do Unix.As regras de sudo, num ambiente bem estruturado, são, em sua maioria, desenhadas para grupos – e então usuários adicionados aos grupos, dando-os permissões para a execução dos comandos como root.

Imaginemos então que o usuário torvalds é membro dos grupos admin, monitoracao e impressoras. E que nosso objetivo é retirá-lo do grupo admin, pois este grupo possui permissões para executar sudo su -.

Seria simples, não ?

usermod -g monitoracao -G impressoras torvalds

Porém agora considere o seguinte: O cara vai estar no grupo admin em todos os servidores, porém os grupos secundários dele são desconhecidos.
Além disso, você não pode conectar-se a cada servidor, grepando o /etc/group pelo ID dele, e montando um script para cada ocasião. Total perda de tempo, certo ?
Ah sim, mais um probleminha: Você vai rodar o script em Solaris, HP-UX, AIX e em alguns poucos servidores Linux. Portanto nada de comandos específicos.

Foi pensando nisso que eu criei um script simples, feio, mal-feito mas que funciona Usando apenas as ferramentas encontradas em todos os sabores de Unix, como sed, while-do, grep, cut, entre outros.
Ele automatiza a coisa, fantástico para uma ocasião como a minha, onde tenho em mãos uma ferramenta web que é capaz de rodar o script em todos os servidores ao mesmo tempo.

Enfim, sem mais delongas – Segue o script. Torço pro Google indexar isso logo e outros que passaram pelo mesmo problema que eu tenham uma solução mais prática:

# Entrar num diretório temporário:
mkdir –p /tmp/controlid && cd /tmp/controlid
# Pegar do /etc/group os grupos atuais do cara e jogar num arquivo temp:
grep torvalds /etc/group | cut -d: -f1 > currgroups
# Botar o output do comando anterior, todos na minha linha, separados por virgula:
while read line; do echo -n "$line,"; done <currgroups >currgroups2
# Tirar a porcaria da virgula que sobrou no final da string:
cat currgroups2 |sed 's/\(.*\)./\1/' > currgroups3
# Remover o grupo admin da lista acima. Troque a palavra admin abaixo pelo grupo que deseja remover.
cat currgroups3 | sed 's#,admin##g' > groups
# Atualizar os grupos do cara !
usermod -G `cat groups` torvalds

Sugestões de otimização para o script são sempre bem-vindas.

Um abraço a todos !

Leia também:

1. Dicas para administração de usuários – Unix Aqui vai uma mini coleção de dicas para gerenciamento de...
2. Using conditional expressions to improve your shell scripts You can use these very simple shell script conditional expressions...
3. A Sysadmin’s Universal Translator (Rosetta Stone) Clicando aqui e ali, encontrei algo que com certeza vai...

- Trabalham numa empresa onde o número de funcionários é relativamente alto (> 5 utilizadores de internet já é um bom número) e todos tem endereços de e-mail, recebem e enviam mensagens o dia todo.
- Tem algumas unidades de Windows espalhados pela rede toda, vulneráveis _sempre_ às praguinhas virtuais.
- São administradores, técnicos ou analistas, preocupados com a segurança e integridade dos dados de sua rede.

Para essas pessoas, aqui vão minhas recomendações:

1) Bloquear todos os webmails conhecidos do mercado. Ou pelo menos certificar-se de que o webmail que o funcionário tenha acesso possua anti-vírus e anti-spam.

Isto pode ser feito facilmente com “ACL’s” no Squid. Se você usar um proxy transparente, tem também a opção de cortar a conexão com os webmails logo no iptables.

Aqui vai uma ACL fácil de se fazer no Squid:

acl webmails url_regex hotmail webmail mail

// Cuidado ! Esta acl irá bloquear todos os endereços que tenham as expressões citadas, como “hotmail”.. isso pode gerar efeitos colaterais desagradáveis. Este é apenas um exemplo para ilustrar o poder das ACL’s.

Se você não puder, ou não quiser bloquear webmails, temos a opção de instalar o viralator no Squid, para ele checar com o antivirus instalado no seu servidor local, todos os arquivos .exe .zip (entre outros) antes de permitir que o usuário os baixe. Mais detalhes sobre o Viralator em uma próxima matéria.

2) Usar o fetchmail para buscar nos webmails dos funcionários as mensagens, e servi-las a eles pelo POP local.

Esta saída tem o lado negativo deles terem de fornecer o login e senha deles, para o fetchmail conseguir baixar as mensagens.

Na verdade cada usuário pode ter seu arquivo .fetchmail, que fica em seu home directory, e dessa forma você não precisaria saber da senha dele, anulando o lado negativo que citei acima. De qualquer forma, você como root vai poder ler o arquivo depois. Mas é só não contar a eles que você tem essa possibilidade, ou não fazer isto de fato. Infringir os direitos à privacidade alheia é feio

Se você quiser fazer um único arquivo para todas as contas POP dos funcionários, crie um arquivo .fetchmailrc que contenha todas as informações de exemplo:

poll pop3.gmail.com with protocol pop3:
user ‘xxxxx’ there with password ‘xxxx’ is ‘xxxx’ here

Explicação : O comando “poll” significa algo como “ir buscar as mensagens”, seguido pelo endereço do servidor e o protocolo.

Logo a seguir temos “user xxxxx”, que representa o usuário no servidor de webmails. “with password xxxx” representa a senha da conta do usuário, e o “xxxx here”, nome LOCAL do usuario, no seu servidor Linux..

Feito isso, execute o comando :

/usr/bin/fetchmail -f /root/.fetchmailrc -a -s -K -F

Ou coloque-o em sua crontab (altamente recomendado), e assim você sempre terá as mensagens baixadas para o seu servidor.

O fetchmail precisa de um MTA (Mail Transport Agent) que pode ser o Sendmail, Postfix, QMAIL ou outros. No meu caso, estou usando o Postfix + MailScanner, que é uma combinação que deu muito certo no meu caso, apesar de ser meio pesada.

Quando seu servidor baixar as mensagens do POP remoto, ele irá colocá-las dentro da mailbox (ou maildir) do usuário, inicializando uma conexão SMTP de dentro para dentro, ou seja, de uma interface ethX para outra, e nessa hora a mensagem seria escaneada pelo seu ClamAV, já pré-configurado.

Um esboço de como a coisa toda funciona:

O usuario foo tem uma conta no Gmail, e o meu servidor local (Debian) irá, pelo fetchmail. buscar as mensagens no servidor pop3 deles.

Quando ele terminar de baixar, antes do conteúdo ir para a mailbox local do foo, meu servidor escanearia tudo em busca de conteúdo malicioso (por intermédio do MailScanner / ClamAV) e só entregaria de fato as mensagens que estiverem limpas.

Leia a segunda parte deste mini-tutorial clicando no link a seguir:
http://www.lsmod.net/2008/09/clamav-mailscanner-e-o-mta/

Leia também:

1. ClamAV, MailScanner e o MTA Vamos para a segunda etapa das dicas de como melhorar...
2. YASG (Yet Another Security Guide) A importância da segurança da informação Tratar da segurança de...
3. Dicas para administração de usuários – Unix Aqui vai uma mini coleção de dicas para gerenciamento de...