Web shell belirtileri hangi dosya değişiklikleriyle incelenir?

Web shell şüphesinde ilk bakılacak yer, web sunucusunun erişebildiği dizinlerde yakın zamanda oluşturulan veya değiştirilen dosyalardır. Özellikle yükleme klasörlerinde bulunan beklenmedik PHP, ASP, ASPX, JSP ya da benzeri sunucu taraflı dosyalar; mevcut dosyalara sonradan eklenmiş çalıştırılabilir kodlar; dosya adıyla uzantısı uyuşmayan içerikler ve anormal izinler önemli belirtilerdir. Ancak yalnızca değişiklik tarihine bakarak karar verilmez: saldırgan zaman damgasını değiştirmiş veya meşru bir güncelleme de dosyaları topluca değiştirmiş olabilir.

İncelemeye başlamadan önce​

Canlı dosyaları hemen silmek yerine önce kanıtı koruyun. Şüpheli dosyanın kopyasını alın, tam yolunu, boyutunu, sahipliğini, izinlerini ve zaman bilgilerini kaydedin. Mümkünse incelemeyi salt okunur bir kopyada yapın. Bakım ekranı tek başına saldırganı durdurmaz. Olay kapsamına göre uygulamayı izole etmek ve ele geçirilmiş hesap/işlemleri sınırlamak devam eden erişimi azaltabilir; bunu yapamıyorsanız en azından şüpheli dosyayı çalıştırılabilir web yolundan çıkarıp kanıt kopyasını koruyun.

Dosya değişikliklerini adım adım tarama​

Aşağıdaki örnekte web kökü /var/www/example.com kabul edilmiştir. Kendi sunucunuzdaki gerçek web köküyle değiştirin. Komutlar Linux/GNU find ve standart shell içindir; macOS BSD find aynı -printf seçeneğini sunmaz. Bilinmeyen dosyayı PHP/ASP çalıştırıcısına veya tarayıcıda canlı URL’ye açmayın; salt okunur inceleyin.

1. Önce web kökünde son değişen dosyaları listeleyin: find /var/www/example.com -type f -printf '%TY-%Tm-%Td %TH:%TM:%TS %s %u:%g %m %p\n' | sort -r | head -n 100. Yeni dosyalar, beklenmeyen sahiplik veya olağandışı izinler not edilmelidir.
2. Yükleme, önbellek ve geçici dizinleri ayrıca inceleyin: find /var/www/example.com -type f \( -path '*/uploads/*' -o -path '*/cache/*' -o -path '*/tmp/*' \) -print. Bu dizinlerde sunucu taraflı kod çalışması gerekmiyorsa PHP, ASP veya JSP dosyaları özellikle şüphelidir.
3. Sunucu taraflı dosyalarda kod çalıştırma ve kod gizleme belirtilerini arayın: grep -RInE 'eval|assert|base64_decode|gzinflate|shell_exec|system|passthru|proc_open|popen' /var/www/example.com --include='*.php'. Bu eşleşme tek başına saldırı kanıtı değildir; uygulamanın meşru kullanımını, dosyanın bağlamını ve değişiklik geçmişini karşılaştırın.
4. Şüpheli dosyanın kimlik bilgilerini kaydedin: stat /var/www/example.com/path/to/suspect.php ve sha256sum /var/www/example.com/path/to/suspect.php. Dosya daha sonra değişirse yeni özet ile ilk kayıt karşılaştırılabilir.
5. Dosyayı bilinen temiz sürümle karşılaştırın: diff -u clean-copy/path/to/file.php /var/www/example.com/path/to/file.php. Temiz kopya yoksa aynı uygulamanın güvenilir dağıtımından veya yedekten karşılaştırma temeli oluşturun; yedeğin saldırıdan önceki duruma ait olduğundan emin olun.
6. Şüpheli dosyayı çağırmadan, yapılandırma ve kayıtlar üzerinden çalıştırılabilme yolunu inceleyin. Yükleme dizini için sunucu yapılandırmasında betik çalıştırma kuralını, dosya uzantısı eşlemelerini ve uygulamanın yükleme kodunu kontrol edin. Doğrudan web eşlemesi olmasa da başka kodun include/require etmesi veya zamanlanmış bir iş dosyayı çalıştırabilir; yalnız uzantı engeli yeterli değildir.

