Showing posts with label firewall. Show all posts
Showing posts with label firewall. Show all posts

Thursday, November 6, 2014

Ölüm Zincirinin diğer halkaları

Ölüm zinciri konusunda en kapsamlı araştırmayı yapan şirketlerden birisi de F16, F117 ve F35 gibi uçakları üreten Lockheed Martin şirketidir.

Resim 1: Lockheed Martin tarafından üretilen F-35

Resim 2: F-35 üretiminde Türkiye de yer almaktadır

Lockheed Martin'in güvenlik olaylarına müdahale birimi tarafından kritik veya önemli ağ ve sistemlere yönelik saldırıların aşamalarını kapsayan  "Ölüm Zinciri" yaklaşımı, güvenlik ihlalinin amacına ulaşması için gerekli adımları sıralar.

Bu adımlar genellikle aşağıdakileri kapsamaktadır;
  1. Bilgi toplama: Hedef hakkında halka açık bilgilerin toplanması ve hedef sistemler hakkında bilgilere ulaşılması gibi konuları kapsayan bu adımda saldırgan hedefi yakından tanımayı amaçlamaktadır. 
  2. Silahlandırma: Başarılı bir saldırı için gerekli sızma ve arka kapı yazılımlarının hazırlanması.
  3. Teslimat: Hazırlanan saldırı ve istismar kodlarının hedefe gönderilmesi.
  4. İstismar: Saldırı kodunun çalışıtırılması, arka kapının açılması.
  5. Kurulum: Arka kapının ve uzaktan erişim sağlayan diğer yazılımların çalıştırılması.
  6. Komuta ve kontrol: Uzaktan erişim sağlanması.
  7. Hedefe yönelik eylemler: Bilgi sızdırma gibi saldırının gerçek amacının gerçekleştirilmesi.

Yukarıdaki zinciri herhangi bir yerinden kırarak saldırının başarıya ulaşmasının engellenmesi önemli bir konu ve etkili bir savunma yaklaşımıdır.

Tenable güvenlik uzmanlarının ölüm zinciri konusunda yaptıkları araştırmalar önemli bir konuya dikkat çekiyor. Araştırma sonuçlarına göre zinciri kırarak saldırının etkisini ortadan kaldırmanın çeşitli aşamalarda mümkün olmasına rağmen zincirin farklı adımlarında farklı maliyetler söz konusu.
Tahmin edeceğiniz üzere saldırıyı "istismar" seviyesinde engellemek için güvenlik duvarı ve anti virüs gibi proaktif güvenlik çözümleri yeterli olurken, "kurulum" aşamasında engellemek için ağ ve dosya izlemesi yapılıp gerekli hallerde gelişmiş teknikler kullanarak kurulumu yapılan zararlı yazılımları temizlemek gerekecektir. Saldırgan tarafından kurulan yazılımların tespit edilmesi bile başlı başına bir konu iken, bunların temizlenmesi ve temizlendiğinden emin olunması da başka uzmanlıklar gerektiren bir konudur.

Bu durumda ölüm zincirinin mümkün olduğu kadar erken bir evrede kırılması hem savunmayı kolaylaştırmakta, hem de maliyetleri (zaman, personel, uzmanlık, vb.) azaltmaktadır. Diğer taraftan zinciri birden fazla yerden kıracak önlemlerin olması da saldırının başarılı olma ihtimalini daha da azaltacaktır.

Ölüm zincirini kırmak için alınabilecek önlemler arasında en etkili olanlardan birisi zafiyet taramasıdır. İnternete dönük tek bir sunucunuz varsa, zafiyet taraması yapmak kolaydır ama birden fazla sistem varsa ve saldırılara birden fazla adımdan oluşabilecek imkanı sunan bir yapınız varsa zafiyet taraması zorlaşır. Örneğin web sunucunuzun bulunduğu bir DMZ yapısı ve internete çıkabilen istemcileriniz (kullanıcıların bilgisayarlarını düşünün) bunlar 2 önemli saldırı vektörüdür.

Ölüm zincirinin 3 önemli saldırı vektörünün olduğu ve bunları izlemenin savunmada bizlere fayda sağladığı görülmüştür:
İnternetten erişilebilen sistemler: İnternete dönük veya internet üzerinden erişilebilen sistemlerinizin nerede olduğunu bilmeniz önemlidir. Web sunucu ilk akılınıza gelen olabilir ama ağınızın içerisinde dışarıya açık bir sunucu olmadığından emin olunmalıdır.Aklınıza hemen tam sürüm bir web sunucusu gelmesin, dışarıdan güncelleme alan veya destek ekiplerinin uzaktan erişim için açtıkları küçük bir servis de olabilir.

İnternete erişebilen sistemler: İstemciler ve tarayıcıların yanında anlık mesajlaşma çözümleri (Skype, Messenger, vb.), sosyal medya uygulamaları ve hatta forex piyasalarını takip etmek için kullanılan uygulamalar da dikkate alınmalıdır.

İç ağdaki zafiyetler: Yalnızca iç ağdan erişilebilen ancak istismar edilebilir zafiyetler bulunduran sistemlere de dikkat edilmelidir. "Zafiyet var ama bu sisteme/sunucuya dışarıdan erişim yok" demek tehlikeli ve size zarar verebilecek bir varsayım olur.

