Chapter 24. Two Sample Firewalls

24.1.1.1. HTTP and HTTPS

For outgoing HTTP and HTTPS (letting our users access other sites), we can use either packet filtering or proxy servers. Packet filtering will allow our users to access HTTP and HTTPS servers only on standard ports; proxying will allow them to reach all HTTP and HTTPS servers. Which approach should we take?

Standard browsers support HTTP and HTTPS proxying, so we don't need to worry about using customized clients with either approach. Proxying will increase configuration overhead, but that price seems fair for the increased abilities it offers.

On the other hand, we could simply allow internal hosts to create connections to port 80, port 443, and any port at or above 1024. That will allow access to almost any HTTP or HTTPS server and will also be useful for supporting FTP. It does add a significant amount of risk; internal users will be able to use any protocol above 1024, with no control from the firewall. If these users are ill intentioned or even careless, they could expose the site to all sorts of dangers. In addition, any Trojan horse programs they bring in will easily be able to send out data. However, we originally chose to trust the users, so this is not an issue. Using pure packet filtering this way would lose us only servers at nonstandard ports below 1024, and those ports are all supposed to be reserved anyway.

If we use a caching proxy server, we significantly improve HTTP performance for all of the following:

HTTP clients

They obtain pages from the cache over the internal network, rather than from the original server over our Internet connection, which is probably much slower.

Non-HTTP clients

The HTTP clients won't be using so much of the bandwidth of our Internet connection, leaving more of it for other clients to use.

HTTP servers at other sites

They will get only one request from our site for a given page, rather than multiple requests.

ost caching servers will also allow us to provide HTTP service to external sites, so we can take advantage of that to publish our site's own public web pages. This configuration is not particularly secure; the security requirements for proxying and publishing are different, and ideally we would want to separate the two. However, in a configuration with only one bastion host, we can't provide much separation in any case.

Combining the proxying and publishing wouldn't be acceptable if we wanted to provide popular pages, or if we needed much security for the pages we were providing (for instance, if the web pages are used for electronic commerce). In either of those situations, we'd separate the outgoing cache from the public web server, putting them not only on different pieces of software but also on different computers. In fact, we might well choose to have the public web server on somebody else's network altogether, using a commercial web hosting service.

HTTP and HTTPS proxying is also trivial to add once you have other things proxied via SOCKS or TIS FWTK. If we had SOCKS running, it would be very tempting to simply proxy through it because SOCKS is one of the systems that many of the browsers support. On the other hand, it's a lot of trouble to install SOCKS just for HTTP and HTTPS; it's probably not worth it unless we have other applications that will use it. If we used the TIS FWTK HTTP proxy, we'd have to get the users to modify URLs they use. In this case, the users wouldn't be able to cut and paste out of their electronic mail when people tell them about cool new things. Neither SOCKS nor TIS FWTK makes an attractive option in this situation.

However, both proxying (through a proxying server) and packet filtering appear to be attractive and reasonable choices. Proxying is definitely preferable if we aren't going to provide passive-mode FTP directly (which gives our users the ability to talk to servers on any TCP port above 1023). On the other hand, packet filtering would definitely be preferable if we wanted to use clients that didn't come with built-in support for proxying, or if we wanted not to provide an HTTP server and had no other services being proxied.

For this example, we're going to assume that we're providing HTTP and HTTPS service to internal clients via a proxy server running on the bastion host, and that we're using the same server to publish our public web pages to the world. We will take special care to make sure that the proxy component is configured to prevent external users from using the proxy to access either our internal network or other external servers. Our reasons for using a proxy server are based mostly on the added efficiency, although it's also useful to make sure that users can reach HTTP and HTTPS servers on nonstandard ports below 1023.

24.1.1.2. SMTP

What other options do we have? We could put a secure SMTP server on the internal mail server and direct incoming mail to it, but if that SMTP server were compromised, the entire internal net would then be at risk. Alternatively, we could have the bastion host send mail directly to machines on the internal network, but once again, we'd be increasing our vulnerability if the SMTP server on the bastion host were compromised. The compromised bastion host would be speaking to untrustworthy internal SMTP servers, and compromise of the internal net would quickly follow. If the bastion host can speak only to the internal mail server, that narrows the possible attacks it can make; the internal mail server can run a secured SMTP server. Furthermore, by making this choice, messy maintenance tasks are transferred from the security-critical bastion host to the less vulnerable internal mail server.

