Yama Yönetimi - Nass oluyor da oluyor? Yama dağıtım merkezini korumak

WSUS , Windows Software Update Services, Windows Security Update Server ya da Services gibi açılımı konusunda her kafadan bir sesin çıktığı, Microsoft'un uzuun zamandır müşterilerine ücretsiz olarak sunduğu, raporlama kabiliyeti 0'a yakın merkezi yama dağıtım ürünü. İstemci ve Sunucu platformlarında çalışabilir, çok az donanım kaynağına ihtiyaç duyar, birkaç adımda konfigüre edilip domain yapısında kullanılmaya başlanabilir. Ücretsiz olduğu için çok yaygın kullanılır,artık System Center ailesiyle birlikte SCCM'e de entegre olmuştur. Yani yamaları güncellemeleri yine WSUS microsoft update sitesinden kontrol eder, indirir ama yamaların dağıtımını SCCM yapar. Hemen her merkezi yönetim/denetim/izleme çözümünde olduğu gibi WSUS'un da sağlıklı çalışabilmesi için kendisi ile yamalayacağı sistemler arasındaki iletişimin kesintisiz olmasına ihtiyaç duyar,bu da birden fazla portun açılması demek.Yine her merkezi yönetim/denetim/izleme çözümünde olduğu gibi çözümle istemci ya da sunucu bilgisayarlar arasında açılması gereken bu portlar dikkate alınmaz, karşılıklı tüm portlardan erişim açık hale getirilir.

Yama Yönetimi - Nass oluyor da oluyor? İdeal Yama Yönetim Süreci

Türkiye'de çok az yerde olması gerektiği gibi yönetilen bir süreçtir. Sistem yönetimi, bilgi güvenliği,yazılım geliştirme, yönetim, çalışanlar yani bir kurumdaki neredeyse herkesin bu sürecin parçası olması gerekir. Üzerine basa basa bunun bir süreç olduğundan bahsediyorum çünkü yama yönetimi düzenli ve sürekli bir iş, kurumsal her organizasyonda olması gerektiği gibi politikası,standardı ve prosedürü olmalı, işleyişteki roller belirlenmeli ve yönetim desteği/onayı olmazsa olmaz. Zaten işin zor kısmı da bu bileşenleri hayata geçirebilmek, gerisi birkaç checkbox işaretlemek ve birkaç da buton'a basmaktan ibaret. Bu yazıda ben politikadan bahsetmeyeceğim, bahsedeceğim şey aslına bakarsanız standardı. Yani çook derin ayrıntıya girmeden bu işin kitabına göre nasıl yapılması gerektiği, hangi araçların kullanılması gerektiği vb ayrıntılar bir başka yazıda anlatılacak.
Yama terimi, her ne kadar istatistiki veriler Microsoft platformları ve ürünleriyle kıyaslandığında açık kaynak kodlu platformlarda ve uygulamalarda bir yıl içinde çok daha fazla yama yayınlandığını gösterse de, Microsoft ürünleriyle özdeşleşti. Bu nedenle spesifik olmak gerektiğinde Microsoft ürünlerini örnek göstereceğim ama bu sürecin adımları genel uygulanabilir olacak. Her nekadar çoğunlukla güvenlik açıklarını ve zaafiyetlerini gidermek amacıyla yayınlanıyor olsalar da performans ve işleyişi iyileştirme adına yayınlanan yamalar da mevcut, ben de yama yönetimiyle hem güvenlik hem iyileştirme amacıyla.Tecrübelerimle birlikte yaygın kullanımı nedeniyle de Microsoft'un yama sürecini esas alacağım,akla mantığa uygun ve uygulanabilir olduğunu siz de göreceksiniz, bu süreç yama yönetimini 4 faz altında tanımlıyor kardeşlerim,hazırsanız başlayalım uzun bir yazı olacak;

IIS Sıkılaştırma Klavuzu - Nam-ı diğer Security Hardening Guide

Hardening, sıkılaştırma-sertleştirme gibi cinsel çağrışımlar yapsa da BT dünyasında bir cihazı,bilgisayarı,uygulamayı,sunucuyu zaafiyetlerden arındırma, saldırı yüzeyi ya da vektörü de denen hedefin saldırı alabileceği noktaları azaltma anlamına geliyor kardeşlerim. Eskiden microsoft hemen her ürünüyle bu tip klavuzlar yayınlardı şimdi nedense pek yapmıyor, belki de yayınlanan bütün o klavuzlara rağmen ürünlerin hala kolayca istismar edilmesindendir bilemiyorum. Herneyse bu yazıda bizi ilgilendiren IIS web sunucuların daha güvenli hale getirilmesi. "SSL" terimi gibi "Hardening" terimi de bana hala bilgi ve bilişim güvenliğinden zerre kadar anlamayan ama her nasılsa çok ciddi kurumlardan birinde güvenlik ekibinin başında dikilen, ağzından bu kelimeyi eksik etmeyen, ismi de lazım olmayan birini hatırlatıyor."Hardening yaptıktan sonra productiona alıcaz,hardeningini kontrol edicez" gibi kusturucu cümlelere maruz kalmıştım bir dönem.

IIS 7-7.5'de hangi klasörleri antivirüs exclusion list'e (gerçek zamanlı kontrol edilmeyecekler listesi) eklemeli

• "C:\inetpub\temp\IIS Temporary Compressed Files"
• "%SystemDrive%\inetpub\logs\LogFiles" (varsayılan iis log klasörü)

Web sunucunuz .NET uygulamaları çalıştırıyorsa

• "C:\Windows\Microsoft.NET\Framework\<yüklü_framework_versiyonu>\Temporary ASP.NET Files"

Klasörlerini antivirüs uygulamanızın (web sunucunuzda antivirüs uygulaması kurulu ve çalışıyor değil mi :) ) gerçek zamanlı tarama işleminin dışında tutun. Yukarıdakiler IIS'e özgü klasörler,bunlar dışında web uygulamalarınızın bulunduğu klasörleri, web uygulamalarınızın loglarının tutulduğu klasörleri de hariç tutabilirsiniz. Bu yazıda Windows işletim sistemi versiyonuna özgü hariç tutulması gereken klasörlerden bahsetmedim, isterseniz aşağıdaki bağlantılardan işletim sistemine ya da rol'e özgü klasörleri/dosyaları da hariç tutarsınız başınız ağrımaz
http://support.microsoft.com/kb/822158
http://support.microsoft.com/kb/943556
Şu küçük hatırlatmayı yapmamın da iyi olacağını düşünüyorum, aynı sizler gibi salgırgan kardeşlerimiz de bilgisayarlarınıza,sunucularınıza zararlı kod bulaştırırken bu makaleleri ve Microsoft'un önerilerini dikkate alıyorlar, ve kodlarını uygulamalarını mümkün olduğunca exclude edilmesi önerilen bu klasörlere yerleştirmeyi tercih ediyorlar :D. Bu yüzden exclusion listlerde aşırıya kaçmamak lazım,ne ka az o ka iyi.

Microsoft Baseline Security Analyzer 2.2 - Can not load security cab file

MBSA Microsoft'un çok az fonksiyonalitesi olan bir aracı,bu yüzden de sorun çıktığında çözümü zor oluyor. Bu araçla sunuculardan birindeki ensik güvenlik yamalarını taratmak istediğimde aldım bu hatayı.

Refleks oldu artık, google'da arattım hata mesajını,her kafadan ayrı ses çıkmış bu hata koduyla ilgili,DCOM ayarlarından bahseden mi dersiniz, WU agent'i güncelleyen mi. Umutsuzca sunucunun "Windows Update" servisini kontrol ettiğimde servisin çalışmadığını gördüm. Belki bu küçük ayrıntı ilerde birinin işine yarar düşüncesiyle yazıyorum.

Yama Yönetimi - Nass oluyor da oluyor? Microsoft Güvenlik Bültenleri

Bu nass oluyor da oluyor dizisinin bu ilk yazısında yama, zaafiyet nedir gibi en basit kavramlara girmeden Microsoft biz sevgili müşterilerini belirlenen zaafiyetlere karşı nasıl bilgilendiriyor konusunu irdelemek istiyorum."Tü-kaka Microsoft,yaşasın penguen kardeşliği" gibi düşünceleriniz varsa bu yazıyı es geçebilirsiniz.
Microsoft düzenli olarak her ayın 2. Salı günü (patch Tuesday), istisnai durumlarda ise anlık olarak (ki buna da out of band patch yaması denir) ürünlerindeki zaafiyetleri (vulnerability) giderici ( nadir de olsa " böyle bir açık var ama henüz giderecek bir güncelleme yok,üzgünüz" dediği de olur) yamalar yayınlar. Terminolojide "Security patch","Critical update","Update","Hotfix","Update rollup","Service pack","Integrated service pack" kavramları birbirinden farklı olsa da ben genel olarak bu güncellemelerden yama olarak bahsedeceğim.

HTTP - Nass oluyor da oluyor? HTTPS - HTTP over SSL

Yine kolay kolay bulamayacağınız detayda, kendisini web uygulama güvenliği konusunda geliştirmek isteyenlerin bilmesi gerektiğine inandığım (merak etmeyin bir çok güvenlikçi bile bu kadar detaya inmeye tırsar) bir yazı,kullanılan örnek paket dosyası ve sunucu sertifikasıyla birlikte.HTTP over SSL, adından anlaşılacağı gibi HTTP trafiğin SSL protokolü ile sağlanan kanal üzerinden iletilmesi anlamına geliyor. Bu kanal şifreleme ve kimlik doğrulama seçenekleriyle ya da her ikisi da olacak şekilde oluşturulabilir ama illa ki hem şifreleme hem de karşı tarafın kimliğinin doğrulanması gibi bir şart yok. OSI katmanda SSL "Presentation" katmanında yer alan bir protokol yığını,dolayısıyla "Application" katmanındaki HTTP ve asıl veri iletişimin yapıldığı "Transport" katmanı TCP protokolü arasında konumlanıyor,açılımı "Secure Sockets Layer". TLS'in de atası.
Trafiğin detaylarına girmeden önce basit ve bu yazıda örnek alınacak trafiğin wireshark'la yakalanmış ekran görüntüsünü de ekliyorum. Yukardaki mekanizmayı anlamada yardımcı olacak.

Internet Explorer SSL Security Warning - yıldırdın beni

HTTPS hakkında bir yazı yazmaya karar verdim, internet explorer beni çileden çıkardı. Yok sertifika sağlayıcısı güvenilir değil, yok sertifikadaki isimle URL'deki isim birbirini tutmuyor vs daral geldi. Warning popup yüzünden trafiği doğru dürüst izleyemez oldum ve bu uyarıları ortadan kaldırmaya karar verdim. Önce yeni bir sertifika otoritesi kurmakla uğraşmamak için bildik sertifika sağlayıcılarından (verisign,thawte vs) trial ssl sertifikaları alayım dedim, demez olaydım. CSR'ı kabul ediyorlar ama daha sonra verilen bilgiler eksik olduğu için sertifika alma isteğinin tamamlanamadığına dair mailler gönderdiler. Hangi bilginin eksik olduğu bilgisi yok tabi gelen mailde. İş başa düştü, sanal sunucuya Enterprise CA (Ceritificate Authority) rolü ekledim, web sunucu için de bu CA'dan bir SSL sertifikası aldım. Sorunsuz,uyarısız, pop-up'sız HTTPS erişimi için bu CA'in sertifikasının da XP istemcinin "Trusted Root Certification Authorities" deposuna eklenmesi lazım,yoksa aşağıdaki gibi mesaj alırsınız.

HTTP - Nass oluyor da oluyor? HTTP Windows Authentication

Mümkün olduğunca yaygın olarak bahsedilmeyen , bilinmeyen,detay verilmeyen konuları yazmaya çalışıyorum.Gelelim en karmaşık IIS kimlik doğrulama (authentication) yöntemine. Windows Authentication, Integrated Windows Authentication, NTLM Authentication, Kerberos Authentication gibi isimlerle anılır kendisi. IIS'in domain ortamında bulunması ve çalışıyor olmasını gerektirir,burası önemli. IIS web sunucusunun veya istemcinin domainde olup olmaması çok da önemli değil ama kimlik doğrulaması Active Directory'den yapılacağı için zırt pırt ortaya çıkan kullanıcı adı/parola pencereleriyle boğuşmak istemiyorsanız ( bu bilgileri kaydetmek te mümkün ama önerilmez ) hem sunucuyu hem istemciyi paşa paşa domaine dahil ederek kullanın. Avantajı ne bu yöntemin ? Basic ve digest authentication yöntemlerinde olduğu gibi kullanıcıya kullanıcı adı/parola penceresi sunmadan kullanıcı kimlik bilgilerini NTLM ya da Kerberos protokolleriyle alırsınız. Ayrıca bu yöntemle kullanıcı parolası değil de parolanın hash i yine kodlanarak gönderilir, bu da oldukça güvenli, açıkları yok mu var ama şimdilik dijital sertifikalardan sonraki en güvenli kimlik doğrulama yöntemlerinden biri. NTLM bildiğiniz gibi yerini Kerberos'a bıraktı ama Kerberos protokolü desteklenmediği durumlarda hala kullanılıyor. NTLM kısaltmasından bir dönem nefret etmiştim, kendisini güvenlik konusunda çok bilgili sanan ve bir bankanın güvenlik bölümün müdürlüğünü yapan ismi ve cismi lazım olmayan bir şahsın ağzından çıkan her cümlede kullanıldığı için :D ( en-ti-el-em otantıkeyşıın şeklinde)

Acunetix WVS Scripting Tool - ara beni ara yar

Bir yandan Acunetix'i kurcalarken klavuzlarda bahsi geçen Scripting Tool'una göz atayım dedim,demez olaydım. Tool'u bulana kadar yarım saat harcadım. Firma nedense ücretsiz olan bu aracı kolay bulunur/indirilir bir yerlere koymamayı tercih etmiş,google aramaları vs nafile. Sonunda aşağıdaki sayfaya eriştim, hint kumaşı tool da sayfanın içinde
http://www.acunetix.com/blog/docs/creating-custom-vulnerability-checks/

HTTP - Nass oluyor da oluyor? Bruter

Bruter bu alanda ün salmış Brutus'e göre nispeten daha yeni bir uygulama. Adından da anlaşılacağı gibi amaç HTTP,FTP,SMTP gibi çeşitli protokollere yönelik bruteforce saldırılar gerçekleştirmek. BruteForce saldırılar ve karşı koyma yolları konusu da ayrı bir blog yazısı.
http://sourceforge.net/projects/worawita/ adresinden ücretsiz indirdiğim aracı XP Professional sanal pc'de çalıştırmaya kalktığımda ilk olarak aşağıdaki hata mesajını aldım.

HTTP - Nass oluyor da oluyor? HTTP Digest Authentication

Basic Authentication'da kullanıcı adı/parola bilgisinin header'larda Base64 algoritması ile karışık hale getirilerek gönderildiğini görmüştük. Basic Authentication'daki bu zaafiyetin giderilmeye çalışıldığı "Digest Authentication" da ise işleyiş şu şekilde;
İstemci, Digest Authentication gerektiren kaynağa erişmek için istekte bulunur;

HTTP - Nass oluyor da oluyor? HTTP Basic Authentication

Windows domain ya da workgroup (hala kullanan yoktur sanıyorum) ortamında IIS web sunucu seviyesinde uygulama erişimi kontrolü için eskiden sıkça kullanılan bir yöntemdi. Basic Authentication yani temel kimlik doğrulaması aktif hale getirilmiş bir web uygulamasına erişilmeye çalışıldığında trafik şu şekilde işler;
İstemci sunucuya bildik HTTP isteği gönderir (ekran görüntüsünde kök dizinine erişme isteği)

Bu mudur?

isc2 twitter hesabında bugün şu tweet vardı "Say goodbye to paper and pencil and hello to Computer-Based Testing for all credentials worldwide",daha önce duyulmuştu aslında isc'nın da sınavlarını bilgisayarla sınav merkezlerinde yapacağı. Şüphesiz maddi kaygıların bir sonucu. Üşenmedim linkleri takip ederek PearsonVue'ya kayıt yaptım