Çoğu kişi güvenliği bir eklenti sanır: güvenlik duvarı aç, bir tarama kur, iki yerde doğrulama iste, iş tamam. Oysa e-pin satan bir panelde saldırganın yaptığı iş neredeyse hiç karmaşık değildir; kimse şifreni kırmaya uğraşmaz, çünkü gerekmez. Yapılandırma dosyanı okuyabildiği ya da yükleme klasörüne çalıştırılabilir bir dosya bırakabildiği anda zaten içeridedir. Bu iki kapının da anahtarı tek bir şeydir: dosya izinleri ve dizin yerleşimi.
Acele kurulumlarda en sık duyulan cümle şudur: "çalışmadı, 777 verdim düzeldi." O an gerçekten düzelir. Aynı anda, panelin kaynak kodunu, ödeme sağlayıcı anahtarlarını ve stoktaki tüm kodları erişebilen herkese yazılabilir hale getirmiş olursun. Bu yazı, bir e-pin scripti kurulumunda dosya izinlerini ve yerleşimi, her kararın neyi engellediğini açıklayarak sıralıyor; ezberlenecek sayı listesi değil, mantığı veriyor.
777 tam olarak neyi açıyor, neden hiç gerekmiyor?
İzin sayıları üç izleyiciye hitap eder: dosyanın sahibi, grubu ve geri kalan herkes. 777 vermek, bu üç grubun hepsine okuma, yazma ve çalıştırma hakkı tanımaktır. Paylaşımlı bir barındırma ortamında "herkes" kelimesi sadece sen değilsin; aynı sunucudaki diğer hesaplar, sunucuda çalışan her süreç ve sunucuya bir şekilde komut çalıştırabilen herkes o kapsama girer. Yani 777 verilmiş bir yapılandırma dosyası, veritabanı şifrenin ortak bir panoya asılmasıdır.
Asıl mesele şu: neredeyse hiçbir durum gerçekten 777 gerektirmez. "Yazma izni yok" hatası aldığında doğru çözüm izni açmak değil, dosyanın sahipliğini web sunucusunun çalıştığı kullanıcıya vermektir. Sahiplik doğruysa dizinler 755, dosyalar 644 ile sorunsuz çalışır. Yazılabilir olması gereken az sayıda klasörde ise 775 fazlasıyla yeterlidir. Bir e-pin satış yazılımı kurulumunda 777 gören her satır, çözülmemiş bir sahiplik sorununun üzerini örtüyor demektir.
| Yol / tür | Önerilen izin | Neden | Yanlış izinde ne olur |
|---|---|---|---|
| Tüm dizinler (genel) | 755 | Sahip yazar, diğerleri sadece listeler | 777'de dış süreçler dosya bırakabilir |
| Tüm dosyalar (genel) | 644 | Sahip düzenler, sunucu okur | 666'da kod içeriği değiştirilebilir |
| Yapılandırma dosyası | 600 veya 640, webroot dışı | Sadece sahip okur | 644 + webroot içi = sır sızıntısı |
| Yükleme / medya klasörü | 755 + PHP çalıştırma kapalı | Dosya saklanır, çalıştırılmaz | Yüklenen betik uzaktan çalışır |
| Önbellek / günlük klasörü | 775, webroot dışı tercih | Yazma gerekir, okuma gerekmez | Günlükler dışarıdan okunur |
| Yedek arşivleri | 600, webroot dışı | İndirilemez olmalı | Tüm veritabanı tek tıkla iner |
| Kurulum sihirbazı dosyası | Kurulumdan sonra silinir | Tekrar çalıştırılmamalı | Panel sıfırlanıp devralınır |
Yerleşimin altın kuralı: ne web kökünde durmalı?
Web kökü, internetin doğrudan adresleyebildiği alandır. Oraya koyduğun her dosya, adresi tahmin edilebildiği ölçüde herkese açıktır. O halde kural sadeleşir: web kökünde yalnızca tarayıcının gerçekten istemesi gereken şeyler bulunmalı; giriş noktası, temaya ait stil ve betik dosyaları, görseller. Kaynak kodun tamamı, kütüphaneler, yapılandırma, günlükler, yedekler ve tedarikçi anahtarları web kökünün bir seviye üstünde durmalıdır.
Bu yerleşimi baştan kurmak, sonradan taşımaktan çok daha kolaydır; çünkü uygulama içindeki yolların tek merkezde tanımlanması gerekir. İyi yazılmış bir dijital ürün satış scripti zaten bu ayrımı destekler ve kurulum sırasında sana "yapılandırmayı nereye koyayım" diye sorar. Desteklemeyen bir kurulumda ise yapabileceğin en iyi şey, hassas dosyaları erişim kurallarıyla kapatmak ve en azından anahtarları ortam değişkenine taşımaktır.
Yükleme klasörü neden en tehlikeli nokta?
Çünkü orası tasarım gereği dışarıdan dosya kabul eder. Panelinde bayi belgesi, ürün görseli veya toplu kod listesi yüklemesi varsa, saldırganın aradığı kapı zaten açık; tek ihtiyacı, yüklediği dosyanın sunucuda çalıştırılabilmesi. Uzantı kontrolü yapmak tek başına yetmez, çünkü dosya adı hileleriyle atlatılabilir. Gerçek çözüm iki katmanlıdır: yükleme klasöründe betik çalıştırmayı sunucu düzeyinde tamamen kapatmak ve yüklenen dosyaları rastgele üretilmiş adlarla saklamak.
Üçüncü bir katman daha var ve çoğu kurulumda eksiktir: yükleme klasörünü web kökünün dışına almak, dosyaları da uygulamanın kontrol ettiği bir aracı üzerinden sunmak. Böylece dosyaya erişim yetkisi de denetlenebilir hale gelir; bayi belgesini sadece yetkili yönetici görür, adresi paylaşan kişi bile açamaz. Toplu kod listesi yüklenen bir panelde bu ayrımın yokluğu, tek bir adres sızıntısında tüm stoğun dışarı çıkması demektir.
Panel ele geçirme olaylarının başlangıç noktası
- Aşırı geniş izin ve yanlış sahiplik 50%
- Yükleme klasöründe çalıştırılabilir dosya 25%
- Web kökünde duran yedek ve yapılandırma 15%
- Silinmemiş kurulum ve test dosyaları 10%
Yedek dosyaları güvenlik açığına nasıl dönüşüyor?
Çok basit bir alışkanlıkla: paneli güncellemeden önce eski halini yedeklemek ve o arşivi bulunduğu yerde bırakmak. Web kökünde duran bir arşiv dosyası, adı tahmin edilebilir olduğu sürece indirilebilir. İçinde ne var? Yapılandırma dosyan, veritabanı dökümü, tedarikçi anahtarların ve muhtemelen müşteri verisi. Bu, yüksek duvarlı bir binanın anahtarını kapı önündeki paspasın altına koymaktır; duvarın yüksekliği artık konu değildir.
Aynı kategoriye giren diğer kalemler: düzenleyicinin bıraktığı yedek uzantılı dosyalar, elle kopyalanmış eski yapılandırma kopyaları, sürüm kontrol dizinleri ve "deneme" adıyla bırakılmış test betikleri. Kurulum sonrası yapılacak en verimli iş, web kökünü listeleyip orada tarayıcının işine yaramayan her şeyi taşımak ya da silmektir. Bu on dakikalık temizlik, çoğu güvenlik eklentisinden daha fazla risk kapatır.
Kurulum sihirbazı erişilebilir kaldığı sürece, onu bulan kişi panelini kendi adına yeniden kurabilir. Kurulum biter bitmez o dosyayı sil; taşımak veya adını değiştirmek yeterli bir önlem değildir.
İzinleri sertleştirdikten sonra panel bozulursa ne yapmalı?
Sertleştirmenin doğal sonucu, bazı işlevlerin "yazma izni yok" diye şikâyet etmesidir. Buradaki doğru refleks, geriye dönüp izni açmak değil, hangi yolun yazma gerektirdiğini tam olarak tespit etmektir. Genellikle listede üç öğe bulunur: önbellek, günlük ve yüklemeler. Bu üçü dışında yazma isteyen bir bileşen varsa bu, yazılımın kendi dosyalarını çalışma anında değiştirmeye çalıştığı anlamına gelir ve sorgulamayı hak eder.
Doğru süreç şöyledir: izinleri sıkı kur, paneli baştan sona bir kez kullan (ürün ekle, sipariş geç, kod yükle, rapor al), hata veren yolları not et, yalnızca o yollara gereken en düşük izni ver. Bu yöntem, panel her güncellemede yeniden gevşemeden sürdürülebilir bir güvenlik seviyesi yakalamanı sağlar. Özellikler sayfasında dosya yerleşimi ve izin gereksinimlerini açıkça yazan bir yazılım, bu süreci senin için zaten yarı yarıya kısaltmış olur.
Kurulum sonrası hangi listeyi baştan sona kapatmalısın?
Aşağıdaki tablo, paneli canlıya almadan önce tek tek kapatılması gereken sertleştirme maddelerini içeriyor. Hepsi ücretsiz, hepsi bir kereliktir ve toplamda yarım saat sürer. Buna karşılık kapattığı risklerin her biri, gerçekleştiğinde işletmeyi günlerce durduran türdendir.
| Sertleştirme adımı | Nasıl doğrularsın | Kapattığı risk | Durum |
|---|---|---|---|
| 777 izinlerini temizle | Geniş izinli dosya/dizin taraması | Kod değiştirme, arka kapı | Zorunlu |
| Sahipliği web kullanıcısına ver | Sahiplik listesi kontrolü | Gereksiz izin gevşetme ihtiyacı | Zorunlu |
| Yapılandırmayı webroot dışına al | Tarayıcıdan dosya adresini çağır | Veritabanı ve anahtar sızıntısı | Zorunlu |
| Yükleme klasöründe betik çalıştırmayı kapat | Test dosyasını çağır, çalışmasın | Uzaktan kod çalıştırma | Zorunlu |
| Kurulum dosyasını sil | Kurulum adresini tarayıcıda dene | Panelin yeniden kurulması | Zorunlu |
| Yedekleri webroot dışına taşı | Arşiv adresini tarayıcıda dene | Tüm verinin indirilmesi | Zorunlu |
| Dizin listelemeyi kapat | Boş bir klasör adresini aç | Dosya keşfi | Zorunlu |
| Yönetim yolunu gizle + IP kısıtla | Farklı ağdan giriş dene | Deneme yanılma saldırıları | Önerilir |
Sertleştirilmiş yerleşimle başla
Yapılandırması webroot dışında, yükleme klasörü kapalı ve izin gereksinimleri belgelenmiş bir kurulum düzeniyle yola çık.
Bazı klasörler için 777 gerçekten gerekli olmuyor mu?
Hayır. Yazma ihtiyacı olan klasörlerde sahipliği web sunucusu kullanıcısına vermek ve 775 uygulamak yeterlidir. 777 gören her yer, çözülmemiş bir sahiplik sorununun üzerini örten geçici bir yamadır.
Paylaşımlı hostingte yapılandırmayı web kökü dışına alabilir miyim?
Çoğu paylaşımlı pakette hesabın ana dizini web kökünün bir üstündedir ve oraya dosya koyabilirsin. Mümkün değilse anahtarları ortam değişkenine taşı ve dosyaya sunucu düzeyinde erişim engeli koy.
Yükleme klasörünü nasıl güvenli hale getiririm?
Üç adım: sunucu düzeyinde betik çalıştırmayı kapat, dosyaları rastgele adlarla sakla, mümkünse klasörü web kökü dışına alıp erişimi uygulama üzerinden yetki kontrolüyle ver.
İzinleri sıkılaştırınca panel hata verirse ne yapmalıyım?
İzni geri gevşetmek yerine hangi yolun yazma istediğini tespit et. Normalde bu liste önbellek, günlük ve yüklemelerden ibarettir; başka bir yol yazma istiyorsa sebebini sorgulamak gerekir.
Dosya izinleri ve yerleşim, güvenliğin en sıkıcı ama en yüksek getirili kısmıdır; çünkü saldırganın kullandığı kapıların çoğunu tek seferde kapatır ve sonra yıllarca bakım istemez. Sertleştirilmiş bir yerleşimin panel arayüzünde hiçbir kolaylığı kaybettirmediğini görmek istersen canlı demo üzerinden yükleme, kod aktarma ve rapor ekranlarını dene; ardından kendi kurulumundaki izin listesini bu yazıdaki tabloyla karşılaştır.

