Teknoloji

Linux Dosya İzinleri 644, 755, 777: Paylaşımlı Hosting ve VPS İçin Güvenli Ayarlar

Linux Dosya İzinleri Neden Bu Kadar Önemli?

Bir web sitesini paylaşımlı hosting, VPS ya da dedicated sunucuda çalıştırırken, çoğu kişi önce CPU, RAM ve disk performansına odaklanır. Oysa pratikte incelediğimiz birçok hack vakasının ortak noktası, yanlış ayarlanmış Linux dosya izinleri oluyor. Özellikle 644, 755 ve 777 gibi sık kullanılan izin değerleri doğru anlaşılmadığında; basit bir tema güncellemesi, yanlış çalışan bir eklenti ya da aceleyle verilmiş bir FTP yetkisi sitenizi saldırganlara tamamen açabiliyor.

Bu yazıda, DCHost ekibi olarak günlük hayatımızda en çok karşılaştığımız izin senaryolarını, paylaşımlı hosting ile VPS ortamlarının farklarını ve gerçek hayatta işe yarayan güvenli ayar örneklerini adım adım anlatacağız. Hedefimiz; ezber yerine mantığı oturtmanız, böylece ister WordPress, ister Laravel, ister özel bir PHP uygulaması çalıştırın, hangi dosyanın neden 644, hangi klasörün neden 755 olacağını içgüdüsel olarak bilebilmeniz.

Anlatımda çok teknik detaya boğulmadan, ama gerektiğinde komut örnekleriyle destekleyerek ilerleyeceğiz. Eğer özellikle WordPress tarafında daha kapsamlı sertleştirme adımları arıyorsanız, detaylı bir kontrol listesini WordPress güvenlik sertleştirme rehberimizde ayrıca bulabilirsiniz.

Temel Kavramlar: Kullanıcı, Grup, Diğer ve rwx

Linux dosya izinlerini anlamanın ilk adımı, üç temel rolü ve üç temel izni kafaya oturtmaktır:

  • Sahip (user) – Dosyanın birincil sahibi olan kullanıcı
  • Grup (group) – Dosyanın ait olduğu kullanıcı grubu
  • Diğer (others) – Geriye kalan tüm kullanıcılar

Her dosya ve klasör için bu üç rolün her birine üç farklı izin atanır:

  • r (read) – Okuma izni
  • w (write) – Yazma / değiştirme izni
  • x (execute) – Çalıştırma izni (klasörler için “klasörün içine girebilme” izni)

Dosya üzerinde bu üçlü kombinasyon; örneğin rwxr-xr-x şeklinde görünebilir. Bunu üçlü gruplara bölerseniz:

  • rwx – Sahip (okuma + yazma + çalıştırma)
  • r-x – Grup (okuma + çalıştırma)
  • r-x – Diğer (okuma + çalıştırma)

Bu gösterimi terminalde görmek için en sık kullanılan komut:

ls -l

Çıktıdaki ilk sütun dosya türü ve izin bilgisini gösterir. Örneğin:

-rw-r--r--  1 user user  1200 Jan  1 12:00 index.php

Burada -rw-r–r–, az sonra sayısal karşılığını göreceğimiz 644 izin setine denk gelir.

Sayısal Gösterim: 644, 755, 777 Ne Demek?

Linux’ta dosya izinlerini sayısal olarak da ifade ederiz. Her izin harfinin bir sayısal karşılığı vardır:

  • r = 4
  • w = 2
  • x = 1

Her rol (sahip, grup, diğer) için bu değerler toplanır:

  • 7 = 4 + 2 + 1 = rwx
  • 6 = 4 + 2 = rw-
  • 5 = 4 + 1 = r-x
  • 4 = 4 = r–
  • 0 = hiç izin yok —

Örneğin 755 dediğimizde:

  • Sahip: 7 → rwx
  • Grup: 5 → r-x
  • Diğer: 5 → r-x