Bu üç önemli konu dikkate alınarak ölüm zincirinin kopartılması mümkündür, zincirin tek bir halkasının kopması saldırıyı büyük ölçüde etkisiz hale getirirken iki veya daha fazla yerden bölmek saldırıyı tamamen etkisiz hale getirir.

Resim 3: Etkili bir zafiyet yönetimi sistemi ile karşılaşan "Ölüm Zinciri" (temsili)

Firewall ve antivirüs gibi Kurumunuzdaki mevcut güvenlik çözümleri ile birlikte basit de olsa bir zafiyet yönetimi süreci oluşturmak size önemli bir savunma hattı daha kazandıracaktır.
Zafiyet yönetimine kısaca değindiğim bir yazıma http://www.alperbasaran.com/2013/09/zafiyet-yonetimi.html adresinden ulaşabilirsiniz.

Tenable tarafından geliştirilen Security Center çözümü aşağıdaki ekranda görüldüğü üzere saldırganlar tarafından kullanılması mümkün ve muhtemel saldırı vektörlerini ortaya koyduğu için Kamu Kurumları, bankalar ve telekom şirketleri gibi stratejik öneme sahip ve büyük ağları yönetmek zorunda kalınan durumlarda faydalı olabilir.

Resim 4: Tenable Security Center ekran görüntüsü

Etkili bir zafiyet yönetimi programı oluşturmak isteyen Kamu Kurumları benimle iletişime geçebilirler.



Tuesday, October 28, 2014

Bulut Teknolojisi: Dost mu? Düşman mı?

Ne zaman “bulut teknolojisi” kelimelerini cümle içerisinde kursam karşımdakilerin önemli bir kısmından verileri veya uygulamaları buluta taşımanın ne kadar güvensiz olduğu konusunda uzunca bir nutuk dinliyorum.

Resim 1: Dost ve düşman bulutlar (temsili ve evet bunları çizmeyi seviyorum)

Bulut teknolojisinin diğer teknolojilerden ne daha güvenli ne de daha güvensiz olduğunu düşündüğüm için hem mevcut tehditleri sıralamak hem de bazı güvenlik önerilerinde bulunmak istiyorum.

Tehlikeyi anlamak

Başkaların verilerinize ulaşabilir, değiştirebilir veya silebilir
Söz konusu verilerimizi ve sistemlerimizi buluta taşımak olduğunda kuşkusuz en büyük korkumuz verilerimizin başkasının eline geçmesidir. Yaşanan büyük güvenlik ihlalleri (target, iCloud, vb.) etrafında yaşanan tartışmaların ateşi henüz geçmedi. Bulut üzerinde bulunan verilerin platform, başka kullanıcıların hataları veya yanlış kurulumlar nedeniyle erişilebilir hale gelmesi ne yazık ki mümkündür.
Verilere erişebilen saldırganların bunları silmesi veya duruma göre değiştirmesi de mümkün olabilir.

Hesabınızı ele geçirebilirler
Oltalama (phishing) benzeri sosyal mühendislik saldırıları veya güvensiz bir ağ üzerinden bağlanmanız durumunda; doğrudan ağ üzerindeki iletişiminizi yakalayarak, buluttaki verilere veya sistemlere ulaşmak için kullandığınız bilgiler (kullanıcı adı ve parola) elde edilebilir. Bu durumda saldırganlar aynı bilgileri kullanarak sistemlerinize erişim kazanmış olur.

Güvensiz API’ler
API’ler (Application Programming Interface – Uygulama Programlama Arayüzü) buluttaki sistemlerinizi yerel ağdaki sistemlerle veya buluttaki başka sistemlere entegre etmek için çok kullanışlıdır. Ancak zayıf bir API, buluttaki sistemlerinizin kapısını saldırganlara açabilir. Bunun en “güzel” örneklerinden birisi iCloud hadisesidir.

Hizmet dışı bırakma
Önemli iş süreçlerini buluta taşıdıktan sonra başımıza gelebilecek en kötü şeylerden birisi de bu sistemlere erişememektir. Yeterince önlem alınmazsa hizmet dışı bırakma saldırısı (DoS/DDoS – Denial of Service/Distributed Denial of Service) karşısında elimiz kolumuz bağlı oturmaktan başka çaremiz kalmaz.

Yetersiz hazırlık
Buluta taşınacak sistemlerin doğru analiz edilmesi ve uygun bulut mimarisinin seçilmesi sadece performansı değil, aynı zamanda buluttaki verilerin ve sistemlerin güvenliğini de doğrudan etkiler. Bulutta alınacak güvenlik tedbirlerinin yerel ağ üzerindekilerden farklı olduğunun, sunucu ve veri tabanı mimarilerinin de farklılık gösterebileceğinin anlaşılması gerekiyor.

Yukarıda saydıklarımın dışında içeriden birinin bilgi sızdırması, yetersiz şifreleme teknolojileri, basit parola kullanımı gibi genel geçer güvenlik zafiyetlerinin de bulutta mevcut olduğunu hatırlatmakta fayda görüyorum.

Güvenlik için Önlem Almak

