TurkTeam | Türk Siber Güvenlik Topluluğu - Linux Genel

Lynis ile Linux Sunucu Sertleştirme Denetimi: Skorunuzu Nasıl Yükseltirsiniz?

Sun, 25 Oct 2026 11:50:09 +0300

Selamlar,

Bir Linux sunucusunu internete açmadan önce "ne kadar güvenli?" sorusuna somut yanıt vermek zor olabilir. Açık kaynak güvenlik denetim aracı Lynis, sisteminizi onlarca kontrol kategorisinde tarayıp bir sertleştirme indeksi (hardening index) ve uygulanabilir öneriler verir. Bu rehberde kurulum, denetim ve önerilere göre sertleştirmeyi adım adım ele alıyorum. (Yalnızca yetkili olduğunuz sistemlerde kullanın.)

Konuda anlatılacaklar

Lynis nedir?
Kurulum
İlk denetim
Çıktıyı okumak
Sertleştirme örnekleri
Periyodik çalıştırma

1. Lynis nedir?
Lynis, CISOfy tarafından geliştirilen, kabuk (shell) ile yazılmış, agentsiz bir güvenlik denetim aracıdır. Sistem sertleştirme, uyumluluk testi ve zafiyet taramasına yardımcı olur. Sadece kontrol eder, varsayılan olarak değişiklik yapmaz.

2. Kurulum

Kod:
# Debian/Ubuntu
sudo apt install lynis
# RHEL/Fedora
sudo dnf install lynis
# Kaynaktan (en güncel)
git clone https://github.com/CISOfy/lynis
cd lynis && ./lynis audit system

3. İlk denetim

Kod:
sudo lynis audit system

Lynis; önyükleme, kernel, bellek, kimlik doğrulama, dosya sistemleri, SSH, güvenlik duvarı, loglama gibi onlarca kategoriyi tarar. Sonunda bir özet ve Hardening index gösterir.

4. Çıktıyı okumak
Çıktıda üç ana işaret vardır:

Warnings (uyarılar): öncelik verilmesi gereken bulgular.
Suggestions (öneriler): iyileştirme fırsatları.
Hardening index: 0-100 arası genel skor.

Detaylı log:

Kod:
sudo cat /var/log/lynis.log
# Rapor verisi:
sudo cat /var/log/lynis-report.dat

5. Sertleştirme örnekleri
Lynis'in sık önerdiği tipik adımlar:

SSH sertleştirme: /etc/ssh/sshd_config içinde PermitRootLogin no, PasswordAuthentication no (anahtar tabanlı giriş), Protocol 2.
Kernel parametreleri: /etc/sysctl.conf ile ağ ve bellek korumaları.
Gereksiz servisleri kapatma: kullanılmayan daemon'ları devre dışı bırakın.
Güvenlik duvarı: varsayılan reddet politikasıyla ufw/nftables yapılandırın.
Denetim izleme: auditd ve dosya bütünlük kontrolü (AIDE) kurun.

Her öneriye kör körüne uymayın; değişikliği anlayarak ve test ortamında doğrulayarak uygulayın.

6. Periyodik çalıştırma
Sertleştirme tek seferlik değil, sürekli bir süreç. cron ile haftalık denetim:

Kod:
0 3 * * 0 /usr/sbin/lynis audit system --quiet >> /var/log/lynis-weekly.log 2>&1

Sonuç
Lynis, "sunucum ne kadar güvenli?" sorusuna ölçülebilir bir yanıt ve somut yapılacaklar listesi verir. Skoru yükseltmek amaç değil, araçtır; asıl hedef anlaşılır ve sürdürülebilir bir sertleştirme. Sunucularınızda en son ne zaman denetim çalıştırdınız?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

17-t17-lynis-linux-sertlestirme.png (Dosya Boyutu: 109.13 KB / İndirme Sayısı: 2)

SSH Host Anahtarı Değişti Uyarısı: Ne Zaman MITM, Ne Zaman Meşru?

Thu, 22 Oct 2026 11:28:47 +0300

Selamlar,

Tor çıkış rölelerinin SSH'yi yönlendirdiği Ekim 2026 olayında kurbanların gördüğü ilk şey klasik OpenSSH uyarısıydı: REMOTE HOST IDENTIFICATION HAS CHANGED. Birçok kişi bu uyarıyı "sunucu yeniden kurulmuş olmalı" diye yok sayıyor. Bu yazıda uyarının ne anlama geldiğini, OpenSSH yapılandırma seçeneklerini ve kendi labınızda güvenli bir alışkanlık nasıl kurulacağını anlatıyorum.

Konuda anlatılacaklar

Uyarı teknik olarak ne diyor?
StrictHostKeyChecking seçenekleri
Meşru değişim ile MITM'i ayırt etmek
Lab alıştırması

Uyarı ne diyor?
OpenSSH, bağlandığınız sunucunun sunduğu host anahtarını ~/.ssh/known_hosts (ve sistem genelindeki known_hosts) ile karşılaştırır. Anahtar değiştiyse iki olasılık vardır: sunucu gerçekten yeniden kurulmuş / anahtar döndürülmüştür, ya da aradaki biri size başka bir sunucu sunuyordur (MITM). Tor olayında ikinci senaryo gerçekleşiyordu: çıkış rölesi sizi saldırganın ara sunucusuna yönlendiriyordu ve o sunucu farklı bir host anahtarı sunuyordu.

StrictHostKeyChecking
OpenBSD ssh_config kılavuzuna göre:

yes: Yeni host anahtarlarını otomatik eklemez; değişen anahtarlara bağlanmayı reddeder. En yüksek MITM koruması.
accept-new: Yeni anahtarları otomatik ekler ama değişen anahtarlara izin vermez.
ask (varsayılan): Yeni anahtarları kullanıcı onayından sonra ekler; değişen anahtarlara bağlanmayı reddeder.
no / off: Yeni anahtarları otomatik ekler ve değişen anahtarlara da (bazı kısıtlarla) izin verir. Kolaydır, tehlikelidir.

Meşru değişim ile MITM'i ayırt etmek

Uyarıyı görünce bağlantıyı kesin; "yes" yazmayın.
Sunucu sahibine / panelinize / out-of-band bir kanala sorun: Anahtar yakın zamanda döndürüldü mü?
Beklenen parmak izini güvenli bir kaynaktan alın (bulut konsolu, önceki yedek, fiziksel konsol).
Eşleşiyorsa known_hosts'taki eski satırı güncelleyin. Eşleşmiyorsa MITM veya yanlış sunucu varsayın.

Kod:
# Parmak izi hesaplama (kendi makinenizden)
ssh-keyscan -t ed25519,ecdsa,rsa hedef.ornek 2>/dev/null | ssh-keygen -lf -
# known_hosts'tan eski kaydi silmek (yalnizca meşru degisim dogrulandiktan sonra)
ssh-keygen -R hedef.ornek
# Guvenli istemci varsayilanlari
cat >> ~/.ssh/config <<'E'
Host *
  StrictHostKeyChecking accept-new
  UpdateHostKeys yes
  PasswordAuthentication no
  HashKnownHosts yes
E

UpdateHostKeys=yes, kimlik doğrulama tamamlandıktan sonra sunucunun gönderdiği ek host anahtarlarını known_hosts'a eklemeye izin verir (OpenSSH 6.8+ sunucularda); anahtar rotasyonunu yumuşatır ama ilk güven ilişkisinin sağlam olmasını gerektirir.

Lab alıştırması
İki VM'niz varsa: B'nin host anahtarını yeniden oluşturun (ssh-keygen -A), A'dan bağlanın, uyarıyı görün, B'nin gerçek parmak izini konsoldan doğrulayın, sonra known_hosts'u güncelleyin. Bu alıştırmayı bir kez bilinçli yapmak, üretimde uyarıyı refleksle yok saymayı azaltır.

Sizin ekipte host anahtarı değişince prosedür nedir? Yazılı bir runbook'unuz var mı?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

13-b03-ssh-hostkey.png (Dosya Boyutu: 115.16 KB / İndirme Sayısı: 9)

systemd Timer ile Güvenlik Görevleri: OnCalendar, Persistent ve Jitter

Wed, 21 Oct 2026 11:29:31 +0300

Selam,

cron hâlâ iş görür; ama modern dağıtımlarda güvenlik otomasyonu için systemd timer daha okunur log, bağımlılık ve Persistent= ile kaçırılan çalışma telafisi sunar. Bu yazıda basit bir "günlük log tarama" zamanlayıcısını labda kuruyoruz.

İki dosya: .service + .timer

Kod:
# /etc/systemd/system/lab-logscan.service
[Unit]
Description=Lab auth log quick scan
[Service]
Type=oneshot
ExecStart=/usr/local/bin/lab-logscan.sh
User=logscan
Nice=10

Kod:
# /etc/systemd/system/lab-logscan.timer
[Unit]
Description=Run lab-logscan daily
[Timer]
OnCalendar=*-*-* 04:15:00
Persistent=true
RandomizedDelaySec=10m
Unit=lab-logscan.service
[Install]
WantedBy=timers.target

Ne anlama geliyor?

OnCalendar= takvim ifadesi (man systemd.time)
Persistent=true makine kapalıyken kaçırılan run'ı açılışta telafi etmeye çalışır
RandomizedDelaySec= thundering herd / eşzamanlı yük için jitter

Kod:
sudo systemctl daemon-reload
sudo systemctl enable --now lab-logscan.timer
systemctl list-timers | grep lab-logscan
journalctl -u lab-logscan.service -n 50 --no-pager

Güvenlik alışkanlıkları

Timer'ı root yerine dar yetkili kullanıcıyla çalıştırın
ExecStart script'ini yazılabilir dizine koymayın
NoNewPrivileges=yes, ProtectSystem=strict gibi sandbox direktiflerini ekleyin
Çıktıyı mail yerine journal + SIEM forwarder ile toplayın

Yasal uyarı
Sistem zamanlayıcılarıyla başkalarının host'larında izinsiz tarama yapmayın.

Kaynaklar

https://www.freedesktop.org/software/sys...timer.html
man systemd.time / systemd.exec

cron'dan göç
Mevcut crontab satırlarını tek tek service+timer çiftine taşıyın. Ortam değişkenlerini EnvironmentFile= ile verin. Başarısız koşularda OnFailure= ile alert unit bağlayın. list-timers çıktısını haftalık gözden geçirin.

Uygulamada sık gördüğüm hatalar
Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.

Ekip içi iletişim şablonu
Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.