Yani rwxr-xr-x elde ederiz. Benzer şekilde:

  • 644 → rw-r–r–
  • 777 → rwxrwxrwx (herkes her şeyi yapabilir)

644, 755 ve 777’i Senaryolarla Anlamak

644: Dosyalar İçin Güvenli Varsayılan

Web projelerinde dosyalar için en sık kullanılan değer 644’tür. Bu izin seti:

  • Sahip: rw- (okuyabilir ve yazabilir)
  • Grup: r– (sadece okuyabilir)
  • Diğer: r– (sadece okuyabilir)

Özetle: dosyayı sadece sahibi değiştirebilir, sistemdeki diğer herkes sadece okuyabilir.

Bir PHP dosyasını (örneğin index.php) çalıştırmak için dosyanın kendisinde “x” olması gerekmez. Çalıştırma izni, esas olarak ikili (binary) dosyalar ve script dosyaları (bash script gibi) için doğrudan önemlidir. PHP dosyanız, PHP yorumlayıcısı tarafından okunduğu için, 644 izin genellikle yeterlidir.

Paylaşımlı hosting ortamlarında, web içeriği çoğunlukla web sunucusunun (Apache, Nginx + PHP-FPM) çalıştığı kullanıcıya okunabilir olmalıdır. DCHost altyapısında kullandığımız izole kullanıcı modellerinde de tipik olarak dosya izinlerini şu şekilde görürsünüz:

  • PHP, HTML, JS, CSS dosyaları: 644
  • Özel yapılandırma dosyaları (örn. .env): 600 veya 640

755: Klasörler ve Bazı Çalıştırılabilir Dosyalar İçin

755 değeri, özellikle klasörler için standart kabul edilir. Çünkü klasör için “x” izni, o klasörün içine girebilmek ve içeriğini listeleyebilmek anlamına gelir.

755 izin seti:

  • Sahip: rwx
  • Grup: r-x
  • Diğer: r-x

Yani klasörün sahibinin tam kontrolü vardır; sistemdeki diğer herkes klasörün içine girebilir, ama içerikte değişiklik yapamaz.

Tipik web projesinde şu şekilde kullanırız:

  • Web kök dizini (public_html, public, httpdocs vb.): 755
  • Uygulama klasörleri (wp-content, storage, vendor vb.): 755

Bazı durumlarda, proje içinde çalıştırılabilir script’ler (örneğin artisan, bin/console) için de 755 verilir ki ilgili kullanıcılar bu script’i terminalden doğrudan çalıştırabilsin.

777: Herkes Yazabiliyorsa, Saldırgan da Yazabilir

777, pratikte “beni hackle” demektir. İzin seti şu şekildedir:

  • Sahip: rwx
  • Grup: rwx
  • Diğer: rwx

Yani sistemdeki her kullanıcı bu dosya veya klasör üzerinde okuma, yazma ve çalıştırma iznine sahiptir. Paylaşımlı hosting ortamında bu, aynı fiziksel sunucudaki diğer hosting hesaplarının da bu dosyayı yazabilmesi anlamına gelebilir (izolasyon modeline göre değişir, ama risk büyüktür).

Uzun zamandır sahada gördüğümüz en yaygın hata şu:

  • WordPress veya başka bir CMS bir klasöre yazamıyor.
  • Panelde ya da FTP’de “Hata: Yazma izni yok” uyarısı çıkıyor.
  • Geliştirici ya da kullanıcı, sorunu hızla çözmek için klasörü 777 yapıyor.
  • Bir süre her şey çalışıyor, birkaç hafta sonra siteye web shell yerleştirilmiş, zararlı kodlar dağılmış, tüm hesap tehlikede.

Özellikle wp-content/uploads gibi herkese açık upload klasörlerinin 777 olması, saldırganların zararlı PHP dosyaları yükleyip çalıştırmasını çok kolaylaştırır. Bu nedenle 777 iznini, hem paylaşımlı hosting hem de VPS ortamlarında son çare bile değil, neredeyse hiç kullanmamanız gereken bir değer olarak düşünmelisiniz.

