Firewall ve Router ACL Optimizasyonu: 7 Adım

İlgili yazılar

Cisco QoS Troubleshooting: Policy Var Ama Trafik Neden Önceliklenmiyor?

1 gün önce

Cisco VLAN Trunk Troubleshooting: VLAN Var Ama Trafik Neden Geçmiyor?

1 hafta önce

Cisco 802.1X + ISE: Access Layer’da Kimlik Tabanlı Erişim Kontrolü

2 hafta önce

Erişim Kontrol Listeleri, yani ACL’ler, ağ güvenliğinin en temel kontrol mekanizmalarından biridir. Ancak kötü yazılmış ACL’ler sadece güvenlik riski oluşturmaz; aynı zamanda cihaz CPU’sunu, TCAM/ACL donanım kaynaklarını ve operasyonel yönetilebilirliği de olumsuz etkiler.

Özellikle router, switch, firewall veya L3 core katmanında büyüyen ACL tabloları şu sorunlara yol açabilir:

• Gereksiz uzun match süresi
• TCAM kaynak tüketimi
• Karmaşık troubleshooting
• Yanlış sıralanmış permit/deny kuralları
• Fazla logging nedeniyle CPU yükü
• Gölgeleyen veya hiç hit almayan kurallar
• Değişikliklerde yüksek kesinti riski

İyi ACL tasarımı; sadece “trafik izin/verme” meselesi değil, performans, güvenlik ve operasyonel sadelik meselesidir.

---

1️⃣ İsimlendirilmiş ve Sıralı ACL Kullanın

Numaralı ACL’ler küçük yapılarda yeterli görünebilir; ancak üretim ortamlarında okunabilirlik ve değişiklik yönetimi için named ACL tercih edilmelidir.

İyi örnek

ip access-list extended INTERNET_IN
 remark [OWN=Network][REQ=CHG-123][WHY=HTTPS access to public web servers]
 permit tcp any host 10.10.10.10 eq 443
 permit tcp any host 10.10.10.11 eq 443
 deny ip any any log

Neden önemli?

• Kural amacı daha net görünür.
• Araya yeni ACE eklemek daha kolaydır.
• Change yönetimi sadeleşir.
• Denetimlerde açıklama yapmak kolaylaşır.
• Hangi ACL’nin nerede kullanıldığı daha hızlı anlaşılır.

---

2️⃣ Tekrarlı Kuralları Azaltın: Object-Group / Gruplama Kullanın

Aynı port veya IP bloğu için onlarca tekrar eden ACE yazmak, konfigürasyonu şişirir ve hata riskini artırır.

Platform destekliyorsa object-group kullanmak daha temiz bir yöntemdir.

Object-group destekli örnek

object-group network WEB_SERVERS
 host 10.10.10.10
 host 10.10.10.11
 host 10.10.10.12

object-group service WEB_PORTS tcp
 port-object eq 443
 port-object eq 80

ip access-list extended INTERNET_IN
 permit tcp any object-group WEB_SERVERS object-group WEB_PORTS
 deny ip any any log

Not

IOS/IOS-XE tarafında object-group desteği platform ve yazılım sürümüne göre değişebilir. Destek yoksa aynı mantık sade ACE’lerle veya mimariye göre firewall tarafına taşınarak uygulanmalıdır.

Yanlış konumlandırmadan kaçının

Aşağıdaki kullanım her IOS ACL senaryosunda geçerli bir interface ACL yazımı değildir:

permit tcp any prefix-list WEB_SERVERS eq 443

prefix-list genellikle route filtering, BGP/OSPF redistribution, route-map veya policy routing gibi senaryolarda kullanılır. Interface ACL içinde IP gruplama için platform destekliyorsa object-group; destek yoksa klasik ACE kullanımı tercih edilmelidir.

---

3️⃣ En Sık Kullanılan ve En Kritik Kuralları Doğru Sıralayın

ACL’ler yukarıdan aşağıya değerlendirilir. Bu yüzden kural sırası güvenlik davranışını doğrudan etkiler.

Sıralama prensibi

• En spesifik kurallar üste
• En sık hit alan kritik izinler üst sıralara
• Riskli deny kuralları uygun yerde
• Genel deny / cleanup rule en altta
• Geniş permit kuralları spesifik kuralların üstüne konulmamalı

Kötü örnek

ip access-list extended INTERNET_IN
 permit ip any any
 deny tcp any host 10.10.10.10 eq 3389

Bu yapıda alttaki deny kuralı hiçbir zaman çalışmaz. Çünkü üstteki permit ip any any tüm trafiği geçirir.

İyi örnek

ip access-list extended INTERNET_IN
 deny tcp any host 10.10.10.10 eq 3389 log
 permit tcp any host 10.10.10.10 eq 443
 deny ip any any log

---

4️⃣ Loglamayı Kontrollü Kullanın

Her deny kuralına log eklemek ilk bakışta iyi görünür; ancak yüksek trafik altında CPU ve syslog altyapısını zorlayabilir.

Riskli örnek

ip access-list extended INTERNET_IN
 deny ip any any log

Eğer bu ACL yoğun internet trafiği alan bir interface üzerinde çalışıyorsa, deny logları hızla büyüyebilir.

Daha sağlıklı yaklaşım

• Sadece kritik deny kurallarında log kullanın.
• Cleanup deny loglamasını sınırlı süre açık tutun.
• Sürekli log yerine NetFlow/Telemetry/SIEM korelasyonu kullanın.
• Spike anında geçici logging açın.
• Syslog seviyesini ve hedefini doğru ayarlayın.
• Mümkünse platformun rate-limit veya logging interval özelliklerini kullanın.

Operasyonel yaklaşım

Normal durum: Kritik deny log açık
İnceleme durumu: Geçici detaylı log açık
Sorun çözüldükten sonra: Gürültülü log kapalı

---

5️⃣ TCAM ve Hardware Kaynaklarını İzleyin

Switch ve router platformlarında ACL’ler çoğu zaman donanım kaynaklarına programlanır. Bu kaynaklar sınırsız değildir.

TCAM dolarsa şu problemler görülebilir:

• ACL donanıma tam yazılamayabilir.
• Trafik software path’e düşebilir.
• CPU artabilir.
• Yeni policy uygulanamayabilir.
• Beklenmeyen forwarding davranışı oluşabilir.

Kontrol komutları

Platforma göre değişmekle birlikte aşağıdaki komutlar kullanılabilir:

show access-lists
show ip access-lists
show platform hardware fed switch active fwd-asic resource tcam utilization
show platform tcam utilization
show platform hardware acl usage

Ne yapılmalı?

• Çok uzun ACL’leri sadeleştirin.
• Tekrarlı ACE’leri birleştirin.
• Object-group desteğini değerlendirin.
• Gereksiz log satırlarını azaltın.
• ACL’yi doğru cihaz rolüne taşıyın.
• Firewall görevi router’a yükleniyorsa mimariyi gözden geçirin.
• VRF veya zone bazlı tasarımla kapsamı daraltın.

---

6️⃣ Stateful Gereksinim Varsa Router ACL ile Firewall’u Karıştırmayın

Klasik ACL’ler çoğunlukla stateless çalışır. Yani tek başına bağlantı durumunu uygulama katmanına kadar takip etmez.

Bu nedenle şu soru önemlidir:

Burada sadece basit packet filtering mi gerekiyor,
yoksa stateful inspection mı gerekiyor?

Stateless ACL için uygun örnekler

• Management erişimini sınırlama
• Belirli subnet’ten belirli servise izin verme
• Anti-spoofing
• Basit inbound/outbound filtreleme
• Routing domain ayrımı

Stateful kontrol gereken örnekler

• İnternet çıkışı ve dönüş trafiği
• Kullanıcı uygulama kontrolü
• Dinamik port kullanan uygulamalar
• Layer 7 inspection
• NAT + session tracking
• UTM/IPS ihtiyacı

Bu durumda firewall, zone-based firewall veya platform destekliyorsa reflexive ACL gibi özellikler değerlendirilmelidir.

Reflexive ACL konsepti

