Server idarə edirsinizsə, qarşılaşmaq istəməyəcəyiniz şeylərdən biri ilə rastlaşdım: saytlarımdan birinin daxilində phishing məqsədilə hazırlanmış saxta giriş səhifəsi var idi.

Ağlıma gələn ilk sual çox sadə idi:

Görəsən, nə qədər irəli gedə biliblər?

Zərərli bir fayl tapanda insan istər-istəməz ən pis ssenariləri düşünür. Root giriş əldə olunub? Verilənlər bazasına çatılıb? Eyni serverdəki digər saytlar da təhlükədədir?

Amma bu hadisəni araşdırarkən öyrəndiyim ən vacib şeylərdən biri bu oldu:

Serverdə phishing səhifəsinin olması sadəcə kiminsə olmamalı olduğu bir yerə fayl yaza bildiyini sübut edir.

Bu, əlbəttə, ciddi məsələdir.

Amma təkbaşına bütün serverin ələ keçirildiyi mənasına gəlmir.

Əsas məsələ bundan sonra nə baş verdiyini anlamaqdır.

İlk etdiyim şey faylı silmək olmadı

Zərərli fayl görəndə ilk refleks onu dərhal silmək olur.

Mən bunu etmədim.

Çünki faylı silmək görünən problemi aradan qaldıra bilər, amma eyni zamanda əlinizdə olan ən dəyərli sübutlardan birini də yox edə bilər.

Ona görə əvvəlcə həmin hissəni izolə etdim və şübhəli faylın bir nüsxəsini istifadəçilərin çata bilməyəcəyi təhlükəsiz yerə köçürdüm.

Məsələn:

SITE_ROOT="/srv/www/example-site"
CASE_DIR="/root/ir-case"
SUSPECT="$SITE_ROOT/path/to/suspect-file"

sudo install -d -m 0700 -- "$CASE_DIR"
sudo cp -a -- "$SUSPECT" "$CASE_DIR/"
sudo sha256sum -- "$CASE_DIR/$(basename "$SUSPECT")"
file -- "$CASE_DIR/$(basename "$SUSPECT")"

Buradakı yollar sadəcə nümunədir.

Real server yollarını, istifadəçi adlarını, IP ünvanlarını və xam log məlumatlarını paylaşmıram.

Mənim üçün düzgün ardıcıllıq belə oldu:

Əvvəl izolə et. Sonra sübutu qoru. Daha sonra araşdır.

Faylı işlətmədim və brauzerdə açıb “görüm nədir” deyə yoxlamağa da çalışmadım.

Bir şeyi də nəzərə almaq lazımdır: faylın timestamp məlumatı sadəcə ipucudur, sübut deyil. Kopyalanmış və ya dəyişdirilmiş faylların tarixləri sizi yanlış istiqamətə apara bilər.

Ona görə yalnız faylın özünə yox, digər mənbələrə də baxmağa başladım.

Hekayəni loglar danışmağa başladı

İşin maraqlı hissəsi burada başladı.

Şübhəli faylın ortaya çıxdığı vaxt ətrafında authentication məlumatlarını, fayl transferi loglarını və web sorğularını bir-biri ilə müqayisə etməyə başladım.

Systemd istifadə edən Linux serverdə SSH hərəkətlərinə, məsələn, belə baxmaq olar:

sudo journalctl --since "24 hours ago" -u sshd --no-pager
sudo last -ai | head -50

Bəzi sistemlərdə servis adı sshd yox, ssh ola bilər.

Daha sonra fayl transfer servisinin loglarına baxdım və onları saytın access logları ilə müqayisə etdim.

Məsələn:

WEB_LOG="/var/log/example-web/access.log"

sudo grep -hE '"(GET|POST|PUT) ' "$WEB_LOG"

Məqsədim ekrana minlərlə log sətri çıxarmaq deyildi.

Üç şeyi anlamağa çalışırdım:

  1. İlk şübhəli dəyişiklik nə vaxt baş verib?

  2. Ondan əvvəl uğurlu login və ya fayl transferi olub?

  3. Phishing səhifəsi yükləndikdən sonra nə baş verib?

Bu fərq vacibdir.

Zərərli fayl sizə nəyin mövcud olduğunu göstərir.

Loglar isə oraya necə gəldiyini izah etməyə başlaya bilər.

Bunlar eyni sual deyil.

Bir zərərli fayl tapmaq kifayət etmirdi

Təxmini zaman xəttini qurduqdan sonra növbəti sual ortaya çıxdı:

Bu phishing səhifəsi hadisənin hamısı idi, yoxsa sadəcə görünən hissəsi?

Bunu anlamaq üçün yaxın zamanda dəyişdirilmiş fayllara baxdım:

sudo find "$SITE_ROOT" -type f -mtime -2 \
  -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

PHP fayllarında tez-tez şübhəli hesab edilən bəzi pattern-ləri də axtardım:

sudo grep -RInE \
  'eval[[:space:]]*\(|base64_decode[[:space:]]*\(' \
  "$SITE_ROOT" \
  --include='*.php'

