Sunucuma Kim Giriş Yaptı? last, lastb ve auth.log İnceleme Rehberi

Sunucunuzun IP adresi bir spam kara listesine düştü, hosting sağlayıcınızdan uyarı e-postası geldi ya da sitede olmaması gereken bir dosya buldunuz. İlk refleks doğru: makineye bağlanıp kimin, ne zaman ve nereden girdiğini görmek. Ama sudo lastb yazdığınızda ekranı yüzlerce satır dolduruyor — root, admin, test, oracle, postgres... Çin'den, Rusya'dan, Brezilya'dan. Bu manzara karşısında iki yanlış tepki verilebilir: ya "hacklendim" diye panik yapmak ya da "her sunucuda böyle" deyip kapatmak.

İkisi de yanlıştır, çünkü asıl soru bu değildir. İnternete açık her SSH portu günde binlerce otomatik deneme alır; bu gürültüdür, olayın kendisi değildir. Asıl soru şudur: bu denemelerden herhangi biri başarılı oldu mu, olduysa hangi kullanıcıyla, hangi yöntemle ve o oturumda ne yapıldı?

Bu rehber bir komut listesi değil, bir yorum kılavuzudur. last, lastb, auth.log ve journalctl çıktısındaki satırları tek tek okuyup hangisinin rutin tarama, hangisinin gerçek bir yetkisiz erişim olduğunu ayırt edeceğiz. Sonra da şüpheli bir oturum bulduğunuzda ilk on dakikada ne yapmanız gerektiğini adım adım göreceğiz.

Giriş Kayıtları Nerede Tutulur? wtmp, btmp ve auth.log#

Linux'ta "kim girdi" sorusunun cevabı tek bir dosyada durmaz. Üç ayrı kaynak vardır ve her biri farklı bir soruya cevap verir:

İlk dördü ikili biçimdedir; cat ile açarsanız anlamsız karakterler görürsünüz, mutlaka kendi komutlarıyla okunmalıdır. Beşincisi ise asıl detayın olduğu yerdir: parola mı kullanıldı yoksa anahtar mı, hangi kullanıcı adı denendi, bağlantı hangi aşamada koptu — bunların hepsi burada yazar.

Dağıtıma göre dosya adı değişir:

• Debian / Ubuntu: /var/log/auth.log
• RHEL / AlmaLinux / Rocky / CentOS: /var/log/secure

Dikkat: Yeni Debian ve bazı minimal Ubuntu kurulumlarında rsyslog paketi gelmez; bu durumda auth.log dosyası hiç oluşmaz ve tüm kayıt systemd journal'ında tutulur. Dosyayı bulamıyorsanız sunucunuz hacklenmiş değildir — journalctl bölümüne geçin.

last Komutu: Kimin Ne Zaman Girdiğini Okumak#

last, wtmp dosyasını okuyup başarılı oturumları en yeniden eskiye doğru listeler.

# Son 25 başarılı oturum, tam tarih ve IP adresleriyle
sudo last -i -F -n 25

# Yalnızca belirli bir kullanıcının girişleri
sudo last -i deploy

# Arşivlenmiş (döndürülmüş) kayıtları da oku
sudo last -i -f /var/log/wtmp.1

-i bayrağı ters DNS çözümlemesi yapmadan ham IP gösterir; bu hem daha hızlıdır hem de saldırganın kontrol ettiği bir PTR kaydının sizi yanıltmasını engeller. -F ise yılı da içeren tam tarihi basar.

Tipik bir çıktı şöyledir:

deploy   pts/0    88.230.14.9    Mon Aug 17 09:14:02 2026   still logged in
deploy   pts/1    88.230.14.9    Sun Aug 16 21:03:11 2026 - 22:41:55 (01:38)
root     pts/0    45.155.205.233 Sun Aug 16 03:22:40 2026 - 03:29:14 (00:06)
reboot   system boot 6.8.0-41    Sat Aug 15 20:55:02 2026   still running
deploy   pts/0    88.230.14.9    Fri Aug 14 10:02:33 2026 - 18:44:07 (08:41)

