Bir shell dosyasını bulmak olayın yalnız son adımı olabilir. Asıl değer, dosyanın ne zaman oluştuğunu; hemen öncesinde hangi URL’ye hangi HTTP yöntemiyle istek geldiğini; panel, FTP veya SSH hesabında olağan dışı oturum olup olmadığını ve WAF’ın aynı istekte ne gördüğünü zaman çizgisinde birleştirmektir. Bu rehber cPanel ve Plesk üzerinde savunma amaçlı log korelasyonunu anlatır.
02:14:31 POST /admin/upload.php 200
02:14:32 public_html/uploads/supheli.php mtime
02:14:33 GET /uploads/supheli.php 200
02:14:45 POST /uploads/supheli.php 200Olay müdahalesinde logların süreli tutulduğunu ve rotation ile eski kayıtların silinebileceğini unutmayın. Raw access, error log, ModSecurity, panel Action Log ve varsa sistem authentication loglarını temizliğe başlamadan önce dışarı alın.
Saat dilimi farkı kritik olabilir. PHP dosyasının mtime değeri sunucu yerel saatine, CDN kaydı UTC’ye, panel arayüzü farklı timezone’a göre görünebilir. Tüm zamanları tek timezone’a dönüştürmeden IP/istek eşleştirmesi yapılmamalıdır.
cPanel dokümantasyonuna göre Metrics → Raw Access arayüzü Apache ve NGINX erişim loglarını .gz biçiminde indirmenizi sağlar. Bu kayıtlar ziyaretçi ve erişilen içerik bilgisini içerir.
İndirdiğiniz access loglarda IP, timestamp, HTTP method, path, status code, referrer ve user-agent alanlarını inceleyin. Özellikle şüpheli dosya oluşumundan hemen önceki POST/PUT istekleri ve sonrasında dosyaya gelen GET/POST çağrıları önemlidir.
zgrep -Ei "POST|PUT|/upload|\.php" example.com-Aug-2026.gz | tail -200awk '$9 ~ /200|201|302/ {print}' access.log | tail -200cPanel’in resmi log dosyaları dokümanı varsayılan log konumlarını listeler ve bu yolların yapılandırmayla değiştirilebileceğini belirtir. Domain erişim logları, cPanel erişim logu, SSH/FTP ve servis logları olay tipine göre farklı dosyalardadır.
Root erişiminiz varsa önce resmi dokümandaki sunucu sürümünüze uygun log konumunu doğrulayın. Kopyayı aldıktan sonra şüpheli zaman aralığını grep/awk ile daraltın. Production loglarını düzenlemeyin; yalnız okuyun ve analiz kopyası üzerinde çalışın.
Örneğin şüpheli dosya 18 Ağustos 02:14:32’de değişmişse access logda 02:10–02:20 aralığı çıkarılır. upload.php, ajax endpoint, admin upload, file manager veya beklenmeyen API route’larına POST istekleri aranır.
Aynı dakika içinde POST → 200/302 → yeni PHP dosyasına GET → tekrar POST gibi bir zincir, tek başına kesin kanıt olmasa da güçlü korelasyon oluşturur. Dosya owner/permission bilgisi de hangi sistem kullanıcısının yazdığını anlamaya yardımcı olur.
stat public_html/uploads/supheli.phpfind public_html -type f -newermt "2026-08-18 02:10" ! -newermt "2026-08-18 02:20" -lsgrep "18/Aug/2026:02:1" access.log | grep -E "POST|PUT|uploads|php"WHM ModSecurity Tools geçmiş rule event’lerini gösterebilir; cPanel dokümantasyonu tam geçmiş için logların incelenmesini önerir. ModSecurity audit engine’i tüm transaction’ları loglayacak şekilde açmak disk ve mahremiyet riski yaratabileceğinden yalnız gerekli seviyede kullanılmalıdır.
Bir event’in WAF tarafından tetiklenmesi saldırının başarılı olduğu anlamına gelmez. HTTP status, backend uygulama logu ve dosya değişikliğiyle korelasyon yapılmalıdır. Engellenmiş 403 isteği ile ardından dosya yazılmış 200 isteğini ayırmak önemlidir.
Plesk Obsidian dokümantasyonunda domain log browser’a Websites & Domains → ilgili domain → Logs yoluyla erişildiği belirtilir. Manage Log Files ekranından izlenen loglar görüntülenebilir veya indirilebilir; real-time updates ile yeni kayıtlar takip edilebilir.
Apache access/error, nginx access/error ve uygulamaya ait özel logları zaman aralığına göre filtreleyin. Olay sırasında log rotation varsa önce döndürülmüş dosyaları da indirin.
Plesk Action Log her kayıt için tarih/saat, işlemi yapan IP, Plesk kullanıcısı ve işlem türüne göre ek ayrıntılar gösterebilir. Server-wide görünüm Tools & Settings → Action Log altındadır; tek siteye ait Action Log da Websites & Domains üzerinden filtrelenebilir.
Bu log, saldırgan çalınmış bir Plesk hesabıyla dosya yöneticisi, cron veya ayar değişikliği yaptıysa web access loguna ek bağlam sağlayabilir. Ancak paneldeki IP yine proxy/VPN olabilir; kimlik atfı yerine olay korelasyonu için kullanılır.
Plesk’in güncel dokümanına göre Linux’ta ayrıntılı ModSecurity audit log varsayılan olarak /var/log/modsec_audit.log konumundadır. Domain Apache error logu ise /var/www/vhosts/DOMAIN.TLD/logs/error_log yolunda kısa güvenlik/hata bilgileri içerebilir.
Windows Plesk’te ModSecurity audit logları domain bazlı olarak %plesk_dir%ModSecurity\vhosts\<GUID>\logs altında bulunur. Event ID ve rule ID üzerinden aynı isteğin bölümleri birleştirilebilir.
grep -n "HOST: alanadi.com" /var/log/modsec_audit.log | tail -50grep -Ei 'ModSecurity|Access denied|id \"[0-9]+\"' /var/www/vhosts/alanadi.com/logs/error_log | tail -100Uygulamada exploitable upload bulunmasa bile çalınmış FTP/SFTP/SSH veya panel hesabı doğrudan dosya yazabilir. Bu durumda access logda zararlı upload isteği görmeyebilirsiniz; olay dosya transferi veya panel file manager üzerinden gerçekleşmiş olabilir.
Başarılı login, kaynak IP, yeni SSH key, olağan dışı ülke/saat, aynı hesapla kısa sürede çok sayıda işlem ve parola değişiklikleri kontrol edilir. Başarısız brute-force denemelerinden çok başarılı ve beklenmeyen oturumlar olay açısından daha kritiktir.
Proxy/CDN kullanılan yapılarda web sunucusu logu doğrudan proxy IP’sini kaydedebilir. Gerçek istemci IP’sinin doğru header üzerinden güvenilir proxy listesiyle restore edilmesi gerekir. Aksi halde tüm ziyaretçiler aynı birkaç IP’den geliyor gibi görünebilir veya saldırgan sahte header göndererek logu yanıltabilir.
Sunucu yapılandırmanızın trusted proxy yaklaşımını doğrulayın. Eski loglarda gerçek IP kaydedilmemişse sonradan kesin olarak üretilemeyebilir; bu sınırlama raporda açıkça belirtilmelidir.
Bir IP olayla güçlü biçimde ilişkili olabilir fakat gerçek kişinin kimliğini kanıtlamaz. VPN, residential proxy, Tor çıkış düğümü, botnet veya ele geçirilmiş başka sunucu kullanılabilir.
Teknik raporda “olayla ilişkili kaynak IP” gibi ölçülü ifade kullanılır. Adli kimlik atfı; servis sağlayıcı kayıtları, yasal süreç ve ek kanıt gerektirebilir.
Dosya zamanları, web access/error logları, WAF kayıtları, Plesk/cPanel hareketleri ve varsa SSH/FTP kayıtları tek timeline’a alınır. Amaç “bir IP listesi çıkarmak” değil, ilk giriş noktası ile kalıcılık ve sonradan yapılan işlemler arasındaki ilişkiyi gösterebilmektir.
Teslimatta şüpheli zaman pencereleri, ilgili URL/method/status bilgileri, teknik IP göstergeleri, değişen dosyalar ve önerilen hardening adımları bulunur. Log eksikliği veya rotation nedeniyle kanıt yetersizse bu durum ayrıca belirtilir.
Log satırlarını yapıştırın. Araç yalnız tarayıcıda IPv4 adreslerini ve POST/PUT/PATCH içeren satırları özetler; adli analiz yerine geçmez.
Standart vakalar ön inceleme sonrasında genellikle 24–72 saatlik analiz planına alınır. Süre; dosya sayısı, log erişimi, zararlı kodun yayılımı ve uygulamanın yapısına göre değişebilir.
Önemli not: Yalnız size ait veya açıkça yetkilendirildiğiniz sistemlerde test yapın.
Metrics → Raw Access altında; erişim loglarını .gz olarak indirebilirsiniz.
Websites & Domains → domain → Logs.
Güncel Plesk dokümantasyonuna göre işlem zamanı, IP, kullanıcı ve işlem detayları görüntülenebilir.
Hayır. Kaynak IP değişebilir; giriş noktası ve kalıcılık mekanizması düzeltilmelidir.
Dosya ve uygulama bulgularından çıkarım yapılabilir fakat kesin timeline kalitesi düşer.
Hayır. WAF olayı, HTTP sonucu ve dosya/uygulama etkisi birlikte değerlendirilmelidir.