BİLİŞİM VE BİLGİ GÜVENLİĞİ İLERİ TEKNOLOJİLER ARAŞTIRMA MERKEZİ 2015 TÜBİTAK BİLGEM Bilişim ve Bilgi Güvenliği İleri Teknolojiler Araştırma Merkezi P.K. 74, 41470 Gebze / KOCAELİ Tel: (0262) 648 10 00, Faks: (0262) 648 11 00 www.bilgem.tubitak.gov.tr
DOKÜMAN ONAY BİLGİLERİ Adı Soyadı Görevi Tarih İmza Hazırlayan(lar) Kontrol Eden(ler) Onaylayan(lar) DEĞİŞİKLİK KAYITLARI Revizyon No Revizyon Tarihi Revizyon Nedeni Hazırlayan(lar) 2 / 33
İÇİNDEKİLER Kısaltmalar...5 Semboller...6 Şekiller...7 1. GİRİŞ...8 1.1 Bilgi Güvenliği Kapısı nda Yer Alan Kılavuzlar Hakkında Genel Bilgiler...8 1.2 Amaç ve Kapsam...9 1.3 Hedeflenen Kitle...9 2. TEMEL KAVRAMLAR... 10 2.1 Uygulama Seviyesi Saldırılar... 10 2.2 IIS Sunucusu Kurulum Ayarları... 10 2.3 Statik İçerik için Yeterli Bileşenler... 11 2.3.1 Common HTTP Features... 11 2.3.2 Management Tools... 11 2.4 IIS 7.0 için Güvenlik Yenilikleri... 11 2.5 IIS 7.5 için Güvenlik Yenilikleri... 12 2.6 XML Konfigürasyon Dosyaları... 13 3. IIS SUNUCUSU SIKIŞTIRMALARI... 14 3.1 Web İçeriği... 14 3.2 Servis Ayarları... 14 3.3 Host Başlığı... 15 3.4 Uygulama Havuzu... 15 3.4.1 Worker Process... 16 3.4.2 Recycle... 17 3.5 Kimlik Doğrulama Mekanizmaları... 18 3.5.1 Anonim Kimlik Doğrulama... 18 3.5.2 Temel Kimlik Doğrulama... 19 3.5.3 Form Kimlik Doğrulama... 19 3.5.4 Özet Kimlik Doğrulama... 19 3.5.5 Tümleşik (Integrated) Windows Kimlik Doğrulama (Negotiate)... 20 3.5.6 Akıllı Kart Kimlik Doğrulama... 21 3.5.7 Uygulanma Sırası... 21 3.6 SSL Sıkıştırma... 21 3.7 NTFS İzinleri... 22 3.8 Kayıt Tutma... 23 3.9 Debug Özelliği... 25 3.10 Hata Mesajları... 25 3.11 Talep Filtreleme... 26 3.12 HTTP Trace... 27 3.13 URL Rewrite... 27 3.14 IP Kısıtlama... 28 3.15 Bağlantı Sayısı ve Süresini Kısıtlama... 29 3.16 Dizin Güvenliği... 29 3.17 Dizin Tarama... 30 3.18 Deployment Retail... 30 3.19 Handler Mappings... 30 3 / 33
3.20 ISAPI Süzgeçleri ve CGI... 31 3.21.Net Güven Seviyesinin Yapılandırılması... 32 3.22 Diğer Güvenlik Önlemleri... 32 4 / 33
Kısaltmalar AAA : Authentication, Authorization, Accounting ACL : Access Control List AES : Advanced Encryption Standart AH : Authentication Header BIOS : Basic Input / Output System BGP : Sınır Ağ Geçidi Protokolü CAST : Bir blok şifreleme algoritması (block cipher), Kısaltma Carlisle Adams, Stafford Tavares in ilk harflerinden oluşmaktadır. DES : Data Encryption Standart DHCP : Dynamic Host Control Protocol DMZ : Demilitarized Zone / Demarcation Zone DNS : Domain Name Server DoS : Servis Dışı Bırakma (Denial of Service) DDOS : Dağıtık Servis Dışı Bırakma (Distributed Denial of Service) EAP-TLS : Extensible Authentication Protocol Transport Layer Security EGP : Harici Ağ Protokolü ESP : Encapsulating Security Payload FTP : File Transfer Protocol GAŞ : Geniş Alan Şebekesi Gbps : Giga bit per second http : Hypertext Transfer Protocol ICMP : Internet Control Message Protocol IDEA : International Data Encryption Algorithm IDS : Intrusion Detection System IEEE : Institute of Electrical and Electronics Engineers IGP : Dahili Ağ Geçidi Protokolü IGRP : Dahili Ağ Geçidi Yönlendirme Protokolü IKE : Internet Key Exchange IP : İnternet Protokolü IPS : Intrusion Prevention System 5 / 33
IPSec : Internet Prtocol Security ISDN : Integrated Services for Digital Networks L2TP : Layer 2 Tunneling Protocol MAC : Media Access Control Mbps : Mega bit per second NTP : Network Time Protocol OSI : Open System Interconnection PEAP : Protected Extensible Authentication Protocol POP3 : Post Office Protocol 3 PPTP : Point to Point Tunneling Protocol RADIUS : Remote Authentication Dial In User Service RIP : Yönlendirme Bilgi Protokolü SHA - 1 : Secure Hash Algorithm 1 SMTP : Sent Mail Transfer Protocol SNMP : Simple Network Management Protocol SSH : Secure Shell SSL : Secure Socket Layer TCP : Transport Control Protocol TFTP : Trivial File Transfer Protocol TKIP : Temporal Key Integrity Protocol UDP : User Datagram Protocol VLAN : Virtual Local Area Network VTP : Cisco ya özgü VLAN Yönetim Protokolü WEP : Wired Equivalent Privacy WLAN : Wireless Local Area Network WMAN : Wireless Metropolitan Area Network WPA : Wireless Protected Access WPAN : Wireless Personal Area Network WPA - PSK Wireless Protected Access-PreShared Key Semboller koyu : İngilizce terimleri belirtmek için kullanılır. komut : Kod parçalarını ve betikleri belirtmek için kullanılır Koyu altı çizili : Vurgu yapmak içindir. 6 / 33
Şekiller Şekil 1 Web Uygulamaları ve Uygulama Havuzları... 16 Şekil 2 Kayıt Tutulması Gereken Değerler... 24 7 / 33
1. GİRİŞ 1.1 Bilgi Güvenliği Kapısı nda Yer Alan Kılavuzlar Hakkında Genel Bilgiler Bilgi Güvenliği Kapısı (www.bilgiguvenligi.gov.tr) web sitesi ve bu sitede yer alan kılavuzlar; ilk olarak Ulusal Bilgi Sistemleri Güvenlik Projesi kapsamında hazırlanmıştır. Daha sonra Kalkınma Bakanlığı nın 2012 bütçesinden desteklenen Kamu Bilgi Sistemleri Güvenliği Programı kapsamında, Bilgi Güvenliği Kapısı web sitesinin siber güvenlik bilgi bankasına dönüşmesi ve siber güvenliğin farklı alanlarında Türkçe içerik oluşturma hedefiyle güncellenmiştir. Bu süreç içinde ihtiyaç doğrultusunda yeni kılavuzlar da oluşturulmuş, kullanıcıların siber güvenlik bilincini arttırmak hedefiyle daha interaktif görsel materyalle desteklenmiş e-öğrenme formatında içerik eklenerek, bilgi bankası zenginleştirilmiştir. Kılavuzlar siber güvenliğin hem teknik hem de teknik olmayan alanlarında bilgi aktarımı hedefiyle hazırlanmıştır. İçerikte; bazen bir servisin, bir işletim sisteminin ya da bir protokolün güvenlik yapılandırmasının gerçekleştirilmesi amacıyla verilen bilgilerin yanı sıra, siber güvenliğin bir bütün olarak görülmesi ve yönetilmesi ihtiyacından yola çıkarak yönetimsel kontrollere ait bilgiler de yer almaktadır. Diğer taraftan kılavuzlarda bilgiye ek olarak gerektiğinde tecrübelere de yer verilmiştir. Kılavuzların daha hızlı okunabilmesi ve etkili kullanılabilmesi için önemli komutlar ya da hap niteliğinde olan özet bilgiler farklı formatta sunulmuştur. Bu sayede sistem, ağ, etki alanı vs. yöneticileri, son kullanıcılar, bilgi güvenliği yönetim sistemi yürütücüleri ya da yöneticiler tarafından başucu referansı olarak kullanılması hedeflenmiştir. Bu dokümanda ticari markalara ismen yer verilmiş olabilir. Bu markalar ve ürünler tamamen özgün sahiplerine aittir. Kılavuzlarda sunulan bilgi, tecrübe, uygulama ve komutlar tamamen tavsiye niteliğinde olup en yoğun kullanılan ürün, sistem, servis ya da protokoller göz önünde bulundurularak hazırlanmıştır. Bu nedenle verilen komut, bilgi ya da tecrübe değişik ürünler/yapılandırmalar için farklılık gösterebilir. TÜBİTAK BİLGEM kılavuzlarda verilen bilgi ve bu bilgiye bağlı olarak sunulan yöntemler ya da uygulamalardan doğabilecek zararlardan sorumlu değildir. Bu doküman TÜBİTAK BİLGEM in izni olmadan değiştirilemez, ticari getiri elde etmek amacıyla basılamaz, çoğaltılamaz, dağıtılamaz. Güncelleme, ekleme ya da düzeltme taleplerinizi sge.info@tubitak.gov.tr e-posta adresine gönderebilirsiniz. 8 / 33
1.2 Amaç ve Kapsam 1.3 Hedeflenen Kitle 9 / 33
2. TEMEL KAVRAMLAR Günümüzde internetin önemi arttıkça web sunucularının önemi de artmaktadır. Web sunucuları, organizasyonların dışarıya açık yüzüdür ve bu yüz dışarıdaki saldırganların iştahını kabartmaktadır. Web sunucularının temel işlevleri şu şekildedir: Kullanıcılara ve diğer organizasyonlara, organizasyon hakkında bilgi sağlamak Kullanıcıların içerikleri indirmesini sağlamak veya içerik yüklemesini sağlamak; böylece internet ortamında veri transferini organize etmek İç ağda organizasyonel işlemlerin gerçekleştirilmesini sağlamak Microsoft un web sunucusu çözümü IIS (Internet Information Services) sunuculardır. Bu başlıkta IIS ile ilgili temel noktalar güvenlik odaklı olarak incelenecektir. 2.1 Uygulama Seviyesi Saldırılar Web yazılımlarına karşı yapılabilecek saldırılardan en önemlileri şu şekildedir: XSS (Cross Site Scripting): Web sayfalarındaki veri giriş alanlarına zararlı kodlar göndererek yapılan saldırılardır. SQL enjeksiyonu (SQL Injection): Web uygulamalarının arkasında çalışan veritabanına yapılan sorgularla gerçekleştirilen saldırılardır. Çerez ve oturum zehirleme (Session Poisoning): Oturumun sürekliliği için kullanılan çerezlerin kötüye kullanılması ile gerçekleşen saldırılardır. Hafıza taşması (Buffer Overflow): Çalışma anında sunucu belleğini doldurmak için yapılan saldırılardır. Çerez kurcalama (Cookies Snooping): Şifrelenmiş çerezlerin şifresinin çözülmesine yönelik yapılan saldırılardır. Sıfırıncı gün atakları (Zero Day Attacks): Henüz yaması çıkmamış olan saldırılardır. CSRF saldırıları: Kullanıcının giriş yaptığı bir uygulamada kullanıcının izni olmaksızın, kullanıcının oturum bilgisiyle zararlı isteklerde bulunma saldırısıdır. 2.2 IIS Sunucusu Kurulum Ayarları IIS sunucusu kurulumu yapılırken dikkat edilecek bir kaç önemli nokta aşağıda belirtilmiştir. Bazı zararlı sistemler dünya üzerinde tüm ip numaralarını belirli aralıklarla gezerek yeni kurulan ve güvenlik sıkılaştırılması tam olarak yapılmamış olan sunucu veya uygulamaları saptamaya çalışır. Bu gibi tehlikelerden korunmak için IIS sunucu mutlaka DMZ adı verilen yarı güvenli bölgeye kurulmalıdır. Sunucunun fiziksel güvenliği sağlanmalıdır. 10 / 33
IIS sunucunun barındıracağı uygulamalar, yüksek performansta çalışması gereken uygulamalar ise; IIS sunucuya yüksek kapasiteli RAM, önbellek (cache) ve yüksek hızlı CPU verilmelidir. Gereksiz donanım ve uygulamalar kaldırılmalıdır. IIS sunucusu kurulurken minimum yetki ve özellik kuralı uygulanmalıdır. Örneğin FTP özelliğine ihtiyaç duymayan bir IIS uygulamasına FTP özelliği eklenmemelidir. Sunucu, son güncelleştirmelere sahip olmalıdır. 2.3 Statik İçerik için Yeterli Bileşenler IIS kurulumu ile gelen gereksiz bileşenler kaldırılmalıdır. Statik HTML içerikleri ve resim gibi dosyalar kullanılması yeterliyse, sadece aşağıda belirtilen bileşenlerin kullanılması tavsiye edilmektedir: 2.3.1 Common HTTP Features Static Content: Web sunucusunun statik olan web dosya biçimlerinin (html sayfaları, görüntü dosyaları vs) yayımlanmasını sağlar. Böylece kullanıcılar bir web tarayıcısıyla bu dosyaları görüntüleyebilir. Default Document: URL olarak bir dosya belirtilmediği zaman, yönlendirme işleminin gerçekleştirileceği sayfayı belirtir. Örneğin www.tubitak.gov.tr adresindeki içeriğe sahip olan www.tubitak.gov.tr/index.html sayfasına yönlendirir. 2.3.2 Management Tools IIS Management Console: Yerel veya uzak bir IIS sunucunun yönetimi için grafiksel bir arayüz sağlar. IIS Management Scripts and Tools: Komut satırı veya betikleri kullanarak IIS sunucuyu yönetmeyi sağlar. Management Service: Uzaktan IIS sunucu yönetimi için kullanılır. Diğer bileşenler gerektiği zaman yüklenebilir, işleri bittiği zaman kaldırılabilir. 2.4 IIS 7.0 için Güvenlik Yenilikleri IIS 7.0 Microsoft tarafından tamamen yeniden üretilmiş bir uygulama olduğundan dolayı, IIS 6.0 ve daha önceki versiyonlara göre çok daha esnek ve güvenilir bir yapı sunmuştur. IIS 7.0 ile birlikte gelen bazı önemli yenilikler aşağıda belirtilmiştir: IIS 6.0 da kurulu olan bir web uygulamasında herhangi bir konfigürasyon değişikliği yapılmak istendiği zaman tüm kurulumun baştan yapılması gerektiği için bu durum ilgili web uygulamasının bir müddet servis dışı kalmasına sebep oluyordu. Fakat IIS 7.0 ile birlikte gelen modüler mimari sayesinde web uygulamaları için gereken özellikler web.config benzeri bir konfigürasyon dosyasında tutulmaya başlandı, bu sayede web uygulaması için gereken 11 / 33
özellikler (features) herhangi bir an uygulamaya eklenebiliyor veya ihtiyaç duyulmayan bir özellik uygulamadan kolayca kaldırılabiliyor hale gelmiştir. IIS 7.0 ile birlikte gelen bir diğer yeni özellik de.net ve ASP.NET entegrasyonudur. IIS 6.0 versiyonunda.net Framework ü web sunucusundan bağımsız bir şekilde çalışırdı ve görevi yalnızca web sunucu tarafından derlenmesi için kendisine gönderilen.aspx gibi uzantılı dosyaları derleyip sonucunu web sunucuya HTML formatında vermekti. Bu sebeple,.net Framework tarafından sunulmuş olan Url Rewritting veya Form Authentication gibi bir çok özellikten yalnızca ASP.NET ile geliştirilmiş uygulamalar faydalanabiliyordu. IIS 7.0 ın gelmesi ile bu kısıtlama kaldırıldı, bir uygulama ASP.NET ile geliştirilmemiş olsa dahi.net Framework ünün sunduğu özelliklerden faydalanabilmektedir. Diğer önemli yenilik ise, IIS 7.0 ın gelmesi ile birlikte uygulamaya özel XML formatlı konfigürasyon dosyalarının oluşturulmasıdır. Bu yenilik sayesinde web uygulaması temelli ayarlamalar yapılabilmekte ve yönetim kolaylaşmaktadır. Daha önceki IIS sürümlerinde tek bir metabase dosyası tutulmuş tüm uygulamalar buradan yönetilmeye çalışılmış, bu durum da yönetimi zorlaştırmaktaydı. Yukarıda belirtilen maddelere ek olarak, IIS 7.0 ve 7.5 varsayılan olarak minimum bileşen kurulumu ile gelmektedir. Bu yenilik sayesinde minimum bileşen ile kurulan bir IIS sunucu çeşitli avantajlara sahiptir, bu avantajlardan en önemlileri aşağıda sıralanmıştır: Sunucularda hizmet veren bileşen sayısı arttıkça, sunucunun saldırganlar tarafından saldırıya uğrama riski de artar, minimum bileşen ile kurulan bir sunucuda potansiyel saldırı yüzeyi azaltılmış olur. Bileşen sayısı arttıkça yönetimi ve güncellenmesi artacağından dolayı, daha az bileşenle yapılmış bir kurulum daha kolay yönetilir. Bileşen sayısının az olması, bellek (memory) tüketimini azaltacağından sunucunun performansını ve devamlılığını arttırır. 2.5 IIS 7.5 için Güvenlik Yenilikleri IIS 7.5 ile bir önceki versiyonunda ( IIS 7.0 ) yapıldığı gibi köklü değişiklik ve yeniliklere gitmek yerine IIS 7.0 ile gelen bir çok özellik üzerinde iyileştirme uygulanmıştır. İyileştirilen özelliklerden bazıları; WebDAV ve FTP Talep Filtreleme (Request Filtering) Yönetimsel modüller 12 / 33
PowerShell için IIS modülünün eklenmesi Kayıt tutma (loglama) ve izleme faaliyetlerinin ayarlanması IIS üzerinde kullanılan servis sıkılaştırılması Servis hesaplarının yönetimi FastCGI için yapılacak taleplerden oluşabilecek hataların izlenmesi olarak sıralanabilir. IIS 7.5 sunucuları hakkında ayrıntılı bilgi için bakınız: http://serverfault.com/questions/312915/what-differences-are-between-iis-7-0-and-iis-7-5 http://technet.microsoft.com/en-us/library/dd939979(ws.10).aspx 2.6 XML Konfigürasyon Dosyaları IIS üzerinde konfigürasyon bilgilerini tutmak için XML dosyaları kullanılmaktadır. Bu dosyalarda hem IIS hem de ASP.NET için bir takım ayarlar bulunur. IIS 7.0 ile artık konfigürasyon ayarları, metabase içerisinde veya kayıt defteri (Registery Editor) içerisinde ayarlanmasına gerek kalmadan bu konfigürasyon dosyalarında ayarlanır. Eski versiyon IIS üzerinde bulunan XML konfigürasyon dosyaları ve yerleri aşağıdaki gibi sıralanabilir: %WinDir%\System32\Inetsrv\Config dizini altındaki; o ApplicationHost.config o Administration.config o Redirection.config \Microsoft.NET\Framework\vXXX\Config; o Machine.config o Web.config Kök ve uygulama dizinleri; o Web.config IIS sunuculardaki XMLD dosyaları ve diğer kritik dosyaların güvenliği önem arzetmektedir. Belirlenen kritik dosyalar belli aralıklarla yedeklenmelidir. Yedekleme işlemi otomatik ve manuel olarak gerçekleştirilebilmektedir. Yedekleme işleminin temel adımları aşağıdaki gibidir: %SystemDrive%\inetpub\history klasöründe son 10 değişiklik saklanmaktadır ve IIS sunucu her iki dakikada bir değişiklik olup olmadığını kontrol ederek otomatik yedekleme sağlar. %SystemDrive%\System32\Inetsrv\backup dosyası el ile (manüel olarak) yedeklenmelidir. 13 / 33
3. IIS SUNUCUSU SIKIŞTIRMALARI Bu başlık altında IIS sunucuları için temel sıkılaştırma adımları incelenecektir. 3.1 Web İçeriği IIS üzerinde çalışan web kaynakları sanal dizinler (Virtual Directories) kullanılarak diskte fiziksel dizinlere eşlenir. Bu özellik kullanılarak, web dosyaları ile sistemin çalışması için gerekli dosyaların farklı fiziksel bölümlerde bulundurulması tavsiye edilmektedir. Web içeriği varsayılan olarak "C:\inetpub\wwwroot" altında bulunur. Sistem dosyaları da C:\Windows altında bulunur. Web içeriği dosyaların sistem dosyaları ile aynı fiziksel bölüme konulması, web sitesinin sistemin disk alanını doldurarak sistemi çalışamaz hale getirmesine neden olabileceği gibi, web sitesinden kaynaklanabilecek bir dosya okuma-yazma açıklığı yüzünden sistem dosyalarının izinsiz okunmasına veya bozulmasına da neden olabilir. Bu sebeple, uygulamaların veya sanal dizinlerin (Virtual Directories) yeni fiziksel bölümü yansıtması için eşleme (mapping) ayarlarının düzeltilmesi gerekmektedir. Bu dizinlerin sistem dosyalarının bulunduğu diskte farklı bir yerde olması gerekmektedir. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Sites > Site Adı > (Actions Penceresi) Basic Settings > Physical Path. 3.2 Servis Ayarları IIS sunucularda klasik servis güvenliği haricinde 3 noktaya daha dikkat edilmesi gerekmektedir: World Wide Web Publishing Services adı servisinde bir problem çıkması durumunda servis yeniden başlatılmalıdır. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: Run > Services.msc > World Wide Web Publishing Services > Properties> Recovery Sekmesi > First, Second, Subsequent Failures kısımlarında 'Restart Service' seçilir. Indexing Service devre dış bırakılmalı veya kaldırılmalıdır. Remote Data Service adlı servise ait 'HKLM\system\CurrentControlset\Services\W3SVC\Parameters\ADCLaunch' kütük anahtarı kaldırılmalıdır. 14 / 33
3.3 Host Başlığı Host Header değeri aynı IP adresinden ve porttan birden fazla web sitesinin servis vermesini sağlar. Bu değerin kullanılmamış olması, iki temel zafiyete sebep olur: Organizasyonun web sunucusu "DNS rebinding" saldırılarına açık olur. Böylece saldırgan site içeriğini ele geçirebilir veya sitenin erişilebilirliğine zarar verebilir. IP tabanlı otomatik tarama gerçekleştiren ve web sitelerine saldırı gerçekleştiren araçlar tarafından organizasyonun bilgileri ele geçirilebilir. Bu gibi saldırılarda karşı saldırı yüzeyini daraltmak için host başlığının tanımlanması tavsiye edilmektedir. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Sites > Site Seçimi > (Actions Penceresi) Bindings > Host Adı > Edit 3.4 Uygulama Havuzu Application Pool (uygulama havuzu), temel işlevi web uygulamalarını birbirlerinden ayırarak izole etmek olan bir IIS bileşenidir. Uygulama Havuzu, IIS 6.0 ile birlikte gelmiş IIS 7.0 ve IIS 7.5 ile daha da geliştirilmiştir. Uygulama Havuzu içerisinde birden fazla web uygulaması barındırılabilir. Genellikle bir IIS sunucu içerisinde birden fazla Uygulama Havuzu ve bunların içerisinde birden fazla sayıda web uygulaması kullanıcılara hizmet vermektedir. IIS 7.0 ile birlikte Uygulama Havuzu yapısına izolasyon özelliği de eklenmiştir. Böylece, farklı Uygulama Havuzları içerisinde çalışan web uygulamaları birbirlerini etkileyemezler. Örneğin DENEME isimli Uygulama Havuzu içerisinde çalışan bir web uygulaması, TEST isimli Uygulama Havuzu içerisinde çalışan bir web uygulamasını etkileyemez. Özellikle hosting hizmeti veren sistemlere her bir web uygulaması için birer Uygulama Havuzu oluşturması tavsiye edilir. Bu şekilde tasarlanmayan sistemlerde tüm web uygulamaları bir Uygulama Havuzu içerisinde olacağından dolayı, web uygulamalarının birinden kaynaklanan bir problem sebebiyle, Uygulama Havuzu kendini yeniden başlatırsa, aynı Uygulama Havuzu içerisindeki bütün web uygulamaları bu durumdan etkilenir. Bu gibi bir durumdan kaçınmak için, her bir web uygulamasına ayrı Uygulama Havuzu verilmesi gerekmektedir. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Sites > Site Adı > (Actions Penceresi) Basic Settings > Application Pool Değişikliği: Select butonu ile değiştirilir. 15 / 33
Şekil 1 Web Uygulamaları ve Uygulama Havuzları Bunun yanında Uygulama Havuzu Kimliği ni, Network Services haricindeki en az yetkili bir kullanıcıya verilmesi gerekmektedir. Eğer bu işlemi gerçekleştirmek için bir kullanıcı oluşturulmuşsa bu kullanıcının IIS_IUSRS grubunun bir üyesi olması gerekmektedir. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Application Pools > Web Uygulamasına Ait Application Pool Seçimi > (Actions Penceresi) Advanced Settings > Process Model: Identity uygun olarak belirlenir. 3.4.1 Worker Process Web uygulamalarına yapılacak her bir istekte (request), işletim sistemi proses oluştursaydı, bu işletim sisteminin performansını ciddi oranda olumsuz olarak etkilerdi. Çünkü bir web uygulamasına bazen birim zamanda binlerce istek yapılabilmektedir ve işletim sisteminin proses oluşturması sistem açısından maliyetli bir süreçtir. Bunun önüne geçilmesi amacıyla Worker Process (İşçi Prosesler) denilen bir yapı geliştirilmiştir. İşçi Prosesler, Uygulama Havuzu içerisinde çalışan web uygulamalarına yapılan isteklerde ve bu isteklere verilen cevaplarda, web uygulamalarına hizmet eden proseslerdir. Bu prosesler işleri bittiğinde işletim sisteminde bulunan normal prosesler gibi sistemden silinmezler ve yeni bir isteğin gelmesini beklerler. Aynı Uygulama Havuzu nda birden fazla İşçi Proses in oluşturulması işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Application Pools > Web Uygulamasına Ait Application Pool Seçimi > (Actions Penceresi) Advanced Settings > Process Model: Maximum Worker Processes, Rapid-Fail Protection: Failure Interval (minutes) & Maximum Failures uygun olarak belirlenir. 16 / 33
Varsayılan olarak bir Uygulama Havuzu içerisinde, Maximum Worker Process ile belirtildiği üzere bir tane İşçi Proses çalışır. Bunun yanında, IIS 7.0 ve 7.5 ile iyileştirilen İşçi Proses yapısı ile izole edilmiş Uygulama Havuzları içerisinde birbirini etkilemeyecek İşçi Prosesler oluşturmak mümkündür. Ayrıca Failure Interval ve Maximum Failures ayarları ile Uygulama Havuzu nda ne kadar süre içerisinde kaç tane hata alındığında Uygulama Havuzu nun yeniden başlatılmayacağı ayarı da tanımlanabilir. Varsayılan olarak 5 dakika içerisinde 5 kere hata alındığında Uygulama Havuzu her defasında yeniden başlatılır. Ancak 5 dakika içerisinde 6. kere Uygulama Havuzu nda hata olursa yeniden başlatılmaz, tamamen kapatılır. Buradaki bağlantı yönelimli ifadesi şu anlama gelmektedir: İstemciler iletişime geçmeden önce aralarında bir oturum kurulur. Oturumun açılması sırasında istemciler kendi iletişim parametrelerini birbirlerine iletir ve iletişim esnasında bu parametrelere göre hareket edilir. 3.4.2 Recycle Recyle, bir Uygulama Havuzu içerisinde çalışan İşçi Prosesler in hangi zaman aralıkları ile sonlandırılıp yeni İşçi Prosesler in oluşturulacağını belirleyen mekanizmadır. Recyle mekanizması sayesinde İşçi Thread lerin çalışırken karşılaşabilecekleri hatalar sonucu web uygulamalarına hizmet verememe gibi durumlarının önüne geçilmiştir. Varsayılan olarak Recyle değeri 1740 dakikadır (29 saat). Bu süre dolduğunda Uygulama Havuzu ile ilişkili İşçi Proses sonlandırılıp, yeni bir İşçi Proses başlatılacağı için Recycle esnasında açık oturumlar kapanacaktır. Ancak, Recyle değerinin bu şekilde verilmemesi tavsiye edilmektedir. Çünkü her 29 saatte bir İşçi Prosesler in çalışması sonlanacak, eski İşçi Prosesler sistemden silinecek ve yeni İşçi Prosesler oluşturulacaktır. Bu süreç içerisinde web uygulamaları kullanıcılara hizmet verirken kesintiler yaşanabilir, ve 29 saatte bir bu işlemin yapılması demek bir zaman sonra gün içerisinde web uygulamasının yoğun kullanıldığı durumlarda da Recyle işleminin yapılabileceği demektir. Belirtilen sebeple, web uygulamalarının yoğun olarak kullanılmayacağı belirli (gece) saatlerde yapılması için bu sürenin 24 saat verilmesi tavsiye edilmektedir. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Application Pools > Web Uygulamasına Ait Application Pool Seçimi > (Actions Penceresi) Recycling... > Regular time intervals seçeneği kaldırılır, Specific time(s) seçilir ve uygun değer girilir. 17 / 33
Bunun yanında Uygulama Havuzu çok fazla bellek kullanıyorsa, belirli bir bellek kullanımına ulaşıldığında da Recycle işleminin başlaması sağlanmalıdır. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Application Pools > Web Uygulamasına Ait Application Pool Seçimi > (Actions Penceresi) Recycling... > Memory Based Maximums seçilir ve uygun değer girilir. 3.5 Kimlik Doğrulama Mekanizmaları IIS sunucuları üzerinde 6 temel kimlik doğrulama mekanizması bulunmaktadır: Anonim (Anonymous) Temel (Basic) Form (Form) Özet & Gelişmiş Özet (Digest & Advanced Digest) Tümleşik (Integrated) Akıllı Kart (Smart Card) Bu seçim işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Sites > Site Adı > Authentication 3.5.1 Anonim Kimlik Doğrulama Web sunucusu, herhangi bir kimlik doğrulama mekanizması uygulanmadan gelen talepleri kabul eder. Bu kimlik denetiminin bir takım güçlü ve zayıf yönleri vardır. Güçlü Yönleri: En hızlı kimlik denetim yönetimidir Bütün güvenlik duvarı ve tarayıcılarla uyumludur Kullanıcı fark etmeden işlem yapabilir Zayıf Yönleri: Kimlik denetimi yoktur Herkes aynı kullanıcı ile bağlantı sağlar Kullanıcı temelli kayıt tutulamaz 18 / 33
3.5.2 Temel Kimlik Doğrulama Kimlik doğrulama protokollerinin en basit ve eski olanıdır. En azından bir kimlik doğrulaması gerçekleştirmektedir. Genellikle Telnet, FTP, POP, IMAP, HTTP gibi protokollerde kullanılır. Kullanıcı adı ve parola gibi kimlik bilgileri ağ üzerinden sunucuya gönderilir ve sunucu üzerinde kimlik doğrulaması yapılır. Bu yöntemde kimlik bilgileri Base64 formatıyla şifrelenip gönderilir. Base64 formatıyla şifrelenmiş veriler kolayca kırılıp ham veriye ulaşılabildiği için, bu yöntem kimlik bilgisinin açık şekilde gönderilmesi gibi düşünülebilir. Temel Kimlik Doğrulama (Basic Authentication) verinin güvenli iletimi gerekçesi ile HTTPS protokolü ile kullanılmalıdır. HTTP protokolü ile kullanımı önerilmemektedir. 3.5.3 Form Kimlik Doğrulama Günümüzde sıklıkla web uygulamalarında karşılaştığımız en çok kullanılan yöntemdir. Bu kimlik doğrulama yöntemi, Temel Kimlik Doğrulama ve Özet Kimlik Doğrulama gibi bir pencere çıkararak kullanıcı bilgilerini almak yerine, (genellikle) kullanıcıları oturum açma sayfasına (login page) yönlendirirler ve bu sayfada (genellikle) form yapısı kullanılarak kullanıcı bilgileri istenir. Form Kimlik Doğrulama metodunda genellikle kullanıcı kimlik bilgileri web sitesine ait veritabanlarında tutulur ve girilen kimlik bilgileri buradan kontrol edilir. Girilen bilgiler doğru ise, kullanıcıya kendisini temsil eden bir çerez (cookie) gönderilir ve bununla kullanıcı web sitesi içerisinde dolaşmaya devam eder. Diğer kimlik doğrulama yöntemlerine göre daha esnek yapıdadır (Kullanıcıdan kullanıcı adı, parola dışında ekstra bilgi istenebilir; E-mail, Cilt_No, Aile_Sıra_No vb). Genellikle çok kullanıcılı uygulamalarda bu gibi bir kimlik doğrulama tercih edilir. 3.5.4 Özet Kimlik Doğrulama Temel Kimlik Doğrulama dan daha güvenilir bir kimlik doğrulama protokolüdür. Genel olarak ağ üzerinden kullanıcı adı, parola ve etki alanı bilgileri ile Nonce adı verilen rastgele (random) üretilmiş bir veri ile birlikte bir özetleme algoritması (MD5) kullanılarak özetlenir (hashing) ve sunucuya gönderilir. Bu bilgileri alan sunucu, Aktif Dizin den kullanıcı bilgisine erişerek istemci tarafından yollanan bilgiler ile karşılaştırır ve kimlik doğrulama işlemi tamamlanmış olur. Bir paket Özet Kimlik Doğrulama ile kimlik doğrulaması yapıyorsa HTTP başlık bilgisi WWW-Authenticate: Digest şeklindedir. Bu şekilde kimlik doğrulama yapan sistemlerde kullanıcı bilgileri ağ üzerinde açık halde gönderilmemiş olur. Özet Kimlik Doğrulama gerçekleştirildiğinde, SSL kullanılmasının kullanılması zorunlu hale getirilmelidir. 19 / 33
Güçlü Yönleri Temel kimlik doğrulama ile benzer ama şifreleme (kullanıcı adı / parola şifrelemesi) çok daha güvenlidir. Nerdeyse bütün tarayıcılar destekler. Proxy ve güvenlik duvarlarıyla çalışabilir. Anonim Kimlik Doğrulama dan sonraki en hızlı yöntemdir. Zayıf Yönleri Hala tarayıcıların tümü tarafından desteklenmez. IIS sunucunun, etki alanına üye olması gerekir. Aktif Dizin kullanıcı hesabı ile giriş yapılmalıdır. 3.5.5 Tümleşik (Integrated) Windows Kimlik Doğrulama (Negotiate) Windows etki alanında kullanılması tavsiye edilen kimlik doğrulama mekanizmasıdır. Windows ortamında oturum açmak için kullanılan Kerberos ve NTLM protokolleri Web sunucularda kimlik doğrulama işlemleri için de kullanılır. Önce Kerberos denenir, başarılı olmazsa NTLM kullanılır. NTLM de kullanılamıyorsa Temel Kimlik Doğrulama metodu geçerli olur. Bunun yanında tavsiye edilmese de, Kerberos kaldırılıp, sadece NTLM ile kimlik doğrulaması da sağlanabilir. Ancak Kerberos kullanılması kesinlikle tavsiye edilmektedir. Ayrıca, kimlik doğrulama için Tümleşik Windows Kimlik Doğrulama yöntemi tercih edildiğinde, Kerberos veya en az NTLMv2 kullanılmalıdır. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: Run > gpedit.msc > Windows Settings > Security Settings > Local Policies > Security Options > Network Security : Lan Manager Authentication Level ilkesi Send NTLMv2 Responses Only olarak seçilir. Güçlü Yönleri: Güçlü şifreleme sağlar. Kullanıcı fark etmeden giriş yapılabilir. Kerberos; Internet Explorer 5 ve Firefox 1 sonrası, NTLM; Internet Explorer 2 ve Firefox 1 sonrasını destekler. Zayıf Yönleri: Orman (forest) ortamında değilse, kullanıcı sisteme giriş yapmalıdır. Kerberos Aktif Dizin ve etki alanı denetleyicilerine (DC) erişim gerektirir. 20 / 33
Proxy sunucu sorunları bulunur. Sadece iç ağ sitelerine erişim için kullanılır. 3.5.6 Akıllı Kart Kimlik Doğrulama Web sunucusu istemcileri, istemcilerin sahip oldukları sertifika ile doğrulayabilir. Akıllı Kart ile Kimlik Doğrulama yönteminde geçerli sertifikaya ihtiyaç vardır ve sertifikanın iyi korunması gerekmektedir. Güçlü Yönleri Çift taraflı kimlik denetimi sağlar. Çoklu (Multi-factor) kimlik denetimine izin verir. 128-bit SSL veya daha üzeri güvenlik sağlar. Kullanıcı arka planda gerçekleşen güçlü PKI yapısı hakkında bir fikir sahibi olmadan, güvenli bir şekilde web sayfasına giriş yapılabilir. Zayıf Yönleri Tüm tarayıcılar tarafından desteklenmez. Kullanıcıda sertifika yüklü olmalıdır. Çok yoğun CPU kullanımı gereksinimi duyar. PKI kurulumu ve yönetiminin zordur. 3.5.7 Uygulanma Sırası Bir web sayfasında birden fazla kimlik doğrulama mekanizması etkin ise, belli bir sıraya göre deneme yaparak kimlik doğrular. Bu sıra şu şekildedir: Akıllı Kart (Smart Card) Anonim (Anonymous) Tümleşik (Integrated) Özet & Gelişmiş Özet (Digest & Advanced Digest) 3.6 SSL Sıkıştırma Web sunucularında iletişim güvenilirliğini sağlamak için SSL kullanılması tercih değil zorunlu hale getirilmelidir. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Sites > Site Adı > SSL Settings > Require SSL 21 / 33
Tüm sunucularda olduğu gibi web sunucularda SSL 2.0 ve PCT 1.0 gibi zayıf şifreleme protokolleri devre dışı bırakılmalıdır. Web sunucularda sadece SSL 3.0, TLS 1.x gibi güçlü şifreleme protokollerine destek verilmelidir. Web sunucuda zayıf şifreleme protokollerine destek verilmemesi verinin gizliliğinin ve bütünlüğünün korunması için gereklidir. Bu amaçla yapılması gerekenler şu şekildedir: PCT 1.0 protokolünün R2 ve SP2'de devre dışı kalması için aşağıdaki anahtar sistemde bulunmamalıdır ya da değeri 0 olmalıdır. o HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\P CT 1.0\Server\Enabled SSL 2.0 protokolünün R2 ve SP2'de devre dışı kalması için aşağıdaki anahtar değeri 0 olmalıdır. o HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\S SL 2.0\Server\Enabled SSL 3.0 protokolünün R2 ve SP2'de aktif olması için aşağıdaki anahtar sistemde bulunmamalıdır veya değeri "ffffffff:" olmalıdır. o HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\S SL 3.0\Server\Enabled Not: 2014 itibariyle ortaya çıkan bir açıklık sebebiyle SSL 3.0 sürümünün de zafiyeti (POODLE) tespit edilmiştir. Bu sebeple sadece TLS kullanılması tavsiye edilmektedir. TLS 1.0 protokolünün R2 ve SP2'de aktif olması için aşağıdaki anahtar sistemde bulunmamalıdır veya değeri "ffffffff:" olmalıdır. o HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\T LS 1.0\Server\Enabled TLS 1.1 protokolünün R2 de aktif olması için aşağıdaki anahtar değeri 0 olmalıdır. o HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\T LS 1.1\Server\DisabledByDefault TLS 1.2 protokolünün R2 de aktif olması için aşağıdaki anahtar değeri 0 olmalıdır. o HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\T LS 1.2\Server\DisabledByDefault 3.7 NTFS İzinleri NTFS, web sunucularda mutlaka kullanılması gereken yetkilendirme temelli erişim kontrolünü sağlayan bir dosya sistemidir. Bir web uygulamasının arka planında mevcut olan içeriklere 22 / 33
kullanıcıların erişimi için dosya izinlerinin (permission) ataması web uygulamasının kurulumu aşamasında ve ilgili içerikleri kapsayan hard disk bölümünde tamamen yapılmalıdır. IIS 7.0 ile birlikte eski IIS versiyonlarında kullanılan IUSR_makineAdı (örneğin IUSR_WEBSUNUCU2 ) kullanıcısının ve IIS_WPG grubunun yerini IUSR kullanıcısı ve IIS_IUSRS grubu almıştır. Bu kullanıcı, sistemde Anonim Kimlik Doğrulaması aktif olduğu zaman web uygulamasından hizmet alan anonim kullanıcılara arka taraftaki klasör ve dosyalara erişim izinlerini sağlar. Eski IIS sürümlerinde sistem bir makineden başka bir makineye taşındığında IUSR_WEBSUNUCU2 kullanıcısı oluşturulduğu sisteme özel SID değeri ile oluşturulduğundan dolayı, sistemin taşındığı yeni sunucu IUSR_WEBSUNUCU2 isimli kullanıcıyı tanımayacak ve sistemde birçok sorun oluşacaktı. Bu yenilik ile Microsoft IUSR kullanıcısını yerleşik (built-in) olarak ve her sistemde aynı değeri alan bir SID değeri ile oluşturur ve sistemin başka bir makineye taşınmasından dolayı oluşabilecek IUSR kullanıcısı problemlerinin önüne geçilmiş olur. Güvenliğin sıkılaştırılması açısından kullanıcı veya gruplara minimum yetki prensibi doğrultusunda ihtiyaç duydukları minimum NTFS izinleri verilmelidir. Ayrıca diğer önemli nokta ise IIS sunucudan hizmet almayı bekleyen IUSR kullanıcısı veya IIS_IUSRS grubuna okuma, çalıştırma ve listeleme haklarının verilmesi ve kayıt tutulmasının aktif olması gerekir. Bu işlem tamamlandıktan sonra, kullanıcılar tarafından kendilerine verilen hakların kötüye kullanılmasını engellemek için talep filtreleme ve URL Rewrite gibi önlemler mutlaka alınmalıdır. 3.8 Kayıt Tutma Kayıt tutulması, bir olay durumunda iz takibi yapılmasına olanak verir. Kayıt tutmak için NTFS in kayıt mekanizmaları ile IIS sunucularına ait kayıt mekanizmaları beraber kullanılmalıdır. İçerik dosyalarının tümü için NTFS kayıt tutma etkin hale getirilmelidir. En azından başarısız bütün erişim denemelerinin ve başarılı yazma, izin değiştirme ve sahipliğini alma işlemlerinin kaydının tutulması gereklidir. IIS üzerinde tutulan kayıtlar web sitesi düzeyinde tutulabildiği gibi dizin veya dosya seviyesinde de tutulabilir. HTTP, FTP ve SMTP protokolleri IIS tarafından kayıt altına alınabilen protokollerdir. Verilerin kayıtlarının tutulması sırasında değişik formatlar kullanılabilir (NCSA, IIS Log Formatı vs). Bu formatlar arasında en uyumlu olanı W3C formatıdır. W3C formatı en esnek olan formatlardan birisidir. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: 23 / 33
IIS Konsolu > Sunucu Adı > Sites > Site Adı > Logging > Log File > Format: W3C Kaydı tutulması gereken en önemli değerler aşağıdaki gibidir: Kayıt İsmi Kayıt Başlığı Tanım Tarih date Yapılan isteğin tarihi Saat time Yapılan isteğin zamanı (Saat cinsinden) İstemci IP Adresi c-ip İstemciye ait IP adresi Kullanıcı Adı cs-username Sunucuya erişim oturum açan kullanıcı ismi Servis Adı s-sitename İstemciye hizmet eden servis tipi ve bu servisin instance numarası Sunucu Adı s-computername Sunucuya ait yerel isim Metod cs-method İstemcinin istek yaparken kullandığı HTTP komutu (GET, PUT, HEAD vs) URI Stem cs-uri-stem IIS sunucudan talep edilen dosya, betik veya dizine ait yol Protokol Durumu sc-status Sunucudan istemciye gönderilen kodlar Şekil 2 Kayıt Tutulması Gereken Değerler Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Sites > Site Adı > Logging > Log File > Select Fields butonu ile alanlar seçilir. Grafiksel dizinlere erişimler de kayıt altına alınmamalıdır, çünkü bu şekilde bir kayıt tutma sistemi aktif edilirse, tutulan kayıtların büyük bir bölümü grafiksel dizinlerden kaynaklanacak ve bir saldırı olması durumunda iz sürme işlemi zorlaşacaktır. Bu şekilde kayıt tutma işlemi devre dışı bırakılmadan önce mutlaka ilgili dizinlere ait verilen izinler güvenlik sıkılaştırılmasından geçirilmelidir. Çünkü kötü niyetli kişiler tarafından sunuculara sızma denemelerinde kayıt tutma işleminin yapılmadığı grafiksel dizinler oldukça yoğun istismar edilir. W3C formatlı kayıt dosyaları yerel saate göre değil Greenwich saat dilimine göre kayıt altına alınır. Bu durum göz önünde bulundurularak kayıtların incelemesi gerçekleştirilmelidir. Ayrıca, Use local time for file naming and rollover seçeneği ile de sunucunun yerel saati ile eşleştirilir. Böylece saat ve tarih karışıklığına sebep olunmaz, başka sistemlerden alınan kayıtlarla ilişkilendirmede (corelation) tutarlılık sağlanmış olur. 24 / 33
Varsayılan kayıt dizini %SystemRoot%\Inetpub\logs\LogFiles\ altında web sitelerine ait dizinler içerisinde tutulur. IIS kayıtları bir saldırı durumunda olayla ilgili araştırmanın yapılması için gerekli kritik bilgileri tutmaktadır. Saldırganlar gerçekleştirdikleri aktiviteler sonunda kanıtları yok etmek amacıyla bu dosyalara erişim elde etmeye çalışacaklardır. Bu yüzden IIS kayıtlarının sistem dosyalarının ve web içeriklerinin bulunduğu bölümden farklı ve hakları kısıtlanmış bir alanda tutulması tavsiye edilir. IIS kayıtlarının sistem ve web dosyalarından farklı bir bölümde ve hakları kısıtlanmış bir alanda tutulması dosyaların değiştirilmesi veya silinmesi gibi riskleri azaltacağı gibi sistem arızası nedeniyle diskte oluşabilecek bir problem sonucunda kayıt dosyanın kaybedilmesi riskini de azaltır. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Sites > Site Adı > Logging > Log File > Directory Bunun yanında, HTTP.SYS sürücüsüne yapılan saldırılar gibi, alt seviyede yapılması muhtemel olan saldırılardan şüphelenilen durumlarda HTTP.SYS sürücüsünün varsayılan olarak aktif olan kayıt tutma özelliği kullanılabilir. HTTP.SYS tarafından tutulan kayıtlar %SystemRoot%\System32\LogFiles\HTTPERR\ altında tutulur ve isimlendirmesi httperrn.log şeklinde olur. 3.9 Debug Özelliği Uygulama geliştirme aşamasında herhangi bir problem çıktığı durumlarda, Debug modu etkinleştirilir ve Debug kayıtlarına bakılır. Ancak etkinleştirilen Debug modunun, web sayfası kullanıma açıldıktan sonra kapatılmaması durumunda, bu özellik kullanılarak saldırgan kişiler tarafından web sitesi hakkında detaylı bilgi elde edilmesi mümkündür. Bu sebeple Debug özelliği devre dışı bırakılmalıdır. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Sites > Site Adı >.NET Compilation > Behavior > Debug: False seçilir. 3.10 Hata Mesajları Güvenlik sıkılaştırmaları iyi yapılmış bir IIS sunucusu, bir betik veya bileşenden kaynaklı hataların (unhandled exception) olması durumunda istemcilere minimum bilgi prensibine göre hata mesajları göstermelidir. Bunun yanında özelleştirilmiş hata mesajları ile bir hata oluşması durumunda geri bildirimin yapılabileceği posta veya telefon gibi iletişim bilgileri hata mesajında görüntülenebilir. Ancak gereğinden fazla bilgi verilmesi halinde kötü niyetli kullanıcılar sunucu hakkında bilgi almak için kasıtlı olarak hata mesajı ürettirebilir. 25 / 33
İstemcilere gönderilecek olan hata mesajlarında minimum bilgi olması gerekirken, diğer taraftan web sitesi geliştiricileri tarafından alınması gereken hata mesajları ise hatanın kaynağını bulabilmek için yeterli bilgi içermelidir. Bunun çözümü IIS üzerinde detaylı hata mesajlarının sadece yerel kullanıcılara gönderilmesi ve basit hata mesajlarının da genel istemcilere gönderilmesi yönünde bir yapılandırma gerçekleştirilmelidir. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Sites > Site Adı > Error Pages 3.11 Talep Filtreleme IIS 7.0 versiyonundan daha önceki sürümlerde UrlScan isimli sonradan eklenen bir uygulama eklentisi ile IIS üzerinde istemcilerden gelen taleplere ait URL kontrolleri gibi bazı güvenlik ilkeleri sıkılaştırması yapılabiliyordu. IIS 7.0 ile birlikte UrlScan isimli güvenlik eklentisinin yerini IIS kurulumu içerisinde bir modül olarak gelen Request Filtering (Talep Filtreleme) aldı. Bazı kıstaslara göre Talep Filtreleme modülü sayesinde filtreleme kuralları yazarak sunucuya yapılacak taleplerin kurallara göre düşürülmesini veya kabul edilmesini sağlanabilir. Talep Filtreme kuralları tüm sunucuya yapılabileceği gibi belirli site veya klasörlere de yapılabilir. Talep filtreleme ile gerçekleştirilen filtrelemelerle hata kodları döndürülebilir, böylece bir saldırının tespit edilebileceği de unutulmamalıdır. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Sites > Site Adı > Request Filtering Filtrelenecek kriterler şu şekildedir: Dosya adı uzantısı: Uygulama sunucuları üzerinde izin verilecek veya onaylanmayacak uzantılara karar vermesine olanak sağlar. allowunlisted özelliği izin verilen veya onaylanmayan tüm dosya uzantılarını kapsar. Çoğu zaman.bat,.config,.exe gibi dosya uzantılarına sunucu üzerinde izin verilmez. Ancak tavsiye edilen durum izin verilecek dosya uzantıların belirlenmesi ve bunların dışında kalan diğer tüm uzantıların yasaklanmasıdır. Böylece uygulamalara ve sunuculara yönelik yapılacak saldırı düzeyi önemli ölçüde azaltılmış olacaktır. İstemci belli uzantıya sahip olan bir dosya talep ettiğinde istemcinin bu talebi reddedilerek 404.7 hatası döndürülebilir. URL talep şifreleme: Saldırgan, erişim hakkı olmayan bir yere çift şifreleme (doubleencoded) ile erişmeye çalışabilir. Bu amaçla, URL içerisine../ yerine %252E%252E%252F yazabilir. Eğer çift şifreli bu talepler filtrelenmiyorsai saldırgan tarafından gerçekleştirilen erişim denemesi başarıya ulaşabilir. Bu saldırıdan korunmak için 26 / 33
IIS üzerinde iki kere normalleştirme gerçekleştirilmesi sağlanarak çıkan sonuçların birbiriyle aynı olduğu kontrol edilmelidir. Bu filtreleme sonucunda birbirinden farklı sonuçlar için 404.11 hata mesajı oluşturulur. Yüksek bitli karakterler: İstemci talebi içerisindeki tüm karakterler ASCII kodu ise talep kontrol edilmelidir. ASCII olmayan karakter bulunması durumunda 404.12 hatası döndürülür. Talep uzunluğu ve cevap boyutu: Talep içerisindeki URL ve sorgu uzunluğu çok fazla ise veya döndürülecek cevap çok büyükse bu talep karşılanmamalıdır. 3.12 HTTP Trace HTTP Trace metodu istemcilerin yaptığı HTTP isteklerinin içeriğini TRACE cevabının içerisinde dönmektedir. Saldırganlar bu özelliği kullanarak HTTP başlıklarında bulunan çerez ve yetkilendirme verileri gibi kritik bilgileri elde edebilmektedir. Bu nedenle TRACE komutunun engellenmesi gerekmektedir. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Sites > Site Adı > Request Filtering > HTTP verbs > Actions > Deny verb: TRACE kaydı girilir. 3.13 URL Rewrite IIS URL Rewrite modülü, kullanıcıların URL leri basitçe hatırlaması veya arama motorlarının düzenli olarak yaptıkları indekslemelerde web sitesinin haritasını daha kolay çıkarabilmesi için geliştirilmiş kural tabanlı bir modüldür. IIS URL Rewrite modülünün düzenli ifadeler ile kural yazma desteği sayesinde oldukça güçlü kurallar geliştirilebilmektedir. Apache sunucularına ait mod_rewrite modülü IIS URL Rewrite modülünden daha önce geliştirilmiş ve kullanılmaya başlanmış olup, mod_rewrite modülü yalnızca PHP ile geliştirilmiş sayfalar için kullanılabiliyordu. Yani ASP.NET ile geliştirilen uygulamalar bu modülden yararlanamıyordu, fakat IIS 7.0 ile birlikte gelen URL Rewrite modülü sayesinde bu sorun çözülmüştür. IIS sunucusu bir talep aldığında Talep Filtreleme ve URL Rewrite modülü arasında karşılıklı etkileşim içerisindedir. Sunucuya bir talep yapıldığında ilk olarak Talep Filtreleme modül devreye girerek talebe ait bazı özellikleri (talep başlığı, sorgu katarı (query string), talep edilen içeriğin uzunluğu, vs.) denetler. Talep Filtreleme modülünde yazılmış olan kurallar ile eşleşen bir talep olursa, modül tarafından 400 ile başlayan hatalar üretilir ve kullanıcıya uygun hata mesajı gönderilir. Eğer bir eşleşme yoksa (yani yapılan talep filtrelenmeyecekse) talep IIS sunucu tarafından URL Rewrite modülüne gönderilir. Bu modül de kendisinde mevcut olan kurallar dahilinde, gelen talebi değerlendirir ve bu talebi yönlendirebilir veya özelleşmiş cevaplar üretip kullanıcıya iletebilir. 27 / 33
IIS mimarisi gereği Talep Filtreleme modülü web sunucuyu zararlı taleplerden korumak için kontrolcü görevindedir. Yani IIS sunucuya gelen bir istek ilk olarak Talep Filtreleme modülüne gönderilir. IIS URL Rewrite modülü ise sunucuya gelmiş ve Talep Filtreleme modülünden geçmiş isteklerin URL temelli manipülasyonu ile ilgilenir. Önerilen kullanım biçimi, Talep Filtreleme modülü kullanarak gerçekleştirilemeyen bir durumda IIS URL Rewrite modülü ile kural yazılır. Geri kalan güvenlik sıkılaştırmaları Talep Filtreleme modülü ile gerçekleştirilir. Genel olarak IIS URL Rewrite modülü; Geliştirilen kurallar sayesinde karmaşık URL taleplerinin daha basit ve kısa bir hale getirilmesi, IIS sunucuya kullanıcılar tarafından yapılan taleplere verilecek URL cevaplarının da aynı şekilde URL Rewrite modülü ile değiştirilmesi, Düzenli ifadeler ile güçlü kural yazılım desteği, Uygulamanın tümünde veya bölgesel kurallar yazabilme, Ters (reverse) proxy kural taslağı barındırma, Yenilenen URL değerlerinin kaydının tutulması, Hem komut satırı hem de grafik arayüzünde kural geliştirilme desteğinin sunulması gibi destekleri barındırır. 3.14 IP Kısıtlama Organizasyon web sitesine sadece belli IP lerin / IP bloklarının veya etki alanlarının; erişmesi / erişmemesi istenebilir. Örneğin finansal bir organizasyona ait bir web sayfası, sadece bankaların bağlanmasına açık olacak şekilde ayarlanabilir. Böylece dosya sisteminde grup veya roller ile NTFS kısıtlamasına yoğunlaşmak yerine IP adresleri veya etki alanı adları kullanılarak kısıtlama uygulanır. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Sites > Site Adı > IP Address and Domain Restrictions > Add Allow/Deny Entry Not: İzin verilen veya izin verilmeyen erişimlerin sırası önemlidir. Listenin en üstteki kural ne ise o uygulanır. Örneğin bir IP önce izinli listesinde daha sonra da engelli listesinde ise bu IP ye izin verilir. 28 / 33
3.15 Bağlantı Sayısı ve Süresini Kısıtlama IIS üzerinde istemciler tarafından yapılan bağlantı sayısı sınırlandırılabilir. Bu sınıra ulaşıldığında web uygulaması gelen talepleri reddedecektir. Böylece ağ kaynaklarının daha uygun olarak kullanılması sağlanacaktır. Bunun yanında bir bağlantının zaman aşımı süresi de IIS üzerinde ayarlanabilir. Belli bir süre boyunca bağlantı devam ediyorsa bu bağlantı koparılabilir. Böylece bağlantı sayısının şişmesinin önüne geçilir. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Sites > Site Adı > (Actions Penceresi) Limits...: Uygun değerleri girilir. 3.16 Dizin Güvenliği IIS sunucuya bir istek yapıldığında Varsayılan Doküman (Default Document) ayarlamasına göre ilgili uzantılı sayfa istemciye cevap olarak gönderilir. IIS 7.0 ile birlikte varsayılan olarak kurulu gelen Default Document modülü sayesinde ApplicationHost.config dosyası içerisinde IIS tarafından bir doküman sıralaması yapılmıştır. Bu sıralama aşağıdaki gibidir: default.htm default.asp index.htm index.html iissstart.htm Bu sıralama haricinde web sunucuya ASP.NET kuruldu ise, listeye ilave olarak kurulum sırasında default.aspx dosyası eklenir. Site veya uygulamanın kök dizinine (root folder) bir talep geldiği zaman varsayılan olarak yukarıdaki sıralamaya göre Varsayılan Doküman araması yapılır. Öncelikle default.htm dosyası kontrol edilir, bu dosya site veya uygulamanın kök dizininde mevcut ise istemciye cevap olarak default.htm gönderilir. Bu dosya yoksa default.asp kontrol edilir ve bu şekilde listenin son sırasındaki dokümana kadar kontrol gerçekleştirilir. Gereksiz varsayılan dokümanlar kaldırılmalıdır. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Sites > Site Adı > Default Document 29 / 33
3.17 Dizin Tarama Varsayılan Doküman aramasında başarı sağlanamaz ve aranan doküman listesinin son sırasında bulunamazsa, IIS üzerinde Dizin Tarama modülü aktif mi değil mi bunun kontrolü yapılır. Dizin Tarama aktif ise kullanıcıya cevap olarak ilgili site veya uygulamaya özgü dosya ve dizin ağaç yapısı döndürülür. Bu modül aktif değilse - varsayılan olarak devre dışı olmalıdır - kullanıcıya HTTP 404 File Does Not Exist hatası döndürülür. Dizin Tarama özellikle gerekmedikçe varsayılan olarak devre dışı bırakılması gereken bir modüldür. Çünkü bu modül aktif olduğunda saldırganlar tarafından sunucudan bilgi almak amacıyla kullanılabilir. Bazen de gizli kalması istenilen bir dizin Dizin Tarama modülünden dolayı gizli kalamayabilir. Bu modüle herhangi bir yerde ihtiyaç yoksa mutlaka kaldırılmalıdır. Kullanılması gereken durumlarda da tüm uygulama çapında kullanmak yerine gerekli olan dizinlerde bölgesel kullanılmalıdır. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: IIS Konsolu > Sunucu Adı > Sites > Site Adı > Directory Browsing 3.18 Deployment Retail Deployment Retail özelliği uygulamaların olabilecek en iyi performansta ve mümkün olan en az güvenlik açıklığı barındıracak şekilde çalışmasına yardım eder. Bu özellik üretim ortamındaki IIS 7 sunucularının kullanımı için hazırlanmıştır. Deployment Retail, uygulamadaki Trace özelliğini kapatmasını, son kullanıcılara detaylı hata mesajı vermemesini ve hata ayıklama (Debug) modunun kapalı olmasını sağlar. Bu özellik ile üretim ortamındaki IIS sunucularında Trace ya da Debug yöntemlerinin açık kalması sonucu oluşabilecek önemli uygulamalar ve sistem hakkında bilgi sızması tehlikelerini en aza indirgemiş olur. Bu sıkılaştırma işlemi şu şekilde gerçekleştirilmektedir: Sunucu 32 bit ise: %windir%\microsoft.net\framework\<framework_version>\config\machine.config dosyasındaki <system.web> altına <deployment retail= true > satırı eklenmelidir. Sunucu 64 bit ise: %windir%\microsoft.net\framework6\<framework_version>\config\machine.config dosyasındaki <system.web> altına <deployment retail= true > satırı eklenmelidir. 3.19 Handler Mappings IIS üzerinde ASP ve ASP.NET için Handler modülünün olması çoğu zaman yeterli olmaz, Handler Mappings modülünün kullanılması da gerekmektedir. Bu Handler modüllerinin dosya uzantıları ile ilişkilendirilmesi gerekir. Yani uzantısı.asp olan dosyalara ASP Handler modülü, uzantılısı.aspx 30 / 33