SSH sifre denemeleri

Varsayilan SSH port’u degistirilmeyen veya SSH erisimi filtrelenmeyen her sunucu, Internet uzerinde otomatik olarak yapilan SSH sifre deneme/yanilma(Brute-Force) saldirilarina acik.

Bu gibi sistemlerin loglarinda bu aktiviteleri gormeye artik herkes alisti. Standart denemelerden farkli olarak, bu sabah gordugum bir aktivite dikkatimi cekti.
Denemeler Turkce isimlerden olusan kullanici adlari ile, Bogazici Universitesi IP bloguna ait 193.140.196.239 IP adresi kullanilarak yapilmis.

08:39’da “murat” kullanici adinin denenmesi ile baslayan denemeler, 8:41’e dogru, “wahid” kullanici adinin denenmesi ile son bulmus ve toplamda 660 potansiyel Turkce kullanici adi zayif sifrelere karsi denenmis.

Apr 30 08:39:10 _hostname_ sshd[_pid_]: Failed password for illegal user murat from 193.140.196.239 port 52828 ssh2
Apr 30 08:39:10 _hostname_ sshd[_pid_]: Failed password for illegal user emre from 193.140.196.239 port 52839 ssh2
Apr 30 08:39:10 _hostname_ sshd[_pid_]: Failed password for illegal user ali from 193.140.196.239 port 52849 ssh2
Apr 30 08:39:10 _hostname_ sshd[_pid_]: Failed password for illegal user onur from 193.140.196.239 port 52858 ssh2
Apr 30 08:39:10 _hostname_ sshd[_pid_]: Failed password for illegal user samet from 193.140.196.239 port 52872 ssh2
Apr 30 08:39:10 _hostname_ sshd[_pid_]: Failed password for illegal user ferhat from 193.140.196.239 port 52880 ssh2
… seklinde gidiyor.

Bunun gibi SSH denemeleri, DenyHosts kullanilarak engellenebilir.

Ayrica SSH uzerinden “root” kullanicisinin girisine izin verilmemeli (“/etc/ssh/sshd_config” dosyasinda “PermitRootLogin no” satirinin oldugundan emin olun) ve olasi bos sifreli kullanicilarin SSH kullanarak girisine izin verilmemelidir (“/etc/ssh/sshd_config” dosyasinda “PermitEmptyPasswords no” satirinin oldugundan emin olun).

Mart 2006 – kisa kisa

Goz acip kapadiginizi gorsun, zaman hemen geciveriyor.
Mart ve hatta Subat aylarinda yazmak istediklerimi zaman sIkintisindan dolayi yazamadim.
“to blog about” listemize bakip devam edelim…

Yazacagim bir yazilim icin ruby, python ve perl arasinda gidip geliyorum. Perl’u de eleyip ruby ve python’a bakmaya basladim. Simdilik ruby’ye daha yakin gibiyim.
Ruby’yi kendi tarafiniza hic bir yazilim kurmadan deneyebilirsiniz.
Bildigim projelerde hangi dillerin kullanildigini da aklimdan geciriyorum…
Aklima ilk gelenler; Metasploit Framework 3, ruby ile yeniden yazildi. CANVAS, SPIKE Proxy gibi Immunity tarafindan gelistirilen yazilimlarda, python kullanildi. CORE IMPACT yaziliminin modulleri ve belki bazi bolumleri yine python kullanilarak gelistirildi.
Neyse; ozet blog’u uzatmayalim.

Ucretsiz kisisel guvenlik duvari olarak kullanilabilecek CORE FORCE denemeye deger. Sadece port filtreleme degil, bir cok ek kontrolu beraberinde getiriyor.
Ilk deneme sumumunu kurdugumda problemliydi, ancak daha sonraki kuruluslarimda da kaldirmak durumunda kaldim. Ama problemin benden kaynaklanabilecegini dusunuyorum, cunku standart Windows shell’i explorer yerine Blackbox for Windows kullaniyorum. Daha onceden Check Point SecureClient gibi yazilimlarda da farkli problemler yasamistim.

