cPanel & WHM Log Dosyaları: Sunucu Yöneticileri için Eksiksiz Teknik Referans

cPanel & WHM, web hizmetleri, posta iletimi, kimlik doğrulama, veritabanları ve sistem işlemleri genelinde her önemli olayı kaydeden kapsamlı, çok katmanlı bir günlük kaydı mimarisi sürdürür. Her günlük dosyasının kendine özgü bir konumu, biçimi ve tanısal amacı vardır — hangi günlüğe başvurulacağını ve nasıl verimli şekilde ayrıştırılacağını bilmek, beş dakikalık bir düzeltme ile saatler süren bir kesinti araştırması arasındaki farkı belirler.

Bu kılavuz, üretim ortamındaki bir cPanel & WHM ortamındaki her kritik günlük dosyasını kapsar; dosya yolları, günlük biçimleri, gerçek dünya tanı kullanım senaryoları ve deneyimli sistem yöneticilerinin gerçekten kullandığı komut satırı teknikleri dahil.

cPanel & WHM Günlük Dosyaları Neden Dikkatinizi Hak Ediyor?

Günlük dosyaları yalnızca bir denetim izi değildir — Linux tabanlı herhangi bir barındırma yığını için birincil tanı aracıdır. Özellikle bir cPanel ortamında, günlük kaydı yüzeyi Apache/LiteSpeed, Exim, MySQL/MariaDB, PHP-FPM, ProFTPd, Pure-FTPd, cPHulk ve cPanel/WHM uygulama katmanını kapsar.

Günlüklere reaktif biçimde yaklaşan — yalnızca bir arızadan sonra kontrol eden — yöneticiler, erken uyarı sinyallerini sürekli olarak kaçırır: kademeli bellek tükenmesi, artımlı kaba kuvvet kampanyaları, yavaş sorgu birikimi ve sertifikayla ilgili iletim hataları. Proaktif günlük analizi, bu kalıpları olaylara dönüşmeden önce yakalar.

cPanel ortamlarında günlük analizini yönlendiren üç temel operasyonel hedef vardır:

• Kök neden tanısı: Bir istek zincirindeki tam arıza noktasını belirlemek için Apache, PHP ve MySQL günlüklerindeki zaman damgalarını ilişkilendirme.
• Performans temel çizgisi oluşturma: Sunucu kapasitesini doyurmadan önce yavaş sorguları, yüksek gecikmeli HTTP yanıtlarını ve kaynak tüketen süreçleri belirleme.
• Güvenlik adli analizi: Kapsam ve düzeltme adımlarını belirlemek için SSH kimlik doğrulama günlüklerinden, cPHulk kayıtlarından ve Exim ret günlüklerinden saldırı zaman çizelgelerini yeniden oluşturma.

Apache Günlük Dosyaları

Apache, cPanel ortamlarında varsayılan web sunucusudur; ancak LiteSpeed, yerinde değiştirme olarak giderek daha yaygın hale gelmektedir. Her ikisi de uyumlu biçimlerde aynı geleneksel yollara günlük yazar.

Apache Hata Günlüğü

Konum: /usr/local/apache/logs/error_log

Bu, herhangi bir cPanel sorun giderme oturumunda en çok başvurulan günlüktür. Apache’nin oluşturduğu her hatayı yakalar: PHP ölümcül hataları (PHP bir modül olarak çalışırken), .htaccess sözdizimi hataları, mod_rewrite kural uyuşmazlıkları, izin redleri, SSL el sıkışma hataları ve yukarı akış proxy hataları.

Birçok kılavuzun atladığı kritik bir ayrıntı: alan adı başına hata günlükleri de mevcuttur ve genellikle genel hata günlüğünden daha hemen kullanışlıdır. Şu konumda bulunurlar:

/home/username/logs/domain.com-ssl_error_log
/home/username/logs/domain.com-error_log

Bu VirtualHost başına günlükler, hataları tek bir hesaba izole eder ve paylaşılan bir sunucuda belirli bir siteyi tanılarken gürültüyü önemli ölçüde azaltır.

Yaygın tanı kalıbı — .htaccess yeniden yazma döngüsü:

grep "RewriteRule" /usr/local/apache/logs/error_log | tail -50

Yaygın tanı kalıbı — Alan adına göre PHP ölümcül hataları:

grep "PHP Fatal" /home/username/logs/domain.com-error_log | tail -30

