Vous êtes sur la page 1sur 3

Spam trojan detection with Mikrotik RouterOS

One major issue facing ISPs today is the difficulty in obtaining sufficient IP space for every
customer. For many, its 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 users computer into a menace to the Internet community. 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). 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 ISPs 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. Ive 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, lets 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 ISPs 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 (well 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 servers 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 youll 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 users 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).

Vous aimerez peut-être aussi