setting up dmz server for etrn?

Though I have my mail server setup and running, it has some issues
and I'm going to change things a bit. I want to put a mail server
in my DMZ with spam assassin, clamav, etc. I have the milters
installed and I think working. I'm currently stuck on how to get
this mail server in my DMZ to not deliver locally, but rather put
the messages to be delivered inside my firewall in a queue. Next I
want my inside server to issue 'ETRN' to the DMZ server and pull
the queued messages (with some frequency).

I need some help please setting the DMZ server to place the messages
to be delivered into a queue for retrieval by the inside server,
and I need help telling the inside server to issue ETRN to the
outside server and deliver either to a queue for processing on the
inside or immediate delivery to cyrus imapd.

Pointers please?

Mike

--
Posted via a free Usenet account from http://www.teranews.com

Re: setting up dmz server for etrn?

In article <87bq7da6bk@sherry.fsf.hobby-site.com>, Andrzej Adam Filip wrote:
> Mike writes:
>
>> Though I have my mail server setup and running, it has some issues
>> and I'm going to change things a bit. I want to put a mail server
>> in my DMZ with spam assassin, clamav, etc. I have the milters
>> installed and I think working. I'm currently stuck on how to get
>> this mail server in my DMZ to not deliver locally, but rather put
>> the messages to be delivered inside my firewall in a queue. Next I
>> want my inside server to issue 'ETRN' to the DMZ server and pull
>> the queued messages (with some frequency).
>>
>> I need some help please setting the DMZ server to place the messages
>> to be delivered into a queue for retrieval by the inside server,
>> and I need help telling the inside server to issue ETRN to the
>> outside server and deliver either to a queue for processing on the
>> inside or immediate delivery to cyrus imapd.
>>
>> Pointers please?
>
> Of course you know that ETRN over incoming connection will make sendmail
> start new outgoing connection?
> Sendmail does not support ATRN (authenticated turn) when outgoing
> messages are sent over incoming connection.
>
> People frequently ask for configuration without TCP connections from
> DMZ to internal network. ETRN does not deliver it.
>
> I have wanted to make sure what you really want before going into a lot
> of details.

Thank you for making sure. I did misunderstand the purpose of ETRN. I thought
(wrongly) that the receiving sendmail would start the protocol over the
new connection from the secure location when the ETRN was issued.

I could securely pull all files in the queue (/var/spool/mqueue) using
rsync over ssh. Doing this method I really want to have two (more?)
queues. One for traffic destined for inside my firewall and the other for
DSN and other internet-bound messages.

Is this right? How do I setup multiple queues inside sendmail and make sure
the right messages get into the right queue?

Mike

--
Posted via a free Usenet account from http://www.teranews.com

Re: setting up dmz server for etrn?

Mike writes:

> Though I have my mail server setup and running, it has some issues
> and I'm going to change things a bit. I want to put a mail server
> in my DMZ with spam assassin, clamav, etc. I have the milters
> installed and I think working. I'm currently stuck on how to get
> this mail server in my DMZ to not deliver locally, but rather put
> the messages to be delivered inside my firewall in a queue. Next I
> want my inside server to issue 'ETRN' to the DMZ server and pull
> the queued messages (with some frequency).
>
> I need some help please setting the DMZ server to place the messages
> to be delivered into a queue for retrieval by the inside server,
> and I need help telling the inside server to issue ETRN to the
> outside server and deliver either to a queue for processing on the
> inside or immediate delivery to cyrus imapd.
>
> Pointers please?

Of course you know that ETRN over incoming connection will make sendmail
start new outgoing connection?
Sendmail does not support ATRN (authenticated turn) when outgoing
messages are sent over incoming connection.

People frequently ask for configuration without TCP connections from
DMZ to internal network. ETRN does not deliver it.

I have wanted to make sure what you really want before going into a lot
of details.

--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
It is very vulgar to talk like a dentist when one isn't a dentist.
It produces a false impression.
-- Oscar Wilde.
----
http://groups.google.com/groups?selm=87bq7da6bk@sherry.fsf.h obby-site.com

Re: setting up dmz server for etrn?