Verilerinizin ve sistemlerinizin bulutta güvende olmasını sağlamak için bulut hizmetini aldığınız yerin de üzerine düşen şeyler var. Bu listedekileri teyit ederek doğru bir şirketten bulut hizmeti aldığınızı kontrol edebilirsiniz.

Hareket halindeki verinin korunması
Veri bir yerden başka bir yere transfer edilirken gerekli şifreleme ve kimlik doğrulama önlemleri alınmalıdır. Veri transferi sırasında üçüncü kişilerce verinin değiştirilmesi veya okunmasının önüne geçilmelidir.

Fiziksel güvenlik
Verilerin tutulduğu platformların fiziksel güvenliği sağlanmalıdır. Sunucuların veya bulut platformunun çalınması, zarar görmesi veya değiştirilmesi bilgi güvenliği ihlaliyle sonuçlanabilir.

Kullanıcıların ayrılması 
Saldırganların aynı bulut yapısını kullanan başka bir kullanıcıya sızmaları veya aynı bulut yapısı üzerinde kendilerine kullanıcı açması halinde bu hesaptan sizin verilerinize ulaşamamaları gerekir.

Bilgi güvenliği yönetimi 
Bulut hizmeti alacağınız firmanın bu yapıyı nasıl yönettiğinin ve gerekli bilgi güvenliği yönetimi süreçlerinin var olduğundan emin olunmalıdır.

Güvenlik süreçleri
Bulut hizmetini aldığınız firmanın bilgi güvenliğine ilişkin süreçleri de oturmuş olmalıdır. Örneğin sızma girişimlerini nasıl yönetiyorlar? DDoS (Dağıtık Hizmet Dışı Bırakma) saldırılarına karşı nasıl bir eylem planları var? Gibi soruların cevapları net olmalıdır. “Bize kimse saldırmıyor”, “o işe bakan bir ekip var ama başka şehirdeler”, “çok sağlam heykır bir arkadaş var, o koruyor”, “mikrotik (jenerik üretici adı anlamında) var be yeeaaa” gibi cevaplarla karşılaşırsanız bulut teknolojisine geçmek için çok yanlış yerdesiniz, koşar adımlarla uzaklaşmanızda fayda var.

Personel güvenliği
Bulut hizmeti aldığınız veri merkezinin personelinin gerekli güvenlik kontrollerinden geçmiş, “düzgün” tabir edebileceğimiz kişilerden oluşmasında fayda var. Bunu anlamak için bulut hizmeti almayı düşündüğünüz firmanın işe alım prosedürlerini ve referans kontrollerinin yapılıp yapılmadığını sormanın faydası olabilir.

Güvenilir uygulamalar
Bir uygulamayı buluta taşıyacaksanız bütün dünyanın buna erişimi olabileceğini düşünmenizde fayda var. Bu nedenle bulut üzerinde çalıştıracağınız uygulamanın kaynak kod analizin ve güvenlik testlerinin yapılmış olmasında fayda var.
Güvenlik yönetimi: Bulut yapısını kullananlara kendi güvenliklerini sağlamak için gerekli yönetim arayüzlerinin ve hayati gelişmeleri takip edebilecekleri ekranların sunulması önemlidir.

Yetkili erişim
Bulut yapısına ve bulut yapısı üzerinde çalışan sistemlere erişimin sadece yetkili kişilerle sınırlandırılmış olması önemlidir.

Dışarıya bakan arayüzlerin güvenliği
Bulut platformunun internete bağlı olan her noktası için gerekli güvenlik önlemleri alınmalıdır. Örnek olarak web tarayıcısı ile port 80 üzerinden erişenleri ülke bazında sınırlandırdıysak SSH ve RDP bağlantıları için de benzer önlemlerin alınması gereklidir.

Güvenli hizmet verme
Bulut hizmeti aldığınız firmanın düzenli olarak güvenlik testlerini yaptırması ve güvenlik altyapısı konusunda gerekli yatırımları ve iyileştirmeleri yapıyor olması önemlidir.

Kullanım kılavuzunu okuyun 
Hizmet şartlarınızı, sözleşmeyi ve size bulut hizmeti veren firma ile aranızdaki SLA’yi (Service Level Agreement – servis şartlarını düzenleyen anlaşma) dikkatle okuyun. Okurken aklınıza yatmayan veya size uygun olmayan bir şart varsa buna mutlaka açıklık getirin. “Orada öyle yazıyor da biz pek şeyapmıyoruz be yeeaaa” türü açıklamalar yapılır koşarak uzaklaşın.

İhtiyaç duyduğunuz güvenlik seviyesini belirleyin
Buluta taşımak istediğiniz verileri veya sistemlerin ne kadar önemli olduğuna göre ihtiyacınız olan güvenlik seviyesini belirlemelisiniz. “güvende olmalı” gibi genel bir yaklaşımdan ziyade basit bir tablo ile en kritik yönlerini ve tehdit oluşturabilecek zafiyetleri listelemek ve bunları adreslemek gerekir.

Varsayımda bulunmayın
Hizmet aldığınız şirketin hiç bir şey yaptığını varsaymayın, her şeyi sorun ve belgeleyin. 


Bulut konusunda temel görüşüm, buluta taşınan verilerinizin, en az kendi ağınızda olduğu kadar, genellikle de daha güvende olduğudur. Doğru bir firmadan hizmet alırsanız ve sistemlerinizin güvenliğine özen gösterirseniz güvenlik seviyeniz artacaktır.

