PMDF System Manager's Guide


Previous Next Contents Index

30.4.1 Separating Message Traffic

One of the fundamental issues for a firewall configuration tends to be separation between internal and external messages: separating message traffic allows for tracking and appropriately controlling the different sorts of messages. So the first recommendation for a firewall system is to set up separate channels to handle messages originating from external sites versus messages originating from internal systems.

For background on rewrite rules, see Section 2.2; for background on channels, see Section 2.3.

30.4.1.1 Separating SMTP Over TCP/IP Message Traffic

The most common case is where messages originating from external sites come in to the PMDF system as SMTP messages over a TCP/IP channel. To separate the externally originating SMTP messages from internally originating SMTP message, use a separate TCP/IP channel in addition to the default TCP/IP channel; e.g., use a tcp_internal channel in addition to the default tcp_local channel. Put the switchchannel channel keyword on your current tcp_local channel, the allowswitchchannel channel keyword (the default) on the tcp_internal channel and any other channels you want to allow switching to, and put noswitchchannel on all other channels, e.g., the local channel, and use rewrite rules to associate internal TCP/IP system names and IP addresses with the tcp_internal channel and all other domains, e.g., Internet domains, with the tcp_local channel.

When deciding whether and to what channel to "switch" an incoming connection, PMDF uses the literal IP address of the incoming connection to perform a reverse-pointing envelope rewrite looking for an associated channel. If that rewrite fails, or if that rewrite matches the default incoming TCP/IP channel, then PMDF will try rewriting the host name as found by a DNS reverse lookup on the incoming IP address; (depending on the use of any ident* keywords, such DNS reverse lookups can be disabled).

So in order to allow internal systems to be recognized as such, you should use IP literal rewrite rules to associate internal IP literals (at least during backwards envelope rewriting) with your internal TCP/IP channel. (Note that even if you do not normally use any IP literal rewrite rules so that PMDF tries to fall through to using host names, you should have such rewrite rules for your internal systems in case of DNS problems causing DNS reverse lookup failures.) If you want to limit the rewriting of internal IP numbers to actual system names in the forward direction, say if you do not want to allow external users to "probe" for internal IP number/internal system name correspondences, then you can want these IP literal rewrite rules to be backwards envelope specific, i.e., $E$R rewrite rules.

Note that the default incoming TCP/IP channel is tcp_local and only system names or IP numbers recognized as internal system names are "switched" to the tcp_internal channel. This provides "failsafe" behavior; systems not specifically recognized (even internal systems, if the PMDF configuration has not been set up to recognize them) are handled by the external, "unsafe" channel.

By default, PMDF allows any channel to be "switched to"; i.e, the default is allowswitchchannel. On a firewall system in particular, it is likely appropriate to make noswitchchannel the default --- for instance, you probably do not want to allow "switching" to the local channel---and mark only the specific channels for which you want to allow switching with the allowswitchchannel channel keyword.

30.4.1.1.1 Sample Configuration with Separate TCP/IP Channels

For instance, a site whose internal systems' IP numbers are all in the [a.b.subnet] range, might want channels


defaults noswitchchannel routelocal 
 
l defragment ... 
official-local-host-name
 
... 
 
tcp_local single_sys smtp mx remotehost switchchannel inner 
TCP-DAEMON 
 
tcp_internal single_sys smtp mx noremotehost allowswitchchannel routelocal 
TCP-INTERNAL 
 
and rewrite rules


! Rewrite rules for private TCP/IP systems/domains 
! 
internaldomain1       $U%internaldomain1@TCP-INTERNAL 
internaldomain2       $U%internaldomain2@TCP-INTERNAL 
... 
! Rewrite rules for private TCP/IP system/domain literals 
! 
[a.b.]                $U%[a.b.$L]@TCP-INTERNAL$E$R 
... 
! Rewrite rules for the Internet 
!    Principality of Andorra 
.AD                                     $U%$H$D@TCP-DAEMON 
... 
!    Zimbabwe 
.ZW                                     $U%$H$D@TCP-DAEMON 

