Klasik network güvenlik anlayışı bir kale modelidir: dışarıda düşman, içeride güven. Bu model perimeter firewall ile uygulanır; “trusted” ve “untrusted” ağlar tanımlanır, aralarına bir router/firewall konur. Ancak 2010’lardan sonra bu model çökmeye başladı. Çalışanlar kafeden VPN ile bağlanmaya başladı, SaaS uygulamalar firewall’ın dışındaki “internete” taşındı, container’lar bir saniye yaşayıp yok olmaya başladı. Google’ın 2014’te yayınladığı BeyondCorp white paper’ı yeni bir paradigma ortaya koydu: Zero Trust. “Verify, then trust” yerine “never trust, always verify”. Bu yazıda Zero Trust prensiplerinin MikroTik üzerinde nasıl uygulanabileceğini ve bunun bir adım ötesi olan adaptive defense mimarisini inceleyeceğiz.

Bir DevOps mühendisi olarak yıllarca firewall yazdım. Klasik 100 satırlık MikroTik firewall script’lerinden, 2000+ satırlık otomatik üretilen RAW + filter chain’lerine kadar farklı ölçeklerde çalışma fırsatım oldu. Şunu söyleyebilirim: MikroTik RouterOS, Zero Trust mimarisini uygulamak için yeterince esnek bir araçtır; ancak doğru tasarım pattern’leri ve scripting disiplini olmadan firewall hem zayıf hem de yönetilemez hale gelir. Bu yazıda hem mimariyi hem de pratik script örneklerini paylaşıyorum.

Zero Trust’ın Beş Temel Prensibi

Zero Trust bir ürün değildir; bir prensipler kümesidir. Forrester’in ZTX modeli ve NIST SP 800-207 standardı şu beş ilkeyi öne çıkarır:

• 1. Implicit trust yok: Bir paketin “iç ağdan” gelmesi onu güvenilir yapmaz. Her bağlantı doğrulanır.
• 2. Least privilege access: Bir kaynağa erişen sadece o kaynağa erişebilir; lateral movement engellenir.
• 3. Microsegmentation: Ağ küçük bölümlere ayrılır; her bölüm arasında firewall kuralı vardır.
• 4. Continuous verification: Bir session’ın açılırken doğrulanması yetmez; süresince izlenir ve şüpheli durumda kapatılır.
• 5. Assume breach: Bir noktada kompromize olunduğu varsayılır; sistemler bu varsayım altında tasarlanır.

Bu beş ilkenin MikroTik üzerindeki karşılığı, tek başına firewall değil; RAW + filter + mangle + script + monitoring katmanlarının orkestrasyonudur.

Katman 0: RAW Chain ile Erken Drop

MikroTik’in /ip/firewall/raw tablosu, conntrack’ten önce işlenir. Bu, açıkça istenmeyen trafiği en ucuz şekilde düşürmek için ideal yerdir. CPU tasarrufu açısından kritiktir; çünkü kötü niyetli paketler conntrack tablosuna ulaşmadan elenir.

# Bogon kaynaklarından gelen tüm trafiği RAW'da düşür
/ip firewall address-list
add list=bogon-v4 address=0.0.0.0/8 comment="this-network"
add list=bogon-v4 address=10.0.0.0/8 comment="rfc1918"
add list=bogon-v4 address=100.64.0.0/10 comment="cgnat"
add list=bogon-v4 address=127.0.0.0/8 comment="loopback"
add list=bogon-v4 address=169.254.0.0/16 comment="link-local"
add list=bogon-v4 address=172.16.0.0/12 comment="rfc1918"
add list=bogon-v4 address=192.0.0.0/24 comment="ietf-protocol"
add list=bogon-v4 address=192.168.0.0/16 comment="rfc1918"
add list=bogon-v4 address=198.18.0.0/15 comment="benchmark"
add list=bogon-v4 address=224.0.0.0/4  comment="multicast"
add list=bogon-v4 address=240.0.0.0/4  comment="reserved"

