Example 3: FortiMail unit for an ISP or carrier

In this example, a FortiMail unit operating in transparent mode is positioned as an offshoot from the backbone or other primary traffic flow between the internal and external network. A router uses policy-based routes to redirect only SMTP connections to the FortiMail unit, which scans the traffic before allowing legitimate connections to return the overall flow. The FortiMail unit does not receive non-SMTP traffic. (This would result in unnecessary processing and resource usage.)

For increased session-handling capacity, multiple FortiMail units could be clustered into a config-only HA group and deployed behind a load balancer that is attached to the router. Connections to the same source IP address would be handled by the same FortiMail unit to avoid sessions split among multiple units, and to maintain the accuracy of IP statistics. Otherwise, attach a single FortiMail unit to the router.

Service providers often fundamentally require transparent mode. Requiring subscribers to explicitly configure a mail relay can be problematic, and in the case of 3G mobile subscribers, impossible. Therefore gateway mode is not suitable. Transparent mode makes SMTP scanning possible without configuration by the subscriber.

A dual-arm attachment is used. This provides natural isolation of traffic before and after inspection, which can be useful if traffic requires further analysis such as packet traces by a sniffer. (If you use a load balancer and it does not support the same session on two different ports, deploy the FortiMail unit using a single-arm attachment instead. For example, Foundry

IronServer has been known to require single-arm attachment.)

Figure 14:Transparent mode deployment at an ISP or carrier (with HA cluster)

port1

Each network interface in the dual-arm attachment (port2 and port3) is removed from the Layer 2 bridge, and is configured with its own IP address. This reduces the possibility of Ethernet loops and improves compatibility with other filtering devices.

Because port1 cannot be removed from the bridge, and the management IP is accessible from any bridging network interface, port1 is reserved for direct connections from the administrator’s computer. (If the administrator’s computer is not directly connected but is instead part of a management LAN, a route must also be configured for port1.)

Network address translation (NAT) must not occur on any device between the FortiMail unit and SMTP clients, such as subscribers and external MTAs. Antispam scans involving the SMTP client’s IP address, such as sender reputation, carrier endpoint reputation, session rate limits, and mail rate limits, require the ability to correctly identify each source of email by its unique IP address in order to operate correctly. NAT would interfere with this requirement.

Full transparency is configured. Popular email services such as Microsoft Hotmail may rate limit by an SMTP client’s IP address in order to reduce spam. If the FortiMail unit were not transparent to those mail servers, all SMTP connections from your subscribers would appear to come from the FortiMail unit. The result is that external mail servers could throttle the connections of all subscribers behind the FortiMail unit. To prevent this, each individual SMTP client’s IP address should be visible to external MTAs. NAT therefore would also interfere with the requirement of transparency.

Protected domains and access control rules (sometimes called access control lists or ACLs) are not configured. Instead, administrators will configure ACLs on their own internal or external

MTAs.

You could configure ACLs to reject SMTP connections from specific IP addresses if required by your security policy.However, in this example, because no protected domains are configured, ACLs are not required. For connections to unprotected SMTP servers, the implicit ACL permits the connection if no other ACL is configured.

To prevent SMTP clients’ access to open relays, the outgoing proxy will require all connections to be authenticated using the SMTP AUTH command, but will not apply authentication profiles on behalf of the SMTP servers, as no protected domains are configured. It will also not interfere with command pipelining. However, the outgoing proxy will be configured to block TLS connections, whose encryption would prevent the FortiMail unit from being able to scan the connection.

The outgoing proxy is enabled. Unlike other transparent mode deployments, because no protected domains are defined, all connections will be considered to be outgoing — that is, destined for an SMTP server whose IP address is not configured in the SMTP server field in a protected domain. As a result, all connections will be handled by the outgoing proxy. The built-in MTA will never be implicitly used, and the incoming proxy will never be used. If a destination SMTP server is unavailable, the outgoing proxy will refuse the connection. The FortiMail unit will not queue undeliverable mail. Instead, each SMTP client will be responsible for retrying its own delivery attempts.