Komut beklenenden fazla dosya döndürüyorsa bu durum tek başına ihlal anlamına gelmez; dağıtım, eklenti güncellemesi veya önbellek yenilemesi toplu değişiklik oluşturabilir. Hiç sonuç çıkmaması da güvenli olduğunuzu kanıtlamaz. Dosya zaman damgaları değiştirilebilir ve web shell farklı bir uzantı altında ya da mevcut meşru dosyaya eklenmiş olabilir.

find çıktısının satır bazlı sıralaması normal dosya adları içindir; yeni satır içeren dosya adları incelemeyi yanıltabilir. İzin hatalarını gizlemeyin; taranmamış dizinler temiz sayılmaz. find varsayılanı sembolik bağları takip etmez; web kökü dışındaki alias, symlink hedefleri ve PHP auto_prepend_file/.user.ini gibi yapılandırmaları bilinen kapsamla ayrıca inceleyin.

Bulguyu nasıl yorumlamalı?​

Aynı zaman aralığında oluşan dosyaları bir olay kümesi olarak değerlendirin. Şüpheli dosyayla birlikte değişen giriş noktası, yükleme kodu, yönetici hesabı, eklenti veya yapılandırma dosyasını arayın. Dosya içeriğini yalnızca satır satır incelemek yerine şu karşılaştırmayı yapın:


Bir dosyada eval veya benzeri işlev bulunması doğrudan web shell demek değildir; bazı kütüphaneler bunları meşru amaçla kullanabilir. Tersine, temiz görünen kısa bir dosya da saldırganın başka bir dosyayı dahil etmesiyle tehlikeli olabilir. include, require, otomatik yükleme ve yapılandırma dosyalarının referanslarını da izleyin.

İnceleme sonrasında yapılacaklar​

Şüphe doğrulanırsa yalnızca bulunan dosyayı silmeyin. Etkilenen uygulamayı temiz, doğrulanmış bir sürümden yeniden kurun; bilinmeyen değişiklik içeren yedekleri kullanmayın. Yönetici, FTP, SSH, veritabanı ve uygulama parolalarını temiz bir sistemden değiştirin. İlgili erişim kayıtlarında dosyanın yüklenmesi veya çalıştırılmasıyla aynı zamandaki istekleri arayın. Açığın kaynağını, örneğin güncel olmayan eklenti, yazılabilir dizin veya yanlış sunucu kuralını kapatmadan siteyi tekrar yayına almak yeniden bulaşmaya yol açabilir.

Sık yapılan hatalar​

Yalnızca mtime değerine güvenmek: Zaman damgası değiştirilebilir; içerik özeti, sahiplik ve log korelasyonu da incelenmelidir.

Tüm PHP dosyalarını silmek: Bu işlem kanıtı yok eder ve çalışan uygulamayı bozabilir. Önce kopya ve kayıt alın, sonra temiz sürümle değiştirin.

Sadece dosya adına bakmak: Web shell normal bir dosyanın içine eklenebilir veya uzantısı maskeleyebilir. İçerik, sunucu eşlemesi ve erişim kuralı birlikte değerlendirilmelidir.

Kaynaklar​

• Microsoft Security: Web shell tespiti ve korunma
• GNU find: Resmî man sayfasının man7 yayını

Sık sorulan sorular​

Bir dosyanın son değişiklik tarihini değiştirmek şüpheyi ortadan kaldırır mı?​

Hayır. Dosya zamanı yalnızca zaman çizelgesinin bir parçasıdır. Web sunucusu erişim kayıtları, dosya özeti, sahiplik değişimi ve uygulama dağıtım kayıtlarıyla birlikte değerlendirilmelidir.

Temiz bir yedek varsa neden log incelemeliyim?​

Yedek dosyaları geri kazandırabilir; loglar ise giriş noktasını, saldırı zamanını ve başka hesapların etkilenip etkilenmediğini anlamaya yardımcı olur. Bu ayrım yapılmadan aynı açık yeniden kullanılabilir.

Yükleme klasöründe PHP dosyası her zaman web shell midir?​

Hayır. Bazı uygulamalar bunu meşru olarak kullanabilir. Fakat yükleme dizininde betik çalışması gerekmiyorsa bu bulgu yüksek öncelikle incelenmeli; dosyanın içeriği, oluşturulma yolu ve sunucu yapılandırması birlikte doğrulanmalıdır.