Script to replace index file when hacked

[adapter]

Hi

i am looking a script that will restore frm the weekly backup the index file and will replace it for all the sites in the /home someone can share it?

thank u

[Creazioni]

hi
i find this

pico /scrpts/nameyouwant



#!/usr/bin/perl

#version 2

my $hasiozlib = 0;
my $hasarchivetar = 0;
eval {
require IO::Zlib;
$hasiozlib = 1;
};
eval {
require Archive::Tar;
$hasarchivetar = 1;
};

if (!($hasiozlib) || !($hasarchivetar)) {
system("/scripts/perlinstaller","IO::Zlib","Archive::Tar");
die "Please re-run this script. Modules were missing!\n";
}

use strict;

my $dir = '/backup/cpbackup/weekly';

opendir(CPB,$dir);
my @FS = readdir(CPB);
@FS = grep(/\.tar\.gz$/, @FS);
closedir(CPB);
my $restorecount = 0;

foreach my $fs (@FS) {
$fs =~ s/\.tar\.gz//g;

next if (!getpwnam($fs));
my $homedir = (getpwnam($fs))[7];
my $uid = (getpwnam($fs))[2];
my $gid = (getpwnam($fs))[3];


print "$fs $homedir\n";
my $tar = Archive::Tar->new;
$tar->read("$dir/${fs}.tar.gz",1);


print "Checking Archive for files!\n";
my @files = $tar->get_files("${fs}/homedir/public_html/index.html",
"${fs}/homedir/public_html/index.htm","${fs}/homedir/public_html/index.php");

foreach my $ft (@files) {
my $filename = $ft->name();
if ($filename =~ /index.html$/) {
open(RESTOREFILE,">${homedir}/public_html/index.html");
chown $uid, $gid, "${homedir}/public_html/index.html";
}
if ($filename =~ /index.htm$/) {
open(RESTOREFILE,">${homedir}/public_html/index.htm");
chown $uid, $gid, "${homedir}/public_html/index.htm";
}
if ($filename =~ /index.php$/) {
open(RESTOREFILE,">${homedir}/public_html/index.php");
chown $uid, $gid, "${homedir}/public_html/index.php";
}
print "Restoring $filename\n";
print RESTOREFILE $ft->get_content();
close(RESTOREFILE);
$restorecount++;

}
}

print "$restorecount file(s) restored!\n";






chmod 755 nameyouwant


./nameyouwant



HEY!! read before to use, read script and choose directory
problem: this is only for index into public_html and not ( ) for all index (subdir)
I hope someone find solution for subdir

Bye

[sleuth1]

Thanks for that script very useful

Another one needed is this

one that will grep " hacked text" and rm -f .hackedtext.file this should go through all directories , including .suspended page . index.html , if some one has done this successfully please publish


Another one is a script or command block, that will prevent mass changing of .index html , or at least send an alert for the this action (not sure if this is possible or not)

Also anyone have any useful methods of preserving the backup pages from defacement , this happened to me and is a real pain (for instance is it possible to make /hdb/backup read only until a restore is needed and associated commands . Thanks very much.

[adapter]

Also anyone have any useful methods of preserving the backup pages from defacement , this happened to me and is a real pain

really u got the tar.gz file hacked?

[fusioncroc]

Well if your needing a script to reguarly replace defaced pages i think you need to look in to stopping them getting defaced in the first place

[sleuth1]

Hi adapter , no they were not in compressed format, but yes they will be from now on, overlooked that simple and obvious solution .

[sleuth1]

Well if your needing a script to reguarly replace defaced pages i think you need to look in to stopping them getting defaced in the first place

No only once, and once is far too many times , scripts detailed above may be useful to others who WILL suffer the same fate , also unless you have something useful to add of a practical nature related to this thread , smug , superior comments are of no value whatso ever .

Also since said attack logged 6 attempts to repeat the damage all blocked by tweaked mod_secuirity , which everyone should have installed , the fact that attacks are continuing leads to the conclusion that it may happen again , and if it did would like to be better prepared next time.

[wzd]

Hi Guys,

Found this thread with some searching and wanted to follow up - Any luck on this?
It would be nice if cPanel could integrate something like this for additional security precuations:

a) Content change notification service - If the index page of a site is changed a notification email is sent out to the contact person and server notification -

