Relaying allowed from outside IP - possible issue with popb4smtp?

[BlueNoteWeb]

Good morning all.

I've seen some mail getting relayed through my server from outside IPs that should not be allowed to relay mail. All of the tools that I can find online tell me that the server is NOT an open relay, but certain IPs from China and Taiwan have recently been allowed to send mail through the server.

For the time being I've firewalled off the entire /8 block where the mail is originating. That's not a permanent solution unfortunately, I have some users who do business with China and I can't leave that up.

In trying to troubleshoot this issue I've noticed that the spammers are using fake HELO information (which of course is nothing new), purporting to be one of the IPs assigned to the server. In the interest of privacy I'll post only the important bit from the mail log:

2008-02-10 09:15:37 1JODu5-0001rx-27 <= [email protected] H=(x.x.x.x) [125.110.209.70]

I've x'd out the value, but it's an IP on the server, owned by one of my users.

In my /etc/maillog I see that x.x.x.x IP showing up also, I assume this is coming from users logging in to webmail/squirrelmail. Is it possible that the popb4smtp system is picking up the false value rather than the real IP, thus granting the spammer access to relay mail?

 

[webquarry]

We have seen the same thing and so has Jeff.

I exchanged some emails with him last night and he indicated that it was something to do with the spamblocker exim.conf file and that he had a solution in beta. He said that he expected to release it this morning if everything tested out well.

DA really needs to jump on this because ALL DA installations are open to relaying until this is fixed.

Keep your net block in place until the fix. The bots that are sending this junk are still hammering our servers even after being blocked for over 15 hours now. They are persistent...

 

[NoBaloney2]

I'm uploading the latest exim.conf beta 3 now; and I've created a new exim.conf version, which I've posted to our server, and which I've announced here.

BlueNoteWeb,

According to the registry, the netblock beginning with 125.110 is not currently assigned so you probably are safe to block it.

If you block it in SpamBlocker instead of with your firewall anyone legit who tries to mail through it will be notified and can go to your page where you tell them how to whitelist themselves.

The spam is also spoofing your own IP# in their attacks, but that doesn't fool us either.

Good Luck!

Jeff

 

[webquarry]

Ok, I was bothered about why this spam was relaying through some of our servers and not through others. Indeed, others seem to have noticed the same behavior.

Here is what I found on the servers that did relay:

We were using a spamblocker2 exim.conf and we had gmail.com listed in our whitelist_domains file.

All the mail that was relaying was claiming to be from [email protected].

Gmail.com appears in /etc/virtual/whitelist_domains ON EACH MACHINE that was relaying. The machines that didn't have that entry didn't relay. We didn't add gmail.com to /etc/virtual/whitelist_domains. It appears that it came from DA that way during the installation.

I would encourage everyone to check that file and make sure that they do not have anything listed in it (if they are using a spamblocker exim.conf earlier than version 3.1) since that appears to be the vector that allows a relay to occur.

I would also encourage DA to find a way to let people know to check this file.

 

[nobaloney]

I don't believe it came that way from DirectAdmin.

Another problem we found was that the spammers appear to be using empty senders, and exim.conf automatically allows emails from empty senders as they're required by RFCs so you can get mail from Mailder-Daemons.

We rewrote the SpamBlocker exim.conf file to allow netblocks in the format:

125.110.0.0/16

inserted at the TOP of /etc/virtual/bad_sender_hosts. That works after you've installed SpamBlocker 3.1-beta.

And according to the chinese authority IP#s, it's supposed to be a not-in-use netblock, so it's okay to block it.

Note that SpamBlocker 3.1-beta requires Dovecot. We think that's a good upgrade .

Jeff

 

[DirectAdmin Support]

Hello,

No other reports of gmail in the whitelist_domains file.
DA uses uses "touch" to create it, so it's not likely part of the install.
To be sure, I also grepped "gmail" from every single file we have and this was the only occurance:

data/templates/forbidden_domains.list:gmail.com

which is just domains you can't create.

Note that apart from creating the whitelist_domains file with "touch" at install time, DA doesn't make any accesses to that file.

John

 

[webquarry]

We've done updates via Wael's update.script and it could be that it came somewhere from there.

Either way, I should point out that whether it cam from DA or Wael, it is NOT coming from either those sources now.

This appeared during a brief period time and then disappeared. New installs and updates are not vulnerable at this time.