spacer.png, 0 kB
Bilgi için: bilgi at bilgiguvenligi gov tr   

 

spacer.png, 0 kB
spacer.png, 0 kB
Apache Güvenlik Yapılandırması -2 Yazdır E-posta
Oğuzhan Topgül, TÜBİTAK-UEKAE   
28.08.2010

Bir önceki yazımızda Apache güvenlik yapılandırmalarının bir kısmına yer vermiştik. Bu ikinci yazıda Apache’nin en zayıf kaldığı nıoktalardan biri olan hizmet dışı bırakma (Denial of Service) saldırılarına karşı önlemler, chroot kullanımı, ModSecurity  gibi çok önemli güvenlik adımlarından bahsedeceğiz.

Gereksiz Modüllerin Kapatılması

1.jpgBütünsel güvenliğin sağlanmasında saldırılacak yüzeyin daraltılması büyük önem arz etmektedir. Dolayısıyla kullanılmayan, gereksiz Apache modüllerinin kapatılması güvenlik açısından önemlidir. Öntanımlı ayarları ile çalışan (yeterli güvenlik sıkılaştırması yapılmamış) ve kullanılmayan, gereksiz bir modül sisteme giriş için zayıf bir nokta oluşturabileceğinden güvenlik açısından tehdit olarak görülebilir.

Modüllerin yüklenmesi httpd.conf dosyasından yapılabileceği gibi Apache ile bütünleşik (built-in) derlenmesi ile de yapılabilir. Eğer modül olarak kullanılıyor ise Apache modüllerinin aktivasyon ve deaktivasyon işlemleri komut satırından

a2enmod (modül adı)

ve

a2dismod (modül adı)

komutları ile yapılabilir. Derleme sırasında kurulan apache modüllerinin deaktive edilmesi için Apache’nin tekrar  derlenmesi gerekmektedir. Derleme sırasında kurulan Apache modüllerinin listesini görmek için komut satırında, ilgili işletim sistemi ya da dağıtımın  Apache paketlemesine bağlı olarak

apache2 -l

veya

httpd -l

komutları kullanılabilir.

Yapılandırma Dosyalarına root İle Erişim

Yetkilendirme konusunda alınacak bir diğer güvenlik önlemi de Apache yapılandırma dosyalarına sadece root kullanıcısıyla erişimin sağlanmasıdır. Yapılandırma dosyalarının diğer kullanıcılar tarafından görülememesi (read), değiştirilememesi (write) ve çalıştırılamaması (execute) gerekmektedir. Bunun için Apache’nin kurulu olduğu klasör için (örnek olarak /apache olduğu varsayılmıştır) komut satırından

chown -R root:root /apache

chmod -R o-rwx /apache

komutlarının çalıştırılıp yetkilerin düzenlenmesi gerekmektedir. chown komutu linux komut satırında uygulama ve klasörün sahibini yani onu çalıştırabilecek veya onu görebilecek kullanıcıyı  ve grubunu değiştirmeye yarar. chmod ise klasör veya dosyanın üzerindeki kullanıcı haklarını ve yetkilerini (okuma-yazma-çalıştırma) değiştirmeye yarar.

Options Direktifi

Options direktifi  <Directory>  içerisine yazılan ve farklı seçenekleri açıp kapatmaya yarayan bir direktiftir. Bir klasör içerisinde hangi özelliklerin aktif olduğunu ayarlamaya yarar. Bu seçeneklerden bazıları güvenlik konusunda bazı zayıflıklara sebep olabilmektedir.  Bunun için en temel olarak bütün seçenekleri dekative etme işlemi, genel yapılandırma dosyasına

<Directory />

        Options None

</Directory>

satırları yazılarak gerçekleştirilebilir. Bunun yanı sıra sadece bazı seçenekleri kapatmak için

<Directory />

        Options –<seçenek adı>

</Directory>

şablonu kullanılabilir.[1]

ModSecurity Kullanımı

ModSecurity, açık kaynak kodlu, web  uygulama güvenlik duvarı gibi davranan bir apache modülüdür. ModSecurity ile basit filtreleme, düzenli İfade (Regular Expression) temelli filtreleme, URL kodlama (Encoding) doğrulaması, unicode kodlama doğrulaması, “null bayt” saldırı koruması, sunucu kimliği maskeleme, chroot desteği ve daha fazla birçok özellik kullanılabilir. Ayrıca ModSecurity ters vekil (reverse proxy) olarak da kullanılarak ağın detayları ve yapısının dış dünyadan saklanması sağlanabilir.[2]

TRACE Metodunun Kapatılması

HTTP TRACE metodu kötü amaçlı olarak kullanıcı çerezlerinin ve kimlik bilgilerinin alınması için kullanılabilir. Çerez (cookie) bilgilerinin elde edilmesi için genellikle uygulanan yöntem XSS atakları ile çerez bilgisinin çalınmasıdır. cookie başlığının HTTPOnly parametresi document.cookie (cookie bilgisinin oldugu yer) objesine  scripting dilleri ile erişilmesini engelleyen bir parametredir. Ancak TRACE metodu ile HTTPOnly parametresinin sağladığı güvenlik çemberi aşılabilir ve kullanıcının çerez ve kimlik bilgilerine ulaşılabilir (Bu saldırı türüne XST-Cross Site Tracing denir). Daha önce çerez almış ve kimlik doğrulama (authentication) yapmış bir kullanıcının TRACE  ile isetek göndermesi sonucunda HTTP cevabında çerez ve kimlik bilgileri görünmektedir, böylece HTTPOnly atlatılmış olunur. Dolayısıyla TRACE metodu, sunuculardan konfigure edilip kullanıma kapatılmalı ya da bu metodun kullanımı kısıtlanmalıdır.
Apache web sunucusunda TRACE metodunun kısıtlanması için yapılandırma dosyasına

 TraceEnable off

yazılması yeterlidir. [3]

Özel Hazırlanmış Hata Sayfaları

Öntanımlı HTTP 4xx ve 5xx hata mesajları içerisinde minimum bilgi prensibine aykırı bilgiler bulunmaktadır. Bu bilgiler sistemin işleyişi ve yapısı hakkında saldırganlara yarar sağlayabilmekte ve saldırıyı kolaylaştırmaktadır. Sunucunun kendi hata mesajları yerine isteğe göre hazırlanmış hata sayfalarının gösterilmesi tercih edilmelidir. Hata sayfası olarak özel olarak hazırlanmış hata sayfalarının gösterilmesi için Apache yapılandırma dosyası (httpd.conf veya apache2.conf) içerisinde

ErrorDocument [Hata Kodu] /hata/sayfasının/yolu.html 

şablonuna uygun bir düzenleme yapılmalıdır. [4] Hata sayfasının yolu yerine “Default” yazılması durumunda Apache’nin kendi hata sayfalarının gösterilmesi sağlanabilir. Ayrıca <Directive> içerisine yazılan ErrorDocument parametreleri ile farklı URL’ler için farklı hata sayfalarının gösterilmesi sağlanabilir.

Chroot

Chroot sunucular için standart işletim sistemi kök dizininden bağımsız bir kök dizin tanımlamaya olanak sağlayan bir servistir. Yapılandırma dosyaları, uygulama dosyaları, sürücü dosyaları ve gerekli kütüphanelerin bu dizin altına kopyalanması ile uygulama işletim sistemi kök dizininde değil chroot kök dizini altından hapsedilerek çalıştırılır.[5] Apache’nin chroot altında çalışmasının sağlanması herhangi bir sızma ve açıklığın sömürülmesi durumunda saldırganın chroot kök dizini altına hapsolması, diğer dizinlere erişememesi anlamına gelmektedir ve bu yüzden çok önemlidir. Chroot hakkında  ayrıntılı bilgi ve chroot açık kaynak kodlu yazılımları için (Apache, MySQL, PHP) hem  güvenli kurulum adımlarını gerçekleştiren,erişim izinlerini güvenli bir biçimde yapılandıran hem de sunucu servisleri için gerekli başlatma ve durdurma betiklerini barından CAMMP[6] uygulamasını hakkında ayırntılı bilgi için referanslardaki bağlantılar takip edilebilir.

Hizmet Dışı Kalmamak

Hizmet dışı bırakma saldırıları basit olarak sunucuların kullanıcıları hizmet veremeyecek kadar yoğun veya işlemez hale getirilmesi olarak tanımlanabilir. Bu saldırıyı OSI katmanlarından taşıma (Transport Layer) katmanında yapabilmek mümkün olduğu gibi, Uygulama (Application Layer) katmanında da yapabilemk mükündür. Dolayısıyla hizmet dışı bırakma saldırılarından korunmak için tek ve mükemmel bir çözümden bahsetmek güçtür. Çünkü bu saldırılar genellikle sunucuların standart çalışma prensipleri kullanılarak yapılmaktadır. Ancak Apache güvenlik yapılandırmalarının bu saldırılılar göz önünde bulundurularak yapılması durumunda birçok saldırı başarısız olacaktır.

  • Timeout direktifinin değerinin düşürmek: Timeout sunucunun zaman aşımı süresini belirler ve öntanımlı olarak 300 saniyedir. Bu değerin düşürülmesi hizmet dışı saldırılarına karşı alınacak önlemlerden biridir. Ancak bu sürenin çok düşük değerlere çekilmesi de sunucunun verimli ve doğru çalışmasını engelleyebilir. Yapılandırma dosyasında birimi saniye olacak şekilde aşağıdaki satırın yazılması yeterlidir.[7]