Sütunlar sırasıyla: kullanıcı, terminal, kaynak IP, başlangıç zamanı, bitiş zamanı ve süre. Okurken şu üç şeye bakın:

• Terminal sütunu. pts/N uzaktan bir SSH oturumudur. tty1-tty6 fiziksel/konsol girişidir; bir VDS'te sağlayıcının VNC konsolundan girildiğini gösterir. system boot satırı yeniden başlatmadır.
• Kaynak IP. Kendi IP'nizi tanıyor olmalısınız — bir sonraki bölümde bunu nasıl netleştireceğinizi anlatıyoruz.
• Süre. Altı dakikalık bir root oturumu, sekiz saatlik bir çalışma oturumundan çok daha şüphelidir: içeri giren biri genellikle kalıcılık bırakıp hızla çıkar.

Yukarıdaki örnekte üçüncü satır alarm verir: root kullanıcısı, tanımadığınız bir IP'den, gecenin üçünde, kısa süreli bir oturum açmış. last bunun başarılı olduğunu söyler — çünkü wtmp yalnızca başarılı oturumları tutar.

lastlog ise farklı bir soruya cevap verir: hangi hesap en son ne zaman kullanıldı?

# Tüm kullanıcıların son giriş zamanı
lastlog

# 90 gündür hiç kullanılmamış hesaplar (temizlik adayları)
lastlog -b 90

Buradaki en değerli bulgu, hiç kullanılmaması gereken bir servis hesabının giriş yapmış olmasıdır. www-data, mysql veya backup gibi bir hesabın lastlog kaydında yakın tarihli bir oturum görüyorsanız durup incelemelisiniz.

lastb ve Başarısız Denemeler: Hangisi Gürültü, Hangisi Alarm?#

lastb, btmp dosyasını okur ve başarısız giriş denemelerini gösterir. Root yetkisi gerektirir.

sudo lastb -i -F -n 30

Bu komutun çıktısı internete açık her sunucuda kabarıktır ve bu normaldir. Ayırt etmenin pratik yolu, satırları tek tek okumak değil, desene bakmaktır:

# En çok deneme yapan IP'ler
sudo lastb -i | awk '{print $3}' | sort | uniq -c | sort -rn | head -10

# En çok denenen kullanıcı adları
sudo lastb | awk '{print $1}' | sort | uniq -c | sort -rn | head -10

Çıkan tabloyu şöyle yorumlayın:

Son satır kritiktir ve iki komutu birlikte okumayı gerektirir. lastb'de bir IP için 3-5 başarısız deneme görüp, hemen ardından last çıktısında aynı IP'den başarılı bir oturum görüyorsanız bu bir tarama değildir; birileri doğru parolayı bulmuştur.

# Şüphelendiğiniz IP'yi her iki kayıtta da arayın
sudo lastb -i | grep '45.155.205.233'
sudo last  -i | grep '45.155.205.233'

Sistematik tarama mantığının arka planı için kaba kuvvet saldırısı yazısı, bu gürültünün nasıl otomatik olarak kesileceği için ise Fail2ban kurulumu rehberi işinize yarar.

Not: btmp dosyası bazı sistemlerde sıfır boyutlu olabilir. Bu, "deneme yok" demek değildir; dosya logrotate ile döndürülmüş ya da PAM tarafında yazımı kapatılmış olabilir. Kesin yargıya varmadan auth.log veya journal'a bakın.

auth.log Satırlarını Yorumlamak: Parola mı, Anahtar mı?#

Asıl detay burada. auth.log içinde bir başarılı girişin nasıl gerçekleştiğini de görürsünüz ve bu ayrım, olayın ciddiyetini belirler.

