ACL Nedir? Standart ve Genişletilmiş ACL, Kural Sırası ve Gerçek Ağ Senaryoları

“ACL’yi yazdık, arayüze uyguladık ama trafik hâlâ geçiyor.” Ya da tam tersi: “Tek bir satır ekledik, bütün VLAN’ın interneti gitti.” İkisinde de sorun çoğu zaman ACL’nin kendisi değil; kural sırası, uygulama yönü ya da listenin sonunda ne olduğunun yanlış bilinmesidir.

Bu yazıda ACL’yi tek bir kampüs senaryosu üzerinden anlatacağız: nasıl değerlendirildiğini, nereye uygulandığını, üreticiden üreticiye neyin değiştiğini ve çalışmadığında nasıl teşhis edileceğini.

Senaryo

Yazı boyunca aynı ağı kullanacağız. VLAN’lar arası yönlendirme bir L3 switch üzerinde, SVI’larla yapılıyor.

Hedef:

• Personel muhasebe ağına erişemesin.
• Personel sunucu ağında yalnızca intranete (TCP 443) ve DNS’e (UDP/TCP 53) erişebilsin; diğer sunucu portları kapalı kalsın.
• Personelin internet erişimi ve DHCP ile adres alması bozulmasın.

ACL ne yapar, ne yapmaz

ACL, paketleri başlık bilgilerine göre (kaynak ve hedef adres, protokol, port) sınıflandıran sıralı bir kural listesidir. Tek başına bir şey yapmaz; bir özelliğe bağlandığında anlam kazanır. Aynı ACL bir arayüzde trafik filtrelemek için, başka bir yerde NAT’a girecek trafiği seçmek, QoS sınıfı belirlemek ya da yönetim erişimini kısıtlamak için kullanılabilir.

Trafik filtrelemede bilinmesi gereken en önemli nokta: klasik ACL durum (state) tutmaz. Her paketi diğerlerinden bağımsız değerlendirir; bir bağlantıyı hangi tarafın başlattığını bilmez. Bu yüzden ACL bir firewall’un yerini tutmaz. Bağlantı takibi yapan stateful denetimi stateful firewall yazısında anlattık.

ACL’nin yeri, kaba ve hızlı filtrelemedir: L3 switch üzerinde segmentler arası temel kısıtlamalar, yönetim erişiminin sınırlanması, bir arayüzde istenmeyen trafiğin erken düşürülmesi. Switch’lerde ACL’ler donanımda (TCAM) işlendiği için hat hızında çalışır ama kural sayısı donanım kaynağıyla sınırlıdır.

Standart ve genişletilmiş ACL

Bu ayrım Cisco ve Huawei’de benzer ama terimler ve numara aralıkları farklıdır. Aruba CX ve FortiSwitch ise ACL’yi bu iki sınıfa ayırmaz; onları aşağıda kendi mantıklarıyla anlatıyoruz.

Standart ACL yalnızca kaynağa baktığı için kaba bir araçtır. En doğal kullanımı, yönetim erişimini belirli bir ağa sınırlamaktır. Segmentler arası trafik filtrelemede neredeyse her zaman genişletilmiş ACL gerekir; çünkü “kimden”in yanında “nereye” ve “hangi servis” de belirleyicidir.

HPE Aruba Networking CX: AOS-CX’te ACL türleri IPv4, IPv6 ve MAC’tir. Standart/genişletilmiş ayrımı yoktur; her IPv4 kuralı (ACE) kaynak, hedef, protokol ve port alanlarının istenen kadarını kullanabilir. Kurallara sıra numarası verilir; numara yazılmazsa 10’dan başlar ve 10’ar artar.

FortiSwitch: FortiSwitchOS’ta ACL, işleme hattının üç aşamasına (prelookup, ingress, egress) yazılan politikalardır; bazı modellerde yalnızca ingress aşaması vardır. Her politika bir sınıflandırıcı (VLAN, MAC, IP öneki, servis, DSCP gibi alanlar) ve bir eylem (drop, count, yönlendirme, ayna, policer gibi) içerir. Yani bir “izin listesi” değil, eşleşen trafiğe eylem uygulayan bir kural kümesidir. Bunu FortiGate’in firewall policy’siyle karıştırmamak gerekir: FortiGate politikaları stateful çalışır ve ayrı bir mekanizmadır.

