Issue Server listed on Spamhaus XBL on a daily basis

[Trigger Box]

For the last week the server IP address is listed on the Spamhaus XBL list on a daily basis.

https://www.spamhaus.org/query/ip/196.201.6.183

We have run both chkrootkit and rkhunter and there seems to be no exploits on the server.

After delisting it takes less than 24 hours before it is listed again.

The XBL link takes us to http://www.abuseat.org/lookup.cgi?ip=196.201.6.183 with the following message:

IP Address 196.201.6.183 is listed in the CBL. It shows signs of being infected with a spam sending trojan, malicious link or some other form of botnet.

It was last detected at 2016-10-19 10:00 GMT (+/- 30 minutes), approximately 3 hours ago.

It has been relisted following a previous removal at 2016-10-19 04:11 GMT (9 hours, 2 minutes ago)

Perhaps the person who previously removed it didn't actually fix the problem.

If this IP address is NOT a shared hosting IP address, this IP address is infected with/emitting spamware/spamtrojan traffic and needs to be fixed. Find and remove the virus/spamware problem then use the CBL delisting link below.

In some unusual cases, IP addresses used in shared hosting (especially those using IPSwitch Imail, Plesk or Cpanel) can trigger CBL listings. If this is a shared hosting IP address, make sure that your mail server software is set up to identify _itself_ in its mail connections, not each of your customers.

If you are using Plesk, see this link.

If you are using cPanel, see this link.​

The Plesk link takes us to: http://www.abuseat.org/PleskAvoid.html

We have changed the setting as recommended by the PleskAvoid article.

The server is details are as follows:

Operating system: Ubuntu 12.04.5 LTS‬
Plesk product: 12.5.30 Update #50
Installed mail server: Postfix
Installed IMAP/POP3 server: Courier-IMAP

Any help in this rather urgent matter will be greatly appreciated.

On a side note we had this issue a while back on Postfix but not when switching to Qmail. For the last week it happens on both Postfix for Qmail but we settled on Postfix - it is our understanding that it is better - and the suggested settings on http://www.abuseat.org/PleskAvoid.html is not available on Qmail.

 

[lvalics]

My suggestion is to go to Postfix and disable sending mail from CLI or phpmailer, only SMTP. This will help that if some WP or other kind of sites are hacked (and they can delete files after sending out mails) to not send out mails. Also limit the outgoing mails to 100/hour/domain then you can see very fast if anyone is sending or not out mails.

 

[Trigger Box]

Hi Ivalics,

Thank you for your suggestion.

There are many sites that need to use PHPMailer legitimately for invoicing, etc and will "break" if we disable it. This will not be a practical work around.

The one screenshot in my initial post indicate that outgoing mail is set to 100/hour/domain. There are no attempts to exceed limits on the Outgoing Mail Control page.

Regards,
Trigger Box

 

[Alberto Pizzarelli]

hello,

but the system logs?

show /var/log/maillog, and control postfix queue messages whit:

/usr/local/psa/admin/sbin/mailqueuemng -s

or mailq command if exist,

another location for your analisys is the outbond connection on destination port 25, whit

netstat  -n | grep :25

or

lsof | grep tcp

to controll all outbond connection

 

[Trigger Box]

Hi Alberto:

Nothing in Mail Queue:

root@cp01:~# /usr/local/psa/admin/sbin/mailqueuemng -s
Messages in deferred queue:  0
Messages in hold queue:      0
Messages in incoming queue:  0
Messages in active queue:    0
Messages in corrupt queue:   0
Messages total:              0
Messages found:              0
Timestamp: 1477045237

Netstat:

root@cp01:~# netstat  -n | grep :25
tcp        0      0 196.201.6.183:25        196.201.6.127:61875     TIME_WAIT 
tcp        0      0 196.201.6.183:25        196.201.6.127:61775     TIME_WAIT 
tcp        0      0 196.201.6.183:587       41.114.195.110:25502    ESTABLISHED

lsof:

root@cp01:~# lsof | grep tcp
couriertc  1798         root  txt       REG                8,1       60728    9457980 /usr/lib/couriertcpd
couriertc  1822         root  txt       REG                8,1       60728    9457980 /usr/lib/couriertcpd
couriertc  1845         root  txt       REG                8,1       60728    9457980 /usr/lib/couriertcpd
couriertc  1877         root  txt       REG                8,1       60728    9457980 /usr/lib/couriertcpd

 

