Section 6: Internet Provider Anti-Spam Network Configuration
by Frank Durda IV 


[Copyright 2002,2003 Frank Durda IV, All Rights Reserved.
Mirroring of any material on this site in any form is expressly prohibited.
The official web site for this material is:  http://nemesis.lonestar.org
Contact this address for use clearances: clearance at nemesis.lonestar.org
Comments and queries to this address: web_reference at nemesis.lonestar.org]
This is a living document, and it is updated from time to time. 
This document was last updated December 17th, 2003.


To protect your network from spammers and hackers, and to make your network an undesirable place for spammers to operate from, certain filter rules can be installed in the routers of your network. For the non-spammer, these filters are typically invisible and do not detract from what the customer can do on the Internet.

There are a few situations where customers with special requirements or personal desires will run into some of these filters. Because of this, the filters demonstrated below are separated by function so that the filters that won't cause any fuss can be implemented promptly and the others can be applied on as much of your network as your customers demands and your company's stated Terms of Service allow.

These recommendations will work for the Internet Provider that has one router or a thousand routers, situated in one or a thousand locations. Just apply the same filtering rules shown to each router that controls access to the devices, access points and servers described below no matter where they occur on the entire network.

To demonstrate how to control this abusive activity using your network, a Hypothetical Internet Providers Network is shown below. It shows a subset of network structural components that almost always exist in the typical Internet Providers network. Those components that do not exist in your environment do not prevent you from utilizing all of these filters. Simply ignore the components and filters that are not applicable.

One of the most important network configuration requirements is that all of the mail servers exist in netblocks separate from netblocks used by customer connections and equipment. For larger Internet Providers, this is likely already the case, but in smaller Internet Providers that exist within a single netblock allocation, the IP addresses assigned to customer modems, customer dedicated lines, and customer web servers may all be intertwined with those addresses used for the Internet Providers mail servers. When mail servers are grouped or isolated, it will be easier to configure the filters in your routers.

The filter rules that are described here assume that your network is (or can be) divided into five categories:

  1. Upstream or off-network peering connections (rest of the Internet)
  2. Netblocks assigned exclusively to the Internet Providers mail servers
  3. Netblocks assigned exclusively to non-dedicated customer access (modems, dynamic DSL or cable IP assignments, etc)
  4. Netblocks assigned exclusively to static IP customer access (dedicated modems, static DSL or cable IP assignments, etc)
  5. Netblocks assigned to non-customer devices (web and other non-mail servers)
Each division may have one or more netblocks and may be served by one or more routers.


Hypothetical Network Using a Single Router

In this hypothetical network, the following netblocks exist:

