<![CDATA[TurkTeam | Türk Siber Güvenlik Topluluğu - Script ve Otomasyon]]> https://www.turkteam.org/ Sun, 25 Oct 2026 18:48:41 +0000 MyBB <![CDATA[gh auth status: GitHub CLI Token'larınızı Düzenli Kontrol Etmek]]> https://www.turkteam.org/konu-gh-auth-status-github-cli-token-larinizi-duzenli-kontrol-etmek.html Thu, 22 Oct 2026 11:33:33 +0300 KulTigin]]> https://www.turkteam.org/konu-gh-auth-status-github-cli-token-larinizi-duzenli-kontrol-etmek.html [Resim: attachment.php?aid=357]
Selamlar,

LiteLLM tedarik zinciri saldırısında saldırganın elinde üç geliştiriciye ait GitHub CLI OAuth token'ı vardı. Bunlardan biri organizasyon sahibi yetkisindeydi; branch koruması bu token ile aşıldı. Bu yazıda GitHub CLI'nin resmi gh auth status komutunu kullanarak kendi makinelerinizdeki token durumunu nasıl kontrol edeceğinizi anlatıyorum.

Konuda anlatılacaklar
  1. gh auth status ne gösterir?
  2. JSON çıktısı ve otomasyon
  3. Token hijyeni için pratik kurallar
  4. Sızma şüphesinde yapılacaklar

gh auth status
Resmi kılavuza göre komut, bilinen her GitHub host'unda aktif hesabı ve kimlik doğrulama durumunu gösterir. Her hesap için durum test edilir; sorunlar çıktıya eklenir. Süresi dolmuş veya dolmak üzere olan ve yenilenebilen token'lar, --no-refresh verilmedikçe otomatik yenilenir. Herhangi bir hesapta kimlik doğrulama sorunu varsa komut çıkış kodu 1 ile biter (JSON modu hariç).

Kod:
# Tum host ve hesaplar gh auth status # Yalnizca aktif hesap gh auth status --active # Belirli host gh auth status --hostname github.com # JSON (otomasyon icin); token'i da eklemek icin --show-token gh auth status --json hosts # DIKKAT: --show-token token'i duz metin basar; ekran paylasiminda kullanmayin

Ne aramalısınız?
  • Beklemediğiniz ekstra hesaplar veya host'lar
  • Organizasyon sahibi / admin yetkili hesapların geliştirici laptop'larında uzun süre durması
  • CI dışında kişisel makinelerde duran yüksek yetkili token'lar
  • Eski, kullanılmayan host girişleri

Pratik hijyen kuralları
  1. Yüksek yetkili (org owner) hesaplarla günlük geliştirme yapmayın; ayrı bir "günlük" hesap kullanın.
  2. gh auth logout ile kullanılmayan girişleri kapatın; github.com/settings/applications üzerinden yetkilendirilmiş OAuth uygulamalarını gözden geçirin.
  3. Token'ların YZ asistanı yanıtlarına veya loglara düşebileceğini varsayın (LiteLLM'in olay sonrası değerlendirmesi tam da bunu işaret ediyor). Loglarda Authorization / gho_ / ghp_ araması yapın.
  4. CI için fine-grained veya environment-scoped token kullanın; laptop OAuth token'ını CI'ya taşımayın.

Kod:
# Basit periyodik kontrol (kendi makineniz) gh auth status --active 2>&1 | tee ~/gh-auth-check-$(date +%F).log # Beklenmeyen hesap varsa alarm (ornek) gh auth status --json hosts --jq '.hosts[].accounts[].username' | grep -vE '^(sizin_beklenen_kullanici)$' && echo "beklenmeyen hesap" || true

Organizasyonunuzda org owner hesabıyla günlük commit atan var mı? Ayrı günlük hesap politikası uyguluyor musunuz?

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

.png   16-k01-gh-auth-token.png (Dosya Boyutu: 101.96 KB / İndirme Sayısı: 10) ]]> [Resim: attachment.php?aid=357]
Selamlar,

