Nasıl çalışır

Argus tek bir kalıbı yakalar: iddia edilen durum ile gerçek durumun ayrışması. Kod "yetkili" varsayar, endpoint herkese açıktır; metrik "trafik" der, fatura "saldırı" der. Bunu görmek için trafiğin önünde durmaz, uygulamanın içinden bakar.

Hat

Müşteri backend'i (Node)
  └─ @argus/node middleware ── metadata ──► Argus backend
       her isteği görür                      ├─ kural motoru
       gövdeyi okumaz                        ├─ olay motoru
       fail-open                             └─ bildirim (Telegram / Discord)
                                                   │
                                             PostgreSQL ── panel

SDK isteğin sonunda bir olay üretir, belleğe alır ve toplu gönderir. Backend olayları tenant'a göre ayırıp saklar; kural motoru periyodik olarak bakar; panel canlı akışı ve olayları gösterir.

Yalnızca metadata

Bir olay şunlardan ibarettir: method, şablonlanmış route, statusCode, durationMs, requestBytes, responseBytes, ip, userAgent, timestamp ve kural eşleştiyse protection. İstek ya da yanıt gövdesi, header değerleri, query parametre değerleri ve gerçek path kimlikleri hiçbir zaman toplanmaz. Byte sayıları content-length başlığından okunur; içerik değil, boyut. IP süreçten çıkar ama ham saklanmaz: backend tenant'a özel bir tuz ve veritabanı dışında tutulan bir anahtarla HMAC-SHA256 ile özetler.

Fail-open teslimat

Transport katmanı hata yutmak için yazıldı. Bir flush asla throw etmez, yeniden deneme fırtınası başlatmaz, uygulamaya geri basınç uygulamaz.

• Gönderim 50 olay birikince ya da her 5 saniyede bir, hangisi önce gelirse.
• Bellekte en çok 10.000 olay tutulur; backend ulaşılamazsa en eskiler düşer, bellek büyümez.
• Başarısız gönderim atılır, tekrar denenmez.
• Flush ve politika zamanlayıcıları unref edilmiştir: telemetri için bir süreç asla açık tutulmaz.
• Süreç kapanırken (beforeExit) son bir gönderim denenir.

Argus backend'i tamamen çökse bile müşterinin trafiği kesintisiz akar. Bu söz testle bağlıdır; uçtan uca test backend'i SIGKILL ile öldürüp isteklerin akmaya devam ettiğini ölçer.

Kural motoru ve olaylar

Motor varsayılan olarak 60 saniyede bir çalışır ve [son tur, şimdi) aralığına bakar; pencereler çakışmaz, aynı istek iki kez sayılmaz. Bir eşik aşıldığında olay açılır. Olayın yaşam döngüsü üç adımdır:

1. Aç. İlk tespitte olay oluşur, bildirim gider.
2. Güncelle. Aynı saldırı sürerken yeni olay açılmaz; mevcut olayın sayaçları ve şiddeti güncellenir. Şiddet yalnızca yukarı gider; açık olay varken eşik yarıya iner ki saldırı eşiğin altına inip çıktıkça olay kapanıp yeniden açılmasın.
3. Kendiliğinden kapan. Sinyal kesildikten 15 dakika sonra olay kapanır.

Bir DDoS'ta 40.000 bildirim değil, bir olay görürsünüz. Olayın türü açıkça yazar: deterministic (kanıtlı bulgu), probabilistic (şüpheli desen, kanıt değil; bugünkü kural setinde yok) ya da intelligence (tarama tespiti). Hacim temelli kurallar taban çizgisi olgunlaşmadan, yani ilk 7 gün, tetiklenmez.

Bildirim

Telegram birincil kanaldır, Discord webhook'u ikincil. E-posta bilinçli olarak yok: gecikir, spam'e düşer, birincil alarm kanalı olamaz. Bildirim yalnızca olay açılırken ve şiddet yükselirken gider.

🔴 api.musteri.com — kimlik doğrulama brute force
04:12'den beri, 8 dk, 12.400 istek
Hedef: POST /api/auth/login
POST /api/auth/login üzerinde 8 dakikada 12400 başarısız kimlik denemesi — başarılı giriş yok.
Olay: 3fa85f64-…

Koruma: gözlemden uygulamaya

Hiçbir kural doğrudan aktif edilmez. Akış üç aşamadır:

Gözlem  →  Gölge mod (kural var, blok yok)  →  Uygulama (süreli)

Kural panelde yazılır ve gölgede doğar: sayar, işaretler, dokunmaz. Backend geçmiş trafiği SDK ile aynı algoritmayla yeniden oynatıp tek cümle üretir: "Bu kural son 7 günde aktif olsaydı 12.480 POST /api/auth/login isteğinin 31 tanesini bloklardı. Hepsi tek kaynaktan, 12 Eyl 04:12–04:19 arası, POST /api/auth/login." Rapor görülmeden kural uygulamaya alınamaz; backend 409 döner.

Uygulama sürelidir: 10 saniye ile 24 saat arası, varsayılan 30 dakika. Süre dolunca kural kendiliğinden gölgeye döner ve bildirim gider. "Geri al" her an elinizdedir.

SDK politikayı varsayılan olarak 30 saniyede bir çeker; uygulama ve geri alma en geç o sürede etkili olur. Ağ hatası ya da 5xx'te SDK elindeki kuralları korur; yalnızca 401/403 (anahtar iptal edilmiş) tüm kuralları düşürür. Süre dolumunu SDK kendi saatiyle uygular: backend ölürse uygulama azalabilir, asla uzayamaz.

Deploy zamanı

Çalışan sistemden bağımsız ikinci bir göz @argus/ci'dır: build çıktısında sızmış anahtar, herkese açık önekli ortam değişkeninde gizli anahtar ve lockfile'da değişen içerik arar. CI'da koşar, deterministiktir, blok bulguda deploy'u kırar.