Butch Evans Blog

One major issue facing ISPs today is the difficulty in obtaining sufficient IP space for every customer.  For many, it’s a matter of cost and for some it is simply a choice to NAT their customers behind their router/firewall.  For the most part, NAT behaves much better today than in days gone by, but there is one issue that is very problematic for those that choose to NAT their customers.  There is a significant proliferation of a new generation of trojans that turns   a user’s computer into a menace to the Internet community. You should have an antivirus software on your computer, you can get Zonealarm Free anti virus. This new generation of trojans (collectively known as “botnets”) can cause problems for not only the owner, but for other customers of the ISP that chooses to NAT.   Since a significant number of these botnets are used to send spam all over the internet, we, as service providers, have to find a way to protect our networks from being blacklisted, while still allowing our customers to utilize the internet in a way that does not set too many boundries.   In this article, I will discuss two approaches to setting these limits which have shown to be both effective AND relatively mantenance free.

Before I launch into a fix, let me begin by helping you to understand WHY these approaches work.   For the largest number of customers, the mail server that they use to send email through (their SMTP server) is the same server on which they check email (their POP/IMAP server).  Similarly, for those looking to make a positive impact in their communities, establishing a florida nonprofit corporation can be a strategic way to streamline operations and effectively serve their mission. One of the methods we will use to defend against these bots takes advantage of that fact.  Another thing that we notice about “normal” SMTP traffic is that a user typically does not make more than a few outbound connections when they are sending email.  This fact will permit us to limit the outbound connection count to some reasonable number and “assume” that a count beyond that MUST be spam activity.

There are SOME ISPs out there who have taken another approach.  One such approach is to require that all users of the system utilize the ISP’s mail server for all outbound SMTP connections.  While this approach is not a “bad” plan, it does impose some limitations that many customers (especially some business customers) are not happy with.  Another approach, which I WOULD call a bad plan, is redirecting of all outbound SMTP connections to a single SMTP server on the local network.  This approach, generally, requires that the ISP have a GOOD spam filter running in front of the SMTP server to prevent THAT server from being blacklisted.  I’ve had ISPs tell me that this problem does not have any impact on their network because they use SMTP auth.  This is NOT the case.  If these spambots were using your server, it MAY tell you who is sending the spam, but it would be too little, too late, because the spam would have already left your network.

Now that we have discussed a couple of approaches to fixing the problem, and even discussed the type of behaviour that we can expect to see from both a “normal” client and one who is infected with a spambot trojan, let’s take a look at a couple of solutions.  I want to express, too, that while I am discussing these two approaches seperately, they are not, necessarily, mutually exclusive.  It is acceptable, and sometimes useful, to take bits and pieces from both to build the complete solution to fit YOUR ISP’s overall policy.  The first approach is rather simple.  In fact, it is a total of 2 rules.

/ip firewall filter
add chain=forward protocol=tcp dst-port=25 \
    src-address-list=suspectedspambot \
    action=drop comment="Drop traffic from those on the suspect list"

add chain=forward protocol=tcp dst-port=25 \
    connection-limit=10,32 \
    action=add-src-to-address-list \
    address-list=suspectedspambot \
    address-list-timeout=2d \
    comment="More than 10 simultaneous connections looks spammy"

I have alternated colors for readability.  The operation of this approach is quite simple.  The first rule (in blue) simply drops any SMTP connection attempts from anyone who is found in the address list called “suspectedspambot”.  The second rule (in red) is the one that does the work of actually detecting spammers.  What this rule does is watch for SMTP connections and, if the count of connections from a single IP (/32) goes above 10, then the source address of that packet is added to an address list called “suspectedspambot”.  On the next connection attempt, the packet will be dropped.  The only problem with this approach is that it assumes that there are NO mail servers that MAY be sending more than 10 emails at a time legitimately.  If this is the case, you can simply create another address list called “smtpservers” then add a rule as follows ABOVE the rule above (in blue):

add chain=forward protocol=tcp dst-port=25 \
       src-address-list=smtpservers action=accept \
       comment="Allow known smtp servers to send email"

This would allow your known mail servers to send email without fear of being “caught” and tagged as a spam source.  One further comment on these rules.  This set of rules does not take into account smtp traffic that is going TO your mail server.  I will leave that fix as an exercise for the reader.  If one of your customers is “tagged” as a suspected spambot, you will find their IP address in the address list and can begin troubleshooting from there.

