FortiGate Proxy-Based Web Filter: Belirli Domainler Neden Bloklanmıyor?

01 / PROBLEM

Problem

FortiGate üzerinde Static URL Filter kullanılarak belirli domainlerin engellenmesi hedefleniyordu.

Proxy-Based inspection kullanılan policy üzerinde belirli domain girdileri beklenen şekilde bloklanmıyordu. Buna karşılık URL Filter tablosuna genel * girdisi eklendiğinde tüm web erişimi başarıyla engelleniyordu.

Aynı hedef domain Flow-Based inspection kullanılan ayrı bir test policy'sinde ise bloklanıyordu.

Bu nedenle problem ilk aşamada URL Filter mekanizmasının tamamen çalışmamasından çok, Proxy-Based inspection sırasında belirli pattern'lerin nasıl işlendiği yönünde daraltıldı.

02 / ORTAM VE BELIRTI

Ortam ve Belirti

İncelenen akışta şu bileşenler bulunuyordu:

• FortiGate
• Proxy-Based inspection
• SSL Deep Inspection
• Web Filter
• Static URL Filter
• HTTPS web trafiği

Örnek test davranışı:

Bu karşılaştırma, policy ve Web Filter profilinin tamamen devre dışı olmadığını gösterdi.

03 / İLK ANALIZ

İlk Analiz

Troubleshooting sırasında sırasıyla şu kontroller yapıldı:

1. 01

   İstemcinin doğru firewall policy üzerinden geçtiği doğrulandı.

2. 02

   Policy üzerinde doğru Web Filter profilinin bağlı olduğu kontrol edildi.

3. 03

   Static URL Filter tablosu ve Block aksiyonu doğrulandı.

4. 04

   Genel * kuralıyla Web Filter mekanizmasının çalıştığı test edildi.

5. 05

   Aynı domain ayrı bir Flow-Based test policy'sinde denendi.

6. 06

   Proxy tarafındaki davranışı görmek için WAD debug çıktıları incelendi.

04 / WAD DEBUG

WAD Debug

İlk incelemede Proxy-Based trafik için WAD debug kullanıldı:

diagnose debug reset
diagnose debug console timestamp enable
diagnose debug application wad -1
diagnose debug enable

Test tamamlandıktan sonra debug kapatıldı:

diagnose debug disable

HTTPS bağlantısına ait SNI bilgisinin WAD tarafından görülebildiği gözlemlenmesine rağmen beklenen Static URL Filter eşleşmesi gerçekleşmiyordu.

Bu noktadan sonra debug kayıtları üretici mühendislik ekibine iletildi.

05 / MÜHENDISLIK BULGUSU

Mühendislik Bulgusu

Üretici mühendislik ekibinin incelemesinde Hyperscan regex database compile hataları görüldü.

İki farklı hata tipi tespit edildi.

1. Geçersiz UTF-8 içeren regex

Debug çıktısında şu hata görülüyordu:

Regex compile failed: Expression is not valid UTF-8.

İlgili pattern içerisinde bir tırnak karakterinden önce gereksiz bir \ escape karakteri bulunuyordu. Mühendislik ekibi bu escape karakterinin kaldırılmasıyla ifadenin düzeldiğini bildirdi.

Buradaki önemli nokta, URL Filter tablosunda yalnızca görünüş olarak doğru duran bir regex'in bulunmasının yeterli olmamasıdır. Pattern, WAD tarafından kullanılan regex engine tarafından da başarıyla compile edilebilmelidir.

2. Hatalı end-anchor kullanımı

İkinci regex şu yapıya sahipti:

(^/)test($//)

Mühendislik ekibinin önerdiği doğru ifade:

(^/)test$

Buradaki $ bir end anchor olarak kullanılır. $ sonrasında tekrar karakter tanımlanması regex derleyicisinde:

Embedded end anchors not supported.

hatasına neden oluyordu.

06 / CONFIRMED ROOT CAUSE

Confirmed Root Cause

Bu vaka için root cause artık doğrulandı:

Proxy-Based Web Filter tarafından kullanılan WAD/Hyperscan regex veritabanında geçersiz regex girdileri bulunuyordu. Bu girdiler Hyperscan compile hataları oluşturuyor ve belirli Static URL Filter pattern'lerinin beklenen şekilde işlenmesini engelliyordu.

Tespit edilen hata tipleri:

• Geçersiz UTF-8 oluşturan hatalı escape kullanımı
• $ end-anchor sonrasında karakter bulunan geçersiz regex yapısı

07 / ÇÖZÜM

Çözüm

Sorunun kalıcı çözümü hatalı regex girdilerinin düzeltilmesi oldu.

Önerilen işlem sırası:

Static URL Filter regex'lerini gözden geçir
        ↓
Hyperscan compile error üreten pattern'i bul
        ↓
Geçersiz escape / anchor kullanımını düzelt
        ↓
WAD'ı kontrollü şekilde yeniden başlat
        ↓
Compile çıktısını tekrar kontrol et
        ↓
Proxy-Based policy üzerinden yeniden test et

Mühendislik ekibi ek geçersiz regex bulunup bulunmadığını kontrol etmek için aşağıdaki komutların kullanılmasını önerdi:

diag debug enable
diag test app wad 99
diag test app wad 2300
diag test app wad 1512

Kontrol tamamlandıktan sonra açık debug oturumu kapatılmalıdır.

diagnose debug disable

08 / WORKAROUND NE OLDU?

Workaround Ne Oldu?

İlk troubleshooting aşamasında Flow-Based inspection aynı domaini başarıyla blokladığı için geçici workaround olarak kullanılabiliyordu.

Ancak root cause doğrulanıp geçersiz regex girdileri düzeltildikten sonra problem Proxy-Based inspection tarafında da giderildi.

Bu nedenle Flow-Based yaklaşımı artık kalıcı çözüm değil, troubleshooting sırasında kullanılan geçici karşılaştırma/workaround olarak değerlendirilmelidir.

09 / DOĞRULAMA

Doğrulama

Regex hataları düzeltildikten sonra hedef domain Proxy-Based inspection kullanılan policy üzerinden yeniden test edildi.

Beklenen davranış sağlandı:

Client Request
     ↓
Proxy-Based Policy
     ↓
WAD / Web Filter
     ↓
Valid Regex Match
     ↓
BLOCK

Vakanın çözüldüğü doğrulandı.

10 / BENZER BIR VAKADA KONTROL LISTESI

Benzer Bir Vakada Kontrol Listesi

11 / BU VAKADAN ÇIKAN DERS

Bu Vakadan Çıkan Ders

İlk bakışta problem Proxy-Based inspection veya Static URL Filter'ın kendisinde bir yazılım hatası gibi görünüyordu.

Gerçek neden ise URL Filter tablosundaki geçersiz regex girdilerinin Hyperscan tarafından compile edilememesiydi.

Bu vaka özellikle şu noktayı gösteriyor:

Bir regex'in GUI veya CLI üzerinde kayıtlı olması, o regex'in arka plandaki matching engine tarafından başarıyla derlendiği anlamına gelmez.

Proxy-Based filtering problemi araştırılırken yalnızca policy, SSL inspection ve domain syntax kontrolü değil, WAD/Hyperscan compile durumu da inceleme kapsamına alınmalıdır.

12 / SONUÇ

Sonuç

FortiGate Proxy-Based Web Filter altında belirli domainlerin bloklanmaması, bu vakada Proxy-Based inspection'ın genel bir limitation'ından kaynaklanmıyordu.

Root cause, Static URL Filter içerisindeki geçersiz regex ifadelerinin WAD/Hyperscan tarafında compile hatası oluşturmasıydı.

Regex ifadeleri düzeltilip WAD tarafı tekrar kontrol edildiğinde Proxy-Based domain blocking beklenen şekilde çalıştı.