Monday, October 27, 2014

CEO'nun Siber Güvenlik Rehberi

“Siber güvenlik” veya daha genel olarak kabul görmüş ismiyle “bilgi güvenliği” konuları her geçen gün kurumsal yapının daha üst basamaklarında ele alınıyor. İş hayatına ilk başladığımda “bilgisayarcı çocuk” tarafından ele alınan konu artık müdür, direktör ve hatta genel müdür seviyesinde ele alınmaya başlandı. Bilgi Güvenliği konusunda çalışmayan ama bütçe veya satınalma onayı gibi nedenlerle bu konuda karar vermek zorunda kalan; CEO, CXO, Genel Müdür, Satınalma Müdürü, Finans Müdürü, Mali Müşavir, Danışman ve benzeri görevleri üstlenenlerin bu konuda daha doğru ve etkin kararlar vermelerini sağlayacak bazı basit soruları toparlamak istedim.

Yönetici (temsili)

Konunun Bilgi İşlem birimlerinin ötesine ve/veya üstüne taşınmasının başlıca nedenleri arasında aşağıdakileri sayabiliriz;
  • Kanuni zorunluluklar: 5651 sayılı kanun gibi kanunların veya  çeşitli yönetmeliklerin kurumsal bilgileri koruma zorunluluğu getirmesi.
  • Değişen iş süreçleri: Internet’e ve bilgi teknolojilerine daha bağlı hale gelen iş süreçleri bilgi güvenliği ihlallerinin iş, para veya itibar kaybına neden olması şirketlerin üst yönetimlerinin konuya daha fazla ilgi göstermesine neden olmuştur.
  • Artan bilinç düzeyi: Bilgi güvenliği konusunda yaşanan ihlallerin ve konunun bir şirket için hayati önem taşıdığının basında ve çeşitli etkinliklerde dile getirilmesi kurumsal yapının her basamağında belli bir farkındalık düzeyi oluşmasını sağlamıştır.

Bilgi güvenliğinin teknik/teknolojik bir konu olmadığını elimden geldiğince her fırsatta vurgulamaya çalışıyorum. Bilgi güvenliği konusu aslında bir risk yönetimi konusudur ve bu nedenle konuşmaların ve kararların sadece teknik bir bakış açısı ile ele alınması çok doğru olmayacaktır. Bilgi güvenliği konusunda doğru adımların atılması ve yatırımların yapılmasını sağlamak amacıyla konuya Üst Yönetim bakış açısıyla yaklaşmanın faydası olacaktır.

Bilgi güvenliği yatırımlarının etkili olması, yapılan yatırımın tam karşılığının alınabilmesi ve şirket veya kurum için hayati önem taşıyan bu konuda atılan adımların somut olarak ne anlama geldiğinin Üst Yönetim tarafından anlaşılması çok önemlidir.

Bu işlere “Bilgisayarcı Çocuk” bakmıyor mu?

Maalesef, Bilgi Güvenliği bir risk yönetimi faaliyetidir ve şirket risklerinin sahiplerinin sorumluluğuna girmiştir. Şirket risklerinin sahipleri; Genel Müdürler, CEO’lar, Finans müdürleri veya İdareciler gibi şirketin veya kurumun doğru çalışmasını, zarara uğramaması ve daha ileriye gitmesi için çalışan kişilerdir.

Teknik birimlerle Yöneticilerin Bilgi Güvenliği konusunda karar vermek için yaptıkları toplantılarda teknik olmayan idarecilerin elinin altında bulunmasında fayda gördüğüm bazı soruları aşağıda toparladım. Bir karar toplantısında veya ilk fırsatını bulduğunuzda teknik birimdeki arkadaşlarınızla bu soruların etrafında bir görüşme yapmak kurumsal Bilgi Güvenliği düzeyinizi anlamak ve iyileştirmek için faydalı olacaktır.

Siber hırsızlık ve Casusluk Zafiyet Kontrol Soruları
  • Korumamız gereken veya yarın sabah gazete manşetlerinde görmekten hoşlanmayacağımız ticari sır, bilgi, yazışma, plan, proje ve/veya patentlerimiz var mı?
  • Ticari sırlarımıza, bilgilerimize, yazışmalarımıza, planlarımıza, projelerimize ve/veya patentlerimize erişmek isteyebilecek rakipler veya başkaları var mı?
  • Ticari sır, bilgi, yazışma, plan, proje ve/veya patentlerimiz bilgisayar ortamında tutuluyor mu?
  • Bilgisayarlarınız veya bilgisayar ağınız internete bağlı mı?
  • Bilgisayarlarınızda USB girişi, ağ kablosu girişi veya CD/DVD yazıcı var mı?
  • Önemli bilgilerimizin, dosyalarımızın ve yazışmalarımızın yedeklerini düzenli olarak alıyor muyuz?


Bu soruların yanıtları kurumsal ağınızın saldırganlar açısından ne kadar “iştah açıcı” olduğunu ortaya koymaktadır. Bunlardan en az 2 tanesine “evet” yanıtı verdiyseniz Yönetim olarak Bilgi Güvenliği konularına dahil olmanız gerekmektedir.

Teknik Riskler ve Zafiyetler Kontrol Soruları