/ip firewall raw
add chain=prerouting action=drop in-interface=ether1 src-address-list=bogon-v4 
    comment="drop bogon src on WAN"
add chain=prerouting action=drop in-interface=ether1 dst-address-list=bogon-v4 
    comment="drop bogon dst on WAN"

Bu kurallar; spoofed kaynak adreslerle yapılan reflection/amplification saldırılarına karşı erken savunma sağlar.

Katman 1: Default Deny Filter

Zero Trust’ın temel taşı: input ve forward chain’leri default drop politikasına ayarlamak. Klasik MikroTik default chain politikası “accept”tir; bu durumda tek bir unutulan kural her şeyi açabilir.

# Önce mevcut conntrack durumunu accept et
/ip firewall filter
add chain=input action=accept connection-state=established,related comment="conntrack ok"
add chain=input action=drop connection-state=invalid comment="invalid"
add chain=input action=accept protocol=icmp limit=10,5:packet comment="icmp rate"

# Yönetim trafiği: sadece bilinen prefix'lerden
/ip firewall address-list add list=mgmt-allow address=10.99.0.0/16 comment="corp vpn"
/ip firewall address-list add list=mgmt-allow address=203.0.113.10/32 comment="bastion"

add chain=input action=accept src-address-list=mgmt-allow protocol=tcp 
    dst-port=22,8291 comment="mgmt SSH+winbox"
add chain=input action=accept src-address-list=mgmt-allow protocol=tcp 
    dst-port=443 in-interface=ether2 comment="webfig"

# Sonra topyekun drop
add chain=input action=drop log=yes log-prefix="INPUT-DROP" comment="default deny"

Aynı yaklaşımı forward chain için de kurarsınız. Önemli olan her trafik türünün açıkça whitelisted olması. Drop kuralının log=yes ile loglanması, ileride neyi unuttuğunuzu görmek için kritiktir.

Katman 2: Microsegmentation – Identity ve Asset Group’lar

“Tüm 10.0.0.0/8 birbirine ulaşabilir” Zero Trust’ın tam karşıtıdır. Bunun yerine her asset grubunun ayrı address-list’i olmalı ve aralarındaki erişim açıkça tanımlanmalı:

# Asset group tanımları
/ip firewall address-list
add list=ag-devs address=10.10.10.0/24 comment="developer workstations"
add list=ag-prod-app address=10.20.20.0/24 comment="production app servers"
add list=ag-prod-db address=10.20.30.0/24 comment="production database"
add list=ag-iot address=10.30.0.0/24 comment="IoT devices"
add list=ag-printers address=10.40.0.0/24 comment="printers/MFP"

# Microsegmentation policy
/ip firewall filter
# Devs -> app (only SSH and HTTPS)
add chain=forward action=accept src-address-list=ag-devs dst-address-list=ag-prod-app 
    protocol=tcp dst-port=22,443 comment="dev->app limited"

# App -> db (only postgres)
add chain=forward action=accept src-address-list=ag-prod-app dst-address-list=ag-prod-db 
    protocol=tcp dst-port=5432 comment="app->db pg"

# IoT can ONLY reach internet, nothing else
add chain=forward action=drop src-address-list=ag-iot dst-address=10.0.0.0/8 
    comment="iot lateral block"

# Printers can be reached from devs only
add chain=forward action=accept src-address-list=ag-devs dst-address-list=ag-printers 
    protocol=tcp dst-port=9100,631 comment="dev->printer"

# Default deny inside corp
add chain=forward action=drop src-address=10.0.0.0/8 dst-address=10.0.0.0/8 
    log=yes log-prefix="MICROSEG-DROP" comment="east-west deny"

Bu pattern lateral movement saldırılarına karşı en güçlü mekanizmadır. Bir devops’un laptop’u kompromize olsa bile, attacker production DB’ye değil sadece app servera ulaşır; orada bir başka exploit gerekir.

Katman 3: Adaptive Defense – Otomatik Blacklist ve Fail2ban Benzeri Scripting