# Başarılı girişleri süz
sudo grep -E 'Accepted (password|publickey|keyboard-interactive)' /var/log/auth.log

# Başarısız denemelerde en çok görülen IP'ler
sudo grep 'Failed password' /var/log/auth.log \
  | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' \
  | sort | uniq -c | sort -rn | head -10

# Arşivlenmiş sıkıştırılmış kayıtlarda da ara
sudo zgrep 'Accepted' /var/log/auth.log.*.gz

Karşılaşacağınız tipik satırlar ve anlamları:

Aug 17 09:14:02 web01 sshd[24581]: Accepted publickey for deploy from 88.230.14.9 port 51234 ssh2: ED25519 SHA256:9Xk2...
Aug 16 03:22:40 web01 sshd[8123]:  Accepted password for root from 45.155.205.233 port 40122 ssh2
Aug 16 03:11:05 web01 sshd[8110]:  Invalid user admin from 45.155.205.233 port 40120
Aug 16 03:11:07 web01 sshd[8110]:  Failed password for invalid user admin from 45.155.205.233 port 40120 ssh2
Aug 16 03:11:08 web01 sshd[8110]:  Connection closed by authenticating user root 45.155.205.233 port 40122 [preauth]
Aug 16 03:22:41 web01 sshd[8123]:  pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)

Satır satır okuyalım:

• Accepted publickey — anahtarla giriş. Sonundaki SHA256: parmak izi, hangi anahtarın kullanıldığını söyler. Bu değeri kendi anahtarlarınızla karşılaştırabilirsiniz; büyük avantajdır.
• Accepted password — parolayla giriş. Sunucunuzda parola girişini kapattığınızı sanıyorsanız bu satır tek başına bir bulgudur: ya yapılandırma değişmiş ya da sizin bilmediğiniz bir yol açık.
• Invalid user — sistemde olmayan bir kullanıcı adı denendi. Neredeyse her zaman bot taramasıdır; hedefli bir saldırgan gerçek kullanıcı adlarını dener.
• Failed password — kullanıcı var ama parola tutmadı.
• [preauth] ile biten satırlar — bağlantı kimlik doğrulama tamamlanmadan koptu. Bunlar giriş değildir; port tarayıcıları ve yarım kalan bağlantılar bu satırları üretir. Rutin gürültünün büyük kısmı budur.
• session opened for user ... (uid=0) — oturumun gerçekten açıldığını PAM tarafından doğrular. uid=0 görmek, root oturumu demektir.

Bir başarılı girişin ardından ne yapıldığını görmek için aynı dosyada sudo satırlarına bakın:

sudo grep 'sudo:' /var/log/auth.log | tail -40

Aug 16 03:23:02 web01 sudo: root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/usr/sbin/useradd -m -s /bin/bash svc
Aug 16 03:23:40 web01 useradd[8140]: new user: name=svc, UID=1003, GID=1003, home=/home/svc, shell=/bin/bash

Bu iki satır bir ihlalin imzasıdır: içeri giren kişi kalıcılık için yeni bir kullanıcı açmış. Kullanıcı ve grup kavramlarını tazelemek isterseniz Linux kullanıcı ve grup yönetimi yazısı yardımcı olur.

journalctl ile SSH Girişlerini Okumak#

systemd kullanan modern dağıtımlarda kayıtların asıl adresi journal'dır. Zaman aralığı filtrelemesi ve yapılandırılmış alanlar sayesinde grep'ten çok daha kullanışlıdır.

# Yalnızca sshd kayıtları, son 7 gün
sudo journalctl -t sshd -S "-7d"

# Belirli bir tarih aralığında başarılı girişler
sudo journalctl -t sshd -S "2026-08-15" -U "2026-08-18" -g "Accepted"

# Canlı takip
sudo journalctl -t sshd -f

# Önceki açılışa ait kayıtlar
sudo journalctl -t sshd -b -1

