Blocking MX query

Mailman List Mirror (Read Only)
1

Hi All,

I've read old archive about blocking SMTP port (TCP port 25). In my current
situation we are mobile operator and use NAT for our subscribers and we
have few spammers, a bit difficult to track it because mostly our
subscribers are prepaid services. If we block TCP port 25, there might be
"good" subscribers will not be able to send email.
We are thinking to block MX queries on our DNS server, so only spammer that
use their own SMTP server will got affected. All DNS queries from our
subscribers already redirected to our DNS cache servers. But seem Bind
don't have feature to block MX query. Any best practice to block MX query?

Regards
Ibrahim

2

Feel free to block port 25. Most if not all mail providers offer
email access on webmail and on an alternate smtp port (587)

If you have NAT - the problem is that if you have spammers abusing
your service (or abusing other services on port 25) providers will end
up blocking your NAT gateway IP and then you have a problem.

You will want to look at walled gardens or similar to block spamming /
infected users.

Please see the maawg best practice for walled gardens and port 25 management.

3

Are you saying that you only allow your subscribers to use your DNS Servers
and block access to all other DNS Server?

4

Not block, but we use DNS transparent proxy mechanism. We need to do this
as our government request all ISP to block porn sites :slight_smile:

Regards
Ibrahim

5

Plenty of ways to work around that actually. This stops random people
from accessing porn sites but you are not likely to see spammers or
bots get deterred too much by this mechanism. Still it does come in
useful as part of a larger walled garden strategy.

6

Hi Suresh,

We create special NAT that all destination use TCP port 25 will be NATed to
one public IP address only. And this public IP address is registered on
most of RBLs. But we are still receiving complaint about spammer from this
public IP address :slight_smile:

Regards
Ibrahim

7

Sure you will get it - but there's also spam through various webmail
services, spam through the outbounds of different ISPs etc that you
won't prevent with your approach.

8

Don't do this. It won't hinder spammers and it'll cause problems for legit
users.

Tony.

9

I've read old archive about blocking SMTP port (TCP port 25). In my current
situation we are mobile operator and use NAT for our subscribers and we
have few spammers, a bit difficult to track it because mostly our
subscribers are prepaid services. If we block TCP port 25, there might be
"good" subscribers will not be able to send email.

Hi,

There are no "good" subscribers trying to send email direct to a
remote port 25 from behind a NAT. The "good" subscribers are either
using your local smart host or they're using TCP port 587 on their
remote mail server. You may safely block outbound TCP with a
destination of port 25 from behind your NAT without harming reasonable
use of your network.

We are thinking to block MX queries on our DNS server, so only spammer that
use their own SMTP server will got affected. All DNS queries from our
subscribers already redirected to our DNS cache servers. But seem Bind
don't have feature to block MX query. Any best practice to block MX query?

Best practice is: don't mess with the DNS.

I don't know if any resolver software supports what you want to do
here. If it does, I don't know what the repercussions are likely to
be. I do know that historically, altering DNS results has proven
problematic. For example, returning an A record for your search server
in place of no-host responses wreaks all manner of havoc.

I also doubt the efficacy of the method. Were this to become common
practice, a spammer could trivially evade it by using his own DNS
software or simply pumping out the address list along with
pre-resolved IP addresses to deliver the mail to. For all I know, they
already do.

Regards,
Bill Herrin

10

You're precisely correct. They've been doing this for many years,
(a) because it's efficient (b) because it evades detection by techniques
that monitor MX query volume (c) because few MX's change often (d) because
it scales beautifully across large botnets.

---rsk

11

Users, like myself, running Linux on home computers and laptops; our local
sendmail-equivalents will in fact attempt direct delivery to remote SMTP MX
servers, and we generally move around enough that setting a smarthost is
semi-impractical, at least on laptops.

I'm a bad subscriber, Bill?

Cheers,
-- jra

12

OpenVPN, et al...

nice for being able to not only relay via the home server, but also
access SMB or even NFS shares and the like, which you'd also not want
reachable from the outside.

13

What sort of an mta do you run on your laptop that doesnt support smtp auth?

14

SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing something,
or are you?

Cheers,
-- jra

15

Have your desktop MTA configured to relay through your smarthost with smtp
auth? Howtos for doing this on sendmail, qmail, postfix etc are over a
decade old now.

