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.
É comum para um firewall Linux ter todas as portas fechadas exceto a porta do serviço SSH, normalmente a porta 22. Existem muitas medidas que tornam esta única porta de acesso externo ao seu servidor um acesso mais seguro contra possíveis ataques, como por exemplo não permitir login do usuário root, configurar o serviço em uma porta diferente da 22, restringir números IPs, entre outras.
Entretanto sempre mostra no log algum tipo de tentativa de acesso, é claro que existem outras formas de tratar este tipo de tentativa de acesso, como Snort, Guardian, etc., mas mesmo repelindo esse tipo de tentativa a porta 22 continua lá, aberta e aguardando uma conexão.
Pensei como seria interessante se a porta SSH também ficasse fechada e se abrisse somente quando eu precisasse acessar externamente o servidor. Então cheguei a duas conclusões:
Comunicar-se por telepatia com o servidor não daria certo porque não tenho driver do meu cérebro para esta versão kernel que utilizo. XD
Um meio confiável de entrar em contato com o servidor firewall sem prejudicar a segurança do ambiente seria se ele aprendesse a ler e-mails.
Uma solução possível
"Existem sempre três formas de se resolver um problema. A forma correta, a forma errada e a minha forma de resolver."
A forma que eu encontrei de resolver este dilema foi criar uma conta de e-mail que permita acesso "POP3" tradicional, depois configurei uma conta de e-mail para o servidor onde ele pode receber as informações e realizar as tarefas desejadas, no caso liberar acesso SSH sempre que eu quisesse.
Esta solução baseia-se em um programa que recebe e-mails via console e os armazena em forma de arquivos de texto, um programa que envia e-mails via console e um script shell que trata os e-mails com base em algumas instruções pré-estabelecidas, sendo executado a cada 5 minutos.
[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...