Makale Özeti

Uygulama geliştiriciler için yeni ayarlarla yaşam

Makale

Windows Server 2003teki Güvenlik Değişikliklerinin Uygulama Geliştirme Alanında Etkileri

Yenilikler güzeldir. Ama her zaman ve herkes için aynı güzellikte olmayabilir. Ya da bir yandan işinize yarayan bir değişiklik başka açılardan sizin için sıkıntı oluşturuyor olabilir.

En iyi faydayı sağlamak için yeni özelliklerin iyi yanlarından yararlanırken sizin için kısıtlayıcı olabilecek yönleri de bilmeniz gerekir. Bu yazımızda Windows Server 2003 platformunda daha iyi güvenlik sağlayan değişikliklerin uygulama geliştiriciler açısından kısıtlayıcı olabilecek yönleri üzerinde duruyoruz.

Gereksindiğiniz servis çalışıyor mu?

Çatışma alanında yapılması gereken ilk işlerden biri hedef küçültmektir. Ne kadar iri bir cüsseniz varsa yaralanma olasılığınız da o ölçüde artar.

Windows 2003teki güvenlik atılımlarının en önemlilerinden biri de bu ilkeye dayanıyordu: Kullanım yaygınlığı daha az olan pek çok servis kapatıldı. Buradaki ilke açık: Eğer bir serviste güvenlik hatası varsa ve o servis normal kurulumda kurulmuyorsa, ilgili hatanın kötüye kullanılma olasılığı dramatik bir şekilde düşmüş olur. IIS dahil pek çok servisin standart kurulumda yüklenmediği Windows 2003 ortamında programlarınız çalışacaksa, setup araçlarıyla daha iyi geçinmeye başlamanız ve program dokümantasyonunuzu daha iyi yapmanız gerekiyor.

IIS 6.0 hiçbir kullanıcı kodunu SYSTEM olarak çalıştırmaz

Normal olarak, tüm worker processler bir Network Servisi olarak çalışırlar. Bu da temel güvenlik anlayışının bir sonucudur. Gereğinden daha geniş haklarla çalışan kodlar, güvenlikle ilgili açıkların oluşmasında önemli bir etken olarak görüldüğünden bu alanda da ciddi kısıtlamalara gidilmiştir. Bazı ISAPI uygulamaları şu işlemleri yapar:

  1. RevertToSelfi çağırır ve oluşacak process kimliğinin SYSTEM olmasını bekler.
  2. Sadece SYSTEMin yapabileceği bazı görevleri gerçekleştirir.
  3. Tekrar kullanıcının kimliğine bürünür.

Windows Server 2003te kullanılan IIS 6.0da bu mekanizma ikinci adımda takılıp kalır, çünkü SYSTEM olarak çalışma engellenmiştir. Peki bunu aşmanın yolu nedir? Yoktur! Kullanıcı processinizin SYSTEM haklarına başvurmaması gerekir. Bunun yerine ancak bu ayrıcalıklarla yapılabilecek işleri bir servis olarak yazmanız ve kullanıcı processinizden gerektiğinde bu servisi çağırmanız çok daha uygun olacaktır.

"Impersonation" fonksiyonları beklediğiniz gibi davranmayabilir

Windows Server 2003te impersonation sadece adminlere, servis hesaplarına ve belirli kimliklerde çalışan COM+ processlerine verilen bir ayrıcalıktır. Yazdığınız kodda herhangi bir impersonation fonksiyonuna çağrı yapıyorsanız ve SeImpersonatePrivilege ayrıcalığına sahip değilseniz, istediğiniz sonucu elde edemeyeceksiniz demektir.

DLL arama sırası değişikliği

DLLleri yüklerken ilk bakılan yer artık o anki klasör değil! Bu değişiklik Windows XPnin de SP1inde yapılmıştı. Artık öncelikle tüm sistem yerleşimlerine, sonra o anki klasöre ve sonra da kullanıcı tanımlı diğer yerleşimlere bakılıyor.

Peki bu sadece performansla ilgili bir konu mu? Şu senaryoyu düşünün: Yerel klasörde bir DLLiniz var, işe bakın ki system klasöründe de aynı isimli bir DLL var. Bu durumda yerel DLL yüklenmeyecektir. Biraz daha açarsak: Diyelim ki paylaşılan alanda yeni versiyonu olan bir DLLiniz var ve siz uygulamalarınızdan birinde bu DLLin daha eski bir versiyonunu yerel klasörden kullanıyorsunuz. Bunu Windows Server 2003te yapamazsınız.

Bu değişikliğin sebebi trojan ataklarının kullandığı yöntemlerden birini etkisiz kılmaktır. Kullandığınız DLLlerin aynı isimli yerel kopyasını oluşturup yüksek yetkilere sahip olarak çalışan programlara sızma esasına dayalı bu yöntem, yeni arama sırasıyla engellenmektedir.

Pekiştirilmiş güvenlikli Internet Explorerın etkileri

Windows Server 2003ün geliştirilmesi sırasında Internet Explorer da güvenlik açısından ele alındı. Bir adminin güvenilmeyen, Internet tabanlı Web sitelerini bir domain controller makine üzerinden gezmesi durumunda olası tehditlerin değerlendirilmesi sonucunda tüm mobil kod yeteneklerinin devreden çıkarılmasına karar verildi. (VBScript, JScript, ActiveX kontrolleri, Java ve .NET Framework bileşenleri dahil.) Bu güvenlik ayarlarının çok sıkılaştırılmasıyla gerçekleştirildi.

Peki bu ne anlama gelir? Ne yaptığınıza bağlı olarak bu değişikliğin anlamı sizin için değişir. Aslında şimdi varsayılan olarak gerçekleşen bu durum daha önce de karşınıza çıkabilirdi: Güvenlik duyarlığı yüksek bir kullanıcının tarayıcı ayarlarını değiştirmesi sonucunda.

İşin doğrusu, kullanıcılarınızın web serverınızı trusted zones listesine eklemesidir. Böylece bu kısıtlamaların programınızın doğru şekilde çalışmasını engellemesinin önüne geçilmiş olur.

Kök ACLlerinde güvenlik

Dosya sistemi kökündeki varsayılan izinler de artık çok daha sıkı:

Admin, SYS, Creator – Full Control
Everyone – Read/Execute
Users – Read/Execute
   Create Folders/Append Data (this and sub folders)
   Create Files/Write Data (sub folders)

Bunun sizin için pratikteki etkisi şu: Uygulamanız eğer admin yetkilerini kullanmıyorsa, C:\ye yazamaz . Geçerli bir nedeniniz yoksa bunu yapmayın.

Güvenli paylaşım ACLleri

Paylaşımların varsayılan ayarı artık Everyone: Full Control değil, Everyone: Read. Bu değişikliğin sebebi doğrudan Nimda solucanı. Bu solucan hatırlanacağı üzere network üzerindeki paylaşımlara yazıyordu. Tabii network üzerinde paylaşımlara yazabilmesi için yerel güvenlik ayarlarının da buna izin veriyor olması gerekli. Yani normalde Nimda virüsü pek de başarıyla bu işi yapamamalıydı. Ama bingo! ne yazık ki, güvenlik ayarlarının yeterince sıkı tutulmadığı durumlarla sıklıkla karşılaşılıyordu.

Event loglarda daha sıkı ACLler

Event logları üzerindeki ayrıcalıklar konusunda da sıkılaştırmalar yapıldı. Daha da iyisi her event log için artık registry üzerinden yerel olarak gerekli gördüğünüz güvenlik ayarlarını yapabiliyorsunuz:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog

Mesela Application Logla ilgili güvenlik ayarlarını yapmak için aşağıdaki registry değerini değiştirmelisiniz:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomSD

System log için:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\System\CustomSD

İlgili ayarı yapmak için Security Descriptor Definition Language (SDDL) sentaksını kullanmanız gerekir.

(SDDL hakkında daha detaylı bilgi için: http://msdn.microsoft.com/library/en-us/security/security/security_descriptor_string_format.asp

Konsol uygulamalarının uzaktan yürütülmesinde kısıtlama

Kötü amaçlı kişilerin cmd.exe ve başka araçlara uzaktan erişmesini engellemek için bazı kritik konsol uygulamaları ile ilgili ACLler de değiştirilmiş durumda. cmd.exe için Windows 2000 ve Windows 2003 ayarlarının bir karşılaştırmasını yapacak olursak:

Windows 2000
Administrators (Full Control)
System (Full Control)
Users (Read & Execute)
Windows Server 2003
Administrators (Full Control)
System (Full Control)
Interactive (Read & Execute)
Services (Read & Execute)

Bu değişiklik iyi niyetli kişiler için pek de önemli olmasa gerek, ama yine de bilmekte fayda var.

Anonim kullanıcılar için daha fazla kısıtlama

Bu da iyi niyetlileri pek etkilemeyecek bir değişiklik ama, uygulamanız Windows Server 2003e anonim olarak bağlantılar yapıp bilgi topluyorsa etkilenecektir. Temelde olan değişiklik, anonim tokenından Everyone SIDinin çıkarılmış olması. Anonim erişime izin vermek istiyorsanız, Group Policy Object eklentisini kullanarak bunu açıkça belirtmeniz gerekiyor. (Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options.)

Hafızada şifreleme

Bu da uygulamalarınızı çok fazla etkilemeyecek ama biliyor olmanız gereken bir değişiklik.

Windows Server 2003te sırları hafızada şifrelemek ya da açmak için kullanabileceğiniz iki yeni fonksiyon eklenmiş bulunuyor. Parolalar, kriptografik anahtarlar gibi veriler için bunları kullanabilirsiniz. Bu, potansiyel veri korunmasızlık riskini azaltır. Yeni fonksiyonlar, CryptProtectMemory ve CryptUnprotectMemory adlarını taşıyorlar. (Aynı işlevi Windows Server 2000 SP3 ve Windows XPde de RtlEncryptMemory ve RtlDecryptMemory fonksiyonları ile gerçekleştirebilirsiniz.)

Özet

Yeni platform için uygulamalarınızı test edin! Hem daha önce yazmış olduklarınızı, hem de yeni yazıyor olduklarınızı. Sorunsuz çalışmasını beklediğiniz kodlarınızda sorunlarla karşılaşabilirsiniz. Kullanıcılarınız yerine sizin bu sorunları keşfetmeniz daha doğru olacaktır.

Hem unutmayın ki, tüm bu yorucu gözüken değişiklikler, uygulamalarınızın daha güvenli çalışabilmesi, hem sizin hem de kullanıcılarınız daha rahat uyuyabilmesi için. : ))