Daha fazla saldırgan, düşük ayrıcalıklı bir hesabı ele geçirip ardından sudo yapılandırmalarındaki hataları araştırmaya çalışıyor. Ortamımda, syslog'u rsyslog üzerinden ayrı bir log sunucusuna merkezileştiriyorum; bu da temiz bir veri akışı sağlıyor. Statik sudoers kurallarına veya basit anahtar kelime eşleştirmesine güvenmek yerine, bir LLM'nin gerçekten anormal sudo davranışlarını tespit etmesine yardımcı olabileceğini görmek istedim—örneğin, bir kullanıcı sadece sudo apt update kullandıktan sonra aniden sudo passwd root veya sudo visudo çalıştırmaya başlayıp başlayamayacağı.
Bunu nasıl kurduğumu şöyle yaptım.
sudo olaylarını syslog'tan ayrıştırma
İlk olarak, sudo günlüklerinin yakalanmasını sağlarım. Ubuntu/Debian'de, sudo auth.log dosyasına yazar ve bu dosya rsyslog tarafından iletilir. Sudo girişlerini filtrelemek için basit bir rsyslog kuralı kullanırım:
authpriv.* /var/log/sudo.log
& ~Ardından rsyslog'u yeniden başlatırım. Bu işlem, şu gibi satırları içeren temiz bir dosya sağlar:
May 10 09:15:22 host sudo: furkan : TTY=pts/0 ; PWD=/home/furkan ; USER=root ; COMMAND=/bin/systemctl restart nginx May 10 09:16:01 host sudo: furkan : TTY=pts/0 ; PWD=/home/furkan ; USER=root ; COMMAND=/usr/bin/passwd root
Bu dosyayı izleyerek kullanıcı adı, komut ve zaman damgasını çıkarırım.
sudo komutlarını anomali tespiti için bir LLM'e besleme
Sürekli çalışan, /var/log/sudo.log dosyasından yeni satırları okuyan küçük bir Python betiği yazdım. Her sudo olayı için, kullanıcıyı ve tam komutu çıkarır, ardından bu bilgileri yerel bir LLM'e gönderirim (Ollama ile mistral modelini kullanıyorum):
""" Aşağıdaki sudo komutunu ayrıcalık yükseltme, sistem manipülasyonu veya kimlik bilgisi erişimi gibi anomali işaretleri için analiz et. Sadece 'ANOMALY' veya 'NORMAL' olarak yanıt ver.
Kullanıcı: furkan Komut: /usr/bin/passwd root """
LLM 'ANOMALY' döndürdüğünde, betik bir eylem tetikler. Zamanla prompt'u iyileştirdim—sudo chmod 4755 /bin/bash veya sudo echo 'ALL ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers gibi tehlikeli komut örnekleri ekleyerek—yanlış pozitifleri azaltmak için. Mükemmel değil, ancak kural tabanlı sistemlerin kaçırdığı şeyleri, özellikle yeni saldırı desenlerini yakalamada etkili.
Otomatik olarak iptables ile engelleme
Bir anomali tespit edildiğinde, sadece uyarı vermekle kalmıyorum—kaynak IP'yi güvenlik duvarı seviyesinde engelliyorum. sudo yerel olarak çalıştığı için, ilgili IP, oturumun SSH kaynağıdır. Bu IP'yi journal'dan veya TTY'ye bağlı who/w çıktısından çıkarırım.
İşte temel eylem:
IP=$(who | grep "$TTY" | awk '{print $5}' | tr -d '()')
if [ -n "$IP" ]; then
iptables -I INPUT -s $IP -j DROP
logger -t sudo-llm-block "Blocked $IP after anomalous sudo: $COMMAND"
fiBu işlemi systemd üzerinden çalıştırdığım bir script içinde sarmalarım, böylece yeniden başlatmalar sonrası da aktif kalır. Ayrıca bir zaman aşımı ekliyorum—20 dakika sonra kural otomatik olarak kaldırılır; bunu iptables ile recent modülü kullanarak ya da temizleme scriptini çağıran bir systemd zamanlayıcı ile yaparım.
Kullanıcı bazeline'leriyle false positive'ları azaltma
Başlangıçta karşılaştığım bir sorun: LLM, nadir ancak meşru yönetici görevlerini, örneğin sudo openssl kullanan bir aylık sertifika yenileme betiğini işaretliyordu. Bunu düzeltmek için hafif bir kullanıcı bazeline'i ekledim. Betik, daha önce görülen (kullanıcı, komut) çiftlerini yerel bir SQLite veritabanında tutar. Eğer bir komut, o kullanıcı için daha önce görülmüşse, LLM yüksek güvenle işaretlemedikçe zararsız kabul edilir.
Bu hibrit yaklaşım—LLM yenilik tespiti için, bazeline ise davranışsal geçmiş için—testlerimde false positive'ları %80'e yakın oranda azalttı.
Important limitations and warnings
Bu, doğru sudoers yapılandırması, auditd veya SELinux'un yerini tutmaz. Bir ek katmandır. Ayrıca, LLM promptunu veya günlükleme soketini güvenilmeyen kullanıcılara asla açma. Ollama örneğini yerel olarak çalıştırıyorum, ağ üzerinden erişime kapalıyım.
Otomatik engelleme ile dikkatli ol: Kaynak IP'yi yanlış tanımlarsan (örneğin, proxy veya NAT nedeniyle), kendini kilitleyebilirsin. İlk olarak kritik olmayan bir kullanıcıyla test yap ve konsol veya dış-band erişimini her zaman açık tut.
Son düşünceler
LLM'leri log analizi için kullanmak, mühendisleri değiştirmekle ilgili değildir—kural tabanlı sistemlerin kaçırdığı düşük sıklıkta, yüksek etki olan olayların tespitini artırmaktır. Benim durumumda, bu, post-incident incelemesine kadar fark edilmeyecek şekilde kalabilecek sudo kötüye kullanım girişimlerini yakalamada yardımcı oldu.
Zaten logları merkezi hale getiriyorsanız ve LLM'lerle deneme yapıyorsanız, bu başlamak için pratik bir yol. Daha önceki yazımda [LLM-tabanlı sudo tespiti](https://furkanikkan.com/urun/llm-ile-syslog-tan-gecersiz-sudo-komutlarini-tespit-etme-ve-iptables-engelleme-122) hakkında bahsettiğim gibi, hedef mükemmellik değil—saldırganların maliyetini artırmaktır.
Güvenli kalın ve loglarınızı tuhaf tutun.
Kapak görseli: Unknown · CC0 (Openverse / kamu malı) · https://www.rawpixel.com/image/11176762/computer-chip