Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi dears.
We designed a new website with PHP 5.x and hosted by Linux CentOS 6.x.
Today we saw that this code was added to first of the index.php file. How we can prevent from these attacks?
This isn't XSS as I normally understand it (entering JavaScript code into website forms). Firstly, are you sure that one of your developers didn't insert this? It looks like an attempt at home-baked analytics, and McAfee's siteadvisor.com doesn't raise any concerns about mattsmarketingblog.com.
If this has been inserted by an attacker, there are a few things you can do to improve security. The main ones that come to mind are:
Sanitise file uploads (if your site allows them) - users should never be able to choose filename or save path for files on the server.
Make sure your code directories are not writable by the web server user (apache?).
Thank you for your answering. I'm sure that this is an attack because we wrote this file and when we compared the file that is located on the server with the source file on our PC, there was this difference.
Can you please explain more about you 1st and 3rd solution?
1. The file will be uploaded to a temporary location, and this location will be passed in $_FILES['name_in_form']['tmp_name'] (generally something like "/tmp/phpOqF3Xs"), and the name on the user's system will be passed as $_FILES['name_in_form']['name']. What I was suggesting is that you should be cautious about storing the file on the server using the original name - instead, your script should select the path and filename (and store the original name in a database if it needs to be retained). This would negate any attempts by the user to overwrite a file already on the system (even if permissions allowed this).
3. Some HTTP actions are intended to change data on the server. In particular, the PUT method requests the server to store a document at a particular URL (and DELETE does what it sounds like). By adding a <Limit...> directive in the <Directory...> section(s) of your Apache config, your can lock this down.
Another point is that it's best to get PHP to check the type of any uploaded files (using the mime_content_type() function), to protect against an attacker managing to spoof the type sent to the server.
The question is, what types of files do your users need to be able to upload? The more limited, the better. If a site I was managing did need to allow users to upload executable files, then I'd want to spend some time investigating the risks and measures needed to protect against them (including making sure the upload directory is not directly accessible from the web, that PHP scripts cannot run from there, that files do not have the execute bit set, etc., etc.).
If someone added code to your index.php file, then they either gained access to your system, or jimmied the system that allows you to update those files remotely (which by the way should never exist).
Your system has been compromised and ultimately it will have to be reinstalled.
Thank you sundialsvcs, but it's a shared hosting and a think that there is some other solutions to solving this issue. (For example, antivirus or antispyware softwares).
There are a few ways how a file could have gotten there so until it's been proven compromised I'd appreciate it if you would not put it that way, if you understand what I'm saying...
Quote:
Originally Posted by centeralweb
(..) it's a shared hosting and a think that there is some other solutions to solving this issue.
Shared hosts share (in)security so it would be best if you would thoroughly investigate the matter and report back any findings.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.