Apache Erişim Günlüğü

Konum: /usr/local/apache/logs/access_log

Genel erişim günlüğü, varsayılan olarak Birleşik Günlük Biçiminde her HTTP/HTTPS isteğini kaydeder:

IP - username [timestamp] "METHOD /path HTTP/version" status_code bytes_sent "referer" "user_agent"

Alan adı başına erişim günlükleri /home/username/logs/domain.com-access_log konumunda depolanır ve bireysel hesaplardaki trafik analizi için doğru kaynaktır.

Pratik kullanım senaryoları:

• IP sıklığına göre bir DDoS veya kazıma kampanyasını belirleme:

awk '{print $1}' /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn | head -20

• Son bir saatteki tüm 500 serisi hataları bulma (günlük zaman damgalarının güncel olmasını gerektirir):

grep " 5[0-9][0-9] " /usr/local/apache/logs/access_log | tail -200

• Kullanıcı aracısı dizesine göre güvenlik açığı tarayıcılarını tespit etme:

grep -i "sqlmap|nikto|masscan|nmap" /usr/local/apache/logs/access_log

Uç durum: WHM’de piped logging etkinleştirilmiş sunucularda, günlükler doğrudan bir günlük işleme arka plan programına yönlendirildiğinden erişim günlüğü boş veya minimal olabilir. Beklenmedik şekilde boş bir erişim günlüğü bulursanız, WHM > Apache Yapılandırması > Genel Yapılandırma bölümünde CustomLog yönergesini kontrol edin.

Apache SSL/TLS Günlüğü

Konum: /usr/local/apache/logs/ssl_error_log

Bu günlük, TLS müzakere hatalarını, sertifika doğrulama hatalarını ve şifre paketi uyuşmazlıklarını yakalar. Ana hata günlüğünde görünmeyen HTTPS bağlantı sorunlarını hata ayıklarken önemlidir. Kullanıcılar tarayıcı SSL uyarıları bildirdiğinde veya AutoSSL aracılığıyla otomatik sertifika yenileme sessizce başarısız olduğunda önce buraya bakın.

cPanel ve WHM Uygulama Günlükleri

cPanel Erişim Günlüğü

Konum: /usr/local/cpanel/logs/access_log

cPanel arayüzüne (port 2082/2083) yapılan her HTTP isteğini kaydeder. Her giriş, kimliği doğrulanmış kullanıcı adını, gerçekleştirilen eylemi ve kaynak IP’yi içerir. Bu günlük, belirli bir kullanıcının cPanel hesabı içinde ne yaptığını denetlemek için birincil kaynaktır.

Belirli bir kullanıcı tarafından gerçekleştirilen tüm eylemleri bulma:

grep "username" /usr/local/cpanel/logs/access_log | grep -v "GET /favicon"

cPanel Hata Günlüğü

Konum: /usr/local/cpanel/logs/error_log

cPanel uygulama katmanından gelen iç hataları yakalar — başarısız API çağrıları, bozuk cPanel eklentileri, cPanel’in arka ucundaki Perl komut dosyası hataları ve şablon oluşturma hataları. cPanel arayüzü 500 hatası veriyorsa veya belirli özellikler bozuksa, kontrol edilecek ilk günlük budur.

WHM Giriş Günlüğü

Konum: /usr/local/cpanel/logs/login_log

Tüm WHM kimlik doğrulama olaylarını kaydeder — başarılı girişler, başarısız denemeler, iki faktörlü kimlik doğrulama zorlukları ve API token kullanımı. Bu günlük, yetkisiz yönetici erişimini tespit etmek için kritik öneme sahiptir.

Tüm başarısız WHM giriş denemelerini bulma:

grep "FAILED" /usr/local/cpanel/logs/login_log | awk '{print $NF}' | sort | uniq -c | sort -rn

cPHulk Kaba Kuvvet Koruma Günlüğü

Konum: /usr/local/cpanel/logs/cphulkd.log

Bu, çoğu kılavuzun tamamen atladığı ancak operasyonel açıdan en önemli günlüklerden biri olan bir günlüktür. cPHulk, cPanel’in yerleşik kaba kuvvet koruma arka plan programıdır. SSH, FTP, cPanel ve WHM giriş denemelerini izler ve eşik sınırlarını aşan IP’leri otomatik olarak engeller.