LiteLLM tedarik zinciri saldırısında saldırganın elinde üç geliştiriciye ait GitHub CLI OAuth token'ı vardı. Bunlardan biri organizasyon sahibi yetkisindeydi; branch koruması bu token ile aşıldı. Bu yazıda GitHub CLI'nin resmi gh auth status komutunu kullanarak kendi makinelerinizdeki token durumunu nasıl kontrol edeceğinizi anlatıyorum.

Konuda anlatılacaklar
  1. gh auth status ne gösterir?
  2. JSON çıktısı ve otomasyon
  3. Token hijyeni için pratik kurallar
  4. Sızma şüphesinde yapılacaklar

gh auth status
Resmi kılavuza göre komut, bilinen her GitHub host'unda aktif hesabı ve kimlik doğrulama durumunu gösterir. Her hesap için durum test edilir; sorunlar çıktıya eklenir. Süresi dolmuş veya dolmak üzere olan ve yenilenebilen token'lar, --no-refresh verilmedikçe otomatik yenilenir. Herhangi bir hesapta kimlik doğrulama sorunu varsa komut çıkış kodu 1 ile biter (JSON modu hariç).

Kod:
# Tum host ve hesaplar gh auth status # Yalnizca aktif hesap gh auth status --active # Belirli host gh auth status --hostname github.com # JSON (otomasyon icin); token'i da eklemek icin --show-token gh auth status --json hosts # DIKKAT: --show-token token'i duz metin basar; ekran paylasiminda kullanmayin

Ne aramalısınız?
  • Beklemediğiniz ekstra hesaplar veya host'lar
  • Organizasyon sahibi / admin yetkili hesapların geliştirici laptop'larında uzun süre durması
  • CI dışında kişisel makinelerde duran yüksek yetkili token'lar
  • Eski, kullanılmayan host girişleri

Pratik hijyen kuralları
  1. Yüksek yetkili (org owner) hesaplarla günlük geliştirme yapmayın; ayrı bir "günlük" hesap kullanın.
  2. gh auth logout ile kullanılmayan girişleri kapatın; github.com/settings/applications üzerinden yetkilendirilmiş OAuth uygulamalarını gözden geçirin.
  3. Token'ların YZ asistanı yanıtlarına veya loglara düşebileceğini varsayın (LiteLLM'in olay sonrası değerlendirmesi tam da bunu işaret ediyor). Loglarda Authorization / gho_ / ghp_ araması yapın.
  4. CI için fine-grained veya environment-scoped token kullanın; laptop OAuth token'ını CI'ya taşımayın.

Kod:
# Basit periyodik kontrol (kendi makineniz) gh auth status --active 2>&1 | tee ~/gh-auth-check-$(date +%F).log # Beklenmeyen hesap varsa alarm (ornek) gh auth status --json hosts --jq '.hosts[].accounts[].username' | grep -vE '^(sizin_beklenen_kullanici)$' && echo "beklenmeyen hesap" || true

Organizasyonunuzda org owner hesabıyla günlük commit atan var mı? Ayrı günlük hesap politikası uyguluyor musunuz?

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

.png   16-k01-gh-auth-token.png (Dosya Boyutu: 101.96 KB / İndirme Sayısı: 10) ]]> <![CDATA[Bash Aliases: Pentest İçin Küçük Hızlandırıcılar ve Güvenli Alışkanlıklar]]> https://www.turkteam.org/konu-bash-aliases-pentest-icin-kucuk-hizlandiricilar-ve-guvenli-aliskanliklar.html Mon, 19 Oct 2026 00:48:28 +0300 KulTigin]]> https://www.turkteam.org/konu-bash-aliases-pentest-icin-kucuk-hizlandiricilar-ve-guvenli-aliskanliklar.html [Resim: attachment.php?aid=271]
Merhaba,

Her pentest lab oturumunda aynı uzun komutları yazmak can sıkıcı. Ama rastgele alias da tehlikeli: yanlış host'a agresif tarama göndermek bir tuş kadar yakın olabilir. Bu yazıda kendi .bashrc notlarımı, güvenli alışkanlıklarla birlikte paylaşıyorum.

Temel: nerede tutmalı?
Kod:
# ~/.bashrc veya ~/.bash_aliases # Değişiklikten sonra: source ~/.bashrc
Kali/Parrot'ta bazen .zshrc kullanırsınız; shell'inizi bilin. Alias'ları git ile dotfiles reposunda tutuyorum (sır yok; API anahtarı koymayın).