Bunlar ilkin yoxlama üçün faydalıdır.

Amma vacib bir məqam var.

Faylda eval() və ya base64_decode() olması onun avtomatik şəkildə malware olduğu demək deyil. Normal proqram təminatları da bunlardan istifadə edə bilər.

Eyni zamanda hücum edən tərəfin zərərli kodu məhz bu qədər açıq pattern-lərlə yazacağına da zəmanət yoxdur.

Ona görə tapılan nəticələrə “bu zərərlidir” kimi yox, ipucu kimi yanaşdım.

Hadisə boyu mənə ən çox kömək edən yanaşma da bu idi:

Təhlükəsizlik alətləri sizə dəlil verir. Sehrli “bəli” və ya “xeyr” cavabı vermir.

Ən vacib məsələ icazələr idi

Bu hadisədən çıxardığım ən böyük dərslərdən biri də budur.

Bir hesabın və ya publishing mexanizminin saytın içərisinə fayl yaza bildiyini gördükdən sonra artıq yalnız həmin fayla fokuslanmadım.

Özümə bu sualı verdim:

Eyni hesab başqa nələrə çata bilirdi?

Application config fayllarını oxuya bilirdi?

Database şifrələrini görə bilirdi?

Başqa saytların fayllarına daxil ola bilirdi?

SSH key-lərə çıxışı var idi?

Scheduled task yarada bilirdi?

Mail credential-larına və ya API token-larına çata bilirdi?

Bu scope-u anlamaq üçün timer-lara və işləyən process-lərə də baxdım:

sudo systemctl list-timers --all
sudo ps auxf

Bundan əlavə application admin hesablarını, SSH key-ləri, database girişlərini, scheduled job-ları, fayl icazələrini və həmin hesabın çata bildiyi digər sahələri yoxladım.

Məncə incident araşdırmalarında ən asan səhvlərdən biri burada edilir.

phishing.php faylını tapıb silmək insana rahatlıq verir.

Ortada konkret problem var və siz onu aradan qaldırırsınız.

Amma əsl təhlükəsizlik sərhədi çox vaxt həmin fayl deyil.

Əsl sərhəd həmin hesabın sahib olduğu icazələrdir.

Əgər o hesab beş fərqli gizli məlumata çata bilirsə, həmin beş məlumatı da hadisənin scope-u daxilində qiymətləndirmək lazımdır.

Şifrələri panika ilə yox, çıxış imkanlarına görə dəyişdim

Başqa bir öyrəndiyim şey də bu oldu:

“Dərhal bütün şifrələri dəyiş” məsləhəti ümumilikdə pis deyil, amma çox qeyri-dəqiqdir.

Credential-ları real olaraq hansı məlumatların exposed ola biləcəyinə görə dəyişmək daha doğrudur.

İlk olaraq təsirlənmiş publishing hesabının şifrəsini dəyişdim.

Amma bunun üçün belə əvvəlcə hesabın hansı növ hesab olduğunu anlamaq lazımdır.

Local Linux user-dır?

Virtual FTP user-dır?

Hosting panel üzərindən idarə olunan hesabdır?

Bunların şifrə dəyişmə prosesi eyni olmaya bilər.

Linux-da passwd işlətmək sistemdə mövcud olan bütün FTP istifadəçilərinin şifrəsini avtomatik dəyişmir.

Daha sonra həmin hesabın oxuya bildiyi və ya oxuya bilmiş ola biləcəyi digər məlumatları da yenilədim:

  • application admin hesabları

  • database şifrələri

  • mail credential-ları

  • API token-ları

  • başqa yerdə də istifadə edilən eyni şifrələr

  • mümkün olduqda aktiv session və token-lar

Bu hadisə credential isolation məsələsinin nə qədər vacib olduğunu mənə bir daha göstərdi.

Əgər bir-biri ilə əlaqəsi olmayan iki sistem eyni şifrəni istifadə edirsə və ya bir account ehtiyacı olmadığı halda başqa sistemlərə də çıxış əldə edirsə, kiçik bir təhlükəsizlik problemi birdən-birə çox böyük scope-a çevrilə bilər.

Əsl həll növbəti upload-u daha az təhlükəli etmək idi

Hadisəni təmizləmək işin yalnız yarısı idi.

Phishing faylını silib “ümid edirəm bir daha olmaz” demək istəmirdim.

Eyni şey təkrar baş versə belə, hücumçunun əldə etdiyi hesabın mümkün qədər az işə yararlı olmasını istəyirdim.

Upload və ya static-content qovluqları üçün ən güclü tədbirlərdən biri əslində çox sadədir:

Həqiqətən ehtiyac yoxdursa, həmin qovluqlarda script işləməməlidir.

Üstəlik bu qaydanın mümkün qədər publishing account-un özünün dəyişə bilməyəcəyi server konfiqurasiyasında saxlanılması daha yaxşıdır.

