Təhlükəsizlik hadisəsi haqqında oxumaqla, həqiqətən idarə etdiyiniz canlı serverdə belə bir hadisənin içində qalmaq arasında böyük fərq var.

Yaxın zamanda Linux üzərində işləyən, web server, idarəetmə paneli və WordPress saxlayan bir sistemdə baş vermiş təhlükəsizlik pozuntusunu araşdırmalı və sistemi yenidən təhlükəsiz vəziyyətə gətirməli oldum.

Burada qəsdən xüsusi infrastruktur detallarını, hücumçunun istifadə etdiyi metodların bütün incəliklərini və ya həssas müdaxilə addımlarını paylaşmıram. Bu yazı exploit təlimatı deyil.

Məqsədim daha çox developerlərə, sistem administratorlarına və sayt sahiblərinə sistemdə nəyinsə qaydasında olmadığını hiss etdikləri anda daha düzgün qərar verməyə kömək etməkdir.

Xüsusilə də ilk əlamətlər qarışıq, natamam və ya aldadıcı görünəndə.

Bu prosesdən çıxardığım ən vacib nəticələrdən biri çox sadə idi:

Ən çox gözə çarpan problem həmişə hücumun başladığı yer olmur.

Real bir hadisədə ilk əlamət qəribə login yönləndirməsi ola bilər.

Tanımadığınız admin hesabı görə bilərsiniz.

Giriş davranışında dəyişiklik ola bilər.

Loglarda qəribə hərəkətlər görünə bilər.

Amma yalnız ilk gördüyünüz problemə fokuslansanız, daha böyük mənzərəni qaçıra bilərsiniz.

Bu yazıda daha təhlükəsiz və praktik bir incident response yanaşmasından danışacağam.

1. Əvvəlcə Dayanın və Sübutları Qoruyun

Təhlükəsizlik hadisəsi zamanı ən asan edilən səhvlərdən biri təmizliyə çox tez başlamaqdır.

Şübhəli faylları dərhal silmək, servisləri söndürmək və ya nə baş verdiyini anlamadan köhnə backup-a qayıtmaq ilk baxışda məntiqli görünə bilər.

Amma bunu etdikdə hadisənin necə baş verdiyini anlamağa kömək edən sübutları da silə bilərsiniz.

İlk mərhələdə əsas məqsədiniz:

“Hər şeyi dərhal düzəltmək” olmamalıdır.

Əvvəlcə:

  • problemi məhdudlaşdırın,

  • davam edən riski azaldın,

  • sübutları qoruyun,

  • hadisənin nə qədər yayıldığını anlamağa çalışın,

  • sonra sistemi təmiz şəkildə bərpa edin.

İlk mərhələdə edilə biləcək yaxşı addımlar

  • Səlahiyyətli hesabların şifrələrini dəyişin

  • Mümkündürsə aktiv sessiyaları bağlayın

  • Admin girişini müvəqqəti məhdudlaşdırın

  • Hadisələrin vaxtını qeyd edin

  • Log rotation baş verməzdən əvvəl logların surətini çıxarın

  • Şübhəli faylları sənədləşdirmədən silməyin

Məsələn:

# Son təhlükəsizlik loglarını təhlükəsiz yerə kopyala
cp /var/log/secure /root/incident-secure.log
cp /var/log/messages /root/incident-messages.log

# Web server loglarını arxivlə
tar -czf /root/web-logs-backup.tar.gz /var/log/nginx /var/log/httpd 2>/dev/null

Sizin sistemdə yollar fərqli ola bilər.

Amma məntiq dəyişmir:

Əvvəl qoruyun, sonra təmizləyin.

2. Həqiqətən Təhlükəsizlik Pozuntusu Baş Veribmi, Onu Yoxlayın

Hər qəribə davranış sistemin hack edildiyi demək deyil.

Bəzən plugin konflikti, səhv redirect qaydası, vaxtı keçmiş token və ya bot trafiki olduqca qorxulu görünə bilər.

Amma müəyyən əlamətlər varsa məsələyə daha ciddi yanaşmaq lazımdır:

  • gözlənilməyən admin giriş yolları

  • tanımadığınız istifadəçi hesabları

  • naməlum cron job-lar

  • dəyişdirilmiş core faylları

  • webshell-ə oxşayan PHP faylları

  • şübhəli xarici bağlantılar

  • mövcud konfiqurasiyaya uyğun gəlməyən login davranışı

  • sizin icazəniz olmadan dəyişdirilmiş təhlükəsizlik parametrləri

Yoxlanılmalı yerlər

  • web server access logları

  • error logları

  • authentication logları

  • cron qovluqları

  • startup servisləri

  • WordPress istifadəçiləri və plugin-lər

  • yaxın zamanda dəyişdirilmiş fayllar

Məsələn:

# Web root daxilində son 7 gündə dəyişən fayllar
find /var/www/html -type f -mtime -7 | less

# Şübhəli PHP pattern-lərini axtar
grep -RInE "base64_decode|eval\(|shell_exec|assert\(|gzinflate" /var/www/html 2>/dev/null

Bu əmrlərin nəticə verməsi təkbaşına sistemin hack olunduğunu sübut etmir.

Amma ilkin araşdırma üçün çox faydalıdır.

3. Problemin Tək Bir Qatda Olduğunu Düşünməyin

Ən çox edilən səhvlərdən biri budur:

Problem sadəcə WordPress-dədir.

Bəzən doğrudan da belə olur.

Amma həmişə yox.

Bir sayt pozulduqda sistemi qat-qat düşünmək daha sağlam yanaşmadır:

  • tətbiq qatı: WordPress, tema, plugin-lər, uploads

  • web server qatı: Nginx, Apache, redirect və proxy qaydaları

  • əməliyyat sistemi qatı: istifadəçilər, servislər, cron, SSH açarları, firewall

  • idarəetmə paneli / hosting qatı: panel girişi, hesablar, vhost konfiqurasiyası

  • credential qatı: təkrar istifadə olunan şifrələr, sızmış secret-lər, API token-ləri

Bu yanaşma vacibdir.

Çünki hücumçu bir qatdan sistemə girib, qalıcı giriş nöqtəsini tamam başqa qatda yarada bilər.

4. Dərin Təmizliyə Başlamazdan Əvvəl Girişi Məhdudlaşdırın

Sistem hələ internetə açıqdırsa, siz araşdırma apararkən idarəetmə interfeyslərini əvvəlki kimi açıq saxlamaq yaxşı fikir deyil.

Müvəqqəti olaraq bunları edə bilərsiniz:

  • admin yollarını IP ilə məhdudlaşdırmaq

  • lazımsız remote access-i bağlamaq

  • daha güclü authentication istifadə etmək

  • istifadə olunmayan servisləri söndürmək

  • həssas panelləri VPN və ya private network arxasına keçirmək

  • riskli birbaşa giriş yollarını bloklamaq

Məsələn, müvəqqəti məhdudlaşdırma:

location /admin/ {
    allow 203.0.113.10;
    deny all;
}

Bu sadəcə nümunədir.

Əsas fikir budur:

Hadisəni araşdırarkən əvvəlcə attack surface-i kiçildin.

Mümkündürsə kritik admin interfeyslərini bunların arxasında saxlayın:

  • VPN

  • private tunnel

  • IP allowlist

  • ayrıca admin hostname

  • MFA qoruması

5. WordPress-i Ətraflı Yoxlayın, Amma Orada Dayanmayın

WordPress tərəfində ilk yoxlanılmalı yerlər bunlardır:

WordPress yoxlama siyahısı

  • admin istifadəçiləri

  • plugin-lər

  • temalar

  • uploads qovluğu

  • must-use plugin-lər

  • .htaccess və digər rewrite qaydaları

  • gizli login plugin-ləri

  • cron event-ləri

  • application password-lər

  • REST API davranışı

  • redirect, login yolu və ya inject edilmiş kodla bağlı database setting-ləri

WP-CLI varsa işiniz xeyli asanlaşır:

wp user list
wp plugin list
wp theme list
wp option list --search=siteurl
wp cron event list

WordPress core fayllarını da yoxlamaq lazımdır:

wp core verify-checksums

Checksum yoxlamasının uğursuz olması avtomatik olaraq serverin hack edildiyi demək deyil.

Amma faylların niyə fərqli olduğunu araşdırmaq lazım olduğunu göstərir.

6. Sadəcə Görünən Zərəri Yox, Qalıcı Giriş Nöqtələrini Axtarın

Hücumçılar həmişə görünən zərər buraxmaq istəmir.

Bəzən onlar üçün daha dəyərli olan şey sistemə sonradan yenidən daxil ola bilməkdir.

Ona görə də görünən zərərli faylları təmizləsəniz belə, başqa mexanizm onları yenidən yarada bilər.

Yoxlanılmalı persistence nöqtələri

  • cron job-lar

  • systemd servisləri

  • yeni SSH açarları

  • dəyişdirilmiş startup script-ləri

  • gizli PHP backdoor-ları

  • mu-plugin-lər

  • drop-in faylları

  • executable kod yerləşdirilə bilən yazıla bilən qovluqlar

  • plugin və ya inject edilmiş kodla yaradılmış scheduled task-lar

Bəzi faydalı yoxlamalar:

crontab -l
ls -la /etc/cron.*
systemctl list-unit-files --state=enabled
find ~/.ssh -type f -maxdepth 2 2>/dev/null

WordPress tərəfində isə:

find wp-content/uploads -type f -name "*.php"
find wp-content/mu-plugins -type f

Uploads qovluğunda PHP faylı tapılması avtomatik olaraq onun zərərli olması demək deyil.

Amma mütləq araşdırılmalıdır.

7. Backup-lara Kor-Koranə Güvənməyin

Təhlükəsizlik hadisəsindən sonra ağla gələn ilk şey çox vaxt belə olur:

Köhnə backup-a qayıdaq.

Amma backup-ın köhnə olması onun təmiz olduğu demək deyil.

Backup yalnız hücumun nə vaxt başladığını bildiyiniz və hansı komponentlərin təsirləndiyini müəyyən etdiyiniz halda etibarlı ola bilər.

Əgər hücumçu sistemdə uzun müddətdir mövcud olubsa, backup-la birlikdə bunları da geri qaytara bilərsiniz:

  • yoluxmuş fayllar

  • dəyişdirilmiş konfiqurasiya

  • backdoor olan plugin-lər

  • zərərli istifadəçi hesabları

  • dəyişdirilmiş database məlumatları

Daha düzgün bərpa yanaşması

Backup bərpa etməzdən əvvəl:

  1. hadisənin təxminən nə vaxt başladığını müəyyən edin

  2. hansı fayl və setting-lərin dəyişdiyini tapın

  3. bir neçə backup nöqtəsini müqayisə edin

  4. backup-ı production-a qaytarmamışdan əvvəl yoxlayın

Mümkündürsə backup-ı əvvəlcə izolə olunmuş mühitdə test edin.

8. Credential-ları Düzgün Ardıcıllıqla Dəyişin

Şifrə dəyişmək vacibdir.

Amma səhv ardıcıllıqla etsəniz bunun faydası az ola bilər.

Əgər hücumçunun sistemə başqa giriş kanalı qalırsa, sizin dəyişdirdiyiniz şifrələri yenidən sıfırlaya bilər.

Credential dəyişmə prioriteti

  1. root / server administrator girişi

  2. hosting və ya control panel hesabı

  3. SSH açarları və səlahiyyətli istifadəçilər

  4. database şifrələri

  5. WordPress admin hesabları

  6. API key-lər və application password-lər

  7. üçüncü tərəf servis token-ləri

  8. password recovery üçün istifadə olunan e-poçt hesabları

