Имало едно време, една хакната машина…

Звучи като приказка, нали? Всъщност е реална история за това как трябваше да открия и да изтрия гаден “вирус” от един сървър.

При поредната проверка на пощата ми, чета писмо от 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/ да не би случайно там да има рестариращ процеса скрипт, но всичко беше наред.

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