Bir sunucu yönetiyorsanız görmek isteyeceğiniz son şeylerden biriyle karşılaştım: sitelerimden birinin içinde phishing amaçlı hazırlanmış sahte bir giriş sayfası vardı.

Aklıma gelen ilk soru çok basitti:

Ne kadar ileri gidebildiler?

Zararlı bir dosya bulduğunuz anda insanın aklı ister istemez en kötü senaryolara gidiyor. Root erişimi alınmış olabilir mi? Veritabanları ele geçirilmiş olabilir mi? Aynı sunucudaki diğer sitelere de ulaşılmış olabilir mi?

Ama bu olayı incelerken öğrendiğim en önemli şeylerden biri şuydu:

Bir phishing sayfasının sunucuda bulunması, birilerinin olmaması gereken bir yere dosya yazabildiğini gösterir.

Bu ciddi bir durumdur.

Ama tek başına bütün sunucunun ele geçirildiği anlamına gelmez.

Asıl önemli olan bundan sonra ne olduğunu anlamaktır.

İlk yaptığım şey dosyayı silmek olmadı

Zararlı bir dosya gördüğünüzde ilk refleks onu hemen silmek oluyor.

Ben bunu yapmak istemedim.

Çünkü dosyayı silmek görünen problemi ortadan kaldırabilir ama aynı zamanda elinizdeki en değerli delillerden birini de yok edebilir.

Bu yüzden önce ilgili alanı izole ettim ve şüpheli dosyanın bir kopyasını ziyaretçilerin erişemeyeceği güvenli bir yere aldım.

Örneğin:

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")"

Buradaki yollar tabii ki örnek.

Gerçek sunucu yollarını, kullanıcı adlarını, IP adreslerini veya ham log kayıtlarını yayınlamıyorum.

Benim için temel sıra şu oldu:

Önce izole et. Sonra delili koru. Ardından incele.

Dosyayı çalıştırmadım ve tarayıcıda açıp ne olduğuna bakmaya da kalkmadım.

Ayrıca dosya tarihlerini tek başına gerçek zaman çizelgesi gibi kabul etmemek gerektiğini fark ettim. Kopyalanmış veya değiştirilmiş bir dosyanın timestamp bilgisi sizi yanlış yere götürebilir.

Bu yüzden sadece dosyaya değil, başka kanıtlara da bakmaya başladım.

Hikâyeyi loglar anlatmaya başladı

İşin gerçekten ilginç hale geldiği kısım burasıydı.

Şüpheli dosyanın ortaya çıktığı zamanın çevresinde authentication kayıtlarını, dosya transfer loglarını ve web isteklerini karşılaştırmaya başladım.

Systemd kullanan bir Linux sunucuda SSH hareketlerini örneğin şöyle inceleyebilirsiniz:

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

Bazı dağıtımlarda servis adı sshd yerine ssh olabilir.

Daha sonra dosya transfer servisinin loglarına baktım ve bunları sitenin access loglarıyla karşılaştırdım.

Örneğin:

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

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

Buradaki amacım ekrana binlerce log satırı dökmek değildi.

Üç şeyi anlamaya çalışıyordum:

  1. İlk şüpheli değişiklik ne zaman olmuştu?

  2. Bundan hemen önce başarılı bir giriş veya dosya transferi var mıydı?

  3. Phishing sayfası yüklendikten sonra ne olmuştu?

Bu ayrım önemli.

Zararlı dosya size ne olduğunu gösterir.

Loglar ise oraya nasıl geldiğini anlatmaya başlayabilir.

Bunlar aynı şey değil.

Tek bir zararlı dosya bulmak yeterli değildi

Kabaca bir zaman çizelgesi oluşturduktan sonra başka bir soru ortaya çıktı:

Bu phishing sayfası olayın tamamı mıydı, yoksa sadece görebildiğim kısmı mıydı?

Bunu anlamak için yakın zamanda değişen dosyalara baktım:

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

Ayrıca PHP dosyalarında sık rastlanan bazı şüpheli kalıpları aradım:

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

Bunlar ilk tarama için faydalı.

Ama burada dikkat edilmesi gereken önemli bir nokta var.

Bir dosyada eval() veya base64_decode() bulunması, onun otomatik olarak zararlı olduğu anlamına gelmez. Meşru yazılımlar da bunları kullanabilir.

Aynı şekilde, saldırganın zararlı kod yazarken bu kadar bariz kalıplar kullanacağının da garantisi yok.

Bu yüzden bulduğum eşleşmeleri “zararlı” diye etiketlemek yerine birer ipucu olarak değerlendirdim.

Olay boyunca bana en çok yardımcı olan yaklaşım da buydu:

Güvenlik araçları size kanıt verir. Sihirli bir evet/hayır cevabı vermez.

En önemli soru izinlerdi

Bu olaydan aldığım en büyük derslerden biri muhtemelen buydu.

Bir hesabın veya yayınlama mekanizmasının site dizinine dosya yazabildiğini gördükten sonra artık sadece o dosyayı düşünmeyi bıraktım.

Şunu sormaya başladım:

Aynı hesap başka nelere erişebiliyordu?

Uygulama yapılandırma dosyalarını okuyabilir miydi?

Veritabanı şifrelerini görebilir miydi?

Başka bir siteye ait dosyalara erişebilir miydi?

SSH anahtarlarına ulaşabilir miydi?

Scheduled task oluşturabilir miydi?

Mail hesaplarını veya API tokenlarını görebilir miydi?

Bu kapsamı anlamak için timer'lara ve çalışan process'lere de baktım:

sudo systemctl list-timers --all
sudo ps auxf

Ayrıca uygulama yöneticilerini, SSH anahtarlarını, veritabanı erişimlerini, scheduled job'ları, dosya izinlerini ve ilgili hesabın ulaşabileceği diğer alanları kontrol ettim.

Bence olay incelemelerinde en kolay hata burada yapılıyor.

phishing.php dosyasını bulup silmek insana bir rahatlama veriyor.

Ortada somut bir şey var ve siz onu yok etmiş oluyorsunuz.

Ama asıl güvenlik sınırı çoğu zaman tek bir dosya değildir.

Asıl sınır hesabın sahip olduğu yetkilerdir.

Eğer o hesap beş farklı gizli bilgiyi okuyabiliyorsa, bu beş bilgi de artık olayın kapsamına dahil edilmelidir.

Şifreleri panikle değil, erişim kapsamına göre değiştirdim

Bir başka öğrendiğim şey de şuydu:

“Her şeyin şifresini hemen değiştir” tavsiyesi kulağa doğru geliyor ama yeterince net değil.

Credential'ları, gerçekten hangi alanların etkilenmiş olabileceğine göre yenilemek gerekiyor.

İlk olarak etkilenen yayınlama hesabının şifresini değiştirdim.

Ama burada bile önce hesabın ne tür bir hesap olduğunu anlamak gerekiyor.

Local Linux kullanıcısı mı?

Virtual FTP kullanıcısı mı?

Hosting panelinden yönetilen bir kullanıcı mı?

Bunların reset yöntemleri aynı olmayabilir.

Linux üzerinde passwd komutunu çalıştırmanız, sistemde tanımlı her FTP kullanıcısının şifresini otomatik olarak değiştirmez.

Daha sonra ilgili hesabın okuyabilmiş olabileceği diğer sırları da yeniledim:

  • uygulama yönetici hesapları

  • veritabanı şifreleri

  • mail hesap bilgileri

  • API tokenları

  • başka yerde tekrar kullanılan şifreler

  • mümkün olduğu yerde aktif session ve tokenlar

Bu olay credential izolasyonunun ne kadar önemli olduğunu da bana tekrar gösterdi.

Birbiriyle ilgisi olmayan iki sistem aynı parolayı kullanıyorsa veya bir hesap ihtiyacı olmadığı halde başka alanlara da erişebiliyorsa, küçük bir güvenlik açığının etkisi bir anda çok daha büyük hale gelebiliyor.

Asıl çözüm, bir sonraki yüklemeyi daha işe yaramaz hale getirmekti

Olayı temizlemek işin sadece yarısıydı.

Phishing dosyasını silip “umarım bir daha olmaz” demek istemedim.

Aynı şey tekrar yaşanırsa saldırganın elindeki erişimin mümkün olduğunca az işe yaramasını istedim.

Upload veya statik içerik klasörleri için yapılabilecek en güçlü şeylerden biri oldukça basit:

Gerçekten gerekli değilse bu klasörlerde script çalıştırılmamalı.

Üstelik bu kural mümkünse yayınlama hesabının değiştiremeyeceği, sunucu yöneticisinin kontrol ettiği bir yapılandırmada tutulmalı.

Web sunucusunda bir değişiklik yaptıktan sonra reload etmeden önce configuration'ı test etmeyi de ihmal etmemek gerekiyor:

nginx -t

veya:

apachectl configtest

Ayrıca yayınlama hesabının izinlerini daralttım.

Eğer bir hesap sadece tek bir siteye dosya yüklemek için kullanılıyorsa, başka sitelerin klasörlerine, shell'e, veritabanına, mail sistemine ve cron işlerine erişmesinin çok da mantıklı bir sebebi yok.

Bunu yazınca zaten son derece bariz görünüyor.

Ama çalınmış bir credential'ın nerelere ulaşabileceğini tek tek incelemek zorunda kaldığınızda çok daha net anlıyorsunuz.

SFTP çalınmış şifre problemini çözmüyor

Bu olay bana başka bir önemli ayrımı da tekrar hatırlattı.

FTP yerine SFTP veya FTPS kullanmak tabii ki daha güvenli.

Çünkü bağlantıyı ve credential'ları aktarım sırasında koruyor.

Ama bu, saldırganın elinde zaten geçerli kullanıcı adı ve şifre varsa sizi kurtarmıyor.

Saldırgan doğru credential'a sahipse SFTP onun bağlantısını da gayet güzel şifreliyor.

Yani transport security ile account security farklı problemleri çözüyor.

Mümkün olduğunda ben artık bunları birlikte düşünmeyi tercih ediyorum:

  • benzersiz şifreler

  • MFA

  • minimum yetki

  • site dizinlerinin birbirinden ayrılması

  • upload klasörlerinde script çalıştırılmaması

  • yönetim erişiminde IP kısıtlaması veya VPN

  • beklenmedik dosya değişiklikleri için monitoring

Hiçbiri tek başına mucize değil.

Ama birlikte kullanıldıklarında tek bir çalınmış hesabın yaratabileceği hasarı ciddi şekilde küçültüyorlar.

Temiz malware taraması “hiçbir şey olmadı” demek değildir

Olay sırasında yapılabilecek en tehlikeli çıkarımlardan biri şu:

“Tarama başka bir şey bulamadı, demek ki sistem temiz.”

Bir scanner size ne bulduğunu söyleyebilir.

Ama görmediği hiçbir şeyin olmadığını kanıtlayamaz.

Aynı durum loglar için de geçerli.

Bir servisin logunda şüpheli bir hareket görememeniz, o hareketin başka bir servis üzerinden yapılmadığını veya logların daha önce rotate edilmediğini kanıtlamaz.

Bu yüzden olayı “enfekte / temiz” şeklinde ikili düşünmek yerine scope, yani kapsam üzerinden değerlendirmeye başladım.

Etkilenen hesap nelere erişebiliyordu?

Bu erişimlerin gerçekten kullanıldığını gösteren hangi kanıtlar vardı?

Elde olan verilerle hangi noktaları kesin olarak bilemiyordum?

Bu sorular, sonsuza kadar yeşil bir “clean” işareti aramaktan çok daha faydalı oldu.

Sistemi ancak olayı anladıktan sonra toparladım

Muhtemel erişim yolunu ve olayın kapsamını anladıktan sonra recovery aşamasına geçtim.

Etkilenen dosyaları güvenilir bir kaynaktan geri yükledim, gerekli güncellemeleri yaptım, izinleri daralttım, risk altındaki credential'ları değiştirdim ve sonrasında authentication, web, transfer, dosya değişiklikleri ve outbound trafik kayıtlarını takip etmeye devam ettim.

Backup'ların da aynı yayınlama hesabı tarafından değiştirilemediğinden emin oldum.

Çünkü saldırganın canlı siteyle birlikte değiştirebildiği bir backup, çok da backup sayılmaz.

Bir de gerçekten restore testi yapmak gerekiyor.

“Backup'ımız var.”

ile

“Bu sunucuyu backup'tan geri döndürebiliyoruz.”

aynı şey değil.

Bunu da olay yaşanmadan önce bilmek daha güzel olurdu.

Bugün aynı olay yaşansa ilk soracağım üç şey

Aynı türde bir phishing sayfasını bugün tekrar bulsam artık ilk sorum şu olmazdı:

“Bütün sunucuyu mu hacklediler?”

Bunun yerine üç şey sorardım:

Ne yüklendi?

Bu dosyayı yükleyen hesabın başka nerelere erişimi vardı?

Saldırganın bu erişimin ötesine geçtiğini gösteren hangi kanıtlar var?

Bu bakış açısı olayı çok daha anlaşılır hale getirdi.

Phishing sayfası sadece gözle görünen belirtisiydi.

Asıl araştırılması gereken şey erişim, yetkiler ve kanıtlardı.

Ve gerçek çözüm de sadece zararlı bir dosyayı silmek değildi.

Bir sonraki credential çalındığında, o hesabın eskisi kadar güçlü olmamasını sağlamaktı.