Kural sırası: ilk eşleşme kazanır

Klasik sıralı ACL’lerde (Cisco, Huawei, Aruba CX) kurallar yukarıdan aşağıya, numara sırasıyla değerlendirilir. Paket bir kurala uyduğu anda o kuralın eylemi uygulanır ve kalan kurallara bakılmaz.

Bunun iki pratik sonucu var:

• Özel kural genel kuraldan önce gelir. permit ip 10.0.20.0/24 any gibi geniş bir satır listenin başındaysa, altına yazılan bütün deny satırları hiç çalışmaz. Bu duruma “gölgelenmiş kural” denir ve sayaçlarda sıfırda kalan satırlar genellikle bunun işaretidir.
• Araya ekleme için boşluk bırakın. Kuralları 10, 20, 30 diye numaralandırmak, sonradan 15’e yeni bir satır eklemeyi mümkün kılar. Numarasız eklenen satırlar listenin sonuna gider.

Huawei’de bir ayrıntı daha var: ACL’nin eşleşme sırası varsayılan olarak config’tir, yani kural numarası sırası. auto seçilirse cihaz kuralları kendi derinlik önceliğine göre sıralar. Bu yazıdaki örnekler varsayılan config sırasını kullanır.

FortiSwitch bu modele birebir oturmaz. ACL politikaları farklı işleme aşamalarında (prelookup, ingress, egress) ve gruplar hâlinde tanımlanır, donanımda (TCAM) ayrılan önceliklere göre işlenir. Bu yüzden “tek liste, ilk eşleşen kazanır” anlatımı FortiSwitch için doğrudan geçerli değildir; politikaların hangi aşamada ve hangi grupta olduğu da sonucu belirler.

Listenin sonunda ne var? Varsayılan davranış üreticiye göre değişir

ACL anlatımlarında en sık tekrarlanan cümle “her ACL’nin sonunda görünmeyen bir deny any vardır” cümlesidir. Bu Cisco için doğrudur, ama her üretici ve her uygulama için değil. Yanlış varsayım gerçek ağlarda açık bırakılmış servisler demektir.

Huawei’de yönetim servislerine bağlanan ACL’ler için tek bir cümle yeterli değildir. Huawei’nin servis bazlı açıklaması üç durumu ayırır: ACL hiç tanımlanmamış, ACL tanımlı ama içinde kural yok, ya da ACL’de kurallar var ama paket hiçbirine uymuyor. Sonuç bu üç durum arasında ve servisten servise (örneğin VTY ile SNMP arasında) farklıdır. Bir yönetim servisine ACL bağlamadan önce, o servisin bu üç durumdaki davranışını Huawei’nin tablosundan kontrol edin; VTY için geçerli olanın SNMP için de geçerli olduğunu varsaymayın.

traffic-filter satırı ise en çok hata yapılan yerdir. Cisco alışkanlığıyla yalnızca izin verilecekleri yazıp “geri kalanı zaten düşer” diye düşünen biri, traffic-filter ile uygulanan bir ACL’de geri kalan her şeyi açık bırakmış olur. Kural basit: engellemek istediğiniz trafiği her platformda açık bir deny satırıyla yazın. Hem davranış üreticiden bağımsız hâle gelir hem de bu satırın sayacı, engellenen trafiği görmenizi sağlar.

Wildcard mask ve adres yazımı

Cisco ve Huawei, ACL’de ağ belirtirken subnet mask yerine wildcard mask kullanır. Wildcard’da 0 “bu bit eşleşmeli”, 1 “bu bit önemsiz” demektir. Bitişik bir ağ için wildcard, subnet mask’ın tersidir:

255.255.255.255
255.255.255.0     (/24 subnet mask)
---------------
  0.  0.  0.255   (wildcard)

