| Previous | Contents | Index |
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.
28.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.
28.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 |
! 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.
28.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.
28.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 28.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 |
! 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 28.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 |