Елементарно Уотсън

sed -n '/^-- Current Database: `dbname`/,/^-- Current Database: `/p' AllDatabases.sql > mydb.sql

Заменете dbname с името на базата данни, която искате да извадите от архива и “магически” тя ще се озове във файла mydb.sql

wget http://downloads2.ioncube.com/loader_downloads/ioncube_loaders_lin_x86-64.tar.gz .

2. Разархивираме

tar -xvf ioncube_loaders_lin_x86-64.tar.gz

3. Така получената директория с име ioncube местим на по-подходящо място:

mv ioncube /usr/local/

4. Създаваме файл с описание за ioncibe extension-a

nano /etc/php5/conf.d/ioncube.ini

и в него пишем следният ред:

zend_extension = /usr/local/ioncube/ioncube_loader_lin_5.3.so

5. Рестартираме Apache и сме готови

/etc/init.d/apache2 restart

Както пише на сайта, Leading Speakers Include:

$.fn.preload = function() {
    this.each(function(){
        $('<img/>')[0].src = this;
    });
}
 
$(['img1.jpg','img2.jpg','img3.jpg']).preload();

For simple JavaScript use:

function preload(arrayOfImages) {
    $(arrayOfImages).each(function(){
        $('<img/>')[0].src = this;
    });
}
 
preload([
    'img/1.jpg',
    'img/2.png',
    'img/3.gif'
]);

За целта използваме командата “pdfimages“, но първо трябва да инсталираме това:

apt-get install poppler-utils

Нека нашият PDF файл се казва test.pdf. За да изкараме картинките от него, използваме следната команда:

pdfimages -j test.pdf img

Това ще извади всички картинки от PDF файла като .jpg с префикс “img”. Пример: img-001.jpg, img-002.jpg

При поредната проверка на пощата ми, чета писмо от datacenter-a, в който се намира една от машините ми. Там пишеше, че ако до няколко часа не разреша проблема с машината, тя ще бъде спряна. По-долу беше обяснено, че от нея има изключително много изходящи конекции, които flood-ят суича, към който е вързана машината.

И така, започна се…

В началото трябваше да намеря кой точно е процеса, предизвикващ въпросните конекции. Използвах ps auxw за да разгледам процесите, които в момента се изпълняваха на машината. На пръв поглед нямаше нищо необичайно – ftp, mysql, apache, ssh и още купчина други, с които няма да ви губя времето.
Но един от тях ми привлече вниманието, а именно /usr/local/apache2/bin/httpd. Нищо необичайно, нали? Всъщност проблема е, че моето apache се намира в друга директория… Ето и заподозреният

От тук нататък ще използвам прякорът “сивчо” за да не разкривам все пак за кой сайт става въпрос

Забелязах, че въпросният процес се изпълнява с потребител “сивчо“. Това означаваше точно две неща:
1. Машината ми не е root-ната. Тоест, мога да си я използвам без да е наложителна преинсталация.
2. Някой, някак е успял да хакне акаунта на “сивчо” – лесна парола или остарял РНР скрипт.

Първото ме успокои… пфу!

Започнах да разследвам “сивчо” и да видя какво е правил в последно време, но преди това заключих цялата му директория за всеки случай:

chmod 0 /home/сивчо

Използвах командата

find /home/сивчо/public_html -mtime -30 -o -ctime -30 -ls

за да разбера кои файлове е променял в последните 30 дни. Тук ударих на камък – няма нито 1 променен файл. Това означаваше, че скрипта не е писал по файлове, принадлежащи на “сивчо“… пълна мистерия…

Видях кой е Process ID на въпросния скрипт и отидох да го поразгледам. Нека кажем, че PID е 2012.
Влязох в директорията на процеса:

cd /proc/2012/

Исках да разбера, кой всъщност е файла, който се изпълнява зад този процес. А именно, на къде сочи exe файла. В случея – към root директорията “/“. Пак удрям на камък.
Исках да видя коя команда е използвана за да се стартира процеса, като погледа съдържанието на cmdline файла, но и той беше празен. Камък.
Погледнах в директорията fd, за да видя по кой файлове пише и чете процеса. Там имаше само сокети и apache error log файла. Това ме наведе на мисълта, че може би щях да мога да видя кои други файлове са се стартирали от потребител “сивчо” и евентуално да разбера точно в кой РНР файл е дупката за да я оправя или да предупредя клиента. Нямаше нищо. Погледнах и в лога на suPHP, но и там беше празно.

Отидох в /tmp/ директорията, която също се използваше от процеса. Там видях доста (десетина) скрити директории, принадлежащи на потребител “сивчо” и един странен .tgz файл, който при опит да разкомпресирам върна греша. Предположих, че това е самият “вирус”.

От тук нататък, изчерпан от идеи, реших да не се занимавам с ходене по следи от трохи, а просто да реша проблема. Убих процесите и изтрих скритите файлове и директории на “сивчо”. Това реши проблема, надявам се за постоянно. Все пак погледнах в /var/spool/cron/ да не би случайно там да има рестариращ процеса скрипт, но всичко беше наред.

Заключението ми е, че може би сам съм пренесал вируса от друг сървър при смяната на машините, която се случи преди известно време.

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

Демонстрация:

blagomir@firefly:~$ netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
      1 173.194.34.73
      3 64.34.119.101

Цифрата е броя отворени конекции последвана от IP адреса.

Редактираме nginx.conf, който ако сте инсталирали nginx от package management system се намира тук: /etc/nginx/nginx.conf

server {
 
   listen   443;
 
   ssl    on;
   ssl_certificate    /etc/ssl/certificate.crt; (или .pem)
   ssl_certificate_key    /etc/ssl/certificate.key;
 
   server_name bgtechblog.com;
   location / {
	root   /home/bgtechblog.com/root/;
	index  index.html;
   }
 
}

Последната стъпка е да рестартираме nginx за да приеме новите промени:

/etc/init.d/nginx restart

Лесно, нали?