Note also how the remotehost and noremotehost channel keywords are used on these channels. The remotehost and noremotehost channel keywords affect PMDF's handling of bare usernames ("addresses" that are illegally formatted in that they have no domain name). PMDF always inserts a domain name on such addresses, to make the addresses syntactically legal. For envelope To: addresses that are missing a domain name, PMDF always inserts the local host name. However for other sorts of addresses, such as From: addresses, another factor comes into play. The remotehost channel keyword on the tcp_local channel (handling incoming messages from external sites) tells PMDF to use the remote sending system's name (as determined by a reverse DNS lookup); the default noremotehost channel keyword on the tcp_internal channel (handling incoming messages from internal sites) tells PMDF to use its own local host name, which can be particularly appropriate in the case of poorly configured POP clients.

The routelocal keyword causes PMDF to attempt "short circuited" rewriting of any explicit routing in the address, such as ! routing, %-hack routing, or @ source routing. If a site expects no legitimate uses of explicit source routing, then blocking such usage blocks a potential way for external senders to relay messages by explicitly routing them past the firewall system through internal systems. Of course, sites that have legitimate uses of explicit routing will not be able to afford to block such usage and hence should not use routelocal on all channels.

The inner keyword causes PMDF address rewriting to be applied to addresses in embedded message parts (MESSAGE/RFC822 parts) within the message; if you are applying address reversal on outgoing messages, this is liable to be desirable.

30.4.1.2 The Case of an Internal Mailhub

In the case where the e-mail firewall relays all messages for internal systems to an internal mailhub system, and receives internal messages only from the internal mailhub, message traffic separation is straightforward: the connection to and from the mailhub system is the only internal connection, and all other connections are external.

Indeed, this can be thought of as a two system e-mail firewall setup, where the system we have been referring to as "the" e-mail firewall is the external portion of the e-mail firewall, and the mailhub system is the internal portion of the e-mail firewall. (In such a setup, particularly if the internal mailhub is a capable system such as another PMDF system, you can even want to have the e-mail firewall system be ignorant of internal addressing details which are handled by the internal mailhub system.)

For such a setup you will want an internal channel for communicating with the internal mailhub, and an external channel (generally a TCP/IP channel, but UUCP, Phonenet, etc. channels are also possible) or channels for communicating with the rest of the world, and corresponding rewrite rules.

30.4.1.2.1 Sample Configuration With an Internal Mailhub System

For instance, for a site using SMTP over TCP/IP to communicate between the e-mail firewall and the mailhub, and with an SMTP over TCP/IP connection to the Internet, a configuration where all internal mail passes through the internal mailhub is simply a special (and potentially simpler) case of having separate TCP/IP channels, as in Section 30.4.1 above, with the major difference being that the tcp_internal channel should be a daemon router channel connecting to the mailhub system, e.g.,


defaults noswitchchannel routelocal 
 
l defragment ... 
official-local-host-name
 
tcp_local single_sys smtp mx remotehost switchchannel inner 
TCP-DAEMON 
 
tcp_internal smtp mx remotehost allowswitchchannel daemon router 
mailhubdomain
TCP-INTERNAL 
 
and rewrite rules


! Rewrite rules for private TCP/IP systems/domains 
! 
internaldomain1       $U%internaldomain1@TCP-INTERNAL 
internaldomain2       $U%internaldomain2@TCP-INTERNAL 
... 
! Rewrite rules for private TCP/IP system/domain literals 
! 
[mailhubIPaddress]    $U%[mailhubIPaddress]@GTCP-INTERNAL$E$R 
... 
! Rewrite rules for the Internet 
!    Principality of Andorra 
.AD                                     $U%$H$D@TCP-DAEMON 
... 
!    Zimbabwe 
.ZW                                     $U%$H$D@TCP-DAEMON 

Compare this with the sample configuration excerpt shown in Section 30.4.1.1.1.

In this case, since messages from the internal side are coming from a PMDF system, the remotehost keyword is likely appropriate on both channels.


Previous Next Contents Index