Konuyu Okuyanlar: 1 Ziyaretçi

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

Bash Scripting ile Basit Güvenlik Otomasyonu: Sıfırdan Giriş
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
  1. Bash betiği nedir, shebang ve çalıştırma
  2. Değişkenler, komut ikamesi ve tırnak kuralları
  3. Koşullar, karşılaştırmalar ve çıkış kodları
  4. Döngüler ve fonksiyonlar
  5. Uygulamalı: güvenlik kontrol betiği
  6. Güvenli betik yazımı ve zamanlama (cron)
  7. 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.
[Resim: attachment.php?aid=157]

Çıktıyı dosyaya kaydetme: Raporu tarihli bir dosyaya yazdırmak için:
Kod:
./guvenlik_kontrol.sh | tee "rapor_$(date +%F).txt"
[Resim: attachment.php?aid=184]


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
[Resim: attachment.php?aid=185]

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
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).


Ek DosyalarEkran Görüntüleri
   
Cevapla



Hızlı Menü: