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.
Hello,
I have a little trouble with our webserver which is using ISPManager 5.
We started to have a problems with injection of malware code to our websites (I think its XSS)
Some bot or someone included codes like this to almost all php files and server is spamming: (theyre doing it again and again if we get code cleaned)
$ua=strtolower($_SERVER["\x48\124\x54\120\x5f\125\x53\105\x52\137\x41\107\x45\116\x54"]); if ((! strstr($ua,"\x6d\163\x69\145")) and (! strstr($ua,"\x72\166\x3a\61\x31")))
Please, can you provide me solution how to fix it? I have default chmod from ispmgr (files 644, folders 755)
Let me know what to do. Thank you.
Absolutely the first thing you must do is take that machine offline!
As long as it is accessible to the internet you CANNOT get it cleaned up, as it will be reinstalled faster than you can clean it up - as you have seen. As long as it remains online it is doing harm to others by spamming and likely by spreading itself to other servers... pull the plug immediately!
Once it is disconnected, you may do whatever forensic investigation you desire, or simply reinstall (safest option).
Several questions that will be very helpful to those here who may try to help you...
Is this a server you own, a VPS or a shared hosting server?
Does this machine serve a single website or user, or multiple websites and users?
How many people have access via ftp, ssh, root login, etc.?
What applications run on it - Wordpress, phpmyadmin, carts, CMSs, etc., and are they fully patched?
What is the Linux version, apache version, etc., and are they all patched to the latest versions?
What sort of firewall is in use? What other security and intrusion detection is in use?
Its machine with multiple websites, but only one user - our company.
We re using SFTP(only our employees) and SSH which has access from our office only and 22 port is changed.
There is Apache2 installed,version:
Quote:
root@webserver:~# apachectl -V
Server version: Apache/2.4.10 (Debian)
Server built: Nov 28 2015 14:05:48
we re using updated Joomla and Opencart CMS.
Linux Version:
Quote:
root@webserver:~# lsb_release -da
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.3 (jessie)
Release: 8.3
Codename: jessie
We re using endian firewall which is connected to the webserver thru private networking. So, webserver hasnt public IP, just private IP 192.168.x.x and every traffic is going through firewall which has a few ports forwarded (80,443,21).
Apache has mod_security, mod_pagespeed activated, but for opencart systems is mod security disabled, because we got 401 bad request for ajax.
every domain have this htaccess:
Quote:
##
# READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE!
#
# The line just below this section: 'Options +FollowSymLinks' may cause problems
# with some server configurations. It is required for use of mod_rewrite, but may already
# be set by your server administrator in a way that disallows changing it in
# your .htaccess file. If using it causes your server to error out, comment it out (add # to
# beginning of line), reload your site in your browser and test your sef url's. If they work,
# it has been set by your server administrator and you do not need it set here.
##
## No directory listings
IndexIgnore *
## Can be commented out if causes errors, see notes above.
Options +FollowSymlinks
Options -Indexes
## Mod_rewrite in use.
Options +FollowSymLinks
RewriteEngine On
## Begin - Rewrite rules to block out some common exploits.
# If you experience problems on your site block out the operations listed below
# This attempts to block the most common type of exploit `attempts` to Joomla!
#
# Block out any script trying to base64_encode data within the URL.
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
# Block out any script that includes a <script> tag in URL.
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL.
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL.
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root homepage
RewriteRule .* index.php [F]
#
## End - Rewrite rules to block out some common exploits.
## Begin - Custom redirects
#
# If you need to redirect some pages, or set a canonical non-www to
# www redirect (or vice versa), place that code here. Ensure those
# redirects use the correct RewriteRule syntax and the [R=301,L] flags.
#
## End - Custom redirects
##
# Uncomment following line if your webserver's URL
# is not directly related to physical file paths.
# Update Your Joomla! Directory (just / for root).
##
# RewriteBase /
## Begin - Joomla! core SEF Section.
#
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
#
# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]
#
## End - Joomla! core SEF Section.
# Anti XSS protection
but hackers are still able to inject compromised code to our php files and upload compromised PHP files to our root directory of every single domain.
Dont know what to do, how to solved it.
thank you for your help, I appreciate it!
(theyre doing it again and again if we get code cleaned)
That's nice but it's wrong. You're combating symptoms while you should address the cause.
Quote:
Originally Posted by ondraasek
Please, can you provide me solution how to fix it?
In short: don't run obsolete software including CMSes, shopping carts, plugins, themes and whatnot. Note this asserts the OS and whatever runs in the network stack was properly hardened, always kept up to date, regularly backed up and audited. If it wasn't start with a clean slate and do things the right way.
Usually, what happens is that people set up their computers with an open ssh link, secured (just) by a password, which gets "forced."
(They might also have their stuff hosted on a shared-hosting environment which, believe it or not, doesn't prevent other subscribers peeking at what their home-directories contain!)
The only way to properly secure a box, and to provide access to it, is to use OpenVPN with digital certificates (not "PSKs == passwords"), including "TLS" security which keeps OpenVPN from answering-the-phone to intruders.
You connect the "tunnel," and now you have access to the box. Daemons don't listen to the external interface: they listen only to OpenVPN's virtual one. The only open ports are: HTTP, HTTPS, and an OpenVPN link that isn't answering the phone. Authorized users can access the box "as though it were local," perhaps without any challenge at all, whereas everyone else sees a smooth, impenetrable wall.
Usually, what happens is that people set up their computers with an open ssh link, secured (just) by a password, which gets "forced."
(They might also have their stuff hosted on a shared-hosting environment which, believe it or not, doesn't prevent other subscribers peeking at what their home-directories contain!)
The only way to properly secure a box, and to provide access to it, is to use OpenVPN with digital certificates (not "PSKs == passwords"), including "TLS" security which keeps OpenVPN from answering-the-phone to intruders.
You connect the "tunnel," and now you have access to the box. Daemons don't listen to the external interface: they listen only to OpenVPN's virtual one. The only open ports are: HTTP, HTTPS, and an OpenVPN link that isn't answering the phone. Authorized users can access the box "as though it were local," perhaps without any challenge at all, whereas everyone else sees a smooth, impenetrable wall.
And what about if I put to hosts.deny:
Quote:
SSHD: ALL
and allowed in hosts.allow only specific IP for ssh access?
I would not be surprised if there's a security hole in Joomla or some other CMS. Having worked extensively with a Joomla project, I know that it commonly requires that apache can write certain directories and/or files in the web root. If you've used any plugins or components written by third parties, there's a better-than-fair chance that one of them didn't properly screen user input and this enabled attackers to modify the source of one or more of your PHP files.
If this machine is a VPS, I sincerely hope that you have a snapshot of the server when it was "clean" -- i.e., before the source code was compromised. This might enable you to get your site back up more quickly but not before you patch the hole in your stack. You should definitely take this machine offline until you are sure it doesn't present a hazard to others. Until you do, you are part of the problem.
If you have apache logs from the time it was compromised, these might provide insight into how it was compromised. If they compromise was effected by some other attack vector, you might need other log files. Some examination of log files can be very helpful in locating the security hole that allowed this attack.
I would say that it goes without saying that someone has engineered a doorway into your system which they can open "at will," and which gives them carte blanche access. They've probably monkeyed with the log-generation processes so that they don't leave evidence of what they're doing.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.