Unlike other FortiMail deployments, because the ISP or carrier uses a RADIUS server to authenticate and/or track the currently assigned IP addresses of subscribers, the FortiMail unit can combat spam using the carrier endpoint reputation feature.

The FortiMail unit scans SMTP connections originating from both the internal and external network.

• Scanning connections from the external network protects subscribers from viruses and spam.
• Scanning connections from the internal network protects subscribers’ service levels and reduces cost of operation to the ISP or carrier by preventing its public IP addresses from being added to DNS black list (DNSBL) servers.

Why should you scan email originating from the internal network?

Spammers often use a subscriber account to send spam, either by purchasing temporary Internet access or, increasingly, by infecting subscriber’s computers or phones. Infected devices become part of a botnet that can be used to infect more devices, and to send spam.

Because many mail servers use DNSBL to combat spam, if a subscriber’s IP address is added to a DNSBL, it can instantly cause email service interruption. If the subscriber’s IP address is dynamic rather than static, when the spammer’s IP address is reassigned to another subscriber, this can cause problems for an innocent subscriber. Even worse, if many subscribers on your network share a single public IP address, if that single IP address is blacklisted, all of your customers could be impacted.

Protecting the public range of IP addresses from being blacklisted is essential for service providers to be able to guarantee a service level to subscribers.

In addition to jeopardizing customer retention, spam originating from your internal network can also cost money and time. Spam consumes bandwidth and network resources. Tracking which in your block of IPs is currently blacklisted, and paying to have them de-listed, can be a significant recurring cost.

By scanning email destined for the Internet, you can thereby reduce your own costs and maximize customers’ satisfaction with your service levels.

To deploy the FortiMail unit at an ISP or carrier, you must complete the following:

• Configuring the connection with the RADIUS server
• Removing the network interfaces from the bridge
• Configuring the session profiles
• Configuring the IP-based policies
• Configuring the outgoing proxy

Configuring the connection with the RADIUS server

FortiMail units can use your RADIUS accounting records to combat spam and viruses. This reduces spam and viruses originating from your network, and reduces the likelihood that your public IP addresses will be blacklisted.

Unlike MTAs, computers in homes and small offices and mobile devices such as laptops and cellular phones that send email may not have a static IP address. Cellular phones’ IP addresses especially may change very frequently. After a device leaves the network or changes its IP address, its dynamic IP address may be reused by another device. Because of this, a sender reputation score that is directly associated with an SMTP client’s IP address may not function well. A device sending spam could start again with a clean sender reputation score simply by rejoining the network to get another IP address, and an innocent device could be accidentally blacklisted when it receives an IP address that was previously used by a spammer.

To control spam from SMTP clients with dynamic IP addresses, you may be able to use the endpoint reputation score method instead.

The endpoint reputation score method does not directly use the IP address as the SMTP client’s unique identifier. Instead, it uses the subscriber ID, login ID, MSISDN, or other identifier. (An MSISDN is the number associated with a mobile device, such as a SIM card on a cellular phone network.) The IP address is only temporarily associated with this identifier while the device is joined to the network.

When a device joins the network of its service provider, such as a cellular phone carrier or DSL provider, it may use a protocol such as PPPoE or PPPoA which supports authentication. The network access server (NAS) queries the remote authentication dial-in user (RADIUS) server for authentication and access authorization. If successful, the RADIUS server then creates a record which associates the device’s MSISDN, subscriber ID, or other identifier with its current IP address.

The server, next acting as a RADIUS client, sends an accounting request with the mapping to the FortiMail unit. (The FortiMail unit acts as an auxiliary accounting server if the endpoint reputation daemon is enabled.) The FortiMail unit then stores the mappings, and uses them for the endpoint reputation feature.

When the device leaves the network or changes its IP address, the RADIUS server acting as a client requests that the FortiMail unit stop accounting (that is, remove its local record of the IP-to-MSISDN/subscriber ID mapping). The FortiMail unit keeps the reputation score associated with the MSISDN or subscriber ID, which will be re-mapped to the new IP address upon the next time that the mobile device joins the network.

The endpoint reputation feature can be used with traditional email, but it can also be used with MMS text messages.