Ubuntu 24.04 tuzağı: Bu sürümde SSH artık soket etkinleştirmeyle (ssh.socket) çalışır ve her bağlantı ssh@0-... biçiminde ayrı bir birim üretir. Bu yüzden alışkanlıkla yazılan journalctl -u ssh.service komutu kayıtların çoğunu kaçırır. Doğru yöntem, birim yerine syslog etiketiyle filtrelemektir: journalctl -t sshd.

Kalıcı kayıt tutma da ayrı bir konudur: Storage=volatile ayarlı bir sistemde journal RAM'de tutulur ve yeniden başlatmayla silinir — yani olayı incelemeye başladığınızda kanıt kalmamış olabilir. Kalıcılığın nasıl açılacağı ve journal'ın diğer kullanımları için journalctl ile log yönetimi yazısına bakın.

Kendi IP'nizi Tanımak: Gürültüyü Ayıklamanın İlk Adımı#

İnceleme yaparken en çok vakit kaybettiren şey, kendi girişlerinizi yabancı sanmaktır. Türkiye'deki çoğu ev ve iş bağlantısı dinamik IP kullanır; geçen haftaki IP'niz bugünkünden farklıdır ve mobil hatta bağlandığınız her sefer başka bir adres alırsınız.

Şu üç adımı önce yapın:

# 1) Şu anki oturumunuzun kaynak IP'si (bağlıyken çalıştırın)
echo $SSH_CLIENT
who am i

# 2) Sunucudan görünen dış IP'niz
curl -s https://ifconfig.me; echo

# 3) Şu an açık olan tüm oturumlar
who -u
loginctl list-sessions

echo $SSH_CLIENT çıktısındaki ilk alan, sunucunun sizi gördüğü IP'dir. Bunu bir kenara not edin ve last çıktısını okurken referans alın. Ekibinizde birden çok kişi varsa kim hangi IP'den, hangi kullanıcı adıyla bağlanıyor listesini bir kez çıkarmak, sonraki her incelemeyi dakikalar yerine saniyeler sürer hâle getirir.

İkinci ayıklama katmanı zamandır. Kendi ekibinizin çalışma saatleri dışında, örneğin sabaha karşı üçte açılmış bir oturum, saat 14:00'te açılmış olandan çok daha fazla ilgiyi hak eder. Üçüncüsü kullanıcı adıdır: doğrudan root ile giriş yapılmışsa ve sizin politikanız sudo üzerinden çalışmaksa, o satır tek başına yeterli bir alarmdır.

Şüpheli Bir Oturum Buldum: İlk 10 Dakika#

Tanımadığınız bir IP'den başarılı bir giriş tespit ettiniz. Sıralama önemlidir; yanlış sırayla hareket etmek kanıtı yok eder.

1. Kanıtı önce kopyalayın. Makineyi kurcalamadan önce kayıtları dışarı alın. Saldırgan hâlâ içerideyse ilk yapacağı şey izlerini silmektir.

sudo tar czf /root/kanit-$(date +%F).tar.gz \
  /var/log/auth.log* /var/log/wtmp* /var/log/btmp* /var/log/syslog*
sudo journalctl -S "-14d" > /root/journal-$(date +%F).txt

Bu dosyaları başka bir makineye indirin.

2. Açık oturumları görün ve kesin.

who -u                 # PID sütununu not edin
sudo ss -tnp | grep :22   # aktif SSH bağlantıları
sudo pkill -9 -t pts/1    # ilgili terminali sonlandır
sudo loginctl terminate-session 7

3. Saldırgan IP'sini geçici olarak kapatın — ama kendinizi dışarıda bırakmayın:

sudo ufw deny from 45.155.205.233
# veya
sudo iptables -I INPUT -s 45.155.205.233 -j DROP

4. Yetkili anahtarları denetleyin. En sık bırakılan arka kapı budur; parolayı değiştirseniz bile anahtar durduğu sürece erişim devam eder.