Mike writes:

> In article <87bq7da6bk@sherry.fsf.hobby-site.com>, Andrzej Adam Filip wrote:
>> Mike writes:
>>
>>> Though I have my mail server setup and running, it has some issues
>>> and I'm going to change things a bit. I want to put a mail server
>>> in my DMZ with spam assassin, clamav, etc. I have the milters
>>> installed and I think working. I'm currently stuck on how to get
>>> this mail server in my DMZ to not deliver locally, but rather put
>>> the messages to be delivered inside my firewall in a queue. Next I
>>> want my inside server to issue 'ETRN' to the DMZ server and pull
>>> the queued messages (with some frequency).
>>>
>>> I need some help please setting the DMZ server to place the messages
>>> to be delivered into a queue for retrieval by the inside server,
>>> and I need help telling the inside server to issue ETRN to the
>>> outside server and deliver either to a queue for processing on the
>>> inside or immediate delivery to cyrus imapd.
>>>
>>> Pointers please?
>>
>> Of course you know that ETRN over incoming connection will make sendmail
>> start new outgoing connection?
>> Sendmail does not support ATRN (authenticated turn) when outgoing
>> messages are sent over incoming connection.
>>
>> People frequently ask for configuration without TCP connections from
>> DMZ to internal network. ETRN does not deliver it.
>>
>> I have wanted to make sure what you really want before going into a lot
>> of details.
>
> Thank you for making sure. I did misunderstand the purpose of ETRN. I thought
> (wrongly) that the receiving sendmail would start the protocol over the
> new connection from the secure location when the ETRN was issued.
>
> I could securely pull all files in the queue (/var/spool/mqueue) using
> rsync over ssh. Doing this method I really want to have two (more?)
> queues. One for traffic destined for inside my firewall and the other for
> DSN and other internet-bound messages.
> Is this right? How do I setup multiple queues inside sendmail and make sure
> the right messages get into the right queue?

You should not move queue files because:
+ it relays on compatibility of *internal* sendmail files
you *may* get hit by "asynchronous packages update"
+ it would be sendmail specific without necessity

Consider one of the following:
+ using uucp over SSH or SSL
+ using "shared mailbox" [with envelope recipient copied to headers]
it may be accessed via POP/IMAP using fetchmail
+ moving BSMTP files (Batched SMTP) [frequently used by uucp]
+ many others usually even more unusual :-)

--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
The number of UNIX installations has grown to 10, with more expected.
-- The Unix Programmer's Manual, 2nd Edition, June 1972
----
http://groups.google.com/groups?selm=87wsq18owq@lanette.fsf. hobby-site.com

Re: setting up dmz server for etrn?

On 01/22/08 14:22, Mike wrote:
> Though I have my mail server setup and running, it has some issues
> and I'm going to change things a bit. I want to put a mail server
> in my DMZ with spam assassin, clamav, etc. I have the milters
> installed and I think working. I'm currently stuck on how to get
> this mail server in my DMZ to not deliver locally, but rather put
> the messages to be delivered inside my firewall in a queue. Next I
> want my inside server to issue 'ETRN' to the DMZ server and pull
> the queued messages (with some frequency).


Andrzej is correct about ETRN starting a new connection. However, you
could still use ETRN to do what you are wanting to do. Make sure that
your external DMZ server can route to your internal server (barning no
firewalls). Then put a firewall between the two servers that by default
will reject new connections from the DMZ server to the internal server.
Configure the firewall to allow related traffic through too. Thus
when you connect to port 25 on the DMZ server, it should be able to
initiate an inbound connection to your internal server as that
connection would be RELATED and thus allowed through where as normally
it would not be.



Grant. . . .

Re: setting up dmz server for etrn?

On 01/22/08 15:11, Mike wrote:
> I could securely pull all files in the queue (/var/spool/mqueue)
> using rsync over ssh. Doing this method I really want to have two
> (more?) queues. One for traffic destined for inside my firewall and
> the other for DSN and other internet-bound messages.

