Sunucu önünde MikroTik koymak, üzerinde en çok mühendislik tartışması döndüğü kararlardan biridir. “Niye Cisco ASR koymayalım?”, “Linux ile iptables ne eksiği var?”, “FortiGate çok daha güçlü değil mi?” gibi sorular her teklif sürecinde karşıma çıkar. Beş yılı aşkın hosting ve hizmet sağlayıcı altyapısında çalışmış biri olarak benim yanıtım pragmatiktir: MikroTik, doğru senaryoda, doğru konfigürasyonla, sunucu başına 10 dolarlık ek maliyetle 50 dolarlık WAF + 20 dolarlık IDS hizmetinin yerini tutabilir. Bu yazıda, hosting müşterileri için sunucu önünde MikroTik koymanın mimari mantığını, somut konfigürasyonlarını ve canlı vakalarla mitigation senaryolarını paylaşacağım.

Hosting Mimarisinde MikroTik Nereye Konumlanır?

Tipik bir hosting topolojisinde trafik şu şekilde akar: ISP → core router → distribution switch → server. MikroTik’i bu zincire iki noktada eklemek mantıklıdır:

• Edge konumu: ISP ile core router arasında. Burada tüm hosting trafiği geçer; volumetric filtreleme, BGP RTBH koordinasyonu, geo-IP’nin upstream eşiği bu noktada yapılır. Genellikle CCR2216 veya CCR2116 sınıfı cihaz gerekir.
• Servis önü konumu: Distribution switch ile belirli bir sunucu grubu arasında. Burada per-müşteri özelleştirilmiş kurallar uygulanır: oyuncu sunucusu için farklı, e-ticaret için farklı, mail sunucusu için farklı politikalar. CCR2004 veya RB5009 yeterli olur.

İki katmanlı yaklaşım, “trafik geldi geçti” yerine “trafik filtre edildi, sınıflandırıldı, sonra hizmet sunucusuna iletildi” mantığını sağlar. Hosting tarafında her müşterinin trafiği bir vlan ile izole edilir; MikroTik her vlan için bağımsız politika uygular. Bu mimari kritik bir avantaj sunar: bir müşteriye yönelik saldırı, diğer müşterileri etkilemez. Saldırgan IP listeniz müşteri başına izole tutulur, yanlış pozitif riski minimize edilir.

Raw Chain ile Aday Filtreleme: İlk Savunma Hattı

Sunucu önündeki MikroTik’in raw chain’i, conntrack devreye girmeden trafiği eleyecek şekilde tasarlanır. Hosting senaryosunda raw chain’de filtrelenmesi gereken kategoriler:

/ip firewall raw
add chain=prerouting action=drop src-address-list=bogon comment="Bogon kaynak"
add chain=prerouting action=drop src-address-list=spamhaus-drop comment="Spamhaus DROP list"
add chain=prerouting action=drop src-address-list=tor-exit-known comment="Tor exit nodlari mail icin"
add chain=prerouting action=drop in-interface=ether1-wan dst-address-type=local 
    protocol=tcp dst-port=22,8291,8728,8729 comment="Yonetim portlari WAN'a kapali"
add chain=prerouting action=drop fragment=yes protocol=tcp comment="TCP fragment drop"
add chain=prerouting action=drop protocol=udp src-port=11211,389,1900,19,389,17 
    comment="UDP amplification kaynak portlari"
add chain=prerouting action=drop protocol=tcp tcp-flags=fin,syn comment="Invalid TCP flag kombinasyonlari"
add chain=prerouting action=drop protocol=tcp tcp-flags=syn,rst comment="SYN+RST kombinasyonu"
add chain=prerouting action=drop protocol=tcp tcp-flags=!fin,!syn,!rst,!ack comment="Null scan"
add chain=prerouting action=drop protocol=tcp tcp-flags=fin,syn,rst,psh,ack,urg comment="Xmas scan"

Bogon ve Spamhaus listeleri otomatik güncellenmelidir. Aşağıdaki script Spamhaus DROP listesini saatlik olarak indirir:

