Bir penetrasyon testinde firewall’u bypass etmeye çalıştığınızda, aslında o firewall’un paketleri nasıl incelediğini öğrenmek için zaman harcarsınız. Çünkü her firewall mimarisinin kör noktaları farklıdır ve bu kör noktalar, paket inceleme yönteminin doğal bir sonucudur. Bu yazı, firewall’ların paketleri “nasıl” incelediğini düşük seviyeden anlatma çabasıdır. Connection tracking nasıl çalışır, stateful inspection algoritması adım adım nedir, Deep Packet Inspection (DPI) motoru bir TLS handshake’i nasıl analiz eder; bunların hepsini hem teorik hem de MikroTik üzerinde göreceğimiz somut örneklerle ele alacağız. Eğer firewall politikalarınızı bilinçli yazmak ve neden bazen bekledikleriniz olmadığını anlamak istiyorsanız, bu yazı sizin için.

Paket Akışı: Bir Firewall’un Hayat Döngüsü

Bir paket, ağ arayüzünden geldiği andan çıkana kadar firewall içinde bir dizi karar noktasından geçer. RouterOS’da bu akışı bilen herkes, neden bazı kuralların beklediği gibi çalışmadığını da anlar. Tipik bir Linux netfilter (ki MikroTik’in temeli budur) akışı şöyledir:

1. Prerouting: Paket fiziksel arayüze geldiğinde ilk uğradığı nokta. Burada DNAT, mangle (mark connection) kararları verilir.
2. Routing Decision 1: Paket bu cihaza mı yoksa başka bir hedefe mi gidiyor sorusu cevaplanır.
3. Input chain: Eğer paket bu cihaza yönelikse (örneğin Winbox yönetim trafiği), input chain’inden geçer.
4. Forward chain: Eğer paket bu cihazdan başka bir cihaza yönlendirilecekse, forward chain’inden geçer.
5. Output chain: Cihazın kendisi tarafından üretilen paketler (örneğin SNMP cevabı) output chain’inden geçer.
6. Routing Decision 2 + Postrouting: Çıkış arayüzü belirlenir ve SNAT kararı verilir.

Bu akışın her aşamasında firewall, mevcut connection table’ına bakarak paketin durumunu belirler. Yani aslında firewall, gelen her paket için “bu paket yeni bir bağlantı mı, var olan bir bağlantının parçası mı, geçersiz bir paket mi?” sorusunu cevaplandırmak zorundadır. Bunu yapmak için ise connection tracking denilen sofistike bir mekanizma kullanır.

Connection Tracking: Bağlantının Dijital Kimliği

Connection tracking, modern stateful firewall’ların kalbidir. Her TCP, UDP veya ICMP bağlantısı, firewall’un hafızasında bir kayıt olarak tutulur. Bu kayıt tipik olarak şu bilgileri içerir:

• Kaynak IP ve port (orijinal)
• Hedef IP ve port (orijinal)
• Kaynak IP ve port (NAT sonrası, reply yönü)
• Hedef IP ve port (NAT sonrası, reply yönü)
• Protokol (TCP, UDP, ICMP, vb.)
• Bağlantının state’i (NEW, ESTABLISHED, RELATED, INVALID)
• TCP-specific state (SYN_SENT, ESTABLISHED, FIN_WAIT, vb.)
• Timeout değeri
• Geçen byte ve paket sayısı (istatistik)
• Mark değerleri (connection mark, packet mark)

MikroTik’te bu tabloyu canlı izlemek için /ip firewall connection print komutu kullanılır. Üretim ortamlarındaki bir kurumsal MikroTik’te bu tablonun yüzbinlerce satır içerebileceğini unutmayın. Her satır bir aktif bağlantıdır ve firewall, gelen her paketi bu tabloyla karşılaştırarak hızla karar verir.

5-Tuple ve Hash Tabloları

Connection tracking algoritmasının kalbi 5-tuple kavramıdır: kaynak IP, hedef IP, kaynak port, hedef port, protokol. Bu beşlinin tek bir kombinasyonu, bağlantının benzersiz kimliğidir. Firewall, gelen her paketin 5-tuple’ını hesaplar, bir hash fonksiyonundan geçirir ve hash tablosunda hızla arama yapar. Hash tabloları, milyonlarca bağlantı arasında milisaniyenin altında lookup imkanı sağlar.