Before I went this route, I'd look in to trying something along the
lines of using UUCP to transfer the messages via an SSH connection (if
it's not too difficult to set up).



Grant. . . .

Re: setting up dmz server for etrn?

Grant Taylor writes:

> On 01/22/08 14:22, Mike wrote:
>> Though I have my mail server setup and running, it has some issues
>> and I'm going to change things a bit. I want to put a mail server
>> in my DMZ with spam assassin, clamav, etc. I have the milters
>> installed and I think working. I'm currently stuck on how to get
>> this mail server in my DMZ to not deliver locally, but rather put
>> the messages to be delivered inside my firewall in a queue. Next I
>> want my inside server to issue 'ETRN' to the DMZ server and pull
>> the queued messages (with some frequency).
>
>
> Andrzej is correct about ETRN starting a new connection. However, you
> could still use ETRN to do what you are wanting to do. Make sure that
> your external DMZ server can route to your internal server (barning no
> firewalls). Then put a firewall between the two servers that by
> default will reject new connections from the DMZ server to the
> internal server. Configure the firewall to allow related traffic
> through too. Thus when you connect to port 25 on the DMZ server, it
> should be able to initiate an inbound connection to your internal
> server as that connection would be RELATED and thus allowed through
> where as normally it would not be.

Are you *sure* about this "RELATED" behavior of (Linux?) firewall in
case of incoming SMTP connections triggered by ETRN?

It would be surprising without "extra magic" and SMTP protocol level
inspections .

--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
The avocation of assessing the failures of better men can be turned
into a comfortable livelihood, providing you back it up with a Ph.D.
-- Nelson Algren, "Writers at Work"
----
http://groups.google.com/groups?selm=87bq7c7cje@teresa.fsf.h obby-site.com

Re: setting up dmz server for etrn?

In article , Grant Taylor wrote:
> On 01/22/08 15:11, Mike wrote:
>> I could securely pull all files in the queue (/var/spool/mqueue)
>> using rsync over ssh. Doing this method I really want to have two
>> (more?) queues. One for traffic destined for inside my firewall and
>> the other for DSN and other internet-bound messages.
>
> Before I went this route, I'd look in to trying something along the
> lines of using UUCP to transfer the messages via an SSH connection (if
> it's not too difficult to set up).

Ok, how do I setup the two sides. I need the dmz box to put the incoming
messages into a queue and to send those messages to the inside box when
the inside box initiates the uucp connection.

Seems like the uucp route should be a lot easier than fiddling with scripts.

Mike

--
Posted via a free Usenet account from http://www.teranews.com

Re: setting up dmz server for etrn?

On 1/23/2008 10:05 AM, Andrzej Adam Filip wrote:
> Are you *sure* about this "RELATED" behavior of (Linux?) firewall in
> case of incoming SMTP connections triggered by ETRN?

I'm not as sure as in having tested it my self. However after running
many Linux firewalls from 2.4.x on using the RELATED state, I feel very
confident that this will do what you are wanting it to do. In essence,
you have the NEW, ESTABLISHED, RELATED, INVALID states that connections
can be in. Your outbound connection from your internal server to your
DMZ server would be NEW out and ESTABLISHED back in. While your
outbound "ETRN" request is still connected, connections from the DMZ
server in to your internal server would be RELATED (same IP pair) to the
on going "ETRN" request, thus allowed through.

Here is a quick quote from the IPTables man page:

"... RELATED meaning that the packet is starting a new connection, but
is associated with an existing connection, such as an FTP data transfer,
or an ICMP error... "

As you can see, the new SMTP connection from the DMZ server to the LAN
server would qualify as RELATED as long as there is an existing outbound
"ETRN" request connection.

This very basic setup would probably allow any and all ports with out
some sort of further filtering, so you would probably want to use a rule
like this:

iptables -t filter -A FORWARD -i ${DMZ} -o ${LAN} -s ${DMZ_Server} -d
${LAN_Server} -p tcp --dport 25 -m state --state RELATED -j ACCEPT

This will prevent the DMZ server from using the opportunity to attack
another port as the firewall will only allow the connection to port 25.

> It would be surprising without "extra magic" and SMTP protocol level
> inspections.

Why would "extra magic" be needed? You are simply starting a connection
in one direction which in and of its self requests another connection
that will be in the opposite direction. Seeing as how the RELATED
criteria has been or will be met, things should work with out
modification to SMTP in any way.

Why do you think that there would have to be SMTP protocol level
inspection? Remember that the firewall is only allowing connections to
your internal LAN server from your external DMZ server, not the world at
large.

I'll toss a question to the IPTables mailing list for some conformation,
but I am very confident that this will work. I don't know how to do
this on things like Cisco PIXs (I've never even touched one) but I'd be
very surprised if this could not be done.



Grant. . . .

Re: setting up dmz server for etrn?

On 1/23/2008 2:20 PM, Mike wrote:
> Ok, how do I setup the two sides. I need the dmz box to put the
> incoming messages into a queue and to send those messages to the
> inside box when the inside box initiates the uucp connection.

I've never used UUCP so I can not say for sure, but I know that it did
(long ago prior to TCP/IP) and does (still) work. Go take a look at
uucpssh.org for details on one way to set it up.

In short, your going to set your DMZ system up and an SMTP-UUCP gateway
for your email. The DMZ system will accept messages via SMTP and queue
them up waiting for your internal server to connect to it and request
the transfer. You could set up your internal server to send messages
either way, UUCP or SMTP. However I would be tempted to use UUCP for
both directions (if I could) for symmetry reasons.

> Seems like the uucp route should be a lot easier than fiddling with
> scripts.

Most definitely.



Grant. . . .

Re: setting up dmz server for etrn?

In article

Grant Taylor writes:

>On 1/23/2008 10:05 AM, Andrzej Adam Filip wrote:
>> Are you *sure* about this "RELATED" behavior of (Linux?) firewall in
>> case of incoming SMTP connections triggered by ETRN?
>
>I'm not as sure as in having tested it my self. However after running
>many Linux firewalls from 2.4.x on using the RELATED state, I feel very
>confident that this will do what you are wanting it to do. In essence,
>you have the NEW, ESTABLISHED, RELATED, INVALID states that connections
>can be in. Your outbound connection from your internal server to your
>DMZ server would be NEW out and ESTABLISHED back in. While your
>outbound "ETRN" request is still connected, connections from the DMZ
>server in to your internal server would be RELATED (same IP pair) to the
>on going "ETRN" request, thus allowed through.

No, RELATED doesn't mean "same IP pair", that would be hole big enough
to drive a truck through.

>Here is a quick quote from the IPTables man page:
>
>"... RELATED meaning that the packet is starting a new connection, but
>is associated with an existing connection, such as an FTP data transfer,
>or an ICMP error... "

The FTP data transfer becomes RELATED due to iptables snooping the
FTP control channel, where the *port number* for the data transfer is
sent. An ICMP error message is RELATED due to having the header of the
original packet (where the ports are given) as payload.

You could probably write a "conntrack helper" that made iptables
consider the connection resulting from an ETRN to be RELATED to the
original one - maybe someone has already written such a thing - but it
won't happen just because it's the "same IP pair".

(And of course the term RELATED is iptables-specific, other firewalls
may have similar things, but I don't know of any that call it RELATED).

>> It would be surprising without "extra magic" and SMTP protocol level
>> inspections.

Correct.

--Per Hedeland
per@hedeland.org

Re: setting up dmz server for etrn?

On 01/23/08 18:29, Per Hedeland wrote:
> No, RELATED doesn't mean "same IP pair", that would be hole big enough
> to drive a truck through.

Dough!

No matter. I have written such rules using the IPTables "recent" match
extension to remember specific things for a while. Rules could be
written using "recent" to watch for the start and successfully three way
hand shake of the TCP session from the LAN server to the DMZ server and
allow new inbound connections up to the point that the original
connection was torn down. Once the existing inbound connection is
established, the outbound one can be closed.

> You could probably write a "conntrack helper" that made iptables
> consider the connection resulting from an ETRN to be RELATED to the
> original one - maybe someone has already written such a thing - but it
> won't happen just because it's the "same IP pair".

*nod*

I think a more generic pseudo-related helper / state would be of more
use and provide the same functionality.

> (And of course the term RELATED is iptables-specific, other firewalls
> may have similar things, but I don't know of any that call it RELATED).

*nod*

>>> It would be surprising without "extra magic" and SMTP protocol level
>>> inspections.
>
> Correct.

I still think this could be done with out having to know a thing about SMTP.

- Add an entry to the recent list when the internal LAN server
three way hand shakes with the external DMZ server.
- Allow new inbound connections from the external DMZ server to the
internal LAN server if there has recent(ly) been a connection in the
recent list.
- Remove the entry from the recent list when the outbound
connection is closed.
- Continue allowing the inbound connection because it is now in the
ESTABLISHED state.

This does not require any knowledge of the SMTP protocol, just
intelligently looking at packets and connection states.

Granted if you wanted to write a connection tracking helper, yes
knowledge of SMTP would be required. However seeing as how I think this
can be done with out an SMTP specific connection tracking helper,
knowledge of SMTP is not needed.



Grant. . . .

Re: setting up dmz server for etrn?

Mike wrote:

> Grant Taylor wrote:
> > On 01/22/08 15:11, Mike wrote:
> >> I could securely pull all files in the queue (/var/spool/mqueue)
> >> using rsync over ssh. Doing this method I really want to have two
> >> (more?) queues. One for traffic destined for inside my firewall and
> >> the other for DSN and other internet-bound messages.
> >
> > Before I went this route, I'd look in to trying something along the
> > lines of using UUCP to transfer the messages via an SSH connection (if
> > it's not too difficult to set up).
>
> Ok, how do I setup the two sides. I need the dmz box to put the incoming
> messages into a queue and to send those messages to the inside box when
> the inside box initiates the uucp connection.
>
> Seems like the uucp route should be a lot easier than fiddling with scripts.
>
> Mike

I'll be the first guy to propose UUCP when the situation warrant it but
it is not the easier solution.

Pulling mail with UUCP is good when you are rarely connected to the
internet or your IP change on a regular basis [or you are a fan, or you
want to hide your IP from being put in received header or your ISP
blocks SMTP port 25, ...].

DMZ / internal network / setting up your own SMTP servers, it seems you
are entirely in control of everything.

The easiest way, if the DMZ and the internal SMTP servers are on static
IPs, and you have control of the NAT firewall between the 2, is to just
forward incoming connection on a specific port on the NAT firewall to
the internal SMTP server.

The sendmail FAQ as an entry on forwarding mail to a different port. You
can further shield the internet from accessing that internal route by
restricting the forwarding entry to the source address of DMZ SMTP
server if your NAT firewall supports something like this.

On the DMZ server, that be something like:

access:
to:domain.tld RELAY

mailertable
domain.tld relay:[NAT Firewall IP]

That's if you use the 2nd exemple of
http://www.sendmail.org/faq/section3.html#3.39


Just saying.

Re: setting up dmz server for etrn?

On 01/25/08 10:52, Hugo Villeneuve wrote:
> The easiest way, if the DMZ and the internal SMTP servers are on
> static IPs, and you have control of the NAT firewall between the 2,
> is to just forward incoming connection on a specific port on the NAT
> firewall to the internal SMTP server.

I got the (mis)understanding that the OP wanted to only allow
connections from the DMZ server to the LAN server in response to
internally initiated SMTP ETRN commands, not all the time. Essentially
have the DMZ server hold on to the messages like a relay until I tell
and allow you to send them.

I guess the OP could run a relaying mail server with out a queue runner
and manually run the queue for messages when s/he opened up the
firewall. It's a thought.



Grant. . . .

Re: setting up dmz server for etrn?

Mike writes:

> In article , Grant Taylor wrote:
>> On 01/22/08 15:11, Mike wrote:
>>> I could securely pull all files in the queue (/var/spool/mqueue)
>>> using rsync over ssh. Doing this method I really want to have two
>>> (more?) queues. One for traffic destined for inside my firewall and
>>> the other for DSN and other internet-bound messages.
>>
>> Before I went this route, I'd look in to trying something along the
>> lines of using UUCP to transfer the messages via an SSH connection (if
>> it's not too difficult to set up).
>
> Ok, how do I setup the two sides. I need the dmz box to put the incoming
> messages into a queue and to send those messages to the inside box when
> the inside box initiates the uucp connection.
>
> Seems like the uucp route should be a lot easier than fiddling with scripts.

It is possible to:
a) make sendmail accept incoming smtp session via stdin&stdout
["sendmail -bs" on internal host ]
b) create mailer that sends over stdin&stdout
[P=[LPC] and F=% on DMZ host ]
c) use two help scripts and SSH/SSL connection to glue the above
together

Are you ready to test it?

--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
I DON'T THINK I'M ALONE when I say I'd like to see more and more planets
fall under the ruthless domination of our solar system.
-- Jack Handley, The New Mexican, 1988.
----
http://groups.google.com/groups?selm=

Re: setting up dmz server for etrn?

In article

Grant Taylor writes:
>
>No matter. I have written such rules using the IPTables "recent" match
>extension to remember specific things for a while. Rules could be
>written using "recent" to watch for the start and successfully three way
>hand shake of the TCP session from the LAN server to the DMZ server and
>allow new inbound connections up to the point that the original
>connection was torn down. Once the existing inbound connection is
>established, the outbound one can be closed.

Yes, that should work - assuming that sendmail actually starts up the
outbound connection at the point where the ETRN command is given and
doesn't wait until QUIT. I haven't checked the source, but there doesn't
seem to be any point in waiting, so it's probably immediate - otherwise
you could of course allow connections for a few seconds after connection
close too. This doesn't give *quite* the "confidence level" of RELATED
though.

>>>> It would be surprising without "extra magic" and SMTP protocol level
>>>> inspections.
>>
>> Correct.
>
>I still think this could be done with out having to know a thing about SMTP.

The thing is that snooping the traffic you could allow inbound
connections only when an ETRN was actually sent, and not when you were
just sending outbound mail - and only *then* can you make some claim
that the connections are actually RELATED, and not just coinciding in
time - though it's still weaker than e.g. ftp control channel snooping.

--Per Hedeland
per@hedeland.org

Re: setting up dmz server for etrn?

In article

Grant Taylor writes:
>On 01/25/08 10:52, Hugo Villeneuve wrote:
>> The easiest way, if the DMZ and the internal SMTP servers are on
>> static IPs, and you have control of the NAT firewall between the 2,
>> is to just forward incoming connection on a specific port on the NAT
>> firewall to the internal SMTP server.
>
>I got the (mis)understanding that the OP wanted to only allow
>connections from the DMZ server to the LAN server in response to
>internally initiated SMTP ETRN commands, not all the time.

I got the understanding that the OP didn't want to allow inbound
connections from the dmz server period - which means that no amount of
iptables manipulation is "good enough". Some people just have that as
no-exceptions rule, personally I think that's overdoing it, but it's
obviously up to the firewall/dmz owner/admin to make the rules.

--Per Hedeland
per@hedeland.org

Re: setting up dmz server for etrn?

On 1/25/2008 6:05 PM, Per Hedeland wrote:
> Yes, that should work - assuming that sendmail actually starts up the
> outbound connection at the point where the ETRN command is given and
> doesn't wait until QUIT. I haven't checked the source, but there doesn't
> seem to be any point in waiting, so it's probably immediate - otherwise
> you could of course allow connections for a few seconds after connection
> close too. This doesn't give *quite* the "confidence level" of RELATED
> though.

*nod*

> The thing is that snooping the traffic you could allow inbound
> connections only when an ETRN was actually sent, and not when you were
> just sending outbound mail - and only *then* can you make some claim
> that the connections are actually RELATED, and not just coinciding in
> time - though it's still weaker than e.g. ftp control channel snooping.

Valid point. I was thinking that the LAN server would send directly to
the destination server rather than passing through the DMZ server.
However if this is not the case and the LAN server is Smart Hosting
through the DMZ server, then what you have pointed out would indeed be a
problem. I think it could be mitigated, but would still be a problem
that would have to be dealt with.



Grant. . . .