[Alberto Pizzarelli]

i know!!
the evidence of what happened to you will find in the log, in the shell commands I gave you, you will see something into the attack moment, surely it is to consider that if you have fallen into the blacklist, it is because of your servers have been sent email , you just have to figure out how.

 

[jorge ceballos]

Hi,

Don´t know if this https://talk.plesk.com/threads/blac...sing-domain-names-in-smtp.306232/#post-802522 has been corrected yet, but just make sure it is not the case.

Regards

 

[UFHH01]

Hi Trigger Box,

first of all, the statement at "http://www.abuseat.org/PleskAvoid.html" is completely wrong. You are certainly able to use the marked option and it will certainly work as expected. For a more detailed explanation, pls see for example: => #18

 

[Trigger Box]

Hi,

Don´t know if this https://talk.plesk.com/threads/blac...sing-domain-names-in-smtp.306232/#post-802522 has been corrected yet, but just make sure it is not the case.

Regards

Hi Jorge,

I am already on setting #1, but we still have this problem of being listed every 6-12 hours in CBL

 

[Trigger Box]

Hi Trigger Box,

first of all, the statement at "http://www.abuseat.org/PleskAvoid.html" is completely wrong. You are certainly able to use the marked option and it will certainly work as expected. For a more detailed explanation, pls see for example: => #18

Hi UFHH01,

Do you have any other ideas of why I am listed on a daily basis?

 

[UFHH01]

Hi Trigger Box,

there is a lack of a lot of informations, which allow investigations to your issue being blacklisted constantly again and again.

We have run both chkrootkit and rkhunter and there seems to be no exploits on the server.

This is a very insufficient information, because as you stated, there are a lot of customers sending mail over PHP. You definetly have to include headers from eMails being declared as spam, or being declared as infected, if you want to investigate your issue. We really can't guess eMail - headers and domain - contents!
In addition, pls. inform us about your "php.ini" - setting(s) ( !!! => be aware, that there are several ones on your server, if you use multiple PHP - versions! ) for "sendmail_path =", "mail.force_extra_parameters =", "mail.add_x_header ="

It would help as well, if you include domains, especially because you setup Google as relay mail - server as well.
Apart from that, WHO told you to setup Google as relay and WHY with this configuration:

triggerbox.co.za.    MX    3600    10 alt4.aspmx.l.google.com.
triggerbox.co.za.    MX    3600    1 aspmx.l.google.com.
triggerbox.co.za.    MX    3600    5 alt1.aspmx.l.google.com.
triggerbox.co.za.    MX    3600    5 alt2.aspmx.l.google.com.
triggerbox.co.za.    MX    3600    10 alt3.aspmx.l.google.com.

You misconfigured your SPF - entry ( there are TWO, with different definitions! ):

triggerbox.co.za.    TXT    3600    "v=spf1 +a +mx -all"
triggerbox.co.za.    TXT    3600    "v=spf1 include:_spf.google.com ~all"