The multimedia messaging service (MMS) protocol transmits graphics, animations, audio, and video between mobile phones. There are eight interfaces defined for the MMS standard, referred to as MM1 through MM8. MM3 uses SMTP to transmit text messages to and from mobile phones. Because it can be used to transmit content, spammers can also use MMS to send spam.

You can blacklist MSISDNs or subscriber IDs to reduce MMS and email spam.

In addition to manually blacklisting or exempting MSISDNs and subscriber IDs, you can configure automatic blacklisting based upon endpoint reputation scores. If a carrier end point sends email or text messages that the FortiMail unit detects as spam, the endpoint reputation score increases. You can configure session profiles to log or block, for a period of time, email and text messages from carrier end points whose endpoint reputation score exceeds the threshold during the automatic blacklisting window.

To configure your RADIUS server

1. On your RADIUS server, configure the FortiMail unit as an auxiliary RADIUS server, to which it will send copies when its accounting records change.
2. Specify that it should send the Calling-Station-Id and Framed-IP-Address attributes to the FortiMail unit.

The data type of the value of Calling-Station-Id may vary. For 3G subscribers, the RADIUS server typically uses Calling-Station-Id to contain an MSISDN. For ADSL subscribers, the RADIUS server typically uses to contain a login ID, such as an email address.

3. Determine whether your RADIUS server sends the Framed-IP-Address attribute’s value in network order (e.g. 192.168.1.10) or host order (e.g. 10.1.168.192).
4. Verify that routing and firewall policies permit RADIUS accounting records to reach the FortiMail unit.

To enable the FortiMail unit to receive RADIUS records

1. Connect to the CLI.

This feature cannot be configured through the web UI. For instructions on how to connect to the CLI, see “Connecting to the Web UI or CLI” on page 25.

2. Enter the following command to enable the FortiMail unit to receive RADIUS records by starting the endpoint reputation daemon:

config antispam settings

set carrier-endpoint-status enable

end

3. Enter the following command to configure the RADIUS secret: config antispam settings

set carrier-endpoint-acc-secret <secret_str>

end where <secret_str> is the secret configured on the RADIUS server.

4. Enter the following command to configure whether to enable or disable the FortiMail unit to validate RADIUS requests using the RADIUS secret:

config antispam settings

set carrier-endpoint-acc-validate <enable | disable>

end where {enable | disable} indicates your choice.

5. Enter the following command to configure whether or not the FortiMail unit will acknowledge accounting records:

config antispam settings

set carrier-endpoint-acc-response {enable | disable}

end where {enable | disable} indicates your choice.

6. Enter the following command to indicate that the RADIUS server will send the value of the Framed-IP-Address attribute in network order:

config antispam settings

set carrier-endpoint-framed-ip-order {host-order | network-order}

end

where {host-order | network-order} indicates your choice. (Most RADIUS servers use network order.)

Removing the network interfaces from the bridge

In transparent mode, by default, network interfaces are members of a Layer 2 bridge, and have no IP addresses of their own. To connect to the web UI, administrators connect to any network interface that is a member of the bridge, using the management IP.

In this deployment example, only port1 will remain a member of the bridge. Administrators will directly connect their computer to that network interface in order to access the web UI or CLI. The network interfaces through which SMTP traffic passes, port2 and port3, will have their own IP addresses, and will not act as a Layer 2 bridge. As a result, the management IP will not be accessible from port2 and port3. In addition, all administrative access protocols will be disabled on port2 and port3 to prevent unauthorized administrative access attempts from the subscriber and external networks.

Both port2 and port3 will be connected to the same router, and do not require additional static routes.

To remove port2 and port3 from the bridge

1. Go to System > Network > Interface in the advanced mode of the web UI.
2. Double-click on port2 to edit it.
3. Select Do not associate with management IP.

The network interface will be removed from the bridge, and may be configured with its own IP address.

4. In IP/Netmask, type the IP address and netmask of the network interface.
5. Next to Access, disable all administrative access protocols, including HTTPS, SSH, and PING.
6. Next to Administrative status, select Up.
7. Select OK.
8. Repeat this procedure for port3.