Mail server security - best practices? - BSD

This is a discussion on Mail server security - best practices? - BSD ; Okay, here's what I have: A four-legged firewall with public interface (fxp0), private client interface (fxp1), private server interface (sis0), and public server interface (sis1). I am going to be running qmail, apache, and BIND on the public server. The ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: Mail server security - best practices?

  1. Mail server security - best practices?

    Okay, here's what I have:

    A four-legged firewall with public interface (fxp0), private client
    interface (fxp1), private server interface (sis0), and public server
    interface (sis1). I am going to be running qmail, apache, and BIND on
    the public server. The private server is running courier-imap and
    fetchmail and is also where all of my private files are kept. It is
    only accessible from the outside via chrooted OpenVPN.

    The question is, how to divvy up the public services? Right now, the
    plan is to run mail and DNS on one machine and web and DNS on the
    other. Ideally, I'd like for the incoming mail to not "live" on the
    public server but to be delivered to the private one, but that, to me,
    defeats the purpose of having public/private servers. The only way I
    can think to do it would be to have the private server export the home
    directories via NFS so that the email server could deliver the messages
    to the user's home directories.

    Any ideas?


  2. Re: Mail server security - best practices?

    sealinux@gmail.com wrote:
    > Okay, here's what I have:
    >
    > A four-legged firewall with public interface (fxp0), private client
    > interface (fxp1), private server interface (sis0), and public server
    > interface (sis1). I am going to be running qmail, apache, and BIND on
    > the public server. The private server is running courier-imap and
    > fetchmail and is also where all of my private files are kept. It is
    > only accessible from the outside via chrooted OpenVPN.
    >
    > The question is, how to divvy up the public services? Right now, the
    > plan is to run mail and DNS on one machine and web and DNS on the
    > other. Ideally, I'd like for the incoming mail to not "live" on the
    > public server but to be delivered to the private one, but that, to me,
    > defeats the purpose of having public/private servers. The only way I
    > can think to do it would be to have the private server export the home
    > directories via NFS so that the email server could deliver the messages
    > to the user's home directories.


    It's not really possible to have a mail store that is not, at least
    indirectly, accessible from the wide internet (save in special cases).

    FWIW, IMHO it's most important to separate the web scripts from anything
    important. Both BIND and qmail are pretty secure, and while Apache
    itself is quite secure, PHP for instance isn't.

    You could put a mail forwarder in the DMZ ('public servers'), if so
    inclined, but I'd recommend setting up the webserver in it's own private
    DMZ, and mail on a server that's 'half-internal' in that you seem not to
    need stored mail being accessible from the outside.

    For maximum protection, configure a mail forwarder in the DMZ - MTAs are
    pretty secure, but spam and virus scans often use weird programs that
    are not quite as well-tested.

    DNS could be kept where you want it, though the risk of a nasty DoS is
    less if you put it on a separate machine.

    Joachim

  3. Re: Mail server security - best practices?

    jKILLSPAM.schipper@math.uu.nl wrote:

    > It's not really possible to have a mail store that is not, at least
    > indirectly, accessible from the wide internet (save in special cases).


    That was my feeling as well, hence the quandry.

    > FWIW, IMHO it's most important to separate the web scripts from anything
    > important. Both BIND and qmail are pretty secure, and while Apache
    > itself is quite secure, PHP for instance isn't.


    I've since acquired a separate machine to run Apache and PHP on. I'll
    have two servers in the DMZ then, one running Qmail and BIND, the other
    running Apache and BIND.

    > You could put a mail forwarder in the DMZ ('public servers'), if so
    > inclined, but I'd recommend setting up the webserver in it's own private
    > DMZ, and mail on a server that's 'half-internal' in that you seem not to
    > need stored mail being accessible from the outside.


    I can access the stored mail from the outside using OpenVPN. How wise
    is it to trust that? I still employ IMAP-SSL on the private server,
    though.

    > For maximum protection, configure a mail forwarder in the DMZ - MTAs are
    > pretty secure, but spam and virus scans often use weird programs that
    > are not quite as well-tested.


    Let me see if I understand. The machine running Qmail in the DMZ would
    be set to forward incoming mail to my private server, also running
    Qmail, behind the firewall. The former would simply act as a conduit
    to the latter, which would deliver mail to the user's home directories.
    This would involve punching a hole in the firewall to allow
    connections to port 25 on the private server, but that can be locked
    down fairly tightly with pf rules. The main thing is for stuff I want
    kept private to not be widely available.

    > DNS could be kept where you want it, though the risk of a nasty DoS is
    > less if you put it on a separate machine.


    (Having visions of my wallet getting lighter and lighter and lighter .
    .. . ) Seriously, thank dog I'm running OpenBSD. There's no way I
    could afford the big iron and licenses requried to run 'Doze.


  4. Re: Mail server security - best practices?

    sealinux@gmail.com wrote:
    > jKILLSPAM.schipper@math.uu.nl wrote:
    >
    >> It's not really possible to have a mail store that is not, at least
    >> indirectly, accessible from the wide internet (save in special cases).

    >
    > That was my feeling as well, hence the quandry.
    >
    >> FWIW, IMHO it's most important to separate the web scripts from anything
    >> important. Both BIND and qmail are pretty secure, and while Apache
    >> itself is quite secure, PHP for instance isn't.

    >
    > I've since acquired a separate machine to run Apache and PHP on. I'll
    > have two servers in the DMZ then, one running Qmail and BIND, the other
    > running Apache and BIND.
    >
    >> You could put a mail forwarder in the DMZ ('public servers'), if so
    >> inclined, but I'd recommend setting up the webserver in it's own private
    >> DMZ, and mail on a server that's 'half-internal' in that you seem not to
    >> need stored mail being accessible from the outside.

    >
    > I can access the stored mail from the outside using OpenVPN. How wise
    > is it to trust that? I still employ IMAP-SSL on the private server,
    > though.


    OpenVPN is not that bad, security-wise, and has an option to require
    each message to be stamped with a certain key (not at the appropriate
    computer now - see tls-auth.

    Stock IPsec or OpenSSH is better, but tls-auth makes exploiting problems
    very difficult.

    >> For maximum protection, configure a mail forwarder in the DMZ - MTAs are
    >> pretty secure, but spam and virus scans often use weird programs that
    >> are not quite as well-tested.

    >
    > Let me see if I understand. The machine running Qmail in the DMZ would
    > be set to forward incoming mail to my private server, also running
    > Qmail, behind the firewall. The former would simply act as a conduit
    > to the latter, which would deliver mail to the user's home directories.
    > This would involve punching a hole in the firewall to allow
    > connections to port 25 on the private server, but that can be locked
    > down fairly tightly with pf rules. The main thing is for stuff I want
    > kept private to not be widely available.


    That's indeed the point.

    Note that a compromised mail gateway would still lead to an attacker
    being able to read incoming mail; but not mail that was already stored.

    Whether or not this is worth the trouble depends on quite a few things.
    I personally run Postfix with amavisd, clamav, spamassassin, and a
    selected subset of helper programs (especially, none of the weird/old
    archive programs that amavisd likes to have, and that seem to have been
    written before the concept of buffer overflow was widely known and/or
    cared about). Everything is chrooted, and the whole thing runs on
    OpenBSD.

    Under these circumstances, I don't really see the need for a mail
    gateway. Some find it useful, though.

    >> DNS could be kept where you want it, though the risk of a nasty DoS is
    >> less if you put it on a separate machine.

    >
    > (Having visions of my wallet getting lighter and lighter and lighter .
    > . . ) Seriously, thank dog I'm running OpenBSD. There's no way I
    > could afford the big iron and licenses requried to run 'Doze.


    Pointing all your machines to the web server, which is probably the
    easiest to compromise, may allow an attacker to effectively DoS you by
    shutting down BIND.

    However, I would personally not mind sharing the mail gateway and the
    BIND daemon - sure, separating them would be better, but your cost
    argument is sound.

    OTOH, you might want to run a DNS daemon on both DMZ'ed servers if said
    DNS is required for the proper functioning of a/your domain. Then again,
    a free ZoneEdit.com account (or similar) is likely to provide a more
    valuable backup.

    Joachim

  5. Re: Mail server security - best practices?


    jKILLSPAM.schipper@math.uu.nl wrote:

    > OpenVPN is not that bad, security-wise, and has an option to require
    > each message to be stamped with a certain key (not at the appropriate
    > computer now - see tls-auth.
    >
    > Stock IPsec or OpenSSH is better, but tls-auth makes exploiting problems
    > very difficult.


    I'm running tls-auth on the OpenVPN gateway. I'm also using
    passphrase-protected unique keys for each client and 2048 bit
    keylengths. Am I paranoid or what?!?

    How long would a brute force attack on a 2048-bit key take?

    > For maximum protection, configure a mail forwarder in the DMZ - MTAs are
    > pretty secure, but spam and virus scans often use weird programs that
    > are not quite as well-tested.


    I'm not running any of those. The gateway will only be running Qmail
    and BIND on OpenBSD with everything chrooted. I fully appreciate the
    idea that nothing is 100% secure. The whole idea is to make it more
    trouble to hack than the data on the machine is worth.

    > Under these circumstances, I don't really see the need for a mail
    > gateway. Some find it useful, though.


    So you think it best for the incoming mail to "live" on the server on
    the DMZ then?

    > However, I would personally not mind sharing the mail gateway and the
    > BIND daemon - sure, separating them would be better, but your cost
    > argument is sound.


    I can snag a few more white boxes from Re-PC. I'm going to take your
    advice and run the webserver on a separate DMZ, this one with no access
    behind the firewall. The mail gateway will have only port 25 access to
    the one machine behind the firewall. I think PF can be set to look at
    Ethernet addresses?

    > OTOH, you might want to run a DNS daemon on both DMZ'ed servers if said
    > DNS is required for the proper functioning of a/your domain. Then again,
    > a free ZoneEdit.com account (or similar) is likely to provide a more
    > valuable backup.


    I'm not familiar with ZoneEdit.

    Thanks a whole lot for your help. You mind if I contact you directly
    by email?


  6. Re: Mail server security - best practices?

    sealinux@gmail.com wrote:
    >
    > jKILLSPAM.schipper@math.uu.nl wrote:
    >
    >> OpenVPN is not that bad, security-wise, and has an option to require
    >> each message to be stamped with a certain key (not at the appropriate
    >> computer now - see tls-auth.
    >>
    >> Stock IPsec or OpenSSH is better, but tls-auth makes exploiting problems
    >> very difficult.

    >
    > I'm running tls-auth on the OpenVPN gateway. I'm also using
    > passphrase-protected unique keys for each client and 2048 bit
    > keylengths. Am I paranoid or what?!?
    >
    > How long would a brute force attack on a 2048-bit key take?


    For all practical purposes, infinitely long if you chose the key in a
    vaguely competent fashion (i.e., not just typed 2048 null bytes or
    somesuch).

    Good crypto is almost undeafatable; however, implementation errors
    abound, and social engineering is likely to be succesful if enough
    (nontechnical) people have access.

    And breaking the administrator's fingers almost always works.

    >> For maximum protection, configure a mail forwarder in the DMZ - MTAs are
    >> pretty secure, but spam and virus scans often use weird programs that
    >> are not quite as well-tested.

    >
    > I'm not running any of those. The gateway will only be running Qmail
    > and BIND on OpenBSD with everything chrooted. I fully appreciate the
    > idea that nothing is 100% secure. The whole idea is to make it more
    > trouble to hack than the data on the machine is worth.
    >
    >> Under these circumstances, I don't really see the need for a mail
    >> gateway. Some find it useful, though.

    >
    > So you think it best for the incoming mail to "live" on the server on
    > the DMZ then?


    Well, security-wise, 'best' is of course the forwarding scheme. I don't
    see sufficient benefit to it that I would personally use it, though.

    That would be a different matter if the backend mailer was not as
    secure, for instance, Exchange.

    >> However, I would personally not mind sharing the mail gateway and the
    >> BIND daemon - sure, separating them would be better, but your cost
    >> argument is sound.

    >
    > I can snag a few more white boxes from Re-PC. I'm going to take your
    > advice and run the webserver on a separate DMZ, this one with no access
    > behind the firewall. The mail gateway will have only port 25 access to
    > the one machine behind the firewall. I think PF can be set to look at
    > Ethernet addresses?


    Mmm, maybe, but it might be better just to hardcode the MAC addresses.
    See arp(8).

    >> OTOH, you might want to run a DNS daemon on both DMZ'ed servers if said
    >> DNS is required for the proper functioning of a/your domain. Then again,
    >> a free ZoneEdit.com account (or similar) is likely to provide a more
    >> valuable backup.

    >
    > I'm not familiar with ZoneEdit.
    >
    > Thanks a whole lot for your help. You mind if I contact you directly
    > by email?


    No, not at all. The address in the header is valid, save the obvious.

    Joachim

  7. Re: Mail server security - best practices?

    jKILLSPAM.schipper@math.uu.nl wrote:
    > sealinux@gmail.com wrote:
    >>
    >> I can snag a few more white boxes from Re-PC. I'm going to take your
    >> advice and run the webserver on a separate DMZ, this one with no access
    >> behind the firewall. The mail gateway will have only port 25 access to
    >> the one machine behind the firewall. I think PF can be set to look at
    >> Ethernet addresses?

    >
    > Mmm, maybe, but it might be better just to hardcode the MAC addresses.
    > See arp(8).


    The mail server in the DMZ does not need to have access to port 25 on
    a machine behind the firewall. As a stateful firewall, pf can be
    configured to not allow connections from the bastion host in the DMZ
    to the internal (private) network until a connection from the internal
    machines (e.g., the mail server in the internal network) to the bastion
    host is established. This way, if the bastion host is compromised the
    cracker will not be able to attack a machine in the internal network.

    Now, the mail server in the private area can download email from the
    mail server in the DMZ (e.g., establishing a connection each five
    minutes to the mail server in the DMZ or when a user requests email).
    But a compromised bastion host (i.e., the mail server in the DMZ)
    will not have access to internal machines.

    Cheers,
    Igor.

  8. Re: Mail server security - best practices?

    wrote in message
    news:1146113618.952386.325750@i39g2000cwa.googlegr oups.com...
    >
    > The question is, how to divvy up the public services? Right now, the
    > plan is to run mail and DNS on one machine and web and DNS on the
    > other. Ideally, I'd like for the incoming mail to not "live" on the
    > public server but to be delivered to the private one, but that, to me,
    > defeats the purpose of having public/private servers. The only way I
    > can think to do it would be to have the private server export the home
    > directories via NFS so that the email server could deliver the messages
    > to the user's home directories.
    >
    > Any ideas?


    This might sound a bit round-the-houses, but have you considered:

    - Public server picks up the mail
    - User's mail client picks up mail from local public server, as if it were
    an external POP3 server
    - User's mail client uses an IMAP mail store on private machine for
    longterm message storage

    Works for me .

    Steve
    http://www.fivetrees.com



  9. Re: Mail server security - best practices?

    Igor Sobrado wrote:
    > jKILLSPAM.schipper@math.uu.nl wrote:
    >> sealinux@gmail.com wrote:
    >>>
    >>> I can snag a few more white boxes from Re-PC. I'm going to take your
    >>> advice and run the webserver on a separate DMZ, this one with no access
    >>> behind the firewall. The mail gateway will have only port 25 access to
    >>> the one machine behind the firewall. I think PF can be set to look at
    >>> Ethernet addresses?

    >>
    >> Mmm, maybe, but it might be better just to hardcode the MAC addresses.
    >> See arp(8).

    >
    > The mail server in the DMZ does not need to have access to port 25 on
    > a machine behind the firewall. As a stateful firewall, pf can be
    > configured to not allow connections from the bastion host in the DMZ
    > to the internal (private) network until a connection from the internal
    > machines (e.g., the mail server in the internal network) to the bastion
    > host is established. This way, if the bastion host is compromised the
    > cracker will not be able to attack a machine in the internal network.
    >
    > Now, the mail server in the private area can download email from the
    > mail server in the DMZ (e.g., establishing a connection each five
    > minutes to the mail server in the DMZ or when a user requests email).
    > But a compromised bastion host (i.e., the mail server in the DMZ)
    > will not have access to internal machines.


    This works, and is pretty secure, but I do not see it scaling too well.
    For not-too-high amounts of traffic, it works well, though.

    Joachim

  10. Re: Mail server security - best practices?

    jKILLSPAM.schipper@math.uu.nl wrote:
    > Igor Sobrado wrote:
    >>
    >> The mail server in the DMZ does not need to have access to port 25 on
    >> a machine behind the firewall. As a stateful firewall, pf can be
    >> configured to not allow connections from the bastion host in the DMZ
    >> to the internal (private) network until a connection from the internal
    >> machines (e.g., the mail server in the internal network) to the bastion
    >> host is established.

    [...]
    >
    > This works, and is pretty secure, but I do not see it scaling too well.
    > For not-too-high amounts of traffic, it works well, though.


    Hi Joachim.

    I do not doubt you are right, but I cannot see why it does not scale
    well; I feel that I am missing some important point on this set up
    and I will be glad to know about it.

    May I ask you to provide some feedback on this matter?

    I am certainly interested in know why it does not scale well. I think
    that I am missing an important detail in this configuration and I do not
    want to make this mistake when setting up a network. Is it, perhaps,
    as a consequence of email being temporarily stored in a host in the DMZ?
    Is it because email is "quantified" when moved to the internal network?

    Just curious...

    Igor.

  11. Re: Mail server security - best practices?


    Igor Sobrado wrote:

    > Hi Joachim.




    > I am certainly interested in know why it does not scale well.


    I get the impression that it would be a pain in the tochas to,
    essentially, keep track of having all the user accounts on both
    machines all the time. In my case, where I have a few dozen, it isn't
    so bad, but if there were a few million . . .


  12. Re: Mail server security - best practices?

    sealinux@gmail.com wrote:
    >
    > I get the impression that it would be a pain in the tochas to,
    > essentially, keep track of having all the user accounts on both
    > machines all the time. In my case, where I have a few dozen, it isn't
    > so bad, but if there were a few million . . .


    Indeed, in this case it is advisable storing information related with
    these accounts on an LDAP server instead. That is a very good point.

    Thanks for the feedback on this matter,
    Igor.

  13. Re: Mail server security - best practices?

    Igor Sobrado wrote:
    > jKILLSPAM.schipper@math.uu.nl wrote:
    >> Igor Sobrado wrote:
    >>>
    >>> The mail server in the DMZ does not need to have access to port 25 on
    >>> a machine behind the firewall. As a stateful firewall, pf can be
    >>> configured to not allow connections from the bastion host in the DMZ
    >>> to the internal (private) network until a connection from the internal
    >>> machines (e.g., the mail server in the internal network) to the bastion
    >>> host is established.

    > [...]
    >>
    >> This works, and is pretty secure, but I do not see it scaling too well.
    >> For not-too-high amounts of traffic, it works well, though.

    >
    > Hi Joachim.
    >
    > I do not doubt you are right, but I cannot see why it does not scale
    > well; I feel that I am missing some important point on this set up
    > and I will be glad to know about it.
    >
    > May I ask you to provide some feedback on this matter?
    >
    > I am certainly interested in know why it does not scale well. I think
    > that I am missing an important detail in this configuration and I do not
    > want to make this mistake when setting up a network. Is it, perhaps,
    > as a consequence of email being temporarily stored in a host in the DMZ?
    > Is it because email is "quantified" when moved to the internal network?


    Not quite a quick response, but oh well...

    Come to think of it, I cannot think of a *theoretical* reason this
    wouldn't scale well. However, if you try to do something like this with
    fetchmail, you'll find that it's capacity is somewhat limited.

    If using a scalable IMAP server, and a good client, it might work.
    However, just forwarding from within the MTA is very, very likely to be
    quicker.

    Joachim

  14. Re: Mail server security - best practices?

    jKILLSPAM.schipper@math.uu.nl wrote:
    >
    > Not quite a quick response, but oh well...
    >
    > Come to think of it, I cannot think of a *theoretical* reason this
    > wouldn't scale well. However, if you try to do something like this with
    > fetchmail, you'll find that it's capacity is somewhat limited.
    >
    > If using a scalable IMAP server, and a good client, it might work.
    > However, just forwarding from within the MTA is very, very likely to be
    > quicker.


    Hi Joachim!

    As someone with a grade in Theoretical Physics I usually trust
    too much on theoretical reasoning leaving practice somewhat
    unattended. :-)

    Seriously, I will remember your advice. It is a very good point
    that must be considered when designing large computer networks.
    Indeed, I was thinking on fetchmail as an easy way to download
    email from the DMZ, and it is a possible bottleneck on the network.

    Cheers,
    Igor.

+ Reply to Thread