Bu soruların yanıtları kurumsal ağınızın ne kadar “hacklenebilir” olduğu konusunda bir fikri verecektir.

  • Daha önce bilgi güvenliği konusunda bir ihlal yaşandı mı?
    Önceki güvenlik ihlaline neden olan açık hala kapatılmamış olabilir. İstatistiksel olarak daha önce saldırıya uğramış bir şirketin tekrar saldırıya uğrama ihtimali çok yüksektir.
  • Bilgisayarlarınızda veya bilgisayar ağınızda zararlı yazılım tespit edildi mi? (virüs, Truva atı, ransomware, vs.)
    Zararlı yazılımlar geride arka kapılar veya kendilerini bile bırakabilirler. Bu nedenle daha önce zararlı yazılım bulaşmış bir ağın ve sistemlerin çok dikkatlice incelenmesi ve temizlenmesi gerekir. 
  • Ağınızı açık portları ve zafiyetleri tespit etmek için dışarıdan tarayanlar var mı?
    Web uzantınız .gov.tr ise günde birkaç bin kez, .com.tr ise günde birkaç yüz kez  taranıyorsunuz. Bilgi İşlem ekibinin bunun farkında olması ve ağ üzerinde gerekli tedbirleri alması önemlidir.
  • Kullandığınız yazılımların ve sistemlerin daha güncel sürümleri veya bu yazılımlar için yayınlanmış yamalar var mı?
    Güncel sürümler güvenlik açıklarını kapattığı için çok önemlidir. Kullandığınız yazılımların bir envanterini çıkartmak ve bunları üreticilerin web sayfalarındaki son sürümlerle karşılaştırmak sistemlerinizin güncel olup olmadığını anlamınızı sağlar.
  • Personeliniz iş için laptop, tablet, akıllı telefon benzeri taşınabilir cihazlar kullanıyor mu?
    Mobil cihazların güvenliğini sağlamak için alınması gereken önlemlerin alındığından emin olmak gerekiyor. Cihazlar çalınabilir, güvenli olmayan bir ağ üzerinden şirket bilgilerine ulaşabilir ki, bu durumda ,aynı ağa bağlı herhangi biri de aynı bilgileri görebilir.
  • Ağ ve bilgiye ulaşmak için sadece parola (kullanıcı adı ve şifre olarak da bilinir) kontrolü mü yapıyorsunuz?
    Sadece parolaya güvenmek parolanın ele geçirilmesi durumda tamamen korumasız kalmanıza neden olur.
  • Ağınızın ve bilgisayar sistemlerinizi düzenli olarak bilinen zafiyetlere karşı tarıyor musunuz?Bu taramaları yapmak bilinen ve saldırganlar tarafından yaygın olarak istismar edilmeye çalışılan güvenlik zafiyetlerini tespit etmenizi ve gerekli önlemleri almanızı sağlar.
  • Ağınıza veya ağınızdaki sistemlere uzaktan erişim (RDP, SSH, Web arayüzü, API, vs.) sağlıyor musunuz?
    Uzaktan erişim sağlayan cihaza (masaüstü bilgisayar, laptop, tablet veya akıllı telefon) zararlı yazılım bulaşmış olabilir veya güvensiz bir bağlantı üzerinden bağlanıyor olabilir. Bu durumların dışında da uzaktan erişim vererek kurumsal ağınızı dış dünyaya açtığınızı bilmeli ve gerekli tedbirleri almalısınız.  

 Yukarıdaki sorular içerisinde “evet” yanıtı verdikleriniz ele alınması gereken güvenlik tehditlerine işaret etmektedir.

 Bu konulardan yola çıkarak bir çerçeve oluşturmak ve kurumsal ağınızın ve bilgilerinizin güvenliğini arttırmak için önemli adımlar atmanızı sağlayacaktır. 




Sunday, August 31, 2014

Boşa giden 250 milyon dolar

250 Milyon Dolar… Fikir vermesi için bu rakam JP Morgan Chase bankasının sadece 2014 yılında bilgi güvenliğine yaptığı yatırımdır. 
Bu ölçekte güvenlik yatırımları yapan bir bankanın hacklenmesi tek başına kötü bir haber iken, FBI’ın bu olayın 5 diğer küresel bankayı da hedef alan daha geniş kapsamlı ve planlı bir saldırının parçası olup olmadığını araştırıyor.

JP Morgan’da ne oldu?
Aklımıza ilk gelen soru sadece güvenliğe 250 milyon dolar harcayan bir yerin nasıl hacklenmiş olabileceğidir. 
Herşeyden önce bilmemiz gereken şey saldırının bir anda olmadığıdır. Filmlerden alışkın olduğumuz şekilde gecenin karanlığında klavyesinde birşeyler yazan siyah giyimli ve önünde terminal ekranı olan bir kişinin saldırısı değil. Yayınlanan raporlardan gördüğüm kadarıyla saldırganlar JP Morgan Chase sistemlerinde 2 aydan fazla süre tespit edilmeden dolaşmışlar. 

