Someone is being able to upload to my /var/www/vhosts/domain a file that sends tons of emails which is causing my server almost to crash, i am not able to understand how this is happening? how can i avoid this? anyone could help with this matter its really series since my clients are not able to use anymore webmail.

I have uploaded a sample of the file, the file usually is located on the root of the directory with the one of the following names:

default.php
_default.php
post.php
home.php

I use fedora

Attached Files

post.txt (969 Bytes, 25 views)

Fedora what? What version? What other software do you have on that box that could be compromised? What kind of firewall/security do you have in place?

Examine the connection logs...look for suspicious traffic. You can block that address/domain via iptables, or through your firewall, and remove the offending files....

How are pages uploaded onto your server?

• If by FTP, is anonymous FTP blocked? Are passwords strong? Are users kept within a "chroot jail" in their own directory, or can they navigate to other directories on the system? Is FTP denied for root and other privileged users?
• Do you use have a content management system (or even message board system) that allows file uploads? Does this allow users to enter (any part of) the filepath to which a file should be uploaded?
• Is your web server configured to allow the HTTP PUT method?

It would be worth looking through your FTP and Apache (I'm assuming you're using Apache) logs. In the FTP logs, assuming anonymous FTP isn't allowed, are there multiple failed login attemtps?

In the main Apache config file, you could include <LIMIT POST> directives for the web root, only allowing POST from localhost / the local domain / trusted hosts (though this is only a temporary solution, as if the user can still upload files, there will be other ways of attacking you). Also, just to be safe, you could <LIMIT PUT> with deny from all

Robhogg which file is the ftp log file?

what does this line means:

Apr 3 15:34:17 ip-xxx-xx-xxx-xx named[1734]: client 203.62.195.76#54968: zone transfer 'domainname.com/AXFR/IN' denied


Robhogg what i understood from your previous reply is that we can add a command that rejects any attempt to send emails from vhosts folder?

A couple of suggestions:

1)Start working your way through the CERT checklist and see if it helps identify how the system has been compromised

2)Pull the network plug. Until you understand what has happened, messing around with bits and pieces of it is only going to tip the spammers that you're on to them and they may get better at hiding their tracks. Besides, if you're clients can't use the server anymore, why should you let the spammers?

I was checking my mail queue list and i found this email:

Received: (qmail 23976 invoked by uid 111); 4 Apr 2009 01:51:25 -0700
Date: 4 Apr 2009 01:51:25 -0700
Message-ID: <20090404085125.23974.qmail@ip-xxx-xx-xxx-xx.ip.secureserver.net>
From: root@ip-xxx-xx-xxx-xx.ip.secureserver.net (Cron Daemon)
To: drweb@ip-xxx-xx-xxx-xx.ip.secureserver.net
Subject: Cron <drweb@ip-xxx-xx-xxx-xx> /opt/drweb/update.pl
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/var/drweb>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=drweb>
X-Cron-Env: <USER=drweb>


i am still waiting if some one could explain the line below which i found on my log file:

Apr 3 15:34:17 ip-xxx-xx-xxx-xx named[1734]: client 203.62.195.76#54968: zone transfer 'domainname.com/AXFR/IN' denied


Thanks

Like the cronjob email output you posted, denied DNS record transfers are not your main problem. If your current setup allows people to upload files then you should investigate what you're exactly running in terms of "plain" services (SSH, FTP, HTTP, .*SQL, et cetera), accessability (users running shell, open dirs, misconfiguration of services), software (webserver, PHP, PHP-based software), the software being up to date and configured well.
* If files are mysterioulsy appearing, then if you are running any PHP-based software, then the first thing to look at would be if a user might have found a hole (like remote file inclusion aka RFI) because you run either outdated software or it's misconfigured. I suggest you firewall off public access until you have investigated this. If you can't figure things out for yourself then log all in and outbound public traffic ports you run services on and post the software names and versions of services you run as well as any CMS or other PHP-based software, as verbose as possible, as well as anything you've tried to mitigate this situation. Understand this is not an exercise in futility but the more we know the more efficient it would be for us to help you.

Depends on which FTP server you're using and how it's configured. Look for a file / directory in /var/log with ftp in the name, or use grep to search for "ftp" in /var/log/messages and other system logs.

No, <limit POST> is used to restrict HTTP POST requests (used to upload data to the server). Looking at the script you attached, the attacker is using POST to control it:
However, if you do not require mail to be sent from the server, the best thing to do would be to stop whatever mail transfer agent you've got running (sendmail, exim4 or whatever).

Some systems might rely on having a MTA around for sending local mail (cronjob output, reporting), so making it unavailable might kill that off as well. Besides, and with all due respect, at this point (where still nothing is clarified by the OP), isn't that more like addressing symptoms instead of addressing the cause? After all it's not the MTA that's the problem. Restricting access and finding the attack vector should be the first task.

Someone tried an anonymous zone transfer. Crackers gather this sort of information in the reconnaissance phase to identify potential targets. Phase 2 is active probing/scanning for vulnerabilities. Phase 3 is gaining access (exploiting the vulnerability). Phase 4 is maintaining access (installing rootkits/backdoors). And last but not least is phase 5, covering one's tracks (deleting or altering logs).


Sounds to me like you're between phase 3 and 4 still. Once you've been rootkited the only way to be 100% sure you're clean again is the three Rs: repartition, reformat, reinstall. If it were me I'd pull the plug now.

With all due respect, unless the OP understands how the machine was cracked in the first place, this could result in a clean machine with the same vulnerabilities as before. I'm all for pulling the network plug, and maybe the power plug, but unless the OP is going to invest in figuring out the problem, the rest is just wasted time.