KertenKerem.NET

Modern bir altyapıda ağ güvenliği sağlarken katman 7 trafiğini denetlemek kaçınılmaz bir zorunluluk haline geldi. Bir WAF (Web Application Firewall) çözümünü prodüksiyon hattına alırken karşımıza çıkan ilk mimari çatallanma bellidir: Araya bir Reverse Proxy mi koyacağız, yoksa trafiği hissettirmeden süzen bir Transparent Bridge mi kuracağız? Çoğu DevOps güvenlik tartışmasında bu karar genelde “kurulumu en kolay olan hangisi?” sorusuna indirgenir; ancak 50 Gbps bant genişliğinde ya da microsecond seviyesinde SLA’leriniz varsa, bu yüzeysel tercih prod ortamında gecikme (latency) krizlerine ve kesintilere yol açar. Bu yazıda her iki yaklaşımı paket seviyesinden operasyonel maliyetine kadar masaya yatırıyoruz.

Paket Seviyesinde Ne Oluyor? L2/L3 Bridge vs L7 Proxy

İki yaklaşım arasındaki temel fark, Linux kernel’ının ve ağ yığınının (network stack) paketi karşılama biçiminde başlar. Konseptleri basitleştirmeden, soket katmanında ne yaşandığına bakalım.

Bir Reverse Proxy kullandığınızda, gelen TCP el sıkışmasını (handshake) bizzat WAF sonlandırır. İstemci ile WAF arasında bağımsız bir TCP soketi, WAF ile upstream servis (backend) arasında ise tamamen farklı bir TCP soketi açılır. Bu durum kernel seviyesinde iki ayrı soket buffer’ı, iki ayrı TCP state machine ve en önemlisi context switch maliyeti anlamına gelir.

Transparent Bridge (bump-in-the-wire) yaklaşımında ise cihaz, ağ topolojisi açısından görünmez bir L2 köprüsüdür. IP routing tablosuna müdahale etmez; gelen ethernet frame’lerini promiscuous mode’da okur, inceler ve hedef MAC adresine iletir. İstemci ile backend doğrudan tek bir TCP oturumu yürütür. WAF, bu trafiğin ortasında durup paketleri L7 seviyesine serialize/deserialize ederek anlık olarak denetler.

# Linux üzerinde basit bir L2 bridge arabirimi oluşturma
ip link add name br0 type bridge
ip link set dev eth1 master br0
ip link set dev eth2 master br0
ip link set dev eth1 up
ip link set dev eth2 up
ip link set dev br0 up

# Bridge üzerinden geçen trafiği netfilter denetimine yönlendirme (bridge-nf-call-iptables)
sysctl -w net.bridge.bridge-nf-call-iptables=1
sysctl -w net.bridge.bridge-nf-call-ip6tables=1

Bu konfigürasyonda paketler işletim sisteminin routing katmanına uğramadan eth1’den eth2’ye akar. WAF motoru bu akışı ya bir eBPF/XDP programı üzerinden ya da NFQUEUE yardımıyla user-space’e çekerek inceler.

Reverse Proxy WAF: Kontrol, Esneklik ve TLS Sonlandırma

DevOps ekosisteminde Envoy, Nginx veya Traefik tabanlı bir Reverse Proxy WAF (örneğin Coraza ya da ModSecurity modülleriyle entegre) görme olasılığınız %90’ın üzerindedir. Bunun geçerli nedenleri var.

Avantajları:

• Tam TLS Hakimiyeti: WAF, TLS terminasyonunu yaptığı için HTTP/2 veya HTTP/3 frame’lerini kolayca çözer. Plaintext HTTP payload’u üzerinde regex, libinjection veya AST tabanlı analizleri doğrudan uygular.
• L7 Manipülasyon Yeteneği: Header manipülasyonu, cookie injection, URL rewriting, request/response buffering ve rate limiting tek bir konfigürasyon dosyasında toplanır.
• Arka Uç İzolasyonu: Upstream servislerinizin gerçek IP adresleri internete kapanır; zero-trust mimarisine geçiş kolaylaşır.