sudo ls -la /root/.ssh/ /home/*/.ssh/
sudo cat /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys
sudo ssh-keygen -lf /root/.ssh/authorized_keys

Tanımadığınız her satırı silin. Kendi anahtarınızın parmak izini bilmiyorsanız yerel makinenizde ssh-keygen -lf ~/.ssh/id_ed25519.pub ile öğrenin; anahtar yönetiminin tamamı için SSH anahtarı oluşturma rehberine bakabilirsiniz.

5. Yetki yükseltme izlerini arayın.

# uid 0 olan tüm hesaplar — root'tan başkası olmamalı
awk -F: '$3==0 {print $1}' /etc/passwd

# Son 7 günde eklenen kullanıcılar
sudo grep -E 'useradd|usermod|groupadd' /var/log/auth.log

# sudoers dosyasında son değişiklik
sudo ls -la /etc/sudoers /etc/sudoers.d/

6. Zamanlanmış görevleri ve servisleri kontrol edin. Kalıcılığın ikinci favori yeri burasıdır.

for u in $(cut -f1 -d: /etc/passwd); do
  echo "== $u"; sudo crontab -l -u "$u" 2>/dev/null
done
sudo ls -la /etc/cron.d/ /etc/cron.daily/
sudo systemctl list-units --type=service --state=running

7. Parolaları ve anahtarları döndürün, sonra web tarafına geçin. Sunucuda bir web uygulaması varsa ihlalin başlangıç noktası büyük olasılıkla oradadır ve temizlik ayrı bir süreçtir; hacklenmiş site kurtarma yazısı bu kısmı adım adım anlatır.

En önemli kural: Kök nedeni bulmadan "temizledim" demeyin. Nasıl girildiği bilinmiyorsa aynı yoldan tekrar girilir. Şüphe ciddiyse en güvenli yol, temiz bir sunucuya yedeklerden kurulum yapıp eski makineyi kapatmaktır.

Bir Daha Yaşanmaması İçin: Kayıtları Anlamlı Tutmak#

İnceleme sırasında en sık duyulan cümle şudur: "Kayıtlar dönmüş, o güne ait bir şey kalmamış." Olay yaşandıktan sonra saklama süresini uzatmak işe yaramaz; bunu önceden yapmak gerekir.

• Saklama süresini uzatın. Varsayılan logrotate ayarları çoğu dağıtımda dört haftalık kayıt tutar. İhlaller genellikle haftalar sonra fark edildiği için bu süre kısadır; ayrıntılar için logrotate ile log yönetimi yazısına bakın.
• Kayıtları sunucu dışına gönderin. Root yetkisi ele geçiren biri yerel kayıtları silebilir; uzak bir kayıt sunucusundaki kopyayı silemez. Tek sunucuda bile olsanız günlük bir kopyayı yedek alanına atmak büyük fark yaratır.
• Parola girişini tamamen kapatın. sshd_config içinde PasswordAuthentication no ve PermitRootLogin prohibit-password ayarları, Failed password satırlarını kökten yok eder. SSH portunu değiştirmek ise güvenlik sağlamaz ama kayıt gürültüsünü ciddi biçimde azaltır ve gerçek olayları görünür kılar.
• Dosya ve komut düzeyinde iz bırakın. Kim hangi dosyaya dokundu sorusuna cevap veren auditd ile sistem denetimi kurulumu, SSH kayıtlarının göremediği katmanı tamamlar.
• Haftada bir bakın. İki komutluk bir alışkanlık yeter: sudo last -i -n 20 ve sudo lastlog. Tanımadığınız bir satırı fark etmenin tek yolu, tanıdık hâlin nasıl göründüğünü biliyor olmaktır.

Sıkça Sorulan Sorular#

last komutu neden bazı girişleri göstermiyor?#

last, yalnızca /var/log/wtmp dosyasına yazılan oturumları gösterir. SFTP/SCP aktarımları, ssh sunucu "komut" biçiminde çalıştırılan tek seferlik komutlar ve bazı otomasyon bağlantıları interaktif oturum açmadıkları için bu dosyaya kaydedilmez. Ayrıca wtmp düzenli olarak döndürülür; eski kayıtlar /var/log/wtmp.1 dosyasındadır. Tam görünüm için auth.log veya journalctl -t sshd çıktısına bakın.

lastb çıktısında yüzlerce başarısız deneme var, hacklendim mi?#

Hayır. İnternete açık bir SSH portu günde binlerce otomatik deneme alır ve bunların büyük çoğunluğu root, admin, test gibi genel kullanıcı adlarını deneyen botlardır. Endişelenmeniz gereken durum, bu denemelerin ardından last çıktısında aynı IP'den başarılı bir oturum görmenizdir. Bir de gerçek kullanıcı adlarınızın denendiğini görürseniz durum hedefli saldırıdır ve ciddiye alınmalıdır.

auth.log dosyası sunucumda yok, ne yapmalıyım?#

İki olasılık var. Birincisi dağıtım farkı: RHEL, AlmaLinux ve Rocky Linux bu kayıtları /var/log/secure dosyasında tutar. İkincisi, yeni Debian ve minimal Ubuntu kurulumlarında rsyslog paketinin kurulu olmaması; bu durumda dosya hiç oluşmaz ve tüm kayıt systemd journal'ında saklanır. journalctl -t sshd komutu her iki durumda da çalışır ve aynı bilgiyi verir.

Bir girişin anahtarla mı parolayla mı yapıldığını nasıl anlarım?#

auth.log veya journal çıktısındaki satırın başına bakın. Accepted publickey for kullanici from IP anahtarla, Accepted password for kullanici from IP ise parolayla yapılan girişi gösterir. Anahtarla yapılan girişlerin sonunda SHA256: ile başlayan bir parmak izi bulunur; bunu ssh-keygen -lf ~/.ssh/authorized_keys çıktısıyla karşılaştırarak hangi anahtarın kullanıldığını kesin olarak tespit edebilirsiniz.

Şüpheli bir oturum bulduğumda ilk olarak ne yapmalıyım?#

Önce kanıtı koruyun: auth.log, wtmp, btmp ve journal çıktısını arşivleyip başka bir makineye indirin, çünkü saldırgan hâlâ içerideyse ilk işi kayıtları silmek olur. Sonra who -u ile açık oturumları görün ve ilgili terminali sonlandırın, saldırgan IP'sini güvenlik duvarında kapatın. Ardından authorized_keys dosyalarını, uid=0 olan hesapları ve cron görevlerini denetleyin.

Kaç günlük giriş kaydı saklamalıyım?#

Varsayılan logrotate ayarları çoğu dağıtımda yaklaşık dört haftalık kayıt tutar ve bu genellikle yetersizdir; ihlaller sıklıkla haftalar sonra fark edilir. Kimlik doğrulama kayıtları için en az 90 gün, mümkünse 180 gün hedefleyin. Bu kayıtlar küçük dosyalardır, disk maliyeti ihmal edilebilir düzeydedir. Kayıtların bir kopyasını sunucu dışında tutmak ise root yetkisi ele geçiren birinin izleri silmesine karşı tek gerçek korumadır.

Kendi IP adresimi nasıl doğrularım, sürekli değişiyor?#

Sunucuya bağlıyken echo $SSH_CLIENT komutunun ilk alanı, sunucunun sizi gördüğü IP adresidir. Yerel makinenizden curl -s https://ifconfig.me da aynı bilgiyi verir. Çoğu ev ve mobil bağlantı dinamik IP kullandığı için bu adres değişir; bu yüzden tek bir IP ezberlemek yerine servis sağlayıcınızın adres bloğunu ve ekipteki herkesin hangi kullanıcı adıyla bağlandığını not etmek daha güvenilir bir referans olur.