/system script
add name=spamhaus-update source={
    /tool fetch url="https://www.spamhaus.org/drop/drop.txt" dst-path=drop.txt
    :local content [/file get drop.txt contents]
    /ip firewall address-list remove [find list=spamhaus-drop]
    :foreach line in=[:toarray [:tostr $content]] do={
        :if (([:pick $line 0 1] != ";") and ([:len $line] > 5)) do={
            :local addr [:pick $line 0 [:find $line ";"]]
            /ip firewall address-list add list=spamhaus-drop address=$addr comment="Spamhaus DROP"
        }
    }
}

/system scheduler
add name=spamhaus-hourly interval=1h on-event=spamhaus-update

Bogon listesi için Team Cymru’nun fullbogons listesini benzer şekilde otomatize edebilirsiniz. Tor exit node listesi için https://check.torproject.org/torbulkexitlist kullanılabilir. Bu otomasyonlar sayesinde sunucu önü MikroTik daima güncel tehdit zekası ile çalışır.

Geo-IP Filtreleme: Türkiye Odaklı Hosting İçin Vazgeçilmez

Hosting müşterilerinin %90’ı sadece Türkiye’den hizmet sunuyorsa, dünya geri kalanından gelen trafiği analiz etmek kaynak israfıdır. MikroTik’te Geo-IP filtreleme için MaxMind GeoLite2 veritabanını kullanırız. RouterOS 7.x’te dahili Geo-IP modülü olmadığı için ya manual address-list üretiriz, ya da Linux container üzerinden cron job ile address-list besler.

Tipik bir manuel yaklaşım:

# Linux tarafinda yapilan hazirlik (cron ile haftalik)
wget https://download.maxmind.com/geoip/databases/GeoLite2-Country-CSV/download
unzip GeoLite2-Country-CSV.zip
awk -F',' '$2=="TR" {print $1}' GeoLite2-Country-Blocks-IPv4.csv > tr-ipv4.txt

# MikroTik'e otomatik yukleme
scp tr-ipv4.txt admin@mikrotik:flash/
ssh admin@mikrotik "/import flash/tr-ipv4.rsc"

# RouterOS scripti olarak
/ip firewall address-list
foreach line in tr-ipv4.txt:
    add list=geo-tr address=$line comment="GeoLite2 TR"

Filter chain’de bu listeyi kullanmak:

/ip firewall filter
add chain=forward action=accept src-address-list=geo-tr dst-port=80,443 protocol=tcp 
    comment="TR'den HTTP/HTTPS izin"
add chain=forward action=drop dst-port=80,443 protocol=tcp src-address-list=!geo-tr 
    comment="TR disindan HTTP/HTTPS drop"

# Mail sunuculari icin esnek
add chain=forward action=accept dst-port=25,587,993,995 protocol=tcp 
    comment="Mail genel olarak butun dunyaya acik"

Bu yaklaşımın incelikleri var. SMTP gibi mail trafiği için geo-IP filtreleme uygulanmamalıdır, çünkü mail dünya çapındadır. SSH gibi yönetim portları için ya tek tek IP whitelist (kurumsal ofis IP’leri), ya da port-knocking, ya da WireGuard VPN arkasına gizleme yapılır. Geo-IP, ortak hosting müşterilerinin web trafiği için çok uygundur, ancak her hizmetin doğasına göre değerlendirilmelidir.

Per-IP Rate Limit: NAT’lı Kullanıcıları Yanlış Engellememek

“Bir IP saniyede 100 istek yapıyorsa block et” cümlesi naif. NAT arkasında 1000 kullanıcısı olan bir kurumsal müşteri, organik şekilde saniyede 200 istek üretebilir. Rate limit kuralları farklı katmanlarda farklı sıklıkta uygulanır:

/ip firewall filter
# TCP yeni baglanti rate limit
add chain=forward action=add-src-to-address-list address-list=rate-limited-tcp 
    address-list-timeout=10m protocol=tcp connection-state=new 
    limit=50,200:packet comment="Saniyede 50 yeni TCP baglanti esigi"

# HTTP isteklerine yonelik (TCP RST ile)
add chain=forward action=add-src-to-address-list address-list=http-flooders 
    address-list-timeout=15m protocol=tcp dst-port=80,443 
    connection-state=new connection-limit=100,32 
    comment="100 essamanli baglanti esigi"

# UDP rate limit (genelde DNS sorgulari icin)
add chain=forward action=drop protocol=udp dst-port=53 
    src-address-list=dns-flooders 
    comment="DNS flood drop"

add chain=forward action=add-src-to-address-list address-list=dns-flooders 
    address-list-timeout=5m protocol=udp dst-port=53 
    limit=20,40:packet comment="Saniyede 20 DNS sorgu esigi"

NAT’lı kullanıcıları yanlış engellememek için iki teknik kullanırız. Birincisi, threshold’u trafiğin gerçek baseline’ına göre kalibre etmek; ikincisi, IP yerine connection-mark veya cookie ile session bazında ayırt etmek. İkinci yaklaşım daha karmaşık ama doğru NAT davranışı sağlar:

/ip firewall mangle
add chain=prerouting action=mark-connection new-connection-mark=client-session 
    protocol=tcp connection-state=new 
    passthrough=yes

/ip firewall filter
add chain=forward action=add-src-to-address-list address-list=session-flooders 
    address-list-timeout=10m connection-mark=client-session 
    connection-rate=50k-1G comment="Yuksek bant kullanan oturum"

connection-rate matchini kullanmak, paket sayısı yerine baytlik aktarım hızına göre filtreler. Bu, dosya indiren yasal kullanıcıyı saldırgan zannetme riskini düşürür.

Vaka 1: Kuyumcu E-ticaret Sitesinin Cyber Monday Karabası

Kasım 2024’te bir kuyumcu e-ticaret sitesi müşterimiz, Cyber Monday öncesi 4 gün boyunca sürekli L7 HTTP flood saldırısına uğradı. Saldırgan, profesyonel görünümlü 1500+ farklı IP’den (rotating proxy/residential botnet) saniyede toplam 25.000 istek üretiyordu. Her istek geçerli görünüyordu: doğru User-Agent, doğru Accept header, hatta Cookie. WAF (ModSecurity) bu trafiği yasal olarak kabul ediyordu çünkü içerik temizdi.

Çözüm MikroTik tarafında oldu. Saldırıdaki IP’lerin %92’si “residential botnet” kaynaklıydı ve bu IP’lerin %78’i bir önceki saatte hiç ziyaret etmemişti. Behavioral fingerprinting ile aşağıdaki kural setini devreye aldık:

/ip firewall filter
# Yeni IP'leri ilk 60 saniyede agresif rate limit altinda tut
add chain=forward action=add-src-to-address-list address-list=new-clients 
    address-list-timeout=60s protocol=tcp dst-port=443 connection-state=new 
    src-address-list=!known-clients

# Yeni IP'lere agresif sinir
add chain=forward action=drop protocol=tcp dst-port=443 
    src-address-list=new-clients connection-limit=3,32 
    comment="Yeni IP'ler 60 saniye boyunca 3 baglanti sinirinda"

# 60 saniyeyi gecip aktif kalan IP'leri known-clients listesine al
add chain=forward action=add-src-to-address-list address-list=known-clients 
    address-list-timeout=24h protocol=tcp dst-port=443 
    connection-bytes=10000-0 comment="10KB veri transferi sonrasi guvenilir"

Bu yaklaşım, gerçek müşterileri etkilemeden saldırıyı sönümledi. Yasal müşteriler sayfada birkaç saniye geçirir, 10KB veri transferi tamamlar ve known-clients listesine alınır. Botlar genelde tek istekte siteyi terk eder, known-clients listesine asla giremez ve sürekli rate limit altında kalır. Saldırı yoğunluğu 25.000 RPS’den 800 RPS’ye düştü ve WAF bu seviyeyi rahatlıkla işledi.

Vaka 2: Mail Sunucusuna Süreğen SMTP Auth Flood

2025 Şubat ayında bir hosting müşterisi olan mail sunucusu, sürekli SMTP authentication brute force saldırısı altındaydı. Saldırgan, 50+ ülkeden 800+ IP’den, saniyede 200 SMTP auth denemesi yapıyordu. Postfix ve Dovecot logları doluyor, disk I/O artıyor, gerçek kullanıcılar bağlantı kuramıyordu.

Çözüm MikroTik tarafında auth deneme oranını saldırgan başına sınırlamak oldu:

/ip firewall filter
# SMTP/IMAP auth denemelerini saymak icin baglanti olusumunu izle
add chain=forward action=add-src-to-address-list address-list=smtp-attempters 
    address-list-timeout=1h protocol=tcp dst-port=25,465,587,993,995 
    connection-state=new comment="Auth denemeleri saydirma"

# Saatte 30'dan fazla SMTP baglantisi acan IP'yi block et
add chain=forward action=add-src-to-address-list address-list=smtp-bruteforce 
    address-list-timeout=24h protocol=tcp dst-port=25,465,587 
    connection-state=new 
    src-address-list=smtp-attempters connection-limit=30,32

add chain=forward action=drop src-address-list=smtp-bruteforce 
    comment="SMTP brute force droppped"

Bu kural seti devreye girdikten 4 saat sonra address-list smtp-bruteforce 612 IP’ye ulaştı. Mail sunucusu yükü %78’den %12’ye düştü. Yasal kullanıcılar ve mail sunucularımız etkilenmedi çünkü onlar saatte 1-5 bağlantı açıyor, threshold çok altında kalıyorlardı.

Vaka 3: Dropshipper Mağazasına Stok Scraping Botları

Mart 2025’te bir dropshipping mağazası, rakip firma tarafından 24/7 stok scraping’e maruz kalıyordu. Saldırgan profesyoneldi: Headless Chrome kullanıyor, User-Agent değiştiriyor, IP rotation yapıyor, Cloudflare bot detection’ı bypass ediyordu. Cloudflare turnstile sayfası bile geçiyordu (muhtemelen turnstile bypass servisi kullanıyor).

Çözüm, Cloudflare’i kaldırıp tüm trafiği MikroTik üzerinden geçirmek ve davranışsal anomali tespiti uygulamak oldu. Scraper’lar belli bir paterne sahiptir: çok hızlı sayfa geçişi, tek sayfa görüntüleme, JavaScript çalıştırmama. Web sunucusu tarafında session tracking aktive edip, MikroTik’te per-IP istek hızına agresif sınır koyduk:

/ip firewall filter
# Sayfa basina 2 saniyeden hizli istek atan IP'ler scraper
add chain=forward action=add-src-to-address-list address-list=potential-scraper 
    address-list-timeout=30m protocol=tcp dst-port=443 
    connection-state=new connection-rate=5-1G 
    limit=30,60:packet comment="30+ baglanti/dakika scraper kandidatlari"

# Scraper'lar uzerinde agresif throttle
add chain=forward action=drop protocol=tcp dst-port=443 
    src-address-list=potential-scraper connection-limit=2,32 
    comment="Scraper'lar 2 essamanli baglanti ile sinirli"

Web sunucusu tarafında ek bir mantık eklendi: kullanıcı 5 saniye boyunca aynı sayfada kalırsa “human” cookie alır, MikroTik bu cookie’ye sahip bağlantıları rate limit’ten muaf tutar. Bunu için bir ek address-list ve cookie marking mekanizması:

# Web sunucusu tarafinda nginx
location / {
    if ($cookie_human = "1") {
        set $is_human 1;
    }
    if ($is_human = 1) {
        proxy_set_header X-Human-Verified "1";
    }
    proxy_pass http://backend;
}

# MikroTik tarafinda layer7 protocol
/ip firewall layer7-protocol
add name=human-cookie regexp="Cookie:.*human=1"

/ip firewall filter
add chain=forward action=accept layer7-protocol=human-cookie 
    comment="Insan dogrulanmis"

Bu çözüm 1 hafta içinde scraping trafiğini %94 azalttı. Rakip firma stok bilgilerini güncel tutamadığı için bizim müşteri rekabet avantajı kazandı.

Sunucu Önünde MikroTik İçin Performans Optimizasyonu

MikroTik’i sunucu önüne koyunca CPU performansı kritik hale gelir. Şu noktalara dikkat:

• Hardware queue: CCR serisi cihazlarda her CPU core bir interface queue’ya assign edilebilir. /queue tree yerine /queue interface kullanın.
• Fast path: Connection tracking gerekmediği durumlarda fasttrack-connection aktive edin. Fast path’te paketler conntrack’ten geçmez, CPU tasarrufu olur.
• Hardware offload: Switch chip’i olan modellerde basit L2 yönlendirme hardware’de yapılır. /interface ethernet switch ayarlarını optimize edin.
• Connection tracking timeout: Varsayılan TCP timeout 1 saat. Hosting trafiği için 10 dakikaya düşürmek conntrack tablosu boyutunu küçültür.

/ip firewall connection tracking
set tcp-established-timeout=10m
set tcp-syn-sent-timeout=10s
set tcp-syn-received-timeout=10s

/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related 
    protocol=tcp dst-port=80,443 comment="HTTP/HTTPS fasttrack"
add chain=forward action=accept connection-state=established,related

Fasttrack ile basit HTTP trafiği conntrack’ten geçmeden iletilir; CCR2004 üzerinde paket başına işlem süresi 1.2 µs’den 0.4 µs’ye düşer. Sürekli %60 CPU kullanımı yapan bir cihaz fasttrack sonrası %25’e iner.

İzleme ve Alarm: SNMP ve Telegraf Entegrasyonu

Production’da sunucu önündeki MikroTik gözünüzün önünde olmalı. Şu metrikleri sürekli izlemelisiniz:

• Interface paket/saniye (rx ve tx ayrı)
• CPU kullanımı (her core ayrı)
• Connection tracking tablosu boyutu
• Address-list eleman sayısı (saldırı altında ani artış)
• Drop edilen paket sayısı (raw chain + filter chain)

SNMP exporter ile Prometheus’a gönderip Grafana’da görselleştirin. Telegraf alternatif olarak InfluxDB’ye yazabilir:

# Telegraf snmp input plugini
[[inputs.snmp]]
  agents = ["udp://mikrotik-edge:161"]
  version = 2
  community = "monitoring"

  [[inputs.snmp.field]]
    name = "uptime"
    oid = "1.3.6.1.2.1.1.3.0"

  [[inputs.snmp.table]]
    name = "mikrotik_interface"
    inherit_tags = ["hostname"]

    [[inputs.snmp.table.field]]
      name = "ifInOctets"
      oid = "1.3.6.1.2.1.2.2.1.10"
      is_tag = false

Alarm tetikleyiciler için temel kurallar: CPU %80 üzeri 5 dakika sürdüğünde, connection count 100.000’i aştığında, drop rate normal trafiğin 10x’ini aştığında, address-list eleman sayısı 5000+’a çıktığında alarm gelmeli. Bu alarmlar, saldırı başlamadan veya başlar başlamaz operasyon ekibinin müdahale etmesine olanak verir.

Yedeklilik: MikroTik Çökerse Ne Olur?

Production’da tek bir MikroTik’e güvenmek riskli. Yedeklilik için iki yaklaşım var:

• Active-passive VRRP: İki MikroTik birbiriyle VRRP ile çalışır, biri aktif, biri yedek. Active çökünce yedek 3 saniye içinde devralır. Konfigürasyon RouterOS dökümantasyonunda detaylıdır.
• Active-active BGP: İki MikroTik aynı prefix’i farklı upstream’lere ilan eder, trafik ECMP ile bölünür. Birisi çökerse trafik tamamen diğerine kayar. Daha karmaşık ama yüksek performans sağlar.

# VRRP basit konfigurasyon
/interface vrrp
add interface=ether1-wan vrid=1 priority=200 
    name=vrrp-wan version=3

/ip address
add address=203.0.113.1/24 interface=vrrp-wan comment="VRRP shared IP"

# Yedek cihazda priority=100 ile aynisi

SSS: Hosting İçin MikroTik Hakkında Sık Sorulanlar

MikroTik tek başına FortiGate yerini tutar mı?

L3/L4 firewall ve DDoS mitigation tarafında tamamen. Ancak DPI (Deep Packet Inspection), gelişmiş antivirüs, sandbox analizi gibi UTM özellikleri MikroTik’te yok. Hosting senaryosunda bu özelliklere genelde gerek olmaz çünkü trafik kullanıcıya değil sunucuya gidiyor. FortiGate’in maliyeti MikroTik’in 8-15 katı; basit hosting için aşırılık.

1 Gbps hat için hangi MikroTik?

RB4011 veya RB5009 yeterli. CPU paket işleme kapasitesi açısından RB5009 daha güçlü, 10 Gbps’lik SFP+ portu sayesinde gelecekte yatırım koruması sağlar.

10 Gbps üzeri trafik için?

CCR2004 (10 Gbps line rate), CCR2116 (100 Gbps line rate), CCR2216 (200 Gbps line rate). DDoS savunması yaparken line rate’in yarısını planlamak makul; çünkü filter kuralları, mangle işlemleri CPU tüketir.

Geo-IP listesi nasıl güncellenir?

MaxMind GeoLite2 ücretsiz API ile, Türkiye için haftalık yeterli (IP allocation çok yavaş değişir). Linux container’da cron job ile script çalıştırıp address-list export edip MikroTik’e import edebilirsiniz.

Müşteri başına ayrı politika nasıl uygulanır?

Her müşteri kendi VLAN’inde olmalı; MikroTik VLAN bazında ayrı filter chain’ler tanımlar. Connection-mark ile müşteri trafiğini işaretleyip downstream’de farklı QoS politikası da uygulayabilirsiniz.

Yedek MikroTik çökerse ne olur?

VRRP ile 3 saniye içinde failover, BGP ECMP ile anında. Aktif-pasif VRRP konfigürasyonu, hizmet sürekliliği için minimum gerekli olan yedeklilik düzeyidir.

Rate limit ne zaman çok agresif olur?

Trafiğinizin baseline’ını biliyorsanız, threshold’unuzu 3-4x üzeri tutarsanız genelde yanlış pozitif riski düşük olur. Müşteri yorumlarını izleyin; “siteniz açılmıyor” şikayetleri rate limit’in çok sıkı olduğunun göstergesidir.

BGP RTBH (black hole) kim için uygundur?

Üst akış ISP’nizin desteklemesi gerekir. Türkiye’de Telia, Telecom Italia Sparkle gibi Tier 1’ler ve TTNet, Vodafone gibi yerel sağlayıcıların kurumsal hatlarında /32 RTBH community desteği var. ISP’nizle anlaşırken bu desteği mutlaka sorun.

Sonuç: MikroTik Hosting İçin Akıllı Mühendislik Seçimidir

Sunucu önünde MikroTik kullanmak, “pahalı enterprise donanıma para vermek” yerine “akıllı mühendislik ile aynı sonuca daha az maliyetle ulaşmak” demektir. Bu yazıda paylaştığım konfigürasyonlar gerçek müşteri vakalarında test edilmiş, sürekli iyileştirilmiş reçetelerdir. Yine de unutmayın: hiçbir firewall konfigürasyonu “kur ve unut” değildir. Saldırı tipolojisi her ay değişir; sizin de threshold’larınızı, address-list’lerinizi, izleme dashboard’larınızı düzenli olarak gözden geçirmeniz gerekir. Hosting tarafında düzenli “saldırı simülasyonu” planlayın, kendi sisteminize kontrollü stress test yapın, zayıf noktaları kapatın. En iyi savunma, kendi sistemine düzenli olarak saldıran sistem yöneticisidir.

Aynı Konuda Diğer Yazılarımız

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

• Firewall Türleri Karşılaştırması: Packet Filter, Stateful, Proxy, NGFW ve WAF — Packet Filter’dan WAF’a kadar bes ana firewall mimarisi: OSI katmani iliskisi, performans-
• MikroTik Hardening: Sertleştirme Kontrol Listesi ve Saldırı Yüzeyi Azaltma — MikroTik cihazlarini saldiri yuzeyi minimize edilmis kurumsal duzeyde guvenligi tasimak ic
• MikroTik Layer 7 Protocol Filtering: Uygulama Katmanı Trafik Tanıma ve Engelleme — MikroTik Layer 7 protocol filtering: regex tabanlı uygulama katmanı trafik tanıma, gerçek

Kaynaklar ve Daha Fazla Bilgi

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

• Cloudflare DDoS Threat Report
• NETSCOUT Threat Intelligence
• CISA DDoS Best Practices
• NIST Cybersecurity Framework
• OWASP Foundation