FAIL (the browser should render some flash content, not this).

Securing NAT

The credit for most of the information below belongs to the CBL.  Please see http://cbl.abuseat.org/nat.html for their complete document.

 

What is a NAT gateway?

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.

 

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 (or typically ours).

Since all viruses and spam sending exploits forge headers, the only information that becomes known from the Internet is the originating IP address - which is the public IP address of your NAT gateway, not the infected machine.

 

What do I do to secure it?

In a nutshell, you must to find a way to prevent these viruses and spam tools from managing to connect directly from the infected machine through your NAT gateway.

You MUST do this, because most DNSBLs (like the CBL) will NOT make exceptions for a NAT IP under any circumstances.

There are a variety of ways to do this.

The simplest and most effective way to stop this is to configure your NAT gateway to prohibit connections to the Internet on port 25 except from real mail servers. See also: How to avoid DNSBL listings. Not only does this stop all of these viruses and spam 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.

 

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

Please see your hub's documentation for further details or contact your IT support for assistance.

 

Nat configuration examples

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

We would appreciate contributions of simple examples of how to configure NATs/firewalls.

We Answer Your Questions: FAQ

Q: What is the maximum e-mail attachment size?

A: The ETRN.com e-mail servers do not limit the size of individual e-mail attachments. The ETRN.com e-mail servers do impose a 400 MB maximum total message size limit. Individual customers can choose a smaller message size limit. We can also customize the handling of "over-sized" e-mails. Please contact us to discuss your specific needs. A couple of important facts:

1. Attachments are typically encoded in what is called Base64[1]. As a result, the actual length of MIME-compliant Base64-encoded binary data is usually about 137% of the original file size.

2. E-mails often contain both plain text and HTML components. This also increases the overall size of the e-mail.