Saldırının başlangıcı ve hackerların banka sistemlerine ilk sızdıkları noktanın bankanın internet sayfası olduğu düşünülüyor. Web sayfasında bulunan bir zafiyet istismar edilerek web sayfasının bulunduğu sunuculara erişim sağlayan saldırganlar veri merkezinde bulunan diğer sunuculara sızmışlardır
.
Saldırının 5 önemli adıma bakarak aşağıdaki saldırı sürecini çıkartabiliriz.





Adım 1: Saldırganlar bankaya ait internet sitesinde bir güvenlik açığı tespit ediyor

Adım 2: Bu güvenlik açığından faydalanan saldırganlar web sitesinin barındırıldığı sunucuyu ele geçiriyor

Adım 3: Bankanın sunucu havuzu içerisinde yatay hareket

Adım 4: Bankacılık işlemlerinin tutulduğu sunuculara sızıyorlar

Adım 5: Ele geçirdikleri hassas verileri aralarında Brezilya ve Rusya’nın da olduğu çeşitli ülkelerde bulunan sunuculara gönderiyorlar. 

Saldırıların her aşamasında “0-day” güvenlik açıklarından ve istismar kodlarından faydalanılmış olması saldırganların bilgi ve beceri seviyesinin oldukça yüksek olduğunun bir kanıtıdır. “0-day” (sıfırıncı gün) açıkları bulunmuş ancak henüz üretici veya kamuoyu tarafından bilinmeyen güvenlik açıklarıdır. Bu güvenlik açıkları uluslararası ticarete konu olmaktadır ve önemli açıklar milyonlarca dolara varan fiyatlarla satılmaktadır. Bu olaydaki saldırganlar ya teknik kaynakları olduğu için açıkları kendileri tespit etmiş, veya finansal güçlerini kullanarak bu açıkları piyasadan satınalmışlardır.

Saldırının başarıya ulaşmış olması ise bize saldırganların bu işe zaman ve kaynak ayırdıklarını gösteriyor. Öncelikle bankanın gelişmiş sızma tespit ve önleme sistemleri özel olarak geliştirilmiş zararlı yazılımlar ve istismar kodları kullanılarak atlatılmıştır. Bu ukodları yazmak ve bankanın kullandığı güvenlik sistemleri hakkında bilgi toplamak teknik bilgi, zaman ve birden fazla alanda beceri gerektiren bir süreçtir. İkinci aşamada ise 1 aydan fazla sürede banka sistemlerinden dışarıya gönderilen gigabaytlarca verinin aktarımının bankanın veri sızdırma (Data Loss Prevention – DLP) sistemlerini atlatacak şekilde yapılması yine saldırganların sıradan kişiler olmadığını kanıtlamaktadır. 

Yıllık bütçe raporunda “2014 yılının sonuna kadar bilgi güvenliğine 250 milyon dolar yatırım yapacağız ve bilgi güvenliği kadromuzu 1000 kişiye çıkartacağız” diyen bir bankanın bile hacklenmesi bu kadar kolayken daha küçük ölçekli finans kuruluşları ve özel şirketler kendilerini nasıl korur? Öncelikle bu saldırıdan gerekli dersleri çıkarttığımızdan emin olmalıyız.

JP Morgan Chase olayından çıkartılacak dersler

İlk ders, her zamanki gibi, güvende olmadığınız gerçeğini kabul etmektir. Yeni aldığınız firewall veya laptoplarınızdaki antivirüsler size güvenlik sağlamaz. Güvende olmak için cihazların ve yazılımların ötesine geçerek genel güvenlik seviyesi ele alınmalıdır. Mesela firewall’un sadece port engelleme yaptığını ve insanların web sayfanıza ulaşabilmeleri için 80.portu açık tutmanız gerektiğini ve büyük ihtimalle IPS/IDS’in (sızma tespit ve engelleme sistemi) iyi yazılmış bir SQL injection kodunu yakalayamayacağını kabul etmeniz gerekir. 
Ders 1: 250 milyon Amerikan Doları bile harcasanız hacklenebilirsiniz

Saldırının nispeten önemsiz gibi görünebilecek bir yerden başladığına dikkat etmek lazım. Öyle ya, banka bile olsa internet sayfalarında müşteri hesap bilgilerini tutmayacaktır. İnternete açık her sistemin, güvenlik kameraları, POS cihazları, cep telefonları, sıra matikler dahil olmak üzere, saldırıya uğrayabileceğini bilmek gerekir. İnternete açık bir şey için şu cümlerlerden birini kullanıyorsanız yakın zamanda başınıza kötü bir şey gelebilir; “kimse bununla uğraşmaz”, “IP var sadece, bunu bulamazlar” veya “şifreyi bilmeyen giremez”…
Ders 2: Bir şey internete açıksa birileri bulur ve saldırır. 