Güvenli ve faydalı alias örnekleri
Kod:
# İnsan okur ls alias ll='ls -alFh --color=auto' alias ..='cd ..' # nmap: varsayılan olarak nazik zamanlama + çıktı kaydı hatırlatması alias nquick='nmap -sV -T3 --top-ports 100' alias nfull='nmap -sV -T3 -p-' # tcpdump: -nn unutulmasın alias td='sudo tcpdump -nn' # Güvenli rm değil; çöp kutusu alışkanlığı (trash-cli) alias rm='trash'

[Resim: attachment.php?aid=272]

Fonksiyon > uzun alias
Parametre alan işler için function yazın:
Kod:
nlab() { # kullanım: nlab 10.10.10.50 local t="$1" [[ -z "$t" ]] && { echo "hedef yok"; return 1; } local out="nmap-${t//\//_}-$(date +%F-%H%M)" nmap -sV -T3 -p 22,80,443,445 -oA "$out" "$t" echo "çıktı: $out.*" }
Bu pattern "çıktıyı kaydetmeyi unuttum" felaketini azaltır.

Tehlikeli kısayollar (yapmayın)
  • alias nmap='nmap -T5 -A -p-' — her seferinde agresif; yanlış hedefte felaket
  • Hedefi sabit kodlayan alias'lar (eski müşteri IP'si kalabilir)
  • curl | sh benzeri kısayollar
  • Parola / API anahtarı içeren export'lar (dotfiles sızarsa biter)

Onay isteyen sarmalayıcı
Agresif işler için bilinçli onay:
Kod:
nagg() { echo "HEDEF: $1 | agresif tarama" read -r -p "Emin misin? yaz EVET: " a [[ "$a" == "EVET" ]] || { echo "iptal"; return 1; } nmap -sV -T4 -A "$1" }

Ortam değişkenleri
Kod:
export EDITOR=vim export HISTCONTROL=ignoredups:erasedups export HISTSIZE=5000
Proxy gereken labda:
Kod:
# export http_proxy=... # sadece o oturum
Kalıcı proxy alias'ı yerine direnv veya elle export tercih ederim; unutulmuş proxy daha sonra her curl'ü bozar.

tmux ile birleştirmek
Alias'lar tek terminalde işe yarar; uzun taramayı tmux'ta koşturun. Benim sık kullandığım:
Kod:
alias ta='tmux attach -t' alias tn='tmux new -s'

Paylaşılabilir dotfiles disiplini
  • Sırları ayrı tut (pass, gopass, 1Password CLI)
  • Makineye özel dosyayı .bashrc.local diye ayırıp git'e koyma
  • alias listesini periyodik gözden geçir; kullanılmayanı sil
Kod:
alias type nquick

Kaynaklar
  • bash(1) ALIASES ve FUNCTIONS bölümleri
  • tmux wiki
  • trash-cli

Sizin en çok zaman kazandıran fonksiyonunuz hangisi? Zararsız olanları yorumda paylaşın; agresif tarama one-liner'larını lütfen paylaşmayın.

direnv ve proje bazlı ortam
Her müşteri labı için ayrı dizin + .envrc (direnv) kullanıyorum. Proxy, hedef IP, VPN arayüzü o dizine girince yüklenir; çıkınca iner. Global alias'a hedef IP gömmek yerine bu yöntem yanlış müşteriye paket gönderme riskini azaltır.

Tamamlama ve güvenlik
bash-completion nmap için kullanışlıdır ama tab-complete ile yanlış bayrağı seçebilirsiniz. Kritik komutlarda --help satırını bir kez daha okuma alışkanlığı, agresif alias'tan daha çok can kurtarır.


Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
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.

.png   100-n09-63766b.png (Dosya Boyutu: 61.94 KB / İndirme Sayısı: 12)

.png   n09-inner.png (Dosya Boyutu: 19.45 KB / İndirme Sayısı: 11) ]]> [Resim: attachment.php?aid=271]
Merhaba,

