What is a NAT Firewall/Router/Gateway?

What is a NAT Firewall/Router/Gateway?
"NAT" stands for "Network Address Translation", which is used to "map" the private IP addresses of individual computers on a local network, to a single IP address (the "NAT's address") on the Internet. Many providers use this to remap their end-consumer IP addresses to the Internet. Many small networks (SOHO and home private networks) use NAT to remap their home or office machines through a DSL (or DSL/Wireless) modem to the Internet.

A NAT firewall, router or gateway is simply a piece of equipment or software that makes the bridge between your local network and the Internet, and makes all of the connections appear to be from the NAT address, not the local address of the LAN computer.

A PAT firewall, router or gateway is effectively the same thing, except that it maps network ports, in addition to IP addresses. For the purposes of the CBL, a PAT is the same as a NAT.

IMPORTANT NOTE: If you are running your own wireless hub/router, it is often possible for "unwanted guests" to sneak into your network (either accidentally or deliberately) and emit crap through your Internet connection as well as have full access to your private network. It is critical that you take steps to protect your wireless connection. See the section on "I have a Wireless Hub/Router" below.

What's significant about NATs?
Virtually all viruses and spam-sending exploits have their own SMTP clients and attempt to send directly from the infected machine to the intended victim's mail server. They DO NOT go through the infected person's mail server, and obviously DO NOT leave mail server logs of any kind.

This means that the virus will establish a SMTP port 25 connection directly to the victim's mail server.

This means that Anti-spam and anti-virus filters on your mail servers CANNOT stop these things - because the email is not going through your mail servers.

Since all viruses and spam sending exploits forge headers, the only information we know is the originating IP address - which is the NAT, not the infected machine.

This means that if the CBL lists a NAT address, one or more machines on the NAT's local network are infected, and there is NO way for the CBL to identify which one[s] they are. Further, it's difficult even for you to tell which machine is really infected - you normally have to check the firewall logs to see which one of your customers is making suspicious connections directly to the Internet on port 25. Most administrators ignore or do not collect NAT logs.

The listed IP is a NAT. Now what do I do to secure it?
In a nutshell, you must to find a way to prevent these viruses and spam tools managing to connect directly from the infected machine through the NAT.

You MUST do this, because the CBL will NOT make exceptions for a NAT IP under any circumstances. We will give you breathing space to fix the problem, but we will not permanently delist a NAT.

There are a variety of ways to do this.

The simplest and most effective way to stop this is to configure your NAT to prohibit connections to the Internet on port 25 except from real mail servers. Not only does this stop all of these viruses and spams dead in their tracks, the NAT logs will immediately tell you the LAN address of the infected machine.

There's a growing list of examples of how to do this at the end of this page.

This can sometimes cause problems with customers with unusual requirements. But the benefits are huge - large providers report a enormous dropoff in complaints and virus problems once they do this. For example, going from a million virus complaints/problems in a month to less than a dozen.

The Internet provider industry now considers port 25 blocking of customer IP pools to be "Best Current Practice". You block port 25 access by default, and only enable port 25 access on request for static IP addresses that you believe are well run mail servers.

To aid in this, we point you to documentation from the Canadian Federal Anti-Spam Task Force. This contains, in part, a "Best Current Practises" for Network Managers: Companion Document to Recommended Best Practices for Internet Service Providers and Other Network Operators, specifically item 2.

You may also find Full FASTF Report useful (or at least interesting). While this BCP obviously applies to Canada specifically, it is a good model to follow everywhere.

The Messaging Anti-Abuse Working Group (MAAWG) has a document on managing port 25 that is also of interest.

You should have a mail server that customers can use (via "smart host" or "outbound SMTP server" settings in their mail readers) to send email to the Internet. This solves almost all of the issues with port 25 blocks.

For those customers who "roam" (particularly if your NAT is related to wireless connectivity) or use mail service provided by someone else, their mail providers should have a non-port-25 method of sending email - ie: "SMTP SUBMIT" on port 587 using SMTP authentication. Or, if there aren't many of those, you can exempt connection to those mail providers from your outbound port 25 blocking.

The above is described in somewhat more detail in the MAAWG document.

You can also encourage your customers to use their mail provider's webmail interface if they have one.