Reflexive ACL, içeriden başlatılan bağlantılar için dönüş trafiğine geçici izin oluşturabilir.

ip access-list extended OUTBOUND
 permit tcp any any reflect REFLECT_TRAFFIC
 permit udp any any reflect REFLECT_TRAFFIC

ip access-list extended INBOUND
 evaluate REFLECT_TRAFFIC
 deny ip any any log

Not

Reflexive ACL modern firewall’un yerine geçmez. Basit stateful dönüş trafiği kontrolü için kullanılabilir; ancak uygulama bazlı güvenlik, IPS, URL filtering veya gelişmiş tehdit kontrolü gerekiyorsa firewall kullanılmalıdır.

---

7️⃣ Test, Canary Rule ve Versioning Kullanın

Büyük ACL değişiklikleri yüksek risklidir. Tek seferde geniş ACL değişikliği yapmak yerine kontrollü geçiş yapılmalıdır.

Güvenli değişiklik modeli

1. Mevcut ACL yedeğini alın.
2. Hit-count ve log analizi yapın.
3. Yeni kuralı küçük scope ile test edin.
4. Canary subnet veya test host kullanın.
5. Değişiklik sonrası logları izleyin.
6. Rollback komutunu hazır tutun.
7. Konfigürasyon diff kaydını saklayın.

Versiyonlama önerisi

ACL değişikliklerini Git benzeri bir repoda takip etmek büyük avantaj sağlar.

Örnek kayıt standardı:

[ACL=INTERNET_IN][OWN=Network][REQ=CHG-456][DATE=2026-06-16][WHY=Payment API restriction]

---

⚠️ Kötü → ✅ İyi Örnek

Kötü ACL

ip access-list extended INTERNET_IN
 permit ip any any
 deny ip any any log

Sorunlar:

• Fazla geniş izin
• Alttaki deny etkisiz
• Uygulama/servis ayrımı yok
• Denetlenebilirlik zayıf
• Gereksiz risk üretir

---

İyi ACL

ip access-list extended INTERNET_IN
 remark [OWN=Network][REQ=CHG-123][WHY=Public HTTPS access]
 permit tcp any host 10.10.10.10 eq 443
 permit tcp any host 10.10.10.11 eq 443
 deny ip any any log

Daha iyi yaklaşım:

• Spesifik hedef
• Spesifik servis
• Açıklama mevcut
• Cleanup deny en altta
• Log kontrollü şekilde kullanılıyor

---

Doğrulama ve Troubleshooting Komutları

show access-lists INTERNET_IN
show ip access-lists INTERNET_IN
show ip interface GigabitEthernet1/0/1 | include access
show running-config interface GigabitEthernet1/0/1
show logging | include ACL
show platform hardware fed switch active fwd-asic resource tcam utilization

Dikkat

debug ip packet detail

Bu komut üretim ortamında çok dikkatli kullanılmalıdır. Yüksek trafikte CPU’yu ciddi şekilde etkileyebilir. Kısa süreli, filtreli ve kontrollü kullanılmalıdır.

---

48s Mini-PoC Planı

1. En uzun 3 ACL’yi listeleyin.
2. Her ACL için hit-count ve log yoğunluğunu kontrol edin.
3. permit ip any any, service:any, gereksiz log satırlarını ayırın.
4. Tekrarlı IP/port satırlarını object-group veya sadeleştirme adayı yapın.
5. TCAM kullanımını kontrol edin.
6. En risksiz ACL’de 1 küçük optimizasyon uygulayın.
7. Değişiklik sonrası trafik, hit-count ve syslog durumunu izleyin.
8. Rollback planını doğrulayın.

---

Sonuç

ACL optimizasyonu sadece birkaç satır konfigürasyon temizliği değildir. Doğru ACL tasarımı; cihaz performansını korur, TCAM tüketimini azaltır, log gürültüsünü düşürür ve güvenlik politikasını daha okunabilir hale getirir.

En iyi ACL, en uzun olan değil; en net iş ihtiyacını en az satırla, doğru sırayla ve denetlenebilir şekilde karşılayan ACL’dir.

---