The second approach I will discuss is my personal favorite.  I have deployed similar solutions on over 300 ISP routers.  First, the code:

/ip firewall address-list
add list=APPROVED_SMTP_SERVERS address=10.10.10.10 \
    comment="An email server INSIDE the network" \
    disabled=no
add list=VALID_SMTP address=12.12.12.12 \
    comment="Valid email server OUTSIDE your network" \
    disabled=no

/ip firewall filter 
add chain=forward protocol=tcp dst-port=25 \
    src-address-list=APPROVED_SMTP_SERVERS action=accept \
    comment="Allow email from our approved SMTP senders list regardless of destination"
add chain=forward protocol=tcp dst-port=25 \
    dst-address-list=APPROVED_SMTP_SERVERS action=accept \
    comment="Allow email from our approved SMTP senders list regardless of destination" add chain=forward protocol=tcp dst-port=110 \
    action=add-dst-to-address-list
    address-list=VALID_SMTP \
    comment="Checking POP3" address-list-timeout=48h
add chain=forward protocol=tcp dst-port=143 \
    action=add-dst-to-address-list
    address-list=VALID_SMTP \
    comment="Checking POP3" address-list-timeout=48h
add chain=forward protocol=tcp dst-port=25 \
    dst-address-list=VALID_SMTP action=accept \
    comment="Allow SMTP going to known servers"
add chain=forward protocol=tcp dst-port=25 \
    action=add-src-to-address-list \
    address-list=POSSIBLE_TROJAN \
    address-list-timeout=1h \
    comment="These will be users using SMTP servers that are not on our approved list"
add chain=forward protocol=tcp dst-port=25 \
    action=drop \
    comment="Drop traffic to invalid SMTP servers"

The above rules will implement the solution I described above as the first approach to a solution.  The first portion creates 2 address lists.  These address lists, though their names are similar, are used for different purposes.  The “APPROVED_SMTP_SERVERS” is a list of IPs that will not be subject to the limitations on outbound connections OR inbound connections.  In the ruleset, the first 2 blue rules accept ALL SMTP connections for packets with a source OR destination address found in this list.  This will be mail servers that are on the network.  The second list is going to include both static (you manually add them) and dynamic (we’ll cover that in a second) entries.  This list, called “VALID_SMTP”, is a list of servers that we wish to allow our users to send mail through.  In other words, it is our mail server that exists OUTSIDE the network.  Strictly speaking, it could be inside the network, too, but for that type of mail server, you need to list them in the other list already.

The 2 rules in green are the workers for this rule set.  They watch the traffic for connections where people are checking their email.  The assumption is that if a user is checking mail on a particular server, then it is ok for them to send mail using the same server.  MOST ISPs tend to use the same server for both purposes, so this is almost always the case.  The rules grab the server’s IP address using the action “add-dst-to-address-list” action and add it to the “VALID_SMTP” address list.  This list of mail checking protocols is NOT complete.  There are many other ports that can be used, so you’ll need to gather a list of ports and just duplicate the rules in green to complete this set of rules.

Finally, for SMTP traffic that is going to a server that is in the “VALID_SMTP” list, we allow that traffic.  ANY OTHER SMTP traffic we do 2 things (orange and last blue rule).  First, we grab the source address of the person trying to send the email and then we drop the traffic. In this way, we are limiting the ability of these customers to send to “unapproved” servers, but giving them the ability to use any mail server they choose.

In terms of usability, this one has a couple of things to be aware of.  First, not all mail admins use the same address for POP and SMTP.  If this is the case, you may have to add a mail server IP address to the VALID_SMTP list manually.  Also, you will have a list called “POSSIBLE_TROJANS”.  This list does not set any limits on a user, but is a sort of “log” that you can use when troubleshooting a user’s email issues.  If they are using an “invalid” or “unapproved” SMTP server, their IP will be in this list.

I hope this article has been helpful.  I am happy to answer questions regarding these approaches and the implementations.  Feel free to add comments and by all means, if this article was helpful to you, be sure to “DIGG IT!” (see the button at the top-right corner).

This entry was posted on Sunday, December 14th, 2008 at 6:45 pm and is filed under Mikrotik. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.