At 01:56 PM 05/11/97 +1100, Jan Zeilinga wrote:
## Reply Start ##
>The current purposed configuration is to allow smtp traffic through the
>firewall to our exchange server. The exchange server then decides what to
>do with the mail and routes it on-wards to its destined servers within our
>network. My question is would you use the smtp security server with
>firewall-1 to do this, no security server at all or allow connections to
>port 25 from the internet, or install an other smtp proxy...
>
>What purpose would the smtp proxy serve?
If we consider, as mathematicians and logicians are wont to do,
a limiting case. Lets also simplify it, running back to the
classical router+bastion+router model.
Inside, there is a mail server, a single point of contact for all
mail operations. Lets call it "MailHost". It holds all the internal
mailboxes, however you choose to implement them. It is inaccessible
from the outside, and hence can be considered 'protected' to whatever
degree the 'firewall' is doing so. (pardon my mad cackle at this point)
Outside, there is "MailGate", which is the mail server seen from the
internet. This may be the bastion, or something dedicated on the DMZ.
It is here that you run your stripped down mail daemon. This daemon
is so incredibly dumb its not true. It merely accepts mail messages.
Its so dumb it cannot be spoofed - that is its definitely not sendmail.
Its job is purely to accept mail into a spool area.
There is also a relayer program, the second part of the STORE AND FORWARD
proxy. This is marginally less dumb. Where if a hacker were to break
in to the listener daemon, it would find out nothing about the internal
network, its users or names or configuration, the relayer at least knows
that there IS an internal network, and what its name is.
Now ideally, the listener will run chrooted and asynchronous to the
relayer; that is the listener will NEVER spawn (fork/execl) the relayer.
The relayer knows the name of the internal network (and possibly any
supported virtual domains). This is can discard messages which spammers
are using your site as a forwarder for. (sorry about the grammar there)
The job of the relayer is purely to pass the messages thru the 'firewall'
to the MailHost.
The MailHost has the knowledge of the internal network and the users.
Use of suitable firewall configuration, filters on the routers and perhaps
TCPWrappers means that MailHost will accept mail ONLY from the internal
network and MailGate. We can argue about the protection for MailGate
endlessly.
For outgoing mail, there is a similar set of filters, and MailGate
will only accept it if it comes from MailHost. Issues like 'hostname
stripping', so that all mail seems to come from "user @
domain .
com" rather
than "user @
internalhost .
domain .
com" can be done by the MailHost.
There are many variations on this.
The advantages are many. You may consider that if Mailgate is taken
out by an attack form the internet then MailHost survives; it can queue
outgoing messages and deal with the internal flow.
Some sources suggest having a Mailgate separate from the bastion/firewall,
so that if the MailGate is taken out other services still function, and
conversely of the bastion is taken out the MailGate can still queue
incoming messages. Once again, there are permutations.
That is a broad outline. Its also probably a more comprehensive
answer than you asked for. Its also not very innovative; this
is pretty standard stuff. The move to put a "firewall in a box"
is clouding the issues of "Separation of Duties/Process" which were
once an important part of security design.
/anton
## Reply End ##
--------------------------------------------------------------------------
Anton J Aylward | "Quality refers to the extent to which
The Strahn & Strachan Group Inc | processes, products, services, and
Information Security Consultants | relationships are free from defects,
Voice: (416) 421-8182 | constraints and items which do not add
Fax: (416) 421-8183 | value." - Dr. Mildred G Pryor, 1995
|
|
