Warning: mysqli_query(): (HY000/3): Error writing file '/tmp/MYDVxdBS' (Errcode: 28 - No space left on device) in /usr/share/nginx/html/syslogs/wp-includes/class-wpdb.php on line 2349

Bilindiği gibi, *nix tabanlı işletim sistemlerine güvenli bir şekilde uzaktan erişmek için kullanılan ssh (secure shell), telnet ve rlogin gibi alternatiflerin tersine, bağlantı sırasında her türlü veri trafiğini şifreleyerek güvenliği had safhaya çıkarıyor. Bu nedenle de hemen her sistem yöneticisi remote erişim için ssh'ı tercih ediyor.

Bir ssh bağlantısını, bağlanılmak istenen sisteme direk olarak kullanıcı adı ve şifre göndermek sureti ile gerçekleştirebildiğimiz gibi bağlantıyı SSH Key-Based authentication isimli yöntemle kullanıcı adı ve şifreye gerek kalmaksızın sağlayabiliyoruz. Yönetiminden sorumlu olduğunuz birden çok *nix tabanlı serverınız olması durumunda Key-Based kimlik doğrulama yöntemi elbette işleri epey kolaylaştırıyor.

Bu yöntemde, uzaktaki sisteme bağlantıda bulunacağınız bilgisayarda public ve private key diye tabir edilen iki adet anahtar dosyası oluşturuyorsunuz, Public Key uzaktan erişim sağlanacak hedef bilgisayarda tutuluyor ve Private Key de, key'i oluşturduğunuz bilgisayarda kalıyor.  Kullanıcı private key'ini kullanarak bağlantı isteğinde bulunduğu zaman hedef bilgisayar gelen isteği elindeki public key ile karşılaştırıp doğruluyor bağlantıyı gerçekleştiriyor. Bağlantı sırasında bilmeniz gereken tek şey keyleri oluşturma sırasında belirlenen Passphrase denilen private key şifresi oluyor. Hatta isterseniz Passphrase dahi kullanmayabilirsiniz. Bu uygulamayı *nix tabanlı sistemlerinizde yaptığınız zaman uzaktan erişim işlemlerinde herserverin kullanıcı adı ve şifresini teker teker girmenize gerek kalmıyor.

Ancak, elbette bu uygulama tahmin edebileceğiniz gibi bazı güvenlik açıklarına neden olabiliyor; bu yazının ana konusu da aslında bu.

Key-Based authentication kullanışlı olmasına rağmen aynı zamanda sistem güvenliğinizin yumuşak karnı da olabilecek bir potansiyele sahiptir. Zira client bilgisayarda bulunan bir private key başkalarının eline geçerse aynen sizin gibi o kişiler de sistemlerinize kullanıcı adı ve şifre olmaksızın bağlanabileceklerdir.

Bunun yanı sıra aslında bu bu yazıyı yazmamın ana nedeni yukarıdaki yumuşak karın mevzusundan çok, US-CERT tarafından 26 Ağustos'ta açıklanan, linux Tabanlı işletim sistemleri için, key-based erişim uygulamasında keşfedilen bir saldırı yöntemi.

http://www.us-cert.gov/current/index.html#ssh_key_based_attacks adresinde yayınlanan rapora göre, linux tabanlı sistemlerde SSH Key-Based authentication kullanılması durumunda ortaya çıkabilecek yeni bir saldırı şekli tespit edilmiş. Buna göre saldırı şekli, ilk olarak SSH keyleri çalarak sisteme login olunup, sonrasında lokal kerneldeki zayıflıklardan yararlanılarak root erişiminin sağlanmasıymış. Root olarak sisteme erişildikten sonra ise sisteme “phalanx2” isimli bir rootkit kurulduğu söyleniyor.

Raporda, Phalanx2'nin amacının sistematik olarak, -key-based auth. konfigurasyonları nedeni ile- güvenilir olarak algılanan diğer sistemlerin SSH keylerini çalmak ve atakta bulunan kişiye göndermekten ibaret olduğu açıklandı. Böylece attacker bu keylerle, ilgili tüm sistemlere erişimde bulunmayı deneyerek sonuca ulaşmaya çalışıyormuş.

Sisteminizde bu rootkitin yüklü olup olmadığını anlamak için aşağıdaki adımlar işinize yarayabilir.

• rootkit /etc/khubd.p2/ dizininde bulunabiliyormuş. Ancak ls komutu ile bu dizini görmek mümkün değil; bu nedenle cd komutu ile dizinin içerisine girmek gerektiği söyleniyor.
• /dev/shm/ dizini altında atakla ilgili dosyaların bulunabileceği belirtiliyor.
• Ayrıca sistemde çalışan gizli bir proses olup olmadığının araştırılması,
• /etc'nin alt dizinlerini count ederek adet bilgisini “ls /etc” çıktısında belirtilen rakamla tutup tutmadığının kontrol edilmesi öneriliyor.

Hal böyle olunca bu ataktan etkilenmemek için, Key'lere muhakkak Passphrase tanımlamak, Tcp erişimlerini gözden geçirmek, sisem patchlerini düzenli geçmek gibi önlemler almak gerekiyor. Hatta belki de key-based authentication yöntemini rafa kaldırmak en iyisi gibi görünüyor.