Paylaşımlı Hosting’de Güvenli Dosya İzni Stratejisi

Paylaşımlı hosting ortamında bir fiziksel sunucuyu birçok müşteri birlikte kullanır. DCHost altyapısında CloudLinux, izolasyonlu kullanıcı hesapları ve güvenlik katmanları ile bu risk minimize edilse de, “others” (diğer) izinleri hala önemlidir. Çünkü saldırganların sıklıkla istismar ettiği vektörlerden biri, komşu hesaplar veya güvenliği zayıf bir web uygulamasıdır.

Genel olarak önerdiğimiz yapı şudur:

  • Tüm dosyalar: 644
  • Tüm klasörler: 755
  • Hassas dosyalar (wp-config.php, .env vb.): 600 veya 640

WordPress Örneği: Pratik İzin Tablosu

Paylaşımlı hosting’de en sık gördüğümüz CMS, tahmin edeceğiniz gibi WordPress. Güvenlik ve çalışabilirlik dengesini korumak için tipik bir WordPress kurulumunda şu izinleri öneriyoruz:

  • WordPress çekirdek dosyaları (wp-admin, wp-includes içindekiler): Dosyalar 644, klasörler 755
  • wp-content klasörü: 755
  • wp-content/uploads: 755 (asla 777 değil)
  • wp-config.php: 600 veya 640

Daha kapsamlı bir WordPress sertleştirme kontrol listesine ihtiyacınız varsa, WordPress güvenlik sertleştirme rehberimizde dosya izinlerinden sunucu güvenlik duvarına kadar uçtan uca adımları bulabilirsiniz. Ayrıca, paylaşımlı ortamda WordPress kullanırken WAF, 2FA ve yedekleme tarafını doğru kurmak için paylaşımlı hosting’de WordPress güvenliği rehberimize da göz atmanızı öneririz.

Paylaşımlı Hosting’de 777 Neden Daha da Tehlikeli?

VPS’te tüm sistemi tek siz kullanıyorsanız, 777 yine risklidir; ama bu risk çoğunlukla kendi süreçleriniz ve yerel privilege escalation açıklarıyla sınırlıdır. Paylaşımlı hosting’de ise tablo daha farklıdır:

  • Aynı fiziksel sunucuda, potansiyel olarak yüzlerce farklı müşteri hesabı bulunur.
  • Bu hesapların bazıları zayıf parolalara, güncel olmayan yazılımlara veya zararlı eklentilere sahip olabilir.
  • Bir hesaptan sisteme sızan saldırgan, 777 izinli klasörlerinize çok daha kolay erişebilir.

Bu nedenle paylaşımlı hosting tarafında 777’i tamamen kırmızı bölge olarak işaretliyoruz. Eğer bir dosya veya klasörün 777’ye ihtiyaç duyduğunu düşünüyorsanız, asıl sorunun genellikle PHP çalıştırma modeli, kullanıcı-grup sahipliği veya yanlış yapılandırılmış bir eklenti olduğunu bilmelisiniz.

Ek olarak, erişim katmanlarında da güvenliği sıkılaştırmak kritik. Örneğin FTP yerine SFTP kullanmak, parolalarınız ve dosya transferleriniz için çok daha güvenli bir zemin oluşturur.

cPanel ve Diğer Panellerde Dosya İzinleri

cPanel veya benzeri kontrol panellerinde genellikle “File Manager” üzerinden dosya izinlerini görebilir ve değiştirebilirsiniz. Burada da mantık aynıdır; sadece arayüz komut satırı yerine tıklamalarla chmod işlemini yapmanızı sağlar.

DCHost üzerinde cPanel kullanan müşterilerimizin, panel güvenliğini de dosya izinleri kadar ciddiye almasını istiyoruz. Bu amaçla hazırladığımız cPanel güvenlik sertleştirme kontrol listesi, panel erişimi, 2FA ve temel sertleştirme adımlarını tek tek ele alıyor. Panel tarafını sıkı tutmak, yanlışlıkla verilmiş geniş izinlerin yaratacağı zararları da azaltır.

