LiteSpeed 403 Forbidden hatası, tarayıcının sunucuya ulaştığını ancak LiteSpeed Web Server’ın istenen dosya veya dizine erişime izin vermediğini gösterir. Hata çoğu zaman yalnızca bir alan adını, belirli bir URL’yi ya da WordPress yönetim paneli gibi bir bölümü etkiler. cPanel sunucularda doğru çözüm; rastgele izin değiştirmek veya güvenlik katmanlarını kapatmak değil, hata kaydındaki ret nedenini bularak .htaccess, dosya sahipliği, ModSecurity, dizin indeksi ve erişim kurallarını hedefli biçimde düzeltmektir. Bu rehber, LiteSpeed Enterprise’ın cPanel ile kullanıldığı Linux sunucular için güvenli teşhis ve çözüm akışını açıklar.
Belirti ve kapsam: 403 hatası tam olarak nerede oluşuyor?
Tarayıcıda genellikle 403 Forbidden, You don't have permission to access this resource veya LiteSpeed’in varsayılan hata sayfası görünür. HTTP durum kodu 403, bağlantı, DNS ve temel web sunucusu yanıtının çalıştığını; fakat erişimin bir kural veya dosya sistemi denetimi tarafından reddedildiğini anlatır.
İlk olarak sorunun kapsamını ayırın:
- Tüm alan adı 403 veriyorsa: Document root izinleri, sahiplik, ana
.htaccessdosyası, vhost erişim kuralları veya güvenlik politikaları önceliklidir. - Yalnızca bir URL 403 veriyorsa: İlgili dizindeki
.htaccess, uygulama yönlendirmesi, ModSecurity kuralı veya URL’ye özel erişim kısıtı incelenmelidir. - Yalnızca yönetim paneli, XML-RPC, API ya da form gönderimi etkileniyorsa: ModSecurity ve uygulama güvenlik eklentileri daha güçlü adaylardır.
- Yalnızca dizin adresi 403 veriyorsa: Dizin listeleme kapalıyken varsayılan indeks dosyasının bulunmaması normal bir 403 nedeni olabilir.
LiteSpeed 403 Forbidden hatası için hızlı teşhis özeti
Değişiklik yapmadan önce aşağıdaki kontrol listesini sırayla uygulayın. Böylece dosya izinlerini gereksiz yere genişletmek veya tüm ModSecurity korumasını kapatmak zorunda kalmazsınız.
| Kontrol | Ne aranır? | Olası çözüm |
|---|---|---|
| HTTP yanıtı | Hatanın URL, IP veya kullanıcıya göre değişmesi | Başlıkları ve yönlendirmeyi doğrulayın |
| LiteSpeed hata kaydı | denied, forbidden, izin veya kural mesajı |
Mesajdaki dosya, kural veya istemciye odaklanın |
| Dosya sistemi | Document root ve üst dizinlerde erişim biti/sahiplik | En az ayrıcalıkla izinleri düzeltin |
| .htaccess | Require all denied, IP engeli, yanlış yönlendirme |
Hatalı kuralı geri alın veya daraltın |
| ModSecurity | Audit kaydında eşleşen kural kimliği | Yalnızca doğrulanan kural için istisna oluşturun |
Loglar ve komutlarla hata nedenini belirleme
İstek yanıtını komut satırından doğrulayın
Sunucu dışından veya sorunu yaşayan istemciden aşağıdaki komutu çalıştırın. -I yalnızca başlıkları getirir; sorun bir POST isteğinde oluşuyorsa uygulamanın gerçek isteğini ayrıca, güvenli bir test ortamında inceleyin.
curl -I https://ornekalanadi.tld/sorunlu-yol/Yanıtta Server: LiteSpeed başlığını, 403 durumunu, olası yönlendirmeleri ve önbellek katmanlarının davranışını not edin. Bir CDN veya ters vekil kullanılıyorsa, aynı isteği mümkünse origin sunucuya yönelik olarak da test edin. Aksi halde 403 yanıtı LiteSpeed’den değil, ön taraftaki güvenlik servisinden geliyor olabilir.
LiteSpeed ve alan adı loglarını izleyin
LiteSpeed Enterprise’ın varsayılan hata günlüğü çoğu kurulumda aşağıdaki yoldadır:
sudo tail -f /usr/local/lsws/logs/error.logArdından tarayıcıda hatalı URL’yi bir kez çağırın. Eski kayıtlar arasında filtreleme için:
sudo grep -iE 'forbidden|denied|access denied|mod_security' /usr/local/lsws/logs/error.log | tail -n 100cPanel kurulumlarında alan adına ait erişim günlükleri sıklıkla /usr/local/apache/domlogs/ altında tutulur. Dosya adı ve yazım yolu yapılandırmaya göre değişebileceğinden önce dizini doğrulayın:
sudo ls -lah /usr/local/apache/domlogs/
sudo tail -n 100 /usr/local/apache/domlogs/ornekalanadi.tldLog satırındaki zaman damgasını, istek yolunu, istemci IP’sini ve hata mesajını birlikte değerlendirin. Sadece tarayıcıdaki hata metnine dayanarak işlem yapmayın.
ModSecurity audit kaydını kontrol edin
Form gönderirken veya belirli sorgu parametrelerinde görülen 403’lerde bir ModSecurity kuralı isteği engellemiş olabilir. cPanel sunucularında yaygın audit log yolu aşağıdaki gibidir; ancak kesin yol sunucu yapılandırmasındaki SecAuditLog tanımına bağlıdır:
sudo tail -n 200 /usr/local/apache/logs/modsec_audit.logLogda bir kural kimliği, örneğin [id "123456"], ve eşleşen alan görünüyorsa bu kimliği kaydedin. WHM’de Security Center > ModSecurity Tools alanından olay ve kuralı inceleyin. Tüm ModSecurity kurallarını kapatmak yerine, yanlış pozitif olduğu kanıtlanan tek kural için alan adı veya uygulama düzeyinde, mümkün olan en dar istisnayı uygulayın.
Olası nedenler ve güvenli çözüm adımları
1. Hatalı dosya izinleri veya sahiplik
Web sunucusunun dosyayı okuyabilmesi için sadece dosyanın değil, dosyaya giden her üst dizinin de geçiş iznine sahip olması gerekir. Paylaşımlı cPanel düzeninde genel başlangıç değerleri dizinler için 755, normal web dosyaları için 644 şeklindedir. Uygulamanın yazması gereken dizinlerin gereksinimi farklı olabilir; bu nedenle herkese yazma izni veren 777 kullanmayın.
Uyarı: Sahiplik değişikliği hatalı kullanıcıya uygulanırsa başka hesabın verisine erişim sorunu doğabilir. İşleme başlamadan önce yedek alın ve yoğun sitelerde bakım penceresi planlayın. Önce yalnızca mevcut durumu görüntüleyin:
sudo namei -l /home/CPANEL_KULLANICISI/public_html/sorunlu-yol/
sudo stat -c '%A %a %U:%G %n' /home/CPANEL_KULLANICISI/public_html \
/home/CPANEL_KULLANICISI/public_html/.htaccessCPANEL_KULLANICISI değerini gerçek cPanel hesap adıyla değiştirin. Sahiplik açıkça yanlışsa, yalnızca ilgili hesabın document root alanında düzeltin:
sudo chown -R CPANEL_KULLANICISI:CPANEL_KULLANICISI /home/CPANEL_KULLANICISI/public_html
sudo find /home/CPANEL_KULLANICISI/public_html -type d -exec chmod 755 {} \;
sudo find /home/CPANEL_KULLANICISI/public_html -type f -exec chmod 644 {} \;Bu komutlar uygulamaya özgü çalıştırılabilir dosyaların veya özel yazma izinlerinin modunu değiştirebilir. Bu nedenle kapsamı tüm site yerine mümkünse sorunlu alt dizinle sınırlayın; özel uygulama gereksinimlerini önce kayda alın.
2. .htaccess içindeki erişim reddi veya hatalı kural
LiteSpeed, Apache uyumlu birçok .htaccess kuralını işler. Require all denied, eski tip Deny from all, yanlış IP kısıtları, ülke/IP engelleme eklentileri veya belirli dosyaları hedefleyen <FilesMatch> blokları 403 üretebilir. Üst dizinlerdeki .htaccess dosyalarının da miras alınabileceğini unutmayın.
Canlı sitede dosyayı silmek yerine yedekleyerek geçici test yapın:
cd /home/CPANEL_KULLANICISI/public_html
cp -a .htaccess .htaccess.before-403-test
mv .htaccess .htaccess.disabled-403-testHatalı URL’yi tekrar deneyin. 403 kalkarsa, yedek dosyayı satır satır inceleyerek reddeden kuralı bulun; ardından dosyayı geri yükleyin ve yalnızca sorunlu kuralı düzeltin:
mv .htaccess.disabled-403-test .htaccessBu test sırasında WordPress kalıcı bağlantıları veya uygulama yönlendirmeleri geçici olarak çalışmayabilir. Aynı anda yapılan içerik yönetimi değişikliklerini önlemek için kısa bir bakım penceresi kullanın.
3. İndeks dosyası olmayan dizin isteği
Kullanıcı bir dizini açtığında ve dizin listeleme kapalıysa, index.html, index.php gibi tanımlı bir başlangıç dosyası yoksa 403 görülebilir. Bu bir güvenlik özelliği olabilir; dizin listelemeyi açmak genellikle doğru çözüm değildir.
ls -lah /home/CPANEL_KULLANICISI/public_html/sorunlu-dizin/Uygulamanın beklediği indeks dosyasının doğru isimde ve doğru document root altında bulunduğunu doğrulayın. Addon domain veya subdomain kullanılıyorsa ana alan adının public_html dizini yerine cPanel’de tanımlı gerçek document root dizinini kontrol edin.
4. ModSecurity veya uygulama güvenlik katmanının isteği engellemesi
Audit kaydında kural eşleşmesi varsa, aynı isteği bir kez daha üreterek kayıt ile eşleştirin. Kuralın gerçekten yanlış pozitif olduğundan emin olun: İstek bir SQL injection, dosya yükleme veya komut çalıştırma denemesi içeriyorsa engelin kaldırılması güvenlik açığı oluşturabilir.
Yanlış pozitif doğrulandığında uygulamanın güncel sürümünü, ilgili eklentiyi ve isteğin biçimini gözden geçirin. Son seçenek olarak WHM ModSecurity araçlarından yalnızca ilgili kural kimliği için sınırlı istisna tanımlayın. Sunucu genelinde kural kapatmak, diğer tüm vhost’ları da etkileyebileceğinden tercih edilmemelidir.
5. Sunucu düzeyinde IP, vhost veya güvenlik politikası
LiteSpeed hata kaydı belirli bir istemci IP’sinin reddedildiğini gösteriyorsa vhost yapılandırması, LiteSpeed güvenlik ayarları, cPanel IP deny listeleri ve varsa CDN/WAF erişim politikalarını inceleyin. Ağ güvenlik duvarları çoğunlukla 403 yerine bağlantı zaman aşımı veya bağlantı reddi üretir; yine de ön taraftaki WAF’ın özel 403 sayfası döndürmediğini doğrulayın.
CloudLinux CageFS kullanılan sistemlerde, hesap sınırları veya dosya görünürlüğü sorunları da uygulamanın dosyaya ulaşmasını engelleyebilir. Bu tür sunucu düzeyi değişiklikleri, diğer hesapları etkileyebileceğinden yetkili sistem yöneticisi tarafından ve değişiklik kaydıyla yapılmalıdır.
Çözümü doğrulama
Düzeltme sonrasında sadece ana sayfayı değil, hatayı üreten gerçek URL’yi ve ilgili işlevi test edin. Tarayıcı önbelleğini atlamak için komut satırından tekrar kontrol edebilirsiniz:
curl -I -L https://ornekalanadi.tld/sorunlu-yol/Başarılı sonuçta beklenen durum kodu çoğunlukla 200, bilinçli bir yönlendirme varsa son yanıtta 301/302 ardından 200 olmalıdır. Ardından LiteSpeed hata kaydında yeni denied veya ModSecurity engeli oluşmadığını kontrol edin. Testi oturum açmış ve oturum açmamış kullanıcıyla yapmak, yalnızca oturum veya çerez kaynaklı kuralları ayırmaya yardımcı olur.
LiteSpeed 403 Forbidden hatasını önleme
.htaccessdeğişikliklerini sürüm kontrolü veya zaman damgalı yedekle uygulayın.- cPanel hesap taşıma ve geri yükleme işlemlerinden sonra document root sahipliği ile izinlerini örnek URL’lerde kontrol edin.
- ModSecurity istisnalarını kural kimliği, alan adı ve gerekçe ile belgelendirin; geniş kapsamlı devre dışı bırakmalardan kaçının.
- Uygulama, tema ve eklentileri güncel tutun; güncel olmayan eklentilerin ürettiği anormal istekler WAF kurallarına takılabilir.
- CDN, WAF ve LiteSpeed katmanlarında hangi bileşenin 403 ürettiğini gösteren erişim ve hata loglarını düzenli saklayın.
Sonuç
LiteSpeed 403 Forbidden hatası çoğunlukla izin, sahiplik, .htaccess veya ModSecurity kaynaklıdır; ancak doğru kaynak ancak log satırıyla kesinleşir. Önce sorunun URL bazlı mı, alan adı genelinde mi olduğunu belirleyin; sonra LiteSpeed hata kaydını ve gerekiyorsa ModSecurity audit kaydını inceleyin. En küçük ve geri alınabilir değişiklikle ilerlemek, site erişimini geri getirirken güvenlik kontrollerini korumanın en güvenli yoludur.
Sık sorulan sorular
LiteSpeed 403 hatasında 777 izni vermek çözüm müdür?
Hayır. 777 güvenlik riskini artırır ve sahiplik, üst dizin geçiş izni veya ModSecurity gibi asıl nedeni çözmeyebilir. Önce log ve mevcut izinleri kontrol edin.
.htaccess dosyasını silince site açıldı; ne yapmalıyım?
Dosyayı kalıcı olarak silmeyin. Yedekten geri yükleyin, reddeden kuralı belirleyin ve yalnızca o kuralı düzeltin. WordPress gibi uygulamalarda yönlendirme kuralları bu dosyada bulunabilir.
ModSecurity’yi tamamen kapatmak güvenli mi?
Genellikle hayır. Doğrulanmış yanlış pozitif için tek bir kuralı, mümkünse yalnızca ilgili alan adında istisna tutmak daha güvenlidir.
403 hatası LiteSpeed önbelleğinden kaynaklanabilir mi?
Önbellek eski bir 403 yanıtını gösterebilir, ancak kök neden çoğunlukla erişim kuralıdır. Önce origin yanıtını ve logları kontrol edin; ardından ilgili önbelleği kontrollü biçimde temizleyin.
Yalnızca bir alt dizin 403 veriyorsa nereden başlamalıyım?
Önce o alt dizindeki ve üst dizinlerdeki .htaccess dosyalarını, dizin izinlerini, sahipliği ve indeks dosyasının varlığını kontrol edin. Ardından aynı zaman damgasındaki LiteSpeed log kaydını inceleyin.
