最近总被CBL
报告如下 服务器上查杀没问题 没有开放中继 也没有运行sendmagic 请问是什么问题 很困扰IP Address 112.xxx.xxx.xxx is listed in the CBL. It appears to be infected with a spam sending trojan or proxy.
It was last detected at 2011-09-19 10:00 GMT (+/- 30 minutes), approximately 1 hours, 30 minutes ago.
It has been relisted following a previous removal at 2011-09-18 05:21 GMT (1 days, 6 hours, 4 minutes ago)
This IP is sending email in such a way to indicate that it is, or is NATting for a web server that is infected with a spam sending script, like Darkmailer, DirectMailer, r57shell, or some analogous PHP or CGI script.
If, however, you are running the "sendmagic" mail server package, please contact your vendor for an update.
If you are not running "sendmagic", the following should help you identify where the spam sending script is located so that you can remove it as well as innoculate your web server so it doesn't happen again.
This IP is infected with, or is NATting for a machine that is infected with, a PHP-based backdoor trojan. The most common target of this infestation is Plesk hosting environments using Qmail and Wordpress or CPanel hosting environments.
The WebMaster should pay very close attention to the following:This infects web hosting environments. ONLY the hosting company can fix these infections properly.
If you are not the administrator of this hosting environment, there is probably nothing you can do to fix this infection, you MUST refer this listing to them. The hosting administrator has to do the fix. We recommend you forward this email to them.
This is a checklist of things the administrator needs to do before delisting.
Turn off PHP script support within the web server except where absolutely necessary. Many of these compromises appear to be uploaded via a vulnerability in older versions of WordPress. Make sure you have the latest version. Identify, kill and remove the backdoor trojan scripts currently on the web server (see below). Implement port 25 blocking so that only your mail server software userid can make outbound port 25 connections from this machine. How to find web-based PHP (and other) backdoor trojan scripts.How to prevent your site from getting hacked. How to repair a damaged site. Website security precautions. and its companion document Website security: How to find backdoor PHP shell scripts on a server have detailed instructions on how to find various kinds of web server trojans and back doors. There is a simple script at the end of this web page that you can download and run. This script is known to detect at least some of these backdoors.
In one case, two malicious files were involved. One was a malicious .htaccess file that could be found by: (substitute rootdir with the directory of your web hosting directories):
find rootdir -name '.htaccess' -print | xargs grep 'RewriteRule' This yielded a line like this naming the malicious PHP script:
RewriteRule . /phpinfo.php Alternately, the script itself could be found with the following command: find rootdir -name '*.php' -print | xargs grep 'eval(base64_decode'Which yields a line like this:
eval(base64_decode('DQpAZXJ ... Followed by many lines of Base64 encoding. Securing your server from future infectionsThere are a variety of things to do.
Ensure that your web server does not allow clients to modify ".htaccess" files. Only permit PHP where necessary. You SHOULD configure your web server to prevent such infections being able to spam the Internet. Once you've done this correctly, it doesn't matter whether the spammer can still upload this malware, they can't spam with it, so they'll leave you alone.
There are a variety of ways to do this. In short, you're implementing a firewall restriction that only permits root and the mail server userid to make outbound port 25 (email) connections. You can either do it yourself with a software firewall, or, use third party software to do the same thing.
configserver.com has a variety of products and services that can deal with this issue. Note that the CBL has no connection whatsoever with ConfigServer. If you know of other software packages that can deal with Darkmailer please let us know and we'll mention them here.
The most commonly used ConfigServer product appears to be ConfigServer Security and Firewall (CSF) and it's FREE. The feature you want to turn on is "CSF SMTP_BLOCK" which, as far as we can tell, does exactly the firewall restrictions we describe above.
Another product that ConfigServer offers is ConfigServer eXploit Scanner (CXS). This software is not free ($75 regular price, currently $50). This software monitors FTP uploads in real-time, will automatically detect Darkmailer and other malicious downloads, and remove them.
Most Cpanel implementations already have something called "SMTP Tweak" (aka "WHM SMTP Tweak") available. It apparently doesn't do the firewall configuration we describe, but it wouldn't hurt to turn it on too.
If necessary, you can implement the firewall restrictions yourself without using any extra software.
iptables -A OUTPUT -d 127.0.0.1 -p tcp -m tcp --dport 25 -j ACCEPTiptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --gid-owner mail -j ACCEPTiptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --gid-owner mailman -j ACCEPTiptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --uid-owner root -j ACCEPTiptables -A OUTPUT -p tcp -m tcp --dport 25 -j REJECT --reject-with icmp-port-unreachableYou may need to add or change the "-m owner ... ACCEPT" to be consistent with your mail server. Eg: you'll need different entries for Qmail.
You will also have to ensure that these iptables commands are executed every time the system reboots, perhaps by an init script.
If you're using cPanel and APF, APF by default will wipe out iptables rules you enter manually leaving the server vulnerable. If you are using APF, you should make the above change via APF and that will take care of reissuing the commands upon reboot or reset.
Note: in some virtual hosting environments, the above commands will return error messages. This generally means that the host (not virtually hosted) operating system does not support the iptables kernel modules. If you do get such errors, make sure that the base operating system has the iptables module fully installed.
r57shell InfestationsIn one case, it turned out to be a file called "info.php" in the user's images directory. Info.php turned out to be a modified copy of the "r57shell" PHP script which provides a backdoor through which an attacker can do virtually anything on your web server.
Thus, even though you have changed the passwords, the spammer could still upload the spamming scripts at will - this was found by noticing invocations of the PHP file in the web server logs from the same IP address the original FTP connections came from. You will need to search for such files as well, and we recommend preventing the execution of scripts (.php, .pl, .cgi, etc) in directories that do not need it. Eg: only the cgi-bin directory should permit execution. Nullamatix has a discussion on some simple ways to find r57shell.
It is known that Symantec EndPoint Protection can detect the original r57shell. The index.php file described above was a modified r57shell, and SEP doesn't detect it. A handful of AV detectors detect it as Backdoor.PHP.Rst!, but this doesn't help on Linux/UNIX. Note in particular, ClamAV not detect the "info.php" variant mentioned above. The script in the next section should find most versions of common trojan shells.
A Simple Trojan finding script in PerlThe following Perl script should find most trojan shells. It was chosen to be short and simple to understand so that an administrator would feel safe cut-and-pasting the script and running it. The script only looks in the most likely places, and therefore should run very fast as a quick check.
It is not expected that this script would find every possible trojan, so if this script fails to find anything malicious, you will need to resort to the other methods described above. Suggestions for improvement are welcome.
Instructions (only for webmasters with shell access to web hosting directories):
Cut and paste the script to a file, we'll use "cblphpfind" for the purposes of these instructions. Make the script executable: chmod 755 cblphpfindRun the script as a user with read access to the web hosting directories like this: ./cblphpfind Note:if this script finds a directory it cannot open, it will stop. If it does stop, you will need to run this script as a user that has read access to the entire directory tree. The userid that runs the web server is a good choice. You can use "root" if you really have to. On a Ubuntu system running Apache (not a hosting environment), the following command checked the web hosting directory:
./cblphpfind /var/wwwIf the web server uses aliases to redirect some web queries (including virtual hosts) to other directories, you should specify those too.
If you know which virtual host has the infection, you can try running cblphpfind on just the directories for that virtual host alone first.
When it finds something suspicious it will print a line like:
/var/www/malicious/.htaccess: Suspicious(RewriteRule): RewriteRule . /phpinfWhich will name the file regarded suspicious, why it's suspicious (above found "RewriteRule"), and a fragment of the file showing the pattern.
Anything that the script finds as "suspicious" should be visually inspected and removed if it turn out to be malicious. #!/usr/bin/perl# The above line may need to be changed to point at your version of Perl# Very simple web malware detection module.# Author: CBL Team <cbl@cbl.abuseat.org># Version 0.01# List of access-control files to checkmy $access = '(\.htaccess)';# Patterns to look for in access-control filesmy $accesspat = '(RewriteRule)';my $MAXLINES = 50;# List of files to checkmy $scripts = '\.(php|pl|cgi)$';# Patterns to look formy $scriptpat = '(r57|c99|web shell|passthru|shell_exec|phpinfo|base64_decode|edoced_46esab|PHPShell)';for my $dir (@ARGV) { &recursion($dir, $access, $accesspat); &recursion($dir, $scripts, $scriptpat);}sub recursion { my ($dir, $filepat, $patterns) = @_; my (@list); opendir(I, "$dir") || die "Can't open $dir: $!"; @list = readdir(I); closedir(I); for my $file (@list) { next if $file =~ /^\.\.?$/; # skip . and .. my $currentfile = "$dir/$file"; if (-d $currentfile) { &recursion($currentfile, $filepat, $patterns); } elsif ($currentfile =~ /$filepat/) {#print $currentfile, "\n"; open(I, "<$currentfile") || next; my $linecount = 1; while(<I>) { chomp; if ($_ =~ /$patterns/) { my $pat = $1; my $string = $_; if ($string =~ /^(.*)$pat(.*)$/) { $string = substr($1, length($1)-10, 10) . $pat . substr($2, 0, 10); } #$string =~ s/^.*(.{,10}$pat.{,10}).*$/... $1 .../; print "$currentfile: Suspicious($pat): $string\n"; last; } last if $linecount++ > $MAXLINES; } close(I); #print $currentfile, "\n"; } }}WARNING: If you continually delistwithout fixing the problem, the CBL will eventually stop allowing the delisting of . If you have resolved the problem shown above and delisted the IP yourself, there is no need to contact us. 我也一样的，申请了几次都没用 是的，我也是，并且你申请解除了几十次之后，就会永远的封掉了！！！！再也不给你解了，最后给你来句：
Specified IP has been removed an excessive number of times from the CBL without being fixed. Therefore, delisting of this IP address has been inhibited. YOU MUST FIX THE PROBLEM FIRST!
Delisting inhibited Follow the above instructions to get it delisted. 应该是您服务器弱密码利用了，群发导致IP被黑的，如果申请不了，建议您采用中继转发 查看日志，好好分析一下，然后把smtp连接数异常的ip封掉即可。
CBL的即使暂时不能解除，如果你的问题解决了，就是没有再发垃圾数据了一般24-32小时内就会重新出来可以解除的链接的。我遇到一回最长的时间是5天。前提是你一定要把问题解决. 我是winwebmail的系统
一直没差到实质问题 日志里可疑的ip和链接都kill掉了
对方的答复是 如下 检查
It will be one of the following scenarios:
1) It's a NAT firewall, in which case it is a NAT
in front of a machine that is infected with spam
sending spamware.
2) It's directly infested with spam sending spamware.
This detection is of the DarkMailer/YellSOFT DirectMailer
Spamware.
You can find out more detail on this by doing google searches
for "YellSOFT DirectMailer" or "DarkMailer", including
screenshots of the control panel this software installs on
your web server (the control panel in Russian).
See, for example, http://en.wikipedia.org/wiki/Dark_Mailer
http://forums.cpanel.net/showthread.php?p=496217
Note the references to "csf SMTP_BLOCK" and "WHM's SMTP Tweak"
This detection is that of a spammer who has broken into your
web server (usually) via cracked or keylogged FTP credentials.
Once they've logged in via FTP, they install perl scripts
that do the spamming.CPanel and Plesk installations are the
most common infectees, but others (including Apache) are also
subject to this problem.
ANY web server capable of running Perl scripts (whether
Windows, UNIX, Linux, FreeBSD etc) and permits FTP access for
customers/users OR EVEN administrators to change their web
pages is potentially a victim of this spamware.
In order to keep this IP delisted from the CBL, not only does
the infestation hae to be found and removed, you must implement
measures to prevent it from recurring.Changing FTP passwords
or suspending users (usually not necessary) will not prevent
future infestations.You must implement measures to
stop Darkmailer uploads _OR_ prevent Darkmailer infection being
able to send email - in other words, implementing outbound
firewall restrictions on email except from the userids associated
with your mail server.Eg: "CPanel/WHM's SMTP Tweak", the
"CSF SMTP_BLOCK", or something similar to the iptables command
we give below.If your IP continues to get reinfected we will
stop delisting.
Furthermore, please examine your system logs (eg: /var/log/messages)
for uploads of the script.If you find any, please send us a copy.
They will look something like this:
Mar4 04:02:11 enam pure-ftpd: (skgurun.41.229.131)
/home2/skgurun//public_html/rocker/dark.cgi uploaded(74627 bytes,
126.66KB/sec)
Mar4 05:03:54 enam pure-ftpd: (skgurun.41.229.131) Deleted
dark.cgi
[Notice how it was uploaded and deleted after about an hour.
You can often identify this (on UNIX/Linux systems) by
doing "ps" (process status) and finding many (often 10
or more) long-running processes named "<something>.cgi",
"<something>.php" or "<something>.pl" that are owned by the
same user as your web server instance.As an example, one
infectee saw 25 copies of a "dm.cgi" program running under
his Apache server's userid.
The other type can be seen by (as root) running the
command "netstat -nap".Lines like this (with random
program names rather than your MTA software) means you're
infected:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 1 192.168.2.2:58246 212.69.102.240:25 SYN_SENT 12614/b.pl
tcp 0 0 192.168.2.2:35843 209.85.201.27:25ESTABLISHED 7996/ciwhcnsb.pl
tcp 0 0 192.168.2.2:53051 81.13.48.2:25 TIME_WAIT -
tcp 0 0 192.168.2.2:53623 77.243.121.126:25 TIME_WAIT -
tcp 0 0 192.168.2.2:57816 217.13.210.81:25TIME_WAIT -
tcp 0 1 192.168.2.2:50531 217.16.16.81:25 SYN_SENT 12270/nxhbo.pl
tcp 0 0 192.168.2.2:52437 217.198.11.26:25TIME_WAIT -
tcp 0 1 192.168.2.2:50140 195.64.222.2:25 SYN_SENT 9273/yzezihd.pl
Foreign addresses that end with ":25" indicate _outbound_
email connections.TIME_WAIT means the connection has been
shutdown, but other states indicate active outbound
connections.You probably won't be able to find the
program names (eg: b.pl, ciwhcnsb.pl, nxhbo.pl etc) on your
file system, because they deleted themselves immediately after
starting.But you will be able to find the process via
"ps" based on process id (PID).
Note that darkmailer is often uploaded, run, and deleted
quite quickly, so you might not see anything except if you're
lucky enough to run the command while the darkmailer script
is actually running.
There are two main versions of this spamware:
In the first, it works by uploading a series of ".php" and
".pl" scripts via FTP (you'll see this in your FTP logs), and
then invoking them via your web server.Once the programs
are invoked, they delete themselves from the file system,
but remain running.
In the second, the spamware is a "cgi" Perl script that does
not delete itself.It can be called anything - eg: "dm.cgi",
"test.cgi", "dark.cgi" etc.
It will most often be in the cgi-bin directory, perhaps that
of an individual user, not the system-wide one.
You also may find various files like "from.txt", "replyto.txt"
etc.There is sometimes also a "sys" directory that contains a
lot of "*.mx" files.This all has to be eradicated.
Whether these exist depends on the configuration of the
DarkMailer/DirectMailer spamware that is infecting your machine.
Dealing with this can be difficult, because as long as your
FTP passwords can be cracked (or stolen from an infected web
developer's PC) it can come back at any time.
First: minimize FTP access.Secure/change all passwords.
If you can do your customer uploads some other way, turn off
FTP, or prevent FTP from writing directly into the web server's
document directory.
It is entirely possible that this spamware can be installed
by other means (eg: FrontPage extensions), but we have not
heard of it actually being done.Yet....
Second: Find the infection.If it's the second version ("cgi"),
you can find it, remove it and kill any running copies.
If it's the first version, there's nothing to find because
it's deleted itself, instead you have to stop the current
processes running.The simplest way is to reboot the server.
Or, if you can identify _all_ of the rogue processes, killing
them should be enough.Just make sure they stay dead.
Third: Configure your system to absolutely prohibit any userid
except root or your mail server's userid (often "mailman" or
something like that) from getting access to outbound port 25.
In this way, even if you do get infected, the spamware can't
get email out to the Internet.
In the above links, take note of the references to "CPanel/WHM's
SMTP Tweak" and "CSF SMTP_BLOCK".
"SMTP Tweak" is apparently a standard feature in WHM."SMTP_BLOCK"
is a feature in ConfigServer's "CSF" firewall.
WHM "SMTP Tweak" doesn't always work, because it doesn't do quite
the same things as SMTP_BLOCK, and "SMTP Tweak" can sometimes be
"clobbered" by other applications.
Note also that the CSF SMTP_BLOCK blocks all port 25 connections
initiated from your server, inluding those to localhost."localhost"
may be used by your webmail application or some other things.If,
after you turn SMTP_BLOCK on, legitimate email gets blocked too
(eg: webmail, web-based email applications etc), set SMTP_ALLOWLOCAL
to "1".
There are many other ways to accomplish this for other web servers,
for example, IPTables on Linux, PF on FreeBSD etc.
These IPtables commands do the same thing as CSF SMTP_BLOCK and
SMTP_ALLOWLOCAL does (both set to "1").
iptables -A OUTPUT -d 127.0.0.1 -p tcp -m tcp --dport 25 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --gid-owner mail -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --gid-owner mailman -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --uid-owner root -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 25 -j REJECT --reject-with icmp-port-unreachable
[Permits only the users "mail", "mailman" and "root" to go outbound
on port 25.
If you're using cPanel and APF, APF by default will wipe out iptables
rules you enter manually leaving the server vulnerable. If you are using
APF, you should make the above change via APF, then APF won't wipe them
out.Furthermore, APF will take care of reissuing the commands upon
reboot or reset.
Note that while this description may seem vague, be assured that
there is NO POSSIBILITY that this listing was caused by any form
of legitimate mail or network activity.Secondly, there is also
NO POSSIBILITY that the IP address was spoofed.Thirdly, the
presence or lack of anti-virus software in your mail server
CANNOT and DOES NOT prevent this from happening, because most of
these infections contain their own mail clients, and they bypass
your mail server software.
You will need to examine the machine for a virus or spam sending
spyware/adware/worm.
Up-to-date anti-virus and anti-spyware tools are essential.
For NAT firewalls, we recommend you pay careful attention to
the next paragraph:
If the IP is a NAT firewall, we strongly recommend configuring
the firewall to prevent machines on your network connecting to
the Internet on port 25, except for machines that are supposed to
be mail servers.Once you have done this, you can use your
firewall logs to detect which machines are infected/compromised.
Note that many NAT routers/gateways support UPNP capabilities.
If yours does, and you don't need it, turn it off.
http://cbl.abuseat.org/advanced.html has more information on
finding infected machines on a NAT, as well as more details
on UPNP.
Running a combination of anti-spyware and anti-virus programs should
help to find the malware.
It is unfortunate, however, the track record of current/popular
Anti-Virus software at finding current and severe threats is abysmal.
In fact, recent studies have shown that "new" threats are only caught by
_any_ of 35 of the most common A-V packages 23% of the time, and that
only improves to 50% after a month.In other words, if you were running
ALL of those 35 A-V products at once, a new threat would be caught only
23% of the time by _any_ of them.
http://www.mynetwatchman.com/tools/sc/ (the seccheck tester) will
probably be the most helpful in analyzing system security, as well
as yielding information we can use to help others to find/kill it.
However, Seccheck requires considerable Windows system internals
experience, and other tools may be more appropriate.
"Hijackthis" is similar to seccheck.There are online forums where
you can upload hijackthis reports and have an expert analyse
them, identify what is wrong, and make suggestions on how to fix it.
Perhaps one of the best tools for spot-removal of specific current and
common threats without requiring very high levels of expertise is the
Microsoft Malicious Software Removal tool (MSRT) at
http://www.microsoft.com/security/malwareremove/default.mspx
MSRT is NOT a replacement for a good A-V scanner.It's just good at
finding/removing many of the BOTs we detect (eg: cutwail, srizbi,
storm, etc).
MSRT is continuously updated with new heuristics.If your copy of
MSRT is more than a day or two old, download it from Microsoft
again.
If this IP is a firewall, scanning/eradication of viruses on your
internal network will NOT reliably keep the IP out of the CBL.
You MUST apply the configuration changes we recommend above to
NAT firewalls.
If you are running Barracuda, you MUST turn off the "bounce
spam and viruses" option.As spam and viruses are always
forged, the "bounce" feature simply results in mailbombing
innocent third parties with misdirected garbage - in other
words, the Barracuda is spamming.
Notes:
- False "gheg" detections have been seen with M&Wise's MTA
software, "UMS".Please contact your vendor for a patch.
We believe that most installations using this software have
already been patched.
- False "gheg" detections have also been observed with
challenge/response messages from the "TotalBlock"
challenge-response (C/R) anti-spam solution (www.totalblock.net).
Please contact your vendor for a patch.
Note: C/R is a bad idea in the first place because it bombards
innocent third parties with challenges to emails that they didn't
send.The CBL does _not_ list on this basis (it has no way of
knowing the email is a challenge), but other DNSBLs do.In this
case, the challenge emails are implemented poorly and trigger
gheg detections.
I've removed the entry from the list.
It may take a few hours to propagate to the public nameservers.
WARNING: the CBL WILL relist this IP if the underlying issues are not
resolved, and the CBL detects the same thing again. 奇怪的是 我用将邮件通过全部用其他的海外转发服务器投递 这台转发服务器始终不会被列入黑名单
但是中继始终不是办法，发出的邮件大部分会被当spam Have you implemented port 25 blocking? Your IP is still actively sending spam from a darkmailer infection.
This is what you need to keep in mind when you're trying to resolve
situations like this:
1) Our detections are based on port 25 SMTP connections your IP makes
to one or more of our mail servers.The CBL listing _itself_ is the
evidence/"proof"/log that the incident occured.
We generally do not keep samples of CBL detections, because the volumes
are so horrendously high (700,000-1,200,000 detections per day).They
never provide any additional information, because the headers, if any,
are all fake anyway.
3) The viruses we detect carry their own SMTP clients with them, and do
not attempt to relay through your mail servers.Hence, email transit
filters (either inbound or outbound) on your mail servers can't help.
Only AV scanning the infected machine does.
Similarly, the spamware (open proxy or spam trojan) we detect do
not route through your mail servers either.
4) AV tools aren't very good at detecting/cleaning out established
infections, especially those resulting from day-zero attacks.Many of
these infections open back doors, and the original infection vector
downloads many pieces of software that _may_ not be in themselves
malware, just used in a malicious fashion.
5) The headers don't help at all.Since virus/spamware have their own
SMTP clients, and doesn't pass through your server, the only thing
knowable about the virus/spamware is the peer (connection) address at
the recipient's mail server - which is what we've listed - your NAT
firewall if you have a NAT...Only your NAT firewall logs can tell you
any different.
Short of AV scanning the infected machine, the only useable information
about which machine is infected is in your NAT firewall logs - if
you actually make any logs and keep them long enough.
For the most part, then, a CBL listing of an IP means that the IP
needs to be fixed.If it's a NAT IP - port 25 blocking (and you
can find/fix the infected machine at your leisure), if it's not
a NAT - virus/malware eradication.
6) Outbound port 25 connection blocking on NAT firewalls (permitting
only your authorized mail servers) is the best solution for NATs.
7) If you have a NAT, once you've implemented port 25 blocking, you
not only contain the viruses, your NAT firewall logs will immediately
tell you who is infected or is compromised with a spam trojan or
open proxy.
8) As far as we're aware, once port 25 blocking is instituted in A
NAT, the only times people have continued to have trouble with CBL
listings is when the blocking wasn't working for some reason.It
would be a good idea to test whether the blocking is in fact working.
We have suggested procedures for this if you want - ask us.
页:
[1]
