Re: Spamrl.com RBL problem

[lists]

"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

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

Sure, you could do that. Correlating ipfw logging of outbound SYNs and 
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?

Not if someone has cracked your machine in a stealthy manner. There are 
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 b

Re: Spamrl.com RBL problem

[Bill Cole]

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


Sure, you could do that. Correlating ipfw logging of outbound SYNs and 
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?


Not if someone has cracked your machine in a stealthy manner. There are 
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 

Re: Spamrl.com RBL problem

[lists]

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: postfix-users@postfix.org
Subject: Re: Spamrl.com RBL problem

* Matthew McGehrin <drinking.cof...@gmail.com>:
> 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.

Give the shortages of ipv4 addresses, this is often the case

-- 
[*] 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

Re: Spamrl.com RBL problem

[Ralf Hildebrandt]

* Matthew McGehrin :
> 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.

Give the shortages of ipv4 addresses, this is often the case

-- 
[*] 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

Re: Spamrl.com RBL problem

[Ralf Hildebrandt]

* 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.
 
-- 
[*] 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

Re: Spamrl.com RBL problem

[Ralf Hildebrandt]

* Matthew McGehrin :
> 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
statistical reports)
-- 
[*] 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

Re: Spamrl.com RBL problem

[Ralf Hildebrandt]

> : 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
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? 

I don't think so

-- 
[*] 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

Re: Spamrl.com RBL problem

[Matthew McGehrin]

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.



Stefan Caunter wrote:
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. 



  

Re: Spamrl.com RBL problem

[Stefan Caunter]

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. 

> On Jul 3, 2016, at 00: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.
> 
> 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
> 
> 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
> 
> 
> li...@lazygranch.com wrote:
>> <i...@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? 
>> 
>> 

Re: Spamrl.com RBL problem

[lists]

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

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


li...@lazygranch.com wrote:
> <i...@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? 
>
> 

Re: Spamrl.com RBL problem

[Matthew McGehrin]

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


li...@lazygranch.com wrote:

: 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? 

  

Spamrl.com RBL problem

[lists]

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

: 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?