=> First you use the strict setting "-all", with the other entry you weaken the setting with "~all". The "FAIL" and "SoftFAIL" setting is VERY important here! ( Pls. read as well: => https://tools.ietf.org/html/rfc7208 )
=> You can only have ONE valid SPF - setting for a domain.
=> On the other hand, your configured "hostname" has NO SPF, DomainKeys/DKIM, DMARC - entry ( see: https://www.dnswatch.info/dns/dnslookup?la=en&host=cp01.triggerbox.co.za&type=TXT&submit=Resolve ).

You setting shown in your post => #1 shows NO DomainKeys / DKIM - signing and investigations for "default._domainkey.cp01.triggerbox.co.za" and "default._domainkey.triggerbox.co.za" tells us, that you miss that completely!
Same goes with DMARC - entries.


Pls. keep in mind, that if you host multiple domains on one IP, it is VERY MUCH recommended to ONLY ALLOW SMTP authenticated eMails, to avoid constant, daily investigations for PHPMail.
Make sure, that ALL domains on your server have existent SPF, DomainKeys/DKIM and DMARC - entries, if you host multiple domains on one IP!


Investigate your mails and scripts, that use sendmail:

Many email messages are sent from PHP scripts on a server. How to find domains on which these scripts are running if Postfix is used? ( KB - article 114845 - for postfix - usage )
Many email messages are sent from PHP scripts on the server. How to find the domains on which these scripts are running? ( KB - article 1711 - for qmail - usage )​

 

[Trigger Box]

This is a very insufficient information, because as you stated, there are a lot of customers sending mail over PHP.

We have in the meantime also done the following

• Ran Clamscan on the server in vhosts/*/httpdocs/* and;
• Cleaned what looked like malicious files on all hosting accounts
• Fixed the PTR record

$ host 196.201.6.183
183.6.201.196.in-addr.arpa domain name pointer cp01.triggerbox.co.za.

You definetly have to include headers from eMails being declared as spam, or being declared as infected, if you want to investigate your issue. We really can't guess eMail - headers and domain - contents!

The biggest frustration after contacting the CBL Team directly is that they do give specific samples of emails being declared as spam, or being declared as infected.

This was the core of their message:

196.201.6.183 was found to be using several different EHLO/HELO names during
multiple connections on or about:

2016:10:22 ~21:30 UTC+/- 15 minutes (approximately 3 hours ago).

The names seen included:

artandwine.co.za, blackboards.co.za, childrensbook.co.za, erangol-consulting.com, erangol-namibia.com, lourensinternationalhotels.com, luxuryhotelawards.com, matthewgifts.com, ramfest.co.za

I am not sure what specific issues there are with these domains.

In addition, pls. inform us about your "php.ini" - setting(s) ( !!! => be aware, that there are several ones on your server, if you use multiple PHP - versions! ) for "sendmail_path =", "mail.force_extra_parameters =", "mail.add_x_header ="

Here are some different PHP versions, those parameters are the same:

PHP Version 5.6.27

sendmail_path = /usr/sbin/sendmail -t -i
mail.force_extra_parameters = no value
mail.add_x_header = On

PHP Version 5.3.10

sendmail_path = /usr/sbin/sendmail -t -i
mail.force_extra_parameters = no value
mail.add_x_header = On

It would help as well, if you include domains, especially because you setup Google as relay mail - server as well.
Apart from that, WHO told you to setup Google as relay and WHY with this configuration:

triggerbox.co.za.    MX    3600    10 alt4.aspmx.l.google.com.
triggerbox.co.za.    MX    3600    1 aspmx.l.google.com.
triggerbox.co.za.    MX    3600    5 alt1.aspmx.l.google.com.
triggerbox.co.za.    MX    3600    5 alt2.aspmx.l.google.com.
triggerbox.co.za.    MX    3600    10 alt3.aspmx.l.google.com.

My company email is with GSuite (previously Google Apps for my Domain). These are the initial MX records they specified. There are only a few domains on my server that uses Gsuite. The rest are all Postfix.

You misconfigured your SPF - entry ( there are TWO, with different definitions! ):

triggerbox.co.za.    TXT    3600    "v=spf1 +a +mx -all"
triggerbox.co.za.    TXT    3600    "v=spf1 include:_spf.google.com ~all"

=> First you use the strict setting "-all", with the other entry you weaken the setting with "~all". The "FAIL" and "SoftFAIL" setting is VERY important here! ( Pls. read as well: => https://tools.ietf.org/html/rfc7208 )
=> You can only have ONE valid SPF - setting for a domain.

I have removed the first one:

triggerbox.co.za.    TXT    3600    "v=spf1 +a +mx -all"

And left the second one as Google's recommendation: https://support.google.com/a/answer/178723?hl=en

=> On the other hand, your configured "hostname" has NO SPF, DomainKeys/DKIM, DMARC - entry ( see: https://www.dnswatch.info/dns/dnslookup?la=en&host=cp01.triggerbox.co.za&type=TXT&submit=Resolve ).

You setting shown in your post => #1 shows NO DomainKeys / DKIM - signing and investigations for "default._domainkey.cp01.triggerbox.co.za" and "default._domainkey.triggerbox.co.za" tells us, that you miss that completely!
Same goes with DMARC - entries.

Will look into this

Pls. keep in mind, that if you host multiple domains on one IP, it is VERY MUCH recommended to ONLY ALLOW SMTP authenticated eMails, to avoid constant, daily investigations for PHPMail.
Make sure, that ALL domains on your server have existent SPF, DomainKeys/DKIM and DMARC - entries, if you host multiple domains on one IP!

I will consider this recommendation

Investigate your mails and scripts, that use sendmail:

Many email messages are sent from PHP scripts on a server. How to find domains on which these scripts are running if Postfix is used? ( KB - article 114845 - for postfix - usage )
Many email messages are sent from PHP scripts on the server. How to find the domains on which these scripts are running? ( KB - article 1711 - for qmail - usage )​

Will look at this again.

Thank you UFHH01

 

[UFHH01]

Hi Trigger Box,

now that you gave some more informations, pls. try to follow my investigations:

sendmail_path = /usr/sbin/sendmail -t -i

1. This is the very issue, where you should put an eye onto... it means, that ALL mails using sendmail on your server, will use "www-data" ( or any other system-user - name for the apache2 - server ) as username and your hostname "cp01.triggerbox.co.za" as sender - domain, if you don't have other settings at "/etc/aliases" and/or "/etc/postfix/generic".

2. Due to the fact, that "cp01.triggerbox.co.za" doesn't have existing SPF -, DomainKeys/DKIM - , DMARC - entries, none of these eMails can be trusted and can be declared as spam. In addition, "cp01.triggerbox.co.za" doesn't have an existing MX - entry... another reason, why eMails can be declared as spam. The only "good" point here is, that your IP resolves to "cp01.triggerbox.co.za" and the reverse check resolves again back to your IP.

3. The recommendation from "https://support.google.com/a/answer/178723?hl=en" for your SPF - entry is nice, but how do you expect other mail - servers checking "A - entries", "MX - entries", "IP" and the "hostname", if you don't advice WHERE they should look for "trusted definitions"? ( I will refer to this question again at other points! )

4. Now let's be more specific and let's investigate the mentioned domains:

artandwine.co.za
blackboards.co.za
childrensbook.co.za
erangol-consulting.com
erangol-namibia.com
lourensinternationalhotels.com
luxuryhotelawards.com
matthewgifts.com
ramfest.co.za

NONE of them have a valid SPF - entries for your server - hostname and "luxuryhotelawards.com" and "ramfest.co.za" don't even trust their own IP "196.201.6.183", according to the SPF - entry "v=spf1 include:_spf.google.com ~all" ( no A - entry, no MX - entry, no hostname - entry, no IP - entry. Pls. go back to point 3. and read that again.​

5. If you resist on NOT using DomainKeys/DKIM and DMARC - validations, you should at least have valid SPF - entries, especially, when you allow sendmail - usage. The corresponding mail - servers must have a reason why they should trust eMails from "[email protected]".

To avoid to setup all these entries manually for each of your domains, you are able to use DNS - templates from Plesk at "Home > Tools & Settings > DNS - Template", where you can change the standard "v=spf1 +a +mx -all" to for example:

v=spf1 +mx +a a:<hostname> include:ispgateway.de ip4:196.201.6.183 ?all
​

After your changes, you just click on "Apply DNS Template Changes" and choose "Apply changes on existing domains".

Pls make sure, that when you don't use your Plesk server as primary nameserver for a domain, then you should not forget to change this specific SPF - entry over the Control Panel from your domain - provider!!! ( the corresponding entry will then look like the ones you can see at "Home > Subscriptions > YOUR-DOMAIN.COM > DNS Settings" => v=spf1 +mx +a a:cp01.triggerbox.co.za include:ispgateway.de ip4:196.201.6.183 ?all​

6. Each corresponding mail - server normally does as well a REVERSE CHECK, but when we go back to point 4. and check these domains ( or your server - hostname ), the result will be for example:

artandwine.co.za resolves to 196.201.6.183
but
196.201.6.183 resolves to cp01.triggerbox.co.za

An eMail probably "tells" the corresponding mail - server, that the sender wants to be "[email protected]", but the headers show that "[email protected]" is the real sender and when the mail - server checks the IP and the domain, there is no "artandwine.co.za". If a mail - server wants to connect to "artandwine.co.za", to switch HELO/EHLO - greetings, the result is:

looking up MX hosts on domain "artandwine.co.za"
mail.artandwine.co.za (preference:10)

and the greetings results in:

Connected to server
220 cp01.triggerbox.co.za ESMTP Postfix (Ubuntu)

Pls. answer for yourself, WHAT DO YOU think about the checks and HOW WOULD YOU react as a mail - server after all these checks and all the discrepancies? At the moment, there is no reason at all, why sendmail - eMails from "[email protected]" could be trusted at all.