Meşru bir yönetici WHM veya SSH’dan kilitlendiğinde, yanıt neredeyse her zaman bu günlüktedir. cPHulk veritabanını doğrudan da sorgulayabilirsiniz:

mysql -u root cphulkd -e "SELECT ip, user, type, timestamp FROM brutes ORDER BY timestamp DESC LIMIT 20;"

Komut satırından belirli bir IP’nin engelini kaldırmak için:

/usr/local/cpanel/bin/cphulk_pam_ctl --unblock=192.168.1.1

cPanel Güncelleme ve Kurulum Günlüğü

Konum: /var/cpanel/updatelogs/

Her cPanel güncelleme çalıştırması bu dizinde zaman damgalı bir günlük dosyası oluşturur. Bir cPanel yükseltmesi bir hizmeti bozduğunda veya bir güncellemeden sonra bir özellik kaybolduğunda, bu dizin paket kurulumu veya yapılandırma geçişi sırasında oluşan hatalar dahil güncelleme sürecinin tam çıktısını içerir.

ls -lt /var/cpanel/updatelogs/ | head -5

E-posta Günlük Dosyaları

E-posta, cPanel’de sorun giderme açısından sürekli olarak en karmaşık alt sistemdir. cPanel’in varsayılan MTA’sı olan Exim, her biri farklı bir tanısal amaca hizmet eden üç ayrı günlük akışı oluşturur.

Exim Ana Günlüğü

Konum: /var/log/exim_mainlog

Bu, birincil e-posta işlem günlüğüdür. Exim’in işlediği her mesaj — gelen veya giden — kabul, yönlendirme kararları, iletim denemeleri ve nihai durum (iletildi, ertelendi veya geri döndü) kapsayan girişler oluşturur.

Günlük girişi anatomisi:

2024-01-15 14:23:01 1rPqXY-0003aB-Kc <= sender@example.com H=mail.example.com [203.0.113.10] P=esmtps S=4821 id=<abc123@example.com>
2024-01-15 14:23:02 1rPqXY-0003aB-Kc => recipient@domain.com R=virtual_user_delivery T=virtual_userdelivery_pipe
2024-01-15 14:23:02 1rPqXY-0003aB-Kc Completed

Mesaj kimliği (1rPqXY-0003aB-Kc), tek bir mesajı tüm günlük boyunca izlemenin anahtarıdır:

grep "1rPqXY-0003aB-Kc" /var/log/exim_mainlog

Belirli bir hesaptan gelen tüm giden postaları izleme (spam araştırması için kritik):

grep "U=username" /var/log/exim_mainlog | grep "<=" | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Gerçek dünya uç durumu: Güvenliği ihlal edilmiş bir WordPress kurulumu spam gönderdiğinde, Exim ana günlüğü gönderen kullanıcıyı bir cPanel hesabı kullanıcı adı yerine nobody (Apache süreç kullanıcısı) olarak gösterir. Bunu özellikle filtreleyin:

grep "U=nobody" /var/log/exim_mainlog | grep "<=" | tail -50

Exim Ret Günlüğü

Konum: /var/log/exim_rejectlog

Exim’in SMTP bağlantı aşamasında kabul etmeyi reddettiği tüm mesajları kaydeder — kuyruğa alınmadan önce bile. Reddedmeler, RBL kara liste isabetleri, SPF/DKIM/DMARC hataları, geçersiz HELO dizeleri, röle reddi veya hız sınırlaması nedeniyle gerçekleşir.

Bu günlük iki senaryo için önemlidir: meşru gelen postanın neden reddedildiğini tanılamak ve spam filtreleme kurallarınızın etkinliğini denetlemek.

En yaygın ret nedenlerini bulma:

grep "rejected" /var/log/exim_rejectlog | grep -oP "(?<=: ).*" | sort | uniq -c | sort -rn | head -10

Exim Panik Günlüğü

Konum: /var/log/exim_paniclog

Panik günlüğü, ölümcül Exim hatalarını yakalar — yapılandırma dosyası ayrıştırma hataları, 25 numaralı porta bağlanamama, veritabanı bağlantı hataları ve TLS kütüphane hataları. Bu dosya boş değilse, Exim kritik bir arıza yaşamıştır. Çoğu durumda, boş olmayan bir panik günlüğü posta kuyruğunun tamamen işlemeyi durdurduğu anlamına gelir.

# Check if the panic log has content — a non-zero exit means there are critical errors
[ -s /var/log/exim_paniclog ] && echo "CRITICAL: Exim panic log has entries" && tail -20 /var/log/exim_paniclog

Dovecot Günlüğü

Konum: /var/log/dovecot.log (ve bilgilendirici olaylar için /var/log/dovecot-info.log)

Dovecot, cPanel ortamlarında IMAP ve POP3 bağlantılarını yönetir. Kimlik doğrulama hataları, bağlantı sınırları, posta kutusu kilitleme sorunları ve kota uygulama olayları burada görünür. Kullanıcılar e-posta istemcilerine bağlanamadığında, bakılacak doğru yer Dovecot’un günlüğüdür — Exim değil.

grep "auth failed" /var/log/dovecot.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -10

Veritabanı Günlük Dosyaları

MySQL/MariaDB Hata Günlüğü

Konum: /var/lib/mysql/$(hostname).err

Bu günlük, MySQL/MariaDB başlatma ve kapatma olaylarını, InnoDB kurtarma işlemlerini, çoğaltma hatalarını, tablo bozulma uyarılarını ve sunucu düzeyinde hataya neden olan sorguları kaydeder. Veritabanı çökmelerini ve beklenmedik yeniden başlatmaları tanılamak için kesin kaynaktır.

Gerçek yolu dinamik olarak alma:

mysql -u root -e "SHOW VARIABLES LIKE 'log_error';"

InnoDB bozulması veya çökme kurtarma olaylarını kontrol etme:

grep -i "crash|corrupt|recovery|innodb" /var/lib/mysql/$(hostname).err | tail -30

MySQL Yavaş Sorgu Günlüğü

Konum: /var/lib/mysql/slowquery.log (etkinleştirildiğinde)

Yavaş sorgu günlüğü, çoğu cPanel kurulumunda varsayılan olarak devre dışıdır. Etkinleştirmek, veritabanı yoğun bir sunucuda alabileceğiniz en yüksek değerli performans ayarlama eylemlerinden biridir.

Çalışma zamanında yavaş sorgu günlüğünü etkinleştirme (yeniden başlatma gerekmez):

mysql -u root -e "SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; SET GLOBAL slow_query_log_file = '/var/lib/mysql/slowquery.log';"

Etkinleştirildikten sonra, en kötü suçluları toplamak ve sıralamak için mysqldumpslow kullanın:

mysqldumpslow -s t -t 10 /var/lib/mysql/slowquery.log

Bu, toplam yürütme süresine göre ilk 10 sorguyu çıkarır — sorgu optimizasyonu için en uygulanabilir başlangıç noktası.

Kritik nüans: long_query_time için 1 saniyelik eşik, çoğu uygulama için makul bir başlangıç noktasıdır; ancak yüksek trafikli siteler, tek tek hızlı ancak yük altında kümülatif olarak pahalı olan sorguları yakalamak için 0,5 saniye veya hatta 0,25 saniyeyi düşünmelidir.

MySQL Genel Sorgu Günlüğü

Konum: Yapılandırılabilir, genellikle /var/lib/mysql/general.log

Genel sorgu günlüğü, sunucuya gönderilen her SQL ifadesini kaydeder. Bunu, belirli ve zaman sınırlı bir tanı nedeni olmaksızın üretimde etkinleştirmeyin. Yoğun bir sunucuda bu günlük saatte gigabaytlarca büyüyebilir ve performans düşüşüne neden olabilir. Kısaca etkinleştirin, sorunu yeniden oluşturun, ardından hemen devre dışı bırakın.

mysql -u root -e "SET GLOBAL general_log = 'ON'; SET GLOBAL general_log_file = '/var/lib/mysql/general.log';"
# ... reproduce the issue ...
mysql -u root -e "SET GLOBAL general_log = 'OFF';"

Sistem Günlük Dosyaları

Sistem Mesajları Günlüğü

Konum: /var/log/messages

Çekirdek ve sistem arka plan programı mesaj günlüğü. Donanım hataları (disk G/Ç hataları, bellek ECC hataları), OOM (Bellek Yetersizliği) öldürücü olayları, ağ arayüzü durum değişiklikleri ve çekirdek modülü yükleme olayları burada görünür. Bir sunucu yanıt vermez hale geldiğinde veya beklenmedik şekilde yeniden başladığında kontrol edilecek ilk günlük budur.

OOM öldürücü olaylarını kontrol etme (bellek tükenmesi nedeniyle sunucunun sessizce süreçleri öldürmesi):

grep -i "oom|killed process|out of memory" /var/log/messages | tail -20

Sürücü arızasına işaret edebilecek disk G/Ç hatalarını kontrol etme:

grep -i "I/O error|blk_update_request|ata.*error" /var/log/messages | tail -20

Güvenli Kimlik Doğrulama Günlüğü

Konum: /var/log/secure

Tüm PAM tabanlı kimlik doğrulama olaylarını kaydeder: SSH girişleri (başarılı ve başarısız), sudo komut yürütme, su denemeleri ve cron tarafından başlatılan kimlik doğrulama. Bu, SSH güvenlik adli analizi için birincil günlüktür.

Başarısız SSH giriş sayısına göre en çok saldıran IP’leri belirleme:

grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20

Sunucuda yürütülen tüm sudo komutlarını denetleme:

grep "sudo:" /var/log/secure | grep "COMMAND" | tail -50

Gerçek dünya uç durumu: sshd_config içinde UseDNS yes bulunan sunucularda, başarısız giriş girişleri IP adresleri yerine ana bilgisayar adlarını gösterebilir; bu da yukarıdaki IP çıkarma awk kalıbını bozar. sshd_config ayarınızı doğrulayın ve alan dizinini buna göre ayarlayın.

Çekirdek Halka Tamponu

Konum: Yalnızca çalışma zamanı — dmesg aracılığıyla erişilir

Çekirdek halka tamponu kalıcı bir dosya değildir, ancak syslog başlatılmadan önce önyükleme sırasında veya hemen sonrasında gerçekleşen donanım düzeyindeki olayları tanılamak için önemlidir. systemd tabanlı sistemlerde (CentOS 7+, CloudLinux 7+), kalıcı çekirdek günlükleri şu yolla kullanılabilir:

journalctl -k --since "1 hour ago"

FTP Günlük Dosyaları

ProFTPd Günlüğü

Konum: /var/log/proftpd/proftpd.log

ProFTPd, cPanel ortamlarında varsayılan FTP arka plan programıdır. Bu günlük tüm FTP oturumu olaylarını kaydeder: kimlik doğrulama denemeleri, dizin gezintisi, dosya yüklemeleri, indirmeler ve bağlantı kesmeleri.

Tüm başarısız FTP giriş denemelerini bulma:

grep "USER|PASS" /var/log/proftpd/proftpd.log | grep -i "failed|incorrect" | tail -30

Büyük dosya yüklemelerini belirleme (potansiyel kötü amaçlı yazılım hazırlama):

grep "STOR" /var/log/proftpd/proftpd.log | awk '{print $NF, $0}' | sort -rn | head -20

Pure-FTPd Günlüğü

Konum: /var/log/pureftpd.log

Pure-FTPd günlükleri, bazı yapılandırmalarda varsayılan olarak syslog’a yazılır; bu, girişlerin özel bir dosya yerine /var/log/messages içinde görünebileceği anlamına gelir. Etkin günlük hedefini doğrulayın:

grep "VerboseLog|AltLog" /etc/pure-ftpd.conf

PHP ve Uygulama Düzeyindeki Günlükler

PHP Hata Günlüğü

cPanel ortamlarındaki PHP hataları, kullanılan PHP işleyicisine bağlı olarak birden fazla konumda günlüğe kaydedilebilir:

PHP-FPM havuz günlüğü yolu, PHP sürüm numarasını içerir. EasyApache 4 tarafından yönetilen PHP 8.2 için:

tail -f /opt/cpanel/ea-php82/root/usr/var/log/php-fpm/error.log

Hesap başına PHP hata günlüğü, hesabın php.ini veya .htaccess dosyasına aşağıdakiler eklenerek etkinleştirilebilir:

log_errors = On
error_log = /home/username/logs/php_errors.log

cPanel’e Özgü Hizmet ve Güvenlik Günlükleri

cPanel Hizmet Yöneticisi Günlüğü

Konum: /usr/local/cpanel/logs/safeapacherestart_log

cPanel’in hizmet yöneticisi tarafından tetiklenen her Apache yeniden başlatma olayını, yeniden başlatmanın nedenini ve başarılı olup olmadığını kaydeder. Apache kesintisini yapılandırma değişiklikleriyle ilişkilendirmek için kullanışlıdır.

cPanel Yedekleme Günlüğü

Konum: /usr/local/cpanel/logs/cpbackup/

Her yedekleme çalıştırması bu dizinde hesap başına bir günlük dosyası oluşturur. Bir yedekleme sessizce başarısız olduğunda, bu dizin disk alanı sorunu, veritabanı dökümü hatası veya izin sorunu olsun belirli hatayı içerir.

ls -lt /usr/local/cpanel/logs/cpbackup/ | head -10
grep -i "error|fail" /usr/local/cpanel/logs/cpbackup/username.log

cPanel AutoSSL Günlüğü

Konum: /var/cpanel/logs/autossl/

AutoSSL, cPanel’in otomatik Let’s Encrypt / Sectigo sertifika sağlama sistemidir. SSL sertifika yenileme başarısız olduğunda, ayrıntılı neden — DCV hatası, hız sınırlaması, alan adı doğrulama uyuşmazlığı — burada kaydedilir. Bu günlük, tarayıcı uyarılarına neden olmadan önce HTTPS sertifika sona erme sorunlarını tanılamak için kritik öneme sahiptir.

ls -lt /var/cpanel/logs/autossl/ | head -5
tail -100 /var/cpanel/logs/autossl/$(ls -t /var/cpanel/logs/autossl/ | head -1)

Birden fazla alan adında SSL sertifikalarını yönetiyorsanız veya AutoSSL’nin sağladığının ötesinde sertifikalara ihtiyacınız varsa, özel bir sağlayıcıdan SSL Sertifikaları, Let’s Encrypt’in sunmadığı genişletilmiş doğrulama ve joker karakter seçenekleri sunar.

Günlük Dosyası Karşılaştırma Referansı

Komut Satırı Günlük Analizi Teknikleri

Gerçek Zamanlı ve Geçmiş Analiz için Temel Komutlar

Bir günlüğü gerçek zamanlı olarak takip etme (en yaygın sistem yöneticisi iş akışı):

tail -f /var/log/exim_mainlog

multitail kullanarak birden fazla günlüğü aynı anda takip etme (yum install multitail aracılığıyla yükleyin):

multitail /usr/local/apache/logs/error_log /var/log/exim_mainlog

Belirli bir alandan benzersiz değerleri çıkarma ve sayma:

awk '{print $1}' /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn | head -20

Sıkıştırılmış döndürülmüş günlük arşivlerinde arama yapma:

zgrep "keyword" /var/log/exim_mainlog.*.gz

Belirli bir zaman aralığındaki günlük girişlerini filtreleme:

awk '/15/Jan/2024:14:00/,/15/Jan/2024:15:00/' /usr/local/apache/logs/access_log

HTTP durum kodu dağılımını sayma:

awk '{print $9}' /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn

cPanel’de Günlük Döndürme

cPanel, günlük dosyası boyutlarını yönetmek için logrotate kullanır. cPanel tarafından yönetilen günlükler için döndürme yapılandırması /etc/logrotate.d/ konumundadır. Apache günlükleri, genel erişim günlüğünü alan adı başına dosyalara da bölen cPanel’in kendi splitlogs mekanizması tarafından döndürülür.

Belirli bir hizmet için mevcut logrotate yapılandırmasını kontrol etme:

cat /etc/logrotate.d/syslog

Test için günlük döndürmeyi manuel olarak tetikleme:

logrotate -f /etc/logrotate.d/syslog

Kritik tuzak: Günlük döndürme yanlış yapılandırılmışsa veya disk alanı tükenmişse, günlük dosyaları tüm bölümü doldurarak tüm hizmetlerin aynı anda uyarı vermeksizin başarısız olmasına neden olabilir. /var/log ve /usr/local/apache/logs içeren bölümdeki disk kullanımını standart bir operasyonel uygulama olarak izleyin.

Merkezi Günlük Yönetimi ve Uyarı

Üretim ortamları için — özellikle bir VPS Hosting veya Dedicated Server üzerinde — manuel günlük incelemesine güvenmek ölçekte yetersizdir. Aşağıdaki yaklaşımlardan birini uygulayın:

rsyslog yönlendirmesiyle günlük toplama: Günlükleri merkezi bir syslog sunucusuna veya bir SIEM platformuna iletmek için /etc/rsyslog.conf yapılandırın. Bu, sunucunun kendisi ele geçirilse bile günlükleri korur.

ELK Stack (Elasticsearch, Logstash, Kibana): Filebeat aracıları aracılığıyla cPanel günlüklerini alın, Logstash ardışık düzenleriyle ayrıştırın ve Kibana’da kalıpları görselleştirin. Bu yaklaşım, aylarca süren günlük geçmişinde saniyeler içinde tam metin araması yapılmasını sağlar.

Fail2ban entegrasyonu: Fail2ban, /var/log/secure ve /var/log/exim_mainlog dosyalarını okur ve saldıran IP’leri engellemek için otomatik olarak iptables kuralları oluşturur. cPHulk’tan bağımsız olarak çalışır ve ek bir savunma katmanı sağlar.

Apache günlük analizi için GoAccess: GoAccess, tam bir ELK dağıtımı gerektirmeden Apache erişim günlüklerinden HTML raporları üreten gerçek zamanlı terminal tabanlı bir günlük analizörüdür:

goaccess /usr/local/apache/logs/access_log --log-format=COMBINED -o /var/www/html/report.html

Birden fazla cPanel hesabını veya bayi kurulumlarını bir cPanel’li VPS üzerinde yöneten yöneticiler, merkezi günlük görünürlüğünden önemli ölçüde yararlanır; çünkü bireysel hesap günlükleri aksi takdirde her ana dizin altında izole edilmiş olur.

E-posta Altyapısı Günlük İlişkilendirmesi

cPanel ortamlarında en az takdir edilen tanı tekniklerinden biri, bir e-posta güvenlik olayının tam yaşam döngüsünü izlemek için Exim günlüklerini Dovecot günlükleri ve sistem kimlik doğrulama günlüğüyle çapraz referanslamaktır.

Senaryo: Bir kullanıcı, hesabının yazmadığı spam gönderdiğini bildiriyor.

Adım 1 — Hesapla ilişkili Exim mesaj kimliklerini belirleme:

grep "U=username|from=<.*@userdomain.com>" /var/log/exim_mainlog | grep "<=" | head -20

Adım 2 — Gönderimin bir web uygulamasından (PHP mail()) mı yoksa kimliği doğrulanmış SMTP’den mi kaynaklandığını kontrol etme:

grep "1rPqXY-0003aB-Kc" /var/log/exim_mainlog | grep -E "P=esmtpa|P=local"

P=esmtpa kimliği doğrulanmış SMTP gönderimini gösterir. P=local veya P=pipe yerel bir komut dosyasını (muhtemelen güvenliği ihlal edilmiş bir web uygulaması) gösterir.

Adım 3 — P=esmtpa ise, Dovecot veya Exim kimlik doğrulama günlüğünden kaynak IP’yi bulma:

grep "username" /var/log/dovecot.log | grep "Login" | tail -20

Adım 4 — Bu IP’yi SSH etkinliği için /var/log/secure ve kontrol paneli girişleri için cPanel erişim günlüğüyle çapraz referanslama.

Bu dört adımlı ilişkilendirme tekniği, ihlalin kimlik bilgisi hırsızlığı mı, savunmasız bir web uygulaması mı yoksa kaba kuvvetle kırılmış bir SMTP hesabı mı olduğunu kesin olarak yanıtlar — ve bu ayrım, düzeltme yolunu tamamen belirler.

Kendi posta altyapısını işleten kuruluşlar için, özel günlük izlemeli düzgün yapılandırılmış bir E-posta Hosting ortamı, hesaplar arası posta itibarı hasarını önlemek için gereken izolasyonu sağlar.

Alan Adı ve DNS ile İlgili Günlük Değerlendirmeleri

DNS çözümleme hataları genellikle özel bir DNS günlüğü yerine uygulama günlüklerinde hata olarak kendini gösterir. cPanel’in DNS için kullandığı Named (BIND), varsayılan olarak /var/log/messages konumuna günlük yazar.

BIND hatalarını kontrol etme:

grep "named" /var/log/messages | grep -i "error|failed|refused" | tail -20

DNS yayılım sorunları yeni kaydedilmiş veya aktarılmış alan adlarını etkilediğinde, BIND günlüğünü cPanel alan adı yapılandırmasıyla ilişkilendirmek, sorunun bir bölge dosyası hatası mı yoksa kayıt şirketi düzeyinde yayılım gecikmesi mi olduğunu izole etmeye yardımcı olur. Alan adı kaydı ve DNS’i aynı platform üzerinden yönetiyorsanız, entegre DNS yönetimiyle Alan Adı Kaydı bu tanı zincirini basitleştirir.

Pratik Karar Matrisi: Önce Hangi Günlüğe Bakılmalı

Temel Teknik Çıkarımlar

• Her zaman önce alan adı başına günlükleri kontrol edin (/home/username/logs/), genel Apache günlüklerinden önce — aynı verileri çok daha az gürültüyle içerirler.
• Boş olmayan bir /var/log/exim_paniclog bir P1 olayıdır — Exim posta kuyruğunu tamamen işlemeyi durdurmuş olabilir.
• /usr/local/cpanel/logs/cphulkd.log konumundaki cPHulk günlüğü, herhangi bir kilitlenme senaryosu için doğru ilk duraktır, /var/log/secure değil.
• MySQL yavaş sorgu günlüğünü etkinleştirin (long_query_time = 1) herhangi bir üretim veritabanı sunucusunda — sağladığı performans zekası, minimal ek yükü değer.
• Exim’in P= alanını Dovecot kimlik doğrulama günlükleriyle çapraz ilişkilendirerek bir spam olayının kimlik bilgisi hırsızlığından mı yoksa güvenliği ihlal edilmiş bir web uygulamasından mı kaynaklandığını kesin olarak belirleyin.
• Günlük döndürme yanlış yapılandırması sessiz bir hata modudur — dolu bir /var/log bölümü, uyarı vermeksizin tüm hizmetleri aynı anda çökertir.
• zgrep döndürülmüş .gz arşivlerinde çalışır — geçmiş günlük analizi dosyaları manuel olarak açmayı gerektirmez.
• rsyslog aracılığıyla merkezi günlük yönlendirmesi, hassas veriler işleyen herhangi bir sunucu için minimum uygulanabilir güvenlik duruşudur — yerel günlükler, kök erişim kazanan bir saldırgan tarafından silinebilir.

Sıkça Sorulan Sorular

cPanel hata günlükleri nerede bulunur?

Birincil cPanel uygulama hata günlüğü /usr/local/cpanel/logs/error_log konumundadır. Apache web sunucusu hataları /usr/local/apache/logs/error_log konumundadır ve hesap başına PHP hataları /home/username/logs/domain.com-error_log konumundadır. Her hizmet, ayrı bir yolda kendi günlük dosyasını tutar.

Exim günlüklerinde belirli bir e-posta mesajını nasıl izlerim?

Exim’in işlediği her mesaj, /var/log/exim_mainlog içinde görünen benzersiz bir mesaj kimliği alır. O mesajla ilişkili her günlük girişini, kabulden nihai iletim veya geri dönüşe kadar almak için grep "MESSAGE_ID" /var/log/exim_mainlog komutunu çalıştırın.

Exim panik günlüğüm neden boş değil ve ne yapmalıyım?

Boş olmayan bir /var/log/exim_paniclog, Exim’in ölümcül bir hatayla karşılaştığını gösterir — genellikle bir yapılandırma ayrıştırma hatası, TLS kütüphane sorunu veya 25 numaralı porta bağlanamama. Panik günlüğü girişlerini okuyun, ardından Exim’in yapılandırma sözdizimini exim -bV ile kontrol edin ve 25 numaralı portun ss -tlnp | grep :25 kullanılarak başka bir süreç tarafından engellenmediğini doğrulayın.

Hangi PHP betiğinin Apache üzerinden spam gönderdiğini nasıl bulurum?

Exim ana günlüğünü Apache kullanıcısı tarafından gönderilen mesajlar için filtreleyin: grep "U=nobody" /var/log/exim_mainlog. Ardından posta işlevini tetikleyen URL’yi belirlemek için zaman damgalarını Apache erişim günlüğü girişleriyle çapraz referanslayın. php.ini içinde etkinleştirilmişse X-PHP-Originating-Script başlığı da tam komut dosyası dosyasını tanımlayacaktır.

Bir sunucunun SSH kaba kuvvet saldırısı altında olup olmadığını kontrol etmenin en hızlı yolu nedir?

Deneme sayısına göre en çok saldıran IP adreslerini görmek için grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10 komutunu çalıştırın. Ardından /usr/local/cpanel/logs/cphulkd.log kontrol ederek veya cPHulk veritabanını doğrudan sorgulayarak cPHulk’un bunları zaten engelleyip engellemediğini doğrulayın.