Linux kernel’inde bu tablo “conntrack” modülü tarafından yönetilir ve MikroTik RouterOS, bu altyapıyı geliştirilmiş bir biçimde kullanır. nf_conntrack_max parametresi, tabloda tutulabilecek maksimum kayıt sayısını belirler. MikroTik’te bu değer, cihaz RAM’ine göre dinamik olarak hesaplanır; RB4011 gibi modellerde 100.000-200.000 civarındadır.

Stateful Inspection Algoritması: Adım Adım

Bir TCP paketinin stateful firewall’a geldiği anda neler olduğunu adım adım inceleyelim. Diyelim ki bir kullanıcı LAN’dan dışarıya HTTPS isteği gönderiyor:

1. SYN paketi gelir. Firewall 5-tuple’ı hesaplar (örneğin 192.168.1.10:54321 -> 142.250.187.46:443 TCP). Conntrack tablosunda bu tuple yoktur.
2. NEW state’i atanır. Conntrack, bu paketin yeni bir bağlantı başlatma denemesi olduğunu kaydeder. State: NEW, TCP state: SYN_SENT.
3. Filter chain’leri çalıştırılır. Forward chain’deki kurallar sırayla değerlendirilir. Eğer kural “connection-state=new ve protocol=tcp ve dst-port=443 ise accept” diyorsa, paket geçer.
4. Conntrack’a kayıt eklenir. Bağlantı tablosuna SYN_SENT durumunda bir satır eklenir.
5. SYN-ACK döner. Hedef sunucudan gelen SYN-ACK paketi firewall’a ulaştığında, 5-tuple ters yönden eşleşir. Conntrack bu paketi ESTABLISHED state’ine geçirir.
6. Sonraki paketler hızlı işlenir. Bağlantı kurulduktan sonra gelen veri paketleri için tek bir kural yeter: “connection-state=established,related ise accept”. Çünkü conntrack zaten her paketin valid olduğunu doğrular.

Bu modelin gücü, performansın yüksek tutulmasıdır. NEW state’deki paketler için detaylı kural değerlendirmesi yapılır; ESTABLISHED paketler için sadece bir state check yeter. Bu sayede 10 Gbps trafikte bile bir MikroTik CCR cihazı line-rate’e yakın performans sunabilir.

State Diyagramı: TCP State Geçişleri

Stateful firewall, TCP state machine’ini de takip eder. Bir TCP bağlantısının yaşam döngüsündeki state’ler şunlardır:

CLOSED -> SYN_SENT -> SYN_RECV -> ESTABLISHED
                                      |
                                      v
                            FIN_WAIT_1 -> FIN_WAIT_2 -> TIME_WAIT -> CLOSED
                                      |
                                      v
                                  CLOSE_WAIT -> LAST_ACK -> CLOSED

Her state için farklı bir timeout değeri vardır. ESTABLISHED state genellikle 5 gün (432000 saniye); TIME_WAIT 2 dakika; SYN_SENT 60 saniye olarak konfigüre edilir. Eğer bir saldırgan eksik el sıkışmalar üreterek SYN_SENT state’inde binlerce kayıt yaratıyorsa, conntrack tablosu hızla dolar; bu klasik bir DoS senaryosudur.

UDP ve ICMP için Pseudo-State

UDP, doğası gereği stateless bir protokoldür; bağlantı kavramı yoktur. Ancak conntrack, UDP için “pseudo-state” uygulayarak şöyle bir mantık geliştirir: İlk paket çıktığında, beklenen reply paketi için bir kayıt açılır. Reply paketi geldiğinde state ESTABLISHED olarak güncellenir. Sonraki paketler ESTABLISHED kabul edilir.

ICMP için durum daha basittir: Echo Request gönderildiğinde, beklenen Echo Reply için bir kayıt açılır. Reply gelirse state ESTABLISHED olur ve bağlantı RELATED ICMP error mesajlarına izin verir (örneğin Destination Unreachable).

RELATED State: Yardımcı Bağlantılar

Conntrack’in en güzel özelliklerinden biri “RELATED” state’idir. Bazı protokoller (FTP, SIP, H.323, IRC DCC, PPTP) birden fazla bağlantı kullanır. Örneğin klasik FTP’de istemci 21 portuna kontrol bağlantısı açar; sonra veri transferi için ayrı bir TCP bağlantısı kurulur. Bu ikinci bağlantı, klasik firewall mantığıyla NEW görünür ve engellenmesi gerekir; ancak conntrack’ın FTP helper’ı kontrol bağlantısındaki PORT komutunu okur, beklenen veri bağlantısını “RELATED” olarak işaretler ve geçişine izin verir.

MikroTik’te bu yardımcılar /ip firewall service-port altında listelenir. Varsayılan olarak FTP, TFTP, IRC, PPTP, H.323 ve SIP için yardımcılar etkindir. Eğer bu protokolleri kullanmıyorsanız, yardımcıları kapamak hem performans hem de saldırı yüzeyi açısından önerilir.

Deep Packet Inspection (DPI): Payload’a Bakmak

Bu noktaya kadar konuştuğumuz her şey, paketin başlık bilgileriyle ilgiliydi. Ancak modern saldırılar büyük çoğunlukla payload’ın içinde gizlenir. Örneğin bir HTTP isteğinin URL parametresinde gizli SQL injection, bir DNS sorgusunun içine gömülmüş malware komuta-kontrol verisi, veya bir TLS bağlantısının SNI alanına yazılmış komut. Bunları görmek için Deep Packet Inspection (DPI) motoruna ihtiyacımız var.

DPI motoru, paketin payload kısmını okur ve şu yöntemlerle inceler:

• Pattern matching: Önceden tanımlanmış imzaları (regex veya byte sequence) trafikte arar.
• Protocol decoding: Trafiği protokol kuralları dahilinde parse eder. Örneğin HTTP request line, header’lar, body olarak ayrıştırılır.
• Heuristic analysis: Paket boyutu, paket aralığı, payload entropisi gibi istatistiksel özellikleri inceler. Örneğin yüksek entropi şifreli veya sıkıştırılmış trafiği işaret eder.
• Behavioral analysis: Trafik akışının uzun vadeli davranışını izler. Örneğin bir endpoint’in normal port 443 trafiği yerine her saniye yeni bir IP’ye SYN paketi gönderiyorsa, bu beaconing davranışı olarak işaretlenir.

DPI Motorlarının Pratikteki Sınırları

DPI’nın iki büyük düşmanı vardır: şifreleme ve performans. Trafik şifreli olduğunda (TLS, IPsec, WireGuard), payload görünmez. Bu nedenle modern NGFW’ler SSL inspection (man-in-the-middle olarak trafiği decrypt etme) yapar. Ancak SSL inspection, ciddi CPU yükü yaratır; ayrıca certificate pinning kullanan uygulamalar (mobil bankacılık, WhatsApp) inspection’da çalışmaz.

Performans açısından DPI motorunun yapacağı analiz miktarı, throughput’u doğrudan etkiler. Her paket için 50 farklı imza kontrol etmek, 5 imza kontrol etmekten 10 kat yavaştır. Bu nedenle ticari DPI çözümleri, ASIC veya FPGA tabanlı hardware acceleration kullanır.

Layer-7 Protocol Detection: MikroTik Örneği

MikroTik, sınırlı da olsa Layer-7 protocol detection sağlar. /ip firewall layer7-protocol altında regex tabanlı pattern’lar tanımlanır ve filter kurallarında bu pattern’lar kullanılır. Örneğin BitTorrent trafiğini engellemek için tipik bir pattern:

/ip firewall layer7-protocol
add name=bittorrent regexp="^(x13bittorrent protocol|azverx01$|get /scrape?info_hash=get /announce?info_hash=|get /client/bitcomet/|GET /data?fid=)|d1:ad2:id20:|x08'7P)[RP]"

/ip firewall filter
add chain=forward layer7-protocol=bittorrent action=drop

Ancak burada kritik bir uyarı: Layer-7 protocol matching, her paket için regex çalıştırır ve CPU yükünü ciddi şekilde artırır. Yüksek trafikli ortamlarda layer-7 kuralları, ya çok seçici kullanılmalı (sadece NEW connection’larda) ya da harici DPI çözümlerine devredilmelidir.

Connection Tracking’in Performans Trade-Off’ları

Conntrack güçlüdür, ama bedava değildir. Her aktif bağlantı için RAM’de 300-500 byte yer tutar. 100.000 bağlantı 30-50 MB RAM demektir. Üstelik her paket için tablo lookup’ı yapılır; bu CPU döngüleri tüketir. Bu nedenle bazı senaryolarda conntrack’ı bypass etmek gerekebilir:

• Çok yüksek paket per saniye (PPS) gereken backbone trafiğinde
• DDoS koruması için fast-path kuralları yazılırken
• UDP video streaming gibi connectionless servislerde

MikroTik’te conntrack bypass için /ip firewall raw chain’i kullanılır. Raw chain, conntrack’tan ÖNCE çalışır ve paketleri notrack action’ı ile işaretleyerek conntrack’a girmelerini engeller. Bu özellikle volumetric saldırı altında performans kurtarıcısıdır.