VPS ve Dedicated Sunucuda Dosya İzinleri

VPS veya dedicated sunucuda sistem genellikle tek bir projeye ya da aynı ekibe ait birkaç projeye hizmet eder. “Zaten sunucuda sadece ben varım” düşüncesi nedeniyle dosya izinleri burada daha da ihmal edilebiliyor. Ancak:

  • Uygulamayı her zaman root dışı bir kullanıcıyla çalıştırmanız gerekir.
  • Sunucuda birden çok servis (web, veritabanı, cache, cron script’leri) aynı anda koşar.
  • Bir servis üzerinden sisteme sızan saldırgan, gevşek dosya izinleri sayesinde hızla yayılabilir.

Bu nedenle VPS tarafında da temel prensipler değişmez:

  • Dosyalar: 644 (özel durumlarda 600/640)
  • Klasörler: 755 (özel durumlarda 750)

Yeni bir VPS aldığınızda yalnızca dosya izinlerini değil, kullanıcı hesaplarını, güvenlik duvarını ve SSH ayarlarını da düşünmek gerekir. Bu kapsamı bir bütün olarak ele aldığımız “Yeni VPS’te ilk 24 saat” rehberimizde, ilk günden itibaren atmanız gereken temel adımları sıraladık.

VPS’te Uygulama Kullanıcısı ve Grup Sahipliği

VPS senaryosunda genellikle şu yapıyı öneriyoruz:

  • Her proje için ayrı bir Linux kullanıcısı (örn. project1, project2) açın.
  • Web sunucusu (Nginx/Apache) ve PHP-FPM, ilgili proje kullanıcısı altında çalışsın.
  • Proje dosyalarının sahibi o kullanıcı ve onun grubu olsun.

Örnek bir yapı:

# Kullanıcı ve grup oluşturma (örnek)
useradd -m -s /bin/bash project1

# Proje dizinini oluşturma
mkdir -p /var/www/project1
chown -R project1:project1 /var/www/project1

# İzinleri ayarlama
find /var/www/project1 -type d -exec chmod 755 {} ;
find /var/www/project1 -type f -exec chmod 644 {} ;

Bu yaklaşımı, genel VPS güvenlik stratejisi ile birlikte düşünmek önemli. Daha sistematik bir bakış açısı için VPS sunucu güvenliği rehberimizde dosya izinleri, SSH sertleştirme, firewall ve izleme adımlarının nasıl birlikte çalıştığını detaylandırıyoruz.

chmod, chown ve umask ile Uygulamalı Örnekler

Sayısal ve Sembolik chmod Kullanımı

Dosya izinlerini değiştirmek için kullandığımız temel komut chmod’dur. İki farklı yazım şekli vardır:

  • Sayısal: chmod 644 dosya.php
  • Sembolik: chmod u=rw,go=r dosya.php

Örnekler:

# Dosyayı 644 yapmak
chmod 644 index.php

# Klasörü 755 yapmak
chmod 755 public_html

# Sadece sahibine yazma izni eklemek (sembolik kullanım)
chmod u+w config.php

# "others" grubundan yazma iznini kaldırmak
chmod o-w somefile

Tüm Projeyi Güvenli Hale Getirmek: tipik web root düzeltme komutu

Özellikle sorun yaşanmış, farklı denemeler yapılmış bir projede izinleri baştan düzenlemek isteyebilirsiniz. Örneğin web kök dizininiz /home/user/public_html ise:

cd /home/user/public_html

# Tüm klasörleri 755 yap
find . -type d -exec chmod 755 {} ;

# Tüm dosyaları 644 yap
find . -type f -exec chmod 644 {} ;

# wp-config.php gibi özel dosyaları sıkılaştır
chmod 600 wp-config.php 2>/dev/null || true

Benzer komutları Laravel veya başka framework’ler için de uygulayabilirsiniz; sadece storage, bootstrap/cache gibi yazılabilir olması gereken klasörler için ek olarak grup veya kullanıcı yazma iznini tanımlamanız gerekir.

