محتوای آموزشی وبلاگ نت‌آرام
Suhosin قدیمی برای سخت‌گیری بیشتر روی بعضی رفتارهای PHP معرفی شده بود. اما برنامهٔ ساخته‌شده برای یک نسل قدیمی PHP، الزاماً روی نسخهٔ فعلی اجرا نمی‌شود. اسم مشابه Suhosin-NG نیز به معنی یکسان بودن سازگاری و روش نصب نیست.
به‌جای نصب یک ابزار قدیمی، مشکل مشخص را حل کنیم
فرض کنید هدف شما جلوگیری از دسترسی یک سایت به فایل‌های حساب دیگر است. ابتدا جداسازی حساب‌ها و مالکیت فایل‌ها را بررسی کنید. اگر هدف جلوگیری از اجرای فایل آپلودشده است، محل آپلود و امکان اجرای PHP در آن پوشه اهمیت دارد. اگر مشکل افزونهٔ آسیب‌پذیر است، نسخهٔ سالم و به‌روزرسانی خود افزونه لازم است. نصب یک نام امنیتی واحد، جای این کارهای مشخص را نمی‌گیرد.
مدیر باید نسخهٔ PHP همان سایت و پشتیبانی رسمی ابزار انتخابی را ببیند. پیش از تغییر روی همهٔ حساب‌ها، یک سایت نمونه را با ورود، آپلود و ذخیرهٔ داده امتحان کند. اگر یک ابزار برای نسخهٔ فعلی پشتیبانی نمی‌شود، دستور نصب قدیمی را نباید به زور روی آن اجرا کنیم.
اول محیط اجرای PHP را بشناسید
ممکن است PHP سایت با PHP خط فرمان متفاوت باشد. نسخهٔ مؤثر هر دامنه، مدل اجرای آن و افزونه‌های فعال را از تنظیمات پنل و برنامه بررسی کنید. اگر سرور چند نسخهٔ PHP دارد، باید روشن باشد تغییر قرار است روی کدام نسخه اعمال شود. فعال شدن افزونه در یک نسخه به معنی فعال شدن آن برای همهٔ حساب‌ها نیست.
بعضی افزونه‌ها به نسخهٔ مشخص یا روش ساخت خاص نیاز دارند. پیش از نصب، فهرست نسخه‌های پشتیبانی‌شده و وضعیت انتشار پروژه را بخوانید. نام Suhosin قدیمی و پروژهٔ Suhosin-NG نیز نباید بدون بررسی سازگاری یکسان فرض شوند. در نصب تولیدی، از بستهٔ ناشناس یا دستور مربوط به PHP ده سال قبل استفاده نکنید.
امنیت را از نیاز برنامه شروع کنید
برای یک سایت وردپرسی، به‌روز بودن هسته و افزونه، استفاده از بستهٔ رسمی، محدود کردن دسترسی مدیریت و حفظ بکاپ قابل بازیابی اهمیت عملی دارد. برای برنامهٔ اختصاصی، اعتبارسنجی ورودی، دسترسی صحیح به دیتابیس و جلوگیری از اجرای فایل آپلودی نیز باید در خود برنامه و تنظیم وب‌سرور بررسی شود. افزونهٔ PHP جای این کارها را نمی‌گیرد.
اگر هدف محدود کردن قابلیت خاصی است، ابتدا مشخص کنید برنامه واقعاً از آن استفاده می‌کند یا خیر. خاموش کردن گروهی توابع ممکن است پردازش تصویر، ارسال ایمیل یا کار زمان‌بندی را از کار بیندازد. بهتر است تغییر محدود را در محیط آزمایشی انجام دهید و مسیرهای وابسته را امتحان کنید.
آزمایش قبل از تغییر سرور اصلی
یک محیط با نسخهٔ مشابه PHP آماده کنید و برنامه را همراه با دادهٔ آزمایشی در آن اجرا کنید. پس از تغییر، ورود مدیر، ذخیرهٔ داده، بارگذاری فایل، پردازش تصویر و کارهای پس‌زمینه را بررسی کنید. خطاهای تازه را با زمان اعمال تغییر تطبیق دهید تا محدودیت امنیتی با خطای قدیمی برنامه اشتباه گرفته نشود.
اگر نصب یک افزونهٔ سخت‌سازی انتخاب نهایی شماست، دستور ساخت و تنظیم را از پروژه و روش پشتیبانی‌شدهٔ پنل بگیرید. تنظیمات سفارشی باید در مسیر پایدار نگهداری شوند تا بازسازی PHP آن‌ها را بی‌خبر حذف نکند. نسخهٔ قبل از تغییر و مسیر برگشت را تا پایان بررسی نگه دارید.
چه زمانی تغییر موفق است؟
موفقیت فقط نمایش نام افزونه در فهرست PHP نیست. باید محدودیت موردنظر واقعاً اعمال شود و کارکرد لازم برنامه نیز حفظ شده باشد. اگر نتیجهٔ آزمایش قابل اندازه‌گیری نیست، ابتدا هدف را دقیق‌تر تعریف کنید. امنیت قابل نگهداری از مجموعهٔ تصمیم‌های مشخص و آزموده‌شده به دست می‌آید، نه از انباشتن افزونه‌ها و فرمان‌های قدیمی.
منابع و ادامهٔ مطالعه
مقاله قبلی
ساخت دیتابیس در دایرکت ادمین
۲۱ بهمن ۱۳۹۴مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام