From: Can Erkin Acar (canacar@eee.metu.edu.tr)
Date: Tue 05 Aug 2003 - 16:42:07 EEST
On Mon, Aug 04, 2003 at 09:52:59PM +0300, =?windows-1254?Q?Engin_=D6. ?= wrote:
> Merhaba ;
>
> IPFILTER hayal kırıklıgı yaratmaya devam ediyor.. bir dolu yazı okuyoruz, ama fazlaca geliştirilmedigini cok net hepimiz gözlemleyebiliyoruz.
Serbest yazilimlarin gelistirilmesi kullanicilarinin elinde. Eger
farkettiginiz eksiklikler, istediginiz ozellikler varsa katkida
bulunmayi dusunebilirsiniz.
> IPCHAINS'e göre cok fazla üstünlükten söz ediliyor ama bence bunların hepsi de IPCHAINS de fazlasıyla var ve hatta harika bir özellike daha var : string.. error-log'larda gördügümüz ve *nix dünyası için hicbir anlam ifade etmeyen .dll ve .ida uzantılı ve buna benzer daha baskaca cok fazla dosya türü için bloklamaktan uzak bir yazılım IPFILTER.
ipchains? biraz eski olmadi mi?
netfilter/iptables daha iyi bir karsilastirma olurdu.
Ancak linux'ta yapildigi gibi her ozelligi cekirdegin (kernel)
icine doldurmaya calismak her zaman iyi sonuc vermiyor.
bahsettiginiz icerik filtreleme islemi cok karisik bir konu.
Konunun zorlugunu gostermek icin dogru bir icerik filtrelemede
yapilmasi gereken islemleri bir siraliyalim:
1. Paketlerden her baglanti icin dogru diziyi (stream) olusturmak
2. Bu dizide kullanilan protokolu (http/ftp/smtp/irc/h323/sip ...) anlamak
3. Bu dizide filtrelenecek icerigi tespit etmek
Bu isleri bir paket filtreleyen firewall'a yaptirmak isterseniz
her asamada cikabilecek pek cok sorun var:
1. Firewall da incelemek uzere olusturulan dizinin, baglantinin diger
ucundaki sunucunun olusturdugu dizi ile ayni oldugundan emin olmak gerek.
Bu noktada isi zorlastiran paket parcalarinin birlestirilmesi, kaybolan
ve yeniden gonderilen paketlerin izlenmesi, paketlerin dogrulanmasi
(checksum) gibi bir saldirgan tarafindan da kotuye kullanilabilecek
pek cok konu var. Eger dogru diziyi olusturamazsaniz, ya da dizi
olusturmak icin bir caba karcamazsaniz, yaratacaginiz filtreler
yanlis paketleri/baglantilari engelleyebilir, ve becerikli bir
saldirgan, sizin filtreden siyrilmanin bir yolunu kolaylikla bulabilir.
(sadece paketlerde 'string' bakmak iyi bir fikir degil)
2. Protokolu izlemek ve gonderilen dosya isimlerini/icerigini bu dizide
bulmak da protokole bagli olarak oldukca karmasik bir kod gerektiriyor
ve bu isi de dogru yapmak, ozellikle de kernel (cekirdek) icerisinde
hic de kolay degil (yoksa web ya da mail sunucularinda bu kadar cok
hata ve/veya guvenlik acigi olmazdi ;) )
3. Icerik tespiti butun diger isleri yaptiktan sonra kolay gibi
gozukuyor, ancak bu isi hizli ve ayni anda pek cok dizi icin
yapmak gerekecek cok bellek harcamak ya da zaman kaybetmek
Kullanim Engelleme (DoS) saldirilarina olanak saglayacaktir.
Bu kadar karmasik kodu cekirdek icine yerlestirirseniz de pek cok
sorunla karsilasmayi beklemelisiniz. ornek olarak www.netfilter.org
sayfasindaki Guvenlik Duyurularini inceleyebilirsiniz. (cekirdekte,
ozellikle de paket isleme kodunda meydana gelen bir guvenlik acigi
diger guvenlik aciklarindan daha tehlikeli olabilir)
Bu durumda elinizde ya karmasik ve potansiyel guvenlik aciklari barindiran
bir cekirdek kodu, ya da yeterince etkili olmayan, sadece sahte bir
guvenlik hissi uyandiran bir filtre olacaktir (muhtemelen ikisi birden)
Sonuc olarak, bu islerin cekirdek disinda, bu is icin yazilmis uygulamalarla
(application proxy/gateway) yapilmasi cok daha sagliklidir.
> Secure ve performans yetenekleri açısından çok başarılı olsada sanıyorum ki OPENBSD nin ayrılmasından sonra IPFILTER büyük yara aldı.
ipf (ipfilter) kullanicisi degilim, OpenBSD ile birlikte ben de pf
(OpenBSD paket filtresi) kullanmaya basladim. pf'in performansi,
ozellikleri, guvenligi cok yuksek ve surekli gelistiriliyor.
pf gelistiricileri de yukarida saydigim nedenlerle cekirdek icerisinde
uygulama tabanli filtreleme yapilmasina karsilar. Uygulama tabanli
filtreleme ve proxy islemleri, baglantilari uygun programlara
yonlendirilerek yapilmakta.
Can