b) Maybe insert a "magic cookie" into the header of each site automatically - If a site is defaced this comment line will not be there. The account can then be suspended to prevent further damage?

c) Maybe use configserver LFD in conjunction with this?

I've seen some providers do offer this service as uptime / hack service but would be nice to integrate into Cpanel.

Any luck on the script that was being made?

Thanks

[cPanelDavidG]

Hi Guys,

Found this thread with some searching and wanted to follow up - Any luck on this?
It would be nice if cPanel could integrate something like this for additional security precuations:

a) Content change notification service - If the index page of a site is changed a notification email is sent out to the contact person and server notification -

b) Maybe insert a "magic cookie" into the header of each site automatically - If a site is defaced this comment line will not be there. The account can then be suspended to prevent further damage?

c) Maybe use configserver LFD in conjunction with this?

I've seen some providers do offer this service as uptime / hack service but would be nice to integrate into Cpanel.

Any luck on the script that was being made?

Thanks

Those are some very nifty suggestions. Since you would better be able to provide any needed clarification about this to our developers than I would, you may want to submit an official feature request for this at http://bugzilla.cpanel.net

[wzd]

Thanks David,

I've opened the bug here http://bugzilla.cpanel.net/show_bug.cgi?id=6229

In the meantime i'll post back here with some ideas on internal security policies that cPanel could implement and i hope everyone else can contribute

[madan.cpanelnet]

Adapter,


Here is that script ( USE it at your own risk , read, understand)



root@maui [/backup/12345]# cat /root/x
#!/bin/bash
mkdir /backup/12345/, cd /backup/12345/
user="whatchat"

tar -tvzf /backup/cpbackup/weekly/$user.tar.gz | grep index.php |awk {'print $6'} > index.txt


for extract in `cat index.txt`
do
tar -xzf /backup/cpbackup/weekly/$user.tar.gz $extract
done


mv $user/homedir/ /backup/12345/
rm -fr /backup/12345/$user
mv /backup/12345/homedir /backup/12345/$user
rsync -vrplogDtH /backup/12345/$user/ /home/$user/

chmod 711 /home/$user ; chown $user.$user /home/$user
chmod 710 /home/$user/public_html ; chown $user.nobody /home/$user/public_html
rm -fr $user
echo " ################ index.php's copie for $user ############"
root@maui [/backup/12345]#


=============

cat /etc/trueuserdomains | awk {'print $2}'

will give the list of usernames on your server... each time replace the username in /root/x in the variable user=""


you can automate this too.

[testtubebaby]

kool thanks

[wzd]

I've read through the script and tried to understand it but what are the criteria for replacing the current index file with the one from the backup ???

[testtubebaby]

say.. only index files are hacked or injected with malicios code or iframes. you can replace index.php to index.htm to copy html files.

[cPanelKenneth]

b) Maybe insert a "magic cookie" into the header of each site automatically - If a site is defaced this comment line will not be there. The account can then be suspended to prevent further damage?

What is the criteria of setting the cookie? i.e. How does the cookie setter determine a site was defaced?

If the cookie is set statically, as part of the file itself, once the defacers know about this, it's a simple mater to handle.

If it is set dynamically, for example as part of some hypothetical mod_defacement Apache module, by what criteria would such functionality determine the site was defaced?


Also, depending upon many factors, modification of user-owned files/content might be illegal in some jurisdictions, even if explicitly agreed to in TOS/AUP. Hence, such "magic cookie" tool might be dependent upon a user knowingly enabling the tool/inserting the cookie.