Xüsusilə hosting və ya e-poçt hesabını nəzərdən qaçırmaq ciddi səhv ola bilər.

Hücumçunun həmin hesabların birinə çıxışı varsa, bir çox şeyi yenidən dəyişə bilər.

9. Loglar Düşündüyünüzdən Daha Qiymətlidir

Hadisənin geriyə doğru necə inkişaf etdiyini anlamağın ən yaxşı yollarından biri loglardır.

Amma logların da qüsursuz olmadığını unutmaq olmaz.

Natamam ola bilərlər.

Çox səs-küylü ola bilərlər.

Hətta bəzən yanlış istiqamət verə bilərlər.

WordPress saytları hər gün çoxlu bot tərəfindən skan edilir.

404 request-lər gəlir.

Avtomatik vulnerability scanner-lar müxtəlif URL-ləri yoxlayır.

Hər şübhəli request hücumun səbəbi deyil.

Ona görə də tək bir log sətrinə baxmaq əvəzinə müxtəlif mənbələri birləşdirmək lazımdır:

  • access logları

  • error logları

  • auth logları

  • fayl dəyişiklik tarixləri

  • servis restart-ları

  • istifadəçi əməliyyatları

  • plugin və tema dəyişiklikləri

Məqsəd tək bir şübhəli sətrə ilişib qalmaq deyil.

Hadisənin zaman xəttini qurmaqdır.

Loglardan cavab tapmağa çalışmalı olduğunuz suallar

  • İlk təsdiqlənmiş şübhəli hadisə nə vaxt olub?

  • Hansı IP və user-agent-lər digərlərindən fərqlənir?

  • Admin yollarına qeyri-adi giriş olub?

  • Login aktivliyindən dərhal sonra fayl dəyişiklikləri baş verib?

  • Privilege dəyişdirmə cəhdləri olub?

  • Gözlənilməyən xarici bağlantılar yaranıb?

Bu sualların cavablarını birlikdə tapa bilsəniz, hücumun necə işlədiyini daha düzgün anlaya bilərsiniz.

10. Sistemi Sərtləşdirmək Bərpa Prosesinin Bir Hissəsidir

Zərərli faylları təmizləmək işin bitdiyi demək deyil.

Əgər sistemi sonradan sərtləşdirməsəniz, növbəti hücum üçün eyni şəraiti yenidən yarada bilərsiniz.

Hadisədən sonra edilə biləcək hardening addımları

  • WordPress core, plugin və temaları aktual saxlayın

  • istifadə olunmayan plugin və temaları silin

  • yazıla bilən qovluqların sayını azaldın

  • admin girişini məhdudlaşdırın

  • həssas panelləri private access arxasında saxlayın

  • mümkün olan yerlərdə MFA istifadə edin

  • lazımsız servisləri bağlayın

  • firewall qaydalarını yenidən nəzərdən keçirin

  • fayl dəyişikliklərini izləyin

  • logları qorunan və ya mərkəzləşdirilmiş sistemdə saxlayın

  • sənədləşdirilmiş recovery plan hazırlayın

Məsələn, permission-ları yoxlamaq üçün:

find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

Bunu kor-koranə hər serverə tətbiq etmək düzgün deyil. Öz mühitinizə uyğunlaşdırmaq lazımdır.

Amma əsas fikir eynidir:

Daha təhlükəsiz default-lar növbəti hadisənin verə biləcəyi zərəri azaldır.

11. Sadə və Praktik Incident Response Axını

Bu təcrübəni təkrar istifadə edilə bilən bir prosesə çevirməli olsaydım, belə qurardım.

Addım 1 — Təsdiqlə

Problemin həqiqətən mövcud olub-olmadığını və ilk əlamətlərin nə olduğunu müəyyən et.

Addım 2 — Məhdudlaşdır

Admin girişini azaldın, credential-ları dəyişin və sistemin xaricə açıq hissəsini minimuma endirin.

Addım 3 — Sübutları Qoru

Logları, timestamp-ləri, şübhəli faylları və konfiqurasiya surətlərini saxlayın.

Addım 4 — Miqyası Müəyyən Et

Problemin yalnız WordPress-də qalıb-qalmadığını və ya daha aşağı sistem qatlarına yayıldığını yoxlayın.

Addım 5 — Təmizlə

Zərərli faylları, icazəsiz istifadəçiləri, persistence mexanizmlərini və pis konfiqurasiyaları silin.

Addım 6 — Bərpa Et

Yalnız təmiz olduğu təsdiqlənmiş komponentləri geri qaytarın və əsas funksiyaları yenidən test edin.

Addım 7 — Sərtləşdir

Girişi məhdudlaşdırın, proqramları yeniləyin, monitorinqi gücləndirin və baş verən hadisədən çıxan nəticələri sənədləşdirin.

Bu ardıcıllıq panik vəziyyətində verilən yanlış qərarların qarşısını ciddi şəkildə ala bilir.

12. Mənim Üçün Ən Vacib Dərs

Bu hadisədən çıxardığım ən vacib nəticə əslində sırf texniki deyildi.

Daha çox əməliyyat və idarəetmə ilə bağlı idi.

Təhlükəsizlik hadisəsi aşağıdakı hallarda çox daha çətinləşir:

  • sənədləşdirmə zəifdirsə

  • giriş metodları qarışıqdırsa

  • gizli login mexanizmləri sənədləşdirilməyibsə

  • bir neçə təhlükəsizlik qatı bir-birinə gözlənilməz şəkildə təsir edirsə

  • hansı qaydanın hansı davranışı yaratdığını heç kim tam bilmirsə

Ona görə də hətta kiçik sistemlərdə belə bunlar ciddi fərq yaradır:

  • sənədləşdirilmiş access architecture

  • aydın adlandırılmış təhlükəsizlik qatları

  • fövqəladə recovery addımları

  • admin access diaqramları

  • public və private interfeyslərin aydın ayrılması

Yaxşı təhlükəsizlik yalnız hücumçının içəri girməsinin qarşısını almaq deyil.

Bir problem yarananda sistemi müdafiə edən insanın işi nə qədər rahatdırsa, bu da təhlükəsizliyin bir hissəsidir.

Son Düşüncələr

WordPress saytı və ya Linux server idarə edirsinizsə, bir gecədə peşəkar incident responder olmağa ehtiyac yoxdur.

Amma sakit və aydın bir prosesiniz olmalıdır.

Bir şey qaydasında getməyəndə:

  • panik etməyin

  • kor-koranə təmizliyə başlamayın

  • fərziyyələrə güvənməyin

  • sadəcə ən görünən problemə fokuslanmayın

Diqqətlə araşdırın.

Riski erkən məhdudlaşdırın.

Sistemi təmiz şəkildə bərpa edin.

Sonra isə onu daha güclü edin.

Bu yanaşma çox vaxt tək bir təhlükəsizlik proqramından daha faydalı olur.

Sürətli Müdaxilə Siyahısı

Qısa versiyanı saxlamaq istəyənlər üçün:

  • səlahiyyətli hesabların şifrələrini dəyişin

  • admin girişini məhdudlaşdırın

  • logların surətini dərhal çıxarın

  • istifadəçiləri, plugin-ləri, temaları və cron job-ları yoxlayın

  • şübhəli fayl dəyişikliklərini araşdırın

  • web server və authentication loglarını nəzərdən keçirin

  • problemin yalnız WordPress-lə məhdud olub-olmadığını yoxlayın

  • açarları və token-ləri yeniləyin

  • yalnız təmiz olduğu yoxlanılmış komponentləri bərpa edin

  • bərpadan sonra sistemi mütləq sərtləşdirin