chown: Sahiplik Doğru Olmadan İzinler Tam Çözüm Değildir

İzinler kadar önemli bir diğer konu da dosya sahipliği (owner/group) bilgisidir. Eğer dosyaların sahibi yanlış kullanıcı ise, izinler teknik olarak doğru olsa bile uygulamanız yazma hataları verebilir.

Sahipliği değiştirmek için chown kullanılır:

# Sahipliği project1 kullanıcısı ve grubuna ver
chown project1:project1 dosya.php

# Tüm proje için (dikkatli kullanın)
chown -R project1:project1 /var/www/project1

Paylaşımlı hosting ortamında, genellikle panel otomatik olarak doğru kullanıcı-grup atamasını yapar. DCHost’ta bir sorun yaşarsanız, destek ekibimiz sizin yerinize güvenli şekilde toplu sahiplik düzeltmesi yapabilir.

umask: Yeni Oluşturulan Dosyaların Varsayılan İzinleri

Elinizle chmod yapmadığınızda, yeni oluşturulan dosya ve klasörlerin izinleri nereden geliyor? Bunun cevabı umask ayarıdır. Umask, “hangi izinlerin yasaklanacağını” tanımlar.

Örneğin bir shell’de:

umask

komutunu çalıştırdığınızda çoğu zaman 0022 ya da 0002 göreceksiniz. Basitçe:

  • Dosyalar için maksimum izin 666 (rw-rw-rw-) olarak düşünülür.
  • Umask değeri bu maksimumdan çıkartılır.

Yani umask 022 ise:

  • Dosyalar: 666 – 022 = 644
  • Klasörler: 777 – 022 = 755

Gördüğünüz gibi, sıkça önerilen 644/755 seti aslında yaygın bir umask değeri ile otomatik olarak oluşur. Özel deployment senaryolarında (örneğin bir CI/CD pipeline’ında) umask’i kastlı olarak ayarlayıp, yeni oluşturulan dosyaların başından itibaren doğru izinlerle gelmesini sağlayabilirsiniz.

Güvenlik Denetimi: Alarm Çanı Çalması Gereken İzinler

Mevcut bir sunucuda ya da hosting hesabında hızlı bir güvenlik taraması yapmak istiyorsanız, dosya izinleri üzerinden şüpheli noktaları tespit etmek oldukça etkilidir. Özellikle aşağıdaki durumlar risklidir:

  • 777 izinli dosya veya klasörler
  • “others” grubunda yazma izni (o+w)
  • Web kök dizini altında herkes tarafından yazılabilir PHP dosyaları

Bunları tespit etmek için kullanabileceğiniz bazı komut örnekleri:

# 777 izinli her şeyi bul (root olarak değil, proje dizininde çalıştırın)
find . -perm 0777 -ls

# Diğer (others) için yazma izni olan dosya/klasörler
find . -perm -0002 -ls

# Web kökünde yazılabilir PHP dosyaları
find . -name '*.php' -perm -0002 -ls

Böyle bir tarama sonrası, gerçekten yazılabilir olması gereken alanlarla (örneğin cache, storage, uploads klasörleri) gereksiz yere açık bırakılmış klasörleri ayırmak gerekir. Gereğinden fazla yazılabilir olanları 755/750 seviyesine indirerek güvenliği artırabilirsiniz.

Bu tip denetimleri düzenli olarak yapmak; log, yedek ve erişim katmanlarıyla birleştiğinde sağlam bir güvenlik stratejisi oluşturur. Sunucu tarafında daha geniş bir resim için VPS sunucu güvenliği üzerine hazırladığımız detaylı rehbere de göz atabilirsiniz.

DCHost Altyapısında Dosya İzinleri İçin Pratik Öneriler

DCHost olarak hem paylaşımlı hosting hem de VPS/dedicated müşterilerimizde en sık karşılaştığımız sorunlardan biri, aslında çok küçük bir izin ayarının büyüyen güvenlik açıklarına dönüşmesi. Deneyimlerimizden süzülen, pratik olarak hemen uygulayabileceğiniz bazı önerileri şöyle özetleyebiliriz:

  • Genel kural: Dosyalar 644, klasörler 755. Bu kuralı bozmadan önce iki kere düşünün.
  • 777’den kaçının: Bir eklenti veya tema sizden 777 isterse, sebebini sorgulayın; çoğu zaman uygulama tasarımındaki bir tembelliktir.
  • Hassas dosyaları sıkılaştırın: wp-config.php, .env, yapılandırma dosyaları 600/640 olsun.
  • Paylaşımlı hosting’de panik yapmayın: İzin sorunu yaşarsanız, DCHost destek ekibine ticket açın; hesabınızı riske atmadan problemi çözebiliriz.
  • VPS’te kullanıcı izolasyonu kurun: Her proje için ayrı kullanıcı açın, web sunucusu ve PHP-FPM’i o kullanıcı altında koşturun.
  • FTP yerine SFTP kullanın: Parola ve dosya içeriklerini şifrelemek için SFTP kullanımını standart hale getirin.

Yeni bir projeyi canlıya alırken, dosya izinlerini de lansman kontrol listenize eklemenizi öneririz. Sunucu tarafında SEO ve performans kontrolleri için hazırladığımız yayına alma kontrol listesi rehberimiz, bu anlamda güzel bir tamamlayıcı olabilir.

Özet ve Son Tavsiyeler

Linux dosya izinleri ilk bakışta karmaşık görünse de, aslında üç harf (r, w, x) ve üç rol (user, group, others) etrafında dönen çok mantıklı bir sistem. Paylaşımlı hosting’de de, VPS veya dedicated sunucuda da ana prensipler aynı:

  • Dosyalar için 644, klasörler için 755 genellikle güvenli ve yeterlidir.
  • Hassas yapılandırma dosyalarını 600/640 ile daha da sıkılaştırın.
  • 777’yi alışkanlık haline getirmeyin; gerçekten mecbur kaldığınız çok istisnai durumlarda bile geçici kullanıp hemen geri dönün.
  • Sadece izinleri değil, sahiplik (owner/group), umask, kullanıcı izolasyonu ve erişim protokollerini (SFTP, SSH) birlikte düşünün.

DCHost olarak, ister paylaşımlı hosting, ister VPS, ister dedicated sunucu kullanın; dosya izinleri ve güvenlik tarafında takıldığınız her adımda teknik ekibimizle yanınızdayız. Yeni bir projeye başlıyorsanız, “daha sonra bakarız” demek yerine, en başta doğru izin modelini kurmak hem güvenlik risklerini hem de ileride yaşayacağınız tuhaf hata mesajlarını ciddi şekilde azaltır.

Mevcut sitenizde izinlerle ilgili sorunlar yaşıyorsanız, DCHost hesabınızdan bir destek talebi açarak hem mevcut dosya izinlerinin hızlı bir analizini isteyebilir, hem de projenize özel en uygun 644/755/600 kombinasyonlarını birlikte planlayabiliriz. Güvenli ve sağlıklı çalışan bir altyapının temelinde, doğru ayarlanmış Linux dosya izinleri olduğunu unutmayın.

Sıkça Sorulan Sorular

Genel kural olarak web projelerinde dosyaların 644, klasörlerin 755 olması hem güvenli hem de pratik bir yaklaşımdır. Çoğu CMS (WordPress, Laravel tabanlı projeler vb.) bu izinlerle sorunsuz çalışır. Ancak istisnalar vardır: Örneğin yapılandırma dosyaları (wp-config.php, .env gibi) daha hassas olduğu için 600 veya 640 olarak ayarlanması daha doğru olur. Öte yandan cache, storage veya uploads gibi yazılabilir olması gereken bazı klasörlerin, ilgili kullanıcı veya grup için ek yazma iznine ihtiyacı olabilir; burada da 775 veya 750 gibi kombinasyonlar devreye girebilir. Yani 644/755 iyi bir başlangıç şablonu, ama her proje için son dokunuşu ihtiyaçlara göre yapmak gerekir.

