Sistem güvenliği için yeni bir pencere
Çalıştığım yerin sistem yönetiminden sorumlu olduğumdan beri teknik bilgilerimi zamanında tamamlayamama endişesinden çok sistem güvenliğini dert ettim. İlk adımlar haliyle en çok bilinenlerdi, kullanılan servis sayısını azalt, portlara erişim kısıtlaması getir ve sık sık güncellemeleri gerçekleştir.
Elbette ki yeterli olmuyor asla. Eskiden "en güvenli bilgisayar, ağ bağlantısı olmayandır" denirdi ancak görünen o ki bazı yeni teknolojiler sayesinde bu tez de çürütülmüş durumda. (Henüz ben uygulamasına rastlamamış olsam da)
Ama aktif kullanılan bir sunucu için elbette ki ağ bağlantısının kesilmesi söz konusu olamaz. Her gün yeni bir güncellemeyle karşılaşmaktan, bir exploit'in yayınlanmış olduğunu öğrenmekten canım çok sıkılır oldu. Bir güvenlik açığının bulunması - dağıtılması - keşfedilmesi - onarılması arasında geçen süre hiç de azımsanacak kadar değil -- malesef Epsilon mertebesindeki süreçlerden bahsedemiyoruz :)
Günler şüpheli eylem özetlerini incelemekle, zaman buldukça sayfalar dolusu raporları okumakla, güncellemeler yapmakla ve türlü cinliklerle yapılan ataklara başka türlü cinliklerle yanıt vermeye çalışmakla geçer oldu.
Ve geçenlerde bir yazı okudum. "The Six Dumbest Ideas In Computer Security" (http://www.ranum.com/security/computer_security/editorials/dumb/)
Sistem yönetimiyle uğraşanların (hatta yazılım geliştiricilerin) mutlaka okuması gerektiğini düşündüğüm bir yazı. Saldırılara ve tehditlere karşı savaşırken veya önlem almaya çalışırken izlenen yöntemlerin aslında ne kadar tehlikeli (ve yazarın diliyle, aptalca) olduğunu gösteren bir makale.
Özellikle ilk üç madde için söyledikleri olmak üzere, 6 maddenin 6'sı da etkiledi beni. (En sondaki minör maddeler dahil)
Raporlarla ilgili kısımı okuyunca yeni bir karar aldım. Sistemin şüpheli gördüğü eylemleri takip etmektense, şüpheli olmadığına emin olduğum maddeler hariç ne varsa takip etmeliyim.
Böylece logwatch yazılımının yerini logcheck aldı. Aslında her ikisini de aktif olarak izliyorum ancak logcheck çok daha ilginç noktalar sunuyor.
Özet olarak anlatırsam; logwatch, sistem raporlarını tarayıp çeşitli istatistikler tutuyor ve sistem üzerinde gerçekleştirilenleri belli filtrelere göre "human-readable" şekilde sunuyor. Böylece sisteme kim giriş yapmış, ne kadar veri aktarılmış, gibi "kayda-değer" veriler özet şeklinde yöneticilere gönderiliyor. Burdaki sorun "kayda-değer" verilerin ne olduğu.. Herşey ön-tanımlı olduğu için, her yazılım kontrol edilmediği için ve sistemin rolü yapıdan yapıya değiştiği için kimi zamanlar bu özet yeterli olmayabiliyor.
Kalan eksik noktaları tamamlamak için ise logcheck yazılımı devreye giriyor. logcheck'in yaptığı da şöyle: sistem raporlarındaki bütün veriler alınıp tanımlanmış pattern'e uyan veriler gözardı ediliyor. Örneğin, "kullanıcı@domain.com adresine email gönderildi" şeklinde bir rapor satırı belli bir sunucu için önemli olmayabilir. Bu gibi satırlar belirlenip gözardı ediliyor ve geriye kalan tüm satırlar yöneticilere gönderiliyor.
Tamamen özelleştirilebilir bir yapıda. Her servise ait yapılandırma dosyası düzenlenebiliyor böylece görülmek istenen girdilerin alınması sağlanabiliyor. Özel servisler (yani gözardı-etme-verisi bulunmayan servisler) için ise bu verilerin oluşturulmasına olanak sağlanmış. Amaç makalede bahsedilen düşüncenin gerçeklenmesi: throw away the log entries you know aren't interesting. If there's anything left after you've thrown away the stuff you know isn't interesting, then the leftovers must be interesting.
Birkaç gündür bunun üzerinde çalışıyorum. İlk zamanlar sayfalar dolusu raporlar gelirken şimdi 4 satırlık bir rapor geliyor (ki o 4 satır da yapılandırma hatasından kaynaklanan bir girdi).
Böylece ön-görmediğim birşey olması durumunda haberdar oluyorum.
Elbette ki iş işten geçtikten sonra (yani o ön-görmediğim durum gerçekleşince) bunun raporunu almanın faydası olmuyor diyebiliriz ilk bakışta. Evet, ama aynı zamanda hayır. Ön-görmediğim durumun sonuçları büyük değilse bu raporlar önlem almamı sağlayabilir. Eğer bu ön-görülmemiş durum bir zarara yol açtıysa, evet bu gerçekten de büyük bir sorun. Bu durumda disaster-recovery ve ardından attacker-identification süreçleri devreye girmeli ki bunlar da şu sıralar oluşturmaya çabaladığım çözümler. (Tüm raporların eş zamanlı olarak uzaktaki bir sunucuya gönderilmesi ve sık sık incremental backup'ların alınması gibi)
---
Uzun lafın kısası, geleneksel yöntemler geleneksel şekilde planlanmış ataklar için çözüm sağlayabilir. Bir "açık" ise sıradışı bir bakış açısıyla keşfedilir. Bu durumda geleneksel ve ön-görülmüş çözümler yetersiz kalır. Önceden düşünülmeyeni izleyebilmek ve en kötü durum senaryosu olduğu taktirde sistemi hayata geçirebilmek yapılması amaçlanan çözümler olmalıdır.
posted by Arda @ 11:09 PM
0 comments