Her pentest lab oturumunda aynı uzun komutları yazmak can sıkıcı. Ama rastgele alias da tehlikeli: yanlış host'a agresif tarama göndermek bir tuş kadar yakın olabilir. Bu yazıda kendi .bashrc notlarımı, güvenli alışkanlıklarla birlikte paylaşıyorum.

Temel: nerede tutmalı?
Kod:
# ~/.bashrc veya ~/.bash_aliases # Değişiklikten sonra: source ~/.bashrc
Kali/Parrot'ta bazen .zshrc kullanırsınız; shell'inizi bilin. Alias'ları git ile dotfiles reposunda tutuyorum (sır yok; API anahtarı koymayın).

Güvenli ve faydalı alias örnekleri
Kod:
# İnsan okur ls alias ll='ls -alFh --color=auto' alias ..='cd ..' # nmap: varsayılan olarak nazik zamanlama + çıktı kaydı hatırlatması alias nquick='nmap -sV -T3 --top-ports 100' alias nfull='nmap -sV -T3 -p-' # tcpdump: -nn unutulmasın alias td='sudo tcpdump -nn' # Güvenli rm değil; çöp kutusu alışkanlığı (trash-cli) alias rm='trash'

[Resim: attachment.php?aid=272]

Fonksiyon > uzun alias
Parametre alan işler için function yazın:
Kod:
nlab() { # kullanım: nlab 10.10.10.50 local t="$1" [[ -z "$t" ]] && { echo "hedef yok"; return 1; } local out="nmap-${t//\//_}-$(date +%F-%H%M)" nmap -sV -T3 -p 22,80,443,445 -oA "$out" "$t" echo "çıktı: $out.*" }
Bu pattern "çıktıyı kaydetmeyi unuttum" felaketini azaltır.

Tehlikeli kısayollar (yapmayın)
  • alias nmap='nmap -T5 -A -p-' — her seferinde agresif; yanlış hedefte felaket
  • Hedefi sabit kodlayan alias'lar (eski müşteri IP'si kalabilir)
  • curl | sh benzeri kısayollar
  • Parola / API anahtarı içeren export'lar (dotfiles sızarsa biter)

Onay isteyen sarmalayıcı
Agresif işler için bilinçli onay:
Kod:
nagg() { echo "HEDEF: $1 | agresif tarama" read -r -p "Emin misin? yaz EVET: " a [[ "$a" == "EVET" ]] || { echo "iptal"; return 1; } nmap -sV -T4 -A "$1" }

Ortam değişkenleri
Kod:
export EDITOR=vim export HISTCONTROL=ignoredups:erasedups export HISTSIZE=5000
Proxy gereken labda:
Kod:
# export http_proxy=... # sadece o oturum
Kalıcı proxy alias'ı yerine direnv veya elle export tercih ederim; unutulmuş proxy daha sonra her curl'ü bozar.

tmux ile birleştirmek
Alias'lar tek terminalde işe yarar; uzun taramayı tmux'ta koşturun. Benim sık kullandığım:
Kod:
alias ta='tmux attach -t' alias tn='tmux new -s'

Paylaşılabilir dotfiles disiplini
  • Sırları ayrı tut (pass, gopass, 1Password CLI)
  • Makineye özel dosyayı .bashrc.local diye ayırıp git'e koyma
  • alias listesini periyodik gözden geçir; kullanılmayanı sil
Kod:
alias type nquick

Kaynaklar
  • bash(1) ALIASES ve FUNCTIONS bölümleri
  • tmux wiki
  • trash-cli

Sizin en çok zaman kazandıran fonksiyonunuz hangisi? Zararsız olanları yorumda paylaşın; agresif tarama one-liner'larını lütfen paylaşmayın.

direnv ve proje bazlı ortam
Her müşteri labı için ayrı dizin + .envrc (direnv) kullanıyorum. Proxy, hedef IP, VPN arayüzü o dizine girince yüklenir; çıkınca iner. Global alias'a hedef IP gömmek yerine bu yöntem yanlış müşteriye paket gönderme riskini azaltır.

Tamamlama ve güvenlik
bash-completion nmap için kullanışlıdır ama tab-complete ile yanlış bayrağı seçebilirsiniz. Kritik komutlarda --help satırını bir kez daha okuma alışkanlığı, agresif alias'tan daha çok can kurtarır.


Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
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.