Lab not defteri
Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.

İzleme ve doğrulama
Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.

Sonuç
Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.

Adım adım kontrol listesi (kopyala-yapıştır)

Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
Yama veya yapılandırma azaltmasını stagingde deneyin.
Üretim penceresinde uygulayın; değişiklik kaydı açın.
Servis sağlık kontrolü + log doğrulaması yapın.
Gerekliyse IOC avı veya compromise assessment planlayın.
Kapanış notunu yazın: sürüm, tarih, kim onayladı.

Sık sorulanlar
Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.
PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.
WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.
Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.

Örnek komut defteri

Kod:
# Tarih damgası ve ortam notu
date -Is
hostnamectl 2>/dev/null | head -5 || true
# Ağ dinleme özeti (lab)
ss -lntp | head -30
# Son reboot / güncelleme ipucu (systemd)
who -b 2>/dev/null || true

Bu komutlar tanı koymaz; değişiklik öncesi/sonrası basline almak için kullanın.

İlgili TurkTeam bölümleri
Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.

Kapanış ve yasal çerçeve
TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.

Kişisel deneyim notu
Ben benzer konuları işlerken önce resmi duyuruyu iki kez okuyup sonra labda en küçük yeniden üretilebilir adımı arıyorum. Yeniden üretemiyorsam bile envanter ve yama doğrulamasını aynı gün bitirmeye çalışıyorum. Siz de "bugün tek iş" diye bir satır seçin: ya yamayı uygulayın ya da etkilenen varlık olmadığını kanıtlayın. İkisi de geçerli kapanıştır.

Okuma listesi

Üretici / araştırmacı birincil yazısı (kaynakçada)
CISA KEV veya CERT duyurusu varsa o
Kendi iç runbook'unuzun ilgili maddesi

Üçünden fazlasını aynı anda açmak yerine birini bitirip not alın; aksi halde tab kaybı başlar.

Kısa senaryo
Diyelim ki bu konuyu pazartesi sabah toplantısında anlatacaksınız: bir slaytta risk, bir slaytta etkilenen varlık sorusu, bir slaytta bugün yapılacak tek eylem. Üç slayttan fazlası dikkat dağıtır. Toplantı bitince eylem sahibinin adını ticket'a yazın.

15-b05-systemd.png (Dosya Boyutu: 106.03 KB / İndirme Sayısı: 9)

Linux'ta Dosya Bütünlüğü İzleme: AIDE Kurulumu, İlk Veritabanı ve Günlük Kontrol

Sun, 18 Oct 2026 22:14:44 +0300

Selam arkadaşlar,

Geçen ay bir test sunucusunda /usr/bin altındaki bir dosyanın tarihi dikkatimi çekti. Sonradan paket güncellemesi olduğu ortaya çıktı ama o an "bu dosya gerçekten değişti mi, ne zaman değişti?" sorusuna elimde net bir cevap yoktu. O günden beri kurduğum her Linux makinede ilk işlerden biri AIDE oluyor. Bu konuda AIDE'yi (Advanced Intrusion Detection Environment) sıfırdan kurmayı, ilk veritabanını oluşturmayı, gürültüyü azaltmayı ve kontrolü otomatiğe bağlamayı anlatacağım. Örnekler Debian 12 / Ubuntu 24.04 üzerinde; RHEL tarafındaki farkları da not düştüm.

AIDE tam olarak ne yapar?
AIDE bir dosya bütünlüğü izleme (FIM) aracıdır. Mantığı basit: sistem temizken seçtiğiniz dizinlerdeki dosyaların özniteliklerini (izinler, sahip, boyut, inode, değişiklik zamanı) ve hash değerlerini (SHA-256, SHA-512 vb.) bir veritabanına yazar. Sonraki her kontrolde mevcut durumu bu veritabanıyla karşılaştırır ve eklenen, silinen, değişen dosyaları raporlar.

Önemli nokta: AIDE gerçek zamanlı değildir. Bir saldırganın değiştirdiği dosyayı anında yakalamaz, bir sonraki taramada yakalar. Gerçek zamanlı izleme istiyorsanız auditd veya Wazuh'un syscheck modülü gibi araçlara bakmak gerekir. AIDE'nin gücü sadeliği ve bağımsız çalışabilmesidir.

Kurulum
Debian/Ubuntu:

Kod:
sudo apt update
sudo apt install aide aide-common
aide --version

RHEL / Rocky / Alma:

Kod:
sudo dnf install aide

Debian paketinde yapılandırma /etc/aide/aide.conf ve /etc/aide/aide.conf.d/ altında parçalı tutulur. RHEL tarafında tek dosya olarak /etc/aide.conf vardır. Bu fark, internetteki örnekleri birebir kopyalarken en sık takıldığım yer oldu.

İlk veritabanını oluşturmak
Debian ailesinde paketle gelen yardımcı betik işi kolaylaştırır:

Kod:
sudo aideinit

Bu komut veritabanını /var/lib/aide/aide.db.new dosyasına yazar ve ardından aide.db olarak kopyalar. RHEL tarafında elle yapılır:

Kod:
sudo aide --init
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

İlk tarama disk boyutuna göre birkaç dakikadan yarım saate kadar sürebilir. Benim 40 GB'lık test VM'imde yaklaşık 6 dakika sürdü.

Çok kritik bir uyarı: veritabanını mutlaka temiz olduğundan emin olduğunuz bir anda oluşturun. Zaten ele geçirilmiş bir sistemde oluşturulan veritabanı, saldırganın değişikliklerini "normal" kabul eder.

Kontrol çalıştırmak ve çıktıyı okumak

Kod:
sudo aide --check --config /etc/aide/aide.conf

Ben test için bilerek /etc/passwd dosyasına bir test kullanıcısı ekledim. Çıktının özeti şuna benziyordu:

Çıktıdaki satır başındaki harf dosya tipini (f: dosya, d: dizin), ardından gelen sütunlar hangi özniteliğin değiştiğini gösterir. Örneğin boyut, mtime, ctime ve hash değişmişse ilgili sütunlarda işaret görürsünüz. Raporun alt kısmında "Detailed information about changes" bölümü eski ve yeni hash değerlerini tek tek listeler.

Çıkış kodu da önemlidir: AIDE değişiklik bulduğunda sıfırdan farklı bir kodla çıkar. Betiklerde bunu kullanarak alarm üretebilirsiniz.

Gürültüyü azaltmak: kural yazımı
Varsayılan yapılandırma ilk günlerde çok fazla satır üretir: log dosyaları, önbellekler, /var/lib altında sürekli değişen veriler... Bunları izlemenin anlamı yok. Kendi kurallarımı Debian'da /etc/aide/aide.conf.d/ altına ayrı bir dosya olarak koyuyorum:

Kod:
# /etc/aide/aide.conf.d/99_yerel
!/var/log
!/var/cache
!/var/lib/apt/lists
!/home/.*/\.cache
/etc        CONTENT_EX
/usr/bin    CONTENT_EX
/usr/sbin   CONTENT_EX
/boot       CONTENT_EX

Ünlem işareti (!) hariç tutma anlamına gelir. CONTENT_EX gibi grup adları ana yapılandırmada tanımlıdır; kendi grubunuzu da tanımlayabilirsiniz:

Kod:
BENIM = p+u+g+s+m+c+sha256
/opt/uygulama BENIM

Buradaki harfler: p izinler, u kullanıcı, g grup, s boyut, m mtime, c ctime. Tam liste için man 5 aide.conf kılavuzuna bakın.

Yapılandırmayı değiştirdikten sonra sözdizimini test etmek için:

Kod:
sudo aide --config-check --config /etc/aide/aide.conf

Meşru değişikliklerden sonra veritabanını güncellemek
Paket güncellemesi yaptığınızda yüzlerce dosya değişir. Bu durumda önce raporu gözden geçirip değişikliklerin beklenen olduğundan emin olun, sonra veritabanını yenileyin:

Kod:
sudo aide --update --config /etc/aide/aide.conf
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Benim alışkanlığım: her "apt upgrade" sonrası bir kontrol, rapor temizse güncelleme. Kontrol etmeden körlemesine güncelleme yapmak AIDE'yi anlamsız kılar.

Günlük otomatik kontrol
Debian paketi zaten /etc/cron.daily/aide betiğiyle günlük kontrol kurar ve sonuçları e-posta ile gönderir (MAILTO ayarı /etc/default/aide içinde). Systemd kullanan dağıtımlarda dailyaidecheck.timer da gelebilir:

Kod:
systemctl list-timers | grep -i aide

Kendi betiğinizi yazmak isterseniz basit bir örnek:

Kod:
#!/bin/bash
LOG=/var/log/aide/aide-$(date +%F).log
mkdir -p /var/log/aide
/usr/bin/aide --check --config /etc/aide/aide.conf > "$LOG" 2>&1
if [ $? -ne 0 ]; then
  logger -t aide "AIDE değişiklik tespit etti: $LOG"
fi

logger ile syslog'a yazınca SIEM'iniz bu satırı yakalayıp alarm üretebilir.

Veritabanını korumak
AIDE'nin en zayıf noktası şudur: root yetkisi alan bir saldırgan veritabanını da güncelleyebilir. Bu yüzden temiz veritabanının bir kopyasını salt okunur bir ortama alın, kontrol öncesi hash doğrulayın ve mümkünse AIDE binary'sinin kendisini de güvenilir bir kopyadan çalıştırın.

Kod:
sha256sum /var/lib/aide/aide.db > /root/aide.db.sha256

AIDE ne değildir?
AIDE size "ne değişti" der, "neden değişti" demez. Bir değişikliğin saldırı mı yoksa yönetici işlemi mi olduğunu anlamak için auditd kayıtları, paket yöneticisi geçmişi ve oturum loglarıyla birlikte değerlendirmek gerekir. Rootkit tespiti için de tek başına yeterli değildir.

Kaynaklar

AIDE resmi proje sayfası: aide.github.io
man aide, man 5 aide.conf
Red Hat Enterprise Linux Security Hardening belgesi, "Checking integrity with AIDE" bölümü

Siz FIM için hangi aracı kullanıyorsunuz? Wazuh syscheck ile AIDE'yi karşılaştıran olduysa deneyimini merak ediyorum.

