Sunucuda loglar ve giriş denetimi
Loglar üç soruyu yanıtlar: ne bozuldu, sunucuya kim girdi ve ne yaptı. Bu yanıtlar ancak loglar açıksa, yeterince uzun saklanıyorsa ve ele geçirilmiş olabilecek sunucunun kendisinde durmuyorsa elinizdedir. Linux'ta logların nerede bulunduğunu, girişleri hangi komutların gösterdiğini, rotasyonun nasıl ayarlandığını ve bir olaydan sonra inceleyecek bir şey kalması için önceden ne yapılması gerektiğini ele alıyoruz.
systemd kullanan Linux'ta loglar iki sistem tarafından yazılır. systemd'nin journald hizmeti tüm hizmetlerin, çekirdeğin ve girişlerin mesajlarını ikili bir günlükte toplar. rsyslog kuruluysa aynı mesajları /var/log altındaki metin dosyalarına dağıtır. Web sunucusu, veritabanı ve Docker ise kendi loglarını tutar. Neyin nerede durduğunu bir olay sırasında değil, ondan önce bilmek gerekir.
Loglar nerede tutulur?
- journald.
journalctlkomutuyla okunur./var/log/journaldizini varsa günlük diskte saklanır, yoksa yalnızca bellekte tutulur ve yeniden başlatmada kaybolur (journald.conf,Storage=autoparametresi). Yeni bir sunucuda bunu kontrol edin:ls /var/log/journal. Dizin yoksa oluşturun ve hizmeti yeniden başlatın:systemctl restart systemd-journald. - Sistem dosyaları. Ubuntu'da girişler ve sudo
/var/log/auth.logdosyasına, genel mesajlar/var/log/syslogdosyasına yazılır. AlmaLinux ve Rocky Linux'ta bunlar/var/log/secureve/var/log/messagesdosyalarıdır. Debian 12 ve sonrasında rsyslog varsayılan olarak kurulmaz ve her şey yalnızca journald'de bulunur. - Web sunucusu. nginx
/var/log/nginx/access.logveerror.logdosyalarına yazar; Apache ise Debian ve Ubuntu'da/var/log/apache2/, AlmaLinux'ta/var/log/httpd/dizinine. Erişim logu her isteği gösterir: adres, zaman, yol, yanıt kodu, boyut, tarayıcı. Alanların bileşimi log_format yönergesiyle belirlenir; site bir CDN'in arkasındaysa ziyaretçinin gerçek adresinin iletilmesini ayarlayın, aksi halde logda yalnızca CDN adresleri görünür (ayrıntılar CDN: bir siteye ne zaman gerekir yazısında). - Uygulamalar ve Docker. Veritabanları
/var/logaltındaki kendi dizinlerine, konteynerler isedocker logskomutuyla okunan Docker dosyalarına yazar.
Çoğu durumda yeten birkaç journalctl komutu: journalctl -u nginx --since "1 hour ago" tek bir hizmetin son bir saatlik mesajlarını, journalctl -p err -b son açılıştan bu yana hataları, journalctl -f yeni mesajların akışını, journalctl --disk-usage ise günlüğün kapladığı alanı gösterir.
Sunucuya kim girdi?
SSH ile yapılan her giriş; kullanıcı adı, adres ve giriş yöntemiyle (anahtar ya da parola) birlikte bir kayıt bırakır. Başarılı girişleri şöyle görebilirsiniz:
- journald'de:
journalctl -u ssh --since today | grep Accepted(AlmaLinux'ta hizmetin adısshd); - dosyada:
grep Accepted /var/log/auth.logya da/var/log/secure; - özet olarak:
lastkomutu girişleri ve yeniden başlatmaları,lastbbaşarısız denemeleri gösterir.
Debian 13'te last, lastb ve lastlog komutları artık yok: eski dosya biçimleri 2038 sonrasındaki tarihleri saklayamıyor. Bunların yerine wtmpdb ve lastlog2 paketleri öneriliyor (Debian 13 sürüm notları). Günlükteki Accepted kayıtları ise her sürümde kalır.
Neye bakılmalı? Tanımadığınız adreslerden ve alışılmadık saatlerde yapılan girişlere. Yalnızca anahtarla girişi ayarladıysanız parolayla yapılan girişlere: bu, ayarın uygulanmadığı anlamına gelir. sudo ile çalıştırılan komutlara: auth.log ve journald her biri için kimin neyi çalıştırdığını kaydeder. ~/.ssh/authorized_keys içindeki yeni anahtarlara ve /etc/passwd içindeki yeni kullanıcılara: bunlar sunucuya daha sonra geri dönebilmek için eklenir. Dosya ve komut değişikliklerinin ayrıntılı denetimi gerekiyorsa Linux'ta auditd denetim alt sistemi vardır, ancak kuralları ayrıca ayarlanmalıdır ve diskte yer kaplar.
fail2ban: SSH dışında ne sağlar?
fail2ban logları okur ve girişte art arda hata yapan adresleri geçici olarak engeller. Kurulumu ve SSH koruması VPS satın aldıktan sonra ilk 10 adım: güvenlik yazısında anlatılıyor. Varsayılan olarak bir adres, 10 dakika içinde 5 hatadan sonra 10 dakikalığına engellenir (jail.conf). Eklemeye değer olanlar:
- Tekrarlayanlar için uzun engeller.
recidivekuralı fail2ban'in kendi logunu okur ve bir gün içinde birkaç kez yakalanan adresi bir haftalığına engeller.bantime.increment = trueparametresi her yeni engelde süreyi ikiye katlar. - Web sunucusu kuralları. Hazır
nginx-http-auth,nginx-limit-reqvenginx-botsearchkuralları, korumalı sayfalardaki parola hatalarına, istek sıklığı sınırının aşılmasına ve var olmayan adreslerin taranmasına tepki verir. - Kendi adresleriniz istisnalarda. Ofisin sabit adresini içeren
ignoreipparametresi sizi kendinizi engellemekten kurtarır.
fail2ban binlerce adresten gelen dağıtık saldırılara karşı korumaz ve anahtarla girişin yerini tutmaz. Denetim açısından asıl faydası logu kısaltmasıdır: logda on binlerce aynı parola tahmini denemesi değil, anlamlı olaylar kalır. Engellenen adreslerin listesini fail2ban-client status sshd gösterir.
Rotasyon ve disk alanı
Loglar sürekli büyür, ucuz VPS'lerde ise disk küçüktür. accsly.io kataloğuna göre Kasım 2026 itibarıyla 1 GB bellekli VPS paketlerinde ortanca disk 20 GB, VPS paketlerinin %9'unda ise disk 20 GB veya daha az. Yoğun bir sitenin erişim logu ya da döngü içinde hata yazan bir konteyner böyle bir diski günler içinde doldurur; ardından veritabanı ve sitenin kendisi çalışmaz hale gelir.
- journald varsayılan olarak dosya sisteminin en fazla %10'unu ve en fazla 4 GB kaplar. Kendi sınırınızı
/etc/systemd/journald.confiçindekiSystemMaxUse=parametresiyle, saklama süresini ise varsayılan olarak kapalı olanMaxRetentionSec=parametresiyle belirleyebilirsiniz. Bir defalığına yer açmak için:journalctl --vacuum-size=500Mya da--vacuum-time=30d. - Metin dosyalarını logrotate,
/etc/logrotate.d/içindeki kurallara göre döndürür. Ubuntu 24.04'te sistem logları haftada bir döndürülür ve 4 eski dosya saklanır, yani yaklaşık bir ay. AlmaLinux 9 paketindeki nginx logları günde bir döndürülür, 10 eski dosya saklanır.rotate,dailyveyaweekly,compressvemaxsizeparametreleri süreyi, sıkıştırmayı ve boyuta göre rotasyonu değiştirir.copytruncatemodu dosyayı yeniden açamayan programlara uygundur, ancak belgelere göre satır kaybedebilir. Bir kuralı değişiklik yapmadan denemek için:logrotate -d /etc/logrotate.d/nginx. - Docker varsayılan olarak konteyner loglarını boyut sınırı olmadan yazar (json-file sürücüsü).
/etc/docker/daemon.jsoniçindemax-sizevemax-filedeğerlerini belirleyin ve konteynerleri yeniden oluşturun: ayarlar yalnızca yeni konteynerlere uygulanır. Ayrıntılar VPS'te Docker: nereden başlamalı yazısında.
Diski neyin doldurduğunu bulmak için: df -h dolu bölümü, du -xh /var/log | sort -h | tail en büyük dizinleri gösterir. Bir hizmetin açık tuttuğu log dosyasını silmeyin: hizmet yeniden başlatılana kadar yer boşalmaz. Dosyayı truncate -s 0 komutuyla boşaltın. Disk dolmadan önce uyarı almak daha iyidir; bunun için Sunucu izleme: çalışma süresi, yük ve uyarılar yazısına bakın.
Olay incelemesi için loglar nasıl saklanır?
Sunucu ele geçirildiyse root yetkisi kazanan saldırganın ilk yaptığı iş logları düzenlemek ya da silmektir. Bu yüzden sunucudan anında çıkan bir kopya, sunucunun kendisindeki tüm saklama ayarlarından daha değerlidir.
- Logları başka bir sunucuya gönderin. rsyslog mesajları ağ üzerinden iletebilir, journald için ise systemd-journal-upload hizmeti vardır. Alıcı sunucu, diski daha büyük ayrı ve ucuz bir VPS ya da Loki, Graylog veya OpenSearch gibi bir log toplama sistemi olabilir; buna uygun paketler Elasticsearch için VPS seçkisinde toplanmış.
- Ne kadar saklayacağınıza karar verin. Olayların çoğunu incelemek için 30–90 günlük loglar gerekir: sızma çoğu zaman gerçekleştiği gün fark edilmez. Sunucunun kendisinde bir iki hafta yeterlidir, geri kalanı toplama sunucusunda ya da arşivde durur.
- Saati senkronize edin. Doğru saat olmadan farklı sunuculardaki olayları eşleştiremezsiniz.
timedatectlçıktısını kontrol edin: "System clock synchronized" satırı yes göstermelidir. - Loglarda gereğinden fazlasını tutmayın. Parolalar, token'lar ve tam kart numaraları loga düşmemelidir. IP adresleri ve kullanıcı adları hem GDPR'a hem de Türkiye'deki 6698 sayılı KVKK'ya göre kişisel veri sayılabilir; bu yüzden saklama süresini kişisel verilerin işlenmesi politikanızda belirtin ve süre dolunca logları silin. Ayrıntılar GDPR ve hosting seçimi yazısında.
- Bir olayda önce saklayın, sonra onarın. Sistemi yeniden kurmadan önce logları kopyalayın ve sağlayıcıda diskin anlık görüntüsünü alın. Anlık görüntülerin ve yedeklerin nasıl işlediği VPS yedekleri: stratejiler ve araçlar yazısında anlatılıyor.
Loglar yalnızca inceleme için değil, uyarılar için de gerekiyorsa (500 hatalarındaki bir sıçrama ya da root olarak giriş gibi), metriklerle birlikte ayrı bir izleme sunucusunda toplanır. Bu iş için paketler İzleme için VPS seçkisinde.