.png   100-n09-63766b.png (Dosya Boyutu: 61.94 KB / İndirme Sayısı: 12)

.png   n09-inner.png (Dosya Boyutu: 19.45 KB / İndirme Sayısı: 11) ]]> <![CDATA[PowerShell ile Gunluk Guvenlik Kontrolu: Otomatik Tarama Scripti]]> https://www.turkteam.org/konu-powershell-ile-gunluk-guvenlik-kontrolu-otomatik-tarama-scripti.html Sat, 17 Oct 2026 11:24:09 +0300 KulTigin]]> https://www.turkteam.org/konu-powershell-ile-gunluk-guvenlik-kontrolu-otomatik-tarama-scripti.html [Resim: attachment.php?aid=93]
Herkese selam,

Windows makinelerinde her sabah elle kontrol ettigim birkac sey vardi: yeni acilan kullanicilar, dinlenen portlar, kritik servislerin durumu. Bunlari tek bir PowerShell scriptine topladim, her sabah otomatik calisiyor. Paylasayim dedim, belki isinize yarar.

Konuda Anlatilacaklar
  1. Neden otomasyon?
  2. Kontrol scripti
  3. Zamanlanmis gorev olarak kurma
  4. Ciktinin degerlendirilmesi

1) Neden Otomasyon?
Elle kontrol atlanir, unutulur, insana bagli olur. Ayni islemi script yaparsa her gun ayni gozle bakilir, cikti kaydedilir, karsilastirilabilir. Basit ama etkili.

2) Kontrol Scripti
Asagidaki script temel bir durum fotografi cikarir:

Kod:
$rapor = "C:\secaudit\rapor_$(Get-Date -Format yyyyMMdd).txt" New-Item -ItemType Directory -Force -Path C:\secaudit | Out-Null "=== Aktif Yerel Kullanicilar ===" | Out-File $rapor Get-LocalUser | Where-Object Enabled | Select-Object Name, LastLogon | Out-File $rapor -Append "`n=== Dinlenen TCP Portlari ===" | Out-File $rapor -Append Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess | Sort-Object LocalPort | Out-File $rapor -Append "`n=== Kritik Servisler ===" | Out-File $rapor -Append Get-Service -Name WinDefend, EventLog, Wuauserv | Select-Object Name, Status | Out-File $rapor -Append "`n=== Son 10 Guvenlik Olayi (4625 - basarisiz giris) ===" | Out-File $rapor -Append Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 10 -ErrorAction SilentlyContinue | Select-Object TimeCreated, Message | Out-File $rapor -Append

3) Zamanlanmis Gorev
Her sabah 08:00'de calistirmak icin:

Kod:
$act = New-ScheduledTaskAction -Execute "powershell.exe" ` -Argument "-File C:\secaudit\gunluk.ps1" $trg = New-ScheduledTaskTrigger -Daily -At 8am Register-ScheduledTask -TaskName "GunlukGuvenlikKontrol" ` -Action $act -Trigger $trg -RunLevel Highest

4) Cikti Degerlendirme
Raporlari gun gun karsilastirin. Dun olmayan bir kullanici bugun varsa, beklenmedik bir port dinleniyorsa veya 4625 (basarisiz giris) olaylari aniden artmissa, bu incelemeye deger. Script tespit yapmaz, gorunurluk saglar; yorumu siz yaparsiniz.

Kaynaklar
Alıntı:Yasal not: Scripti yalnizca yonettiginiz bilgisayarlarda calistirin.

Siz gunluk kontrol scriptinize baska ne eklerdiniz?

.png   kultigin-k03.png (Dosya Boyutu: 83.5 KB / İndirme Sayısı: 9) ]]> [Resim: attachment.php?aid=93]
Herkese selam,

Windows makinelerinde her sabah elle kontrol ettigim birkac sey vardi: yeni acilan kullanicilar, dinlenen portlar, kritik servislerin durumu. Bunlari tek bir PowerShell scriptine topladim, her sabah otomatik calisiyor. Paylasayim dedim, belki isinize yarar.