JP Morgan Chase saldırısının 5 temel adımdan oluştuğunu gördük. Daha küçük hedeflere yönelik saldırılar da aynı şekilde birden fazla adımdan oluşan bir zincir ile gerçekleştirilmektedir. Yukarıdaki senaryoda saldırganların web sayfasının bulunduğu sunucuları ele geçirdikten sonra diğer sunuculara erişemediğini varsayalım. Bu durumda Bankanın başına gelebilecek en kötü şey web sayfalarına “h4ck3d by l33tsec” türü yazı eklenmesi olacaktı. Benzer şekilde saldırganlar sistem sunucularından müşteri işlemlerinin tutulduğu sunuculara geçemeseydi müşteri verilerine ulaşamayacaklardı. Son olarak da ulaştıkları verileri dışarı gönderemeselerdi yine sorun büyük ölçüde azalacaktı. Zafiyetleri ve potansiyel saldırı vektörlerinin ortaya çıkartılmasının yanında, risk analizleri sırasında önem verdiğim noktalardan birisi de bu tür “kâbus zincirlerini” ortaya çıkartmaktır. Bulduğum her zinciri birden fazla yerinden kopartarak benzer senaryoların yaşanmasını önlemeye çalışıyorum. Böylece saldırgan sisteme sızsa bile sistemden bilgi sızdıramayacak veya sızdığı sistemden bir diğerine atlayamayacaktır. 
Ders 3: Başınıza gelebilecek en kötü şey için bir araya gelmesi gerekenleri bulun ve bir araya gelmediklerinden emin olun. 

Yapılan saldırıların ürettiği logları düşünürsek daha küçük ölçekli bir bankada veya herhangi bir Türk bankasında dikkat çekecek kadar garipler. Özellikle dışarı bilgi gönderildiği aşamada Brezilya ve Rusya’da bulunan sunuculara yapılan veri transferi basit bir scriptle bile kolayca ortaya çıkartılabilecektir. Sadece sızdırılan bilgiler değil, zararlı yazılımların komuta sunucuları ile olan iletişimi de bu şekilde yakalanabilir.
Ders 4: Ağınızdan çıkan trafiği izlemeniz çok önemli.

Diğer öneriler
Bu olaydan almamız gereken derslerin devamı olarak bazı basit önerilerim olacak;

Web sayfanızı dışarıda tutun: Hayır, DMZ’de değil, tamamen dışarıda. Bir hosting hizmeti alacak şekilde dışarıda.

Güvenlik analizleri yaptırın: Sızma testlerinin dışında da bu tür saldırı senaryolarının ortaya çıkartılacağı çalışmalar yaptırın

Sistemlerinizin kendi aralarında ne konuştuklarını takip edin: Örneğin web sunucunuz ile dosya sunucunuzun iletişim kurmasını gerektirecek bir neden olup olmadığını araştırın. 

Hata loglarını takip edin: Ne kadar iyi olursa olsun hacker hata loglarına neden olacaktır. Bunları tespit etmek, saldırıyı ve saldırganı tespit etmek için hayati önem taşır.






Monday, June 23, 2014

NSA sunucuları listesi

Alman Der Spiegel dergisi tarafından yayınlanan NSA sunucularının IP adreslerinin listesi. 




Kurumsal ağa doğru veya kurumsal ağdan bu IP'lerle olan trafiği yasaklamakta fayda var. Özellikle kamu kurumlarda geçmişe dönük loglara bakıp bu IP'lere doğru bir trafik olduysa tespit etmek çok önemli. 


Kaynak: http://www.spiegel.de/media/media-34056.pdf

PROJE KODU IP ADRESİ ÜLKE
ACRIDMINI           146.185.26.163    İngiltere
BALLOONKNOT         176.249.28.104    İngiltere
APERTURESCIENCE   212.118.232.104 İngiltere
CROSSEYEDSLOTH    212.118.232.184 İngiltere
KOALAPUNCH          212.118.232.50    İngiltere
WAXTITAN            31.6.17.94        İzlanda
LUTEUSICARUS      37.130.229.100 İngiltere
MAGNUMOPUS        37.130.229.101 İngiltere
MURPHYSLAW          37.220.10.28      İngiltere
WILDCOUGAR          80.84.63.242      İngiltere
MAGNUMOPUS          84.45.121.218     İngiltere
CROSSEYEDSLOTH    85.237.211.177 İngiltere
HEADMOVIES        85.237.211.198 İngiltere
APERTURESCIENCE     85.237.212.52    İngiltere
DARKFIRE            94.229.78.58      İngiltere
SHARPSHADOW         184.154.95.24     A.B.D.
WILDCHOCOBO       198.105.215.147 A.B.D.
SCREAMINGHARPY    198.144.105.223 A.B.D.
DARKTHUNDER       198.144.107.244                   
POTBED              198.144.107.45                      
MURPYSLAW           199.127.100.25    A.B.D.
DARKTHUNDER       216.172.135.105                   
SCREAMINGHARPY    216.172.135.136                   
SHAREDTAFFY         37.72.168.84      Hollanda
CHOCOLATESHIP     50.115.118.140 A.B.D.
LUTEUSICARUS      50.115.119.172 A.B.D.
WAXTITAN            64.9.146.208      A.B.D.
WAXTITAN            65.49.68.162      A.B.D.
WHISTLINGDIXIE      68.68.107.164     A.B.D.
CHAOSOVERLORD       68.68.108.69      A.B.D.
JEEPFLEA            69.175.29.74      A.B.D.

Sunday, May 4, 2014

Güvenlik duvarı (firewall) yönetimi ipuçları

Kurumsal bilgisayar ağlarının önemli bir kısmının ilk savunma hattını güvenlik duvarları (firewall) oluşturuyor. Gözümüzde Çin Seddi gibi canlandırdığımız bu cihazların kullanımı ve yönetimi konusunda bazı genel ipuçlarını toparlamak istedim. Unutmayalım ki en gelişmiş güvenlik çözümleri bile onu yönetenlerin imkan tanıdığı ölçüde bizleri koruyabilir.


