Pular para o conteúdo

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.
Kernel Panic kpanic
Hits: 45.846 Categoria: Linux Subcategoria: Firewall
  • Indicar
  • Impressora
  • Denunciar

Parte 3: Configurando o servidor para enviar emails (Email 2.5)

Para que o servidor possa enviar e-mail por comandos eu optei por usar um programa chamado "e-mail" (e-mail?? estranho, né?). Pode ser obtido em:
Por que o servidor também precisa mandar e-mails?
  1. Para poder retornar o resultados ou status do que foi solicitado.
  2. Porque é falta de educação não responder seus e-mails. =]

Instalação

Passo 1: Baixando

$ wget http://www.cleancode.org/downloads/email/email-2.5.1.tar.gz

Passo 2: Instalando

$ ./configure
$ make
$ su -c 'make install'


3.b. Configuração

Após a instalação será criado um arquivo email.conf em /usr/local/etc/email. Ele possui muitas características, a mais importante para nós é poder enviar emails por console utilizando SMTP autenticado.

Colocarei apenas as mais relevantes no caso em questão.

Passo 1: Configurando o "email.conf"

# vim /usr/local/etc/email/email.conf

# seu servidor para enviar mensagem smtp.
SMTP_SERVER = 'smtp.provedor.com.br'
# a porta do seu servidor de smtp.
SMTP_PORT = '25'
# nome da maquina.
MY_NAME = 'SERVIDOR'
# email do servidor.
MY_EMAIL = 'servidor@provedor.com.br'
# email de resposta do servidor.
REPLY_TO = 'servidor@provedor.com.br'
# Tipo de autenticação SMTP.
# SMTP_AUTH = 'LOGIN'
# usuário para autenticação SMTP.
SMTP_AUTH_USER = 'usuário'
# senha para autenticação SMTP.
SMTP_AUTH_PASS = 'senha'

3.c. Testando

Enviando o resolv.conf por email.

$ email -s "testando o envio de e-mail" meuemail@meuprovedor.com.br < /etc/resolv.conf
Sending "testando o envio..." |*******************************************************************| 100% of 456 Bytes
E-Mail Sent

Pronto, seu servidor agora já está enviando e-mails.

   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
Nenhum artigo encontrado.

Como bloquear o Ultrasurf - solução definitiva (iptables + Fail2ban)

L7-filter (funcionando) no Slackware 10.2

Script de Firewall com redirecionamento de portas em Linux Debian

IPTABLES - Conceitos e aplicação

IPCop Firewall - Uma ótima opção de proteção para sua rede ADSL

#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
#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

Entre na sua conta para comentar.