Aşağıda Nginx üzerinde Coraza WAF ile çalışan tipik bir reverse proxy bloğu görüyorsunuz:

# nginx.conf içerisindeki örnek konfigürasyon
http {
    coraza_waf on;
    coraza_rules_file /etc/coraza/coraza.conf;
    coraza_rules_file /etc/coraza/coreruleset/crs-setup.conf;
    coraza_rules_file /etc/coraza/rules/*.conf;

    upstream backend_nodes {
        server 10.0.10.15:8080 max_fails=3 fail_timeout=10s;
        keepalive 64;
    }

    server {
        listen 443 ssl http2;
        server_name api.sirket.com;

        ssl_certificate /etc/ssl/certs/bundle.crt;
        ssl_certificate_key /etc/ssl/private/privkey.pem;

        location / {
            # Upstream soketine proxy pass
            proxy_pass http://backend_nodes;
            proxy_set_header X-Forwarded-For $remote_addr;
            proxy_set_header Host $host;
            proxy_http_version 1.1;
            proxy_set_header Connection "";
        }
    }
}

Dezavantajları:

Proxy yaklaşımının en büyük handikapı gecikme (latency penalty) ve kaynak tüketimidir. Her HTTP isteği hafızada tamponlanır (buffered), kural motoru tarafından parse edilir ve ancak temiz olduğu doğrulanırsa upstream’e yeni bir HTTP payload’u olarak yazılır. Yüksek trafikli I/O işlemlerinde CPU tüketiminin ana sebebi şifreleme ve parsing operasyonlarıdır.

Transparent Bridge WAF: Sıfır Ağ İzi ve Düşük Gecikme

Fintech, yüksek frekanslı işlem (HFT) platformları veya legacy ağ yapısını bozamayacağınız senaryolarda devreye Transparent Bridge girer. Buradaki temel motivasyon şudur: “Mevcut ağ mimarisini, DNS kayıtlarını ve routing tablolarını değiştirmeden araya gir.”

Avantajları:

• Topoloji Bağımsızlığı: DNS yönlendirmesi (CNAME değişikliği), BGP route enjeksiyonu veya backend servislerde X-Forwarded-For header ayrıştırması gerektirmez. Uygulama, istemcinin gerçek IP’sini doğrudan paket başlığında görür.
• Görünmezlik (Stealth Mode): Köprü cihazının dışarıya açık bir yönetim IP’si olmak zorunda değildir; saldırgan ağ haritalama (traceroute/nmap) sırasında bu filtreleme noktasını göremez.
• Fail-Open Güvencesi: Özel ağ kartları (Hardware Bypass NICs) kullanılarak elektrik kesintisinde veya kernel panik anında röleler fiziksel olarak kapanır ve iki port doğrudan birbirine bağlanır (straight-through cable gibi). Trafik kesintiye uğramaz, yalnızca denetim bypass edilir.

TLS Sorunsalı: “Bump-in-the-wire” Nasıl Şifre Çözer?

İşte Transparent Bridge’in en zorlu ve can sıkan noktası. Eğer trafik HTTPS ise —ki artık HTTP neredeyse kalmadı— bridge cihazı akan şifreli veriyi nasıl inceleyecek? Burada iki yol vardır:

1. Inline SSL Offloading / Private Key Injection: Backend sunucunun private key’i bridge cihazına yüklenir. Eğer TLS 1.2 ve RSA anahtar değişimi kullanılıyorsa trafik pasif dinlenebilirdi; ancak TLS 1.3 ve Diffie-Hellman (PFS) dünyasında bu artık mümkün değil. Cihazın oturum anahtarlarını dinamik olarak yakalaması veya inline man-in-the-middle (MitM) yapması gerekir. Bu da istemcinin köprü cihazının CA sertifikasına güvenmesini zorunlu kılar.
2. kTLS ve eBPF Ayrıştırması: Bazı modern cihazlar kernel seviyesinde kTLS (Kernel TLS) mekanizmasını kullanarak şifre çözme yükünü CPU çekirdekleri arasında dağıtır, ancak bu senaryoda bile köprü bir nevi şeffaf proxy davranışı sergilemek zorunda kalır.

# NFQUEUE üzerinden paketi kullanıcı alanındaki inline bir IDS/WAF motoruna iletme
iptables -A FORWARD -p tcp --dport 80 -j NFQUEUE --queue-num 0

# eBPF ile köprü üzerinde katman 7 trafiğini denetlemek için TC (Traffic Control) kullanımı
tc qdisc add dev br0 clsact
tc filter add dev br0 ingress bpf da obj waf_filter.o sec l7_inspect

Mimari Karşılaştırma: Hangi Metrikte Kim Kazanıyor?

Kritik mühendislik parametrelerini yan yana koyarak sistemi tartalım:

Failover ve High Availability Senaryoları

Bir siber güvenlik aracı prodüksiyonu aşağı indirdiği an, güvenliğin hiçbir anlamı kalmaz. İki modelin çökme senaryoları tamamen farklı işletilir.

Reverse Proxy çöküşlerinde yük dengeleyici (Load Balancer) katmanında aktif health check mekanizmalarına güveniriz. Eğer proxy instance’ı çökerse, upstream LB trafiği diğer node’lara aktarmak zorundadır. Ancak bu süreçte mevcut TCP bağlantıları resetlenir ve P99 sürelerinde ani zıplamalar görülür.

# Keepalived ile Reverse Proxy için VRRP tabanlı VIP yönetimi örneği
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass SecOps123
    }
    virtual_ipaddress {
        192.168.1.100/24
    }
    track_script {
        chk_waf_service
    }
}

Transparent Bridge mimarisinde ise failover mantığı yazılımdan ziyade donanım seviyesindedir. Sunucu üzerinde çalışan Watchdog servisi kernel’ı periyodik olarak yoklar. Eğer WAF motoru heartbeat göndermeyi keserse, ağ kartı röleleri devreye girer. Bu durum ağda paket kaybı olmadan (maksimum 1-2 ms’lik link negotiation seviyesinde) trafiğin filtrelenmeden akmasını sağlar. Güvenlikten geçici olarak feragat edilir ama operasyonel kesinti engellenir.

Hangi Senaryoda Hangisini Tercih Etmelisiniz?

Pragmatik bir mimar olarak şu kuralları kılavuz edinebilirsiniz:

Reverse Proxy Tercih Edin, Eğer:

• Kubernetes cluster’ları yönetiyor, Ingress controller veya Service Mesh (Istio, Linkerd) üzerinde L7 trafiği yönlendiriyorsanız.
• Edge katmanında CDN entegrasyonu yapıyor, API Gateway işlevleri (rate limiting, authentication, path-based routing) bekliyorsanız.
• TLS terminasyonunu merkezi bir noktada toplamak ve upstream’e mTLS ile gitmek istiyorsanız.

Transparent Bridge Tercih Edin, Eğer:

• IP topolojisini değiştirmenin aylar süren regülasyon ve onay süreçlerine tabi olduğu geleneksel bir veri merkezinde çalışıyorsanız.
• İstemci IP adreslerinin L7 katmanında (header enjeksiyonu olmaksızın) saf L3 seviyesinde korunması gereken SCADA, legacy ERP veya özel bankacılık protokolleriniz varsa.
• SLA kurallarınız, ek bir TCP el sıkışmasının getireceği mikrosaniyelik ek yükleri dahi tolere edemiyorsa.

Özetle; bulut-yerel mimarilerde esneklik ve TLS yönetim kolaylığı nedeniyle Reverse Proxy WAF tartışmasız standarttır. Fakat düşük gecikme, fail-open zorunluluğu ve sıfır ağ topolojisi değişikliği gerektiren kritik kurumsal altyapılarda Transparent Bridge, yerini hiçbir şeyin dolduramadığı bir cankurtaran olmaya devam ediyor.