How to provide secure email service using JBoss Mail Server 1.0M3

versions: 1.0M3

Overview

This document (draft stage) focuses on providing services to local users who wish to receive and send mail from/to other users on both the local network and internet. 

Issues

There are many issues around email security that you want to attend to:

• DO NOT create "open relays" - It is actually difficult to create an open relay with JBMS.  First off, it is not possible without some manual configuration.  Don't turn AuthRequired to false and you should be okay.  Essentially you do not want users to be able to send OUTGOING mail without prior authentication.  You DO want to allow incoming mail ONLY for local users from "unauthenticated" sources.

• DO NOT pass credentials over clear text.  SMTP and POP are clear text protocols in that you can read them with common tools such as Ethereal or tcpdump.  However, JBoss Mail Server support wrapping these protocols over SSL in a similar fashion to the way your browser goes to secure sites using HTTP over SSL.  You NEED to enable SMTP to allow unauthenticated mail over port 25 for incoming users.  You SHOULD NOT enable authentication over port 25 without requiring TLS (same port but changes to SSL mode).  JBoss Mail Server supports both SMTP/SSL on a dedicated port or SMTP/TLS on the same port.  You can also REQUIRE TLS FOR AUTHENTICATION and thus allow both incoming mail over the plain text protocol and disallow users to pass credentials over clear text.

• Perforance.  Performance IS a security feature.  Many shops create layer and layers of network devices in vertical teirs with the idea that crackers will need to get a few layers deep to get to sensitive systems.  However, most attacks these days are not so intent on getting to protected data, but to disable the services themselves.  This is not to say that you should never worry about protected data, but that you should also worry about deliberate traffic spikes/etc.  The more layers of network serialization involved in the service, the more processor, bandwidth, etc. consumed per request especially in an attack.  Moreover, mail servers are especially vulnerable to misuse (if they can be cracked they can send spam).  Adding more mail servers in vertical tiers may actually make the problem worse in the end (the more special routing rules required, the more likely you are to experience logical or configuration errors that can be exploited).  We suggest a single load balancer of firewall component that only allows specific incoming and outgoing traffic.  Common equipment such as BigIP can perform this service.  Crackers/Spammers will see the load balancer which will be presumably harder to crack when properly configured to only allow port 25 traffic.  Moreover, we suggest iptables rules on each mail server with two NIC cards and specific rules for each NIC.  One NIC should be dedicated to serving local users with the POP/SSL and SMTP/SSL, the other to serving pure SMTP for incoming mail.  This is a fairly flat but simple and secure network.

• Authentication. You want to use resources such as database and LDAP servers as security.

• Security through Obfuscation or Obscurity. You are not fooling anyone, attacks on these services are well known.  It does not matter if passwords are in clear text on the filesystem because if someone is on that system, they can decrypt the password (since the system has to anyhow in order to verify it and thus all the information they need to decrypt it is there).  It is quite a different matter if they are in the clear over the network.  Focus on real problems not ceremony. You need to think "who should be allowed here" and "how do I prevent them from getting here" and lock down filesystem permissions, database permissions/etc.

Configuration

The GUI installer creates a very basic configuration.  While this is not too bad for a small network, you need to customize things for a highly available "high value target".  Meaning if I'm setting up an internal-only mail server for Bob's car wash I'll take different measures than for the internet mail server for SCO.  The above is one recommended topology to achieve this.  Do this by creating seperate instances of SMTP bound to different NIC addresses.

Use the installer to create both an SMTP (no TLS) and SMTP/SSL instance as well as a POP/SSL instance and then make the changes indicated below.  The POP/SSL instance should left "as is" with the exception of the bind port should be the local nic.

  <!--
    SMTPProtocol is used for a "Server" instance.  This is an unencrypted
    protocol, this instance is configured for receiving incoming unencrypted mail.
  -->    
  <mbean code="org.jboss.mail.smtp.SMTPProtocol"
    name="jboss.mail:type=MailServices,name=SMTPProtocol">
...
    <attribute name="AuthRequired">true</attribute>  <!-- there are more attributes that you should copy but we have only -->
    <attribute name="VerifyIdentity">true</attribute><!-- included the ones important for this setup -->
    <attribute name="RequireTls">false</attribute>   <!-- for 1.0M3 (this is stinky) you requireTlsForAuth(entication) but -->
    <attribute name="RequireTlsForAuth">true</attribute> <!-- disable TLS in order to prevent authentication -->
    <attribute name="TlsEnabled">false</attribute>   <!-- but you MUST require authentication to send emails -->
...
  </mbean>

  <!-- defines an SMTP server.  -->
  <mbean code="org.jboss.mail.Server"
    name="jboss.mail:type=MailServices,name=SMTP">
    <depends>jboss.mail:type=MailServices,name=SMTPProtocol</depends>
     <!-- should link to the protocol factory in depends.  Presently classpath protocol factories
          aren't supported unless they can find their own properties -->
<!--     <attribute name="ProtocolFactoryName">jmx:jboss.mail:type=MailServices,name=ProtocolFactory</attribute>-->
      <!-- protocol should reference SMTP protocol above by name -->
     <attribute name="Protocol">jboss.mail:type=MailServices,name=SMTPProtocol</attribute>
     <!-- port to listen on -->
     <attribute name="Port">25</attribute>
     <!-- which addresses to listen on 0.0.0.0 = all or localhost means only the localhost  -->
     <attribute name="Address">123.123.123.123</attribute> <!-- configure as the NIC pointed at the LB -->
  </mbean>

  <!-- this is the encrypted SMTP Protocol for local users sending mail OUT -->
  <mbean code="org.jboss.mail.smtp.SMTPProtocol"
    name="jboss.mail:type=MailServices,name=SMTPSSLProtocol">
    <depends>jboss.security:service=JaasSecurityDomain,domain=Mail+SSL</depends>
    <attribute name="SecurityDomain">java:/jaas/Mail+SSL</attribute>
...
    <attribute name="AuthRequired">true</attribute>
    <attribute name="VerifyIdentity">true</attribute>
    <attribute name="RequireTls">false</attribute>        <!-- you do not want SMTP/SSL and TLS at the same time -->
    <attribute name="RequireTlsForAuth">false</attribute>
...
  </mbean>

  <mbean code="org.jboss.mail.Server"
    name="jboss.mail:type=MailServices,name=SMTPSSL">
    <depends>jboss.mail:type=MailServices,name=SMTPSSLProtocol</depends>
     <!-- should link to the protocol factory in depends.  Presently classpath protocol factories
          aren't supported unless they can find their own properties -->
     <!-- protocol should reference SMTPSSL protocol above though it is actually the SERVER instance providing encryption -->
     <attribute name="Protocol">jboss.mail:type=MailServices,name=SMTPSSLProtocol</attribute>
     <!-- Secure servers require a security domain -->
     <attribute name="SecurityDomain">java:/jaas/Mail+SSL</attribute>
     <!-- port to listen on -->
     <attribute name="Port">465</attribute>
     <!-- which addresses to listen on 0.0.0.0 = all or localhost means only the localhost  -->
     <attribute name="Address">192.168.1.1</attribute> <!-- should be the NIC talking to the local network -->
     <attribute name="UsesSSL">true</attribute>
...
  </mbean>

Final steps

• Switch to JAAS login modules rather than StaticUserRepository such as LDAP or DBMS.

• Do not forget to secure the underlying application server and perhaps remove unused services from the appserver. 

• Ensure you do not run as root by making use of port forwarding.