Ensinando seu servidor a ler emails e liberar acesso SSH

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.

[ Hits: 44.052 ]

Por: Kernel Panic em 14/11/2007 | Blog: http://nooooooooooooooo.com


Apresentação



O dilema

É 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.

    Próxima página

Páginas do artigo
   1. Apresentação
   2. Configurando o servidor para receber emails (Getmail)
   3. Configurando o servidor para enviar emails (Email 2.5)
   4. Configurando o servidor para "LER" os emails
   5. Finalizando
Outros artigos deste autor
Nenhum artigo encontrado.
Leitura recomendada

Firewall invisível com Proxy ARP

Como construir um firewall de baixo custo para sua empresa (parte 2)

Servidor Firewall-Proxy utilizando CentOS, IPtables, Squid, DHCP, DNS e outros

Firewall profissional

Firewall com Iptables: direto ao assunto (RHEL5 e Fedora)

  
Comentários
[1] Comentário enviado por thiagop em 14/11/2007 - 08:58h

Gostei da sua solução :)

Só fiquei preocupado em dar os direitos a todos os usuários a rodar o iptables no /etc/sudoers... mas dá-se um jeito ;)


Abraços e parabéns!

[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. =]

Abraços

Kernel Panic

[3] Comentário enviado por thiagop em 14/11/2007 - 09:51h

Epa, comi bola hahaha valeu pelo lembrete!

E agora acho que ninugém mais se confunde ;)

[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.

[5] Comentário enviado por elgio em 14/11/2007 - 10:53h

Bastante criativo

[6] Comentário enviado por elgio em 14/11/2007 - 10:58h

A, esqueci, porque mesmo que a solução por telepatia foi abandonada?
:-D

[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

[8] Comentário enviado por volcom em 14/11/2007 - 11:22h

Muiiiiiiiiiiiiiiito Bom!!!

Cara, impressionante heheheh, gostei muito mesmo e vou testar assim que possível :D

Abraço e Parabéns

[9] Comentário enviado por elgio em 14/11/2007 - 11:27h

y2h4ck: hehehehe
Eu não quiz ser tão direto ao ponto como tu, mas não posso deixar de registrar que fecho contigo no teu comentário!

[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) ;)

Abraços

Kernel Panic

[11] Comentário enviado por y2h4ck em 14/11/2007 - 15:00h

"entretanto prefiro crer que todo servidor é seguro, exceto os mal administrados."

Infelizmente ehueh até o dos bons administradores é inseguro =]

[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...

[13] Comentário enviado por jalexandre em 06/03/2008 - 16:04h

Kernel Panic, a idéia a sem duvida nenhuma bem criativa, ponto para você.

Porém, se você fizer isso em lugares que seguem a BS7799, é bem provavél que tu seja mandado embora.

Uma forma interessante de fazer isso seria uma implementação de VPN + PortKnocking.

Parabéns pela criatividade. Sem dúvida, eu irei utilizar este método para algumas coisas que divertidas, como robozinhos de manutenção. =)

[ ] 's

[14] Comentário enviado por joaorubens em 01/03/2013 - 13:10h

da uma olhada no meu post e me fala se esqueci alguma coisa.
http://www.vivaolinux.com.br/topico/vivaolinux/Como-enviar-email-via-SSH

[15] Comentário enviado por GIRLinux em 19/03/2013 - 18:09h

Ola quando tento enviar um email me da o erro
Fatal smtp error 530 5.7.0 must issue a STARTTLS COMMAND FIRST

Conta : hotmail
Porta smtp

smtp_server = 'smtp.live.com'
smtp_port = '587'


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts