| 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 |