16

Would that were true going forward. Consider a world where your
home is chock full of purpose built devices, most likely with an
embedded web browser for configuration where you have a
username/password for each. In the web world this works because
there is a hidden assumption that you can use email for user/password
reset/recovery and that it works well. When your boxen can't do that
because email is blocked, what are you going to do? Reset to factory
defaults? Every time I forget? And please lets not get another useless
lecture on why the unwashed masses should be using password vaults.
They won't.

This hidden assumption of a reliable out of band mechanism for account
recovery is going to come to the fore as v6 rolls out and ip is as gratuitously
added to cheap devices as digital controls are now. Email is the glue that
keeps the web world functioning. Until there's something else, it will
continue to be needed and its role will expand in the home too.

Mike

17

Okay, fair enough. There are no good users *expecting* to send email
direct to a remote port 25 from behind a NAT. There are some good
users who occasionally run slightly sloppy configurations which might
attempt spurious port 25 connections.

Good to block port 25. Not good to knee-jerk ban users whose machines
happen to poke the port once or twice.

Regards,
Bill Herrin

18

From: "William Herrin" <bill@herrin.us>

> I'm a bad subscriber, Bill?

Okay, fair enough. There are no good users *expecting* to send email
direct to a remote port 25 from behind a NAT. There are some good
users who occasionally run slightly sloppy configurations which might
attempt spurious port 25 connections.

I do, in fact, expect that. You're alleging that's a bad practice.

Good to block port 25. Not good to knee-jerk ban users whose machines
happen to poke the port once or twice.

I wasn't even talking about banning or blocking me. I was, as you'll see
in my other response, exercising the end-to-end architecture of the
Internet, as members of this list regularly exhort that I should be able
to.

"This is why we can't have nice things" is not, actually, a sufficiently
useful excuse for me to not agree with that principle.

Cheers,
-- jra

19

Hi Mike,

A. What device do you offer as an example of this? I haven't stumbled
across one yet. Web sites yes. Physical home devices, no.

What I *have* seen is devices that call out to a web server, you make
an account on the remote web server to configure them and then all the
normal rules about accounts on remote web servers apply.

B. Bad hidden assumption. Expect it to fail as more than a few cable
and DSL providers are blocking random port 25 outbound. Besides, some
folks change email accounts like they change underwear. Relying on
that email address still working a year from now is not smart.

Regards,
Bill Herrin

20

What sort of an mta do you run on your laptop that doesnt support smtp
auth?

SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing something,
or are you?

You are. You should be doing SMTP Auth to *your* email server on which
you have an authorized account and then letting it relay your messages
to the world.

Okay, fair enough. There are no good users *expecting* to send email
direct to a remote port 25 from behind a NAT. There are some good
users who occasionally run slightly sloppy configurations which might
attempt spurious port 25 connections.

I do, in fact, expect that. You're alleging that's a bad practice.

Yes, I am. Here's a few others.

http://security.comcast.net/get-help/spam.aspx

"Port 25 Blocking

    Port 25 is conduit on a computer that spammers can take control of
and use to send their spam - often without the user ever knowing
his/her computer has been "hijacked". Comcast works with our customers
to block access to Port 25 and protect their PC.
    Comcast recommends that our customers establish a more secure
email configuration on their PC - Port 587 - We have made it easy by
creating a one-click fix that automatically configures your computers
to this safer PC configuration."

http://qwest.centurylink.com/internethelp/email-troubleshooting-port25.html

"CenturyLink filters port 25 to reduce the spread of email viruses and
spam (unsolicited email). Filtering port 25 has become the industry
standard to reduce the spread of email viruses and spam. These email
viruses allow malicious software to control infected computers. These
viruses direct the infected machines to send email viruses and spam
through port 25. "

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

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

http://tools.ietf.org/html/rfc5068

"A proactive technique used by some providers is to block all use of
   port 25 SMTP for mail that is being sent outbound, or to
   automatically redirect this traffic through a local SMTP proxy,
   except for hosts that are explicitly authorized."

http://www.microsoft.com/security/sir/strategy/default.aspx#!section_2_4

"Block access to port 25 from all hosts on your network other than
those you explicitly authorize to perform SMTP relay functions."

Regards,
Bill Herrin