Esta solução baseia-se em um programa que recebe emails via console e os armazena em forma de arquivos de texto, um programa que envia emails via console e um script shell que trata os emails com base em algumas instruções pré-estabelecidas, sendo executado a cada 5 minutos.
Depois de tudo devidamente configurado, agora é o momento de colocar para rodar automaticamente através do crontab. Adicione a seguinte linha usando o comando:
# crontab -e usuário
# Executar o script a cada 5 minutos
*/5 * * * * /bin/cmdemail.sh
Pontos importantes a considerar:
O tráfego de e-mail poderá ser facilmente interceptado e alguém poderá ler as informações contidas nos e-mails, mas ainda terá que passar pela segurança do próprio SSH.
Não foi abordada nenhuma rotina para "desfazer" os comandos por considerar que uma vez conectado o resto pode ser feito manual.
Bem é isso, espero que ajude.
Agradecimento a equipe TI da D2D por doarem seus cérebros a ciência.
[2] Comentário enviado por kpanic em 14/11/2007 - 09:49h
Saudações...
Concordo com você, eu avaliei desta forma também, entretanto a idéia é rodar estas rotinas como um usuário específico e atribuir apenas a este usuário poder utilizar o iptables através do comando sudo sem que precise passar a senha do root.
Exemplo [ /etc/sudoers ]:
gasper ALL = NOPASSWD: /usr/sbin/iptables
Nesse exemplo somente o usuário gasper tem a permissão e apenas para executar o comando iptables sem que lhe seja solicitado senha.
Esse "ALL" confunde um pouco. =]
[4] Comentário enviado por dedraks em 14/11/2007 - 10:25h
Muito legal o seu tutorial.
Eu gostaria de dar umas dicas:
1) Seria bom enviar os emails de forma criptografada ao invés de texto plano.
2) Melhor, enviar os emails usando chaves criptográficas. Aí o servidor só aceitaria emails que vierem de fontes seguras.
3) Colocar no script de logout do bash, o comando pra fechar a porta 22 novamente. Desso modo, ao se desconectar do servidor, a porta é fechada automaticamente.
[7] Comentário enviado por y2h4ck em 14/11/2007 - 11:17h
Rapaz, sem querer desmerecer seu artigo mas vc dizia no começo
"queria uma forma segura e confiável de acessar o firewall"
Onde diabos vc acha que :
- Mandar emails para um firewall para liberar acesso é seguro
- Adicionar iptables no SUDOERS é seguro ?????
Rapaz, coisa de loco isso ... segurança -1 :P
A soluçao é bacana para vc aprender a fazer umas coisas bacanas,
mas nunca implementem um trosso desse em ambiente de produção !!
Quer uma forma segura e confiável de acesar o firewall ? Acesse via VPN :) com criptografia.
ehehe
[10] Comentário enviado por kpanic em 14/11/2007 - 14:08h
Saudações...
Agradeço a todos pelos comentários e sugestões.
Algumas reações considero normais para a maioria do administradores que assim como eu acreditam que: "A paranóia é nossa amiga".
Muito mais do que somente uma receita de bolo, a intenção foi passar a idéia de uma máquina linux realizando instruções recebidas por email.
Quanto a aspectos de segurança, é um debate tão amplo que não cabe tratar aqui, já que a proposta do artigo nunca não foi esta, entretanto prefiro crer que todo servidor é seguro, exceto os mal administrados.
Uma resposta genérica seria: Sim, existem muitas formas de melhorar e tornar isso mais seguro.
Cabe a cada um conhecer seu ambiente e decidir a te que ponto isso pode ou não ser implementado.
PS: Quer uma forma de deixar seu firewall seguro? tire os cabos de rede.
(não vale usar tempest) ;)
[12] Comentário enviado por eduka em 14/11/2007 - 16:06h
É uma idéia muito boa, mesmo.
Independentemente das questões acima citadas sobre segurança relativas a sudo ou criptografia dos emails, o que vale mesmo é o fato de a porta 22 não ficar disponível o tempo todo, ou seja, a questão é manter segurança por "default"
Creio que o mecanismo proposto é legal, pois é uma forma criativa e controlada de fazer uma abertura (vejam que somente os scripts no servidor é que tem a inteligência de fazer ou não fazer a abertura ).
Kernel Panic: esta idéia de ler email é legal, hein? Já fiz implementações de interpretar emails, mas sempre sendo eu um servidor SMTP (ex. qmail, procmail ), mas sua idéia é que o servidor é client de uma conta externa. Ótimo! parabéns...