Evvel zaman icinde(2006) bir musterimizdeki Websense Enterprise urununu 5.2 surumunden, son cikan 6.1.1 surumune guncelleme karari almistik. Standart yapilandirmalardan tek farki, SQL veritabaninin ayni veya dedike makina uzerinde degil, farkli bir SQL cluster ortaminda tutulmasiydi.
Standart upgrade denemesi, SQL’deki hak yetersizliginden dolayi basarisizlikla sonuclandi. Bunun uzerine dokumanlar bir daha karistirildi, net bir cevap bulunamadigindan Websense’e ticket acildi.
“Websense neden ‘sa’ kullanicisina ihtiyac duyuyor? Websense’e ayrilan SQL kullanicisina hangi haklari verirsek bu asamayi gecebiliriz? Politikalarimizdan ve SQL sunucusunun kritikliginden dolayi ‘sa’ hesabini veremiyoruz, ne yaptigini net olarak bilmeden de bu yetkiyi vermek de istemiyoruz.”
Tum ugraslara ragmen “SQL ‘sa’ kullanicisini kullanin, ne olucak” tadindaki cevaplarin disinda bir cevap alinamadi. Websense’e ayrilan SQL kullanicisina neredeyse tum yetkiler verildi ancak arsiz Websense’in istedigi ‘sa’den baska bir sey degildi.
Test ortaminda gerekli testler yapildiktan sonra Websense problemsiz upgrade edilebildi tabi ama, bunca ugras da cabasi. Websense’in notunu bu durumdan dolayi da kiriyoruz.
Oysa ki Cisco CSA oyle mi? Farkli bir SQL sunucusunda veriler tutulacaksa kurulum icin neler yapilmasi gerektigi dokumantasyonda cok detayli olarak anlatilmis.

Metasploit ekibi kendi bloglarini olusturmus.

Emektar, Debian ile yeniden hayatta

Uzun suredir kullanilmayan eski Pentium 133, 64mb RAM’li makineme hem Snort vb. kurmak, hem de cesitli denemeler yapmak icin kollari sivadim. Simdilik uzerinde Slackware 8.0 kurulu (kernel 2.2.x) olan bu canavari sifirdan kurup yeniden canlandirmakta kararliyim. Kurulumu yaptigim sirada da, bu yaziyi yaziyor olacagim.
Makine uzerinde 2 disk var; ana disk linux, digeri ise Windows 98. Iki isletim sisteminde de, su an artik kullanilmayan, veya hala kullanilan yazilimlarin eski surumlerini gormek insanin anilarini canlandiriyor :)
Bunlarin hatrina ve olur da eski haline getiririm diye dusunerek yedek aliyorum. Makinemin diskleri dolu oldugu icin, hemen bir NFS server ayarlayip, olusturdugum backup klasorune mount ederek yedekleme islemini yapiyorum.

Gelelim Pentium 133 uzerine kurulacak Linux dagitimini secimine. Ilk goz agrim, 3.5 surumunden beri kullandigim Slackware. Uzun suredir Gentoo Linux makineleri yonetiyoruz ve kullaniyoruz. Paket yonetimi, guvenlik guncellemeleri, kurulan yazilimlar makineye gore derlendigi icin kurulduktan sonraki calisma performansi cok iyi, dagitimin tum araclarina ve yapisina hakimim. Diger tarafta ise Debian var. Debian kullananlarin -bence- biraz fazla fanatikligi beni bu dagitimdan uzaklastiran baslica nedenlerden. Stabil dagitimindaki fazla stabil olma arzusu da paketlerin biraz geriden gelmesini sagliyor; ama heralde ben istedigim gibi guncelleyebilirim. Debian’in paket yonetimi harika.
Su an benim icin en gerekli olan sey, paket yonetimi kolayligi. Makineyi kafamda belirledigim duruma getirmek icin fazla zaman harcamak istemedigimden, istedigim bir yazilimin hazir paketini internet uzerinde kolayca bulmak ve kurmak istiyorum. Yine bir guncelleme oldugunda bu guncellemeyi cok fazla efor sarfetmeden kurabilmeliyim. Slackware’i bu nedenle eliyorum.
Gentoo kurdugumda P133 makinem -kapasitesine gore- gayet iyi calisacaktir. Ama islemcinin yavasligini, ve eski gunlerdeki ozellikle kernel derleme sirasindaki bekledigim zamani goz onunde bulundurarak bunu da eliyorum.
Bu kosullarda Debian ile mutlu olacak gibiyim. Bu dagitimla daha fazla hasir nesir olmak istemem de Debian yonundeki isteklerimi arttiriyor ve karar veriyorum. Hemen network install cd image indirip rewritable mini cd’me yazdiktan sonra kuruluma hazirim.

Debian ISA ethernet kartimi tanimiyor. Artik kimsenin bu kartlari kullanmadigi donemde bu normal. Ama en azindan kurulum menusunde ethernet kartimi “ne” olarak secip, IO ve IRQ degerlerini girmeme izin vermesi guzel. Karti kolayca tanitiyorum. Sistem once DHCP’den IP alamiyor, ancak hemen ardindan tekrar otomatik IP yapilandirmasini denemesini istedigimde alabiliyor. Belki DHCP sunucusundan olabilir diyerek devam ediyorum.
Diskimi otomatik olarak bicimlendirip kurulum asamasina gectigimde GRUB kisminda takiliyorum, kurulum kitlenip kaliyor. Kurulum islemini yeniden baslatip, bu sefer disk bolumlerini kendim olusturuyorum:
/boot ~40mb (ext2) *
swap ~200mb
/ <kalan> (ext3)
Acikcasi fdisk’e o kadar alisigim ki, bu disk bolumleme aracindan pek hoslanmiyorum.
GRUB kurulumu sirasinda yeniden takiliyor. Dakika 1, Bug 1.
Expert modunda kurmak icin kollari siviyorum. Tekrar boot ederek “expert” diyorum ve gelen menuden tek tek islemleri gerceklestiriyorum. Burada GRUB’u gecerek Lilo’yu kurabilecegimi goruyorum, ancak Lilo da sisteme kurulmuyor. Daha sonradan sonra kendim ayarlamak uzere boot loader kismini geciyorum.

Sistemi ilk actigimda bolca hata mesaji ile karsilasarak kurulumun kalan kismina devam ediyorum.
root sifresi belirleyip, kendime bir kullanici actiktan sonra diger konsola gecip ethernet kartimi tanitiyorum ve “/etc/init.d/networking start” komutu ile DHCP’den IP aldirtiyorum.
Debian, sistemimi nasil kullanabilecegimi secmeme izin veriyor. Basta testing secmek istesem de, guvenlik guncellestirmeleri ana nedeninden dolayi stable seciyorum. Bunlar arasinda daha sonradan gecis yapilabilecegini ogrendigimden, istersem testing veya unstable’a gecebilirim. (Debian testing security team, testing’deki guvenlik guncellestirmeleri eksikligini gidermek icin kurulmus, ama ben bir sure stable olarak kullanip Debian’i daha yakindan tanimak istiyorum)

Network kategorisindeki paketlerde Stable, Testing ve Unstable‘i karsilastirdigimda testing ve unstable arasinda cok fazla fark gormedigimi belirtmeliyim. Belki kisa bir sure sonra Testing branch’ine gecebilirim. (Ornegin MySQL 5 stable’da bulunmuyor)
Kurulumla fazladan gelen bazi paketleri kaldirip kullanacagim paketleri kuruyorum.

Sistem artik kullanilmaya hazir. Cesitli ayarlari yaptiktan ve Debian’i biraz daha tanidiktan sonra cok daha rahat edecegime eminim. ^D

IntruShield 3.1 Serisi Yeni Ozellikler

McAfee IntruShield saldiri tespit ve engelleme sistemi, sensor ve yonetim yazilimlarinin 3.1 surumu serisini duyurdu. Bir grup IntruShield manager ve sensor’u bu yeni surume gecirebilmek icin incelemeye basladim.

Yeni Gelen Ozellikler
IntruShield’in, daha onceki 1.9.x ve 2.1.x serisinden farkli ozellikleri

  • Manager Disaster Recovery (MDR): 2. bir IntruShield Manager yaziliminin kurulup kullanilabilmesine olanak sagliyor. Bu ozellik sayesinde, 2. bir IntruShieldyonetim yazilimi fail-over ve disaster recovery icin kurulup kullanilabilir. Active/Standby modunda calisiyor. Bir sensor iki manager’la da baglanti halinde, ancak loglari primary manager’a gonderiyor. Secondary manager, periyodik olarak primary manager’dan konfigurasyon bilgisini aliyor, ancak log ve alert bilgisini senkronize etmiyorlar. Bu islem alert archival mekanizmasi ile manuel olarak yapilabilir.
  • Vulnerability Assessment (VA): FoundScan ve Nessus guvenlik aciklari tarama yazilimlarinin sonuclarini IntruShield’a import edebilmek mumkun hale gelmis. Bu islem, uretilen alarmlarin onceliklendirilmesi ve etkisinin daha rahat incelenmesini saglayacaktir. Foundstone’u almasinin ardindan, McAfee, ISS‘te daha onceden olan bu ozelligi kendisine eklemis.
  • The Global Attack Response Editor (GARE): Bir saldiri ile karsilasildiginda ne yapilmasi gerektigi, yani response, (saldiri paketini engelle, TCP RST paketi gonder vb.) politikalarda belirtilmektedir. Bir saldiri imzasi icin ayarlanmis olan response’u degistirmek icin bu saldirinin bulundugu politikaya gidip degistirmek gerekir. GARE ozelligi ile, politikalara tek tek girip degisiklik yapmaya gerek kalmadan, bir kerede, herhangi bir saldiri imzasinin response ayarini degistirerek tum politikalarda bu sekilde aktif olmasini saglamak mumkun oluyor.
  • SYN Cookie Proxy Ozelligi: Servis kullanimini engelleme (DoS) saldirilarina karsi eklenen bu ozellik, bir sunucu ile olan baglantilari IntruShield’in karsilayarak, sadece gecerli baglantilarin sunucuya iletilmesini saglamakta. Bu ozellik firewall yazilimlarinda da mevcut.
  • IPv6 Trafigi Inceleme Destegi: Daha onceden bu IP surumundeki paketler icerigine bakilmadan iletiliyordu.
  • ACL Logging: 2.1 serisi ile gelen access-list ozelligine, 3.1 serisinde loglama olanagi eklenmis. Sensor, access-list loglarini bir syslog sunucusuna gonderebiliyor.
  • Alert Viewer Yenilikleri: Saldirilarla ilgili alarmlari gormemizi saglayan alert viewer’a gelen yeni ozelliklerden bazilari yapilan islemleri oldukca kolaylastiracak.
    • Herhangi bir alarma sag tusla tiklayip, bu alarmin oldugu politikayi degistirmek artik mumkun. Bu sayede alarmin response ayarlarini degistirebilir, veya alert filter yazabilirsiniz. Alert filter, haric tutma(exclude) islemleri icin kullaniliyor.
    • Tools menusune “update sensor configuration” kisayolu eklenmis. Degistirilen politikanin sensore uygulanmasi gerekiyorsa, bu kisayol kullanilabilir.
  • RADIUS/LDAP/TACACS+ Entegrasyonu: IntruShield Manager’a girilirken kullanilan kimlik dogrulama islemi, harici bir RADIUS veya LDAP(Or: Sun One’s Directory Server, Microsoft Active Directory) sunucusu kullanilarak yapilabiliyor. Sensor tarafindaki authentication’da ise TACACS+ kullanilabiliyor.
  • IntruShield Sensor SNMP Destegi: Sensorun SNMP ile izlenebilmesi saglanmis. Sadece read-only SNMP erisimi var.
  • Windows 2003 Destegi: Sonunda, McAfee IntruShield Manager Windows 2003 uzerinde desteklenir hale gelmis. Yani manager yazilimi Windows 2003 isletim sistemine artik kurulabilir. (Eski surumlerini test ortamlarinda problemsiz calistirmistim)

Eklenen diger ozellikler arasinda; kullanim kolayliklari, cesitli arabirim degisiklikleri, uretilen alarmlarin SNMP ile gonderilebilmesi (trap), manager arabiriminde performans artisi, sensor saldiri tespit yeteneginin artisi, manager’da saklanan paket loglarinin encrypt edilebilmesi, sensor tarafindan bilinen protokollerdeki artis vb. sayilabilir.
Manager client icin artik JRE 1.5.0_04(Java Runtime Environment) gereksinimi bulunuyor. Daha onceden JRE 1.3.x gerekiyordu.

Umarim upgrade ve yeni kurulumlar problemsiz gecer.

IntruShield Manager Password Recovery

McAfee IntruShield urununun yonetim yaziliminin sifresinin unutulmasi durumunda, MySQL uzerinden sifreyi orjinal haline dondurebilmek mumkun.

Bunu yapabilmek icin, IntruShield manager yaziliminin kurulu oldugu sunucuda MySQL client yazilimini kullanarak (Or: komut satirinda “c:\mysql\bin\mysql.exe -u root -p” ile) asagidaki SQL sorgusunu calistirdiktan sonra, sifre eski haline gelecektir.
username: admin
password: admin123

— buradan kesin ——–
use lf;
update iv_usercredential SET crval=’3304b042e5d8426e5f503e58723cd931′ WHERE uuid=1;
quit;
— buradan kesin ——–

Bunun IntruShield manager 1.9.x ve 2.1.x serilerinde problemsiz calistigini soyleyebilirim.

IntruShield yonetimi icin uzun bir suredir 1.9.x serisi kullanilmaktaydi. 2.1.x serisinin kullanilabilir surumlerinin cikmasinin ardindan, 3.1 serisi hic beklemedigim bir hizla cikti.
Bu seriyi ilerleyen gunlerde test edip deploy ettikten sonra tecrubelerimi paylasacagim.

Bir Cisco switch’e bagli olan cihazin hangi port’tan bagli oldugunu bulmak

Bugun SPAN port yaratacagim bir Cisco Catalyst 3750 switch uzerinde bagli bulunan bir makinanin hangi porttan bagli oldugunu yerimden kalkmadan bulmak icin asagidaki yontemi izledim.

# ping IP_Address
komutu ile hem cihazin ulasilabilirligini test edip, hem de switch’in ARP tablosunda bulunmuyorsa eklenmesini sagladiktan sonra
# sh arp | inc IP_Address
Burada IP adresine sahip olan network kartinin MAC adresini gordum ve dogruladim. Artik yapmam gereken
# sh mac-address-table | inc MAC_Address
veya
# sh mac address-table | inc MAC_Address
komutlarindan birisi ile cihazin hangi switch port’undan bagli oldugunu gormekti

Mac Address Table, sirasi ile “Vlan, Mac Address, Type(STATIC/DYNAMIC), Ports” degerlerini veriyor.