lf294, SystemAdministration: IDS- İzinsiz Giriş Sezimleme Sistemi, 2. Bölüm

<-- | Ana Sayfa | Erişimdüzeni | İçindekiler | Arama

Bu makalenin farklı dillerde bulunduğu adresler: English Deutsch Francais Nederlands Turkce

Klaus Müller
<Socma(at)gmx.net>

Yazar hakkında:
Klaus Müller a.k.a. 'Socma' Linux programlama ve güvenliği konuları ile uğraşan bir öğrencidir.

Türkçe'ye çeviri:
Muzaffer AYVAZ <ayvazm(at)be.itu.edu.tr>

İçerik:

Çözümleme Olasılıkları
İmzalar
Kavram
Zaaflar
Yanıtlar
Aktif Yanıt
Pasif Yanıt
Filtre
Standartlar
CVE
Ornekler
Snort
LIDS
COLOID
Kapanış Kelimeleri
Bu yazı için görüş bildiriminde bulunabilirsiniz

IDS- İzinsiz Giriş Sezimleme Sistemi, 2. Bölüm

Özet:

1. Bölüm IDS üzerine olan tipik saldırılara odaklanır. 2. Bölüm ise, bunların keşif ve yanıt yöntemlerine giriş yapar ve imzalar ve filtrelerin bunlar arasında uygulamasına anlatır. Sonunda da Snort LIDS'e giriş yapacağız.

_________________ _________________ _________________

Çözümleme Olasılıkları

Öncelikli olarak IDS'leri ve var olan birçok sistemi korumak için ayrıntılı bir şekilde saldırılar üzerine hazırlnadık. Daha sonra çözümleme yöntemlerini ve bir IDS'in bir saldırı olup olmadığını, nasıl tanımladığını, aslında bir saldırının başarılı olup olmadığının nasıl tanımladığını inceledik.

Aslında, yanlış kullanım sezimleme (Misuse Detection) ile Anormallik Denetleme(Anomaly Detection)'i birbirinden ayırıyoruz. Misuse Detection saldırıları meydana çıkarmak için özel tanımlı örüntülerden faydalanır. Bu örüntüler "imzalar"(signatures) olarak adlandırılırlar, bunlar kendilerine ayrılan bölümde ele alınacaklar. Şimdilik ağ trafiğini kesin dizgeler(ör./etc/passwd) araştıran "imzalar"'ı, özel dosyalara giriş izinlerini reddediğini ve bir uyarı mesajı gönderdiğini bilmemiz gerekir. Misuse Detection'ın avantajı, imza kriterleri iyi bir şekilde tanımlanabildiği takdirde yanlış uyarıların düşük olma olasılığıdır.Dezavantajları ki oldukça açık, sık sık yeni saldırıların kaçırılacağıdır, çünkü bunlar tanımlanmamıştır. ( "imzalar" bölümüne bakınız).

Diğer metod Anomaly Detection' dır. Bu basitce kullanıcıların normal hareketlerinin profillerinin geliştirilmesi anlamına gelir. Eğer kullanıcının davranışı profilinden çok fazla farklılaşırsa bir uyarı tetiklenir. Bu çözümlemenin ilk adımı normal kullanıcı davranış profillerinin(veri tabanı) oluşturulmasıdır. Değişik türde adımlar kaydedilebilir: Kullanıcı özel komutları hangi sıklıkta çalıştırıyor? Bu özel komutlrı ne zaman çalıştırıyor? Özel dosyaları hangi sıklıkta açıyor? .... Küçük bir örnek: - kullanıcı "Example" , /bin/su komutunu günde üç kere çalıştırıyor. ( Bu değer profilde olamalı). Ansızın - birgün - kullanıcı "Example" , su komutunu günde yedi kere çalıştırıyor, normal davranışın iki katından daha fazla. Anomaly Detection bu "onormal" davranışı sezer ve sistem yöneticisini kullanıcı "Beispiel's"'ın normal davranışını su komutunu üç kez çalıştırmak olduğu ancak yedi kez çalıştırdığı hakkında uyarır. Bu yöntemin dezavantajları, uygalamaya başladığımda, daha anlaşılır hale geldi ( sondaki örneğe bakınız - COLOID). Kullanıcı davaranışları için bir veritabanı yüklemek oldukça hesaplama yoğunlukludur. Örneğin, on özel dosyayı kullanıcının ne sıklıkta açtığını gözleyelim. Her open() komutu, açılan dosyanın on özel dosayadan biri olup olamadığını anlamak için kontrol edilmeli ve sonuç pozitif ise, var olan sayaç arttırılımalı. Yinede, "anormal" gibi göründükleri müdedetce yeni çıkan saldırı tekniklerini ortaya çıkarmak için, bu büyük bir fırsat. Ayrıca, sistem yöneticisinin kendiside ne kadarlık bir farklılığın "anormal" tanımlanacağını belirleyebilir, ör. 10% sapma yada 75%.... Bu yöntemden faydalanmak için kullanıcı profillerini "güvenli bir ağda" oluşturmaya dikkat etmeliyiz, aksi takdirde saldırganın(attacker) davaranışı "normal" sanılırken,yasaya uyan kullanıcının iletisi "anormal" sanılabilir. Genel olarak Anomaly Detection aşağıdaki prosedürleri içerir:

Threshold Detection = Burada sayaclardan faydalanılır, Bunlar birşey ne sıklıkta çalıştırılıyor,açılıyor,başatılıyor hesaplarlar... Bu durağan çözümleme zenginleştirilebilir. Böylece Heuristic Threshold Detection diye adlandırılabilir.
Rule-Based Detection = tanımlı kurallara dayanır, kullanıcı kurallardan ayrıldığında bir uyarı mesajı tetiklenir.
Static Measure = Kullanıcının davranışı ya önceden tanımlı ya da başka bir şekilde bulunabilecek imzalara uyar. İmzaların tanımı için normal kulanıcı davranışlarını kaydeden bir program sıklıkla bulundurulur.

Heuristic Threshold Detection bu koşulda sayacın ( Ne sıklıkta ne çalıştırabilir) sabit bir başlangıç değeri yoktur ancak değişken bir değeri vardır. Bir kullanıcı normal olarak /bin/login komutunu 4 kez çalıştırısa sayaca 5 atanabilir....
Protocol Anomaly Detection, Anomaly Detection'ın bir alt grubudur. Bu nispeten yeni bir tekniktir,Anomaly Detection'a benzer bir şekilde çalışır. Her protokolün bir ön tanımlı imzası vardır.(RFC'e bakınız).Protocol Anomaly Detection'ın amacı protokol davranışının daha önceden tanımlandığı gibi olup olmadığını bulmaktır. Çoğu saldırılar yanlış protokol kullanımına dayanır ve şuna inanılabilir ki, bu alt prub IDS ler için oldukça önemlidir. Tarama (scanning) bölümüne baktığımızda Protocol Anomaly Detection'a bazı göstergeler bulabiliriz.

Check if no flag is set (NULL scan)
Check if all flags are set(XMas scan)
Check if "nonsense" combinations of flags are set, like SF
.......

İlgili RFC'lerde doğru spesifikleri bulacağız, aynı zamanda ne tür davaranışlar olmamalı?,yanıt. Hangi tür davaranışlar özel bi olaya karşı yanıtlarda bulunmalı? Buna ek olarak Application Anomaly Detection ( yaklaşık Application Based IDS bigi çalışır) var. Bazı literatürlerde bu çapta göstergeler buldum, bu yüzden inceledim. Tabii ki,bir program "normal" davranır, ör. Olay X'e..yada Y'ye nasıl karşılık verdi yada eğer kullanıcının girişi yanlışsa. Sık var olan ikililer(binaries) (ör. ps, netstat, v.b. ) kullanıcı girişiyle yer değiştirilirler,ps olması koşulunda özel prosesleri saklamk için. Application Anomaly Detection'la, bir programın anormal davranışını çözümlemek olasıdır.IDSs'den yaralanan bazı uygulmalar bu şekilde çalışır, ancak benim çok az bir deneyimim var.

sonuç olarak bir başka yeni ID-Sistem metodu: Intrusion Prevention(İzinsiz Giriş Koruması). Bazı yeni ID-Sistemlerine uygulandı, bu metod diğer tanımlanan metodlardan farklılık gösteriyor. Trafiğin logfileslarını analiz etmek yerine, saldırı olduktan sonra ortaya çıkarır, ataklardan korumaya uğraşır.

Klasik IDSs'lerin tersine, saldırıları çözümlemek için hiçbir imza kullanılmaz.Aşağıdaki IPSs'lerin nasıl çalıştığının kısa bir açıklamasıdır, bunların fonsiyonalliği bu örneklerle daha açık olacak:

Monitor application behavior
Create application rules
Alert on violations
Correlate with other events
System Call Interception
......

'Monitor application behavior', Application-Based-IDSs'lerle ilgilidir, i.e.bir uygulamanın davranışı analiz edilir ve kaydedilir, ör. Hangi data normal olarak soruluyor , hangi programlarla birlikte çalışyor, hangi kaynakları gerektirir.Anomaly Detection gibi, bir programın normal olarak nasıl çalıştığını bulmaya çalışır,yanıt. Ne yapılmasına izin verildi?

Üçüncü konu ('Alert on violations') herhangi bir açıklama gerektirmemeli , sadece bir sapma olduğu zaman ( bir saldırı sezildiğinde) bir uyarı tetiklenir. Bunun sonucu bir "log entry" ya da bloklanmış kaynaklar olabilir.

İkinci adımla beraber ('Create application rules') böyle adlandırılan uygulama kuralları bölüm I ( 'Monitor application')'deki analizlere uygun olarak bulunur. Bu kural seti ne uygulmasına izin verildiği (ne kaynakları isteyebileceği) ve neyin uygulanmasına izin verilmediği hakkında bilgi üretir.

'Correlate with other events' beraber çalışan sensörlerin bilgi paylaşımı anlamına gelir, Bu daha iyi bir saldırı koruması(attack preventation) üretir.

       Application
        |
        V
       Action
        |
        V
    ---------------------
    | Realtime decision |
    ---------------------
       /       \
      Deny     Allow
       /           \
   Alert         execute Action

Bu basitleştirilmiş diagram prosesi biraz daha iyi açıklayabilir. Bir aktiviteden önce 'realtime decision'(gerçek zamanlı karar verme)çalıştırılır. (Aktivite kural setiyle karşılaştırılır.) Eğer aktivite yasaya uygun değilse (ör.Program , sistem datasına ulaşmasına izin verilmemesine rağmen bile data ister ya da onları değiştirmek ister) bir uyarı başlatılır. Çoğu şartlarda,diğer sensörler( ya da merkezi konsol) bilgilendirilir. Bu ağdaki diğer bilgisayarları özel dosyaların açılmasından/çalıştırılmasından korur. Eğer aktivite kurallar setine uyarsa , izin kabul edilir ve sonunda proses gerçekleştirilir.

Listemizdeki son konu: 'System call interception'. Geliştirilmiş "system call" lar ("rootkits" diye adlandırılır) sık sık sezilirler."system call" ların durdurulmasına yaklaşım oldukça basittir: Bir "system call" kabul edilmeden önce,kontrol edilir. Kontrol etmek aşağıdaki soruların sorulması anlamına gelir.( [5]'e bakınız):

"system call" ı kim yayımladı (Hangi program) ?
Proses hangi kullanıcının kontrolü altında çalışıyor (root...) ?
"system call" neye ulaşamaya çalışıyor?

Bu önemli config/sistem dosyalarında ki başarılı değişikliklerin gözlenmesini sağlar,izin verir, "sistem call" un ön tanımlı kural setine uygun olup olmadığını denetlemek zorundayız.

               Program
                   |
                   V
             System call
                   |
                   V
            System call Interception
                 /          \
             Deny           Allow
               |               |
            do not call     Kernel
            System call

Intrusion Prevention diğer metodlarla kıyaslayacak olursak nispeten yeni, ve bu konuyla ilgili daha fazla bilgi bulunabilecek.

Sonuç olarak OKENA' ya bir ima yapacak olursak,çok güçlü bir IPS. www.okena.com'un "white paper" Storm Watch hakkında ek bilgi bulabilirsiniz.Storm Watch'un eksiklerini bulmak için [6]. bölümü okuyun

İmzalar

Şimdi IDSs üzerinde imza kullanımı hakkında konuşacağız, ikinci bölüm bunların zayıflıklarından oluşacak.

Kavram

İmzaların yardımıyla bilinen ataklar tanınabilir, bir imza veri tarfiğinde kesin bir örüntü arar. Bu örüntü bir çok şey olabilir, dizgiler, göze çarpan header(başlıklar) (değişik flag kombinasyonlarıyla), trojan'lar tarafından kullanıldığı bilinen portlar. Çoğu saldırıların kesin karakteristikleri vardır, ör. özel flaglar kurulu ya da payload(taşınan veri) içindeki parçalı dizgiler. İmzalar sayesinde bu karakterlerden bir saldırı bulunabilir.

"Payload Signatures" diye adlandırılanlardan başlamak istiyorum. Bu paket payload'un bir bölümüdür.:

00 00 00 00 E9 FE FE FF FF E8 E9 FF FF FF E8 4F    ...............
0 FE FF FF 2F 62 69 6E 2F 73  68 00 2D 63 00 FF FF .../bin/sh.-c...

Daha sonra SNORT kurallarının tanımlanmasında göreceğimiz gibi yapılacak bazı seçenekler var. Sıkça payload'ın içeriği özel sipesifik dizgeler için araştırılır. (in Snort with 'content' or 'content-list'). Birinin bir password dosyasına ulaşmak istediğini varsayalım (ör. /etc/passwd) Payload (/etc/passwd)' için araştırılabilir, eğer dizge sayaç ölçümünü içeren paket başlatılabilmişse,örneğin:

 alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80        \
 (msg:"WEB-MISC/etc/passwd";flags: A+; content:"/etc/passwd"; \
 nocase;classtype:attempted-recon; sid:1122; rev:1;)

Bir başka olasılık bir özel, spipesifik bir dizge içermeyen paketlerin sezilmesidir.

Olası bir arabellek taşmasından korunmaya bir başka yaklaşım, özel portlardaki paket büyüklüğünün kontrol edilmesidir . Genel olarak kaynak portu ve hedef portu tanımlamak mümkündür, sipesifik portlardan veya sipesifik portlara olan istekler engellenebilir. Genel olarak dizgi imzalar payload imzalardır. Payload imzalar bir paketin payloadını kontrol ederler, ör. Payloadın dizgi imzası sipesifik dizgi için araştırılır. .
İmzalardan başka ne sezilebilir? Payloadları sipesifik dizgiler için kontrol etmek her zaman en iyisi değildir.İmzalara TCP başlıklarının flag kombinasyonlarını araştırmasını sağlamak bir başka olasılıktır.Eğer bir pakette SYN ve FIN kurulmuşsa, bu onormal olarak görülür. Saldırgan(attakcer) işletim sisteminin özelliklerini bulmak için kullanabilir(ya da işletim sisteminin kendisini). Başlangıçta değindiğimiz gibi, tojanlar tarafından tercih edilen bazı özel portlar var. Böyle portlara örnek 31337 ya da 27374'tür.

Prosesi bir örnekle açıklarsam, belki daha anlaşılır olacak. Synscan saldırılarının tipik ortaya çıkarıcılarına bir bakalım :

different source IPs
TCP Src and Dest Port is 21
Type of service 0
IP id 39426
SF set (SYN and FIN)
different sequence numbers set
different acknowledgment numbers set
TCP Window size of 1028

Bu gibi şartlarda imzaların fonksiyonu "normal" ve "anormal" bağlantı özelliklerinin ayrılması olabilir. Bazı IDSs'ler bilgilerle birlikte özel veri tabanı tutarlar , yukarıda gösterildiği gibi, eşlemeler için araştıracaklar.
Pirensip olarak, anormallikler imza kontrolü yardımıyla synscanlerde sezilebilir:

Kaynak ve hedef portlar 21 dir. (File Transfer Protocol - ftp) .
Aynı kaynak ve hedef port numarası çaresizce bir saldırının yakın olduğunu göstermek sadece bir olasılık vardır.
SF atanması, yukarıda değinildiği gibi, birisi bir bağlantı isteyip aynı zamanda sonlandırmadıkça gerçekleşmez
Sadece SF atanmışsa ve ACK atanmamış olsa bile, alındı numarası sıfıra eşit değildir. Eğer ACK atanmamışsa alındı numarası 0 olmalı.
Bu numara sabit kalmasa bile, IP ID daima 39426'dır, (RFC'e göre ), fakat bu kaçınılmaz bir şekilde synscan attack olduğunu götermez- aynısı sabit pencere büyüklüğüne uygular.(consatant window size)...

Synscan attackların sezilmesi için kullanılan imzaların gelişimi yukarıda değinilen kriterlerden daha çok göz önüne alınması gerekir. İmzalaraın amacı Var olanlar olduğu gibi yeni versiyon saldırılarında sezilmesidir. Bu sebeble saldırı seziminin olasılığını yükseltmek için genel ve özel karakteristikler kombine edilir. Bir saldırının her yeni versiyonu için yeni bir imza yazmak mümkün olsa bile, bu bizi daha önemli işler yapmaktan alı koyup meşğul edecektir. Bu yüzden imzalara dikkat etmeleyiz ki bu imzalar mümkün olduğu kadar çok saldırıyı (ve onların versiyonlarını) yeni imzalar düzenlemeye gerek duymadan sezebilsin.

İmzalar özel saldırıları sezmek için yazılmalı, fakat onormallikleri bulmak için genel imzalara ihtiyaç vardır. Özel atakların sezilmesi için örnek bir imza aşağıda gösterilmiştir. ( synscan attack ). Daha genel bir imza,örneğin, aşağıdaki kriterleri kontrol eden bir imza olabilir:

ACK atanmamış olsa bile alındı numarası 0'a eşit değildir.
TCP başlıklarındaki anormal flag kombinasyonları (SYN ve FIN) ya da başkaları ("scan"'lerin tanımlarına bakınız)
....

Protokoldeki anormallikleri bulan imzalar "Protocol analysis based signatures" diye adlandırılırlar, diğer grup "Packet Grepping" diye bilinir.

Zaaflar

Payload imzalar metodu (dizgi imzaları içeren) oldukça güvenilir görünse bile,bunların da hilesini bulmak için yollar var. Snort kurallarıyla nasıl çalışılacağı hakkında yaklaşık bir sayfa yazacağım, burada faydalı olmak için kendimi sınırlıyorum. "/etc/passwd"'i araştıran bir imza nocase 'le birlikte hesaba katılmaz,bunlara aldırılmaz. Her ne kadar, biz /etc/passwd'e doğrudan değilde dolaylı olarak yaklaşırsak, örneğin,saldırgan(attacker) ' /etc/blablabla/.../.../\passwd ' kullanırsa İmza hala bir uyrı vereck mi? Hayır, çünkü o /etc/passwd'ı arıyor. (ve diğer capitilized/non-capitalized versiyonları). Bu imzaların diğer bir limiti çok bilinen saldırıların sezimlenmesi ve bilinen "vulnerability(örselenebilirlikleri)" leri aramasıdır. Belirli attackların yeni versiyonları sıklıkla bulunmadı, keşfedilmedi.... Diğer imzalar - sipesifik attacklara özelleştirilmiş olanlar - ya da genelleştirilmiş imzalar yeni saldırıları keşfetme avantajına sahiptir. Her ne kadar, İmza kurallarının oluşturulmasında çok dikkatli olunması gereksede . Sipesifik attacklara özelleşmiş bir imza az gelişmiş bir varyasyonu bulamayacaktır. ( sabit bir IP ID değeri(39426) yerine yeni saldırının değişken bir değeri vardır...). Genel imzaları haritalarken (protocol analysis based signatures) kuralların global olarak tanımlandığından emin olmalıyız, Bu olamayan ya da olmayan anormalliklerin onlar tafarından işaret edilebilmesi anlamına gelir.

Diğer açıklar Unicode attack sınavlarında görülür. ([4]'e bakınız). Burada Unicode attack tarafından gerçekleştrilen MS IIS deki bir güvenlik açığını görüyorsunuz.

"Özet:
Microsoft Internet Information Server (IIS)' da uzak kullanıcıların dizin içeriklerini listelemelerine, dosyaları görüntülemelerine, dosyaları silmelerine, keyfi komutlarını çalıştırmalarına izin veren bir noksanlık vardır. Attacker'lar Unicode karakter setini kullanarak ve IIS den yararlanarak normal olarak ulaşalımaz kayanaklara URL'ler vasıtasıyla ulaşabilirler. IIS'in şimdiki bütün versiyonları bu örselenebilirlikten etkilenir. Bu örselenebilirliğin işletmesi saçmadır. ISS X-Force yaygın olan bu örselenbilirliğin işletmesinden haberdardır."

IDSs'ler için gerçekte var olan bir problem UTF-8 karekterlerinin aynı sonucu veren birçok kodu vardır, e.g. "A" : U+0041, U+0100,

U+0102, U+0104, U+01CD, U+01DE, U+8721. MS IIS koşul bağımsız olunca, yine birçok karalter görüntülemek için birçok olasılık var. (örneğin AEIOU 'u görüntülemek için 83.060.640 farklı olasılık var).

Eğer bir attacker örneğin "http://victim/../../winnt/system32/cmd.exe"'ı çağırırsa IIS bir hata verir. Her ne kadar , "../.." yerine UTF-8 eşiti yazılırsa hiçbir hata vermez: "http://victim/..%C1%9C../winnt/system32/cmd.exe". Zaten , UN-escape UTF-8 diye adlandırılan kodlar bizim ulaşmamız gereken sayfaları açmamızı mümkün kılar. Olay uygulama tabakasında yer aldığından,bir NIDS 'ın attackları sezmesinde zorluklar vardır - şöyle bir koşulda HIDS'ın uygulanması daha uygundur. Şifreleme genel olarak sensörler için bir problemdir. - Bu arada bu gerçek sık sık istismar edilir. Bazı "IDS-producers"'lerinin raporları imzaların limitlerini açıkça göstermektedir, faydalı imzalar bazı bilinen Unicode-attackları sezdiler, ancak saldırıların küçük modifikasyonlardan sonra imzalar yeniden kullanışsız hale geldiler. Sadece NetworkICE başarılı bir şekilde bu tip attackları sezen imzalar keşfetti. (Snort ISS Real Secure sadece bilinen Unicode attack'ları sezen imzalar keşfettiler).

Yanıtlar

Önceden açıklandığı gibi, IDSs PC ve ağdaki aktivitekleri analiz eder. - fakat bir karşılık vermeden veya bir uyarı yapmadan IDS nasıl faydalı olur? IDS değersiz olur, makine performansının boş yere harcanması olur. 'Response(Yanıt)' Active Response ve Passive Response arasında farklılık gösterir. Özel bir bölümde bu farklılıkları açıklayacağız. İlgili okuyucu bu bağlantıyı tıklayabilir OPSEC

Secured by Check Point' appliances are security solutions that integrate
Check Point VPN-1/FireWall-1 technology onto our partners' hardware
platforms.

Bu sistem var olan sistemlerin Fire Wall-1(güvenlik duvarı)'da bütünleşmesine olanak sağlar.Ek bir avantajı ise dünya çapında bilinmesidir. 300 civarında ortağı vardır). Eğer bir saldırı keşfedersiniz, saldırganın IP adresini kitleyebilirsiz.( sadece olası bir yanıt seçeneği) ...Eğer OPSEC ile ilgiliyseniz "Deployment Platforms"'u okuyunuz, Orada sisteme katılım "joining" için bir çok koşul bulacaksınız (ortak olmak için).

Aktif Yanıt

Active Response,IDS bir saldırı(veya buna benzer bir uğraş) sezdiği zaman otomatik olarak tepki gösterilmesidir. Attack ların farklılığına bağlı olarak IDSs birçok yanıtlma seçeneği sunar.
1) Muhtemel saldırgana karşı tepkide bulunmak. 2) "Simply(basitce)" ek veriler toplamak (saldırgan saldırısı ve onun içeriği hakkında). 3) Konfigürasyonu değiştirmek Birinci yapılabilir tepki, saldırgan karşısında başlangış adımları olmalıdır. Bu bir çok adım içerebilir, insanaların ulşaımı kitlemek ya da saldırgan karşısında atakları sonlandırmak gibi.Honeypot'la bağlantılarda açıkladığımız gibi, saldırgana karşı çoğonlukla zor değildir fakat aynı zamanda yas dışıdır. Bu bağlamda "Third Party Effect" diye adlandırılanlar çıkagelir. Gerçekte bu etki nedir? Third Party Effect'in grafik olarak açıklanması aşağıdaki gibidir:

 ------------               ------------              -------
 | Intruder | ------------> | Innocent  | ----------> | YOU |
 ------------               ------------              -------

Third Pary Effect masum bir insan ( ya da masum bir network)'ın attacker tarafından saldırıya uğraması, mutakiben bu masum insanın ağını kullnarak bizim ağımıza saldırması anlamına gelir (ve olsaı diğer ağlara). Böylece problem nedir? Problem bizim ağımızın masum ağı masum değilmiş gibi ortaya çıkaramasıdır ve bunun sonucu olarak ihmal edilen ağı istila eden masum olmayan kişi bize karşı yeni bir attack üretecektir. bizim atağımızın sonucu olarak (yanlış zannettiğimizde masum olmayan kişiye saldırabiliriz) "masum" üzerinde tespit edilemez hasarlara yol açabiliriz. Eğer suçlu izini saklamaya yetecek kadar zeki ise zarardan biz sorumlu tutulacağız. "suçlu" değil.

İkinci seçenek (ek bilgiler toplama) daha az tartışmalı. Bir olası saldırı veya izinsiz giriş sadece saldır ve saldırgan hakkında bilgiler toplanarak sezimlenebilir. Eğer bir IDS özel bir kullanıcının ayrıcalıklarını genişlettiğini kararlaştırısa (veya başka bir çeşit saldırı meydana gelirse) bu kullanıcın gözlenmesi genişletilebilir, ör. logging komutları (active edilmemişse), kullanıcı nerde sisteme girecek, ne kadar kalacak, ne zaman giriş yaptı, son iki gün içerisinde ne zaman ve hangi sıklıkta giriş yaptı , Spesifik ikilileri transfer(FTP) etmeye uğraştı mı... Bu yolla saldırganın bir profili oluşturulur. Bununla beraber detaylı kayıtların ve yakın olası kaçamkların analizini yapma avantajımız olur, bu aynı zamanda bizim yasal adımlar atmamızı olası kılar. Üçüncü seçenek sistemin modifikasyonu güvenlik duvarı, v.b. Eğer saldırgan sipesifik IP adresleri kullanıyorsa bu IP adresinden ağa olan bağlantısını kesebiliriz. Tabii ki diğer kuşkulu olkasyonlardan geln ulşaım isteklerini bloklayabilir ve kaydeddebiliriz . Özel şartlarda kendi ağımıza olan herhangi bir ulaşımı engelleyebiliriz (yada herhangi bir tp özel port isteği, özel network arayüzlerinden...).Active Response 'un bir başka olasılığı TCP bağlantısına devam etmemektir (TCP kill olarak da bilinir). Bağlantıyı sonlandırabilmek için bir RST gönderilir (Reset Flag), bu da oturumu sonlandırır("kill"). Normalde RST, bağlantıda bir hata olduğu zaman yollanır..., burada başaka bir bilgisayarla olan oturumu bitirmek için IDS ( ISS RealSecure gibi) bundan faydalanır. ( Win-NT içinde aynı isimde bir araç vardır.).

 " tcpkill - kill TCP connections on a LAN
   .......
   tcpkill  kills specified in-progress TCP connections (use-
   ful for libnids-based applications which  require  a  full
   TCP 3-whs for TCB creation). "

Bu 'man tcpkill''den seçilmiştir ....
Görüldüğü gibi, saldırılara karşı yanıtların gerçekten geniş olasılıkları var. Kontraatak yürütmek çekici görünsede yapılmamalı.

Pasif Yanıt

Active Response kıyasla, çağunlukla rastlanan uyarıların kaydedilmesidir, admin/user'lar tarafından gözetlenmeleri gerekir. Yanıt seçenekleri şunlardır:

1) uyarılar, imalar...kayıt
2) sistemi özel bir zamnada denetleyen raporların oluşturulması ve bir hesap açılması

Hemen her IDS uyarılar oluşturma ve kullanıcıya/browsera belirtiler gönderme yeteneğine sahiptir. Saldırı başarıldıysa - örneğin - önemli bir sistem dosyasını silmek, özel servisleri başlatamak (kullanımı yasaklananlar) ... olayı bildiren bir uyarı geliştirilir, aynı zamanda ne zaman olduğu ve kimin rol aldığı. Bu arada çok fazla IDSs böyle adlandırılan raporları oluşturma seçeneğine sahiptir. Sistemin durmu geniş bi zamanda gözlenebilir, aktiviteler kaydedilebilir ve durum raporları geliştirilebilir. Hemen bütün IDSs'ler passive response seçeneğini desteklerler.

Filtre

Saldırıların kimlere ait olduğunu imzalrı yardımıyla belirlemek için filtrelerden faydalanılır.Bu imza daha önce edğinilen imzalarla dolaylı olarak ilgilidir, burada bir saldırının tipik karekteristiğini arıyoruz ( dest/src ports, dest/src IPs, gibi...). Bu bölümün bir başka kısmı N-code giriş yapılması ve bilinen saldırılar için filtre örneklerinin açıklanmasıdır. Bu makalenin sonunda kullanıcılara (ileri kullanıcı klavuzu - nfr) N-code planı sunan bir sayfa bulacaksınız - eğer iyi bilmiyorsanız.
land:

# This is an example on how to detect

# in N-code a land attack
 filter pptp ip () {
        if(ip.src == ip.dest)
        {
                record system.time,
                        eth.src, ip.src, eth.dst, ip.dest
                to land_recdr;
        }
 }

Bilinmeyen değişkenler kullanıldığınadan kısa bir açıklama yapılmıştır :

ip.src = kaynak IP adresi
ip.dest = hedef IP adresi
eth.src = "target-machine(hedef makina)"'in MAC adresi
eth.dst = "source-PCs(kaynak PC)"'in MAC adresi
record system.time = ip.src == p.dest koşulu sağlandığında zamanı kaydeder.

görüldüğü gibi N-code == operatörünü tanır, Eğer ileri kullanıcılar klavuzunu okursanız,diğer var olan benzerlikleri bulacaksınız (diğer yüksek seviye dilleele birlikte), ör. N-code + , - , *... operatörlerini tanır ya da dönüştürülen operatörleri >=, != ....gibi, ay da yukarıda gösterildiği gibi ==. Xmas Scan: "Types of Attacks"'tan anımsayacağınız gibi Xmas Scan'da bütün flaglar atanır. Bu yüzden ,onların atanıp atanmadığını tasdik etmek akla yakındır. Bunun için ayrı ayrı atanan bitlerin değerlerine ihtiyaç duyarız:

 Bit                    Value
 --------------------------------------
 F-FIN                  1
 S-SYN                  2
 R-RST                  4
 P-PSH                  8
 A-ACK                  16
 U-URG                  32
---------------------------------------

filter xmas ip() { if(tcp.hdr) { $dabyte = byte(ip.blob,13); if(!($dabyte ^ 63)) { record system.time, ip.src,tcp.sport,ip.dest, \ tcp.dport, "UAPRSF" to xmas_recorder; return; } } }
Burada yine bazı bilinmeyen değişkenler var:

tcp.hdr = Eğer tcp.hdr == 0 sa,paket herhangi bir TCP Header içermez , Eğer tcp.hdr == 1 se içerir.
tcp.dport = TCP hedef portu
tcp.sport = TCP kaynak portu
ip.blob = paketin payload contenti (başlıksız)
"UAPRSF" , URG,ACK,PSH,RST,SYN ve FIN'in atandığı anlamına gelir.

$dabyte byte (ip.blob,13)'a atanan yerel bir değişkendir. "byte expression"'ı açıklamak için burada küçük bir TCP code bits örneklmesi var:

| Src Port | Dest Port | Seq Number | ACK Number | HDR Length | Flags |\
URG | ACK | PSH | RST | SYN | FIN | Win Size | Chksum | Urg Off | Opt |

byte()'da neden 13 byte'ın yer aldığının farkındayız, çünkü flagları ayakta tutmak için 13 byte gerekli. Byteların nasıl çalıştığını anlamadan önce ilk bazı laflar var. Örneğin "blob". İleri kullanıcılar kalvuzunda üçüncü bölüme bakarsanız, "blob" "keyfi boyutlandırılmış ardışık bytelardır". bir 'byte' bir blob'un özellleştirilmiş offsetinden bir byte döner, alışılagelen sentax şöyledir: byte (str blob_to_search, int offset). İlk argüman araştırılacak blob'u belirler ( yukarda: ip.blob), İkinci argüman arama sonrası byte (sought-after byte) (in 'blob_to_search') ofsetini belirler. 'if(!($dabyte ^ 63))' komutuyla bütün flagların atanıp atanmadığı kontrol edilir, bunun sonucu bütün flagların değerleri (32+16+8+4+2+1) toplanırsa 63 olur, eğer bilinmek istenirse: " ^ " birlikte, XOR çalıştırılır.

bu seçeneklerin aynında N-code çok geniş olasılıklar sunar. Örneğin, şunları blmak mümkündür:

Paketin bir IP paket olup olmadığı (ip.is)
IP paketinin uzunluğu (ip.len)
IP paketinin uygulamalı protokolu (ICMP,TCP or UDP) (ip.protocol)
ICMP paketinin toplamının kontrolü (icmp.cksum)
ICMP paketlerinin payload larını içeriği ( in blob) (with icmp.blob)
Paketin geçerli bir ICMP header içerip içermediği (icmp.hdr)
Paketin bir ICMP paket olup olmadığı (icmp.is)
ICMP paketinin tipi,Echo Reply , Destination unreachable(hedef ulaşılamaz),gibi....
..... vb .....

N-code ile ilgili ek bilgiyi şu linklerde Bulabilirsiniz Advanced User's Guide Guide at:http://www.cs.columbia.edu/ids/HAUNT/doc/nfr-4.0/advanced/ advanced-htmlTOC.html

Bu sayfaların gelecek versiyonlarında daha çok filtre ler tartışılacak, yenileri için düzenli aralıklarla ontrol edin ;)

Standartlar

Bu bölümde çeşitli standartlara ve birçok uzmanlar tafaından kullanılan liste/anlaşmalar'a (list/agreements) giriş yapacağız.

CVE

CVE (Common Vulnerabilities and Exposures) örselenebilirlik ve ışınlamların(vulnerabilities/exposures)listesinden başka birşey değildir. İlk bakışta eğlenceli gelebilir, Daha sonra oldukça el altında bulunacak. Sezilmiş örselenebilirlikler için çeşitli araçlar CVE(herkesin anlayip kullanabilecegi tek tip cesitli orselenebilirlik ve isinlama tanimlamasi )'lerden faydalanarak farklı terimler kullanıyorlar. Boylece baska kullanicilar icin ayni araclari kullanmak artik zorunlu degil.

CVE spesifik orselenbilirlik ve isinlama icin bir isim ve tektip bir tanimlama uretir bunlar farli kullanicilar arasindaki yanlis anlasimalari onler. CVE orselenebilirligi, normal orselenebilirlik ile ilgili problemler ve butun makul guvenkil policelerinin conteksi anlamaına gelir. CVE ısınlamayı bazı makul sigorta policelerindeki ihlal problemi olarak tanimlar. CVE ‘ de ikisinin arasindaki fark temeldir. Orselenbilirlige ornekler phf, world-writeable pasword dosyaları. Isınlamanın ornekleri Bruteforce tarfından calictirilan programlarin kullanimi ya da genel olarak calistirilan servislerin kullanilmasidir.Tanimlama ve orneklerle orselenebilirlik ve isinlanın ayrimi mumkun oldu. Temel fark saldirganin farklı bir kullaniciymis gibi komutlari uygulama yetenegi ya da dosya izinlerine bagli olarak mumkun olmayan dosyalari okuyup bunlar uzerinde degisiklik yapmasidir. Isinlamalar, tersine, kullaniciya sistem ve sistemin durumu hakkinda ek bilgiler edinmesine izin verir. Bu aktiviteler arka planda olur…Isinlamalar, duzeltilebilen kusurlu guvenlik ayarlarından dogar.Orselenebilirlikler normal guvenlik sistemlerindeki(izin kontrolune karsi olasi saldirilarda tehlikeyi en aza indirme olanagi bulunan) aciklardir. Her ne kadar bu “liste” su anda kaliyor olsa da , her orselenebilirlik ya da isinlamalar kabul edilmez. Bir orselenebilirlik/isinlama sezildikten sonra ilk once bir aday numarası ulaştırır.(Bu CNA – Candidate Numbering Authority içinde olur) Buna ek olarak CVE editörü tafarından Board’a gönderilir ve örselenebilirliğin/isinlamanın kabul edilip edilmediği ele alınır.Eğer Board adayın kabul edilmediğini sonuca bağlarsa (şimdilik) bunun sebebi web sitesi üzerine gönderilir. Eğer aday kabul edilirse listeye eklenir(ve CVE nin resmi bir parçası olur). Şimdilik, her olası örselenebililiğin başlangıç olarak bir aday numarası (kabul edilip edilmeyeceği tartışılan) aldığı açık olmalı. Örselenebilirlik bu aday numarasını listedeki resmi girişlerden ayırmak için alır. Her adayın 3 temel alanı vardır.

Numara
Tanımlama
Referanslar

Bu bağlamda numara adayın gerçek ismidir,ek bir numara olarak giriş yılıyla birleştirilir,bu o yıl içindeki ardışık adayları ortaya çıkarır:

        CAN-Year - sequential candidate of the year

Daha önce işlendiği gibi kabul edilen aday listeye eklenir. Sonuç olarak 'CAN-YEAR- Candidate number' 'CVE-Year-Candidate number' halini alır. Örneğin: 'CAN-2001-0078' listede 'CVE-2001-0078' halini alır .

Hepsi bu, daha fazla bilgi için CVE’nin resmi web sitesine bakınız.

Ornekler

Bu son bölümde bazı IDS ‘ lere başlangıç yapılacak.

Snort

Çünkü Snort çok iyi bilinen ve daha sonra çok detaylı anlatacağım bir çok seçenek sunan bir IDS örneğidir. Esasında, Snort 3 moddan birinde olabilir: Sniffer, Packet Logger ve Network Intrusion Detection System. Sniffer modunda Snort konsolda paket oluşturur, Packet Logger modunda onları hardiske kaydeder ve Network Intrusion Detection modu paketleri analiz etmeyi sağlar. Çoğunlukla son modan bahsedeceğim, fakat burada Sniffer ve Packer Logger modunada bir giriş yapacağım:
Sniffer modunda çeşitli paket bilgileri okunabilir, TCP/IP paket başlığı gibi:

 [Socma]$ ./snort -v

Çıktı olarak yalnızca IP/TCP/ICMP/UDP başlığını alırız. Çok fazla opsiyonu, kullanım seçeneği var, burada bir kaçı gösterilecek.

 -d = will deliver the packet data
 -e = shows the Data Link Layer

Packet Logger Modu:
Sniffer modundan farkli olarak Packet Logger modu hard diske paketleri kayit edebilir. Bizim yalnızca Snort’un kaiyt edecegi dizini belirlemiz gerekir ve o otomatik olarak Packet Logger moduna gececektir:

 #loggingdirectory must exist:
 [Socma]$ ./snort -dev -l ./loggingdirectory

“-l” girince Snort bazen uzak bilgisayarin adresini dizinmis gibi gosterir (icine kaydetigi) bazende yerel host adresini alir. Ev agina kayit edebilmek icin ev agini komut satirinda belirlememiz gerekir:

[Socma]$ ./snort -dev -l ./loggingdirectory -h 192.168.1.0./24

Baglanmak icin diger bir olasilik TCP-DUMP formatıdır:

 [Socma]$ ./snort -l ./loggingdirectory -b

Şimdi giriş paketi kayıt edilecek, yanlizca belirlei bolumler degil, ek secenekler icinde eleme yapar. Dosyalari ASCII’ye donusturebilmek icin tcpdump gibi programları kullanmak mumkundur, ancak Snort bunu yapabilir:

 [Socma]$ ./snort -dv -r packettocheck.log

Network Intrusion Detection Modu: NIDS moduna gecebilmek icin asagidaki gibi bir komut kullanabiliriz:

 [Socma]$ ./snort -dev -l ./log -h 192.168.1.0/24 -c snort.conf

Bu sartlarda snort.conf dosyasi konfigurasyon dosyasidir. Bu dosya bir sladiri olup olmadigini belirten kurallarin nerede oldugunu Snortun bilmesi icin kullanilir (ve istege izin verilip verilmedigini). Snort.conf ‘ta tanımlanan kurallar, bunlari analiz etmek icin pakette uygulanacak. Eger belirli bir cikti dizini olusturulmamissa var olan dizin /var/log/snort kullanilir. Snort ciktisi uyari moduna baglidir – bunun uzerine yakin yada uzak bir zamanda gerceklesme bilgisi verir.

 ----------------------------------------------------------------
 |      Modus   |  How/what is displayed                    |
 ----------------------------------------------------------------
 | -A fast      |  Time, Source and Destination IPs/ports,  |
 |              |  the Alert Message              |
-----------------------------------------------------------------
 | -A full      |  Default Setting                          |
-----------------------------------------------------------------
 | -A unsock    |  Sends the Warnings to a UNIX           |
 |              |  socket                                       |
-----------------------------------------------------------------
 | -A none      |  Stops the Alerts                          |
-----------------------------------------------------------------

Goruldugu gibi –b ile binary moda kayit yapabiliriz, -N ile paket kaydi tamamen sonlandirilir. Fakat bu bir sinir degildir, ornegin Snort syslog’a mesajlar gonderebilir bunun icin var olan ayar LOG_AUTHPRIV ve LOG_ALERT’tir. Syslog’a mesaj gondermek icin yapmamiz gereken tek sey “–s” kullanmaktir. Bunadan baska smbclient’a mesaj gonderme yada Windows bir bilgisyara Win-pop-up uyarilari gonderme olanagimiz vardir. Bu ozellikten faydalanabilmek icin Snort’un knfigurasyonuna "-enable-smbalerts" girmek yeterlidir.

 [Socma]$ ./snort -c snort.conf -b -M MYWINWORKSTATION

Uyari modunun bir uygulama ornegi:

 [Socma]$ ./snort -b -A fast -c snort.conf

Tanimlanan secenkelerin yaninda digerleri asagidaki gibidir:

 -D = starts Snort in daemon mode
 -u usersnort= starts Snort with UID 'usersnort'
 -g groupsnort = starts Snort with GID 'groupsnort'
 -d = also log the data of the applications layer
r

Eger bir bilgisayarda Snort –h komutunu calistirirsaniz yada problem olan mail listesine bakarsaniz Snort bircok secenek sunar. Takip eden bilen Snort kurallarindan olusur. Eger anlamaya dikkat etmek istemiyorsaniz bu bolumu gecebilirsiniz. Bu bolumun en sonunda belirttigim gibi (Snort hakkinda) www.snort.org ‘tan Snort kullanici manuelini indirebilirsiniz, bu bizim gercek kaynagimizdir.

Snort Kuralları:
Snort’u daha iyi anlamak icin Snort kurallarini bilmek zorunludur. Snort bazen “var” diye tanimlanabilen belirli degiskenler kullaniyor:

   var: <name> <wert>      var

   MY_NET [192.168.1.0/24,10.1.1.0/24]
   alert tcp any any -> $MY_NET any (flags:S;msg: "SYN packet";)

Degisken ismi girebilmek icin baska yollarda mevcut:

$variable = defines the Meta variable
$(variable) = here the value of the variable 'variable' is entered
$(variable:-default) = if 'variable' is defined, its  value is entered here,
is 'variable' not defined the value 'default' is entered.
$(variable:?msg) = enters the value of the variable 'variable' or
if not defined puts the message 'msg' out.

Daha once kabuk programlama ile ilgilendiyseniz asagidaki size yabanci gelmeyecektir:

 [Socma]$ shelltest=we
 [Socma]$ echo hello $shelltestlt
 hello
 [Socma]$ echo hello ${shelltest}lt
 hello world

Snort’taki $(variable) ile kabuktaki ${variable} aynidir. Kabuk programlamada baska esitleri (yada benzer terimleri) vardir:

 [Socma]$ shelltest = bash
 [Socma]$ echo ${shelltest:-nobash}
 bash
 [Socma]$ echo ${notdefined:-nobash}
 nobash

'$(variable:-default)' teriminin uygulanmasi sadece () yerine kabugun {} kullanmasidir. Son terim kabukta da vardir:

 [Socma]$ shelltest = bash
 [Socma]$ echo ${shelltest:?"then csh"}
 bash
 [Socma]$ echo ${notdefinedvariable:?"not defined or nil"}
 not defined or nil

Bu kisa gezintinin amaci bilgi ile iliksi kurmakti. Terimleri, kafamda dusunmektense Snortun syntax’ını boyle daha hizli hatirladim.
Konfigurasyon dosyasini bircok komut satiri secenegi yazilabilir. Bunun icin 'config' kullanilir::

        config <directive> [: <value> ]

En onemli komutlar:
alertfile = uyarilarin kayit edildigi dosyayi degistirir
daemon = daemon ( -D) olarak porosesi baslatir
reference_net = home network (-h)
logdir = kayit edilecek dizini atar (-l
nolog = Kayiti sonlandirir
set_gid = GID'ı değiştirir (-g)
chroot = chroot'ed in th especified directory (-t)
set_uid = UID'ı atar (-U)

Eger uyari dosyasini degistirmek istiyorsaniz, ornegin "mylogs" soyle yazin:

        config alertfile : mylogs

Gercek kurallara geri donersek ( burada ftp.rules orneği ):

alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP EXPLOIT overflow";\
flags: A+; content:"|5057 440A 2F69|";\
classtype:attempted-admin; sid:340;rev:1;)

Esasında , Snort kuralları iki parçadan oluşur : Kural başlığı ve kural seçeneği. Kural başlığı 2 şey hakkında bilgi verir.:

Kaynak ve hedef IP adresi
protokol
kural tarafından başlatılması gerekli hareketler

Yukarıdaki ftp kuralında başlık aşağıdaki gibidir.

 Action       source ip         destination ip
    |              |                |
 alert tcp $EXTERNAL_NET any -> $HOME_NET 21
         |                |               |
        Protokoll       From any port   Port

Görüldüğü gibi ilk önce kural başlığı sona erer ( ve sonra kural seçenekleri başlar. Birçok olası hareket (Snort kurallarının kuşkulu bir şey keşfedip keşfetmediğini ortaya koyan)vardır (bu koşulda 'alert’)

alert = hangi alert metodunun kullanıldığına bağlı olarak(varsayılan 'alert full'), bir uyarı tetiklenir ve gerekl paket kaydedilir.
log = sadece paket kaydedilir.
pass = paketteki sonuçlara aldırılımaz
activate = bir uyarı oluşturu ve başka bir dinamic Snort kuralına döner (sonra daha fazla bilgi)
dynamic = kural başka bir kuarl tarafından aktive edilene kadar pasif kalır, daha sonra 'log' gibi çalışır (yukarıya bakınız)

İkinci alan (burada protocol - tcp ) hangi protokolun analiz edileceğini belirler. Olası olanlar: tcp, udp, icmp and ip ( gelecekte başkaları da olabilir ... ARP, GRE,..gibi).
Sonraki alanla bağlantı olarak (source ip) sıkça “! –“ operatörünü buluyoruz. (negations operator).

 alert tcp !$EXTERNAL_NET any -> $HOME_NET 21

Sonuç olarak “!”operatörü $EXTERNAL_NET ‘den ulaşmayan paketleri kaydeder. IP adresi girmek, IP adresi listesi gibi birçok olasılık var. Adresler virgülle ayrılmları ve “[ ]” içine alınmalıdır..

        alert tcp ![ip address,ip address] any -> ....

Bir başka alternatif "any"i kullanmaktır, bu her IP adresini içerir.

        log tcp any any -> ...

Kural başlıklarındaki son bölüm portların belirlenmesidir, örneğimizde ftp. Tek bir portu gözetlemek mümkün değildir fakat bir çok portu gözetlemek mümkündür. Seçenkler aşağıdadır.

 :portnumber                     -> all ports smaller equal
                                 portnumber
 portnumber:                     -> all ports higher equal
                                 portnumber
 fromportnumber:toportnumber     -> all ports between fromportnumber
                                 and toportnumber (and those included)

Girilenler dışındaki bütün portların gözetlenmesi için “!” operatörünü kullanmak tabii ki mümkündür.

       !:21            -> all ports which are not smaller equal 21

Açıklanmayan fakat kullanılan bir operatörde yön operatörüdür. "->".

                "source" -> "destination"

Başka bir şeklide var .<> :

                 "source" <> "destination"

Bu Snort’un kaynaklar gibi hedefleride araştıracağı anlamına gelir
Belirttiğim gibi 'activate' adımı vardır, bu bir uyarı mesajı oluşturur ve başka bir dinamik Snort kuralına döner.
Belirli bir kural hareketlerini tamamlamışsa,başka bir kuralı active edebilir. Esasında, normal kurallar ile "activated rules" kuralları arasındaki farksadece belirli bir alan oluşturulmasıdır.: "activates". Dinamik kurallar, diğer taraftan, log gibi çalışır (yukarıya bakınız),tek fark : "activate_by" girilmelidir. Bir alan daha girilmelidir: "count". "activate rule" yapıldıktan sonra onun görevi dinamik kuralların istenmesidir, yalnızca “forcount" kaydeder (count=40 iken 40 paket).

activate tcp !$HOME_NET any -> $HOME_NET 143 (flags : PA;  \
  content : "|E8C0FFFFFF|\bin|;activates : 1; msg : "IMAP buf!";)
dynamic tcp !$HOME_NET any -> $HOME_NET 143 (activated_by : 1; \
  count : 50;)

Seçeneklerin bazılarına, kural seçenekleri gibi, henüz girilmedi,onları şimdi açıklayacağım, fakat siz daha sonra emin olacaksınız. Lütfen yukarıdaki örneğimizdeki alanları activates ve activated_by (dynamic rule) not al. İlk kural dinamik kuralı gerektirir, bu ilk kuraldan sonra görevi biter, bu aynı zamnda şu ifade ile belirtilir.

Snort Kurallarının İkinci Bölümü: Kural Seçenekleri. Yeniden ilk ftp.rule ‘u kullanalım:

alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP EXPLOIT
overflow"; flags: A+;\
content:"|5057 440A 2F69|";classtype:attempted-admin;\
sid:340; rev:1;)

Bu koşulda kural seçeneği (ilk önce kural başlığı durur)):

 (msg:"FTP EXPLOIT overflow";\
flags: A+; content:"|5057 440A 2F69|";\
classtype:attempted-admin; sid:340; rev:1;)

34 tane anahtar kelime var , ben kendimi en önemlilerle ya da en çok kullanılanlarla sınırladım. Bu nedenle bütün anahtar kelimeleri görmek isteyen Snort Kullanıcı Manualine bakabilirler..

msg -uyarı mesajlarını görüntüler ve Packet Logger Moduna kaydeder
logto -belirli dosyalara paketleri kaydeder.
dsize - farklı değerlerdeki paket büyüklüklerini kıyaslar
flags - belirli değerler için TCP flag larını kontrol eder
content - pakette belirli bir örgü/dizgi arar
content-list - pakette belirli bir örgü/dizgi arar
nocase - yukarı ve aşağı koşullarda bulunan dizgiler ihmal edilir
react - aktif yanıt (web sitelerini bloklar)
sid - Snort Kural id'si
classtype - bir gruptaki olası saldırıları sıralar
priority - duyarlılığı kurar
Kişisel kurallar nasıl çalışır ? msg:
Kuralları çalıştırtığımızda 'msg' ‘ oldukça sık görüyoruz, uyarıların oluşturulması ve kaydedilmesine sorumludur..

   msg:"<text>";

t "" uyarı dosyasına yazılan mesajdır
logto:
Kuralın uygulanabildiği her paket belirli bir dosyaya kaydedilir.

    logto: "<filename>";

Bu koşulda "" uygulanabilir dosyaların kaydedildiği dosyadır.
dsize:
Bu paketin büyüklüğünü belielemek için kullanılır.Belirli bir servisin arabellek büyüklüğünü biliyorsak,bu seçenek olası bir arabellek taşmasından korunmak için kullanılabilir. 'content' ‘ e kıyasla dha hızkıdır, bu yüzden ara bellek taşmalarını önlemek için sıkça kullanılır.

        dsize: [>|<] <size>;

İki opsiyonel operatör( > ve < ) paket büyüklüğünün daha büyük olması gerektiğini belirtir,yani: belli değerlerdeki flaglardan daha küçük olmalı:
Bu hangi flagların atandığını test eder. Snort da 9 flag kullanılmaktadır:

 F      FIN
 S      SYN
 R      RST
 P      PSH
 A      ACK
 U      URG
 2      Bit 2 assigned
 1      Bit 1 assigned
 0      no TCP flags set

Flagların belli kriterlerini test etmek için bazı mantıksal operatörlerde vardır.

 + ALL flag     = Hit at all specified flags (others as well).
 * ANY flag     = Hit at all specified flags.
 ! NOT flag     = if the specified flags are not set.

Anahtar kelime “flag” genelde şu şekilde kullanılır.

        flags: <Flag valuet>;

Reserve edilen bitler olğandışı davranışların sezilmesinde kullanılabilir
content:
En çok kullanılan anahtar kelimelerden bir ( 'msg' yanında) 'content' dir. Paketlerin payloadlarının kısmi içeriklerini araştırmak için kullanılır . Eğer belirlenen content sezilmişse, öncden tanımlı adımlar kullanıcıya karşı ortaya konur. Paketin payloadındaki contentlerin sezilmesinden sonra Snort kuralları çalıştırılır. 'nocase' (aşağıya bak) uygulmadan capitalization yapılabilir. Payloadın contenti binarileri tex gibi araştırabilirler. Binary veri | | içine alınır ve byte kodları gösterilir. Byte Kodları binary bilgiyi hexadecimal numaralar olarak verir .Bu anahtar kelimenin içeriğinde (!) operatörü uygulanbilir, örneğin, paket belirli bir text içeriyorsa, bit uyarı mesajı verebiliriz..

        content: [!] "<content>";

"!" zorunlu değil.

 alert tcp any any -> 192.168.1.0/24 143 \
(content: "|90C8 C0FF FFFF|/bin/sh";\
msg: "IMAP buffer overflow";)

Bu kuralda kanıtlandığı gibi binary veri | | içine alınır, bunu müteakip, normal text’de uygulanabilir. Snort User Manual.’de “offset” ve “depth”’in tanımına bakınız , İçerikte sık sık 'context' ‘ le birlikte kullanılır.

content-list:

Bu anahtar kelime 'content'’e benze olarak çalışır,dizgi numarası (paketlerin araştırılması için kullanılır) farkıyla. Uygun hexa munaraları, dizgileri, v.g. bir dosyaya girdik.Bu dosya(araştırılacak kelimeleri içeren), 'content list'’in uygulanmasında belirlenecek.. Dizgilerin düşey olarak yazıldığını aklımızda tutmamız gerekir (her dizgi bir satırda), ör.

        "kinderporno"
        "warez"
        .....

Bunu takiben, 'content-list: [!] "" ‘i uygulayarak ' dosyayı araştırabiliriz. Tabii ki ! opsiyonel, 'content'.’ Teki aynı etkiyi yapar

nocase:
'content' anahtar kelimesiyle birlikte içerikte bu kural çok önemli bir rol oynar . normalde büyük/küçük harf gereklidir, 'nocase' koşul duyarlılığı kullanılarak bu ihmal edilir.

 alert tcp any any -> 192.168.1.0/24 21 (content: "USER root";\
  nocase; msg: "FTP root user access attempt";)

’nocase' kullanılmazsa sadece 'USER root' araştırılır, çünkü 'nocase' koşul duyarlılığın belirlenmesi uygulanmamıştır..
Belirli bir 'content' için araştırma bir darbeyle sonuçlanırsa 'react' bunu yanıtlamak için kullanılabilir.Kullanıcı tarafından istenen belirli genel amaçlı sayfalar bloke edilir(porno sayfalar...) Flex Resp bağlantısı uygulanarak bağlantısı sonlandırılabilir yada penceresine bir uyarı gönderilebilir. Aşağıdaki seçnekler olasıdır.

block - bağlantıyı sonlandırır ve bir bildiri gönderir
warn - görünür bir uyarı yollar (daha sonra kullanılabilir olacak)
Bu basit argümanlar ek argümanlarla tamamlanabilir(böylece el geliştirici diye adlandırılırlar)

msg - 'msg' anahtar kelimesinden yararlanılara gönderile text kullanıcıya bönderilen bidiri içinde de yer alır.
proxy : - Bildirileri göndermek için kullanılır(daha sonra kullanılabilir olacak)

        react : <basic argument [, additional modifier ]>;

'react' anahtar kelimesi kural seçeneklerinin en sonuna eklenir, şöyle kullanılabilir.

 alert tcp any any <> 192.168.1.0/24 80 (content-list: "adults"; \
   msg: "This page is not for children !"; react: block, msg;)

sid:
'sid' ya da Snort Kurallar Belirlenmesi özel Snort kurallarının kimlere ait olduğunu saptar belirler.'ouput plugin'ler için her kuralı belirlemek olasıdır. Birçok sid grubu vardır.

 < 100 = reserved for future use
 100-1 000 000 = rules which come with Snort
 > 1 000 000 = being used for local rules

 sid-msg.map contains a mapping of msg tags for sid's.
It is being used foe post processing to assign a warning to an id.
 sid:  <snort rules id>;

 alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80  \
  (msg: "WEB-IIS file permission canonicalization"; uricontent:\
  "/scripts"..%c1%9c../"; flags: A+;nocase;sid: 983;rev:1;)

classtype:
'classtype'ı kullanarak saldırıları birçok gruba ayırabiliriz.Kurallarda olası saldırıların önceliğini tanımlayabiliriz. Konfigürasyon dosyasında sınıflandırılan kurallar standart bir önceliğe otomatik olarak atanacaktır.

 classtype: <class name>;

Kuralların kategorileri clasification.config ' de tanımlanır.Aşağıdaki sentaks kullanılır.

 config classification: <class name>,<class description>,\
       <standard priority>

Aşağıdaki paragrafda - priority'nin tanımlanması- ne çeşit saldırı grublarının olduğunu öğreneceğiz.
priority:
Bu anahtar kelime kurallarımıza güvenlik önceliğini atamak için kullanılır, olası bir saldırının ne kadar zarar vereceği anlamına gelir.Öncelik ne kadar büyükse olası güvenlik riski,zararı o kadar fazladır. 'clas types' da daha önce açıklandığı gibi öncelikleri anlamak oldukça kolaydır.

Class type                    Description                Priority
---------------------------------------------------------------------
 not-suspicious                Any "unsuspicious" traffic    0
 unknown                       Unknown traffic                  1
 bad-unknown                  Potential "bad" traffic      2
 attempted-recon              Attempted Information Leak            3
 successful-recon-limited     Information Leak                      4
 successful-recon-largescale  Large Scale Information Leak          5
 attempted-dos                Attempted DoS-attack                6
 successful-dos               Successful DoS-attack              7
 attempted-user              Attempted to get user privileges 8
 unsuccessful-user            Unsuccessful attempt to get
                                        user privileges
 successful-user             Successful attempt to get
                                     user privileges
 attempted-admin              Attempt to get admin privileges     10
 successful-admin            Successful attempt to get admin privileges

Daha önce belirtildiği gibi, yüksek öncelikler büyük güvenlik riskleri demektir. Admin önceliklerini kullanan bir kullanıcı bir çok saldırı üretebilir.

 alert tcp any any -> any 80 (msg: "WEB-MISC phf Versuch";\
        flags: A+;content: "/cgi-bin/bash";priority:10;)

Kurallar konusu çok karmaşık ancak zor değil.Bir kaç kurala çalışıp, manuelde araştırdıktan sonra bir süre sonra bu konuda çok iyi olursunuz :) Snort için kaynaklar ve belgeler http://www.snort.org da bulunabilir. Orada bazı değerli .pdf'ler bulacaksınız. Snort kullanıcı Manuel'i bu tanımlama için ana kaynaktır

LIDS

Stealth'in bildirisi (ve kaynaklar) ve LIDS-Hacking-HOWTO'ya baktıktan sonra LIDS'in gerçekten bilgisayar güvenliğini yükseltmediğini biliyoruz.

LIDS kavramına güçlü ve zayıf yönlerine bir bakalım. LIDS temel olarak-örneğin- önemli sistem dosyalarını korumak, kullanıcıdan gelen belirli prosesleri gizlemek için geliştirildi. Buna ek olarak bind modullerini basitleştirmeye izin verilmedi, gerekli moduller sistemin başlatılmasıyla sınırlandırıldı.Daha önce LIDS-Hacking-HOWTO ve Stealth'in bildirisinden bahsettim, her ikiside LIDS'in çalışmasını ve zaaflarını açıklıyor. En öneli özelliklerle ben kendimi sınırlayacağım. Her iki text'e linki bu bölümün sonunda bulacaksınız

LIDS'in ana görevi dosya sisteminin korunmasıdır. Önemli dosya ve dizinleri korumak için bunlar farklı grublara ayrılırlar.

Read Only = Bu dosya veya dizin sadece okunabilir. Değişikliklere izin verilmez
Append Only = Sadece dosyaya ek yapmaya izin verilir
Exception = Bu dosyalar korunmamıştır.
Protect (un)mounting = Bir kullanıcının dosya sistemini değiştirmesine izin verilmesini ya da verilmemesini sağlar.

Gerçek koruma için bazı sistemler bu özellerini geliştiriyorlar.(ör. sys_open(), sys_mknod(), ...)
Bunula beraber, LIDS öldürülen,sonladırılan belirli prosesleride korur. Bu prosedürün amacı kullanıcıyı yöneten bazı belirli prosesleri kullanıcının görmesini engellemektir. Bir 'ps-ax' bizim prosesimizi ortaya çıkarmayacaktır. Prosesi gerçekten gizlemek için, 'PF_HIDDEN' diye işaretlenir.'ps' in proses hakkında bilgi geliştirmek için çalışması durumunda,'PF_HIDDEN' olarak işaretlenen prosesleri korunması sürecektir. Bu kendi başına prosesi gizlemek için yararlı değildir, çünkü hala geçici olarak proc dosya sistemine giriş vardır(/proc), sonuç olarak LIDS /proc dizinini göterme fonksiyonunun önlenmesi için aynı zamanda geliştirlmektedir. Bunların yanında, yeteneklerle birlikte ayrıcalıkları kısıtlama olasılığıda vardır.Eğer- örneğin- CAP_CROOT sıfıra atanırsa prosesin chroot'u kullanması önlenecektir. (/usr/src/linux/include/linux/capatibilites.h ' a bakınız).
Bununla beraber,LIDS iki güvenlik seçeneğini çalıştırma olanağına sahiptir: 'güvenlik' yada 'güveli olmayan(none_security)'. İkisinin arasındaki farkı anlatmak için 'lids_load' tan faydalanılır. Varsayılan değeri 1'dir, bu LIDS in güvenlik modunda çalıştığı anlamına gelir-sınırlamalar yasalaştırlmıştır. Eğer 'security=0' olarak başlangıçta (LILO promptu) 'none_security' çalıştırılır. Sonuç olarak bütün kontroller sınırlamar çalışmaz hale gelir. 'lids_load=0' atanarak bilgisayarın LIDS yüklenmeyecekmiş gibi çalışması sağlanır. Güvenlik seçeneğini değiştirmek için ek bir seçenek 'lidsadm-S' in online olarak uygulanmasıdır, bu bir parola gerektirir.

LIDS,CONFIG_LIDS_ALLOW_CHANGE_ROUTES active ederek ve CAP_NET_ADMIN kapatarak güvenlik duvarı kuarllarını önleme olanağıda sağlar.Eğer bir kimse güvenlik duvarı kurallarını modifiye etmek isterse,CAP_NET_ADMIN in bu kuralları başkasının değiştirmemesi için aktive edilmesi gerekir.Buna ek olarak, Siniffer'ın çalışması engellenebilir ve porrt tarayının kernelle bütünleştirilebilir.

Lids birçok yanıt seçeneği de sunar(Yanıtlar bölümüne bakınız).

Genel olarak birçok seçenek vardır. Stealth LIDS 'in nasıl kötüye kullnılacağını bildirisinde anlatmaktadır: http://www.securitybugware.org/Linux/4997.html. LIDS Howto şu adreste bulunabilir: http://www.lids.org/lids-howto/lids-hacking-howto.html.

COLOID

COLOID(Collection of LKMs for Intrusion Detection), Bir süre önce benim tafarımdan bulundu.
Projenin parçalarını bilmeye gelince iyi çalışmıyor ve proje geçici olarak durdurulmuş durumda. Buna rağmen, planlanan özelliklerin ayrıntılarına girmek istiyorum. İlk modulle(prev_exec) belirli binarylerin belirli zamanlarda çalıştırılmasını geçici olarak önlemek istedik(Kaynağımda GNU compiler kullandım GCC) Çalıştırılma yasaklandığı zaman bu kaynakta tanımlanır-zaman dakika olarak belirlenebilir.Eğer bir kullanıcı bu zamanda GCC çalıştırmak isterse bloke olacaktır,GCC çalıştırılmayacaktır. Bir kullancının izin verilen zamanda GCC yi çalıştırıp çalıştıramayacağı argümanı kontrol edilecek ve .c dosyaları için araştırılacak.Bu prosedürün amacı kaynaktaki 'tehlikeli fonksiyonaların'araştırılmasıdır. Varsayılanlar 'scanf' ve 'strcpy'....vbdir. Birçok fonksiyon eklemek mümkündür. Daha önce belirtiğimiz gibi LKM kayanakları araştırır, fonksiyonların sezilip sezilmediği, GCC nin çalıştırılması yasaklanmıştır. Kayıt dosyasına ek olarak bir 'beep' geliştirlmiştir.

Sonunda modül çalıştı fakat kavram genel olarak yeterli değildi ve kolayca atlatılabilirdi.

İkinci modül daha önce bahsettiğimiz Anomaly Dedection'ı kullanan'anom_dedection'dır. Aslında iki LKM bu bölüme aittir.
1) Anomaly_Detection.c : normal kullanıcı aktivitelerinin bi veri tabanını oluşturur
ve
2) Misuse_Detect.c : kullanıcının davranışının veritabanında kaydedilen normal davranışından farklılık gösterip göstermediğini kontrol eder.

LKM kontrolü için plan aşağıdaki gibiydi.

Aşağıdaki komutları kullanıcı nesıklıkta çalıştırdı?:

su
login
chmod
chown
insmod
ps
lsmod
rm
last
lastlog
ftp

aşağıdaki komutları kullanıcı ne zaman çalıştırdı:

ya da kullanıcı PC'yi ne zaman normal olarak başlattı ve ne zaman kapattı
Diğerleri:
Aşağıdaki dosyaları ne sıklıkta açmaya uğraştı:

/etc/passwd
/etc/group
/etc/shadow
/etc/ftpusers
/etc/ftpgroups
/etc/ftpaccess
/etc/hosts.allow
/etc/hosts.deny
/etc/inetd.conf
.....

SUID bit setiyle programları çalıştırmaya ne sıklıkta uğraştı?
Gözetlenecek dosyaların belirlenmesinde dikkatli olmalıyız.(Bunalrı ne sıklıkta açtı?) Eğer biz çok fazla dosya seçersek bu PC'nin performansına bir darbe vuracaktır. Makul olan dosyalar çalışmayacaktır.

Tam kaynağı olmayan benzer LKM'ler vardır.Bu iki modulün kaynağı aşağıda belirtilen sayfamdan alınabilir, belki birisi bununla bişeyler yapmak isteyebilir.

Kapanış Kelimeleri

Bu konunun içeriği hakkında daha fazla fikir edinmek isteyen birisi bana bir not bırakabilir:Socma(Q)gmx.net Ek bilgi, görüş ve kritikler için lütfen bana mail gönederin
Referanslar (Bunlarla birlikte text tede var):

Bu yazı için görüş bildiriminde bulunabilirsiniz

Her yazı kendi görüş bildirim sayfasına sahiptir. Bu sayfaya yorumlarınızı yazabilir ve diğer okuyucuların yorumlarına bakabilirsiniz.

talkback page

<--, Bu sayının ana sayfasına gider

Çeviri bilgisi:

de --> -- : Klaus Müller <Socma(at)gmx.net>

de --> en: Jürgen Pohl <sept.sapins(Q)verizon.net>

en --> tr: Muzaffer AYVAZ <ayvazm(at)be.itu.edu.tr>

2004-07-14, generated by lfparser version 2.43