Gerçek Bir Olaydan: SYN Flood ile Conntrack Doldurma

Bir hosting müşterimde yaşadığımız olaydı. Sabah saat 03:00 civarında MikroTik CCR cihazı sürekli “no buffers” hatası vermeye başladı. Conntrack tablosunda /ip firewall connection print count-only komutuyla baktığımızda 250.000+ kayıt görüldü. Çoğu SYN_SENT state’inde, kaynak IP’ler dünyanın dört bir yanından, hedef tek bir IP. Klasik SYN flood.

Çözüm üç katmanlı oldu:

1. Raw chain’de erken drop: Bilinen kötü IP listelerinden gelen paketler conntrack’a hiç girmeden drop edildi.
2. TCP SYN cookies: /ip settings set tcp-syncookies=yes ile SYN cookie mekanizması aktif edildi. Bu sayede SYN paketleri conntrack tablosunda yer tutmadan validate edildi.
3. Connection limit kuralı: Kaynak IP başına eşzamanlı bağlantı sayısı sınırlandırıldı. add chain=forward connection-limit=20,32 protocol=tcp action=drop şeklinde bir kural yazıldı.

Üç katmanın birleşik etkisi, conntrack tablosunu 30 dakika içinde 250K’dan 8K’ya düşürdü. Sistem normalize oldu.

NAT Traversal ve Conntrack

NAT, conntrack ile derinden iç içedir. Bir LAN istemcisi dışarıya bağlantı kurduğunda, kaynak IP ve port public IP ve farklı bir port ile değiştirilir. Conntrack, hem orijinal hem de NAT’lanmış 5-tuple’ı kaydeder. Geri dönen paket public 5-tuple ile eşleşir; conntrack bu paketi ters yöne çevirip iç ağdaki istemciye iletir.

Bu mekanizmanın güzelliği şudur: NAT, conntrack olmadan çalışamaz. Çünkü dönen paketin hangi iç IP’ye gideceğini bilmek için orijinal bağlantının kaydı gerekir. MikroTik’te /ip firewall nat kuralları aslında sadece “yeni bağlantılar için NAT yap” der; geri kalan her şey conntrack tarafından otomatik halledilir.

Helper Modülleri ve ALG (Application Layer Gateway)

Bazı protokoller NAT ile başa çıkamaz. Örneğin SIP, kendi mesajlarının içinde iç IP adresini taşır; dışarıdaki taraf bu iç IP’yi göremez. Bunu çözmek için Application Layer Gateway (ALG) denilen helper modülleri kullanılır.

ALG, ilgili protokolün mesajını parse eder, iç IP’leri public IP ile değiştirir ve gerekirse beklenen yan bağlantılar için conntrack’ta RELATED kayıtları açar. MikroTik’te /ip firewall service-port bu helper’ları yönetir. Ancak modern dünyada ALG’ler sorunludur:

• SIP ALG, modern VoIP istemcilerinde (WebRTC, STUN/TURN) sorunlara yol açabilir
• FTP ALG, FTPS (FTP over TLS) trafiğinde işe yaramaz çünkü payload şifrelidir
• H.323 ALG, modern unified communications çözümleriyle (Microsoft Teams, Zoom) gereksizdir

Bu nedenle çağdaş ağ tasarımlarında, ALG’leri kapatıp uygulamaların kendi NAT traversal mekanizmalarını (STUN, TURN, ICE) kullanmasına izin vermek daha sağlıklıdır.

Mangle ve Connection Mark: Conntrack’ı Genişletmek

MikroTik’in conntrack özelliklerinden biri connection-mark ve packet-mark mekanizmasıdır. Mangle chain’inde, belirli kriterlere uyan ilk paket connection-mark ile etiketlenir. Sonraki tüm paketler conntrack tarafından otomatik olarak aynı mark’ı taşır.

Bu özellik PCQ (Per-Connection Queueing), VPN routing ve traffic shaping gibi karmaşık senaryolarda kritiktir. Örneğin bir IP’den gelen tüm trafiği belli bir VPN tüneline yönlendirmek için:

/ip firewall mangle
add chain=prerouting src-address=192.168.1.100 action=mark-connection new-connection-mark=vpn-out passthrough=yes
add chain=prerouting connection-mark=vpn-out action=mark-routing new-routing-mark=vpn-table

