فایروال چیست؟ فایروال یا دیوارهٔ آتش، ارتباطات عبوری از محدودهٔ خود را بر اساس سیاست تعریفشده مجاز یا مسدود میکند. این ابزار همهٔ خطرها را خودکار تشخیص نمیدهد و جای بهروزرسانی برنامه، کنترل حسابها یا نسخهٔ بازیابی را نمیگیرد.
نحوهٔ تصمیمگیری فایروال چیست؟
قاعده میتواند به مبدأ و مقصد، پروتکل، پورت، وضعیت اتصال یا ویژگیهای سطح برنامه وابسته باشد. قابلیت دقیق به محصول و محل استقرار بستگی دارد. ترافیکی که از فایروال عبور نمیکند، لزوماً تحت کنترل همان قواعد نیست.
برای نمونه، اجازهٔ اتصال به پورت وب یعنی آن مسیر شبکه باز است؛ به معنی سالمبودن هر درخواست وب یا مجازبودن هر کاربر نیست. اگر برنامه روی پورت دیگری گوش میدهد، بازکردن پورت پیشفرض بهتنهایی دسترسی مورد نظر را ایجاد نمیکند.
انواع بر اساس روش بررسی
- فیلتر بسته: با مشخصات بسته مانند IP، پورت و پروتکل تصمیم میگیرد.
- Stateful: وضعیت ارتباط را هم در ارزیابی بسته لحاظ میکند.
- پراکسی کاربردی: در نقش واسط، ارتباط و درخواست سازگار را بررسی میکند.
- نسل بعدی: ممکن است شناسایی برنامه، جلوگیری از نفوذ و قابلیتهای تکمیلی داشته باشد.
معرفی انواع فایروال در Cisco تفاوت این قابلیتها را شرح میدهد. برچسب نسل بعدی به معنی بررسی کامل هر محتوای رمزگذاریشده یا تضمین مسدودشدن همهٔ حملهها نیست؛ پیکربندی و امکان مشاهدهٔ ترافیک اهمیت دارد.
میزبان، شبکه یا ابر؟
فایروال میزبان روی همان سیستم اعمال میشود. فایروال شبکه مرز میان بخشها را کنترل میکند و سرویس ابری میتواند قواعد را در زیرساخت ارائهدهنده اعمال کند. سختافزاری یا نرمافزاریبودن، محور دیگری از دستهبندی است؛ این نامها همیشه گزینههای کاملاً جدا از هم نیستند.
در اوبونتو، UFW یکی از ابزارهای مدیریت فایروال میزبان است. مستند رسمی اوبونتو روش کار آن را توضیح میدهد. روی سرور دارای پنل مدیریت یا ابزار تنظیم قواعد دیگر، ابتدا مشخص کنید کدام بخش مالک تنظیمات است تا چند ابزار روی هم اثر نگذارند.
تفاوت فایروال شبکه و WAF
WAF روی درخواستهای برنامهٔ وب تمرکز دارد؛ برای مثال میتواند بعضی الگوهای مخرب HTTP را تشخیص دهد. شرح AWS WAF این محدوده را مشخص میکند. اجازهٔ TCP روی پورت 443 با تحلیل محتوای یک درخواست وب یکسان نیست.
WAF کد ناامن را اصلاح نمیکند و فایروال میزبان نیز لزوماً از اشباع لینک بالادستی جلوگیری نمیکند. برای حملهٔ حجمی باید مسیر شبکه و سرویس کاهش حمله بررسی شود. کنترلهای مختلف باید با یکدیگر هماهنگ باشند.
پیش از تغییر قواعد سرور
پورت و مبدأ مدیریت، سرویسهای ضروری و راه دسترسی جایگزین را مشخص کنید. تغییر را مرحلهای اعمال و با یک اتصال جدید آزمایش کنید؛ بازماندن نشست قدیمی اثبات نمیکند اتصال تازه مجاز است. IPv4 و IPv6 و قواعد ارائهدهندهٔ زیرساخت را جداگانه در نظر بگیرید.
برای هر قاعده دلیل و مسئول بازبینی داشته باشید. در صورت پشتیبانی، ابتدا حالت ثبت یا شمارش را برای قاعدهٔ جدید به کار ببرید و اثر بر کاربران واقعی را بسنجید. زیادبودن تعداد قواعد یا بازبودن همهٔ پورتها برای رفع فوری خطا، نشانهٔ پیکربندی مناسب نیست.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شدهاند.