0

I have developed a website with php and apache server on linux centos I am not professional on security issues and I think some folks try to hack my website first please advice me which security things I should follow

but my problem: tonight as I tried to login firebug showed it tries to load login.php for serveral times but a file error occurs (I think a permanent move or something....) anyway when I checked the login.php file in linux I have noticed the file permission has been changed and all x (execution) flags has been removed.

could it be the work of a hacker? what should I do to prevent such happening.

I changed chown to root, and also set chmod of all files from 775 to 755 please give more

Ahmad
  • 227

2 Answers2

1

In a situation like this, the first thing I would do is check the Apache log files. There should be an access_log as well as an error_log file(s). It should give you a clue as to possibly the source and what was done, if anything.

The logs are usually found in:

/etc/httpd/log/

The second thing I would do, if you think the script was changed, is to compare it for differences with a backup copy (that you know is secure and has not been tampered with).

canadmos
  • 166
-1

Boot from a CentOS installation LiveCD. Determine the harddrive installation location or $ROOT and if it is already mounted. Pass $ROOT to the following command. 

`rpm  --root $ROOT --query --verify --all`

which is the same as 

`rpm --root $ROOT -qva`

will verify all packages installed via yum/rpm. If a binary, say httpd is different than what was installed, then somebody has root. The catch is that rpm verify does not verify anything installed outside of rpm/yum. So if you download a module and install manually or a cgi script not installed via rpm, then it will not find changes to those files. Even if you only installed via rpm and it finds everything ok, that does not find compromise via misuse.

Examples of misuse:

  1. send a password over http instead of https.
  2. Do not choose a strong password for ssh.
  3. Use login credentials for ftp instead of using sftp.
rjt
  • 584
  • On a compromised host you cannot trust *anything, including the RPM checksums that would be used in this verification. (You've wisely chosen not to use the rpm binary from the compromised host, but unless you have all of the packages available on your CD you still need to reference potentially compromised data (the RPM manifests) on the hard drive.) You also can't verify that something not* managed by RPM wasn't installed, removed, or modified... – voretaq7 Dec 03 '13 at 21:42
  • @voretaq7 of course nothing can be trusted on the harddrive, that is why a boot from LiveMedia is necessary, preferably containing all the rpm packages. Not hard with 64GigaByte USB sticks. If not predownloaded, the rpms can be downloaded in the live session. Further, i addressed the second concern about installations outside of rpm starting with "The catch is ...." – rjt Dec 09 '13 at 16:13
  • If you read the man page for rpm you will find the following in the section about --root: "Use the system rooted at DIRECTORY for all operations. Note that this means the database will be read or modified under DIRECTORY". That means you'll be using the RPM metadata from the (compromised) --root in your example above (i.e. "trusting the compromised system's metadata"). If you intend to use RPM data from the CD you've left out a bunch of steps... – voretaq7 Dec 09 '13 at 16:29
  • @voretaq7 The canonical answer does not give specific information for quick forensic analysis of a RedHat derived machine. However, it recommends attempting to find out the cause of break-in because restoring from backup will probably just make the system vulnerable to attack yet again. Yes, steps were left out, such as using --dbpath but this is not necessarily a compromise yet. It could very well be a restoration of selinux context, not a hacking attempt. – rjt Dec 09 '13 at 16:37
  • Log files can be compromised too and if my answer is voted down, so should checking that answer. – rjt Dec 09 '13 at 16:39