LLM'yi tekrar eden güvenlik gürültüsünü yorumlamak için deniyorum. /var/log/iptables.log dosyasını elle greplemek yerine, günlük girdilerini modele verip eyleme dönüştürülebilir iptables önerileri almak istiyorum—özellikle tarayıcılar veya botnetler gibi geçici tehditler için LOG ve DROP kuralı. Bu, manuel incelemeyi değiştirmek değil, triage aşamasını hızlandırmak için.
Günlüklerden kural önerisi otomatikleştirmek neden önemli
Ortamımda iptables günlükleri genellikle aynı kaynak IP'den kullanımsız portlara yönelen patlamaları gösterir—örneğin yüksek numaralı TCP/UDP hizmetlerine port taraması veya standart olmayan SSH portlarına tekrar eden denemeler. Bunları elle ilişkilendirmek zaman alır, özellikle saatler dışında. Günlük girdilerinin niyetini özetleyen bir LLM kullanarak, geçici blokun gerekli olup olmadığını hızlıca karar verebilirim.
Önemli olan promptu doğru şekilde şekillendirmek. Modelden üretim hazır güvenlik politikası üretmesini istemiyorum; desenleri gözlemlemesi ve özenli, zaman sınırlı bir tepki önermesini istiyorum. Bunu junior bir analistin log parçalarını senin için özetleyip değerlendirmen için sunduğu gibi düşünebilirsin.
Kullandığım prompt şablonu
Burada, iptables LOG çıktısının son 50 satırını çıkardıktan sonra yerel bir LLM (Mistral veya Llama 3 gibi) üzerinden ollama ile beslediğim tam prompt:
Analyze the following iptables LOG entries. Each line shows a packet that matched a LOG rule (usually placed before DROP in INPUT chain).
Identify:
- Repeating source IPs
- Common destination ports or protocols
- Likely intent (scan, brute force, misconfiguration)
Then suggest:
1. A temporary iptables DROP rule for the most offending source (if any)
2. An optional LOG-only rule if the behavior is suspicious but not clearly malicious
Use this format for each suggestion:
iptables -I INPUT -s <IP> -p <proto> --dport <port> -j DROP
# or
iptables -I INPUT -s <IP> -p <proto> --dport <port> -j LOG --log-prefix "FIREWALL: "
Only suggest rules if a clear pattern exists. If unsure, say "No clear pattern detected."
---
<PASTE_LOG_HERE>Tonumu nötr ve öğretici tutuyorum. Modelin iptables dahiliyı bilmesine gerek yok; sadece tekrarlamaları görüp port/protokol kombinasyonlarından niyti çıkarması yeterli.
Günlüklerimden gerçek örnek
Geçen hafta şu parçayı prompta yapıştırdım:
Jan 10 03:14:22 firewall kernel: IN=eth0 OUT= MAC=... SRC=185.130.105.117 DST=10.0.0.5 PROTO=TCP SPT=45332 DPT=23
Jan 10 03:14:25 firewall kernel: IN=eth0 OUT= MAC=... SRC=185.130.105.117 DST=10.0.0.5 PROTO=TCP SPT=45335 DPT=23
Jan 10 03:14:28 firewall kernel: IN=eth0 OUT= MAC=... SRC=185.130.105.117 DST=10.0.0.5 PROTO=TCP SPT=45338 DPT=23
Jan 10 03:14:31 firewall kernel: IN=eth0 OUT= MAC=... SRC=185.130.105.117 DST=10.0.0.5 PROTO=TCP SPT=45341 DPT=23Model şu yanıtı verdi:
Repeated TCP SYN packets to port 23 (Telnet) from 185.130.105.117. Likely scan for legacy services.
Suggested rule:
iptables -I INPUT -s 185.130.105.117 -p tcp --dport 23 -j DROPBu öneriyi inceledim, -m comment --comment "Scanner via LLM suggestion 2024-01-10" ile bir açıklama ekledim ve 4 saat sonra otomatik olarak kaldırılacak bir cron işi kurdum. Bu örnekte yanlış pozitif olmadı.
Güvenlik kontrolleri ve otomasyon
LLM tarafından önerilen kuralı doğrudan asla uygulamıyorum. Her zaman:
- Mantığını gözden geçiririm
- İzlenebilir bir yorum eklerim
- Önce üretim dışı bir zincirde test ederim (veya
-Ckullanarak kontrol ederim) - Elle uzatılmadıkça otomatik kaldırma zamanlar
Bu süreci şu şekilde bir betikle sarmalayabilirdin:
- iptables günlüğünün sonunu alır
- Son N satırı çıkarır
- Bunları API veya yerel çıkarım üzerinden LLM'e verir
- Çıktıdan
iptables -Isatırlarını ayrıştırır - Manuel inceleme için bir dosyaya çıktı verir
Ama hatta yarı-otomatik—sadece günlükleri bir sohbet arayüzüne kopyalayarak—olay başına 5-10 dakika tasarrufu sağlıyor.
Sınırlamalar ve ne zaman kullanılmamalı
Bu yöntem gürültülü, tekrarlayan taramalar için en iyi sonucu verir. Şu durumlarda etkili değildir:
- Düşük ve yavaş saldırılar
- Asimetrik yönlendirme nedeniyle yanlış tanımlanan meşru trafik
- Uygulama katmanı tehditleri (bunlar WAF veya ModSecurity günlükleri gerektirir)
Ayrıca, iptables söylentisi üreten LLMs ile dikkatli olmak gerekir. Her zaman oluşturulan kuralı iptables -t filter -C INPUT ... komutuyla doğrulamalı, eklemeden önce.
Daha önce [AI destekli log anomali tespiti](https://furkanikkan.com/urun/ai-ile-log-anomali-tespiti-gpt-4o-mini-syslog-hatalarini-bulma-87) konulu yazımda da belirttiğim gibi, hedef karar mekanizmasını değiştirmek değil, sinyal hacim altında kaybettiğinde bilişsel yükü azaltmaktır.
Son düşünceler
Zaten iptables DROP günlüğü tutuyorsan (ve tutman gerekiyor), bu prompt pasif günlükleri aktif triage malzemesine dönüştürür. Büyü bir şey değil, ama küçük ekipler veya tek başına yöneticiler çevre savunmalarını yönetirken bir kuvvet çarpanı olarak iş görür. Bir sonraki tarayıcı olayıyla deneyebilir—sadece kuralı sonradan temizlemeyi unutma.
Kapak görseli: ₡ґǘșϯγ Ɗᶏ Ⱪᶅṏⱳդ · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/148598741@N02/51973552248