Pratikte 777 iznine neredeyse hiç ihtiyaç yok diyebiliriz. 777, sistemdeki herkesin (diğer kullanıcılar ve süreçler dahil) ilgili dosya veya klasörde okuma, yazma ve çalıştırma hakkına sahip olması demektir. Paylaşımlı hosting’de bu, başka bir hesabın bile dosyalarınıza yazabilmesi anlamına gelebilir. Bazı yanlış yazılmış eklenti veya script’ler 777 talep eder; bu genellikle uygulama tasarımındaki bir tembelliğin göstergesidir. Çok nadir, çok kontrollü bakım senaryolarında, kısa süreliğine 777 verilebilir, ama hemen ardından daha sıkı bir değere dönmek şarttır. Kural olarak: 777'yi çözüm değil, en son çare bile saymayın; sorunun kök nedenini (sahiplik, kullanıcı modeli, PHP-FPM ayarı) düzeltmeye odaklanın.

Teknik olarak Linux dosya izinleri hem paylaşımlı hosting’de hem VPS’te aynı şekilde çalışır; fark, tehdit modelindedir. Paylaşımlı hosting’de aynı fiziksel sunucuyu birçok farklı müşteri paylaşır; dolayısıyla "others" (diğer) için verilen izinler, potansiyel olarak başka hesaplar tarafından da kullanılabilir hale gelir. Bu yüzden 777 gibi geniş izinler burada çok daha tehlikelidir. VPS’te ise sistem genellikle sadece size aittir; ama bu, gevşek izinlerin masum olduğu anlamına gelmez. Uygulamalarınız, servisleriniz ve olası güvenlik açıkları üzerinden bir saldırgan sisteme sızdığında, gereğinden fazla yazılabilir alanlar hızlı yayılım sağlar. Özetle: Mantık aynı, ama paylaşımlı ortamda hata toleransı çok daha düşüktür.

Evet, özellikle popüler framework ve CMS’lerde bazı klasörlerin yazılabilir olması gerekir ve bu alanlar dikkatlice tanımlanmalıdır. WordPress için wp-content/uploads, Laravel için storage ve bootstrap/cache klasörleri tipik örneklerdir. Bu klasörler ilgili kullanıcı/grup için yazılabilir olmalı, ama 777 gibi herkese açık izinlerden kaçınılmalıdır; çoğunlukla 755 klasör + doğru sahiplik (chown) kombinasyonu yeterlidir. Ayrıca wp-config.php veya .env gibi kritik yapılandırma dosyalarını daha sıkı (600/640) yapmak iyi bir pratiktir. Uygulamaya özel detaylı sertleştirme adımlarını, DCHost blogumuzdaki WordPress güvenlik sertleştirme ve Laravel/WordPress prod ortam optimizasyonu rehberleri üzerinden adım adım takip edebilirsiniz.

Yanlış dosya izinleri, saldırganlara iki ana kapı açar: Zararlı dosya yükleme ve mevcut dosyaları değiştirme. Örneğin uploads klasörünüz 777 ise, bir güvenlik açığı üzerinden saldırgan bu klasöre zararlı bir PHP dosyası (web shell) yükleyebilir ve çalıştırabilir. Benzer şekilde, everyone için yazılabilir olan .php veya .js dosyaları, zararlı kod enjekte edilmesi için ideal hedeflerdir. Paylaşımlı hosting’de geniş izinler, komşu hesaplardan gelebilecek saldırıları da kolaylaştırır. Sonuçta, güvenlik açığı + gereğinden geniş izin kombinasyonu, saldırganın sunucuda kalıcı hale gelmesini ve daha fazla sisteme yayılmasını sağlar. Bu yüzden izinleri, özellikle world-writable (o+w, 777) durumlarını düzenli olarak denetlemek kritik önem taşır.