<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.tr.xsl"?>
<!-- English Revision: 805050 -->
<!-- =====================================================
 Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
   Reviewed by: Orhan Berent <berent belgeler.org>
========================================================== -->

<!--
 Licensed to the Apache Software Foundation (ASF) under one or more
 contributor license agreements.  See the NOTICE file distributed with
 this work for additional information regarding copyright ownership.
 The ASF licenses this file to You under the Apache License, Version 2.0
 (the "License"); you may not use this file except in compliance with
 the License.  You may obtain a copy of the License at

     http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.
-->

<manualpage metafile="security_tips.xml.meta">
  <parentdocument href="./">Çeşitli Belgeler</parentdocument>

  <title>Güvenlik İpuçları</title>

  <summary>
    <p>Bir HTTP Sunucusunu ayarlarken dikkat edilmesi gerekenler ve bazı
    ipuçları.  Öneriler kısmen Apache’ye özel kısmen de genel olacaktır.</p>
  </summary>

  <section id="uptodate"><title>Güncel Tutma</title>

    <p>Apache HTTP Sunucusu iyi bir güvenlik sicilinin yanında güvenlik
      konularıyla oldukça ilgili bir geliştirici topluluğuna sahiptir. Fakat,
      bir yazılımın dağıtılmasının ardından küçük ya da büyük bazı sorunların
      keşfedilmesi kaçınılmazdır. Bu sebeple, yazılım güncellemelerinden
      haberdar olmak oldukça önem kazanır. HTTP sunucunuzu doğrudan
      Apache’den temin ediyorsanız yeni sürümler ve güvenlik güncellemeleri
      ile ilgili bilgileri tam zamanında alabilmek için <a
      href="http://httpd.apache.org/lists.html#http-announce">Apache
      HTTP Sunucusu Duyuru Listesi</a>ne mutlaka üye olmanızı öneririz.
      Apache yazılımının üçüncü parti dağıtımlarını yapanların da buna benzer
      hizmetleri vardır.</p>

    <p>Şüphesiz, bir HTTP sunucusu, sunucu kodunda bir sorun olmasa da
      tehlike altındadır. Eklenti kodları, CGI betikleri hatta işletim
      sisteminden kaynaklanan sorunlar nedeniyle bu ortaya çıkabilir. Bu
      bakımdan, sisteminizdeki tüm yazılımların sorunları ve güncellemeleri
      hakkında bilgi sahibi olmalısınız.</p>

  </section>

  <section id="serverroot">
    <title><code>ServerRoot</code> Dizinlerinin İzinleri</title>

    <p>Normalde, Apache root kullanıcı tarafından başlatılır ve hizmetleri
      sunarken <directive module="mpm_common">User</directive> yönergesi
      tarafından tanımlanan kullanıcının aidiyetinde çalışır. Root tarafından
      çalıştırılan komutlarda olduğu gibi, root olmayan kullanıcıların
      yapacakları değişikliklerden korunmak konusunda da dikkatli
      olmalısınız. Dosyaların sadece root tarafından yazılabilir olmasını
      sağlamak yeterli değildir, bu dizinler ve üst dizinler için de
      yapılmalıdır. Örneğin, sunucu kök dizininin
      <code>/usr/local/apache</code> olmasına karar verdiyseniz, bu dizini
      root olarak şöyle oluşturmanız önerilir:</p>

    <example>
      mkdir /usr/local/apache <br />
      cd /usr/local/apache <br />
      mkdir bin conf logs <br />
      chown 0 . bin conf logs <br />
      chgrp 0 . bin conf logs <br />
      chmod 755 . bin conf logs
    </example>

    <p><code>/</code>, <code>/usr</code>, <code>/usr/local</code>
      dizinlerinde sadece root tarafından değişiklik yapılabileceği kabul
      edilir. <program>httpd</program> çalıştırılabilirini kurarken de benzer
      bir önlemin alındığından emin olmalısınız:</p>

    <example>
      cp httpd /usr/local/apache/bin <br />
      chown 0 /usr/local/apache/bin/httpd <br />
      chgrp 0 /usr/local/apache/bin/httpd <br />
      chmod 511 /usr/local/apache/bin/httpd
    </example>

    <p>Diğer kullanıcıların değişiklik yapabileceği bir dizin olarak bir
      <code>htdocs</code> dizini oluşturabilirsiniz. Bu dizine root
      tarafından çalıştırılabilecek dosyalar konulmamalı ve burada root
      tarafından hiçbir dosya oluşturulmamalıdır.</p>

    <p>Diğer kullanıcılara root tarafından yazılabilen ve çalıştırılabilen
      dosyalarda değişiklik yapma hakkını tanırsanız, onlara root
      kullanıcısını ele geçirilebilme hakkını da tanımış olursunuz. Örneğin,
      biri <program>httpd</program> çalıştırılabilirini zararlı bir programla
      değiştirebilir ve o programı tekrar çalıştırdığınız sırada program
      yapacağını yapmış olur. Günlükleri kaydettiğiniz dizin herkes
      tarafından yazılabilen bir dizin olduğu takdirde, birileri bir günlük
      dosyasını bir sistem dosyasına sembolik bağ haline getirerek root
      kullanıcısının bu dosyaya ilgisiz şeyler yazmasına sebep olabilir.
      Günlüklerin dosyaları herkes tarafından yazılabilir olduğu takdirde ise
      birileri dosyaya yanıltıcı veriler girebilir.</p>
  </section>

  <section id="ssi">
    <title>Sunucu Taraflı İçerik Yerleştirme</title>

    <p>SSI sayfaları bir sunucu yöneticisi açısından çeşitli olası risklere
      kaynaklık edebilir.</p>

    <p>İlk risk, sunucu yükündeki artış olasılığıdır. Tüm SSI sayfaları,  SSI
      kodu içersin içermesin Apache tarafından çözümlenir. Bu küçük bir artış
      gibi görünürse de bir paylaşımlı sunucu ortamında önemli bir yük haline
      gelebilir.</p>

    <p>SSI sayfaları, CGI betikleriyle ilgili riskleri de taşır. <code>exec
      cmd</code> elemanı kullanılarak bir SSI sayfasından herhangi bir CGI
      betiğini veya bir sistem programını Apache’nin aidiyetinde olduğu
      kullanıcının yetkisiyle çalıştırmak mümkündür.</p>

    <p>SSI sayfalarının yararlı özelliklerinden yararlanırken güvenliğini de
      arttırmanın bazı yolları vardır.</p>

    <p>Sunucu yöneticisi, bir başıbozuk SSI sayfasının sebep olabileceği
      zararları bertaraf etmek için <a href="#cgi">CGI Genelinde</a>
      bölümünde açıklandığı gibi <a href="../suexec.html">suexec</a>’i etkin
      kılabilir.</p>

    <p>SSI sayfalarını <code>.html</code> veya <code>.htm</code>
      uzantılarıyla etkinleştirmek tehlikeli olabilir. Bu özellikle
      paylaşımlı ve yüksek trafikli bir sunucu ortamında önemlidir. SSI
      sayfalarını normal sayfalardan farklı olarak <code>.shtml</code> gibi
      bildik bir uzantıyla etkinleştirmek gerekir. Bu, sunucu yükünü asgari
      düzeyde tutmaya ve risk yönetimini kolaylaştırmaya yarar.</p>

    <p>Diğer bir çözüm de SSI sayfalarından betik ve program çalıştırmayı
      iptal etmektir. Bu, <directive module="core">Options</directive>
      yönergesine değer olarak <code>Includes</code> yerine
      <code>IncludesNOEXEC</code> vererek sağlanır. Ancak, eğer betiklerin
      bulunduğu dizinde <directive module="mod_alias">ScriptAlias</directive>
      yönergesiyle CGI betiklerinin çalışması mümkün kılınmışsa,
      kullanıcıların <code>&lt;--#include virtual="..." --&gt;</code> ile bu
      betikleri  çalıştırabileceklerine dikkat ediniz.</p>

  </section>

  <section id="cgi">
    <title>CGI Genelinde</title>

    <p>Herşeyden önce ya CGI betiğini/programını yazanlara ya da kendinizin
      CGI'deki güvenlik açıklarını (ister kasıtlı olsun ister tesadüfi)
      yakalama becerinize güvenmek zorundasınız. CGI betikleri esasen
      sisteminizdeki komutları site kullanıcılarının izinleriyle
      çalıştırırlar. Bu bakımdan dikkatle denenmedikleri takdirde oldukça
      tehlikeli olabilirler.</p>

    <p>CGI betiklerinin hepsi aynı kullanıcının aidiyetinde çalışırsa diğer
      betiklerle aralarında çelişkilerin ortaya çıkması ister istemez
      kaçınılmazdır. Örneğin A kullanıcısının B kullanıcısına garezi varsa
      bir betik yazıp B’nin CGI veritabanını silebilir. Bu gibi durumların
      ortaya çıkmaması için betiklerin farklı kullanıcıların aidiyetlerinde
      çalışmasını sağlayan ve 1.2 sürümünden beri Apache ile dağıtılan <a
      href="../suexec.html">suEXEC</a> diye bir program vardır. Başka bir yol
      da <a href="http://cgiwrap.sourceforge.net/">CGIWrap</a> kullanmaktır.</p>

  </section>

  <section id="nsaliasedcgi">
    <title><code>ScriptAlias</code>’sız CGI</title>

    <p>Kullanıcıların sitenin her yerinde CGI betiklerini çalıştırmalarına
      izin vermek ancak şu koşullarda mümkün olabilir:</p>

    <ul>
      <li>Kullanıcılarınızın kasıtlı ya da kasıtsız sistemi saldırıya açık
        hale getirecek betikler yazmayacaklarına tam güveniniz vardır.</li>
      <li>Sitenizin güvenliği zaten o kadar kötüdür ki, bir delik daha
        açılmasının mahzuru yoktur.</li>
      <li>Sitenizin sizden başka kullanıcısı yoktur ve sunucunuzu sizden
        başka hiç kimsenin ziyaret etmesi mümkün değildir.</li>
    </ul>

  </section>

  <section id="saliasedcgi">
    <title><code>ScriptAlias</code>’lı CGI</title>

    <p>CGI’yi belli dizinlerle sınırlamak yöneticiye bu dizinlerde daha iyi
      denetim imkanı sağlar. Bu kaçınılmaz olarak <directive
      module="mod_alias">ScriptAlias</directive>’sız CGI’den çok daha
      güvenlidir, ancak bu dizinlere yazma hakkı olan kullanıcılarınız
      güvenilir kişiler olması ve site yöneticisinin de olası güvenlik
      açıklarına karşı CGI betiklerini ve programlarını denemeye istekli
      olması şartıyla.</p>

    <p>Çoğu site yöneticisi <code>ScriptAlias</code>’sız CGI yerine bu
      yaklaşımı seçer.</p>

  </section>

  <section id="dynamic">
    <title>Devingen içerikli kaynaklar</title>

    <p>Sunucunun bir parçası gibi çalışan, <code>mod_php</code>,
      <code>mod_perl</code>, <code>mod_tcl</code> ve <code>mod_python</code>
      gibi gömülü betik çalıştırma seçenekleri sunucuyu çalıştıran
      kullanıcının aidiyetinde çalışırlar (<directive module="mpm_common"
      >User</directive> yönergesine bakınız). Bu bakımdan bu betik
      yorumlayıcılar tarafından çalıştırılan betikler, sunucu kullanıcısının
      eriştiği herşeye erişebilirler. Bazı betik yorumlayıcıların getirdiği
      bazı sınırlamalar varsa da bunlara pek güvenmemek, gerekli sınamaları
      yine de yapmak gerekir.</p>

  </section>

  <section id="systemsettings">
    <title>Sistem Ayarlarının Korunması</title>

    <p>Güvenliği gerçekten sıkı tutmak istiyorsanız, kullanıcılarınızın
      yapılandırmanızdaki güvenlik ayarlarını geçersiz kılmak için
      <code>.htaccess</code> dosyalarını kullanabilmelerinin de önüne
      geçmelisiniz. Bunu yapmanın tek bir yolu vardır.</p>

    <p>Sunucu yapılandırma dosyanıza şunu yerleştirin:</p>

    <example>
      &lt;Directory /&gt;
      <indent>
        AllowOverride None
      </indent>
      &lt;/Directory&gt;
    </example>

    <p>Böylece, belli dizinlerde özellikle etkinleştirilmedikçe bütün
      dizinlerde <code>.htaccess</code> dosyalarının kullanımını engellemiş
      olursunuz.</p>

  </section>

  <section id="protectserverfiles">
    <title>Sunucu dosyalarının öntanımlı olarak korunması</title>

    <p>Apache’nin ister istemez yanlış anlaşılan yönlerinden biri öntanımlı erişim özelliğidir. Yani siz aksine bir şeyler yapmadıkça, sunucu normal URL eşleme kurallarını kullanarak bir dosyayı bulabildiği sürece onu istemciye sunacaktır.</p>

    <p>Örneğin, aşağıdaki durumu ele alalım:</p>

    <example>
      # cd /; ln -s / public_html
    </example>

    <p>Ve, tarayıcınıza <code>http://localhost/~root/</code> yazın.</p>

    <p>Böylece, istemcilerin tüm dosya sisteminizi gezmelerine izin vermiş olursunuz. Bu işlemin sonuçlarının önünü almak için sunucu yapılandırma dosyanıza şunları yazın:</p>

    <example>
      &lt;Directory /&gt;
      <indent>
        Order Deny,Allow <br />
        Deny from all
      </indent>
      &lt;/Directory&gt;
    </example>

    <p>Bu suretle, dosya sisteminize öntanımlı erişimi yasaklamış olursunuz. Erişime izin vermek istediğiniz dizinler için uygun <directive module="core">Directory</directive> bölümleri eklemeniz yeterli olacaktır. Örnek:</p>

    <example>
      &lt;Directory /usr/users/*/public_html&gt;
      <indent>
        Order Deny,Allow <br />
        Allow from all
      </indent>
      &lt;/Directory&gt; <br />
      &lt;Directory /usr/local/httpd&gt;
      <indent>
        Order Deny,Allow <br />
        Allow from all
      </indent>
      &lt;/Directory&gt;
    </example>

    <p><directive module="core">Location</directive> ve <directive
    module="core">Directory</directive> yönergelerinin etkileşimine de özellikle önem vermelisiniz; örneğin <code>&lt;Directory /&gt;</code> erişimi yasaklarken bir <code>&lt;Location /&gt;</code> yönergesi bunu ortadan kaldırabilir.</p>

    <p><directive module="mod_userdir">UserDir</directive> yönergesi de size buna benzer bir oyun oynayabilir; yönergeye <code>./</code> atamasını yaparsanız, root kullanıcısı söz konusu olduğunda yukarıda ilk örnekteki durumla karşılaşırız. Apache 1.3 veya üstünü kullanıyorsanız, sunucu yapılandırma dosyanızda aşağıdaki satırın mutlaka bulunmasını öneririz:</p>

    <example>
      UserDir disabled root
    </example>

  </section>

  <section id="watchyourlogs">
    <title>Günlüklerin İzlenmesi</title>

    <p>Sunucunuzda olup biteni günü gününe bilmek istiyorsanız <a href="../logs.html">günlük dosyalarına</a> bakmalısınız. Günlük dosyaları sadece olup biteni raporlamakla kalmaz, sunucunuza ne tür saldırılar yapıldığını ve güvenlik seviyenizin yeterli olup olmadığını anlamanızı da sağlarlar.</p>

    <p>Bazı örnekler:</p>

    <example>
      grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log <br />
      grep "client denied" error_log | tail -n 10
    </example>

    <p>İlk örnek, <a href="http://online.securityfocus.com/bid/4876/info/">Apache Tomcat
    Source.JSP Bozuk İstek Bilgilerini İfşa Açığı</a>nı istismar etmeyi deneyen saldırıların sayısını verirken ikinci örnek, reddedilen son on istemciyi listeler; örnek:</p>

    <example>
      [Thu Jul 11 17:18:39 2002] [error] [client falan.filan.dom] client denied
      by server configuration: /usr/local/apache/htdocs/.htpasswd
    </example>

    <p>Gördüğünüz gibi günlük dosyaları sadece ne olup bittiğini raporlar, bu bakımdan eğer istemci <code>.htpasswd</code> dosyasına erişebiliyorsa <a href="../logs.html#accesslog">erişim günlüğünüzde</a> şuna benzer bir kayıt görürsünüz:</p>

    <example>
      falan.filan.dom - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
    </example>

    <p>Bu, sunucu yapılandırma dosyanızda aşağıdaki yapılandırmayı iptal ettiğiniz anlamına gelir:</p>

    <example>
      &lt;Files ~ "^\.ht"&gt;
      <indent>
        Order allow,deny <br />
        Deny from all
      </indent>
      &lt;/Files&gt;
    </example>

  </section>

</manualpage>