Konuda Anlatilacaklar
  1. Neden otomasyon?
  2. Kontrol scripti
  3. Zamanlanmis gorev olarak kurma
  4. Ciktinin degerlendirilmesi

1) Neden Otomasyon?
Elle kontrol atlanir, unutulur, insana bagli olur. Ayni islemi script yaparsa her gun ayni gozle bakilir, cikti kaydedilir, karsilastirilabilir. Basit ama etkili.

2) Kontrol Scripti
Asagidaki script temel bir durum fotografi cikarir:

Kod:
$rapor = "C:\secaudit\rapor_$(Get-Date -Format yyyyMMdd).txt" New-Item -ItemType Directory -Force -Path C:\secaudit | Out-Null "=== Aktif Yerel Kullanicilar ===" | Out-File $rapor Get-LocalUser | Where-Object Enabled | Select-Object Name, LastLogon | Out-File $rapor -Append "`n=== Dinlenen TCP Portlari ===" | Out-File $rapor -Append Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess | Sort-Object LocalPort | Out-File $rapor -Append "`n=== Kritik Servisler ===" | Out-File $rapor -Append Get-Service -Name WinDefend, EventLog, Wuauserv | Select-Object Name, Status | Out-File $rapor -Append "`n=== Son 10 Guvenlik Olayi (4625 - basarisiz giris) ===" | Out-File $rapor -Append Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 10 -ErrorAction SilentlyContinue | Select-Object TimeCreated, Message | Out-File $rapor -Append

3) Zamanlanmis Gorev
Her sabah 08:00'de calistirmak icin:

Kod:
$act = New-ScheduledTaskAction -Execute "powershell.exe" ` -Argument "-File C:\secaudit\gunluk.ps1" $trg = New-ScheduledTaskTrigger -Daily -At 8am Register-ScheduledTask -TaskName "GunlukGuvenlikKontrol" ` -Action $act -Trigger $trg -RunLevel Highest

4) Cikti Degerlendirme
Raporlari gun gun karsilastirin. Dun olmayan bir kullanici bugun varsa, beklenmedik bir port dinleniyorsa veya 4625 (basarisiz giris) olaylari aniden artmissa, bu incelemeye deger. Script tespit yapmaz, gorunurluk saglar; yorumu siz yaparsiniz.

Kaynaklar
Alıntı:Yasal not: Scripti yalnizca yonettiginiz bilgisayarlarda calistirin.

Siz gunluk kontrol scriptinize baska ne eklerdiniz?

.png   kultigin-k03.png (Dosya Boyutu: 83.5 KB / İndirme Sayısı: 9) ]]> <![CDATA[Bash ile Log Temizliği ve Rotasyon: find, xargs, logrotate Notları]]> https://www.turkteam.org/konu-bash-ile-log-temizligi-ve-rotasyon-find-xargs-logrotate-notlari.html Fri, 16 Oct 2026 11:21:20 +0300 BilgeKagan]]> https://www.turkteam.org/konu-bash-ile-log-temizligi-ve-rotasyon-find-xargs-logrotate-notlari.html [Resim: attachment.php?aid=34]
Selamlar,

Lab ve küçük VPS'lerde loglar hızla şişiyor. journald'yi sınırlamak bir çözüm; klasik metin loglar için de Bash ile basit bakım şart. Bu konuda kendi cron'umda kullandığım güvenli kalıpları yazıyorum.

Konuda Anlatılacaklar
  1. find ile eski log bulma
  2. xargs tuzakları (boşluklu dosya adları)
  3. Sıkıştırma ve silme
  4. logrotate'a bırakmak daha doğru mu?
  5. Örnek cron

1) find Temelleri
Kod:
# Son 1 günde değişen .log dosyaları find /var/log -type f -name '*.log' -mtime -1 # 14 günden eski, boyutu 10M üstü find /var/log -type f -name '*.log' -mtime +14 -size +10M -ls

[-mtime +14] "14 tam günden eski", [-size +10M] "10 mebibayttan büyük" demek.

2) xargs ve Güvenli Silme
Kod:
# YANLIŞ: boşluklu isimde kırılır find /var/log -name '*.log' -mtime +30 | xargs rm # DOĞRU: null ayracı find /var/log -type f -name '*.log' -mtime +30 -print0 | xargs -0 rm -v # Daha da iyisi: find -delete (aynı süreçte) find /var/log -type f -name '*.log' -mtime +30 -delete