Timeout SÜRE

  • KeepAliveTimeout direktifinin değerini düşürmek: KeepAliveTimeout direktifi yeni bir bağlantı açmadan önce kalıcı bağlantının ne kadar süre ile bekletileceğini belirleyen direktiftir. Bu değerin yüksek olması durumu hizmet dışı bırakma saldırılarını yapanlarca en çok sömürülen durumdur. Çok sayıda ve uzun süre aktivite beklenen talepler sebebiyle sunucu yeni taleplere hizmet veremez hale gelebilmektedir. Bu direktifin değerinin çok düşük seviyelere çekilmesi (veya KeepAlive direktifinin tamamen kapatılması) durumunda ise suınucuda performans problemleri ortaya çıkmaktadır. Çünkü KeepAlive direktifi aynı TCP bağlantısı üzerinden birden fazla istek yapılmasına olanak verdiği için bazı durumlarda ciddi performans artışı sağlayabilmektedir. Bu yüzden KeepAliveTimeout değeri ayarlanırken performans konusu da göz önünde bulundurulmalı, saniye zaman birimi kullanılacak şekilde, sistemin ihtiyaçlarına uygun bir değer tercih edilmelidir. (Öntanımlı olarak 15 değerini almaktadır)

KeepAliveTimeout SÜRE

Veya

KeepAlive on/off

  • MaxClients direktifinin değerini seçmek: Öntanımlı olarak 150 adet eşzamanlı bağlantı değerini alan MaxClients direktifi, eşzamanlı olarak bağlanabilecek maksimum istemci sayısını belirtir. Bu değerin çok düşük seviyelere çekilmesi de sistemin hizmet verebilmesini negatif yönde etkiler. Bu yüzden bu değer de seçilirken dikkatli olunmalıdır.

MaxClients SAYI

  • LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine, and LimitXMLRequestBody direktifleri dikkatli bir şekilde sistem gereksimleri ve performans da göz önünde bulundurularak ayarlanmalıdır. Bu direktiler istemci tarafından yapılan talep  bölümlerinin boyutlarının sınırlandırılmasını sağlar.  Bu direktifler sayesinde sistem yöneticisi anormal talepler üzerinde gayet büyük bir kontrol  sahibi olur. Örneğin sunucuya yüklenebilecek dosyanın en büyük boyutunu LimitRequestBody direktifi ile ayarlayabiliriz. [8]

  • Mod_evasive[9], SYN-Cookie[10], SYN-Cache[11], SYN-Proxy[12] gibi modüller ve yazılımlar kullanmak güvenlik konusunda yardımcı olacaktır.

Hizmet dışı bırakma saldırılarına karşı yukarıda yer alan hiçbir madde tek başına yeterli değildir. Daha önce de söylediğimiz gibi hizmet dışı bırakma saldırıları sunucuların çalışma mantıkları sömürülererk yapıldığından bu tarz saldırılar için alınan önlemler bir yandan performans ve işleyiş üzerinde negatif bir etki oluşturabilmektedir. Hizmet dışı bırakma  açıklıklarını test edebileceğiniz uygulamalar ve   betikler bulunmaktadır.

Sonuç

Bu yazımızda Apache sunucusu için temel güvenlik yapılandırma adımlarını incelemeye çalıştık.  Bu adımların bir çoğu sistemin işleyişine ve yapısına göre sunucudan sunucuya farklılık gösterebilmekte ve sistem yöneticilerinin tercihleri doğrultusunda düzenlenebilmektedir. Dolayısıyla Apache sunucu güvenliği denince tek bir optimum çözümden bahsetmek güçtür. Her sistem kendi gereklilikleri ölçüsünde yapılandırmalarla sıkılaştırılmalıdır.

Referanslar

[1]    http://httpd.apache.org/docs/2.2/en/mod/core.html#options

[2]    http://www.modsecurity.org/

[3]    http://httpd.apache.org/docs/2.2/en/mod/core.html#traceenable

[4]    http://httpd.apache.org/docs/2.2/en/mod/core.html#errordocument

[5]    http://www.bilgiguvenligi.gov.tr/teknik-yazilar-kategorisi/chroot-nedir.html

[6]    http://www.bilgiguvenligi.gov.tr/teknik-yazilar-kategorisi/uygulamalarinizi-cammp-ile-hapsedin.html

[7]    http://httpd.apache.org/docs/trunk/mod/core.html#timeout

[8]    http://httpd.apache.org/docs/trunk/en/mod/core.html#limitrequestbody

[9]    http://www.zdziarski.com/blog/?page_id=442

[10]    http://cr.yp.to/syncookies.html

[11]    http://www.usenix.org/events/bsdcon/full_papers/lemon/lemon_html/node7.html

[12]    http://lists.netfilter.org/pipermail/netfilter-devel/2001-September/005542.html

[13]    http://www.bga.com.tr/calismalar/synflood.pdf


Favori olarak ekle (1) | Görüntüleme sayısı: 1374

Bu yazıya ilk yorumu yazın

Sadece kayıtlı kullanıcılar yorum yazabilir.
Lütfen sisteme giriş yapın veya kayıt olun.

 
spacer.png, 0 kB
spacer.png, 0 kB
Copyright 2012 TÜBİTAK-BİLGEM. Sitenin teknik altyapısında Joomla kullanılmıştır. Yazar ve site referans gösterilmeden alıntı yapılamaz. Görüşleriniz
spacer.png, 0 kB