Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Spamrl.com RBL problem
1,404 views
Skip to first unread message
li...@lazygranch.com
Jul 2, 2016, 6:51:46 PM7/2/16
to
I will start this over to get rid of the HTML mail crap. This is the bounce reply with some sanitizing to keep this message off of the Google bot:
------------------------
This is the mail system at host www.mydomain.com
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<in...@anotherdomain.com>: host smx1.web-hosting.com[209.188.21.38] said: 550 The
sending IP (my dotted quad) is listed on https://spamrl.com as a source of
dictionary attacks. (in reply to end of DATA command)
-----------------
Is the "in reply to end of DATA command" significant?
------------------------
This is the mail system at host www.mydomain.com
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<in...@anotherdomain.com>: host smx1.web-hosting.com[209.188.21.38] said: 550 The
sending IP (my dotted quad) is listed on https://spamrl.com as a source of
dictionary attacks. (in reply to end of DATA command)
-----------------
Is the "in reply to end of DATA command" significant?
Matthew McGehrin
Jul 2, 2016, 10:23:48 PM7/2/16
to
Hello.
I would check your local system to see if you have any rogue perl
processes running. These are generally the cause of being blacklisted
for a dictionary attack, which implies that a script is running on your
local server.
Generally, you can spot them by the amount of CPU time, and they try to
mask the process id.
The end of DATA command is just the sequence at which it was denied.
It's standard.
-- Matthew
I would check your local system to see if you have any rogue perl
processes running. These are generally the cause of being blacklisted
for a dictionary attack, which implies that a script is running on your
local server.
Generally, you can spot them by the amount of CPU time, and they try to
mask the process id.
The end of DATA command is just the sequence at which it was denied.
It's standard.
-- Matthew
li...@lazygranch.com
Jul 3, 2016, 12:37:08 AM7/3/16
to
This is probably more of a freebsd question, but it seems to me that Postfix should be hogging (bound) to the mail ports, so if something is sending email, it has to be using Postfix.
I suppose modifying IPFW to log all mail port activity is also a good idea.
Wouldn't a script need to be in the rc.d to get fired up when I boot?
Original Message
From: Matthew McGehrin
Sent: Saturday, July 2, 2016 7:24 PM
To: Postfix users
Subject: Re: Spamrl.com RBL problem
I suppose modifying IPFW to log all mail port activity is also a good idea.
Wouldn't a script need to be in the rc.d to get fired up when I boot?
Original Message
From: Matthew McGehrin
Sent: Saturday, July 2, 2016 7:24 PM
To: Postfix users
Subject: Re: Spamrl.com RBL problem
Stefan Caunter
Jul 3, 2016, 1:07:14 AM7/3/16
to
On FreeBSD you still need to install postfix from a port. The port install will allow you to switch the MTA preference but you still need to configure an rc entry. Once that is done and postfix starts it will grab the relevant TCP/IP ports. Note that scripts can generally access localhost port 25; any MTA will relay faithfully for a local client.
Matthew McGehrin
Jul 3, 2016, 7:03:04 AM7/3/16
to
Hello.
Your assuming that port 25 needs to be open on the local side to send
mail. this is not the case. There are two possibilities here.
1. A dirty IP was assigned to your server, and that the previous owner
had a spam issue.
2. It's a php exploit, that spawns a perl script to send outbound mail.
You don't need port 25 open to sendmail, that's only for receiving mail.
As long as you can connect outbound on port 25, mail can sent. Most
RBL's are dumb, and they don't record the port, only the IP of the
sending host. So, it's quite possible to have SMTP listening on port 25,
for receiving mail, and also have an exploit running, sending mail.
I work in the hosting industry and I have seen many cases where
customers have an exploited wordpress that is being used to spam
e-mails, while also having a 'valid' smtp server running.
Your assuming that port 25 needs to be open on the local side to send
mail. this is not the case. There are two possibilities here.
1. A dirty IP was assigned to your server, and that the previous owner
had a spam issue.
2. It's a php exploit, that spawns a perl script to send outbound mail.
You don't need port 25 open to sendmail, that's only for receiving mail.
As long as you can connect outbound on port 25, mail can sent. Most
RBL's are dumb, and they don't record the port, only the IP of the
sending host. So, it's quite possible to have SMTP listening on port 25,
for receiving mail, and also have an exploit running, sending mail.
I work in the hosting industry and I have seen many cases where
customers have an exploited wordpress that is being used to spam
e-mails, while also having a 'valid' smtp server running.
Ralf Hildebrandt
Jul 3, 2016, 1:00:53 PM7/3/16
to
> <in...@anotherdomain.com>: host smx1.web-hosting.com[209.188.21.38] said: 550 The
> sending IP (my dotted quad) is listed on https://spamrl.com as a source of
> dictionary attacks. (in reply to end of DATA command)
That would mean that something tried logins against a POP/IMAP/SMTP
> sending IP (my dotted quad) is listed on https://spamrl.com as a source of
> dictionary attacks. (in reply to end of DATA command)
server -- not necessarily your MTA itself, but some piece of software
(it could be a root shell exploit or some abusable piece of Word Press
to give you a few ideas!)
> Is the "in reply to end of DATA command" significant?
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Ralf Hildebrandt
Jul 3, 2016, 1:01:27 PM7/3/16
to
* Matthew McGehrin <drinkin...@gmail.com>:
statistical reports)
> Hello.
>
> I would check your local system to see if you have any rogue perl
> processes running. These are generally the cause of being blacklisted
> for a dictionary attack, which implies that a script is running on your
> local server.
>
> Generally, you can spot them by the amount of CPU time, and they try to
> mask the process id.
One could also sniff the traffic (using "iptraf" which generates nice
>
> I would check your local system to see if you have any rogue perl
> processes running. These are generally the cause of being blacklisted
> for a dictionary attack, which implies that a script is running on your
> local server.
>
> Generally, you can spot them by the amount of CPU time, and they try to
> mask the process id.
statistical reports)
Ralf Hildebrandt
Jul 3, 2016, 1:02:52 PM7/3/16
to
* li...@lazygranch.com <li...@lazygranch.com>:
> This is probably more of a freebsd question, but it seems to me that Postfix should be hogging (bound) to the mail ports, so if something is sending email, it has to be using Postfix.
No. Sending can be done by other processes as well, since it doesn't
require binding to port 25, but connecting to port 25.
> I suppose modifying IPFW to log all mail port activity is also a good idea.
Yes. Ports 25, 143, 110 and the encyrpted equivalents.
> This is probably more of a freebsd question, but it seems to me that Postfix should be hogging (bound) to the mail ports, so if something is sending email, it has to be using Postfix.
require binding to port 25, but connecting to port 25.
> I suppose modifying IPFW to log all mail port activity is also a good idea.
Ralf Hildebrandt
Jul 3, 2016, 1:03:41 PM7/3/16
to
> Your assuming that port 25 needs to be open on the local side to send
> mail. this is not the case. There are two possibilities here.
>
> 1. A dirty IP was assigned to your server, and that the previous owner
> had a spam issue.
Give the shortages of ipv4 addresses, this is often the case
> mail. this is not the case. There are two possibilities here.
>
> 1. A dirty IP was assigned to your server, and that the previous owner
> had a spam issue.
li...@lazygranch.com
Jul 3, 2016, 3:30:57 PM7/3/16
to
The only issue against the "dirty" IP address is for a little over a year, I had no problems with this RBL. My problem now is I keep clearing the block, and it gets reset.
This particular RBL has a few complaints about false positives. In fact, for dictionary searches. However the most recent being two years ago.
If I really had a problem with the server, you would think a few other RBLs would be tripped.
Regarding my web server, I run Nginx. I don't have PHP. I have no CMS. In fact, I don't even allow "put" in the list of commands. I just serve static pages.
I read the error log from Nginx. I investigate any hacking activity. What I see is minor league stuff such as attempts to log into WordPress or php admin, neither of which I have. Further, I look up the IP of the hacker. If from a VPS, data center, or anything that isn't an ISP, I block the entire address space associated with the hacker. If the IP goes to an ISP, I handle it on a case by case basis. I don't block edu, though I have in the case of UC Berkeley asked their researches not to fuzz my server.
Original Message
From: Ralf Hildebrandt
Sent: Sunday, July 3, 2016 10:03 AM
To: postfi...@postfix.org
This particular RBL has a few complaints about false positives. In fact, for dictionary searches. However the most recent being two years ago.
If I really had a problem with the server, you would think a few other RBLs would be tripped.
Regarding my web server, I run Nginx. I don't have PHP. I have no CMS. In fact, I don't even allow "put" in the list of commands. I just serve static pages.
I read the error log from Nginx. I investigate any hacking activity. What I see is minor league stuff such as attempts to log into WordPress or php admin, neither of which I have. Further, I look up the IP of the hacker. If from a VPS, data center, or anything that isn't an ISP, I block the entire address space associated with the hacker. If the IP goes to an ISP, I handle it on a case by case basis. I don't block edu, though I have in the case of UC Berkeley asked their researches not to fuzz my server.
Original Message
From: Ralf Hildebrandt
Sent: Sunday, July 3, 2016 10:03 AM
To: postfi...@postfix.org
Subject: Re: Spamrl.com RBL problem
Bill Cole
Jul 4, 2016, 5:22:14 PM7/4/16
to
On 3 Jul 2016, at 0:36, li...@lazygranch.com wrote:
> This is probably more of a freebsd question, but it seems to me that
> Postfix should be hogging (bound) to the mail ports, so if something
> is sending email, it has to be using Postfix.
That's not how TCP/IP or Postfix works. Postfix binds listeners to the
> This is probably more of a freebsd question, but it seems to me that
> Postfix should be hogging (bound) to the mail ports, so if something
> is sending email, it has to be using Postfix.
*LOCAL* IP+port pairs that you tell it to listen on. Typically this
includes at least port 25 on all local IP's and possibly port 587 on all
local IPs. See your own master.cf for specifics...
This does not prevent other programs from using ephemerally-allocated
*LOCAL* ports (typically <48k) to open connections connect to port 25 or
587 on REMOTE addresses where other people run their MTAs on their
machines. And of course Postfix has nothing to do with the various ports
POP and IMAP servers can be listening on, which usually use a common
authentication mechanism to the MTAs on the same hosts.
> I suppose modifying IPFW to log all mail port activity is also a
> good idea.
Postfix logs is a... um... painful task.
One approach that is useful and much less annoying to use is to make
your mail services use only a non-default IP address, so that most forms
of system compromise which result in something running that is not under
your control and tries to engage in mail naughtiness can be blocked by
ipfw (or on Linux, iptables) rules that prohibit outbound port
25/587/465/110/143/993/995 on the IP address that a program would use by
default if it does not specify one when opening a socket. This can be a
bit tricky to set up if your system is directly connected to the
Internet with only one public IP available, but it's still possible. The
more subtle initial configuration buys you the ability to block bad
traffic rather than just logging it and no need to use the Postfix logs
to sift out the legitimate outbound mail traffic from the illegitimate.
Another useful tool on FreeBSD is the "jail" mechanism. On FreeBSD I
only run Postfix in jails that include at most only a few intimately
related services (e.g. Dovecot, Unbound) precisely because that allows
me to prohibit all traffic to ports 25 and 587 from other jails running
riskier things (e.g. webservers) except to the jailed Postfix.
> Wouldn't a script need to be in the rc.d to get fired up when I boot?
cracks which don't bother trying to make themselves permanent, they just
hide themselves very well by running under innocent names and unlinking
their visible locations in the filesystem. There are also FreeBSD
rootkits which are very hard to find short of booting from immutable
media after reflashing the BIOS.
But don't go that far quite yet... There's another possible (and more
likely) explanation.
One thing that can make Postfix act like a "dictionary attack" bot is
the non-default abusive misfeature "reject_unverified_sender" which
implements what is sometimes called "SMTP Callback," verifying each
sender by running a fake SMTP transaction that looks like a bounce
through the point of a response to RCPT and then quitting. This is done
synchronously during each SMTP session that offers an unknown
RFC5321.MailFrom address. This technique sounds like a great idea until
you consider the secondary consequences and responses outside of your
own system. If you do SMTP callback, you make your system a public
nuisance that actual spammers can (and eventually will) use as a
dictionary attack proxy for discovering deliverable addresses. Sender
address verification by SMTP callback is an example of a spam-fighting
tactic that looked and worked great when it was first conceived, as long
as one didn't think about the scaling effects, external reactions, and
vulnerabilities to abuse. Postfix's implementation is arguably the least
obnoxious in widespread use, but it remains an intrinsically problematic
tactic.
If you're using sender address verification you should stop,
immediately. There are spamtrap tactics in fairly widespread use for
detecting spam sources which cannot distinguish between spammer systems
and those doing sender address verification and whose users do not see
any reason to make such a distinction. There are DNSBLs which are fed by
such trap mechanisms. There are useful *non-abusive* anti-spam tactics
which break even the least-bad implementations of sender address
verification, causing them to see valid addresses as invalid. The
beliefs that it is possible to make a 99.99% accurate determination of
whether a sender address is deliverable in real time between receiving a
MAIL FROM command and responding to DATA, that trying to do so will not
reduce objective performance and add to resource demands, and that it
won't cause the blockage of legitimate messages are all simply
incorrect. It can take years to notice any problems or to be noticed as
a source of problems, but once you are listed by a public DNSBL as a
result of doing SMTP callbacks, you'll never be able to do them safely
again and you will lose legitimate inbound mail as a result before you
notice problems with outbound deliverability.
li...@lazygranch.com
Jul 4, 2016, 9:32:27 PM7/4/16
to
"reject_unverified_sender" not used.
The VPS is 13 months old and I never ran rkhunter on it. Very lame in my part. However, no rootkit found. It did find some symbolic links that went nowhere regarding perl, which I deleted once I verified the problem was common. I also ran rkhunter on all linux boxes on hand.
Original Message
From: Bill Cole
Sent: Monday, July 4, 2016 2:22 PM
To: Postfix users
Reply To: Postfix users
Subject: Re: Spamrl.com RBL problem
0 new messages