How about outgoing mail? It would probably be safe to allow internal machines to send mail directly to the outside world, but doing so creates a maintenance headache. (You have to watch the mail configuration on all the internal machines.) Besides, doing this opens another direct connection between the internal and external networks. There aren't any known ways for an SMTP server to attack an SMTP client, but stranger things have happened.

Allowing internal machines to send mail directly to the outside world doesn't seem to bring much advantage either. The only difference it makes is that we'd be able to send mail (but not receive it) when the bastion host is down.

No matter what decision we make, we'll have to configure our mail clients. (Unlike FTP and Telnet, SMTP does not work as installed without modifying configuration files.) In addition, the work to direct the mail to a server is less than the work to correctly send it to the external universe.

The only real question is whether to direct the outgoing mail from the internal machines to the internal mail server or to the bastion host. Directing it to the internal mail server has the same advantages as for incoming mail and keeps internal information away from the bastion host. Mail between internal users should not go through the bastion host.

We'll set up SMTP, as outlined in Chapter 16, "Electronic Mail and News", with the bastion host acting as a middleman for incoming and outgoing mail. Here's what to do:

• Publish DNS MX records that direct incoming mail for the site to the bastion host.

• Configure internal machines to send all outgoing mail to the internal mail server.

• Configure the bastion host to send all incoming mail to a single internal mail server and to send outgoing mail directly to its destination.

24.1.1.3. Telnet

Proxying will require either modified clients or modified user procedures; either one will be tedious to implement. Proxying would allow us to restrict or monitor Telnet usage by user by forcing our users to authenticate to a proxy server before completing their requests. However, remember that we have decided to assume that internal users are trustworthy, so there is no need for authentication. Proxying would be necessary if we were using unassigned or unadvertised IP addresses internally, but that's not the case here either. Because we have trustworthy users and proper IP addresses, proxying for Telnet doesn't provide any advantage over packet filtering, and it's more difficult to set up and maintain. Therefore, for this example, we're going to provide outgoing Telnet via packet filtering.

Incoming Telnet is considerably more difficult to provide safely and conveniently. If it were necessary, incoming Telnet could be provided on the bastion host using extra authentication. However, for a site that is looking for a simple configuration, the reasonable thing to do is to disallow incoming Telnet altogether, replacing it with SSH. That's what we'll do for this example.

24.1.1.4. SSH

Forcing SSH to a single bastion host allows us to make sure that what's coming in is genuinely SSH and that the SSH server is safely configured. On the other hand, it requires us to have user accounts configured on the bastion host. If only a few users need to use SSH, it may be the best way to provide the service. However, with only a single bastion host, significant risks are involved in having user accounts around.