Paket güncellemesi sonrası kontrol rutini
Üretimde unattended-upgrades veya Ansible ile yama dağıtıyorsanız AIDE veritabanını körlemesine güncellemek yerine şu sırayı kullanın: yama penceresi bitince aide --check, değişen dosyaların paket listesiyle kesişimini doğrula (dpkg -S /path veya rpm -qf), ardından --update. Kesişmeyen dosyalar (ör. /etc altında elle değiştirilmiş config) ayrı ticket ister.

Wazuh syscheck ile fark
Wazuh syscheck gerçek zamanlıa daha yakın (inotify) çalışabilir ve merkezi yöneticiden politika iter. AIDE ise ajan gerektirmeyen, tek makinelik, denetim izine kolay eklenen bir araçtır. Küçük lab veya internete kapalı sunucuda AIDE yeter; filo yönetiminde Wazuh/OSSEC ailesi daha ölçeklenir. İkisini birlikte kullananlar: AIDE'yi "altın imaj doğrulama", Wazuh'u "sürekli izleme" diye ayırır.

Sık sorulanlar
AIDE veritabanını NFS'e koymayın; saldırgan orayı da yazabilir. cron mail çalışmıyorsa logger + SIEM yolunu kullanın. İlk kurulumda /var ve /home'u olduğu gibi izlemek gürültü tsunami'sidir; önce /etc /bin /sbin /usr/bin /boot ile başlayın, sonra genişletin. Sunucu immutable infrastructure ise her deploy'da yeni baseline alın; AIDE'yi golden image pipeline'ının son adımı yapın.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

100-n01-a26bb9.png (Dosya Boyutu: 66.93 KB / İndirme Sayısı: 10)

n01-inner.png (Dosya Boyutu: 19.37 KB / İndirme Sayısı: 12)

Linux Kullanıcı ve İzin Yönetimi: chmod, chown, umask ve ACL Rehberi

Sun, 18 Oct 2026 21:34:05 +0300

Selam TurkTeam,

Linux'ta güvenliğin temeli izinlerdir. "Bu dosyayı kim okuyabilir, kim çalıştırabilir, kim değiştirebilir?" sorusunun cevabı; bir sunucunun ne kadar sağlam ya da ne kadar savunmasız olduğunu doğrudan belirler. Bu rehberde Linux izin modelini sıfırdan ele alıyor; chmod, chown, umask, özel izin bitleri (SUID/SGID/sticky) ve klasik modelin yetmediği yerde devreye giren ACL'yi uygulamalı olarak anlatıyoruz.

Konuda Anlatılacaklar

Linux izin modeli: kullanıcı/grup/diğer ve rwx
chmod: sembolik ve sayısal (oktal) kullanım
chown ve chgrp: sahiplik yönetimi
umask: varsayılan izinlerin belirlenmesi
Özel bitler: SUID, SGID, sticky bit
ACL: getfacl / setfacl ile ince ayar
Sonuç, kaynakça ve yasal uyarı

1. İzin Modeli: Üç Sınıf, Üç Yetki
Her dosya ve dizinin bir sahibi (user), bir grubu (group) ve bir de diğerleri (others) sınıfı vardır. Her sınıf için üç yetki tanımlanır: okuma ®, yazma (w) ve çalıştırma (x). İzinleri görmek için:

Kod:
ls -l dosya.txt

Çıktı şuna benzer:

Kod:
-rw-r--r-- 1 ahmet ekip 1024 Oct 17 14:00 dosya.txt

Baştaki 10 karakteri çözelim: ilk karakter tür (- dosya, d dizin, l sembolik bağ), sonraki üçlü sahip (rw-), ortadaki üçlü grup (r--), son üçlü diğerleri (r--) izinleridir. Yani sahibi okuyup yazabilir, grup ve diğerleri yalnızca okuyabilir.

Dizinlerde x yetkisinin anlamı özeldir: bir dizine "girip" içindeki yollara erişebilmek için x gerekir; r ise yalnızca listeleme yetkisidir.

2. chmod: İzin Değiştirme
chmod'u iki biçimde kullanırsınız: sembolik ve sayısal (oktal).

Sembolik kullanım (u=user, g=group, o=other, a=all; +ekle, -kaldır, =eşitle):

Kod:
chmod u+x script.sh          # sahibe çalıştırma ekle
chmod go-w dosya.txt         # grup ve diğerlerinden yazmayı kaldır
chmod a=r dosya.txt          # herkese yalnızca okuma

Sayısal (oktal) kullanım: r=4, w=2, x=1 değerlerinin toplamı her sınıf için bir rakam verir:

Kod:
chmod 644 dosya.txt    # rw-r--r--
chmod 755 script.sh    # rwxr-xr-x
chmod 600 gizli.key    # rw------- (yalnızca sahibi)

Dizinleri özyinelemeli değiştirmek için -R kullanın, ancak dikkatli olun:

Kod:
chmod -R 750 /opt/uygulama

3. chown ve chgrp: Sahiplik
Bir dosyanın sahibini ve/veya grubunu değiştirmek için chown kullanılır (genelde root yetkisi gerekir):

Kod:
sudo chown ahmet dosya.txt           # sahibi değiştir
sudo chown ahmet:ekip dosya.txt      # sahip ve grup
sudo chgrp ekip dosya.txt            # yalnızca grup
sudo chown -R ahmet:ekip /srv/proje  # özyinelemeli

Sahiplik, izinlerle birlikte düşünülmelidir: 600 izinli bir anahtar dosyası, yanlış kullanıcıya ait olursa koruması anlamını yitirir.

4. umask: Varsayılan İzinler
Yeni oluşturulan dosya ve dizinler, umask değerine göre izin alır. umask, verilmeyecek bitleri maskeler. Tipik varsayılan 022'dir:

Kod:
umask          # mevcut değeri göster
umask 027      # yeni dosyalara daha sıkı varsayılan

Hesaplama mantığı: dosyalarda taban 666, dizinlerde 777'dir ve umask bundan çıkarılır. 022 umask ile yeni dosya 644, yeni dizin 755 olur. 027 ile dosya 640, dizin 750 olur; yani "diğerleri" hiçbir erişim almaz. Kalıcı yapmak için ~/.bashrc veya /etc/profile içine umask satırı eklenir.

5. Özel Bitler: SUID, SGID, Sticky
Klasik rwx'in üstünde üç özel bit vardır ve güvenlik açısından kritiktir.

SUID (4): Çalıştırılabilir dosya, sahibinin yetkisiyle çalışır. Örnek: passwd komutu root SUID'lidir, böylece sıradan kullanıcı parolasını değiştirebilir.
SGID (2): Dosyada grup yetkisiyle çalıştırma; dizinde ise içinde oluşturulan dosyaların dizin grubunu devralmasını sağlar (ortak çalışma dizinleri için idealdir).
Sticky bit (1): Dizinde, bir kullanıcının yalnızca kendi dosyasını silebilmesini sağlar. /tmp dizini buna klasik örnektir.

Ayarlama:

Kod:
chmod u+s program       # SUID
chmod g+s paylasim/      # SGID dizin
chmod +t /ortak/alan     # sticky bit

Sistemdeki SUID dosyaları denetim için önemlidir; yanlış yapılandırılmış bir SUID, yetki yükseltmeye yol açabilir:

Kod:
find / -perm -4000 -type f 2>/dev/null

Bu komut root SUID'li ikilileri listeler; beklenmedik bir giriş varsa incelenmelidir.

6. ACL: getfacl ve setfacl
Klasik model yalnızca tek sahip, tek grup ve diğerlerini tanımlar. "Bu dosyaya Ayşe de yazsın ama başka kimse değil" gibi ince ihtiyaçlarda ACL (Access Control List) devreye girer.
Mevcut ACL'yi görme:

Kod:
getfacl dosya.txt

Belirli bir kullanıcıya izin verme:

Kod:
setfacl -m u:ayse:rw dosya.txt

Bir gruba izin ve varsayılan (yeni dosyalara miras) ACL:

Kod:
setfacl -m g:ekip:rx klasor/
setfacl -d -m g:ekip:rx klasor/

ACL kaldırma:

Kod:
setfacl -x u:ayse dosya.txt   # tek kayıt
setfacl -b dosya.txt          # tüm ACL

ls -l çıktısında izinlerin sonundaki "+" işareti, o dosyada ek ACL kayıtları olduğunu gösterir. ACL güçlüdür ancak karmaşıklığı artırır; yalnızca klasik modelin yetmediği yerde kullanın.

7. İleri Seviye ve İyi Uygulamalar

En az ayrıcalık: Her zaman gereken en dar izni verin; 777'den kaçının, bu neredeyse her zaman hatalı bir çözümdür.
Anahtar ve sır dosyaları: SSH özel anahtarları 600 olmalı, aksi halde istemci bağlanmayı reddeder.
Düzenli denetim: Dünyaya yazılabilir dosyaları bulun:
Kod:
find / -perm -0002 -type f 2>/dev/null
Değişmezlik: Kritik dosyaları kazara değişikliğe karşı chattr +i ile değişmez yapabilirsiniz (ext4):
Kod:
sudo chattr +i /etc/onemli.conf

Sonuç
Linux izin yönetimi, karmaşık görünse de birkaç sağlam kavrama dayanır: üç sınıf, üç yetki, özel bitler ve gerektiğinde ACL. chmod/chown/umask üçlüsünü ve SUID/SGID/sticky mantığını iyi oturtmak, hem sistemlerinizi sertleştirmenizi hem de bir denetimde zayıf noktaları hızla görmenizi sağlar. "En az ayrıcalık" ilkesini her kararın merkezine koyun.

Kaynakça

GNU Coreutils El Kitabı (chmod, chown) - https://www.gnu.org/software/coreutils/manual/
chmod(1), chown(1), umask(1p) man sayfaları
setfacl(1) / getfacl(1) man sayfaları - https://man7.org/linux/man-pages/man1/setfacl.1.html
Arch Wiki: File permissions and attributes - https://wiki.archlinux.org/title/File_pe...attributes
Debian Yönetici El Kitabı - https://www.debian.org/doc/

Yasal Uyarı

Alıntı:İzin ve sahiplik değişiklikleri yalnızca kendi sistemlerinizde veya yönetim yetkiniz olan sistemlerde yapılmalıdır. Başkasının sistemine izinsiz müdahale Türk Ceza Kanunu 243-245. maddeleri kapsamında suçtur.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

  000-team-new-fc305f.png (Dosya Boyutu: 59.69 KB / İndirme Sayısı: 10)

  konu-07-1.png (Dosya Boyutu: 53.79 KB / İndirme Sayısı: 11)

  konu-07-2.png (Dosya Boyutu: 56.07 KB / İndirme Sayısı: 8)

tmux ile Terminal Verimliliği: Pentest İçin Oturum ve Panel Yönetimi

Sun, 18 Oct 2026 21:32:47 +0300

Merhaba TurkTeam,

Uzun süren taramalar, SSH üzerinden yönetilen hedefler ve aynı anda koşan onlarca komut... Bir pentest ya da sistem yönetimi oturumunda en büyük düşmanınız, bağlantı koptuğunda çalışan işlerinizin de ölmesidir. İşte tmux (terminal multiplexer) tam burada devreye girer: tek bir terminalde birden çok oturum, pencere ve paneli yönetmenizi, bağlantı kopsa bile işlerin arka planda sürmesini sağlar. Bu rehberde tmux'u sıfırdan, pentest akışına odaklanarak ele alıyoruz.

Konuda Anlatılacaklar

tmux nedir, neden kullanılır (session/window/pane kavramları)
Kurulum ve ilk çalıştırma
Prefix tuşu ve temel kısayol referansı
Uygulamalı: kopan bağlantıya dayanıklı tarama oturumu
Panel bölme, pencere yönetimi ve kopyalama modu
İleri seviye: ~/.tmux.conf ile özelleştirme
Sonuç, kaynakça ve yasal uyarı

1. tmux Nedir, Neden Kullanılır?
tmux, tek bir terminal penceresini birden çok sanal terminale bölen bir "terminal çoğullayıcı"dır. Üç temel kavramı vardır:

Session (oturum): İçinde pencere ve panellerin barındığı en üst kapsayıcı. Oturumdan "detach" olup (ayrılıp) daha sonra "attach" ile geri dönebilirsiniz.
Window (pencere): Oturum içindeki bir sekme gibidir; her biri tam ekrandır.
Pane (panel): Bir pencerenin yatay/dikey bölünmüş parçası; aynı ekranda birden çok kabuk.

Pentest'te en kritik faydası kalıcılıktır: SSH ile bir sunucuya bağlanıp uzun bir Nmap/Gobuster taraması başlattığınızda, bağlantı koparsa klasik kabukta iş ölür. tmux oturumunda ise iş sürmeye devam eder; yeniden bağlanıp attach olduğunuzda kaldığınız yerden devam edersiniz.

2. Kurulum ve İlk Çalıştırma

Kod:
sudo apt update
sudo apt install tmux
tmux -V

İsimli bir oturum başlatmak, sonradan bulmayı kolaylaştırır:

Kod:
tmux new -s denetim

3. Prefix Tuşu ve Kısayol Referansı
tmux komutlarının çoğu bir prefix tuşundan sonra verilir. Varsayılan prefix Ctrl+b'dir (aşağıda "C-b" olarak gösterilir). Önce prefix'e, sonra ilgili tuşa basarsınız.

Oturumdan ayrılma (detach): İş sürerken terminale geri dönmek için.

Kod:
C-b d

Dikey panel bölme:

Kod:
C-b %

Yatay panel bölme:

Kod:
C-b "

Paneller arası geçiş:

Kod:
C-b ok-tuşları

Yeni pencere / pencereler arası geçiş:

Kod:
C-b c      (yeni pencere)
C-b n      (sonraki)
C-b p      (önceki)
C-b 0..9   (numaraya git)

Paneli kapatma:

Kod:
C-b x