Yani 10.0.20.0 0.0.0.255, 10.0.20.0/24 ağının tamamını; 10.0.30.10 0.0.0.0 yalnızca tek bir adresi ifade eder. Cisco’da tek adres için host 10.0.30.10 da yazılabilir, Huawei’de 10.0.30.10 0 yeterlidir.

Her üretici aynı sözdizimini kullanmaz:

Cisco konfigürasyonunu Aruba ya da FortiSwitch’e taşırken en sık yapılan hata, wildcard’ı olduğu gibi kopyalamaktır. 0.0.0.255’i subnet mask yerine yazmak, hedeflenenle hiç ilgisi olmayan bir eşleşme üretir.

ACL nereye ve hangi yönde uygulanır

Bir ACL’yi uygularken üç şeye karar verilir: hangi arayüz veya VLAN, hangi yön ve hangi özellik.

• Inbound (ingress): Trafik arayüze girerken, cihaz yönlendirme kararı vermeden önce değerlendirilir. İstenmeyen trafik en erken noktada düşer.
• Outbound (egress): Trafik arayüzden çıkarken değerlendirilir. O arayüze hangi kaynaktan gelirse gelsin, giden trafiğin hepsi etkilenir.

Klasik kural şudur: genişletilmiş ACL kaynağa yakın, standart ACL hedefe yakın uygulanır. Genişletilmiş ACL hedefi de bildiği için, trafiği daha ağın içinde dolaşmadan kaynağında durdurabilir. Standart ACL yalnızca kaynağa baktığından, kaynağa yakın uygulanırsa o kaynağın her yere giden trafiğini keser; bu yüzden hedefe yakın konur.

Senaryomuzda kısıtlanan taraf personel olduğu için ACL’yi VLAN 20’nin girişine, inbound uyguluyoruz. Böylece personelden çıkan her akış, L3 switch’te yönlendirilmeden önce tek bir listeyle denetlenir.

Alternatif, muhasebeyi korumak için VLAN 10 SVI’sına outbound bir ACL yazmaktır. Bu, muhasebeye hangi segmentten gelirse gelsin bütün trafiği tek yerde denetler; ama personelin sunucu erişimini ayrıca ele almak gerekir. Hangisinin seçileceği, politikanın “kimin ne yapabileceği” mi yoksa “neyin kimden korunacağı” üzerine mi kurulduğuna bağlıdır.

Senaryonun konfigürasyonu

Cisco, Huawei ve Aruba CX’te aynı politikayı yazıyoruz; FortiSwitch’te neyin farklı olduğunu kendi başlığında anlatıyoruz. Örnekler, yazının başında belirtilen sürümlerin resmî dokümantasyonundaki sözdizimine göre hazırlandı; üretim ortamına almadan önce kendi sürümünüzde ve laboratuvarda deneyin.

Politikanın sırası:

1. DHCP isteklerine izin ver.
2. Personelden muhasebeye giden her şeyi açıkça engelle.
3. İntranet (TCP 443) ve DNS’e (UDP/TCP 53) izin ver.
4. Sunucu ağının geri kalanını açıkça engelle.
5. Personelin geri kalan trafiğine (internet) izin ver.

İlk satırın neden gerekli olduğu sık atlanır. DHCP ile adres almaya çalışan bir istemcinin ilk paketi kaynak adresi 0.0.0.0, hedefi 255.255.255.255 olan bir yayındır. L3 switch DHCP relay yapıyorsa bu paket SVI’ya ulaşır. Cisco’nun dokümantasyonuna göre L3 arayüzdeki ACL, yönlendirilen paketlerin yanında cihazın kendi L3 süreçlerine gelen paketleri de filtreler. Kaynağı 10.0.20.0/24 olmayan bu paket hiçbir izin satırına uymaz ve implicit deny’a takılır: istemci adres alamaz. Bu yüzden DHCP satırı listenin başında durur.

Cisco IOS XE (Catalyst 9300)

ip access-list extended PERSONEL-IN
 10 permit udp any any eq bootps
 20 deny   ip 10.0.20.0 0.0.0.255 10.0.10.0 0.0.0.255
 30 permit tcp 10.0.20.0 0.0.0.255 host 10.0.30.10 eq 443
 40 permit udp 10.0.20.0 0.0.0.255 host 10.0.30.11 eq domain
 50 permit tcp 10.0.20.0 0.0.0.255 host 10.0.30.11 eq domain
 60 deny   ip 10.0.20.0 0.0.0.255 10.0.30.0 0.0.0.255
 70 permit ip 10.0.20.0 0.0.0.255 any
!
interface Vlan20
 ip access-group PERSONEL-IN in

Bu bir router ACL’dir: SVI’ya uygulandığı için VLAN’lar arasında yönlendirilen trafiği filtreler, aynı VLAN içinde L2’de anahtarlanan trafiği etkilemez. Personel bilgisayarları arasındaki trafiği de kısıtlamak gerekirse VLAN map (VACL) ya da port ACL ayrı bir konudur.

Huawei S serisi

Örnek, S1720/S2700/S5700/S6720 V200R011C10 dokümantasyonuna göre yazıldı. Güncel S serisi modellerin ve sürümlerin tamamını temsil etmez; komutları kendi modelinizin ve sürümünüzün komut referansıyla karşılaştırın.

Huawei’de ACL’yi bir VLAN’a traffic-filter ile uyguluyoruz. Listenin sonunda eşleşmeyen trafik iletildiği için 60 numaralı deny satırı burada zorunludur; yazılmazsa sunucu ağının diğer portları açık kalır.

acl number 3020
 rule 10 permit udp destination-port eq 67
 rule 20 deny ip source 10.0.20.0 0.0.0.255 destination 10.0.10.0 0.0.0.255
 rule 30 permit tcp source 10.0.20.0 0.0.0.255 destination 10.0.30.10 0 destination-port eq 443
 rule 40 permit udp source 10.0.20.0 0.0.0.255 destination 10.0.30.11 0 destination-port eq 53
 rule 50 permit tcp source 10.0.20.0 0.0.0.255 destination 10.0.30.11 0 destination-port eq 53
 rule 60 deny ip source 10.0.20.0 0.0.0.255 destination 10.0.30.0 0.0.0.255
 rule 70 permit ip source 10.0.20.0 0.0.0.255
#
traffic-filter vlan 20 inbound acl 3020

Bu örnek Cisco’dakinden farklı bir noktada çalışır. Cisco ACL’si SVI’ya bağlı olduğu için yalnızca yönlendirilen trafiği görür; VLAN’a uygulanan traffic-filter ise VLAN 20’ye giren trafiğin tamamına, VLAN içinde L2’de anahtarlanan trafik dahil, işler. Son satır permit ip source 10.0.20.0 0.0.0.255 olduğu için personel bilgisayarları arasındaki trafik etkilenmez; bu satırı daraltırsanız VLAN içi iletişimi de kısıtlamış olursunuz.

HPE Aruba Networking CX (AOS-CX 10.13)

AOS-CX’te ACL bir VLAN’a, bir arayüze ya da SVI’ya (interface vlan) uygulanabilir. Burada VLAN’a uyguluyoruz. Sayacını görmek istediğiniz satırlara count ekleyin; hit count yalnızca bu satırlar için tutulur.

access-list ip PERSONEL-IN
    10 permit udp any any eq 67
    20 deny any 10.0.20.0/24 10.0.10.0/24 count
    30 permit tcp 10.0.20.0/24 10.0.30.10 eq 443 count
    40 permit udp 10.0.20.0/24 10.0.30.11 eq 53
    50 permit tcp 10.0.20.0/24 10.0.30.11 eq 53
    60 deny any 10.0.20.0/24 10.0.30.0/24 count
    70 permit any 10.0.20.0/24 any
vlan 20
    apply access-list ip PERSONEL-IN in

VLAN’a uygulanan ACL, VLAN içi trafiği de görür; 70 numaralı satır bu yüzden personel kendi arasında konuşabilsin diye gereklidir. Yalnızca yönlendirilen trafiği filtrelemek isterseniz ACL interface vlan 20 altında routed-in yönüyle uygulanır.

FortiSwitch

FortiSwitch’te iki durum var. FortiSwitch tek başına yönetiliyorsa ACL switch’in kendi CLI’ında config switch acl ile yazılır. FortiGate’e FortiLink ile bağlı ve FortiGate’ten yönetiliyorsa bu komut desteklenmez; ACL FortiGate üzerinde config switch-controller acl ile tanımlanıp yönetilen switch portlarına bağlanır (FortiOS 7.4 ve FortiSwitchOS 7.4 ile).

FortiSwitch ACL’leri eşleşen trafiğe eylem uygulayan politikalar olduğu için senaryoyu “kısıtlanacak akışları düşür” mantığıyla yazıyoruz. FortiLink ile yönetilen bir switch için örnek:

config switch-controller acl ingress
    edit 20
        config classifier
            set src-ip-prefix 10.0.20.0 255.255.255.0
            set dst-ip-prefix 10.0.10.0 255.255.255.0
        end
        config action
            set drop enable
            set count enable
        end
    next
end
config switch-controller acl group
    edit "PERSONEL-IN"
        set ingress 20
    next
end
config switch-controller managed-switch
    edit "<FortiSwitch seri no>"
        config ports
            edit "port10"
                set acl-group "PERSONEL-IN"
            next
        end
    next
end

FortiOS 7.4.0 dokümantasyonuna göre bu sınıflandırıcı IP öneki, MAC ve VLAN alanlarıyla eşleşir; port numarası alanı yoktur. Bu yüzden “sunucu ağında yalnızca 443 ve 53 açık” gibi port bazlı bir politika FortiLink ACL’siyle tam olarak yazılamaz. Fortinet mimarisinde bu tür segmentler arası, port bazlı kural genellikle VLAN’lar arası trafiğin FortiGate’ten geçirilmesiyle stateful firewall policy olarak yazılır. Tek başına yönetilen FortiSwitch’in config switch acl sınıflandırıcısı ise servis alanını da destekler.

Bu örnekle ilgili üç sınırlama:

• Yalnızca bağlandığı portu korur. ACL grubu yönetilen switch’in portlarına tek tek bağlanır. Örnekteki kural sadece port10’dan giren trafiğe uygulanır; VLAN 20’deki diğer erişim portlarına otomatik uygulanmaz. Personelin bağlandığı her port için acl-group ayrıca tanımlanmalıdır.
• Model desteği gerekir. FortiLink ile kullanıcı tanımlı ACL, switch’te ACL grup 3 desteği ister; bu desteği olmayan modellerde kullanılamaz.
• İç ACL’lerle çakışabilir. FortiSwitch’in başka özellikler için kendi oluşturduğu ACL’ler, kullanıcı tanımlı kurallarla çakışabilir ya da onları geçersiz kılabilir. Fortinet, kullanıcı ACL’lerinin açık olan diğer özelliklerle birlikte doğrulanmasını öneriyor.

Dönüş trafiği: established ve reflexive ACL

ACL durum tutmadığı için dönüş trafiği ayrıca düşünülmelidir. Senaryomuzda personelin intranete giden isteği VLAN 20’nin girişinde denetlenir; sunucunun yanıtı VLAN 20’den çıkarken bir ACL’ye takılmadığı için sorun yoktur.

Sorun ters yönde başlar. Muhasebedeki bir kullanıcı personeldeki bir bilgisayara uzak masaüstüyle bağlanmak isterse, bağlantının dönüş paketleri personelden muhasebeye gider ve 20 numaralı deny satırına takılır. Bağlantı kurulmaz.

Cisco ve Aruba CX’teki established anahtar kelimesi bunun için kullanılabilir:

ip access-list extended PERSONEL-IN
 15 permit tcp 10.0.20.0 0.0.0.255 10.0.10.0 0.0.0.255 established

Bu satır, muhasebeden başlatılmış TCP bağlantılarının dönüş paketlerine izin verir; personelin muhasebeye yeni bağlantı açmasına izin vermez. Ama bu stateful denetim değildir. Cisco dokümantasyonunun tanımıyla established, ACK veya RST bayrağı taşıyan paketlerle eşleşir. Cihaz böyle bir bağlantının gerçekten var olup olmadığını kontrol etmez; bayrakları elle ayarlanmış bir paket de bu satırdan geçer. Ayrıca yalnızca TCP için çalışır.

İleri seviye: reflexive ACL

Reflexive ACL bir adım daha ileri gider: giden bir oturum görüldüğünde, dönüş trafiği için kaynak, hedef ve port bilgisiyle geçici bir kural oluşturur; oturum bitince kural silinir. TCP dışında UDP için de çalışır.

Ama her platformda yoktur ve sınırlamaları vardır. Cisco Catalyst 9300’de reflexive ACL desteği IOS XE 17.10 ile ayrı bir özellik olarak geldi; daha eski sürümlerin ACL dokümantasyonunda desteklenmediği yazar. Desteklendiği sürümlerde de yalnızca L3 arayüzlerde ve isimli extended ACL içinde tanımlanabilir, aktif mod FTP gibi dönüş portu değişen uygulamalarda çalışmaz. Gerçek oturum takibi gerekiyorsa doğru araç genellikle bir firewall’dur.

Yönetim erişimini ACL ile kısıtlamak

Standart ACL’nin en doğal kullanımı budur: switch’e SSH ile yalnızca yönetim ağından bağlanılabilsin.

Cisco IOS XE:

ip access-list standard YONETIM
 10 permit 10.0.99.0 0.0.0.255
!
line vty 0 15
 access-class YONETIM in

Huawei:

acl number 2099
 rule 10 permit source 10.0.99.0 0.0.0.255
#
user-interface vty 0 4
 acl 2099 inbound

İki ayrıntıya dikkat:

• VTY aralığı: user-interface vty 0 4 yalnızca bu aralıktaki oturumları kapsar. Cihazda kaç VTY olduğu modele ve sürüme göre değişir; ACL’yi cihazdaki bütün VTY’lere uyguladığınızdan emin olun.
• ssh server acl: Huawei’de SSH için ayrıca servis seviyesinde ssh server acl 2099 komutu da vardır. VTY ACL’si, o VTY aralığına bağlanan oturumlara (Telnet ve SSH) uygulanır; ssh server acl ise doğrudan SSH sunucusuna gelen bağlantılara, yalnızca SSH için uygulanır. Hangisinin ya da ikisinin birlikte kullanılacağı cihazın desteğine ve yönetim politikasına bağlıdır.

ACL’de kurallar varken bu kuralların hiçbirine uymayan bir VTY bağlantısı kabul edilmez; traffic-filter’daki “eşleşmeyen iletilir” davranışını yönetim erişimine taşımayın. ACL’nin boş ya da tanımsız olduğu durumlar için yukarıda bahsettiğimiz servis tablosuna bakın. AOS-CX ve FortiSwitchOS’ta yönetim erişimi kendi mekanizmalarıyla kısıtlanır; ilke aynıdır, sözdizimi farklıdır.

Uzaktan bağlıyken yönetim ACL’si yazmak, kendinizi cihazdan kilitlemenin en kısa yoludur. İzin satırını uygulamadan önce bağlandığınız adresin listede olduğunu kontrol edin; mümkünse konsol erişimi hazır olsun.

Doğrulama ve sorun giderme

ACL’yi yazmak işin yarısıdır. Diğer yarısı, doğru yerde, doğru yönde çalıştığını ve hangi satırın neyi yakaladığını görmektir.

Doğrulama komutları

Cisco IOS XE:

show ip access-lists PERSONEL-IN
show running-config | section ip access-list extended PERSONEL-IN
show ip interface Vlan20
show platform software fed active acl counters hardware

show ip access-lists satır başına eşleşme sayısını gösterir. Catalyst 9000 serisinde dikkat: bu sayaçlar yazılım sayaçlarıdır ve donanımda işlenen paketleri içermeyebilir. Bir satırın sayacı sıfırda kalıyor diye trafiğin o satıra hiç uğramadığı sonucuna varmayın; donanım sayaçlarını show platform software fed active acl counters hardware ile kontrol edin. show ip interface Vlan20 ise ACL’nin SVI’ya hangi yönde bağlı olduğunu gösterir.

Huawei:

display acl 3020
display traffic-applied record
traffic-statistic vlan 20 inbound acl 3020
display traffic-statistics vlan 20 inbound acl 3020

display traffic-applied record ACL tabanlı basitleştirilmiş trafik politikalarının (traffic-filter dahil) nereye ve hangi yönde uygulandığını gösterir. Bu komutun adı S serisi sürümleri arasında değişebilir; V200R011C10 dokümantasyonu bu biçimi kullanır, kendi sürümünüzün komut referansını kontrol edin. Huawei’de eşleşme sayısını görmek için istatistiğin traffic-statistic ile ayrıca açılması gerekir.

Aruba AOS-CX:

show access-list ip PERSONEL-IN commands
show access-list vlan 20 ip
show access-list hitcounts ip PERSONEL-IN vlan 20

Hit count yalnızca count eklenmiş satırlar için tutulur.

FortiSwitch:

get switch acl counters ingress
diagnose switch-controller switch-info acl-counters <FortiSwitch seri no>

İlki tek başına yönetilen switch’te, ikincisi FortiLink ile yönetilen switch için FortiGate üzerinde çalışır. Sayaçlar yalnızca count eylemi açık politikalar için tutulur.

Sorun giderme sırası

ACL beklendiği gibi çalışmadığında şu sırayla ilerleyin:

1. ACL gerçekten uygulandı mı? Doğru arayüz veya VLAN, doğru yön. Tanımlanıp hiçbir yere bağlanmamış ACL, en sık rastlanan “çalışmıyor” nedenidir.
2. Trafik o noktadan geçiyor mu? Aynı VLAN içindeki iki cihaz SVI’ya uğramaz; router ACL’si bu trafiği görmez. Asimetrik yönlendirmede dönüş trafiği başka bir yoldan gelebilir.
3. Hangi satırın sayacı artıyor? Test trafiği üretin ve sayaçları izleyin. Beklenen satır yerine üstteki geniş bir satır artıyorsa kural gölgelenmiştir.
4. Listenin sonunda ne oluyor? Huawei traffic-filter’da eşleşmeyen trafik iletilir. “Engellenmesi gerekirken geçiyor” şikâyetinde ilk bakılacak yer, o trafiği yakalayan açık bir deny satırının olup olmadığıdır.
5. Dönüş trafiği hesaba katıldı mı? “Bir yönde çalışıyor, diğer yönde çalışmıyor” durumu çoğunlukla dönüş paketlerinin bir deny satırına takılmasıdır.
6. Donanım kaynağı yetti mi? Switch’lerde ACL’ler TCAM’e yazılır. Kaynak yetmediğinde ACL kısmen ya da hiç uygulanamayabilir; cihazın log’una ve kaynak kullanım komutlarına bakın.

Değişiklik yaparken: yeni satırı numarayla araya ekleyin, listeyi silip baştan yazmayın. Arayüze bağlı bir ACL’yi silip yeniden oluşturmak, aradaki sürede platforma göre ya her şeyin geçmesine ya da her şeyin düşmesine yol açabilir.

Sahada sık görülen hatalar

• Wildcard yerine subnet mask yazmak: Cisco ve Huawei’de 10.0.20.0 255.255.255.0 yazmak /24 ağını değil, bambaşka bir adres kümesini ifade eder.
• Geniş izni başa koymak: permit ip any any ya da kaynağın tamamına izin veren satır en üstteyse, altındaki bütün kısıtlamalar ölü kalır.
• Implicit deny’a güvenmek: Cisco alışkanlığını Huawei traffic-filter’a taşımak, engellenmesi gereken trafiği açık bırakır. Engellemeyi her zaman açık satırla yazın.
• DHCP, DNS ve yönlendirme protokollerini unutmak: Router ACL’si cihazın kendisine gelen trafiği de görür. Bir SVI’da OSPF komşuluğu ya da DHCP relay varsa, bu trafiğe izin verildiğinden emin olun.
• Yanlış yön: Inbound yazılması gereken ACL’yi outbound uygulamak, çoğu zaman hiçbir şeyi engellememek ya da beklenmedik bir şeyi engellemek demektir.
• ACL’yi firewall sanmak: established ve reflexive ACL bile gerçek oturum takibi değildir. Segmentler arası sıkı kontrol gerekiyorsa trafiği bir stateful politika noktasından geçirin.

Üretici yaklaşımları

Tablodaki “uygulama noktası” satırı, konfigürasyonları birebir karşılaştırırken atlanmaması gereken farktır. Cisco örneği SVI’da çalıştığı için aynı VLAN içindeki iki personel bilgisayarı arasındaki trafiği hiç görmez. Huawei ve Aruba örnekleri VLAN’a uygulandığı için bu trafiği de görür; son permit satırı bu yüzden zorunludur. Aruba’da yalnızca yönlendirilen trafiği filtrelemek istenirse ACL ayrı bir komutla, interface vlan 20 altında routed-in yönüyle uygulanır. Aynı politikayı farklı uygulama noktalarına taşırken satırların yanında bu kapsam farkını da hesaba katın.

Ortak nokta şu: ACL’ler her üreticide durumsuz ve donanımda işlenen kurallardır; Cisco, Huawei ve Aruba CX’te ayrıca sıralı bir liste olarak değerlendirilir, FortiSwitch’te ise aşama ve grup yapısı da işin içine girer. Farklılık, listenin sonunda ne olduğu, adresin nasıl yazıldığı ve ACL’nin hangi özelliğe bağlandığındadır. Bir üreticiden diğerine konfigürasyon taşırken satırları çevirmek yetmez; bu üç farkı da kontrol etmek gerekir.

Sonuç

ACL basit bir araçtır ama yanlış bilinen tek bir ayrıntı onu güvenlik açığına çevirebilir. Üç şeyi aklınızda tutun: sıralı ACL’lerde ilk eşleşen kural kazanır, listenin sonunda ne olduğu platforma bağlıdır ve ACL durum tutmaz.

Pratikte bunun anlamı: engellemek istediğinizi açık deny satırlarıyla yazın, satırlara numara boşluğu bırakın, uyguladıktan sonra sayaçlarla doğrulayın ve segmentler arası gerçek oturum kontrolü gereken yerde trafiği bir firewall’dan geçirin.

ACL’lerin hangi segmentler arasında kurulacağını belirlemek için önce akışları tanımlamak gerekir. Bunun yöntemini ağ segmentasyonu ve DMZ yazısında anlattık.

Kaynaklar

• Cisco: Security Configuration Guide, Cisco IOS XE Cupertino 17.9.x (Catalyst 9300), IPv4 ACLs
• Cisco: Configuring Reflexive Access Lists, IOS XE 17.10 (Catalyst 9300)
• Cisco: Validate Security ACLs on Catalyst 9000 Switches
• Huawei: Configuring a Basic ACL, S1720/S2700/S5700/S6720 V200R011C10 Configuration Guide - Security
• Huawei: How Can I Apply an ACL to a VLAN? (V200R011C10)
• Huawei: ACL-based Simplified Traffic Policy Commands (V200R011C10 Command Reference)
• Huawei: FAQ, How Are deny and permit in ACL Rules Used in Different Services
• HPE Aruba Networking: AOS-CX 10.13 ACLs and Classifier Policies Guide (6300, 6400, 8100, 8360)
• Fortinet: FortiSwitchOS 7.2.4 Administration Guide, Configuring an ACL policy
• Fortinet: FortiSwitch 7.4.0 FortiLink Guide, Configuring an ACL