Tuesday, March 18, 2008

Firewall Ar-Ge Çalışmaları – 1

Zemana AntiLogger’a ileriki versiyonlarında Firewall özelliğinin eklenebilmesi için yoğun bir şekilde ar-ge çalışmalarımızı sürdürüyoruz

Windows platformunda network paketlerini kontrol etmek için,
Ring3 (user)’ten Ring0 (kernel)’a kadar birçok alternatif metot bulunuyor ancak hepsi ayrı katmanlarda olduğundan birbirlerine göre eksileri ve artıları bulunmaktadır. Kısaca bu katmanların genel yolunu aşağıdaki şemayla ifade edebiliriz.








Bu katmanlarda, farklı özellik ve amaçlarla çalışabilecek teknolojiler Ring3’ten Ring0’a doğru aşağıdaki gibi sıralanır:.

Winsock Hook
Winsock Replacement DL
Winsock Layered Service Provider (LSP)
AFD WinSock Driver Hook
Filter-Hook Driver
Firewall-Hook Driver
Transport Data Interface (TDI) Filter Driver
Transport Data Interface (TDI) Hooking Driver
NDIS Intermediate (IM) Driver
NDIS Hooking Filter Driver
Windows Filtering Platform (WFP)


Desktop Firewall modülümüzü hangi katman ya da katmanlarda, hangi metotlarla geliştireceğimizi bulmak için ilk önce firewall’dan beklentilerimizi belirlememiz gerekiyor.

1. Diğer network tabanlı firewall, sniffer, proxy, router, network analiz vb. programlarla çakışmadan çalışabilmeli
2. Son kullanıcıları TCP/IP, Port, Subnet Mask gibi terimlerle karşılaştırmadan, uygulama tabanlı kurallar oluşturulabilmeli
3. Son modern tüm protokolleri ve cihazları desteklemeli (bluetooth, wifi vb.)
4. Fiziksel network donanımına en yakın katmanda kontrol yapabilmeli
5. Network trafiğini yavaşlatmayacak performansta olmalı
6. Microsoft’un, çekirdeğinde hayli değişiklik yaptığı Vista’yı desteklemeli
7. Kullanıcıya gereksiz uyarı vermemeli ve gereksiz sorular sormamalı
8. IPv6 protokolünü desteklemeli
9. ICMP ve DNS paketlerinin içeriğine ulaşabilmeli ve içeriği analiz edebilmeli. Bu analiz sonucunda içeriğin doğru amaç için kullanılıp, kullanılmadığını anlayarak, kullanıcının onayını almadan otomatik işlem yapabilmeli

Şu an için üzerinde çalıştığımız nokta; yukarıda saydığımız tüm özellikleri aynı teknolojiyi kullanarak, tek bir katmanda geliştirebilmek. Çünkü bu sayede her Windows dağıtımı için veya servis paketi için ayrı modüller yazılmasına gerek kalmayacak. Böylece hem yazılım ekibinin hem de ar-ge ekibinin işleri kolaylaşacak, test süreçleri kısalacak, hatalar azalacak ve versiyon güncellemeleri de kolaylaşacak.

Hangi Teknolojiyi Kullanmalı?
NDIS IM Driver; ilk bakışta yapısı, performansı ve güvenliği açısından en uygunu gibi gözüküyor. Ayrıca donanıma en yakın katman olduğu için tam bir kontrol sağlanabiliyor fakat bu katmanda network iletişimi yapan uygulama bilgilerine (process context) ulaşmak mümkün değil.

(TDI) Filter Driver; tcpip.sys tarafından kaydedilen IP, RawIP, TCP ve UDP protokollerinin üzerine bağlanan bir filtreleme arabirimidir. Çekirdekte neredeyse en üst katman olduğu için bu katmanda uygulama bilgilerine (process context), network adres ve paketlerine ulaşmak ve kontrol etmek çok kolaydır ancak, Windows başlangıcında NetBIOS (Port 137) ve SMB (Port 445) gibi alt seviyeli protokoller TDI Filter’den önce yüklendiği için bu protokolleri kontrol altına almak mümkün olmuyor.

Windows Filtering Platform (WFP) ise bütün isteklerimize cevap verebilecek bir filtreleme arabirimi ancak maalesef sadece Vista ve Server 2008’den sonraki Windows sürümleri için geliştirildi.

Firewall-Hook Driver da bütün isteklerimizi karşılayabilmesine rağmen, maalesef Vista ve daha ileri Windows sürümlerinde desteği durduruldu.

Gördüğünüz gibi, şu anda Microsoft tarafından desteklenen sadece 2 farklı çekirdek olması bile bu tip teknolojileri adapte etmek için ne kadar sorun yaratıyor. Bir de Linux’un yüzlerce sürümünü ve çekirdek yapısını düşünün! Bu yüzden, donanım geliştiricilerinin neden Windows'a oranla Linux için daha yavaş ve sorunlu sürücüler geliştirdiğini, akabinde Linux kullanıcılarının donanım sorunlarının arttığını ve buna bağlı olarak da Linux kullanma oranının neden düşük kaldığını anlayacaksınız.

Şu an, TDI Filter ya da Dispatch Table Hook ile çalışabilecek, NetBIOS ve SMB protokollerini kontrol altına alabilecek bir teknoloji üzerinde çalışıyoruz.

Diyelim ki, TDI ile NetBIOS protokollerini de kontrol etmeyi başardık. Peki; zararlı, direk NDIS protokolü ile iletişime geçerek, bizim TDI filtremizi bypass edebilir mi? Cevap: Evet, ancak birincisi; bu türde bir bağlantının çok karmaşık ve zor olması nedeniyle, şimdiye kadar internette bu tür bir zararlıya rastlanmadı. İkincisi; TDI Filter’i bypass etmek için zararlının kernel alanında çalışması gerekir ki böyle bir durumda dahili AntiLogger System-Defense modülü, çekirdek sürücüsü yükleme alarmı verecek ve bu girişimi engelleyecektir.

Eğer sadece TDI katmanı üzerine kurulu bir sistemde, NetBIOS protokolünü kontrol altına alamazsak, 2 katman kullanacağız. Birinci katman, uygulama bilgilerini toplayabileceğimiz LSP ya da TDI olacak. İkinci katman ise tam kontrolü alacağımız NDIS üzerine kurulu olacak.

Eğer birinci katmanda Ring3 LSP tabakasında çalışan bir filtreleme teknolojisi kullanırsak, bunun herhangi bir çekirdek sürücüsü yüklenmeden, Ring3’ten DeviceIoControl vasıtası ile IOCTL kontrol kodları gönderilerek bypass edilmesi mümkün ancak NDIS katmanında ikinci bir filtremiz olduğu için LSP’yi bypass eden tüm paketler engellenecektir.

Ar-ge hedefimiz, tek katmanda filtreleme yaparak firewall modülü oluşturmak olacak. Bunun için ilk saydığımız bazı özelliklerden fedakârlık yapmamız da gerekebilir.

İnternette bunca firewall alternatifi varken, neden bu denli karmaşık bir ar-ge çalışmasına giriyorsunuz diyenler olabilir. Bunun nedeni; bize göre en üstte saydıklarımızı karşılayan Desktop Firewall bulunmamasıdır. Mevcut programlar ya çok güvensizler ya da güvenli olmaya çalışırken, çok fazla alarm verip kullanıcı dostu olmaktan çok yüklendiği gibi kaldırılan programlar oluyorlar.

Basit bir örnek vermek gerekirse, henüz DNS veya ICMP protokolünü gerektiği gibi analiz edip, kullanıcı onayı almadan hareket edebilecek bir firewall yok.

Bunu şu şekilde örneklendirebiliriz: Birçok program, aslında hiçbir internet bağlantısı gerçekleştirmediği halde, Windows modüllerinde bulunan istem dışı dns sorgusu gerçekleştiren fonksiyonlar yüzünden firewall alarmına maruz kalıyor. Örnek: GetComputerNameW

Borland Delphi 3. parti internet componentleri ile uygulama geliştirenler ya da wintrust vb. modülleri kullanan yazılımcılar bu durumu iyi bilirler. Çünkü uygulama hiçbir şey yapmadığı halde, çalıştığı anda piyasadaki tüm firewall programları tarafından alarm verilir.

İlerleyen zamanlarda ar-ge çalışmalarıyla ilgili son gelişmeleri tekrar yazacağız ve alpha testlerden geçtikten sonra ilk firewall modüllü AntiLogger’ı beta kullanıcılarımızla paylaşıp, test edeceğiz. Her şey umduğumuz gibi giderse, tahminen 3 ay içinde de ilk stabil versiyonu yayınlamayı plânlıyoruz.



No comments:

Post a Comment