Komut satırından oturum yönetimi (prefix'siz):

Kod:
tmux ls                 # oturumları listele
tmux attach -t denetim  # oturuma geri dön
tmux kill-session -t denetim

4. Uygulamalı: Kopmaya Dayanıklı Tarama Oturumu
Adım 1 - Oturum aç ve uzun bir iş başlat:

Kod:
tmux new -s tarama
nmap -sV -p- 192.168.56.101 -oN tam_tarama.txt

Adım 2 - Oturumdan ayrıl (iş arkada sürer):

Kod:
C-b d

Terminalde "[detached (from session tarama)]" mesajını görürsünüz. Artık SSH bağlantınız kopsa bile Nmap çalışmaya devam eder.

Adım 3 - Daha sonra geri dön:

Kod:
tmux attach -t tarama

Tarama devam ediyorsa onu görürsünüz; bittiyse çıktıyı tam_tarama.txt dosyasında bulursunuz:

Kod:
tail -n 20 tam_tarama.txt

5. Panel ve Pencere ile Çoklu İş
Pentest'te sık senaryo: bir panelde tarama, diğerinde notlar, üçüncüsünde hedefe açık bir SSH. Bir pencereyi ikiye bölüp ikisinde ayrı iş yürütün:

Kod:
C-b %        # dikey böl
C-b "        # alt paneli yatay böl

Panel boyutunu ayarlamak için prefix'i basılı tutup ok tuşlarıyla yeniden boyutlandırabilir (C-b sonrası alt+ok veya :resize-pane komutu) veya bir paneli tam ekran yapıp geri küçültebilirsiniz:

Kod:
C-b z        # aktif paneli büyüt/küçült (zoom)

Kopyalama modu: Uzun çıktıda yukarı kaydırmak ve metin kopyalamak için kopyalama moduna girin:

Kod:
C-b [        # kopyalama moduna gir, ok/PageUp ile gez, q ile çık

Bu mod, kaydırma çubuğu olmayan uzak oturumlarda çıktı incelemeyi çok kolaylaştırır.

6. İleri Seviye: ~/.tmux.conf ile Özelleştirme
Varsayılan prefix (C-b) bazılarına rahatsız gelir; birçok kullanıcı onu C-a yapar. Ayrıca fare desteği ve daha büyük geçmiş tamponu verimliliği artırır. Örnek bir yapılandırma:

Kod:
# ~/.tmux.conf
set -g prefix C-a
unbind C-b
bind C-a send-prefix
set -g mouse on
set -g history-limit 100000
setw -g mode-keys vi

Değişiklikleri çalışan oturuma uygulamak için:

Kod:
tmux source-file ~/.tmux.conf

mouse on ile paneller fareyle seçilip boyutlandırılabilir; history-limit uzun tarama çıktılarının kaybolmamasını sağlar. vi kip tuşları kopyalama modunda vi alışkanlıklarını getirir.

Bir diğer güçlü alışkanlık, iş bazlı isimli oturumlardır: her müşteri/hedef için ayrı bir oturum (tmux new -s musteri1) açmak, işleri birbirine karıştırmadan paralel yürütmeyi sağlar. Günün sonunda tmux ls ile tüm aktif işlerinizi tek bakışta görürsünüz.

6.1. tmux, screen ve Pratik Alışkanlıklar
tmux'un en yakın alternatifi GNU screen'dir. screen daha eski ve yaygın olarak çoğu sunucuda hazır bulunur; tmux ise daha modern yapılandırma, daha güçlü panel yönetimi ve daha okunur bir durum çubuğu sunar. Yeni bir alışkanlık ediniyorsanız tmux'a yatırım yapmanızı öneririm, ancak bir sunucuda yalnızca screen varsa benzer mantıkla (Ctrl+a tabanlı kısayollar) iş görebileceğinizi bilin. İkisinin de ortak amacı aynıdır: oturumu kabuktan ayırıp işi yaşatmak.

Pentest sırasında tmux'u asıl değerli kılan, bir hedefe uzun süren bir işlem başlatıp bağlantıyı güvenle bırakabilmenizdir. Örneğin saatler sürebilecek bir tam port taraması, bir dizin keşfi ya da bir parola denetimi başlattığınızda, dizüstünüzü uyku moduna alıp eve gidebilir, ertesi gün attach olup kaldığınız yerden devam edebilirsiniz. Bu, özellikle sınırlı zaman penceresi olan kurumsal testlerde zaman kazandırır ve kesintiye bağlı veri kaybını önler.

Verimliliği artıran birkaç alışkanlık: her göreve anlamlı bir oturum adı verin, böylece tmux ls çıktısı okunur kalsın; sık kullandığınız panel düzenini bir kabuk fonksiyonu veya tmux betiğiyle otomatikleştirin; uzun çıktıları dosyaya da yazdırın (-oN, tee gibi) ki tmux geçmiş tamponuna bel bağlamayın. Son olarak, durum çubuğunu özelleştirerek saat, oturum adı ve aktif pencereyi görünür kılmak, aynı anda birçok iş yürütürken kafa karışıklığını ciddi biçimde azaltır.

Bir uyarı: tmux oturumu makine yeniden başlatıldığında kaybolur; kalıcılık yalnızca aynı oturum açıkken geçerlidir. Gerçekten kritik, günlerce sürecek işler için işleri bir servis veya nohup ile arka plana almayı da değerlendirin. tmux, insan etkileşimli oturumları yaşatmakta mükemmeldir; uzun ömürlü otomasyon için ise servisleştirme daha doğru bir yaklaşımdır.

Sonuç
tmux, terminalde çalışan herkesin verimliliğini kökten artıran bir araçtır; pentest'te ise bağlantı kopmalarına karşı sigortanızdır. Önce session/window/pane üçlüsünü ve prefix mantığını oturtun, ardından ~/.tmux.conf ile kendinize göre ayarlayın. Birkaç gün bilinçli kullanımdan sonra kısayollar kas hafızanıza yerleşir ve geri dönmek istemezsiniz.

Kaynakça

tmux Resmi Deposu ve Wiki - https://github.com/tmux/tmux/wiki
tmux(1) Man Sayfası - https://man.openbsd.org/tmux.1
tmux Getting Started - https://github.com/tmux/tmux/wiki/Getting-Started
Kali Belgeleri - https://www.kali.org/docs/
man tmux (yerel man sayfası)

Yasal Uyarı

Alıntı:tmux bir verimlilik aracıdır; onunla yürüttüğünüz tüm testler yalnızca kendi sistemlerinizde veya yazılı izinli hedeflerde yapılmalıdır. İzinsiz erişim ve test Türk Ceza Kanunu 243-245. maddeleri kapsamında suçtur.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

  000-team-new-f79a96.png (Dosya Boyutu: 56.6 KB / İndirme Sayısı: 11)

  konu-06-1.png (Dosya Boyutu: 51.56 KB / İndirme Sayısı: 11)

  konu-06-2.png (Dosya Boyutu: 54.93 KB / İndirme Sayısı: 11)

Bash Scripting ile Basit Güvenlik Otomasyonu: Sıfırdan Giriş

Sun, 18 Oct 2026 11:20:27 +0300

Merhaba TurkTeam,

Güvenlikte tekrarlayan işleri elle yapmak hem zaman kaybı hem de hata kaynağıdır. "Her gün açık portları kontrol et", "yeni SUID dosyası var mı bak", "başarısız giriş sayısını say" gibi işleri bir kez yazıp otomatikleştirmek, hem tutarlılık hem de hız kazandırır. Bu rehber, Bash betik yazımını sıfırdan ele alıyor ve sonunda işe yarar, küçük bir güvenlik kontrol betiği çıkarıyoruz. Amaç, saldırı değil; kendi sisteminizi düzenli denetlemek.

Konuda Anlatılacaklar

Bash betiği nedir, shebang ve çalıştırma
Değişkenler, komut ikamesi ve tırnak kuralları
Koşullar, karşılaştırmalar ve çıkış kodları
Döngüler ve fonksiyonlar
Uygulamalı: güvenlik kontrol betiği
Güvenli betik yazımı ve zamanlama (cron)
Sonuç, kaynakça ve yasal uyarı

1. İlk Betik: Shebang ve Çalıştırma
Bir Bash betiği, ilk satırında yorumlayıcıyı belirten "shebang" ile başlar:

Kod:
#!/usr/bin/env bash
echo "Merhaba TurkTeam"

Dosyayı kaydedip çalıştırılabilir yapın ve çalıştırın:

Kod:
chmod +x betik.sh
./betik.sh

Betiklerinizi sağlamlaştırmak için başa güvenli kipi eklemek iyi bir alışkanlıktır:

Kod:
#!/usr/bin/env bash
set -euo pipefail

Burada -e hata olunca durur, -u tanımsız değişkende hata verir, pipefail boru hattındaki hatayı yakalar. Bu üçlü, sessiz hataların önüne geçer.

2. Değişkenler, Komut İkamesi ve Tırnak

Kod:
ad="TurkTeam"
tarih=$(date +%F)
echo "Rapor: $ad - $tarih"

Kritik kural: Değişkenleri daima çift tırnak içinde kullanın; aksi halde boşluk içeren değerler bölünür ve betik beklenmedik davranır:

Kod:
dosya="rapor 2026.txt"
# yanlış: cat $dosya   -> iki argüman
cat "$dosya"           # doğru

Komut ikamesi $(...) ile bir komutun çıktısını değişkene alırsınız; bu, otomasyonun temel taşıdır.

3. Koşullar, Karşılaştırmalar ve Çıkış Kodları
Her komut bir çıkış kodu döndürür: 0 başarı, sıfırdan farklısı hata. Bunu koşullarda kullanırsınız:

Kod:
if systemctl is-active --quiet ssh; then
  echo "SSH çalışıyor"
else
  echo "SSH kapalı!"
fi

Sayısal ve metinsel karşılaştırmalar [[ ]] içinde yapılır:

Kod:
sayi=5
if [[ "$sayi" -gt 3 ]]; then echo "üçten büyük"; fi

if [[ -f /etc/passwd ]]; then echo "dosya var"; fi

Burada -gt sayısal "büyüktür", -f "dosya mevcut mu" testidir. Dizin için -d, okunabilirlik için -r kullanılır.

4. Döngüler ve Fonksiyonlar
for döngüsü bir liste üzerinde gezer:

Kod:
for servis in ssh cron auditd; do
  systemctl is-active --quiet "$servis" \
    && echo "$servis: aktif" \
    || echo "$servis: PASİF"
done

while read ile bir dosyayı satır satır okursunuz:

Kod:
while IFS= read -r satir; do
  echo "Kontrol: $satir"
done < hedefler.txt

Fonksiyonlar tekrarı önler ve betiği okunur kılar:

Kod:
log() {
  echo "[$(date +%T)] $*"
}
log "Tarama başladı"

5. Uygulamalı: Güvenlik Kontrol Betiği
Şimdi öğrendiklerimizi, kendi makinenizde çalıştırabileceğiniz küçük bir günlük kontrol betiğinde birleştirelim:

Kod:
#!/usr/bin/env bash
set -euo pipefail

log() { echo "[$(date +%F_%T)] $*"; }

log "== Dinlenen portlar =="
ss -tulnp

log "== Root SUID dosyaları =="
find / -perm -4000 -type f 2>/dev/null

log "== Son başarısız SSH girişleri (sayı) =="
if command -v journalctl >/dev/null; then
  journalctl -u ssh --since "today" 2>/dev/null \
    | grep -c "Failed password" || true
fi

log "== Kontrol tamamlandı =="

Betiği çalıştırın:

Kod:
chmod +x guvenlik_kontrol.sh
./guvenlik_kontrol.sh

Çıktı; açık portları, root SUID ikililerini ve bugünkü başarısız SSH giriş sayısını zaman damgalı satırlarla özetler. Beklenmedik bir açık port veya yeni bir SUID dosyası, incelenmesi gereken ilk sinyallerdir.

Çıktıyı dosyaya kaydetme: Raporu tarihli bir dosyaya yazdırmak için:

Kod:
./guvenlik_kontrol.sh | tee "rapor_$(date +%F).txt"

6. Güvenli Betik Yazımı ve Zamanlama

set -euo pipefail kullanın; sessiz hataları yakalar.
Değişkenleri tırnaklayın ve kullanıcı girdisini asla doğrudan komuta gömmeyin (komut enjeksiyonu riski).
Mutlak yollar: Otomatik çalışan betiklerde komutları tam yoluyla veya kontrollü bir PATH ile çağırın.
shellcheck ile denetleyin:
Kod:
sudo apt install shellcheck && shellcheck guvenlik_kontrol.sh
Bu araç, yaygın hataları ve riskli kalıpları işaretler.
cron ile zamanlama: Betiği her gün 07:00'de çalıştırmak için kullanıcı crontab'ına ekleyin:
Kod:
crontab -e
ve satır:
Kod:
0 7 * * * /home/kullanici/guvenlik_kontrol.sh >> /home/kullanici/gunluk.log 2>&1

Betiklerinizi küçük tutun, her birini tek bir işe odaklayın ve çıktıyı makinece okunur (örn. anahtar=değer) biçimde tasarlarsanız, ileride bir uyarı sistemine bağlamak kolaylaşır.

6.1. Betik Otomasyonunda Sık Yapılan Hatalar
Yeni başlayanların güvenlik betiklerinde en sık düştüğü tuzak, tırnaksız değişken kullanımıdır. Bir dosya adında veya bir log satırında boşluk, yıldız veya özel karakter bulunduğunda, tırnaksız bir değişken beklenmedik biçimde bölünür ya da genişler; bu hem hatalı sonuç hem de ciddi güvenlik açığı doğurabilir. Kural basittir: hemen her zaman "$degisken" yazın. İkinci sık hata, kullanıcıdan veya dış bir dosyadan gelen veriyi doğrudan bir komuta gömmektir; bu, komut enjeksiyonuna kapı açar. Dış veriyi her zaman güvenilmez kabul edin ve mümkün olduğunca değişken olarak, tırnaklı biçimde kullanın.

Bir diğer önemli nokta, betiğin hatasız çalıştığını varsaymaktır. set -euo pipefail olmadan yazılmış bir betik, ortasında bir komut başarısız olsa bile çalışmaya devam eder ve yanıltıcı bir "başarıyla tamamlandı" çıktısı üretebilir. Örneğin disk dolu olduğu için rapor dosyası yazılamazsa, güvenli kip olmadan betik bunu fark etmeden ilerler. Güvenli kip ve anlamlı çıkış kodları, otomasyona güvenebilmenin ön koşuludur; çünkü otomasyonun değeri, siz izlemezken bile doğru çalışmasındadır.

Son olarak, bir betiği cron ile zamanlamadan önce mutlaka elle birkaç kez çalıştırıp çıktısını doğrulayın. cron ortamı etkileşimli kabuğunuzdan farklıdır: PATH daha dardır, bazı ortam değişkenleri tanımsızdır ve ev dizini farklı bağlamda çözülebilir. Bu yüzden cron ile çalışacak betiklerde komutları tam yoluyla çağırmak veya betiğin başında gerekli PATH'i açıkça ayarlamak, "elimde çalışıyordu ama cron'da çalışmadı" sorununu baştan engeller. Çıktıyı bir log dosyasına yönlendirmek de (>> gunluk.log 2>&1) sorun ayıklamayı kolaylaştırır.

Sonuç
Bash, güvenlik otomasyonuna başlamak için en erişilebilir araçtır: her Linux sisteminde hazırdır ve birkaç temel yapıyla (değişken, koşul, döngü, fonksiyon) güçlü kontroller yazabilirsiniz. Önce güvenli kip ve tırnak disiplinini oturtun, shellcheck ile denetleyin, sonra cron ile düzenli çalıştırın. Karmaşık işler büyüdüğünde Python'a geçebilirsiniz, ama günlük denetimlerin çoğu için iyi yazılmış bir Bash betiği fazlasıyla yeterlidir.

Kaynakça

GNU Bash Resmi El Kitabı - https://www.gnu.org/software/bash/manual/
Bash(1) Man Sayfası - https://man7.org/linux/man-pages/man1/bash.1.html
ShellCheck - https://www.shellcheck.net/
Google Shell Style Guide - https://google.github.io/styleguide/shellguide.html
crontab(5) Man Sayfası - https://man7.org/linux/man-pages/man5/crontab.5.html

Yasal Uyarı

Alıntı:Buradaki betikler yalnızca kendi sistemlerinizde veya yönetim yetkiniz olan sistemlerde çalıştırılmalıdır. Başkasının sistemine izinsiz müdahale Türk Ceza Kanunu 243-245. maddeleri kapsamında suçtur.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

000-team-gb-konu-14.png (Dosya Boyutu: 62.8 KB / İndirme Sayısı: 8)

auditd ile Linux Olay Denetimi: Kural Yazımı ve Log İnceleme

Sun, 18 Oct 2026 11:11:15 +0300

Merhaba TurkTeam,

Bir Linux sistemde "kim, ne zaman, hangi dosyaya dokundu veya hangi komutu çalıştırdı?" sorusunun kesin cevabını veren bileşen auditd'dir. Linux Audit alt sistemi, çekirdek düzeyinde olayları yakalayıp standart bir denetim kaydına yazar; bu da hem güvenlik izleme (mavi takım) hem de uyumluluk (PCI-DSS, CIS) için paha biçilmezdir. Bu rehberde auditd'yi kurulumdan kural yazımına ve log incelemeye kadar uygulamalı ele alıyoruz.

Konuda Anlatılacaklar

Linux Audit alt sistemi nedir, syslog'dan farkı
Kurulum ve servis yönetimi
Dosya izleme (watch) ve syscall kuralları
auditctl, ausearch ve aureport referansı
Uygulamalı: hassas dosya ve komut denetimi
Kalıcı kurallar ve ileri ipuçları
Sonuç, kaynakça ve yasal uyarı

1. Linux Audit Alt Sistemi Nedir?
Linux Audit, çekirdekteki olayları (dosya erişimleri, sistem çağrıları, kullanıcı oturumları, yetki değişiklikleri) yakalayan bir denetim çerçevesidir. Kullanıcı uzayındaki auditd servisi bu olayları toplayıp genelde /var/log/audit/audit.log dosyasına yazar. Sıradan syslog'dan farkı, çekirdek düzeyinde ve değiştirilmesi zor, ince ayarlı bir denetim izi sunmasıdır: Örneğin "bu dosya her değiştirildiğinde kaydet" veya "her execve sistem çağrısını kaydet" gibi kurallar yazabilirsiniz. Bu, bir olay sonrası adli incelemenin ve gerçek zamanlı tespitin temelini oluşturur.

2. Kurulum ve Servis Yönetimi

Kod:
sudo apt update
sudo apt install auditd audispd-plugins
sudo systemctl enable --now auditd
sudo systemctl status auditd

Çalışan kuralları ve durumu görmek için:

Kod:
sudo auditctl -s      # durum (enabled, backlog vb.)
sudo auditctl -l      # yüklü kurallar

3. Dosya İzleme ve Syscall Kuralları
auditd iki temel kural türü kullanır: watch (dosya/dizin izleme) ve syscall (sistem çağrısı izleme).

Dosya izleme (-w): -p ile izin türleri (r okuma, w yazma, x çalıştırma, a öznitelik), -k ile arama anahtarı:

Kod:
sudo auditctl -w /etc/passwd -p wa -k passwd_degisiklik

Bu kural, /etc/passwd her yazıldığında veya özniteliği değiştiğinde bir kayıt üretir ve "passwd_degisiklik" anahtarıyla etiketler.

Syscall kuralı (-a): mimari (-F arch), çağrı (-S) ve koşullarla:

Kod:
sudo auditctl -a always,exit -F arch=b64 -S execve -k komut_calistirma

Bu kural, 64-bit sistemde çalıştırılan her komutu (execve) kaydeder. "always,exit" çağrı tamamlandığında her zaman kaydet anlamına gelir.

Belirli kullanıcıyı hedefleme (-F auid):

Kod:
sudo auditctl -a always,exit -F arch=b64 -S execve -F auid=1000 -k kullanici1000_komut

4. auditctl, ausearch ve aureport Referansı
auditctl - kuralları canlı yönetir (yeniden başlatınca kaybolur, kalıcı için bkz. 6. bölüm):

Kod:
sudo auditctl -l        # listele
sudo auditctl -D        # tüm kuralları sil

ausearch - denetim kayıtlarında arama (anahtara, kullanıcıya, zamana göre):

Kod:
sudo ausearch -k passwd_degisiklik
sudo ausearch -ui 1000 --start today
sudo ausearch -m EXECVE --start recent

aureport - özet raporlar:

Kod:
sudo aureport --summary
sudo aureport -au        # kimlik doğrulama olayları
sudo aureport -f         # dosya olayları

5. Uygulamalı: Hassas Dosya ve Komut Denetimi
Adım 1 - /etc/shadow izleme kuralı ekleyin:

Kod:
sudo auditctl -w /etc/shadow -p wa -k shadow_izleme

Adım 2 - Dosyaya dokunarak olay üretin (lab):

Kod:
sudo touch /etc/shadow

Adım 3 - İlgili kaydı arayın:

Kod:
sudo ausearch -k shadow_izleme --start recent

Dönen kayıt şuna benzer alanlar içerir; type=SYSCALL satırında syscall, başarı durumu (success=yes), komut (comm="touch"), çalıştıran kullanıcı (auid) ve anahtar (key="shadow_izleme") yer alır:

Kod:
type=SYSCALL ... syscall=... success=yes ... comm="touch" exe="/usr/bin/touch" ... auid=1000 ... key="shadow_izleme"

Bu çıktı, hangi kullanıcının hangi komutla dosyaya dokunduğunu net biçimde gösterir.

Adım 4 - Komut çalıştırma denetimi ve özet rapor:

Kod:
sudo auditctl -a always,exit -F arch=b64 -S execve -k tum_komutlar
# birkaç komut çalıştırdıktan sonra
sudo aureport -x --summary

aureport -x çalıştırılabilir dosya (executable) bazında özet verir; anormal bir ikili (örn. beklenmedik bir yoldan çalışan kabuk) hemen göze çarpar.

6. Kalıcı Kurallar ve İleri İpuçları
auditctl ile eklenen kurallar yeniden başlatmada kaybolur. Kalıcılık için kuralları /etc/audit/rules.d/ altında bir .rules dosyasına yazın:

Kod:
# /etc/audit/rules.d/ozel.rules
-w /etc/passwd -p wa -k passwd_degisiklik
-w /etc/shadow -p wa -k shadow_izleme
-a always,exit -F arch=b64 -S execve -k komut_calistirma

Ardından kuralları derleyip yükleyin:

Kod:
sudo augenrules --load
sudo auditctl -l

Hazır kural setleri: CIS ve STIG uyumlu örnek kurallar için topluluk kural dosyalarını (ör. Neo23x0/auditd) başlangıç olarak inceleyebilirsiniz.
Değişmezlik: rules dosyasının sonuna "-e 2" eklemek, kural setini sonraki yeniden başlatmaya kadar kilitler; saldırganın denetimi kapatmasını zorlaştırır.
Performans: Her execve'yi kaydetmek yoğun sistemlerde çok log üretir; kapsamı anahtar dosyalar ve kritik çağrılarla sınırlayın.
Merkezileştirme: audispd eklentileriyle kayıtları bir SIEM'e iletebilirsiniz; yerelde kalan log, saldırgan tarafından silinebilir.

6.1. auditd ve Olay İzlemeyi Birlikte Düşünmek
auditd tek başına bir "tespit" aracı değildir; o, güvenilir bir ham kayıt üretir. Asıl değer, bu kayıtların düzenli olarak incelenmesi ve bir uyarı mekanizmasına bağlanmasıyla ortaya çıkar. Pratikte çoğu kurum auditd kayıtlarını audispd eklentileri aracılığıyla merkezi bir toplama noktasına (SIEM) iletir; çünkü yerelde kalan bir log, makineyi ele geçiren bir saldırgan tarafından silinebilir veya değiştirilebilir. Kayıtları ulaşıldığı anda ağ üzerinden dışarı taşımak, delil bütünlüğünü korumanın en sağlam yoludur.

Kural tasarlarken "her şeyi kaydet" tuzağına düşmeyin. Çekirdek düzeyinde her sistem çağrısını yakalamak teknik olarak mümkündür, ama yoğun bir sunucuda bu, dakikalar içinde gigabaytlarca log ve ciddi bir performans maliyeti anlamına gelir. Bunun yerine tehdit modelinize odaklanın: hassas yapılandırma dosyaları (/etc/passwd, /etc/shadow, /etc/sudoers), yetki yükseltme ile ilişkili ikililer, kimlik doğrulama olayları ve kritik dizinlerdeki değişiklikler. Az ama anlamlı kurallar, çok ama gürültülü kurallardan her zaman daha kullanışlıdır.

Son olarak, auditd kayıtlarını okumayı öğrenmek bir beceridir. type=SYSCALL, type=PATH ve type=EXECVE gibi farklı kayıt tipleri aynı olayın farklı yönlerini anlatır; ausearch bunları olay kimliğiyle gruplar. Bir kaydı incelerken auid (asıl oturum açan kullanıcı) ile uid (etkin kullanıcı) ayrımına özellikle dikkat edin: bir saldırgan sudo ile yetki yükseltse bile auid, gerçekte kimin oturum açtığını ele verir. Bu küçük detay, adli incelemede failin kim olduğunu belirlemenin anahtarıdır.

Sonuç
auditd, Linux'ta denetim izinin altın standardıdır: ince ayarlı kurallarla kimin neyi ne zaman yaptığını güvenilir biçimde kaydeder. watch ve syscall kurallarını, ausearch/aureport ile inceleme alışkanlığını ve kalıcı kural yönetimini oturttuğunuzda, hem tespit hem de adli inceleme kapasiteniz ciddi biçimde artar. Kuralları kritik varlıklara odaklayın ve mümkünse kayıtları merkezi bir sisteme iletin.

Kaynakça

Linux Audit Projesi (resmi) - https://github.com/linux-audit/audit-documentation
auditctl(8) Man Sayfası - https://man7.org/linux/man-pages/man8/auditctl.8.html
ausearch(8) ve aureport(8) man sayfaları - https://man7.org/linux/man-pages/man8/ausearch.8.html
Red Hat: Linux Audit Sistemi - https://access.redhat.com/documentation
CIS Benchmarks - https://www.cisecurity.org/cis-benchmarks

Yasal Uyarı

Alıntı:Denetim yapılandırması yalnızca kendi sistemlerinizde veya yönetim yetkiniz olan sistemlerde uygulanmalıdır. Başkasının sistemine izinsiz müdahale Türk Ceza Kanunu 243-245. maddeleri kapsamında suçtur.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

000-team-gb-konu-12.png (Dosya Boyutu: 56.67 KB / İndirme Sayısı: 10)

SSH Sertleştirme: Anahtar Tabanlı Giriş, Port ve Fail2ban Rehberi

Sun, 18 Oct 2026 11:03:43 +0300

Selam TurkTeam,

SSH, uzak sunucu yönetiminin bel kemiğidir; aynı nedenle de saldırganların en çok kaba kuvvet denediği servislerden biridir. İnternete açık bir SSH servisi, saatler içinde otomatik parola denemeleriyle dolar. Bu rehberde SSH'ı adım adım sertleştiriyoruz: anahtar tabanlı kimlik doğrulama, parola girişinin kapatılması, güvenli sunucu yapılandırması ve Fail2ban ile otomatik engelleme. Tüm adımlar kendi sunucunuz içindir.

Konuda Anlatılacaklar

SSH neden hedeftir, tehdit modeli
Anahtar çifti oluşturma ve sunucuya kurma
sshd_config ile güvenli yapılandırma
Önemli yapılandırma parametreleri referansı
Fail2ban kurulumu ve sshd jail yapılandırması
Doğrulama ve ileri ipuçları
Sonuç, kaynakça ve yasal uyarı

1. SSH Neden Hedeftir?
SSH genelde 22 portunda, internete açık çalışır ve doğrudan kabuk erişimi sağlar. Bu yüzden botnet'ler sürekli olarak yaygın kullanıcı adları (root, admin, ubuntu) ve zayıf parolalarla otomatik deneme yapar. Savunmanın özü iki ilkedir: tahmin edilebilir kimlik doğrulamayı (parola) ortadan kaldırmak ve kötü niyetli deneme trafiğini otomatik engellemek. Anahtar tabanlı giriş birincisini, Fail2ban ikincisini çözer.

2. Anahtar Çifti Oluşturma ve Kurma
İstemci makinenizde modern ve güçlü bir anahtar türü olan ed25519 ile çift oluşturun:

Kod:
ssh-keygen -t ed25519 -C "kullanici@ismakinesi"

Varsayılan olarak ~/.ssh/id_ed25519 (özel) ve id_ed25519.pub (açık) dosyaları oluşur. Parola koruması (passphrase) belirlemeniz, anahtar çalınsa bile koruma sağlar.

Açık anahtarı sunucuya kolayca kurmak için:

Kod:
ssh-copy-id -i ~/.ssh/id_ed25519.pub kullanici@sunucu_ip

Bu komut, açık anahtarı sunucudaki ~/.ssh/authorized_keys dosyasına ekler. Artık anahtarla giriş yapabilmelisiniz:

Kod:
ssh kullanici@sunucu_ip

3. sshd_config ile Güvenli Yapılandırma
Sunucuda /etc/ssh/sshd_config dosyasını düzenleyin (bir yedek alın):

Kod:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

Önerilen ayarlar:

Kod:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 3
X11Forwarding no
AllowUsers kullanici

Değişiklikten önce söz dizimini test edin, sonra servisi yeniden başlatın:

Kod:
sudo sshd -t
sudo systemctl restart ssh

Kritik uyarı: PasswordAuthentication no yapmadan önce anahtarla girebildiğinizden kesinlikle emin olun; aksi halde kendinizi kilitlersiniz. İlk bağlantıyı açık tutarak ikinci bir oturumdan test etmek güvenli bir alışkanlıktır.

4. Önemli Parametreler Referansı
PermitRootLogin no - Root ile doğrudan girişi kapatır; yönetici işleri sudo ile yapılır:

Kod:
PermitRootLogin no

PasswordAuthentication no - Parola girişini tamamen kapatır, yalnızca anahtar kalır:

Kod:
PasswordAuthentication no

MaxAuthTries - Bir bağlantıda izin verilen deneme sayısı:

Kod:
MaxAuthTries 3

AllowUsers / AllowGroups - Yalnızca belirli kullanıcı/grupların girişine izin:

Kod:
AllowUsers ahmet mehmet

Port - Standart dışı port, otomatik tarama gürültüsünü azaltır (güvenlik önlemi değil, sadece gürültü azaltma):

Kod:
Port 2222

ClientAliveInterval / ClientAliveCountMax - Atıl oturumları kapatma:

Kod:
ClientAliveInterval 300
ClientAliveCountMax 2

5. Fail2ban ile Otomatik Engelleme
Fail2ban, log dosyalarını izleyip belirli sayıda başarısız girişten sonra kaynak IP'yi güvenlik duvarında geçici olarak engeller.

Kod:
sudo apt update
sudo apt install fail2ban

Yerel ayarlarınızı varsayılanı ezmeyecek şekilde jail.local içine yazın:

Kod:
sudo nano /etc/fail2ban/jail.local

Kod:
[sshd]
enabled = true
maxretry = 4
findtime = 10m
bantime = 1h

Burada maxretry izin verilen başarısız deneme sayısını, findtime bu denemelerin sayılacağı pencereyi, bantime engel süresini belirtir. Servisi başlatıp etkinleştirin:

Kod:
sudo systemctl enable --now fail2ban

Durumu ve engellenen IP'leri görün:

Kod:
sudo fail2ban-client status sshd

Çıktı, aktif engelleri ve toplam yakalanan deneme sayısını gösterir:

Kod:
Status for the jail: sshd
|- Filter
|  `- Currently failed: 1
`- Actions
   |- Currently banned: 2
   `- Banned IP list: 203.0.113.10 198.51.100.20

Bir IP'yi elle engelden çıkarmak için:

Kod:
sudo fail2ban-client set sshd unbanip 203.0.113.10

6. Doğrulama ve İleri İpuçları

Yapılandırmayı doğrulayın: Yeni bir terminalden anahtarla bağlanın; parola istenmemsini ve root girişinin reddedildiğini kontrol edin.
2FA ekleyin: Kritik sunucularda Google Authenticator PAM modülüyle anahtar + TOTP ikili doğrulama kurulabilir.
Güvenlik duvarı: UFW/nftables ile SSH portunu yalnızca gereken ağlara açın; mümkünse bir VPN arkasına alın.
Anahtar hijyeni: Özel anahtar dosyası 600 izinli olmalı ve bir passphrase ile korunmalı; eski/yetkisiz anahtarları authorized_keys'ten temizleyin.
İzleme: Başarılı girişleri de izleyin; beklenmedik bir kaynaktan başarılı giriş, en önemli alarmdır.

6.1. Neden Anahtar Tabanlı Giriş Parolayı Yener?
Anahtar tabanlı kimlik doğrulamanın parolaya üstünlüğünü anlamak, bu sertleştirmenin neden bu kadar etkili olduğunu kavramanın anahtarıdır. Parola, tahmin edilebilen ve tekrar kullanılan bir sırdır; bir botnet saniyede yüzlerce parolayı deneyebilir ve zayıf bir parola er ya da geç bulunur. SSH anahtarı ise asimetrik kriptografiye dayanır: sunucu yalnızca açık anahtarı tutar, özel anahtar hiçbir zaman ağdan geçmez. Bir ed25519 anahtarını kaba kuvvetle bulmak pratikte imkansızdır. Dolayısıyla PasswordAuthentication no yaptığınız anda, saldırganların en sık kullandığı saldırı yüzeyini tamamen ortadan kaldırmış olursunuz; loglardaki başarısız giriş selinin aniden kesilmesi bunun gözle görülür kanıtıdır.

Bu noktada sık sorulan bir soru şudur: "Anahtar giriş zaten bu kadar güçlüyse Fail2ban'a ne gerek var?" Cevap katmanlı savunmadır. Fail2ban yalnızca parola denemelerini değil, portunuzu sürekli yoklayan gürültülü tarayıcıları da engelleyerek log kirliliğini ve kaynak tüketimini azaltır; ayrıca anahtar girişe geçişi henüz tamamlamadığınız veya bir servisin geçici olarak parola kullandığı durumlarda ek bir güvenlik ağı sağlar. Güvenlik tek bir mükemmel önleme değil, birbirini tamamlayan birden çok katmana dayanır.

Son bir pratik tavsiye: standart dışı port kullanımını bir güvenlik önlemi sanmayın. Portu 2222'ye almak otomatik tarama gürültüsünü azaltır, ancak hedefli bir saldırgan birkaç saniyede gerçek portu bulur. Gerçek güvenliği anahtar tabanlı giriş, root erişiminin kapatılması, güvenlik duvarı kısıtlaması ve mümkünse VPN sağlar; port değişikliği yalnızca bunların üstüne eklenen küçük bir konfordur, onların yerine geçmez.

Sonuç
SSH sertleştirmenin özü nettir: parolayı anahtarla değiştir, root ve gereksiz kullanıcı girişini kapat, deneme trafiğini Fail2ban ile otomatik engelle ve servisi güvenlik duvarı/VPN ile sınırla. Bu katmanlar birlikte, internete açık bir SSH'ı kaba kuvvete karşı pratikte işe yaramaz hale getirir. Her değişiklikten önce yedek alın, söz dizimini test edin ve kendinizi kilitlemeyin.

Kaynakça

OpenSSH Resmi Kılavuzu - https://www.openssh.com/manual.html
sshd_config(5) Man Sayfası - https://man.openbsd.org/sshd_config.5
ssh-keygen(1) Man Sayfası - https://man.openbsd.org/ssh-keygen.1
Fail2ban Resmi Wiki - https://github.com/fail2ban/fail2ban/wiki
Debian Wiki: Fail2ban - https://wiki.debian.org/fail2ban

Yasal Uyarı

Alıntı:Bu yapılandırmalar yalnızca kendi sunucularınızda veya yönetim yetkiniz olan sistemlerde uygulanmalıdır. Başkasının sistemine izinsiz erişim Türk Ceza Kanunu 243-245. maddeleri kapsamında suçtur.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

000-team-gb-konu-13.png (Dosya Boyutu: 56.25 KB / İndirme Sayısı: 10)

Linux Güvenlik Duvarı Rehberi: UFW ve nftables ile Sıfırdan Kural Yazımı

Sat, 17 Oct 2026 11:27:03 +0300

Bir sunucuyu kiralayıp hemen hizmet açmak kolay; onu güvenli hale getirmek ise genelde ertelenen iş. Oysa ilk saatlerde yapılması gereken en temel adımlardan biri güvenlik duvarını kurmak. Bu rehberde Linux'ta iki pratik yolu, yeni başlayanlar için UFW'yi ve altta yatan modern motor nftables'ı sıfırdan anlatıyorum.

Konuda anlatılacaklar

Linux güvenlik duvarı katmanları (netfilter, iptables, nftables, UFW)
UFW ile hızlı başlangıç
Sık kullanılan UFW kuralları
nftables mantığı ve temel yapı
Örnek nftables kural seti
Test etme ve sık hatalar
Yasal/operasyonel not

Katmanları Anlamak

Linux'ta paket filtreleme çekirdekteki netfilter altyapısına dayanır. Üstünde tarihsel olarak iptables vardı; modern dağıtımlar artık nftables kullanıyor. UFW (Uncomplicated Firewall) ise bunların üzerine oturan, insan dostu bir ön yüzdür. Yani:

Kod:
UFW  -->  (arka planda) nftables/iptables  -->  netfilter (çekirdek)

Yeni başlıyorsanız UFW ile başlayın; ne yaptığınızı anlamak isterseniz nftables'a inin.

UFW ile Hızlı Başlangıç

Kod:
sudo apt install ufw

# Varsayilan politika: gelen reddet, giden izin ver
sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH'i ACMADAN once izin verin, yoksa kendinizi kilitlersiniz!
sudo ufw allow 22/tcp

sudo ufw enable
sudo ufw status verbose

Çok önemli uyarı: Uzak bir sunucuda UFW'yi SSH portuna izin vermeden etkinleştirirseniz bağlantınız kopar ve dışarıda kalırsınız. Önce SSH'e izin, sonra enable.

Sık Kullanılan UFW Kuralları

Kod:
# Web sunucusu
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Belirli bir IP'den SSH
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

# Bir portu kapatma / kuralı silme
sudo ufw deny 23/tcp
sudo ufw delete allow 80/tcp

# Oran sinirlama (brute force'a karsi SSH)
sudo ufw limit 22/tcp

ufw limit, aynı IP'den kısa sürede çok bağlantı gelirse engeller; SSH kaba kuvvetine karşı basit ama etkili bir önlem.

nftables Mantığı

nftables'ta yapı şöyledir: table (aile: ip, ip6, inet) içinde chain'ler, chain içinde rule'lar bulunur. "inet" ailesi hem IPv4 hem IPv6 için tek yerde kural yazmayı sağlar.

Kod:
sudo apt install nftables
sudo systemctl enable --now nftables

Örnek nftables Kural Seti

/etc/nftables.conf içine temel ve güvenli bir başlangıç:

Kod:
#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # Mevcut baglantilar ve loopback
        ct state established,related accept
        iif "lo" accept

        # ICMP (ping) - istege bagli
        ip protocol icmp accept
        ip6 nexthdr icmpv6 accept

        # SSH (oran sinirli)
        tcp dport 22 ct state new limit rate 10/minute accept

        # Web
        tcp dport { 80, 443 } accept

        # Geri kalan her sey dusurulur (policy drop)
    }

    chain forward { type filter hook forward priority 0; policy drop; }
    chain output  { type filter hook output  priority 0; policy accept; }
}

Yüklemek ve kontrol:

Kod:
sudo nft -f /etc/nftables.conf
sudo nft list ruleset

Burada da aynı uyarı geçerli: policy drop koymadan önce SSH kuralının doğru olduğundan emin olun.

Test Etme ve Sık Hatalar

Değişiklik öncesi ikinci bir oturum/konsol erişimi (ör. sağlayıcının web konsolu) hazır tutun.
Kuralları başka bir makineden nmap ile doğrulayın: sadece beklenen portlar açık mı?
UFW ve ham nftables kurallarını aynı anda elle karıştırmayın; birini seçin.
Giden (output) trafiği gereksiz yere tamamen kapatmak sistem güncellemelerini bozabilir; dikkatli daraltın.
IPv6'yı unutmayın; sadece IPv4 kuralı yazmak yanıltıcı bir güvenlik hissi verir.

Sonuç

Güvenlik duvarı, sunucu sertleştirmenin ilk ve en ucuz adımı. UFW ile başlayın, mantığı oturunca nftables ile ince ayara geçin. Siz sunucularınızda hangi varsayılan kural setini kullanıyorsunuz, yorumlarda paylaşın; güzel bir şablon arşivi çıkabilir.

Yasal/Operasyonel Not

Bu rehber kendi sunucunuzu/sisteminizi korumak içindir. Yapılandırmayı yalnızca yönettiğiniz sistemlerde uygulayın; yanlış kural uzaktan erişiminizi kesebilir, önce test ortamında deneyin.

Görsel: TurkTeam özgün kapak görseli

tonyukuk-14-firewall.jpg (Dosya Boyutu: 77.7 KB / İndirme Sayısı: 9)

Linux Terminal Ipuclari: Her Guvenlikcinin Bilmesi Gereken 25 Komut

Sat, 17 Oct 2026 11:20:31 +0300

Selam millet,

Ise siber guvenlikte yeni baslayan arkadaslarda en sik gordugum eksik, terminalde rahat olmamak. Araclari biliyorlar ama kabukta (shell) takiliyorlar. Kendi notlarimdan derledigim, gunluk islerde surekli kullandigim 25 komutu paylasiyorum. Ezber degil, pratik hedef.

1) Dosya ve Dizin

Kod:
ls -lah          # detayli, okunur boyutlar
find / -name "*.conf" 2>/dev/null
tree -L 2         # dizin agaci
du -sh *          # klasor boyutlari
stat dosya        # dosya meta verisi

2) Metin Isleme (en degerlisi)
Log analizinin belkemigi bu ucludur:

Kod:
grep -rIn "hata" /var/log
awk '{print $1}' access.log | sort | uniq -c | sort -nr | head
sed -n '10,20p' dosya.txt
cut -d: -f1 /etc/passwd

En cok IP'yi bulan tek satir, SOC'ta surekli ise yarar.

3) Surec ve Sistem

Kod:
ps aux --sort=-%mem | head
top            # veya htop
lsof -i        # hangi surec hangi portu dinliyor
kill -9 PID

4) Ag

Kod:
ss -tulnp      # dinlenen portlar
ip a           # arayuzler
curl -I https://ornek.com
dig ornek.com

netstat yerine artik ss kullanin, cok daha hizli.

5) Yetki ve Kullanici

Kod:
sudo -l               # neyi sudo ile calistirabilirim
id
chmod / chown
history | grep ssh

6) Hayat Kurtaranlar

Kod:
!!            # son komutu tekrarla
sudo !!       # son komutu sudo ile
Ctrl+R        # komut gecmisinde arama
tmux          # oturumu koparsan bile surer

Benim en sevdigim Ctrl+R; uzun bir komutu tekrar yazmak yerine gecmiste ariyorum. tmux da uzun taramalarda SSH kopunca isi kurtariyor.

Kucuk Tavsiye
Bu komutlari tek tek ezberlemeye calismayin. Bir lab kurun, gercek bir gorev yapin (orn. bir logdan en cok istek atan IP'yi bulun), takildikca man sayfasina bakin. Birkac hafta sonra parmaklariniz kendiliginden yaziyor olacak.

Kaynaklar

Alıntı:Not: Komutlari once kendi lab makinenizde deneyin; find / gibi genis taramalar uretim sunucusunda yuk yaratabilir.

Sizin listeden eksik, olmazsa olmaz komutunuz hangisi?

kultigin-k01.png (Dosya Boyutu: 81.73 KB / İndirme Sayısı: 9)

journalctl ile SSH Log Analizi: Debian 12+ için auth.log Alternatifi

Fri, 16 Oct 2026 11:13:50 +0300

Selamlar,

Ubuntu'dan Debian 12'ye geçtiğimde ilk şaşırdığım şeylerden biri /var/log/auth.log dosyasının hiç oluşmaması oldu. rsyslog varsayılan kurulumda gelmiyor, her şey systemd journal içinde. Bu konuda "auth.log yok, SSH loglarım nerede?" diyenler için journalctl ile pratik bir rehber bırakıyorum.

Konuda Anlatılacaklar

Neden auth.log yok?
Servis adı: ssh mi, sshd mi?
Zaman aralığı, çıktı formatı ve filtreler
Dosyaya yazma ve Python ile birleştirme
Kalıcı log isterseniz rsyslog kurmak

1) Neden auth.log Yok?
Debian 12 (Bookworm) ve sonrasında varsayılan kurulumda rsyslog paketi gelmez. Loglar binary olarak /var/log/journal altına yazılır. Ubuntu'da rsyslog hâlâ varsayılan olduğu için auth.log alışkanlığı devam ediyor. İkisi de doğru; sadece araç değişiyor.

2) Servis Adı Dikkat
Debian/Ubuntu paketlerinde OpenSSH servisinin birimi çoğu zaman ssh.service, bazı eski veya özel kurulumlarda sshd.service olabilir. Hangisi aktifse onu kullanın:

Kod:
systemctl status ssh
# Unit ssh.service could not be found. ise:
systemctl status sshd

3) Temel Komutlar

Kod:
# Bugünün SSH logları, ham metin (scriptlere uygun)
sudo journalctl -u ssh --since today -o cat

# Son 2 saat, saat damgalı
sudo journalctl -u ssh --since "2 hours ago" -o short-iso

# Belirli bir IP'yi ara
sudo journalctl -u ssh --since yesterday | grep "198.51.100.7"

# Sadece hatalı denemeler
sudo journalctl -u ssh --since today | grep -E "Failed|Invalid user"

[-o cat] satır başındaki zaman damgasını kaldırıdığı için Python regex'lerinizi temiz tutar. Zaman damgası istiyorsanız [-o short-iso] kullanın.

4) Dosyaya Yazma ve Script
Forumdaki Python SSH analiz scripti stdin okuyabiliyor. journalctl çıktısını doğrudan borulayabilirsiniz:

Kod:
sudo journalctl -u ssh --since yesterday --until today -o cat | python3 ssh_tespit.py --esik 10

Kalıcı bir günlük özet dosyası için:

Kod:
sudo journalctl -u ssh --since yesterday --until today -o short-iso >> /var/log/ssh_gunluk.log

5) Klasik auth.log İsterseniz
Zorunlu değil ama alışkanlık için rsyslog kurulabilir:

Kod:
sudo apt update && sudo apt install -y rsyslog
sudo systemctl enable --now rsyslog
# Kısa süre sonra /var/log/auth.log oluşmaya başlar

Ben journalctl'ye alışmayı tercih ediyorum: tek komutla servis, zaman ve öncelik filtresi yapabiliyorsunuz.

Bonus: journald Boyut ve Kalıcılık
Laptop'ta lab çalıştırıyorsanız journal disk doldurabilir. /etc/systemd/journald.conf içinde SystemMaxUse=500M gibi bir sınır koyabilirsiniz. Kalıcı journal için /var/log/journal dizininin var olduğundan emin olun (Debian'da genelde vardır).

Ayrıca "öncelik" filtresi işe yarar:

Kod:
sudo journalctl -u ssh -p err..alert --since today

sadece hata ve üstü mesajları getirir. Brute force botları Failed satırlarını info seviyesinde yazar; bu yüzden brute force analizi için -p kullanmayın, grep kullanın.

Kaynaklar

Alıntı:Yasal not: Yalnızca kendi yönettiğiniz sistemlerde kullanın. TCK 243-245.

Kapak: özgün TurkTeam görseli.

bilgekagan-02.png (Dosya Boyutu: 83.35 KB / İndirme Sayısı: 9)