Güvenlik duvarı algısı (temsili)

Dokümantasyon
ISO kalite standartları dünyasında “yaptığını yaz, yazdığını yap” diye bir cümle vardır. Güvenlik duvarları içinse bu konu hayati önem taşımaktadır. Güvenlik duvarının kurulduğu topoloji (tek hat üzerinde, iç/dış güvenlik duvarı olarak veya 3 bacaklı topoloji) ve üzerindeki kuralların yazıya dökülmelidir. Bundan sonra da yapılacak her topoloji veya kural değişikliği, yazılı olarak kayıt altına alınmalıdır.

ANY sadece DROP kapsamında kullanılmalıdır
Kurumsal ağlarda “TCP ANY ANY ACCEPT” kuralını her gördüğümde bir kumbaraya 50TL atsaydım şimdiye kadar iyi para biriktirmiştim. Bu kuralı kimse bilerek girmiyor tabii ki ama bir test yapılırken veya bir sorunun kaynağı araştırılırken bu kural giriliyor ve orada unutuluyor.
Prensip olarak güvenlik duvarı kuralının her hangi bir yerinde ANY varsa ve bu dünyaya açık bir web sunucusu vs değilse kural mutlaka DROP ile yazılmalıdır.
Bazı durumlarda, tek bir trafik yönlendirmesi için, birden fazla kural yazmanız gerekebilir ama bu ağınıza birilerinin sızmasından iyidir.

Kural değişiklikleri
Güvenlik duvarına kural eklerken veya mevcut kuralları değiştirirken bunu neden yaptığımızı bilmemiz şarttır. Güvenlik duvarları aslında kurumsal bilgi güvenliği politikalarının (veya genel olarak kabul görmüş güvenlik önlemlerinin) gerçek dünyaya bir yansımasıdır. Yapılan değişikliklerin güvenliğimizi arttırması veya en azından mevcut güvenlik seviyemizi kötüleştirmemesi şarttır. Kural değişiklik talebinin nereden geldiği ve neden gerekli olduğu anlaşılmalıdır. Bundan bir süre önce bir kamu kurumunda gözlerimin önünde güvenlik duvarı kuralları “XXX entegratör firmadan gelen teknisyenin” talebi üzerine anında yapılıvermişti. Hatırladıkça tüylerim diken diken olur. Entegratör firmanın teknik elemanın yaptığı/yapacağı bir demo için güvenlik duvarında 15 – 20 port açtırması kabul edilebilir birşey değildir.

Vedalaşmayı bilin
Artık geçerli olmayan veya kullanılmayan kuralların silinmesi gerekir. Kural silme sürecinin de tıpkı yeni kural girişi gibi belgelenmesi önemlidir. Güvenlik duvarı kurallarını yazanların yeni alımlar, güncellemeler ve devreden çıkartmalar konusunda bilgilendirilmesi gerekmektedir.

Senede 1 gün
Yılda en az bir sefer güvenlik duvarının mevcut durumu analiz edilmeli ve gerekli iyileştirmelerin hızlıca yapılması gerekmektedir. Bu analiz sırasında sızdırmazlık testlerinin, güvenlik duvarı işletim sistemi güncellemelerinin kontrolünün ve topoloji değerlendirilmesi yapılmalıdır.

Diğer ipuçları:
  • Kullanılan servisler dışındaki kapatın
  • Güvenlik duvarını yetkili kullanıcı dışında bir kullanıcı ile çalıştırın
  • Fabrika çıkışı ayarlanmış kullanıcıları/parolaları değiştirin
  • Sadece paket filtrelemeye güvenmeyin
  • Güvenlik duvarı bir yazılımsa mutlaka sıkılaştırılmış bir işletim sistemi üzerinde çalıştırılmalıdır
  • İç ağdaki trafiği de güvenlik duvarından geçirin
  • Güvenlik duvarı loglarını düzenli olarak inceleyin
  • Güvenlik loglarını düzenli olarak yedekleyin
  • Güvenlik duvarı üreticisinin güvenlik uyarılarını yayınladığı mail listelerini takip edin
  • Kurallara isim verirken belirli bir yöntem kullanın
  • Benzer kuralları alt alta toplayın
  • Geçici kurallar için “notlar” kısmına devreden çıkartma tarihi yazın
  • Güvenlik duvarının yönetim arayüzüne erişmek için en güvenli yolu tercih edin
  • Güvenlik duvarı üzer,nde açılması gereken "tehlikeli" bir servis varsa, bunların da güvenli alternatifi tercih edilmelidir (Telnet yerine SSH gibi)


Güvenlik duvarının sizi sadece sınırlı sayıda tehdide karşı koruduğunu hatırlamak gerekir. Bunlarla birlikte bir sızma tespit ve engelleme sisteminin veya eposta güvenliğini sağlayacak bir çözümün konumlandırılmasında fayda vardır. 

MITRE ATT&CK Gerçek Hayatta Ne İşimize Yarar?

  Rusya kaynaklı siber saldırılar webinarı sırasında üzerinde durduğum önemli bir çalışma vardı. MITRE ATT&CK matrisini ele alıp hangi...