Statik kurallar yetmez. Saldırı pattern’lerini gerçek zamanlı tespit edip kaynak adresi geçici/kalıcı bloklayan dinamik mekanizmalar gerekir. MikroTik’in address-list + dynamic timeout özellikleri tam bunun için tasarlanmıştır.

SSH Brute Force Adaptif Bloku

/ip firewall filter
# Stage 1: SSH connection attempt
add chain=input protocol=tcp dst-port=22 connection-state=new 
    src-address-list=ssh-stage3 action=drop 
    comment="repeated SSH offenders blocked"

add chain=input protocol=tcp dst-port=22 connection-state=new 
    src-address-list=ssh-stage2 action=add-src-to-address-list 
    address-list=ssh-stage3 address-list-timeout=30d 
    comment="3rd offense = 30 days"

add chain=input protocol=tcp dst-port=22 connection-state=new 
    src-address-list=ssh-stage1 action=add-src-to-address-list 
    address-list=ssh-stage2 address-list-timeout=1h 
    comment="2nd in 1m = stage2"

add chain=input protocol=tcp dst-port=22 connection-state=new 
    action=add-src-to-address-list address-list=ssh-stage1 
    address-list-timeout=1m comment="1st in 1m = stage1"

Burada üst-üste işleyen kurallar zinciri yaratır: 1 dakika içinde 2. deneme stage2’ye, stage2’deyken 3. deneme stage3’e ve 30 gün boyunca bloklanır. Bu, geleneksel fail2ban’in MikroTik üzerindeki muadilidir; tamamen on-device çalışır, harici daemon gerekmez.

Port Knocking ile Hidden Management

# Sırasıyla port 1000, 2000, 3000'a UDP knock = SSH 1 saat açık
/ip firewall filter
add chain=input action=add-src-to-address-list protocol=udp dst-port=1000 
    address-list=knock1 address-list-timeout=15s

add chain=input action=add-src-to-address-list protocol=udp dst-port=2000 
    src-address-list=knock1 address-list=knock2 address-list-timeout=15s

add chain=input action=add-src-to-address-list protocol=udp dst-port=3000 
    src-address-list=knock2 address-list=mgmt-temp address-list-timeout=1h

add chain=input action=accept protocol=tcp dst-port=22 src-address-list=mgmt-temp

Port knocking single solution değildir (timing attack riskleri vardır), ancak savunma katmanlarından biri olarak değerlidir.

Katman 4: Threat Intelligence Feed Entegrasyonu

Bilinen kötü IP listeleri (Spamhaus DROP, Feodo Tracker, Emerging Threats) her gün güncellenir. MikroTik’e bunları otomatik import etmek, modern firewall yönetiminin temel parçasıdır.

Script: Spamhaus DROP List İmportu

:local listURL "https://www.spamhaus.org/drop/drop.txt"
:local listName "ti-spamhaus"
:local tmpFile "spamhaus.txt"

# Eski listeyi temizle
/ip firewall address-list remove [find list=$listName]

# Çek
/tool fetch url=$listURL dst-path=$tmpFile mode=https

# Parse + ekle
:local content [/file get $tmpFile contents]
:local lines [:toarray ""]
:foreach line in=[:toarray $content] do={
    :if ([:pick $line 0 1] != ";") do={
        :local sp [:find $line " "]
        :if ($sp > 0) do={
            :local cidr [:pick $line 0 $sp]
            :if ([:len $cidr] > 6) do={
                /ip firewall address-list add list=$listName address=$cidr 
                    timeout=2d comment="spamhaus-auto"
            }
        }
    }
}

/file remove $tmpFile
:log warning "Spamhaus list updated"

Bu script /system scheduler ile günde bir kez çalıştırılır. Sonra filter’da:

/ip firewall raw
add chain=prerouting action=drop src-address-list=ti-spamhaus in-interface=ether1 
    comment="threat-intel drop"

Aynı pattern Feodo (banking trojan C&C IP’leri), Tor exit node listesi, AbuseIPDB, FireHOL combined block list için tekrarlanabilir. Önemli: threat intel listeleri false positive üretebilir; her zaman log + alert ile başlayın, sonra drop’a geçin.

Katman 5: Geo-IP ve Country-based Filtering

Şirketinizin sadece Türkiye’den hizmet veren bir SaaS portu varsa, başka ülkelerden gelen tüm bağlantıları reddetmek meşrudur. MikroTik native geo-IP desteklemez ama MaxMind GeoLite2 veya IPDeny country zone files import edilebilir.

:local geoBaseURL "https://www.ipdeny.com/ipblocks/data/aggregated"

:foreach cc in={"cn"; "ru"; "kp"; "ir"} do={
    /ip firewall address-list remove [find list="geo-$cc"]
    /tool fetch url=($geoBaseURL . "/" . $cc . "-aggregated.zone") dst-path=($cc . ".zone") mode=https
    :local content [/file get ($cc . ".zone") contents]
    :foreach cidr in=[:toarray $content] do={
        :if ([:len $cidr] > 6) do={
            /ip firewall address-list add list=("geo-" . $cc) address=$cidr comment="geo-auto"
        }
    }
    /file remove ($cc . ".zone")
}

Sonra filter:

/ip firewall raw
add chain=prerouting action=drop src-address-list=geo-cn in-interface=ether1 
    comment="block CN inbound"

Üretimde dikkat: business model’iniz uluslararası ise geo-block kötü kullanıcı deneyimi yaratır. Genelde sadece yönetim portlarını geo-restrict etmek mantıklıdır.

Katman 6: Behavior-based Anomali Tespiti

İmza tabanlı tespit klasik IDS yaklaşımıdır; modern yaklaşımda davranış pattern’leri izlenir. MikroTik’in basit ama etkili anomali tespit araçları:

Port Scan Tespiti

/ip firewall filter
add chain=input protocol=tcp tcp-flags=fin,!syn,!rst,!psh,!ack,!urg 
    action=add-src-to-address-list address-list=scanner 
    address-list-timeout=1d comment="FIN scan detect"

add chain=input protocol=tcp psd=21,3s,3,1 
    action=add-src-to-address-list address-list=scanner 
    address-list-timeout=1d comment="port scan detect"

add chain=input src-address-list=scanner action=drop comment="block scanners"

psd (Port Scan Detection) parametresi: 3 saniye içinde 3 farklı düşük port + 1 yüksek port = scanner. Bu kombinasyon basit ama etkili.

Connection Limit per Source

add chain=forward protocol=tcp connection-limit=200,32 src-address=0.0.0.0/0 
    action=add-src-to-address-list address-list=conn-flood 
    address-list-timeout=10m comment="200+ conn per /32 = flood"

add chain=forward src-address-list=conn-flood action=drop

Bir IP’den gelen aktif connection sayısı 200’ü geçerse 10 dakika bloklanır. Normal kullanıcılar bu eşiğe ulaşmaz; bot/scraper davranışı yakalar.

Continuous Verification: Session Re-evaluation

Zero Trust’ın “continuous verification” prensibi; bir session’ı sadece açılırken değil, süresince izlemek demektir. MikroTik üzerinde bu, conntrack timeout + session limit + behavior monitor kombinasyonuyla yapılır. İdeal mimari:

• Her session için maksimum süre tanımlanır (örneğin SSH session 8 saat sonra otomatik düşer).
• Bandwidth anomalisi tespit edilirse (kullanıcı 100 GB indirme yaptı) alert üretilir.
• Source IP değişirse (mobile roaming dışında beklenmedik bir change) session yeniden auth gerektirir.

Bu gibi davranışsal kararlar genellikle MikroTik’in kendi başına yapacağı şey değildir; SIEM (Wazuh, Splunk, Elastic Security) entegrasyonu ile orkestre edilir. MikroTik logları SIEM’e syslog ile iletilir, SIEM kuralları tetiklediğinde MikroTik API üzerinden ilgili IP address-list’e eklenir.

