Access denied on this server: nedenleri ve çözümleri

Hata ne anlama gelir

Bu ifade hiçbir standardın parçası değildir, bu yüzden bu kadar çok farklı biçimde karşınıza çıkar. Apache onu bir dizin kuralından yazdırır. ModSecurity ve barındırma kontrol panelleri bir kural tetiklendiğinde yazdırır. Bir CDN veya WAF, bir referans numarasıyla kendi markalı sürümünü yazdırır. AWS onu S3 veya CloudFront'tan kısa bir XML belgesi olarak döndürür. Hepsi HTTP düzeyinde aynı şeyi söylüyor: 403, reddedildi, ve kimlik bilgileriyle tekrar denemek için bir davet yok.

İşte bu son kısım onu karıştırıldığı hatalardan ayırır. Bir 401 kimlik doğrulaması ister ve yeniden denemeyi bekler. Bir 404, kaynağın orada olmadığını söyler. Bir 403, kaynağın orada olduğunu ama size verilmeyeceğini söyler, ve isteği değiştirmeden tekrarlamak aynı yanıtı üretir. Durum kodunun kendisi 403 Forbidden rehberinde ele alınır; bu rehber hangi katmanın hayır dediğini bulmakla ilgilidir.

Önce bunun sizin mi yoksa herkesin mi sorunu olduğunu bulmakla başlayın, çünkü çözümlerin birbiriyle hiçbir ortak yanı yoktur. Başka bir ağdaki bir meslektaşınız sayfayı sorunsuz yüklüyorsa, engellenen sizsiniz. Kimse yükleyemiyorsa, site yanlış yapılandırılmıştır.

Neden olur

• IP adresiniz engellenmiş. Başarısız girişlerden sonra eklenen bir güvenlik duvarı veya WAF kuralı, ağınızdaki bir kazıyıcı, veya kimsenin kaldırmadığı elle konulmuş bir engel.
• Hız sınırlama. Kısa bir pencerede çok fazla istek; yeniden yükleme ağırlıklı bir hata ayıklama oturumuyla veya paylaşımlı bir ofis bağlantısıyla kolayca tetiklenir.
• Coğrafi kısıtlamalar. Tek bir ülkeyle sınırlı siteler, veya bir bölgeden gelen kötüye kullanım sonrası tüm bölgeyi engelleme.
• Paylaşımlı veya itibarı işaretlenmiş bir IP. VPN çıkış düğümleri, mobil operatör NAT'ı ve ucuz barındırma aralıkları, başka kullanıcıların yaptığı yüzünden genellikle bir grup olarak engellenir.
• Kullanıcı aracınızı okuyan bot kuralları. Komut satırı araçları, başsız tarayıcılar ve alışılmadık kullanıcı aracısı dizeleri, normal bir tarayıcının izinli olduğu yerde reddedilir.
• Bayat çerezler veya bozuk bir oturum. Süresi dolmuş bir oturum jetonu, giriş sayfasına yönlendirme yerine bir ret üretebilir.
• Başlıkları çıkaran veya ekleyen bir tarayıcı uzantısı, veya isteği yeniden yazan bir kurumsal proksi.
• Dosya ve dizin izinleri. Web sunucusu kullanıcısı dosyayı okuyamıyor veya bir üst dizinden geçemiyor.
• Listeleme kapalıyken indeks dosyası yok. Sunacak hiçbir şeyi olmayan bir dizin isteği ve yürürlükte olan Options -Indexes, boş bir sayfa yerine 403 döndürür.
• Açık bir reddetme kuralı. Apache yapılandırmasında bir Require all denied veya bir bakım penceresinden kalma bir .htaccess.
• Bir WAF yanlış pozitifi. ModSecurity ve benzeri kural setleri, genellikle bir form alanında veya bir sorgu dizesinde bir enjeksiyon girişimine benzeyen bir şey içeren meşru istekleri reddeder.
• Bulut depolama izinleri. Nesnenin okunmasına izin vermeyen bir S3 kova politikası veya bir CloudFront kaynak erişimi ayarı.

Ziyaretçiyseniz

1. Sayfa metnine güvenmek yerine durum kodunu doğrulayın. curl -s -o /dev/null -w "%{http_code}\n" https://example.com/page, bunun gerçekten bir 403 mü yoksa benzer bir mesaj giyen bir 401 veya 429 mu olduğunu söyler.
2. Sayfayı gizli bir pencerede açın. Bu tek adımda çerezleri ve çoğu uzantıyı devre dışı bırakır. Orada başarılı olmak, çözümün sitede değil profilinizde olduğu anlamına gelir.
3. Her şeyi temizlemek yerine yalnızca o site için çerezleri temizleyin, sonra yeniden yükleyin.
4. VPN'i veya proksiyi kapatın ve tekrar deneyin. O zaman çalışırsa, reddedilen şey çıkış düğümünün adresidir, ve başka bir bölgeye geçmek genellikle sorunu çözer.
5. Farklı bir ağ deneyin, en kolayı mobil veri üzerinden bir telefon. Bu, adresinizin engellenen şey olduğunu kanıtlamanın en hızlı yoludur.
6. Uzantıları birer birer devre dışı bırakın, reklam engelleyicilerden, gizlilik araçlarından ve başlıkları düzenleyen her şeyden başlayarak.
7. Engelin bölgesel olup olmadığını kontrol edin, başka bir ülkedeki birine sorarak, veya engel sayfasında konumunuzdan bahsedilip bahsedilmediğini okuyarak.
8. Engel sayfası bir referans numarası gösteriyorsa siteyle iletişime geçin. WAF sayfaları genellikle, operatörün saniyeler içinde tetiklenen tam kuralı bulmasını sağlayan bir olay kimliği yazdırır.