There are other ways to prevent outbound port 25 connections from viruses and spam, such as "outbound port 25 intercepter/filtering" arrangements and network level anti-virus "appliances". If selected and carefully configured, these can work. But they cannot be as effective as outright port 25 blocking.

Most large providers have come around to understanding that port 25 blocking is the ONLY way to get a handle on compromised computers.

Except in unusual environments (eg: wireless portals), providers report that less than 1% of their customers are affected by implementing port 25 blocking.

You can always arrange to have an outbound mail server for your customers that isn't behind the same NAT - correctly configured customers won't have problems with their email. However, this means that your NAT will continue to be listed, and those customers who don't switch will continue to be blocked. We do not believe this to be the right thing to do, because it continues to subject the rest of the Internet to viruses spewing from your network, and those customers that don't switch may still experience problems with email. However, it is a good way to move to a fully secured NAT and allow you to gradually move customers with unusual requirements.

Once you have implemented port 25 blocks in your NAT, delist your IP.

How do I find the infected machine on a NAT?
This can often be rather difficult, because many NAT gateways provide very little in the way of diagnostic/logging. See How to find BOTs on a LAN

I have a Wireless Hub/Router
If your Hub/Router is acting as your Internet connection (NAT'ing to the Internet), you will need to configure its firewall facilities as in the section "The listed IP is a NAT. Now what do I do?".

In addition, you need to take steps to protect your local network from intrusion. In other words: turn on wireless encryption.

If you don't turn on encryption, getting CBL listed is the least of your worries: ANYONE anyone wardriving by (or indeed a close enough neighbor) is automatically ON YOUR NETWORK and great destruction (eg: loss or theft of your private files, keylogging, backdoors or in some extreme cases, getting arrested) can ensue.

THIS IS NO JOKE! The consequences are very real, and the probability of being taken over is very high.

You really don't want your home network to be OWN3D BY CRIMINALS.

Wireless hubs usually support at least three varieties of encryption: WEP, WPA and WPA/PSK.

WEP is the old encryption methodology. It's relatively awkward to setup, and the encryption is fairly insecure. We advise against it.

WPA is more modern, and has highly secure encryption. "Plain WPA" generally requires that you have a Radius server on your network to perform per-user login authentication - you have to supply a userid and password to connect. This is generally more effort than small networks are willing to go to, but it does have advantages (eg: selectively allow/disallow casual users, logging).

WPA/PSK (WPA with "Public Shared Key") uses the same high security encryption as WPA, but it simpler to setup. You configure in a password into the hub, and anyone attempting to connect to the wireless LAN merely needs to supply that password to get connected. This is the simplest to use for very small home networks where ordinary WPA is overkill.

See your hub's documentation for further details - the CBL team cannot provide assistance on wireless hub configuration.

Nat configuration examples
We would appreciate contributions of simple examples of how to configure NATs/firewalls.
Please make sure you understand what these examples do before implementing anything derived from them.

Linux iptables
# Assume MTA on the gateway box, nothing from the LAN needs to contact
# the world on port 25 directly.

# Log packets trying to cross the interfaces.
iptables -A FORWARD -p tcp --dport 25 -j LOG

# Drop those packets
iptables -A FORWARD -p tcp --dport 25 -j DROP

# Assume MTA is inside the NAT and needs to be able to talk to the
# world, but not receive.

# Fill in this field
IP_OF_MTA_HOST=
iptables -A FORWARD -p tcp -s $IP_OF_MTA_HOST --dport 25 -j ACCEPT

# Log packets trying to cross the interfaces.
iptables -A FORWARD -p tcp --dport 25 -j LOG

# Drop those packets
iptables -A FORWARD -p tcp --dport 25 -j DROP

CISCO
These are generally applicable to most (all?) CISCO firewalls:
First you need to create an access list describing the traffic (X.X.X.X is the IP address of your mail server. Add more lines if you have more than one)


access-list acl_out permit tcp host X.X.X.X any eq 25
access-list acl_out deny tcp any any eq 25
... any other outbound rules you may want go here ...
access-list acl_out permit ip any any

Then you need to apply that access-list to the inside interface (because it is being checked on the inside before it goes out)

access-group acl_out in interface inside

source : http://cbl.abuseat.org/nat.html