Web server konfiqurasiyasında dəyişiklik etdikdən sonra reload etməzdən əvvəl onu yoxlamaq da vacibdir:

nginx -t

və ya:

apachectl configtest

Publishing hesabının icazələrini də azaltdım.

Əgər bir account yalnız bir sayta fayl yükləmək üçündürsə, başqa saytların qovluqlarına, shell-ə, database-ə, mail sisteminə və cron işlərinə girişinin çox da mənası yoxdur.

Yazanda bu olduqca aşkar görünür.

Amma oğurlanmış bir credential-ın hara qədər gedə bildiyini bir-bir yoxlamaq məcburiyyətində qalanda bu məsələ daha aydın hiss olunur.

SFTP oğurlanmış şifrə problemini həll etmir

Bu hadisə başqa bir vacib fərqi də mənə yenidən xatırlatdı.

FTP əvəzinə SFTP və ya FTPS istifadə etmək əlbəttə daha yaxşıdır.

Çünki connection və credential-ları ötürülmə zamanı qoruyur.

Amma hücumçunun əlində artıq doğru username və password varsa, bu sizi xilas etmir.

Hücumçuda etibarlı credential varsa, SFTP onun bağlantısını da çox gözəl şəkildə şifrələyəcək.

Yəni transport security və account security fərqli problemləri həll edir.

Mümkün olduqda mən artıq bunları birlikdə düşünürəm:

  • unikal şifrələr

  • MFA

  • minimum icazə

  • sayt qovluqlarının bir-birindən ayrılması

  • upload qovluqlarında script execution-un söndürülməsi

  • idarəetmə girişində IP restriction və ya VPN

  • gözlənilməz fayl dəyişiklikləri üçün monitoring

Bunların heç biri təkbaşına möcüzə deyil.

Amma birlikdə istifadə olunanda bir oğurlanmış hesabın yarada biləcəyi zərəri ciddi şəkildə azaldırlar.

Təmiz malware scan “heç nə olmayıb” demək deyil

Incident zamanı edilə biləcək ən təhlükəli nəticələrdən biri budur:

“Scanner başqa heç nə tapmadı, deməli sistem təmizdir.”

Scanner sizə nə tapdığını deyə bilər.

Amma görmədiyi heç bir şeyin olmadığını sübut edə bilməz.

Eyni şey loglara da aiddir.

Bir servisin logunda şübhəli hərəkət görməmək həmin hərəkətin başqa servisdə baş vermədiyini və ya logların artıq rotate olunmadığını sübut etmir.

Ona görə mən hadisəni “infected / clean” kimi ikili şəkildə düşünmək əvəzinə scope, yəni əhatə dairəsi üzərindən qiymətləndirməyə başladım.

Təsirlənən account nələrə çata bilirdi?

Bu çıxışların həqiqətən istifadə edildiyini göstərən hansı sübutlar var idi?

Əlimdə olan məlumatla hansı hissələri dəqiq bilə bilmirdim?

Bu suallar sonsuz şəkildə yaşıl “clean” işarəsi axtarmaqdan daha faydalı oldu.

Sistemi yalnız nə baş verdiyini anladıqdan sonra bərpa etdim

Ehtimal olunan giriş yolunu və hadisənin scope-unu anladıqdan sonra recovery mərhələsinə keçdim.

Təsirlənmiş faylları known-good mənbədən bərpa etdim, lazım olan update-ləri etdim, icazələri azaltdım, risk altında ola biləcək credential-ları dəyişdim və bundan sonra authentication, web, transfer, file-change və outbound traffic loglarını izləməyə davam etdim.

Backup-ların da eyni publishing account tərəfindən dəyişdirilə bilmədiyinə əmin oldum.

Çünki hücumçunun canlı saytla birlikdə dəyişə bildiyi backup, çox da backup sayılmaz.

Bir də backup-ın həqiqətən restore oluna bildiyini test etmək lazımdır.

“Backup-ımız var.”

ilə

“Bu serveri həmin backup-dan bərpa edə bilirik.”

eyni şey deyil.

Bunu incident baş verməmişdən əvvəl bilmək daha yaxşıdır.

Bu gün eyni hadisə baş versə verəcəyim ilk üç sual

Bu gün yenidən eyni tip phishing səhifəsi tapsam, artıq ilk sualım belə olmazdı:

“Bütün serveri hack ediblər?”

Bunun yerinə üç daha faydalı sual verərdim:

Nə yüklənib?

Bu faylı yükləyən hesab başqa haralara çata bilirdi?

Hücumçunun bu çıxışdan daha irəli getdiyini göstərən hansı sübutlar var?

Bu yanaşma hadisəni başa düşməyi çox asanlaşdırdı.

Phishing səhifəsi sadəcə görünən simptom idi.

Əsl araşdırma giriş imkanları, icazələr və sübutlar haqqında idi.

Əsl həll də sadəcə zərərli bir faylı silmək deyildi.

Növbəti dəfə hansısa credential oğurlansa, həmin hesabın əvvəlki qədər güclü olmamasını təmin etmək idi.