
|
 |
Ana sayfa
Kütüphane
Ürün dokümanları
|
|
|
Yazar: Ertan Kurt
|
Yayınlanma tarihi: 16.05.2001 12:18
|
Aşağıdaki yazı 2600 1999 sayısından alınmıştır. NMAP`in o anki (eski) sürümüne göre yazılmış fakat NMAP`in günümüzdeki haline gelmesine çok yardımcı olmuş bir doküman olduğu için olympos`ta bulunması gerektiğini düşündüm. /CronoS
NMAP, Fyodor tarafından yazılmış ve SYN, FIN gibi çeşitli tarama tiplerini yapabilen bir ağ tarayıcısıdır. Uzun zamandır unix sürümleri vardı ama windows`a da port edildi.
Çaylak çalışması #1: SYN ve FIN nedir? Bunların taramayla alakası nedir? TCP/IP protokolünü inceleyin (özellikle TCP/IP pakedinin yapısını). Ayrıca Fyodor`un web sayfasında nmap dokümanlarını okuyun.
Elite çalışması #1: Arkaya yaslanın ve rahatlayın. Değerli bilgiler geliyor.
Şimdi, Nmap`in çok harika bir yazılım olduğunu düşünüyorum fakat bahsetmek istediğim bir kac nokta var ve herkes bundan birşeyler çıkarabilir. Göreceğiniz gibi bir gizli (stealth) tarama bazen gizli olmayabiliyor.
İlk olarak, bir connect() taramasının loglandığını söylememe bile gerek yok. Bu -t seçeneği ve aynı zamanda varsayılan seçenek. Eğer izninizin olduğu bir ağ üzerinde yapacaksanız problem yok. Fakat eğer bir parça gizlilik istiyorsanız -s, -u veya -U seçeneklerini kullanmayı unutmayın. Bu şekilde normal bağlantıları kullanmazsınız.
Çaylak için ipucu: Bir connect() taraması diğer sisteme normal bağlantılar kullanır, herhangi bir gizleme uygulamaz ve çoğu zaman loglanır (ki buda kötüdür). İsmi 'connect()' çünkü bu işlemi yapan programlama fonksiyonunun ismidir.
Bir NT 4.0 sp3 sistemde connect() taraması sonrası herhangi bir log bulamadım fakat NT öncesindeki bir güvenlik duvarı yada router bu taramayı kolaylıkla yakalayabilir.
Ayrıca, pek çok durumda -F (hızlı tarama) özelliğini kullanabilirsiniz. Bu sadece /etc/services (strobe gibi) de bulunan servisleri tarayacaktır. Bu gönderilen paketlerin sayısını azaltacak ve gerçekten sadece önemli port`ları tarayacaktır.
Çaylak çalışması #2: Unix bir sistemde, /etc/services dosyasına bir göz atın. Port fikrini ve genel port atamalarını (ftp, telnet, smtp, dns, pop, imap) öğrenmelisiniz. Ayrıca strobe nedir? Araştırın. O da başka bir tarama (biraz eski) aracıdır. Ne yapar? Gizli tarama yapabilirmi?
Elite çalışması #2: -p seçeneği ile özel port listesi yaparak o engin port bilginizi gösterin. Örneğin, çoğu sistemlerde SSHD (test: hangi porttu?) /etc/services içinde değildir. Bu yüzden eğer onu bulmak istiyorsanız yapmanız gereken 1) /etc/services e ekleyin. veya 2) -p seçeneği ile belirleyin.
Nelerin bulunabildiğini görmek için evdeki sistemler üzerinde birkaç deneme yaptım. Ve ağda nelerin gezindiğini görmek içinde NetXray ile sniff ettim.
Çaylak çalışması #3: Ağ dinleyiciler (network sniffers) hakkında araştırma yapın. En çok bilinenler hangileridir? Switch kullanılan bir ortam sniffing`den nasıl etkilenir?
Elite çalışması #3: tcpdump kullanın. Raw çıktı kodlarını okuyun ve alışverişlerin tamamını izleyebilin. Eğer yapabilirseniz, kralsınız! (yada kraliçe).
Evet şimdi 2 sistem üzerinde aldığım bazı basit sonuçlar:
RedHat Linux üzerinde SYN scan denemesi:
Açık portları doğru olarak buluyor fakat loglarda iz bırakıyor:
/var/log/messages:
Jul 7 05:16:12 empri ftpd[404]: getpeername (in.ftpd): Transport endpoint is n$
Jul 7 05:16:13 empri named[241]: accept: Connection reset by peer
Jul 7 05:16:36 empri lpd[252]: accept: Connection reset by peer
Jul 7 05:16:36 empri rlogind[407]: Can`t get peer name of remote host: Transpo$
Jul 7 05:16:36 empri rshd[408]: getpeername: Transport endpoint is not connect$
/var/log/secure:
Jul 7 05:16:12 empri in.telnetd[405]: connect from unkown
Jul 7 05:16:36 empri in.rexecd[406]: warning: can`t get client address: Connec$
Jul 7 05:16:36 empri in.rexecd[406]: connect from unkown
Jul 7 05:16:36 empri in.rlogind[407]: warning: can`t get client address: Conne$
Jul 7 05:16:36 empri in.rlogind[407]: connect from unknown
Jul 7 05:16:36 empri in.rshd[408]: warning: can`t get client address: Connecti$
Jul 7 05:16:36 empri in.rshd[408]: connect from unkown
Kaynak belli değil ve port listesini doğru olarak buluyor.
Win NT 4.0 sp3 üzerinde Syn scan denemesi:
Port listesini tam ve doğru olarak buluyor. Fakat MS DNS, App event loglarına iki adet log bırakıyor. kaynak: dns, event: 1 & 2. Her ikisininde tanımı yok ve anlamsız giriş satırları var. Bunun port taramasından olduğunu özel olarak bilmiyorsanız tamamen şifrelenmiş gibi:
' The description of Event ID (1) in Source (DNS) could not be found. It contains the following insertion string(s):.'
Çaylak çalışması #4: Eğer yapabiliyorsanız, bir Unix (Linux) makine kurmayı deneyin ve log`lar (/var/log) ve servisler (ftpd, lpd vb) hakkında bilgi sahibi olun. Yada b,r NT 4.0 sunucu kurun. Bu arada sp3 service pack 3 uygulandı demektir.
Elite çalışması #4: Örnek tarama listelerim fazla detaylı değil. Solaris, HPUX, AIX vb üzerinde taramalar yapıp neler bulabileceğinize bakın.
Benim UDP tarama tecrübelerim hiçte iyi değil. NT ve Linux üzerindeki denemelerim port`ları düzgün olarak bulamadı. Fakat NT taraması sırasındaki bir paket yakalama çıktısına göre, açık olmayan bir UDP port`una karşı ICMP 'port unreachable' mesajı dönüyor ve açık olan bir port için ise hiçbirşey dönmüyor. Bu tarama NT için çalışabilir fakat yazılım şu an için çalışmıyor yada böyle birşey beklemiyor.
Elite çalışması #5: Bunu nasıl düzelteceğinizi düşünün. Varsayılan zamanaşımını arttırmak kadar basit olabilir.
Dikkat edilmesi gereken bir nokta, NT TCP port 80`e bir UDP paketini alıyor fakat geriye ICMP 'port unreachable' mesajı dönmüyor fakat Linux dönüyor (her ikisinde de web sunucusu aktif). Sanırım bu daha önce yayınlandı, o yüzden geçiyorum.
İlgi çekici bir diğer noktada gönderilen her paketin data olarak 'blah' içermesi. Bu firewall`da filtrelenebilir ve 'blah' içeren herhangi bir UDP pakedine rastladığında sistem yöneticisini port taraması olduğu yönünde uyarabilir.
Çaylak çalışması #5: nmap.c`de 'blah' kelimesinin geçtiği satır 920. Kaynak kodunu değiştirerek bunu 'blah' yerine boşluğa (0x00) çevirin. Gerek varsa C ile biraz tanışın.
Elite çalışması #6: Daha yaratıcı olun. 'blah' yerine rastgele (random()) bilgi kullanın. Ve yine nmap.c de satır 920.
Benzer bir şekilde SYN ve FIN taramalarıda yakalanabilir. Tüm paketlerin kaynak portu aynı (49724).
Çaylak çalışması #6: nmap.h ve tcpip.h dosyalarında gönderilecek her paket için bir #define MAGIC_PORT tanımlaması vardır. Bunu başka bir port`a çevirin. Dikkatli olun! Hangi port numaralarını geçerli olduğuna emin olun. (Hangi port menzilleri ayrılmıştır? En yüksek port numarası kaç olabilir?)
Elite çalışması #7: Gönderilen her paket için MAGIC_PORT`u değiştiren ek fonksiyonlar yazın. Ve bir ipucu: Sıralı artışlar yakalanabilir. Yaratıcı olun. 1-5 port aralıklarıyla rastgele artışlar yapın.
Ayrıca, her paket için '\n\help\nquit\n' olarak 'frame padding' var.
Çaylak çalışması #7: '\n\help\nquit\n' yazısını başka bir şeye çevirin. Bu sefer nereye bakmanız gerektiğini söylemeyeceğim. Bulmak için Unix`deki 'grep' komutunu kullanmanızı öneririm. Eğer bu komut hakkında bilgiye ihtiyaç duyarsanız 'man grep' komutunu kullanın.
Elite çalışması #8: Bulup bilinmeyen birşeye değiştirin. Tercihen rastgele bilgi.
Unutmayınki bir vanilla (vanilla= kaynak kodu değiştirilmemiş) nmap taramasını yakalayacak filtre kuralları yazmak çok kolaydır. Port 49724 dan gelen ve 'QUIT' içeren gibi.
Yukardaki örnek taramalardan bir ikilem olduğunun farkına varabilirsiniz. Eğer bir sistemde hangi işletim sisteminin çalıştığını bilmiyor ve bir FIN taraması yaptıysanız, Linux bir makina için doğru sonuçlar alırsınız fakat bir NT için alamazsınız. Ve eğer bir SYN taraması yaptıysanız, Linux makine bunu log`layacaktır fakat NT için doğru sonuçları bu şekilde alabilirsiniz. Bu ne demek?
Hangi işletim sistemini tarıyor olduğunuzu bilmek çok önemlidir! İşletim sistemleri gizli taramalara farklı cevaplar verirler. Bu yüzden yaratıcı olup bunları önceden bulmanız gerekir. Yeni bir program olan 'queso' nun ardındaki fikir budur.
Çaylak çalışması #8: queso`yu bulun ve çalıştırın (Unix platformu içindir).
Elite çalışması #9: queso kendini gizleyebiliyormu yada loglanıyormu? Raw paket çıktıları haricinde queso olduğunu belli eden işsaretler varmı?
Ayrıca, kısa bir süre önce (bu yazı yazıldığı sürede) Shadow tarafından taramalarda bulunanlarla ilgili bir mesaj gönderildi.
Çaylak çalışması #9: Shadow kimdir? Size bir ipucu vereyim: onlar hükümettir. Arayın.
O mesajdan birşeyi belirtmeliyim: Günde iki paketten oluşan taramaları dahi yakalamak mümkün! Günde 1 paketten oluşan taramaları bulmakda pek çok yanlış alarma yol açabilir. Size bir ipucu vereyim... Shadow sistemi tcpdump çalıştıran ve çok büyük harddisk kapasitesine sahip bir kaç sistemden oluşur. Her pakedi loglar ve geçmiş birkaç günün bilgisini bir araya getirip analiz ederler. Hiçbir gizli tarama bunadn kaçamaz. Radara yakalanmamak için bir beyin hücrenizi daha harcamanız gerekiyor.
Bu noktada, herkese söylemek istediğim birşey var:
Shadow 'hacker`ların tarama çabalarında birbirlerine yardım ettiklerini' rapor ediyor. Üzgünüm ama o dokümanın içinde bunu destekleyecek birşeye rastlamadım.
Nokta 1: Eğer iki hacker farklı yerlerden ortak bir hedefe tarama yapıyorlarsa, IP ve port atamalarında çakışma olmamalı. (ör. bir port iki kere taranmamalı) Ya bu hacker`lar aptal yada beraber çalışmıyorlar. Aynı yeri aynı zamanda tarıyor olmalılar.
Nokta 2: Bir tarama için iki farklı coğrafik kaynağın olması bu işi iki kişinin yaptığına kanıt değildir. İki farklı makinaya iki telnet açıp oralardan aynı hedefe tarama yapmamı kimse engelleyemez. Taramasını iki farklı kaynağa bölen birisi olabilir.
Ok, burda neler öğrendik? Umarım işe yarar şeyler. Ve umarım bazı çaylaklar sırada yapmaları gerekeni biliyorlar. Bu tarama yazısını bir iki ipucu ile bitireyim:
-
Herhangi bir sistem yada port`u iki defa taramak saçmadır. Organize olun ve gönderdiğiniz paket sayısını azaltın.
-
Paketleri belirli aralıklarla göndermek saçmadır. Paketler arası gelişigüzel aralıklarla olmalıdır. Her iki paket birbirine çok yakın aralıklarla gönderilmemelidir.
-
Sabır bir erdemdir. Günde bir paket iyidir.
-
Dağınık kaynaklar (coğrafik yada değil, fakat aynı organizasyondan değil) gereklidir. Ve ipucu #3 her kaynak için geçerli değil bütün kaynakların tümü için geçerlidir. Yani 5 kaynak sisteminiz varsa, her 5 günde bir paket sistem başına olacak şekilde ve çakışma olmayacak şekilde ayarların)
-
Bizler basit varlıklarız ve genelde herşeyi sıralı olarak yaparız. Fakat taramaları sıralı bir düzende (yada ters sırada) yapmanız için hiçbir sebep yok.
Unutmayın: Günümüzde ve çağımızda ağ yeterliliği ve dayanıklılığı artıyor. Bir paketin yanlış route edilmesi çok zor. Tamamen rastgele paket kavramı nadirleşiyor ve paranoya pakedin planlandığını kolayca ortaya çıkarabilir.
rain forest puppy
|
|
 |

|