Sitenin sahibiyseniz

1. Önce hata günlüğünü okuyun. Nedeni doğrudan adlandırır, ve bundan sonraki her adım onsuz tahmin yürütmektir:

   sudo tail -50 /var/log/apache2/error.log
   sudo tail -50 /var/log/nginx/error.log
   sudo grep -i modsecurity /var/log/apache2/error.log | tail -20

   Apache bir izin sorununu "client denied by server configuration" veya "Permission denied" olarak günlükler. nginx "directory index of ... is forbidden" veya "open() ... failed (13: Permission denied)" yazar. Bu üç mesaj çoğu durumu kapsar.
2. Her üst dizin dahil, tüm yol boyunca izinleri kontrol edin. Web sunucusunun giremediği bir dizin, dosyanın kendisi ne kadar doğru görünürse görünsün altındaki her şeyi reddeder:

   namei -l /var/www/html/index.html
   sudo chmod 755 /var/www/html
   sudo chmod 644 /var/www/html/index.html
   sudo chown -R www-data:www-data /var/www/html

3. Vhost'ta ve belge kökü altındaki her .htaccess'te bir reddetme kuralı arayın. sudo grep -rn "Require\|Deny from" /etc/apache2/sites-enabled /var/www/html bunları tek geçişte bulur.
4. İstek bir dizin içinse bir indeks dosyası ekleyin veya listelemeyi etkinleştirin. Çıplak bir dizin için 403 vermek varsayılan davranıştır, bir hata değil.
5. Doğru Unix izinlerinin hala yetmediği Red Hat ailesi sistemlerde SELinux'u kontrol edin: ls -Z /var/www/html, sonra sudo restorecon -Rv /var/www/html.
6. Tetiklenen WAF kuralını bulun ve ya isteği düzeltin ya da o kural ve o yol için dar bir istisna ekleyin. Hatayı ortadan kaldırmak için kural setini tamamen kapatmak, bir sorunu daha kötüsüyle takas eder.
7. Bir olay sırasında eklenen aralıklar için engel listesini gözden geçirin. Hiç bir son kullanma tarihi verilmemiş geçici engeller, haftalar sonraki şikayetlerin yaygın bir nedenidir.
8. S3 veya CloudFront için kova politikasını ve kaynak erişimi yapılandırmasını kontrol edin. XML gövdesi reddedilen işlemi adlandırır, ki bu da verilmesi gereken belirli izni işaret eder.

Dışarıdan kontrol edin

Tek bir adrese yönelik bir ret, o adresten bakıldığında tam olarak site geneli bir kesinti gibi görünür, ve ikisini reddedilen makineden ayırt edemezsiniz. Başka bir yerden sorun.

Yanıt başlıkları genellikle yanıt veren katmanı adlandırır. Server'a ve CF-Ray veya X-Amz-Cf-Id gibi satıcı başlıklarına bakın; bunlar size reddin kaynağınızdan mı yoksa ona hiç ulaşmayan bir kenardan mı geldiğini söyler:

curl -sS -D - -o /dev/null https://example.com/page
curl -s -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" https://example.com/page

İkinci komut, birincinin 403 döndürdüğü yerde 200 döndürüyorsa, engel kullanıcı aracısındadır ve izinlerinizde bir sorun yoktur. Sonra aynı URL'ye karşı birkaç ülkedeki kontrol noktalarından aynı anda HTTP kontrolünü çalıştırın. Her konumdan gelen bir 403, sitede bir yapılandırma sorunudur. İki ülkeden 403 ve geri kalanından 200, tek bir masadan tek bir curl ile ulaşamayacağınız bir sonuç olan coğrafi bir kural veya bölgesel bir engel listesidir.

Kastetmediğiniz bir 403'ü yakalamak

Erişim kuralları, sizin tarafınızda hiçbir hata üretmeyen şekillerde bozulur. Bir WAF kural seti güncellenir, bir sertifika yenileme betiği bir yapılandırmayı yeniden yazar, geçici bir engel unutulur, ve site size 200 döndürmeye devam ederken gerçek ziyaretçilerin bir dilimini reddeder. Kendi günlüklerinizde alarm verici hiçbir şey yoktur, çünkü sunucu açısından 403 normal, başarılı bir rettir. 158 şehirdeki 300'den fazla kontrol noktasından durum kodunu okuyan zamanlanmış bir kontrol, bir bölgenin reddedilmeye başladığı günü yakalar, ve e-posta, SMS, sesli arama, Slack, Telegram ve daha fazlasıyla uyarır. Buradaki diğer rehberler düzeltme kümesindedir, ve bu mesajın arkasındaki durum kodunun kendi referansı 403 Forbidden'da bulunur.