SIEM Entegrasyonu: Logları Akıllı Hale Getirmek

# MikroTik tarafında syslog hedefini ayarla
/system logging action add name=remote target=remote remote=10.99.100.10 remote-port=514 
    src-address=10.99.0.1 bsd-syslog=yes

/system logging
add topics=firewall action=remote
add topics=ssh,info action=remote
add topics=warning,!debug action=remote

SIEM tarafında (örneğin Wazuh) rule:

<rule id="100200" level="10">
  <decoded_as>mikrotik</decoded_as>
  <match>INPUT-DROP</match>
  <frequency>5</frequency>
  <timeframe>60</timeframe>
  <same_source_ip />
  <description>Multiple firewall drops from same IP</description>
</rule>

Bu rule tetiklendiğinde Wazuh’un active-response modülü, MikroTik’e REST API çağrısı yapıp source IP’yi address-list’e ekler. Bu, gerçek zamanlı adaptive defense’in temelidir.

Otomasyon: Tüm Bunları Ansible ile Push Etmek

Yukarıdaki tüm yapı 50 farklı router’da tutarlı olmalı. Ansible playbook:

- hosts: edge_routers
  vars_files: [ vars/threat_intel_lists.yml, vars/microseg_rules.yml ]
  tasks:
    - name: Render firewall config
      template:
        src: templates/firewall_zerotrust.j2
        dest: /tmp/fw_rendered.rsc
      delegate_to: localhost

    - name: Upload to router
      community.routeros.api:
        path: /file
        cmd: import
        file: /tmp/fw_rendered.rsc

    - name: Verify config applied
      community.routeros.command:
        commands: ["/ip firewall filter print where comment~"auto-""]
      register: rules
      failed_when: rules.stdout_lines | length < 20

Template tarafında Jinja2 ile her router için ilgili microsegmentation kuralları render edilir. Bu sayede config drift en aza iner; bir kuralın bir router’da varsa hepsinde olur.

Performans Notları

• Address-list lookup hızı: RouterOS 7.x address-list’i hash table tabanlıdır; 100.000 entry’lik listede bile O(1) lookup. Tereddütsüz büyük threat intel listeleri import edebilirsiniz.
• Kural sırası önemli: En sık eşleşen kurallar yukarıda olsun. Conntrack established/related en üstte, default drop en altta.
• RAW vs Filter: Açıkça istenmeyen trafik RAW’da düşürülmeli. Conntrack ile takip edilecekler filter’a bırakılmalı.
• FastTrack: Established connection’lar için fastpath. Throughput’u 2-3x artırır. Ancak fastpath kullanılan paketler firewall filter’dan tekrar geçmez; pattern detection ihtiyacınız varsa dikkatli kullanın.
• Log overhead: log=yes her paketi CPU tüketir. Production’da log=yes sadece drop kurallarında, accept’lerde log=no.

Monitoring ve Görselleştirme

Adaptive firewall’unuzun ne yaptığını görmüyorsanız, çalışıp çalışmadığını da bilemezsiniz. Önerdiğim stack:

• Promtail + Loki: MikroTik syslog’larını alıp index’ler. Grafana üzerinden sorgu.
• Prometheus + mikrotik-exporter: Firewall counter’larını metric olarak çeker. “Saatte kaç drop oldu?” sorusuna anlık cevap.
• Grafana dashboard: Top 10 banned IPs, threat intel feed effectiveness, microsegmentation violations, geo-IP heatmap.
• Alerting: Spike detection (1 saatte normal limitin 5x’i drop varsa alert), threat actor focus (aynı kaynaktan birden çok router’ı targetleyenler).

Sık Sorulan Sorular

MikroTik gerçekten Zero Trust için yeterli mi?

Network katmanı için evet; identity/user katmanı için tek başına yetersizdir. Tam Zero Trust mimarisi için MikroTik + bir identity provider (Keycloak, Okta, Azure AD) + ZTNA gateway (Cloudflare Access, Tailscale, Twingate) kombinasyonu gerekir. MikroTik bu yapının network enforcement katmanıdır.

