• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

hacked through PHP!!

D

devindull

Guest
My server keeps being hacked through PHP. I have removed the psybncs many times over. I also changed the php.ini to close up a couple supposed leak holes for hacking through. They keep starting processes under "Apache" and even crontabing them. Any advice on how to stop these people from entering and using our system for processes and so forth? THANKS!
 
Other than whole server hardening, or even kernel hardening, have you looked for known exploitable apps (such as certain versions of phpBB)?

You'll have to scan through all the hosted domains to take inventory of what apps and scripts they have on the server, then do some research as to which versions of what scripts are known to be exploitable.

Some also make their /tmp no-exec, but this can mess with other things, in some cases, spamassassin and mysql.

I would also advise installing RKHunter and CHKRootkit and doing regular updates and full scans.

You did not mention exactly which php.ini options you changed, but definitely you want Safe_mode ON, and make sure open_basedir is not set for /

This is enough to get you started...
 
Ok I changed the tmp directories access to no execute using chmod. Hopefully that is sticky? If not I can add it to a cronjob or for bootup execution. Anyway, aside from that, would SAFEMODE kill the ability of many php scripts to work?

I found that PHP.INI removed a lot of my disabled functions, which is how they entered. Plesk upgrade must have done that. Anyway, when I chmoded the tmp directories, Plesk would not restart. Is there a way to have Plesk use other full access directories aside from the /tmp/ and /var/tmp/ for starting itself?
 
Definitely a phpBB issue.

I think all HSP's should ban phpBB these days. Use some other bulletin board for your clients.

You could also mount /tmp with -noexec and / or 'chmod 600 wget'.
 
I tried mounting /tmp/ and /var/tmp/ as chmod 1600 or whatever it was to remove the execution ability. After doing so, Plesk wouldn't start. It for some odd reason requires those to be 1777 for me. Any reason why and how to fix that? I also changed the php.ini to use another tmp directory for its storage, and it's in a chroot jail. I really would like to get the chmod of those tmp directories fixed while keeping Plesk working though.
 
Yes, that would probably be due to mysql having problems with a no-exec /tmp as I posted earlier. This is not going to solve your problems. I recommend not pursuing the /tmp no-exec further, but concentrate on securing your server in other more fundamental areas!

Griffith has a good point (which I forgot to post) about installing mod_security, that would definitely be a good thing to do.

Originally posted by ShadowMan: have you looked for known exploitable apps (such as certain versions of phpBB)?
Have you done this yet?

Or are you simply trying to solve a complex problem with a bandaid?? (ie. only concentrating on the /tmp thingy)
 
I've modifed the PHP.INI by adding disable functions and activating some more safety features (not safemode though, that affects some scripts people use). I also setup a new php tmp directory as nonexecute. I can modify sqls configuration to use another tmp dir probably, solving that problem holding back the chmod of no execute, right? I'm going to look into mod security as well.
 
Originally posted by BoXie
Definitely a phpBB issue.

I think all HSP's should ban phpBB these days. Use some other bulletin board for your clients.

You could also mount /tmp with -noexec and / or 'chmod 600 wget'.
That is overkill. Blaming a program for a known vulnerbility that was patched is not the problem. If the forum admin keep the product up-to-date, phpBB (or any other forum program) would not be the problem. Right now the problems stem from vulnerbilities in php itself, the forum software is just being one of many avenues to exploit the php vulnerbility.

I have been running several forums for about 5 years now and have not had any problems with the forum software if it is kept up-to-date, same as you do the OS itself.

Educate your users about keeping the software programs updated is one of many steps to preventing further problems.

Also, as others have pointed out, the server admin could also help prevent some of these exploits/vulnerbilities with kernel/OS hardening.

Don't blame the software for admin mistakes.
 
I hate to sound like a broken record, but your php is most likely not being hacked and none of your php or mysql stuff will work if you mess with the permissions of your /tmp folder. What is most likely happening, is someone is using wget to plant things in your /tmp folder. Do a search for wget on your machine and change the permissions of it to 700, where only root can execute it. Then put everything back like it was and I bet your problems go away. At least RedHat 9 comes where by default, anyone can use wget to plant stuff in your /tmp folder.
 
I went one step further and renamed wget, and in its place I have a script which gets the URL and other args passed.

I'm sure there's a good automated/scripted solution to do an nslookup/whois on the URL and send an automatic abuse notice to the ISP and any contacts associated with the domain.
 
wget, curl, etcetera.

Renaming or chmodding wget only is pretty useless. Then you should also rename and chmod curl. And possibly some other of this kind of nice tools that are often standardly installed on al Linux box...

If they can't find wget, i have seen the hacking bots trying to use curl instead.
Beware of the open source scripts that want you to have safe_mode = off.

Leaving safe_mode = ON is the first and most easy step in securing your box against scripting exploits.
 
I didn't say it was absolute, but is one of the most common holes attempted, among the other obscure security methods implemented.

You say useless by renaming that executable, but I have curtailed the backdoor php drops that had been occuring.

I do agree with the safe_mode issue.
 
I didn't mean to be rude, Jimsander.
But i have seen this so many times in the logs: First they try WGET and if it fails, they switch to CURL.

And it is always happening to webmasters who do not keep their scripts up to date (phpBB, Gallery, phpadsnew).
 
Back
Top