SunucuKontrol — Sunucu Yönetim Paneli
Kontrol listesi

Sunucum php2shell saldırısına uğradı mı? Kontrol listesi

Yayın:

Kısaca
Kimin için?
17 Ekim 2026'dan sonra bir süre yamasız PHP ile çalışmış sunucular.
Ne yapacaksınız?
Altı yere bakacaksınız: PHP kayıtları, web kayıtları, değişen dosyalar, zamanlanmış görevler, çalışan programlar ve hesaplar.
Bir şey bulursam?
Siteyi 17 Ekim öncesi bir yedekten geri yükleyin ve bütün parolaları değiştirin.

Amazon, php2shell açığına karşı ilk saldırı denemesini duyurudan dört gün önce, 17 Ekim 2026'da gördü. Bu yüzden PHP'yi bugün güncellemiş olmanız, daha önce içeri girilmediği anlamına gelmez. Aşağıdaki kontrolleri 17 Ekim'den bu yana olan her şey için yapın.

Önce PHP'yi yamalı sürüme güncelleyin (adım adım rehber). Açık kapanmadan yapılan temizlik aynı yoldan yeniden bozulabilir.

1. PHP-FPM işçi çökmeleri

Bellek bozulmasına dayanan saldırı denemeleri çoğu zaman işçileri çökertir. Kısa sürede çok sayıda çökme dikkat çekicidir:

# Dağıtımın FPM kaydı, SunucuKontrol'ün site başına (php-fpm-<alan adı>.log) ve panel FPM kayıtları, döndürülmüş .gz dahil:
sudo zcat -f /var/log/php*-fpm.log* /var/log/php-fpm-*.log* /var/log/sunucukontrol-panel-fpm.log* 2>/dev/null | grep -iE 'SIGSEGV|exited on signal' | tail -50

2. Web sunucusu kayıtları

17 Ekim'den bu yana 500/502 yanıtlarında ani artış, aynı adresten gelen çok büyük gövdeli POST istekleri ve olağandışı adreslere yapılan istekler:

# 502 yanıtlarını gün gün sayın. SunucuKontrol her sitenin kaydını ayrı tutar
# (<alan adı>_access.log, <alan adı>_ssl_access.log); desen hepsini ve döndürülmüş .gz dosyalarını kapsar:
sudo zcat -f /var/log/nginx/*access.log* 2>/dev/null | awk '$9==502 {split($4,t,":"); print t[1]}' | sort | uniq -c

3. Son günlerde değişen PHP dosyaları

Saldırgan genellikle kalıcı olmak için bir "web kabuğu" bırakır. Güncellemediğiniz hâlde değişmiş dosyalar en güçlü işarettir:

sudo find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls
# Yükleme dizinlerinde PHP dosyası olmamalı:
sudo find /var/www -path '*uploads*' -name '*.php' -ls
# Sık görülen gizleme kalıpları:
sudo grep -rlE 'eval\((base64_decode|gzinflate|str_rot13)' /var/www --include='*.php'

Son komut güvenli eklentilerde de eşleşme verebilir; her bulguyu açıp bakın.

4. Zamanlanmış görevler

Kalıcılık için sık kullanılan bir yol da web kullanıcısına cron görevi eklemektir:

sudo ls -la /var/spool/cron/crontabs/ /etc/cron.d/
for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

5. Şüpheli süreçler ve bağlantılar

# Web kullanıcılarıyla çalışan, php-fpm olmayan süreçler:
ps -eo user,pid,etime,cmd | grep -E '^(www-data|web_)' | grep -v php-fpm
# Dışarı açılmış bağlantılar:
sudo ss -tnp state established

Web kullanıcısıyla çalışan bir kabuk, /tmp altından çalışan bir program ya da tanımadığınız bir adrese sürekli bağlantı ciddi işarettir.

6. Hesaplar ve SSH anahtarları

sudo grep -E ':(0|[1-9][0-9]{3,}):' /etc/passwd
sudo find / -name authorized_keys -newermt '2026-10-17' 2>/dev/null

Bulgu varsa ne yapmalı?

  1. Siteyi bakım kipine alın ya da sunucuyu ağdan ayırın; delilleri silmeden kayıtların kopyasını alın.
  2. Değiştirilmiş dosyaları silmek yerine siteyi 17 Ekim öncesi bir yedekten geri yükleyin.
  3. Site yönetici, veritabanı, FTP/SSH ve API parolalarını değiştirin; uygulama gizli anahtarlarını yenileyin.
  4. Kişisel veri sızmış olabilirse KVKK kapsamındaki bildirim yükümlülüklerinizi değerlendirin.

SunucuKontrol'de nasıl sınırlanır?

SunucuKontrol'de siteler ortak bir kullanıcıyı paylaşmaz: her alan adının kendi sistem kullanıcısı ve kendi PHP-FPM havuzu vardır. Bir sitede açılan kabuk, aynı sunucudaki diğer sitelerin dosyalarına o kullanıcıyla erişemez. Yedekleme ekranından tarih seçerek geri dönüş ve site hata kaydını panelden okuma da bu kontrolleri hızlandırır.

İlgili yazılar