Allowing SSH inbound to all hosts avoids the problem with user accounts on the bastion host but opens up the possibility of having hosts running SSH servers that will do port forwarding, or running other servers altogether on the SSH port. As we discuss in Chapter 18, "Remote Access to Hosts", port forwarding across SSH is a significant risk, which may make your site vulnerable to people who are attacking the client. We will allow SSH inbound to all hosts (we're already trusting internal users).

For a more secure configuration, we would limit the hosts that were accessible via SSH, either by adding another bastion host on the screened network or by treating some internal hosts as screened hosts and allowing SSH to just those hosts.

Since we are allowing incoming SSH, we should also allow outgoing SSH; it would be unjust to ask people to use SSH to access our site but require our users to use insecure Telnet to access other sites. However, we will want to warn our users about the risks of remote port forwarding. Unlike outgoing Telnet, outgoing SSH opens us up to incoming attacks if port forwarding is turned on. (See Chapter 18, "Remote Access to Hosts", for more information about the risks of SSH port forwarding.) For more security, we might want to limit even outgoing SSH to a machine where we could control the clients in use and disallow remote port forwarding. Note that even when SSH is limited to a single machine, it is significantly difficult to prevent users from providing their own SSH clients.

24.1.1.5. FTP

• Support passive mode via packet filtering

• Support normal mode via proxies

A reasonable compromise would be to use both packet filtering and proxies, using a proxying gateway like ftp-gw from TIS FWTK that doesn't require modification of the clients. Clients that support passive mode will work via the packet filters. On platforms where we can easily replace the provided clients, we can provide passive-mode clients; on platforms where we can't easily replace the clients, we can modify user procedures instead.

As we've said, if we wanted to monitor FTP usage, we'd have to use proxying exclusively, but that's not the case here. If we were using an unassigned or unrouted network number, we'd have to do either proxying or network address translation. We also might want to use proxying exclusively if we decided to hide DNS data -- it would save us the trouble of faking data for double-reverse lookups by using a published address with an advertised reverse mapping -- but hiding DNS data is more trouble than it's worth. In a situation where proxying is used exclusively, we'd have to reconsider which proxy server to use. The proxy server we've selected requires users to modify their procedures, which makes sense in the configuration we're discussing because there are no other options. The balance might come out differently if everybody were proxying.

Be aware that in order to use the TIS FWTK ftp-gw proxy server on your bastion host, your packet filtering will have to allow TCP connections from ports above 1023 on your bastion host to ports above 1023 on internal hosts, and from port 20 on external hosts to ports above 1023 on your bastion host, for FTP data channels. (See the discussion of FTP in Chapter 17, "File Transfer, File Sharing, and Printing".) This means that someone who breaks in to the bastion host could easily connect to any server on any internal host that uses a TCP port above 1023 (for example, an X11 server on port 6000). Further, any servers that are using such ports (that is, TCP ports above 1023) on the bastion host itself are also vulnerable. For this reason, if you allow these FTP data connections at all for proxying, you probably want to explicitly block access to internal systems to TCP ports above 1023 where you know, or have good cause to suspect, that servers might be listening. At the very least, the ports you want to block probably include 6000 through around 6003 (assuming four or fewer real or virtual X11 servers per machine; see the discussion of X11 in Chapter 18, "Remote Access to Hosts"). Since we're allowing SSH, we also need to protect the virtual X11 servers that SSH creates, which start at 6010, so we'll extend this port range to 6020.

Keep in mind, however, that blocking specific ports, rather than blocking all ports by default and then allowing specific ports, is generally a dangerous strategy. It's hard to develop and maintain a complete list of ports that need to be blocked at your site. It would be better to block everything by default and then allow only specific ports, but you can't do that with standard (nonpassive) FTP because of the way it works.

Allowing passive-mode FTP with packet filtering is a fairly liberal approach because it allows pretty much any connection to go through as long as it is initiated by the inside. The number of servers above port 1023 is very large. This has some advantages (it lets users access nonstandard HTTP servers, for example), but it may also allow users to access all kinds of services that are unsafe. In allowing it, we're assuming that our users are not only well intentioned, they're also capable of telling the difference between a safe and an unsafe connection, or at least avoiding the temptation to do unexpected things.

Because we've denied incoming Telnet, it makes sense to deny incoming user FTP as well. Both services require approximately the same security measures, and making one of them available would make configuring the other trivial.

Incoming anonymous FTP is a different matter, and we'll provide it. Because we're not a major Internet service provider, and because we're using TIS FWTK already anyway, we can go for security over features and use the TIS FWTK anonymous FTP server. If we were going to provide major anonymous FTP, we'd probably want to use the more feature-filled wuarchive FTP server (see Chapter 17, "File Transfer, File Sharing, and Printing", for a description of its capabilities) and run it on a machine that was not the main bastion host but that was still a bastion host on the perimeter network. Using another bastion host avoids overloading the main bastion host with risky and interacting services.

24.1.1.6. NNTP

For this example, we're going to assume a single external NNTP newsfeed.

24.1.1.7. DNS

For this example, we're going to assume that the DNS server on the bastion host is a secondary server for our domain, and that the primary server is on an internal host. We're not going to do any DNS information hiding.

24.1.2.1. Interior router

[180]UDP has no ACK equivalent.

Here is some additional information about each set of rules in this table:

Spoof-1 and Spoof-2

Spoof-1 blocks incoming packets that claim to come from internal IP addresses (that is, forged packets presumably sent by an attacker). Spoof-2 blocks outgoing packets that claim to come from external IP addresses (these reflect either bad misconfiguration of machines or an attacker's operating inside your network). Spoof-2 may be difficult to implement on some packet filtering systems because it can be easily written only if you can use negation on source addresses (to specify addresses that are not in the internal range). It would be acceptable to omit it in this situation; it is mostly there to protect other people, not to protect your site.

HTTP-1 and HTTP-2

Allow internal HTTP clients to connect to the HTTP proxy server on your bastion host. Clients can use their HTTP connection to the proxy server to request services with any protocol the proxy server will support; the connection from the client to the proxy server will be over port 80, while the connection from the proxy server to the destination server will be over the appropriate port for the desired protocol. Therefore, these rules will support HTTPS as well as HTTP.

Telnet-1 and Telnet-2

Allow outgoing Telnet connections.

SSH-1 and SSH-2

Allow outgoing SSH connections. We have the client port set to "Any" (instead of ">1023" like most of the other protocols) because some forms of authentication require SSH clients to use ports at or below 1023.

SSH-3 and SSH-4

Allow incoming SSH connections. We have the client port set to "Any" (instead of ">1023" like most of the other protocols) because some forms of authentication require SSH clients to use ports at or below 1023.

FTP-1 and FTP-2

Allow outgoing command-channel connections to FTP servers, for use by passive-mode internal clients that are interacting with those servers directly.

FTP-3 and FTP-4

Allow the FTP data channel connections from passive-mode internal clients to external FTP servers. Note that these rules actually allow all connections from internal TCP ports above 1023 to external TCP ports above 1023. That may be more than you want to allow, but there's no way to cover passive-mode FTP with anything less broad, and connections are at least restricted to those opened from the inside.

FTP-5 and FTP-6

Allow normal (nonpassive-mode) internal FTP clients to open an FTP command channel to the proxy FTP server on the bastion host. Note that these rules are actually redundant if you have rules FTP-1 and FTP-2 in place earlier in the list because "Bastion" as a source or destination (covered by rules FTP-5 and FTP-6) is a subset of "All" (covered by rules FTP-1 and FTP-2). Having these redundant rules is going to impose a slight performance cost but makes the rule set easier to understand. It also makes it possible to change rules FTP-1 and FTP-2 (e.g., if you decide you don't want to support passive-mode clients) without accidentally breaking normal-mode client access to the proxy server.

FTP-7 through FTP-9

Allow FTP data connections from the proxy server on the bastion host to nonpassive internal clients. The FTP-7 rule prevents an attacker who has gained access to the bastion host from attacking internal X11 servers via the hole created by rules FTP-8 and FTP-9. If you have other servers internally listening for connections on TCP ports above 1023, you should add similar rules for them. Note that trying to list things that should be denied (as in rule FTP-7) is generally a losing proposition because your list will almost always be incomplete somehow (e.g., because you overlooked or didn't know about some internal service, or because the service was added after the filters were established). However, it's the best you can do in this situation to support normal-mode FTP clients.

SMTP-1 and SMTP-2

Allow outgoing mail from your internal mail server to the bastion host.

SMTP-3 and SMTP-4

Allow incoming mail from the bastion host to your internal mail server.

NNTP-1 and NNTP-2

Allow outgoing Usenet news from your news server to your service provider's news server.

NNTP-3 and NNTP-4

Allow incoming Usenet news from your service provider's news server to your news server.

DNS-1

Allow UDP-based DNS queries and answers from the internal DNS server to the bastion host DNS server.

DNS-2

Allow UDP-based DNS queries and answers from the bastion host DNS server to the internal DNS server.

DNS-3 and DNS-4

Allow TCP-based DNS queries from the internal DNS server to the bastion host DNS servers, as well as answers to those queries. Also allow zone transfers in which the bastion host DNS server is the primary server and the internal DNS server is the secondary server.

DNS-5 and DNS-6

Allow TCP-based DNS queries from the bastion host DNS server to the internal DNS server, as well as answers to those queries. Also allow zone transfers in which the bastion host DNS server is the secondary server and the internal DNS server is the primary server.

Default-1 and Default-2

Block all packets not specifically allowed by one of the preceding rules.

24.1.2.2. Exterior router

• To connect the perimeter net (and thus your site) to the outside world

• To protect the perimeter net and the internal net against the outside world

The differences between the rules for the interior router and the exterior router all have to do with the bastion host. That's because the bastion host sits "outside" of the interior router (i.e., on the side of the interior router towards the Internet), but it sits "inside" of the exterior router (i.e., on the side of the exterior router away from the Internet).

If you can set up filtering on the exterior router, it's a good idea to do so. If nothing else, it can serve as a backup to some of the filtering on the interior router. For this example, you would need to establish the following rules.

[181]UDP has no ACK equivalent.

Here is some additional information about each set of rules in this table:

Spoof-1 and Spoof-2

Block incoming packets that claim to have internal or perimeter net source IP addresses -- that is, forged packets presumably sent by an attacker. Rule Spoof-1 is the same as the Spoof-1 rule on the interior router; rule Spoof-2 is unique to the exterior router.

Spoof-3

Block outgoing packets that claim to have external source IP addresses. These are either forged packets from an attacker on your network or symptoms of bad network misconfigurations. Spoof-3 may be difficult to implement on some packet filtering systems because it can be easily written only if you can use negation on source addresses (to specify addresses that are not in the internal range). It would be acceptable to omit it in this situation; it is mostly there to protect other people, not to protect your site.

HTTP-1 and HTTP-2

Allow the bastion host HTTP proxy server to connect to the HTTP and HTTPS servers on any machine on the Internet. Actually, these rules allow any TCP client program on the bastion host using a port above 1023 to contact any server program on any host on the Internet using any port. This is done so that the HTTP proxy server can contact HTTP servers on nonstandard port numbers (i.e., other than port 80). As broad as these rules are, it's important that they allow only outgoing connections, by examining the ACK bit.

HTTP-3 and HTTP-4

Allow external clients to contact the bastion host HTTP server. There are no equivalent rules on the interior router because no HTTP servers are on the internal network that external clients can access.

Telnet-1 and Telnet-2

Allow outgoing Telnet connections. These are identical to the corresponding rules on the interior router (as are all rules on the exterior router that involve internal and external hosts but nothing on the perimeter net).

SSH-1 and SSH-2

Allow outgoing SSH connections. We have the client port set to "Any" (instead of ">1023" like most of the other protocols) because some forms of authentication require SSH clients to use ports at or below 1023. These are the same as the corresponding rules on the interior router.

SSH-3 and SSH-4

Allow incoming SSH connections. We have the client port set to "Any" (instead of ">1023" like most of the other protocols) because some forms of authentication require SSH clients to use ports at or below 1023. These are the same as the corresponding rules on the interior router. If there is a need to allow administrators to reach the bastion host with SSH for remote administration, we will need to add another pair of rules. As it is, administrators can use SSH to an internal host and then connect from there to the bastion host, but this is somewhat fragile (if the interior router is down, there will be no way to administer anything remotely).

FTP-1 through FTP-4

Allow outgoing passive-mode FTP connections and are identical to the corresponding rules on the interior router.

FTP-5 and FTP-6

Allow the FTP proxy server on the bastion host to open an FTP command channel to FTP servers on the Internet. Note that, unlike the corresponding rules on the interior router, these rules are not redundant if you have rules FTP-1 and FTP-2 in place earlier in the list. Why? Because "Bastion" as a source or destination (covered by rules FTP-5 and FTP-6) is not a subset of "Internal" (covered by rules FTP-1 and FTP-2).

FTP-7 through FTP-9

Allow FTP data connections from external FTP servers to the proxy server on the bastion host. The FTP-7 rule prevents an attacker from attacking X11 servers on the bastion host via the hole created by rules FTP-8 and FTP-9. If other servers on the bastion host are listening for connections on TCP ports above 1023, you should add similar rules for them. Note that trying to list things that should be denied (as in rule FTP-7) is a losing proposition because your list will almost always be incomplete (e.g., because you overlooked or didn't know about some service or because the service was added after the filters were established). However, it's the best you can do in this situation if you must support normal-mode FTP.

FTP-10 through FTP-15

Allow passive- and normal-mode FTP from external clients to the anonymous FTP server on the bastion host. There are no equivalent rules on the internal router because no FTP servers are on the internal network that external clients can access.

SMTP-1 and SMTP-2

Allow outgoing mail from the bastion host to the outside world.

SMTP-3 and SMTP-4

Allow incoming mail from the outside world to the bastion host.

NNTP-1 to NNTP-4

Allow Usenet news both ways between your Usenet news server and your service provider's news server. These rules are identical to the corresponding rules on the interior router.

DNS-1

Allows UDP-based DNS queries and answers from the bastion host DNS server to DNS servers in the outside world.

DNS-2

Allows UDP-based DNS queries and answers from Internet DNS servers to the bastion host DNS server. Note that rule DNS-2 (which allows server-to-server communication) is redundant if rule DNS-3 (which allows client-to-server communication) is present.

DNS-3 and DNS-4

Allow external UDP-based DNS clients to query the DNS server on the bastion host and it to answer them.

DNS-5 and DNS-6

Allow TCP-based DNS queries from the bastion host to DNS servers on the Internet, as well as answers to those queries. Also allow zone transfers in which the bastion host DNS server is the secondary server and an external DNS server is the primary server.

DNS-7 and DNS-8

Allow TCP-based DNS queries from the outside world to the bastion host DNS server, as well as answers to those queries. Also allow zone transfers in which the bastion host DNS server is the primary server and an external DNS server is the secondary server.

Default-1 and Default-2

Block all packets not specifically allowed by one of the preceding rules, just as the corresponding rules do on the interior router.

24.1.4.1. Least privilege

24.1.4.2. Defense in depth

Several times, we've explicitly made decisions to increase the depth of defense. For example, that's one of the main purposes of using an internal mail server between the bastion host and the internal clients. The interior and exterior routers often deny the same packets. Defense in depth is almost the only reason for having the interior router deny packets that it supposedly can't receive (because they've already been denied by the exterior router).

24.1.4.3. Choke point

24.1.4.4. Weakest link

Allowing inbound SSH to every host is another candidate for the weakest link; it is the point where we put the most trust in the users. Users who choose poor passwords or set up SSH tunnels can easily undermine the security of the firewall. This could be strengthened significantly by restricting SSH to a dedicated bastion host, which could help enforce password and tunneling restrictions. Users could still connect from that host to internal hosts.

The proxy FTP setup we've described would allow an attacker who has compromised the bastion host to attack servers on ports above 1023 (if there are any) on internal hosts. How can you address this vulnerability? Obtain and use only passive-mode FTP clients internally, don't run proxy FTP, and remove the rules allowing proxy FTP from the filters.

Combining incoming and outgoing HTTP service has several drawbacks. First, the server program itself is more complicated; it is trying to enforce different restrictions for internal and external users, and bugs or misconfigurations may inappropriately mix the two, allowing external users to use the server to attack internal machines or third parties. Second, public HTTP servers attract attackers, who you do not want to concentrate on a machine that is important to your site's functioning. You could address this problem by moving the public HTTP server to a dedicated machine, or even using an outside web hosting service to remove it from your site altogether.

As discussed in Chapter 3, "Security Strategies", there are two reasons for knowing what the weakest links in your firewall are. The first reason is so that you can fix them, if possible; we've already talked about things you might change in this firewall to strengthen some of the weak links. The second reason is so that you can monitor those links which you cannot eliminate for one reason or another. For instance, to address the risks posed by allowing SMTP from the bastion host to the internal mail server, you can't practically disallow incoming SMTP; that would cut off incoming mail from the outside world, which probably isn't appropriate. Since you can't eliminate that weak link, you should instead monitor it closely to make sure that an attacker doesn't take advantage of it (i.e., you should monitor the internal mail server for attacks from the bastion host via SMTP, by monitoring the SMTP logs and reports on the internal mail server).

You can keep playing the game of thinking "If I were an attacker, what would I do?" and then addressing the problems you discover ad nauseam, or until you run out of time or money. At some point, though, you (or your management) will probably decide you've done enough (based on your own site's definition of "enough").

24.1.4.5. Fail-safe stance

24.1.4.6. Universal participation

To some extent, we're relying on voluntary universal participation. We've granted free Telnet, SSH, and FTP access, and in the process, we've allowed any outbound connection to ports at or above 1024 (which is plenty of rope for the users to hang us with). FTP is by no means the only service above 1024.

In particular, we've assumed that this is your sole connection to the Internet and that internal users aren't just going to bypass the firewall entirely by setting up their own Internet connections. All it takes is one joker with a modem, a PPP software package, and an outside phone line, and you too could have an unprotected back door into your network.

24.1.4.7. Diversity of defense

Using different SMTP servers on the internal mail server and the bastion host would be a fairly major advance in this configuration because that's one of the main weak points of this setup. Even a less secure but different SMTP server on the internal mail server is arguably better than one that's going to yield to the exact same attack that just succeeded on the bastion host. The more vulnerable the SMTP server you're using, the more important an issue this is.

24.1.4.8. Simplicity