Blocking SPAM behind a NAT server

In this article I will give an example of detecting and blocking the sending of spam messages behind a NAT server.

Once a complaint was sent to one company that spam was being sent from their IP addresses, as it turned out these IP addresses belonged to a NAT server behind which there were hundreds of clients.

I connected to this server and added a rule to iptables that allows client SMTP requests to be written to /var/log/syslog:

iptables -t filter -A FORWARD -s -m tcp -p tcp --dport 25 -j LOG --log-prefix "iptables: "

Do not forget to delete it later so as not to fill up the entire disk space with logs:

iptables -t filter -D FORWARD -s -m tcp -p tcp --dport 25 -j LOG --log-prefix "iptables: "

You can set a limit for requests that will be recorded:

iptables -t filter -A FORWARD -s -m tcp -p tcp --dport 25 -m limit --limit 5/minute -j LOG --log-prefix "iptables: "

You can also configure iptables logging to a separate file:

nano /etc/rsyslog.d/10-iptables.conf
:msg, contains, "iptables: " -/var/log/iptables.log
& ~

And the rotation of logs, for example, so that they are not stored for more than 7 days:

nano /etc/logrotate.d/iptables
        rotate 7
                /etc/init.d/rsyslog restart > /dev/null

After a while, I analyzed the logs and noticed that some clients simply send emails through their mail servers, and some send spam, most often it is viruses that send spam.
Therefore, it is impossible to block all smtp traffic on port 25, since there are about 10,000 clients behind a NAT server and the probability of blocking mail to ordinary clients is 100%.
I will just give an example of a rule that completely blocks traffic to SMTP port 25 and will not help in my case:

iptables -A FORWARD -s -p tcp --dport 25 -j DROP

Unless you can block unnecessary smtp traffic from viruses to the gray client network, but this will not save you from sending spam to the Internet (in this way, you can block other ports to reduce the likelihood of viruses spreading on the local network through vulnerabilities):

iptables -A FORWARD -d -p tcp --dport 25 -m comment --comment SMTP_Blocked_to_local -j DROP

Each IP address that constantly flooded with requests to SMTP port 25, I blocked manually, I will give an example:

iptables -A FORWARD -s -p tcp --dport 25 -m comment --comment "SPAM_09_01_2021" -j DROP

Also, a mandatory anti-spam solution will be to create reverse PTR records on the DNS server for all IP addresses that are used for NAT. So that mail servers can verify the sender’s domain name with the domain of the IP address from which the letter came, if the domain name does not match, then the mail server may not accept such a letter, but most often it will accept and sometimes place it in the spam folder (this depends on the number of emails and the rating spam level), so it is also necessary to calculate and block spammers on the NAT server.

Let’s see the reverse PTR record for the IP address (example of commands for Linux / MacOS):


In my case, there were no PTR records, so I wrote in support of LIR, which once sold AS with a block of white IPv4 addresses, so that it would indicate to RIPE two of my DNS servers, which will contain reverse records for all /24 networks. There must be at least two DNS servers and reverse PTR records must already be configured before specifying these DNS servers in RIPE.

I have run a couple of DNS servers, recently I prefer bind9.

Example (let’s say the IP addresses of the NAT server

nano /etc/bind/
$TTL 3600
@          IN SOA (
              2020112511        ; Serial
              21600             ; refresh
              3600              ; retry
              3600000           ; expire
              86400 )           ; minimum
        IN  NS
        IN  NS
100 IN PTR
101 IN PTR
102 IN PTR
103 IN PTR
nano /etc/bind/named.conf
zone "" {
type master;
file "/etc/bind/";
/etc/init.d/bind9 restart

There are also many systems and scripts for monitoring traffic and security, which will allow you to create top IP addresses for SMTP traffic and block it. However, I do not recommend running those that use tcpdump on servers with very high traffic.

See also my articles:

Leave a comment

Leave a Reply