محتوای آموزشی وبلاگ نتآرام
دامنه را باز میکنید و بهجای سایت پیام 403 Forbidden یا «دسترسی ممنوع است» میبینید. این کد یعنی درخواست به یک سامانه پاسخگو رسیده و آن سامانه اجازه دسترسی به درخواست موردنظر را نداده است. دلیل آن میتواند مجوز فایل، نبود صفحه آغازین، تنظیم دامنه، قانون امنیتی یا حتی محدودیتی باشد که عمداً برای آن مسیر گذاشته شده است.
پیش از تغییر هر تنظیمی، باید بفهمیم خطا برای کدام نشانی و کدام کاربر رخ میدهد و چه لایهای آن را صادر کرده است. غیرفعالکردن همه قوانین امنیتی یا بازکردن مجوز همه فایلها ممکن است خطا را پنهان کند و مشکل بزرگتری بسازد.
قدم اول: محدوده مشکل را مشخص کنید
نشانی کامل، زمان و متن صفحه خطا را یادداشت کنید. آیا فقط صفحه اصلی خطا دارد یا یک عکس، پوشه و صفحه داخلی هم همین وضعیت را دارند؟ آیا مدیر سایت در پیشخوان دسترسی دارد اما بازدیدکننده عمومی نه؟ نام با و بدون www و
http و https را نیز جداگانه در نظر بگیرید؛ دامنه و پروتکل متفاوت ممکن است از مسیر یا تنظیم متفاوتی عبور کنند.در یک مرورگر خصوصی و در صورت امکان یک اینترنت دیگر همان نشانی را آزمایش کنید. اگر فقط یک شبکه یا کاربر خطا میبیند، محدودیت IP، فایروال برنامه یا حساب کاربری میتواند مطرح باشد. اگر همه کاربران و همه صفحات خطا میبینند، مسیر دامنه یا تنظیم عمومی سایت را هم بررسی کنید. این مقایسه علت نهایی را ثابت نمیکند، ولی محدوده جستوجو را کوچک میکند.
اگر ۴۰۳ فقط هنگام ذخیره نوشته در ویرایشگر وردپرس رخ میدهد، راهنمای خطای 401 و 403 در REST API وردپرس مسیر تخصصی آن درخواست را توضیح میدهد. پیام صفحه عمومی سایت با خطای یک درخواست داخلی یکسان نیست.
قدم دوم: ببینید پاسخ از کجا آمده است
اگر سایت از CDN، فایروال برنامه وب یا سرویس امنیتی عبور میکند، صفحه ۴۰۳ ممکن است توسط آن لایه صادر شود، نه هاست اصلی. نام سرویس، شناسه رخداد و زمان را از صفحه خطا یادداشت کنید. برای بررسی، اطلاعات حساس حساب، کوکی یا رمز را در تصویر عمومی نفرستید.
مدیر فنی میتواند از رایانه خود پاسخ همان نشانی را با یک درخواست معمولی و بدون نمایش بدنه ببیند:
کد / دستورcurl -sS -o /dev/null -D - https://example.com/
نام نمونه را با دامنه واقعی عوض کنید. خط اول وضعیت HTTP و خطهای بعد سربرگ پاسخ را نشان میدهند. این خروجی ممکن است درباره سرویس میانی سرنخ بدهد، اما از روی یک سربرگ نمیتوان همیشه صادرکننده را قطعی تشخیص داد. اگر فرمان با خطای گواهی مواجه شد، اعتبار گواهی را درست کنید و گزینه غیرفعالکردن کنترل TLS را برای عبور از هشدار اضافه نکنید.
اگر پاسخ برای مرورگر و فرمان متفاوت است، تفاوت حساب واردشده، کوکی، شبکه و مسیر درخواست را در نظر بگیرید. دستکاری User-Agent یا دورزدن قانون امنیتی بدون شناخت آن، علت اصلی را حل نمیکند.
قدم سوم: اتصال دامنه و پوشه سایت را ببینید
در سیپنل به Domains بروید و نام دامنه و Document Root یا پوشه متصل به آن را بخوانید. در DirectAdmin مسیر و نام گزینهها با نسخه متفاوت است. سپس در File Manager همان پوشه را باز کنید. اگر دامنه به پوشه اشتباه وصل است، پیش از تغییر مسیر اثر آن بر سایتهای دیگر و نسخه پشتیبان را بررسی کنید. حذف و افزودن دوباره دامنه بدون تشخیص میتواند تنظیمات وابسته را تغییر دهد.
برای صفحه اصلی، معمولاً وبسرور باید فایل آغازین مناسب، مانند
index.php یا index.html، را مطابق تنظیم خود پیدا کند. اگر پوشه خالی است یا فایل آغازین در جای دیگری قرار گرفته و نمایش فهرست پوشه ممنوع است، ممکن است پاسخ ۴۰۳ دیده شود. فایل درست را از محل معتبر یا نسخه پشتیبان تأییدشده به مسیر مناسب برگردانید؛ یک فایل ناشناس را برای رفع موقت خطا نصب نکنید.اگر ۴۰۳ فقط برای پوشهای است که قرار نبوده عمومی باشد، مسدودبودن آن میتواند درست و مطلوب باشد. برای مثال، بازشدن عمومی فایل بکاپ خطرناک است؛ راهنمای محافظت از بکاپ سایت دلیل آن را توضیح میدهد. قبل از بازکردن دسترسی، تصمیم بگیرید آن فایل واقعاً باید برای همه قابل مشاهده باشد یا نه.
قدم چهارم: مجوز و مالکیت همان فایل مشکلدار
در File Manager، فایل یا پوشه موردنظر را انتخاب و گزینه مجوزها یا Permissions را ببینید. در بسیاری از هاستهای لینوکسی، فایل معمولی با ۶۴۴ و پوشه با ۷۵۵ نمونههای رایج هستند، اما مقدار درست به کاربر اجرای وبسرور، مالکیت، تنظیمات سرویس و حساسیت فایل بستگی دارد. این اعداد قانون همگانی برای همه فایلها و همه سرورها نیستند.
اگر پس از انتقال، مالکیت یا مجوز همان فایل با تنظیم سرویس ناسازگار شده، مدیر هاست باید مالک و مجوز درست را برای همان مسیر تعیین کند. روی کل سایت دستور بازگشتی با حدس اجرا نکنید و همه چیز را ۷۷۷ نگذارید. مجوز بیش از حد باز ممکن است امکان تغییر یا افشای اطلاعات را ایجاد کند. راهنمای cPanel درباره خطاهای HTTP نیز مجوز فایل را یکی از علتهای قابل بررسی ۴۰۳ میداند.
اگر سایت وردپرسی فایلهای رسانه را نمیسازد، موضوع میتواند مجوز، مالکیت یا سیستمفایل فقطخواندنی باشد؛ راهنمای خطای پوشه uploads برای آن وضعیت مناسبتر است.
قدم پنجم: قانون امنیتی یا تنظیم وبسرور را جدا کنید
اگر خطا پس از فعالشدن WAF، افزونه امنیتی یا تغییر فایل تنظیمات وبسرور شروع شده، زمان و شناسه درخواست را با گزارش همان ابزار تطبیق دهید. مدیر میتواند قانون مشخص و دلیل فعالشدن آن را ببیند و اگر مثبت کاذب است، استثنای محدود و مستند برای همان مورد یا اصلاح درخواست را بررسی کند. خاموشکردن کل WAF روی سایت فعال، بدون شناخت قانون و برنامه بازگشت، محافظت سایر بخشها را هم از بین میبرد.
فایلهایی مانند
.htaccess ممکن است قواعد دسترسی یا بازنویسی داشته باشند. قبل از ویرایش، نسخه فعلی را نگه دارید و تغییر را ابتدا در محیط آزمایشی انجام دهید. روی Nginx این فایل به شکل Apache تفسیر نمیشود؛ نسخه، وبسرور و پیکربندی واقعی اهمیت دارند. اگر به گزارش یا تنظیم سرور دسترسی ندارید، دامنه، نشانی دقیق، زمان، شبکه و شناسه رخداد را برای پشتیبانی هاست بفرستید.پس از اصلاح، هم دسترسی و هم حفاظت را امتحان کنید
همان صفحه عمومی را از مرورگر خصوصی و یک شبکه دیگر باز کنید و مطمئن شوید محتوای مورد انتظار نمایش داده میشود. سپس یک مسیر خصوصی که عمداً باید محافظت شود را با روش مناسب بررسی کنید تا تغییر، دسترسی اضافی ایجاد نکرده باشد. اگر CDN یا کش فعال است، پاسخ هر مسیر را با زمان تغییر مقایسه کنید.
برای مشاهده مشخصات میزبانی میتوانید صفحه هاست وردپرس نتآرام را ببینید. علت ۴۰۳ باید بر اساس درخواست و گزارش واقعی همان سایت تعیین شود؛ یک تغییر عمومی برای همه موارد مناسب نیست.
برچسبها:
اشتراکگذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاهها (۰)
دیدگاههای تاییدشده و پاسخهای تیم نتآرام
