Eu tenho um cliente muito paranóico que executa duas redes separadas (uma off-line, uma on-line) com PCs separados, etc.
Eu tenho um desafio em que eu escrevi um aplicativo para eles que será executado na rede offline, no entanto, a rede precisa ser capaz de enviar e-mails para os clientes. Minha ideia é ter uma conexão de rede unidirecional (como um diodo) do servidor off-line para um PC on-line que enviaria os e-mails.
Qual é a maneira mais eficaz de lidar com isso que é semi-econômica? Posso obter uma placa de rede unidirecional?
Rede do Windows Server 2008, PC com Windows.
Basicamente você só precisa de um firewall entre os dois com regras realmente rígidas, basicamente algo chamado de regra 'Negar tudo' e depois permitir que um único ponto de um ponto aponte a regra de saída de porta única para o que você precisa. Isso é fácil para um cara de segurança / rede e deve ser satisfatório para o seu cliente.
Eu não os chamaria de paranoicos, e aplaudo a atitude deles em relação à segurança.
Se eles se deram ao trabalho de redes separadas, eles provavelmente também se deram ao trabalho de instalar um firewall. Um pequeno buraco no firewall que só permite que o tráfego na porta 25 passe de um endereço IP específico em sua rede offline para um endereço IP específico em sua rede on-line deve funcionar perfeitamente.
Eu usaria um link serial que tenha apenas o GND e o TX no servidor seguro e o GNS e o RX na rede insegura. Sem controle de fluxo, pois isso pode ser usado para vazar informações da rede insegura para a rede segura.
Eu criaria um pequeno proxy SMTP-UDP-SMTP composto em 2 daemons. SMTP2UDP e UDP2SMTP.
SMTP2UDP será um MTA não compatível que será executado na rede segura e aceitará emails que enviarão usando o UDP no link serial.
O UDP2SMTP será executado em uma rede insegura e aceitará e-mails via UDP e os enviará para um MTA real.
No link serial eu usaria um optoacoplador para usar o diodo nos requisitos.
Se você quisesse implementar os requisitos ao pé da letra, poderia usar um link IP unidirecional que enviava seus e-mails via UDP (ou um protocolo unidirecional semelhante) para um daemon personalizado que escutava esses pacotes e os enviava via SMTP para o destinatário pretendido.
É claro que o sistema de envio (offline) não teria idéia se eles realmente saíram ou não. Para que esse reconhecimento aconteça, você precisa de uma configuração mínima de firewall, conforme Ben e Chopper3 responderam.
O protocolo TCP precisa de comunicação bidirecional. Essa configuração é semelhante a um design da DMZ , em que seu aplicativo é executado na intranet confiável e no servidor de e-mail e / ou destinatários existem na zona não-confiável da DMZ.
Um firewall bem configurado só permitirá que conexões sejam iniciadas na intranet confiável, e não o contrário. Se isso não for suficiente, duvido que qualquer conexão física entre as duas redes satisfaça seu cliente, o que significa que você não poderá enviar e-mails automaticamente.
Se eles foram até este ponto para separar as redes, deve haver dois firewalls instalados aqui com uma caixa habilitada para email no meio. No lado off-line, apenas permita conexões a essa caixa para despejar mensagens para enviar por meio de seu aplicativo personalizado. No lado on-line, permita somente a conexão SMTP ao servidor de e-mail.
Você poderia fazer o mesmo com muito custo-benefício com uma única caixa de hospedagem dupla com firewall de software em execução em cada interface, mas separar as coisas criará várias camadas adicionais de proteção e seria preferível.
Eu teria apenas dois servidores de e-mail, um interno e um externo. Faça com que os servidores anexem continuamente os e-mails enviados a um arquivo e, de vez em quando, renomeiem o arquivo, copiem-no em uma chave USB e soltem-no em uma pasta recebida no outro servidor. Essa é a quantidade de instalações que realizam intervalos de ar nos servidores de rede.
Se for muito importante atrasar, pode ser enviado por um dos clientes externos.