Default drop politikası lockout riski yaratmaz mı?

Evet; ilk kez uygulanırken risk yüksektir. Önce yeni kuralları log-only ile çalıştırın, gerçek trafiği analiz edin, sonra accept/drop kararını verin. Critical: Console (serial) erişimini her zaman koruyun; networkten kilitlenirseniz fiziksel erişim hayat kurtarır.

Threat intel feed’leri ücretli mi?

Birçoğu ücretsizdir: Spamhaus DROP, Feodo Tracker, AbuseIPDB free tier, Emerging Threats open. Ücretliler (Recorded Future, ThreatConnect, IBM X-Force) enterprise SLA + curation sunar. Çoğu SME için open source feed kombinasyonu yeterlidir.

Microsegmentation MikroTik’in CPU’sunu zorlar mı?

Address-list tabanlı microsegmentation O(1) lookup olduğundan, 100+ asset group’lu yapılarda bile CPU yükü düşüktür. Asıl zorlanma, çok sayıda küçük flow’da connection-tracking yükünden gelir. RouterOS 7.x’in connection-tracking iyileştirmesi (raw + filter ayrımı) bu yükü azaltır.

SIEM şart mı, küçük ofis için overkill değil mi?

Küçük ofis için Wazuh (open source) veya Graylog tek VM’de çalışır ve değerlidir. Tam SIEM yerine basit log aggregation + cron-based pattern search ile başlanabilir. Önemli olan logların merkezi bir yerde tutulması; sonra zekâ katmanı eklenir.

Geo-IP bloklamak hukuken sorun yaratır mı?

Genel olarak hayır; özel firmanız kime hizmet vereceğini seçer. Ancak fundamental right’ı olan hizmetler (örneğin gazete, public service) için problemli olabilir. SaaS B2B için yaygın ve kabul edilen bir pratiktir.

Adaptive firewall ile yanlışlıkla bir CEO’yu bloklayabilir miyim?

Evet, ve bu klasik hatadır. VIP whitelist mutlaka olsun: /ip firewall address-list add list=vip-bypass ... ve tüm dynamic block kurallarında src-address-list=!vip-bypass exception’ı koyun. Best practice: VIP listesi sadece office prefix değil, kişiye özel cihaz MAC veya ZTNA identity ile yapılsın.

Sonuç

Zero Trust mimarisi MikroTik üzerinde uygulanabilir bir hedeftir; ancak tek bir firewall config değil, katmanlı bir yaklaşım gerektirir: RAW erken drop, default deny, microsegmentation, adaptive blacklist, threat intel feed, behavior detection ve SIEM entegrasyonu. Her katman önemlidir; bir tanesi atlanırsa zincir zayıflar. En önemlisi, tüm bu yapının kodla yönetilmesidir; manuel girilen kurallar tutarsızlık ve drift yaratır. Bir sonraki yazıda bu mimarinin üzerinde çalışacak production firewall checklist’ini ve otomasyon snippet’lerini derleyeceğiz.

Devamı İçin Okumanızı Öneririz

Bağlantılı kavramları daha derinden işleyen yazılarımız:

• Alpine Linux ile DIY Router: MikroTik Alternatifi mi, Tamamlayıcısı mı? — Alpine Linux ile DIY router kurulumu, MikroTik ile karşılaştırma, hibrit kullanım ve conta
• MikroTik Hardening: Sertleştirme Kontrol Listesi ve Saldırı Yüzeyi Azaltma — MikroTik cihazlarini saldiri yuzeyi minimize edilmis kurumsal duzeyde guvenligi tasimak ic
• MikroTik Cloud Hosted Router (CHR): VMware, Proxmox, AWS ve Hetzner Üzerinde Dağıtım — MikroTik Cloud Hosted Router (CHR) ile VMware, Proxmox, AWS, Hetzner ve Vultr üzerinde Ter

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
• MikroTik Resmi Dökümantasyon (RouterOS Wiki)
• MikroTik Resmi Forumu