How to PULL queued mail... secure SMTP transfer from DMZ.
GVB
again incase I am missing any new technologies.
I have a bunch of machines in an untrusted DMZ network which need to
send email via SMTP to our Internal network. The problem is that
security policy prohibits connections initiated from DMZ to Internal
networks.
I plan on setting up a SMTP server in the DMZ which will relay mail
from any server in the DMZ network. From there I need to get that
email into the Internal network by pulling it, with a connection
initiated from the Internal network. This is queued mail, so no
POP-like solutions will work.
I have read about UUCP tunneling, BSMTP, etc... thought about just
scripting an scp pull of the mqueue dir, but might run into problems
with mail that is in the process of being queued (d* and q* files).
What is the best way to do this? Any help?
Thanks!!
Leif Neland
.
>
> I have read about UUCP tunneling, BSMTP, etc... thought about just
> scripting an scp pull of the mqueue dir, but might run into problems
> with mail that is in the process of being queued (d* and q* files).
>
> What is the best way to do this? Any help?
UUCP would work nicely.
Leif
GVB
Is UUCP a persistant connection? That is another security
requirement.. no persistant connections. All connections must be
setup, data transfered, and then torn down.
Thanks!
"Leif Neland" <le...@neland.dk> wrote in message news:<40a4708e$0$179$edfa...@dread11.news.tele.dk>...
David F. Skoll
> I plan on setting up a SMTP server in the DMZ which will relay mail
> from any server in the DMZ network. From there I need to get that
> email into the Internal network by pulling it, with a connection
> initiated from the Internal network. This is queued mail, so no
> POP-like solutions will work.
Sigh...
Run an SMTP server on an internal host.
Periodically, SSH out from the inside SMTP server to the DMZ SMTP
server, port-forwarding the remote port 2025 to localhost:25. Then
(assuming an appropriately-configured sendmail, not trivial) initiate
a queue run on the DMZ server, so that it delivers queued mail to
localhost:2025.
Details left to the reader. :-)
Regards,
David.
Chuck Yerkes
I've run into this for a decade, since people started doing firewalls.
And mail "PULLS" are never the right thing.
And in many ways, the notion that the DMZ machine is compromised is a
good one. That's why I use a DMZ for mail. From my DMZ, you can only
reach SMTP on the internal machines.
You can secure the connection. Secure and lock down the internal
MTA. Use TLS to ensure that you're talking only to the right machine.
Configure the firewall to ONLY allow connections from DMZ -> your 2
internal mail relays.
You might point to the hundreds of smart sites that run it with SMTP
connections allowed in. You can point to the many many many Fortune 500
companies that do this.
The alternatives include making your security folks copy all the queued
files to a zip drive and moving it.
Installing and turning on UUCP (welcome to 1990) and running that over
ethernet or serial. I'd use IPSec for ethernet. Now your security
group's policy is requiring you to install and run new code that's been
perhaps ignored for years. With little popular support.
And explain to your managers that they COULD have their mail in a matter
of 1-2 seconds from it arriving, but the security policy is limiting it
so they should get their mail in 30 minutes or an hour or so. Perhaps
they should use the FAX instead.
> What is the best way to do this? Any help?
The best way? restrict DMZ -> IN to port 25 (best practice. really.)
Leif Neland
> Thanks!
>
> "Leif Neland" <le...@neland.dk> wrote in message
> news:<40a4708e$0$179$edfa...@dread11.news.tele.dk>...
>> GVB wrote:
>> .
>>>
>>> I have read about UUCP tunneling, BSMTP, etc... thought about just
>>> scripting an scp pull of the mqueue dir, but might run into problems
>>> with mail that is in the process of being queued (d* and q* files).
>>>
>>> What is the best way to do this? Any help?
>>
>> UUCP would work nicely.
> Where can I read more about doing this with UUCP?
>
> Is UUCP a persistant connection? That is another security
> requirement.. no persistant connections. All connections must be
> setup, data transfered, and then torn down.
>
UUCP was designed for transferring mail via dialup-lines, so the connection
is not persistant.
Leif
GVB
minded folks.
We have Internet -> Firewall 1 -> Untrusted DMZ (web servers, external
DNS, etc..) -> Firewall 2 -> More trusted DMZ (database servers that
support the web servers, application servers, etc...).
A cluster of servers in the "More trusted DMZ" need to send email out
to the Internet based on DNS/MX. Our security policy prohibits
connections initiated from the "More trusted DMZ" which is why I was
trying to come up with a method of "pulling" mail, if required we can
get an exception to the security policy to allow outbound SMTP.
I plan on setting up a relay server and pointing all these servers to
it for mail relay so we have more control over outgoing email (queue
times, max size, sanity checks, etc...)
1) Put the relay server in the "Untrusted DMZ" and create rules on
Firewall 2 to allow SMTP connections from the servers in "More Trusted
DMZ" to the relay server, then allow the relay server access to ANY on
the internet via SMTP.
2) Put the relay server in the "More trusted DMZ" and rules on both
firewalls to allow SMTP connections out to ANY on the Internet.
3) Put the relay server in the "More trusted DMZ" and add a rule to
Firewall 2 to allow it to only send to relay servers on our Internal,
trusted network (which has connections to both Firewalls). The relay
servers on out Internal network would then send the email out.
Thoughts?
Chuck Yerkes <new...@may2004.NOSPAMsnew.com> wrote in message news:<UwBpc.57166$xw3.3428505@attbi_s04>...
GVB
Thoughts?