Silmeden önce [-ls] ile listeleyin. Üretimde körlemesine rm kullanmayın.

3) Sıkıştırma
Kod:
find /var/log -type f -name '*.log' -mtime +2 ! -name '*.gz' -print0 | xargs -0 gzip -9

gzip orijinali siler; .gz uzantılı dosyayı tekrar sıkıştırmamak için [! -name '*.gz'] şart.

4) logrotate Tercih Edin
Debian/Ubuntu'da /etc/logrotate.d/ altında servis bazlı kurallar vardır. Kendi uygulamanız için:

Kod:
/var/log/benimapp/*.log { weekly rotate 8 compress delaycompress missingok notifempty copytruncate }

Bash one-liner'lar acil temizlik içindir; uzun vadede logrotate + journald SystemMaxUse.

5) Örnek Cron
Kod:
# Her pazar 04:30 - 30 günden eski uygulama loglarını sıkıştır 30 4 * * 0 find /var/log/benimapp -type f -name '*.log' -mtime +30 -print0 | xargs -0 gzip -9

Kaynaklar
Alıntı:Yalnızca kendi sistemlerinizde kullanın.

Kapak: özgün TurkTeam görseli.

.png   bilgekagan-06.png (Dosya Boyutu: 89.03 KB / İndirme Sayısı: 11) ]]> [Resim: attachment.php?aid=34]
Selamlar,

Lab ve küçük VPS'lerde loglar hızla şişiyor. journald'yi sınırlamak bir çözüm; klasik metin loglar için de Bash ile basit bakım şart. Bu konuda kendi cron'umda kullandığım güvenli kalıpları yazıyorum.

Konuda Anlatılacaklar
  1. find ile eski log bulma
  2. xargs tuzakları (boşluklu dosya adları)
  3. Sıkıştırma ve silme
  4. logrotate'a bırakmak daha doğru mu?
  5. Örnek cron

1) find Temelleri
Kod:
# Son 1 günde değişen .log dosyaları find /var/log -type f -name '*.log' -mtime -1 # 14 günden eski, boyutu 10M üstü find /var/log -type f -name '*.log' -mtime +14 -size +10M -ls

[-mtime +14] "14 tam günden eski", [-size +10M] "10 mebibayttan büyük" demek.

2) xargs ve Güvenli Silme
Kod:
# YANLIŞ: boşluklu isimde kırılır find /var/log -name '*.log' -mtime +30 | xargs rm # DOĞRU: null ayracı find /var/log -type f -name '*.log' -mtime +30 -print0 | xargs -0 rm -v # Daha da iyisi: find -delete (aynı süreçte) find /var/log -type f -name '*.log' -mtime +30 -delete

Silmeden önce [-ls] ile listeleyin. Üretimde körlemesine rm kullanmayın.

3) Sıkıştırma
Kod:
find /var/log -type f -name '*.log' -mtime +2 ! -name '*.gz' -print0 | xargs -0 gzip -9

gzip orijinali siler; .gz uzantılı dosyayı tekrar sıkıştırmamak için [! -name '*.gz'] şart.

4) logrotate Tercih Edin
Debian/Ubuntu'da /etc/logrotate.d/ altında servis bazlı kurallar vardır. Kendi uygulamanız için:

Kod:
/var/log/benimapp/*.log { weekly rotate 8 compress delaycompress missingok notifempty copytruncate }

Bash one-liner'lar acil temizlik içindir; uzun vadede logrotate + journald SystemMaxUse.

5) Örnek Cron
Kod:
# Her pazar 04:30 - 30 günden eski uygulama loglarını sıkıştır 30 4 * * 0 find /var/log/benimapp -type f -name '*.log' -mtime +30 -print0 | xargs -0 gzip -9

Kaynaklar
Alıntı:Yalnızca kendi sistemlerinizde kullanın.

Kapak: özgün TurkTeam görseli.

.png   bilgekagan-06.png (Dosya Boyutu: 89.03 KB / İndirme Sayısı: 11) ]]>