Netblock Function of equipment in this Netblock
16.2.4.8/30 A connectivity provider interface (our side is .10).
192.0.1.128/30 Another connectivity provider interface (our side is .130.
10.0.0.0/24 The Core Network and other non-mail company servers.
10.0.1.0/24 The Internet Providers Servers
10.0.1.0/28 The Internet Providers Mail Servers (first 16 addresses of above).
10.0.3.0/24 Ethernet Interfaces of modem equipment.
10.0.4.0/21 Customer Static/Fixed IP Dedicated/Leased Line equipment (DSL, T1, Cable modem).
10.0.8.0/21 IP Pools for modems, Customer Dynamic IP equipment (DHCP, PPPOA, PPPOE) including non-Static DSL or Cable modems.
192.168.6.0/22 More modems and similar customer-accessible equipment.

The following drawing shows how these networks are connected to the core router or routers in this example network: 


		To		To		To
	    Upstream A	    Upstream B	      Modems
		|10.2.4.9	|192.0.1.129	|10.0.0.6
		|		|		|
		|		|		|
		|16.2.4.10	|192.0.1.130	|10.0.0.5
		|HSSI0/0/0	|HSSI0/0/1	|HSSI0/1/0
	+-----------------------------------------------+
	|						|
	|						|
	|		Core Router(s)			|
	|						|
	|						|
	+-----------------------------------------------+
		|FastE1/0/0			|FastE1/1/0
		|10.0.1.254			|10.0.0.33
		|				|
		|				|
		|				|10.0.0.34
		To		 		To
	       ISP 	                   Customer Eqpt
	     Servers                       DSL, T1, Cable

The device names shown in this example network were selected arbitrarily.

A word about modems and how Internet Providers connect to them:

Internet Providers use a variety of methods to provide modem services. Internet Providers may possess no modems at all (using virtual POP services), may operate their own modems housed in one or more facilities, or may use a combination of Provider-owned modems, and virtual POP services. In this example, all types of modems that connect back to the Internet Provider would be connected to the single interface shown (HSSI0/1/), but multiple interfaces (perhaps on multiple routers) are likely to be needed in real-life configurations.

Regardless of whether it is multiple interfaces to serve modem equipment or multiple interfaces for uplinks or connectivity peering, or multiple interfaces to serve some other listed category of equipment, the same access lists containing the filtering rules shown below would be applied to each router interface that serves that stated type of equipment.


The Hypothetical Router Interfaces

The following Cisco IOS router commands are used in this hypothetical network to establish the various interfaces, define what they are for, and bind the various IP addresses and netblocks to the appropriate interfaces. These commands also reference all of the filters applied to the interfaces. (The filters functions are described in a moment.)

Commands shown are grouped together by function, not in the order that they would appear in the Cisco IOS "show run" or "show config" display. 

interface HSSI0/0/0
  description Link to Upstream Provider A
  ip address 16.2.4.10 255.255.255.252
  ip access-group from-internet in


interface HSSI0/0/1
  description Link to Upstream Provider B
  ip address 192.0.1.130 255.255.255.252


interface HSSI0/1/0
  description Link to modem farm
  ip address 10.0.0.5 255.255.255.252
  ip access-group to-general-customer-equipment out
  ip access-group from-general-customer-equipment in

ip route 10.0.3.0 255.255.255.0 10.0.0.6
ip route 10.0.8.0 255.255.248.0 10.0.0.6
ip route 192.168.6.0 255.255.252.0 10.0.0.6


interface FastEthernet 1/0/0
  description Link to ISP Servers
  ip address 10.0.1.254 255.255.255.0


interface FastEthernet 1/1/0
  description Link to T1/DSL routers
  ip address 10.0.0.33 255.255.255.224
  ip access-group from-general-customer-equipment in

ip route 10.0.4.0 255.255.248/0 10.0.0.34

access-list compiled


The Hypothetical Router Filters

The following Cisco IOS access lists create filters that restrict traffic headed in certain directions to certain ports. Each filter is described below.

I. Block spammers and hackers from exploiting customer equipment connected to dial-up, DHCP, PPP, PPPOA, and PPPOE pools.

Function:
This filter prevents probes and connections from any location from going towards certain potentially-vulnerable network ports on ranges of IP addresses used by dial-up, DHCP, PPP, PPPOA, PPPOE and other applicable customer equipment.

Although this filter should be applied to all dynamic customer connections (where their IP address usually changes each time they reconnect), it should also be applied in cases where the Terms of Service prohibits some or all customers from operating servers. The filter blocks the ports used most frequently for server activity, and it also protects ports that are frequently used to gain unauthorized control of computers that use the Windows operating system. At the same time, the filter does not impede the ability of the authorized customers using these IP addresses to access servers located within or outside the filtered netblocks, including the Internet Providers' own servers and servers located out on the Internet.

Benefit:
By blocking traffic for certain ports headed towards customer equipment, it eliminates any concern about whether these customer systems are secured against the most common types of attacks. The filter prevents any vulnerable customer systems from being used to relay spam, and prevents any unsecured proxy software on customer computers that could be exploited to gain the credentials of your customers on your network. This prevents proxies on customer computers with default settings from launching further attacks from your network.

Technique:
This filter rule blocks any traffic headed towards certain ports on dial-up, DHCP, PPP, PPP0A, PPPOE pools (and other customer-accessible equipment as appropriate in your situation). These ports are the standard listening ports for common server software, such as HTTP/WWW, POP2, POP3, HTTPS, and SMTP. It also blocks and the ports used for back-door access to Windows operating systems, including 139, 194, 1080, 8000 and 8080.

This filter requires no changes on the part of servers or customer equipment, although any customers who were attempting to operate servers in these blocks on standard ports will now not be able to do so.

Whether the filter should be applied to DSL, cable modem and other leased line customers depends on the Terms of Service that you have established for these customers. It may be that a smaller set of filter rules should be applied to such lines, allowing these customers to run certain types of servers (such as HTTP/HTTPS), but still preventing access to the other potentially vulnerable ports on customer computers. 

ip access-list extended to-general-customer-equipment
  deny tcp any 10.0.8.0 0.0.7.255 eq smtp
  deny tcp any 192.168.6.0 0.0.3.255 eq smtp
  deny tcp any 10.0.8.0 0.0.7.255 eq www
  deny tcp any 192.168.6.0 0.0.3.255 eq www
  deny tcp any 10.0.8.0 0.0.7.255 eq pop2
  deny tcp any 192.168.6.0 0.0.3.255 eq pop2
  deny tcp any 10.0.8.0 0.0.7.255 eq pop3
  deny tcp any 192.168.6.0 0.0.3.255 eq pop3
  deny tcp any 10.0.8.0 0.0.7.255 eq 139
  deny tcp any 192.168.6.0 0.0.3.255 eq 139
  deny tcp any 10.0.8.0 0.0.7.255 eq 194
  deny tcp any 192.168.6.0 0.0.3.255 eq 194
  deny tcp any 10.0.8.0 0.0.7.255 eq 443
  deny tcp any 192.168.6.0 0.0.3.255 eq 443
  deny tcp any 10.0.8.0 0.0.7.255 eq 1080
  deny tcp any 192.168.6.0 0.0.3.255 eq 1080
  deny tcp any 10.0.8.0 0.0.7.255 eq 8000
  deny tcp any 192.168.6.0 0.0.3.255 eq 8000
  deny tcp any 10.0.8.0 0.0.7.255 eq 8080
  deny tcp any 192.168.6.0 0.0.3.255 eq 8080
  permit ip any any

Note: Because new security flaws are found almost daily in the Windows Operating System, additional ports may need to be blocked to protect customer computers that are running these insecure operating systems.

For Internet Providers that use virtual POP (also known as "rent-a-POP") services where the IP traffic flows directly to the Internet (instead of passing through the Internet Providers network first), the Internet Provider should require that the above filter (or its functional equivalent) be installed in front of the virtual POPs modems to provide similar protection. In some virtual POP arrangements, these filters can be activated by remote control via instructions returned in RADIUS authentication records. Check with your virtual POP provider for what options they offer.)


II. Force customers to send all outgoing mail to local mail servers first.

Function:
This filter forces mail sent by customers to be sent via the Internet Providers mail servers instead of bypassing them.

Benefit:
By forcing all mail from customer equipment to be routed through local mail servers, it deters spammers who hope to directly connect to off-shore relays or direct to the spam destinations. Any spam sent will be immediately traceable back to the originating Internet Provider. It also gives the Internet Provider the opportunity to perform spam filtering and detection on mail that would normally bypass such checks.

Technique:
This rule is implemented by allowing SMTP traffic from dial-up, DHCP, PPP, PPPOA, PPPOE pools (and other customer-accessible equipment as appropriate in your situation) to be sent only to designated local mail servers. Those servers will then be responsible for relaying and delivering mail to the appropriate destination.

All equipment residing in netblocks that use this filter must be configured to send mail to a designated SMTP mail server within the network that the filter allows access to. 

ip access-list extended from-general-customer-equipment
  permit tcp 10.0.8.0 0.0.7.255 10.0.1.0 0.0.0.15 eq smtp
  permit tcp 192.168.6.0 0.0.3.255 10.0.1.0 0.0.0.15 eq smtp
  deny tcp 10.0.8.0 0.0.7.255 any eq smtp
  deny tcp 192.168.6.0 0.0.3.255 any eq smtp
  permit ip any any

For Internet Providers that use virtual POPs, this rule can only be used on modems and equipment that are directly-connected to the Internet Providers network. (Customers on virtual POPs MUST have to check their mail on the Internet Providers servers via POP3 or IMAP protocols before they are allowed to relay mail through the Internet Providers mail servers. NEVER assume that a SMTP connection originating from a virtual POP is always coming from a computer operated by one of your customers.)


III. Force mail from the Internet to go to designated servers first.

Function:
This filter forces mail sent from other Internet locations to be received only by designated mail servers operated by the Internet Provider, who will then apply strict spam checking and then forward approved mail to the desired destination within the Providers local network.

Benefit:
By forcing all mail from other Internet locations to be sent only to designed servers, the Internet Provider can apply spam filtering rules and source identification checks on those servers to detect and discard spam and other mail abuse.

This is a critical point: The server or servers that receive mail from the outside should apply stricter checking on that mail than the checks that are applied to mail received from local customers.

The reason customer mail typically has to be checked less-aggressively is that most customer mail software fails to send mail via SMTP that complies with rules mandated by RFC 2821 and other standards, although applying such checks to mail received from non-customer locations blocks large amounts of spam. (More details on filtering mail in the mail servers based on RFC 2821 is covered in another section.)

For larger ISPs, deploying two sets of mail servers with one set accepting SMTP traffic from non-customer locations and denies any third-party relaying (the MX servers), and a set of servers (the customer-accessible SMTP servers) that accept SMTP traffic from your customers and allows relaying only after the sender has identified themselves greatly simplifies mail server configuration. (Some mail server software has enough flexibility for a single machine to perform both functions.)

Technique:
This filter rule allows mail from Internet sources to be sent only to designated MX servers in your network. Any mail for customer mail servers must be forwarded from these MX servers, or the customer equipment must be included in the ranges of network addresses that outside mail can be sent to. 
ip access-list extended from-internet
  permit tcp any 10.0.1.0 0.0.0.15 eq smtp
  deny tcp any any eq smtp
  permit ip any any

For those Internet Providers using virtual POPs, the MX mail server (for mail from the Internet) and the SMTP mail servers (for mail from your customers) should both be in the range of IP addresses that this filter controls. Your customers will use the SMTP server where they have to authenticate to accept their mail. Other parties must send mail to the MX server and be subject to the strict checking that those servers should be performing.


Acknowledgments

The Cisco IOS coding samples shown in this section were generated by the Internet America Networking Group. Their assistance was greatly appreciated.


Related Topics

Section 7: Internet Provider Anti-Spam Mail Server Configuration (HTML) [NEXT] (NOT YET AVAILABLE)

The Anti-Spam Index (HTML) 


[Copyright 2002,2003 Frank Durda IV, All Rights Reserved.
Mirroring of any material on this site in any form is expressly prohibited.
The official web site for this material is:  http://nemesis.lonestar.org
Contact this address for use clearances: clearance at nemesis.lonestar.org
Comments and queries to this address: web_reference at nemesis.lonestar.org]

Visit the nemesis.lonestar.org home page and index

Valid HTML 4.01!