Bu örnekte ilk kural, kaynaktan gelen yeni bağlantıları “vpn-out” mark’ı ile işaretler; conntrack bu mark’ı tüm paketlere uygular. İkinci kural, bu connection-mark’ı route table’a yönlendirir. Yüzbinlerce kuralı tek tek yazmak yerine conntrack’ı kullanarak basit ve performanslı bir akış yaratırız.

Sıkça Sorulan Sorular

Stateful firewall, packet filter’dan çok mu daha yavaş?

Tam tersine, stateful firewall yeni paketler için yavaş ama ESTABLISHED paketler için packet filter’dan hızlıdır. Çünkü ESTABLISHED paketler tüm kural setine bakılmadan tek bir state check ile geçer. Yoğun trafikte stateful, packet filter’a göre daha verimlidir.

Conntrack tablosu dolarsa ne olur?

Tablo dolduğunda yeni bağlantılar reddedilir ve “nf_conntrack: table full, dropping packet” gibi loglar görülür. Çözüm: maksimum kayıt sayısını artırmak, timeout değerlerini kısaltmak, raw chain ile gereksiz trafiği erken drop etmek.

DPI ile Layer-7 protocol matching aynı şey midir?

Hayır. Layer-7 protocol matching, basit regex pattern eşleştirmesidir; DPI ise tam protokol parsing, heuristic analiz ve davranışsal incelemeyi kapsayan daha geniş bir disiplin. MikroTik’in built-in özelliği layer-7 protocol matching seviyesindedir; gerçek DPI için Suricata, Snort veya ticari NGFW gerekir.

Şifreli trafiği DPI nasıl inceler?

İki yoldan: ya SSL inspection (MITM proxy ile trafiği açıp tekrar şifreleme) ya da JA3/JA4 fingerprinting (TLS handshake imzalarını analiz ederek hangi istemcinin/malware’in bağlandığını tahmin etme). Modern NGFW’ler her ikisini de destekler.

Connection tracking IPv6’da çalışır mı?

Evet. MikroTik’te /ipv6 firewall connection komutu IPv6 conntrack tablosunu gösterir. Mekanizma IPv4 ile aynıdır; sadece adresleme farkı vardır.

Sonuç

Firewall’ların paket inceleme süreci, basit “kuralı eşleştir ve geçir” mantığından çok daha karmaşık bir orkestra. Connection tracking sayesinde her paket binlerce kuralı tekrar tekrar değerlendirmek zorunda kalmaz; stateful inspection sayesinde TCP state geçişleri firewall tarafından doğrulanır ve sahte trafik engellenir; DPI sayesinde uygulama katmanı tehditler görünür hale gelir. Bu üç katmanın birlikte çalışması, modern firewall’ları sadece bir paket filtresi değil, ağ trafiğinin akıllı bir gözlemcisi yapar. MikroTik gibi platformlarda bu mimariyi anlamak, sadece kural yazmaktan öteye geçip neden ve nasıl çalıştığını kavramak, gerçek firewall mühendisliğinin temelidir. Bir sonraki paket attığınızda, arkasında onlarca kararın milisaniyenin altında alındığını hatırlayın.

Devamı İçin Okumanızı Öneririz

Konuyu daha geniş ele almak için aşağıdaki yazılarımıza da göz atabilirsiniz:

• MikroTik Firewall Stratejisi: Zero Trust Mimarisinden Adaptive Defense'e — MikroTik firewall ile Zero Trust mimarisi, adaptive defense, threat intel feed ve SIEM ent
• MikroTik Firewall Mimarisinin Detayları: Chain, Action, Connection-State ve Best Practice — MikroTik firewall mimarisini derinlemesine inceleyen pratik rehber: chain mantigi, action
• MikroTik Hardening: Sertleştirme Kontrol Listesi ve Saldırı Yüzeyi Azaltma — MikroTik cihazlarini saldiri yuzeyi minimize edilmis kurumsal duzeyde guvenligi tasimak ic
• Firewall Nedir? Tarihçesinden Modern Uygulamalarına Kavramsal Rehber — Firewall’in 1988’deki ilk packet filter prototipinden 2026’nin SASE ve Zero Trust mimarile

Kaynaklar ve Daha Fazla Bilgi

Bu yazıdaki konuları derinleştirmek için aşağıdaki otoriter kaynaklara başvurabilirsiniz:

• NIST Cybersecurity Framework
• OWASP Foundation
• MITRE ATT&CK Matrix
• Wikipedia: Network Address Translation
• Wikipedia: OSI Model