ارزیابی و تست امنیت فایروال

بزرگترین حفره امنیتی در شبکه ها، خود فایروال نیست. بلکه تصور غلط مدیران از مفهوم امن بودن است. آنها فکر میکنند چون یک برند معتبر فایروال خریده اند و چراغ هایش سبز است، کار تمام شده. درحالیکه یک Rule اشتباه در تنظیمات، میتواند تمام آن سرمایه گذاری را به باد دهد. این مقاله قرار نیست شما را با تئوری های آکادمیک خسته کند. قرار است دقیقا همان مسیری را برویم که یک مهندس خبره برای ارزیابی واقعی امنیت فایروال طی میکند؛ مسیری که در پروژه های تیم متااندیش بارها آن را پیموده ایم و میدانیم کجای کار بیشتر از همه پول و زمان مشتری هدر میرود.

چرا تست پورت ساده برای ارزیابی امنیت فایروال کافی نیست و عملا فریب میخورید؟

بگذارید با یک خاطره تلخ شروع کنم. سال گذشته برای یک شرکت مالی بزرگ در تهران ارزیابی امنیتی انجام میدادیم. مدیر شبکه شان با افتخار گزارش ShieldsUP را نشانم داد که همه پورت ها را Stealth اعلام کرده بود. او مطمئن بود که فایروالش در اوج امنیت است. اما وقتی یک اسکن تخصصی با پکت های Fragment شده و Timer های سفارشی از سه VPS مختلف اجرا کردیم، پنج پورت مدیریتی باز پیدا شد که ShieldsUP اصلا قادر به دیدنشان نبود. این دقیقا همان جایی است که اعتماد کورکورانه به تست های آنلاین رایگان، فاجعه می آفریند.

تست های سطحی مانند ShieldsUP یا اسکن پورت های رایج صرفا یک Snapshot از وضعیت ظاهری فایروال به شما میدهند. این تست ها پکت های ساده و استاندارد ارسال میکنند و منتظر پاسخ میمانند. مشکل اینجاست که فایروال های مدرن Next-Generation رفتار متفاوتی با ترافیک های مختلف دارند. یک پورت ممکن است در برابر اسکن ساده بسته به نظر برسد، اما وقتی همان پورت با یک Payload خاص در لایه Application هدف قرار بگیرد، کاملا باز و آسیب پذیر باشد. این پدیده را بارها در فایروال هایی دیده ام که IPS شان به درستی Configure نشده بود.

در ارزیابی های تیم متااندیش، ما هرگز به یک ابزار یا یک متد بسنده نمیکنیم. چون میدانیم که تمرکز صرف روی کیفیت ارزیابی و جلوگیری از هدررفت بودجه مشتری، یعنی باید لایه های زیرین را بکاویم، نه اینکه صرفا یک گزارش رنگارنگ تحویل دهیم و برویم. این همان دردی است که بسیاری از مدیران شبکه ایرانی با آن دست و پنجه نرم میکنند: گزارش های امنیتی پرزرق و برقی که هیچ نشانی از واقعیت شبکه شان ندارند.

ارزیابی Rule Base؛ جایی که نود درصد فایروال ها در آن شکست میخورند

اگر از من بپرسید قلب تپنده امنیت فایروال کجاست، بدون تردید میگویم Rule Base. میتوانید بهترین سخت افزار دنیا را داشته باشید، اما اگر قوانین فایروال تان اشتباه نوشته شده باشند، عملا یک درب باز گذاشته اید. بدتر از آن، Rule Base ای که شش ماه پیش نوشته شده و حالا ده ها قانون موقت و استثنا به آن اضافه شده، تبدیل به یک اسپاگتی درهم تنیده میشود که هیچکس جرات دست زدن به آن را ندارد.

یک باور غلط و بسیار مخرب در بازار ایران وجود دارد: اینکه هرچه قوانین بیشتری بنویسم، امنیت بالاتر میرود. این یک افسانه کاملا خطرناک است. قوانین زیاد و بدون مستندسازی، نه تنها امنیت را بالا نمیبرد، بلکه سطح حمله را افزایش میدهد. چرا؟ چون در میان این همه قانون، یک قانون Any-Any که سه ماه پیش برای تست یک نرم افزار اضافه شده و فراموش شده، به راحتی گم میشود. من شخصا در یکی از پروژه های ارزیابی، بعد از چهار ساعت بررسی Rule Base یک سازمان تولیدی، به یک قانون Allow All از یک IP داخلی خاص به تمام اینترنت برخوردم. دلیلش را که پرسیدم، معلوم شد برنامه نویس بخش حسابداری شش ماه پیش برای دانلود یک کتابخانه برنامه نویسی درخواست داده و همان قانون موقت، برای همیشه باز مانده بود.

ارزیابی Rule Base باید این سوالات کلیدی را پاسخ دهد:

• آخرین بار چه زمانی Rule Base به صورت کامل بازبینی شده است؟
• چه تعداد قانون داریم که بیش از شش ماه هیچ ترافیکی از آنها عبور نکرده ؟
• قوانین Shadow شده کدامند؟ یعنی قوانینی که به دلیل قرار گرفتن یک قانون کلی تر بالای سرشان، هرگز به اجرا نمیرسند.
• آیا ترتیب قوانین بر اساس اصل کمترین دسترسی تنظیم شده یا صرفا بر اساس ترتیب زمانی درخواست ها؟
• چه تعداد قانون Any در Source یا Destination داریم که میتوانند محدودتر شوند؟

در تجربه من، بدترین لحظه برای یک مدیر شبکه، ساعت دو نیمه شب است که یک Incident رخ داده، و او باید در میان هزاران قانون فایروال، بگردد و ببیند کدام یک مقصر است. این درد فیزیکیِ کم خوابی و استرس، دقیقا نتیجه نداشتن یک Rule Base تمیز و مستند است. تیم ما در متااندیش بارها این صحنه را از نزدیک دیده و حس کرده ایم.

تست نفوذپذیری فایروال با متدولوژی ترکیبی؛ فراتر از اسکن پورت

حالا که بحث Rule Base روشن شد، برسیم به بخش فنی و عملیاتی ارزیابی. اسکن پورت با Nmap را همه بلدند. اما آنچه یک ارزیابی حرفه ای را از یک اسکن ساده جدا میکند، متدولوژی ترکیبی و تفسیر نتایج است. بگذارید تکنیک های واقعی را گام به گام با شما به اشتراک بگذارم، دقیقا همانطور که در پروژه های واقعی اجرا میکنیم.

Traceroute معکوس و تحلیل مسیر؛ شناسایی دستگاه های خاموش پشت فایروال

قبل از هر اسکنی، باید توپولوژی شبکه را بشناسید. اجرای Traceroute از بیرون به سمت IP عمومی فایروال، اطلاعات ارزشمندی از مسیر و دستگاه های میانی به شما میدهد. اما نکته ای که کمتر کسی به آن توجه میکند: Traceroute را باید از چندین منبع مختلف جغرافیایی اجرا کنید. یک فایروال ممکن است در برابر ترافیک ورودی از اروپا رفتار محتاطانه ای داشته باشد، اما ترافیک ورودی از یک کشور همسایه را راحت تر عبور دهد. این عدم تقارن در رفتار، خودش یک نشانه از پیکربندی ضعیف است.

تکنیک Firewalking که با ابزار Firewalk اجرا میشود، قدم بعدی است. این تکنیک با سوءاستفاده از مکانیزم TTL در بسته های IP، دستگاه های پشت فایروال را شناسایی میکند. عملا شما میتوانید بفهمید که پشت این فایروال، چه سرویس هایی روی چه پورت هایی فعال هستند، حتی اگر فایروال آنها را از دید مستقیم مخفی کرده باشد. این دقیقا همان نقطه کوری است که اسکن های ساده مثل ShieldsUP هرگز نمیتوانند ببینند.

اسکن پورت پیشرفته با Nmap؛ تنظیماتی که تفاوت را میسازند

همه Nmap را با سوئیچ sS- میشناسند. اما چند نفر از شما سوئیچ های زیر را در اسکن های ارزیابی استفاده کرده اید؟

• fragment- mtu 8- : بسته ها را به قطعات هشت بایتی خرد میکند. بسیاری از فایروال ها و IDS ها در بازسازی این قطعات کوچک شکست میخورند و ترافیک مخرب را عبور میدهند.
• scan-delay 1s- : بین هر Probe یک ثانیه تاخیر میگذارد. اسکن های سریع، هشدارهای فایروال را فعال میکنند. اسکن آهسته و Patient، شانس شناسایی را بالا میبرد.
• source-port 53- : ترافیک اسکن را طوری نشان میدهد که گویی از پورت ۵۳ (DNS) آمده. بسیاری از فایروال ها به ترافیک ورودی از پورت های شناخته شده اعتماد میکنند و این یک ضعف مهلک است.
• data-length 200- : بسته ها را با داده تصادفی پر میکند تا از الگوهای تشخیص امضای IDS فرار کند.

ترکیب این سوئیچ ها با یکدیگر، یک اسکن کاملا متفاوت از اسکن پیش فرض Nmap ایجاد میکند. در یکی از ارزیابی های اخیر برای یک دیتاسنتر در اصفهان، اسکن معمولی Nmap فقط ۳ پورت باز نشان داد. اما اسکن Fragment شده با سورس پورت ۵۳، تعداد پورت های باز را به ۱۱ رساند. تفاوتی که میتوانست به قیمت یک نفوذ کامل تمام شود.

این جدول را بارها در جلسات فنی با مشتریان به کار برده ام تا نشان دهم که انتخاب متد اسکن، مستقیما روی نتیجه ارزیابی تاثیر میگذارد. یک ارزیابی که فقط از اسکن SYN استفاده میکند، عملا بخشی از واقعیت را نمیبیند.

Banner Grabbing و اثر انگشت نگاری سرویس ها

پیدا کردن پورت باز کافی نیست. باید بدانید پشت آن پورت دقیقا چه سرویسی و با چه ورژنی در حال اجراست. Banner Grabbing با Netcat یا ابزارهای تخصصی تر مثل Amap این اطلاعات را فاش میکند. چرا این کار حیاتی است؟ چون بسیاری از اوقات، مدیر شبکه فکر میکند پورت ۴۴۳ فقط برای وب سرور اصلی باز است، درحالیکه همان پورت ۴۴۳ روی یک IP دیگر، به interface مدیریتی iLO یا iDRAC سرور متصل است که ورژن قدیمی و آسیب پذیر دارد. این نوع کشف ها، دقیقا همان لحظاتی هستند که ضربان قلب یک مهندس امنیت را بالا میبرند.

دردسر اجرایی واقعی اینجاست: خیلی از سازمان ها حتی یک Inventory دقیق از سرویس های خارج از سازمان خود ندارند. وقتی ارزیابی را شروع میکنیم، خودشان هم نمیدانند چه چیزهایی به اینترنت اکسپوز شده. این سردرگمی و فقدان دید، دقیقا همان چیزی است که مهاجمان از آن سوءاستفاده میکنند. تیم متااندیش در پروژه های ارزیابی، گاهی تا ۳۰ درصد سرویس های بیشتری نسبت به آنچه مشتری تصور میکرد پیدا کرده است.

تست کانال های مخفی و تونل های فرار از فایروال

حالا میرسیم به بخشی که کمتر کسی در ارزیابی های معمولی به آن میپردازد، اما پیشرفته ترین حملات از همین مسیر عبور میکنند. کانال های مخفی مسیرهایی هستند که ترافیک غیرمجاز را در دل پروتکل های مجاز جاسازی میکنند. برای مثال، تونل کردن ترافیک SSH درون بسته های DNS (با ابزارهایی مثل iodine یا dnscat2) یا انتقال داده درون فیلدهای Header پروتکل HTTP.

چطور باید فایروال را در برابر این تکنیک ها ارزیابی کرد؟

اول، باید Policy فایروال در برابر پروتکل DNS را بررسی کنید. اگر فایروال شما به تمام کلاینت های داخلی اجازه میدهد که به هر سرور DNS خارجی درخواست بدهند، عملا یک بزرگراه برای خروج داده ساخته اید. تست عملی این است: از یک کلاینت داخلی، ابزار iodine را اجرا کنید و ببینید آیا میتوانید یک تونل DNS به یک سرور خارجی برقرار کنید. اگر موفق شدید، فایروال شما در این لایه شکست خورده است.

دوم، Deep Packet Inspection یا DPI باید روی پروتکل های خروجی فعال باشد. بسیاری از فایروال های NGFW قابلیت شناسایی تونل های DNS و HTTP را دارند، اما این قابلیت ها معمولا به صورت پیش فرض فعال نیستند و نیاز به تنظیم دستی دارند. ما بارها دیده ایم که سازمانی یک فایروال گران قیمت با قابلیت های فوق العاده خریده، ولی عملا از ده درصد توان امنیتی آن استفاده میکند. این دقیقا مصداق هدررفت بودجه است که متااندیش ماموریت خود را جلوگیری از آن میداند.

ارزیابی امنیت فایروال در برابر حملات لایه Application

فایروال های سنتی Stateful در لایه ۳ و ۴ کار میکنند. اما حملات امروزی، لایه ۷ را هدف میگیرند. SQL Injection، Cross-Site Scripting، و Command Injection همگی از پورت های مجاز (مثل ۸۰ و ۴۴۳) عبور میکنند و فایروال سنتی هیچگاه آنها را بلاک نمیکند. اینجاست که WAF یا ماژول IPS فایروال باید وارد عمل شود.

برای ارزیابی این لایه، باید سناریوهای حمله واقعی را شبیه سازی کنید. ابزارهایی مثل sqlmap برای تست تزریق SQL، و ابزارهای Fuzzing برای ارسال داده های ناهنجار به وب سرور، بخشی از این فرایند هستند. نکته کلیدی: ارزیابی را حتما با IPS روشن و خاموش انجام دهید تا متوجه شوید که IPS شما واقعا چه میزان از حملات را شناسایی و بلاک میکند.

در یکی از پروژه ها برای یک فروشگاه اینترنتی بزرگ، ما متوجه شدیم که IPS فایروال آنها با وجود اینکه روشن بود، به دلیل آپدیت نبودن Signature ها، بیش از ۶۰ درصد حملات شبیه سازی شده SQL Injection را عبور میداد. مدیر شبکه با دیدن نتایج، رنگ از چهره اش پرید. او ماه ها بود که با خیال راحت گزارش های روزانه IPS را میدید و فکر میکرد همه چیز تحت کنترل است. اما Signature هایی که دو سال از آخرین آپدیتشان میگذشت، عملا هیچ ارزش امنیتی نداشتند.

تست عملکرد و پایداری فایروال تحت فشار؛ امنیتی که با ترافیک سنگین ذوب میشود

یک جنبه کاملا مغفول در ارزیابی امنیت فایروال، تست عملکرد تحت بار ترافیکی بالاست. بسیاری از فایروال ها وقتی تحت فشار ترافیک قرار میگیرند، رفتار غیرقابل پیش بینی از خود نشان میدهند. بعضی از آنها وارد حالت Fail-Open میشوند (یعنی برای اینکه شبکه قطع نشود، تمام ترافیک را عبور میدهند). بعضی دیگر شروع به Drop کردن تصادفی پکت ها میکنند که خودش یک فاجعه برای سرویس های حساس است.

برای تست این سناریو، باید ترافیک مصنوعی با حجم بالا تولید کنید و همزمان یک اسکن امنیتی اجرا کنید. ابزارهایی مثل hping3 با فلگ flood- میتوانند پکت های SYN با نرخ بسیار بالا تولید کنند. هدف این نیست که فایروال را از کار بیندازید، بلکه میخواهید ببینید در آستانه ظرفیت، رفتار امنیتی آن چگونه تغییر میکند.

در یک ارزیابی برای یک ISP متوسط، ما متوجه شدیم که فایروال آنها در بار بالای ۸۰ درصد ظرفیت، عملا IPS خود را غیرفعال میکند تا بتواند Throughput را حفظ کند. این یک تصمیم طراحی در firmware بود که هیچکس از آن خبر نداشت. یعنی درست در زمان هایی که شبکه تحت فشار بود (مثلا زمان اوج مصرف کاربران)، امنیت عملا وجود نداشت. این نوع کشف ها، دقیقا همان ارزش افزوده ای است که یک ارزیابی عمیق و مهندسی شده به همراه دارد.

کدام ابزارهای ارزیابی فایروال واقعا ارزش وقت گذاشتن دارند؟

بازار پر است از ابزارهای رنگارنگ با رابط کاربری زیبا که قول ارزیابی کامل فایروال را میدهند. اما واقعیت این است که ابزار، فقط به اندازه شخصی که آن را به کار میبرد ارزش دارد. در ادامه، ابزارهایی را معرفی میکنم که واقعا در میدان عمل جواب داده اند، نه صرفا در دموهای فروش:

• Nmap: استاندارد طلایی اسکن پورت. اگر فقط یک ابزار میتوانستید داشته باشید، همین باشد. اما به شرطی که سوئیچ های پیشرفته اش را بشناسید.
• Metasploit Framework: برای شبیه سازی حملات واقعی و تست نفوذپذیری لایه Application. ماژول های آماده آن برای انواع آسیب پذیری ها، کار را تسریع میکند.
• Wireshark: برای تحلیل پکت و بررسی اینکه فایروال دقیقا چه تصمیمی روی بسته ها گرفته. هیچ چیز جای دیدن خود پکت ها را نمیگیرد.
• Firewalk: تخصصی برای شناسایی توپولوژی پشت فایروال. قدیمی است اما همچنان در بسیاری از سناریوها کار میکند.
• Nipper: برای تحلیل خودکار پیکربندی فایروال و شناسایی اشکالات امنیتی در Rule Base. مخصوصا برای فایروال های Cisco ASA و Juniper عالی است.
• RedSeal: اگر بودجه دارید و شبکه پیچیده ای دارید، این ابزار میتواند مدل ریاضی از دسترسی پذیری شبکه شما بسازد و مسیرهای حمله را شبیه سازی کند.

اما هشدار مهم: ابزارپرستی آفت ارزیابی امنیت است. هیچ ابزاری جای تحلیل انسانی و درک زمینه را نمیگیرد. من بارها دیده ام که یک مهندس تازه کار با یک اسکنر خودکار، گزارش پر از False Positive تحویل داده و مشتری را بیهوده نگران کرده. درحالیکه یک مهندس باتجربه، با همان Nmap ساده، نتایج را به درستی تفسیر کرده و مسائل واقعی را شناسایی کرده است. در متااندیش، ما معتقدیم که تمرکز بر کیفیت تحلیل و جلوگیری از هدررفت بودجه مشتری، یعنی اولویت دادن به تخصص انسانی در کنار ابزارهای قدرتمند، نه جایگزینی آن.

افسانه فایروال گران یعنی امنیت بالا را کنار بگذارید

وقتی یک سازمان چند صد میلیون تومان برای یک فایروال خارجی هزینه میکند، یک حس امنیت کاذب در کل تیم فنی ایجاد میشود. انگار که صرف خرید یک برند معتبر، یک سپر جادویی دور سازمان میکشد. این بزرگترین دروغی است که فروشنده های تجهیزات به شما گفته اند.

یک فایروال Fortinet یا Palo Alto به اندازه تنظیماتش ارزش دارد، نه به اندازه برندش. من در کارنامه حرفه ای خود، هم فایروال های Enterprise را دیده ام که به دلیل پیکربندی فاجعه بار، از یک روتر خانگی هم بی دفاع تر بودند، و هم فایروال های opensource مثل pfSense را دیده ام که با تنظیمات دقیق و هوشمندانه، امنیت قابل قبولی فراهم کرده بودند. انتخاب بین این دو، یک Trade-off است: فایروال Enterprise امکانات بیشتر، پشتیبانی بهتر، و Throughput بالاتر میدهد، اما پیچیدگی بیشتر و نیاز به تخصص بالاتر برای تنظیم را هم به همراه دارد. فایروال opensource هزینه کمتر و انعطاف بیشتر دارد، اما مسئولیت پشتیبانی و به روزرسانی کاملا با شماست. هیچکدام ذاتا بد یا خوب نیستند، بلکه تناسب با نیاز و بودجه سازمان تعیین کننده است.

درد واقعی مشتریان ایرانی در این حوزه، فقط خرید تجهیزات نیست. درد اصلی، پیدا کردن تیم یا شرکتی است که واقعا بلد باشد این تجهیزات را به درستی پیاده سازی، تنظیم و نگهداری کند. بارها دیده ام که یک سازمان، یک فایروال فوق پیشرفته خریده، اما چون شرکت مجری صلاحیت کافی نداشته، تنظیمات اولیه را با حالت Wizard و پیش فرض انجام داده و رفته. نتیجه؟ یک فایروال چند صد میلیونی که عملا مثل یک روتر ساده کار میکند.

چک لیست اجرایی ارزیابی امنیت فایروال

وقتی به انتهای یک ارزیابی میرسیم، چیزی که بیش از گزارش های بلندبالا به کار مدیران می آید، یک برنامه اقدام مشخص و الویت بندی شده است. این چک لیست را دقیقا به همان شکلی مینویسم که در پروژه های متااندیش به مشتریان تحویل میدهیم:

1. مستندسازی کامل Rule Base: هر قانون فایروال باید یک Owner، یک هدف مشخص، و یک تاریخ انقضا داشته باشد. قوانین بدون این سه مولفه را حذف یا بازبینی کنید. این کار شاید یک روز کامل وقت ببرد، اما ارزشش را دارد.
2. اسکن کامل ۶۵۵۳۵ پورت از سه منبع جغرافیایی متفاوت: با Nmap و سوئیچ های Fragment و Source Port متنوع. نتایج را با Rule Base تطبیق دهید و هر مغایرت را فورا بررسی کنید.
3. تست نفوذپذیری لایه Application روی تمام سرویس های اکسپوز شده: با Metasploit یا ابزارهای مشابه، سناریوهای حمله رایج را شبیه سازی کنید. اگر IPS دارید، حتما یک بار با IPS روشن و یک بار خاموش تست کنید.
4. بررسی وضعیت آپدیت Signature ها و Firmware فایروال: اطمینان حاصل کنید که تمام Signature های امنیتی حداقل طی یک ماه گذشته آپدیت شده اند. Firmware ای که بیش از شش ماه از آخرین آپدیت آن میگذرد، یک ریسک جدی است.
5. تست بازیابی و Failover: یک سناریوی قطع برق یا خرابی لینک را شبیه سازی کنید و ببینید رفتار Failover فایروال چگونه است. آیا واقعا بدون قطعی و بدون باز شدن ناخواسته پورت ها، مسیر ثانویه فعال میشود؟

سوالات متداول قبل از تصمیم گیری برای ارزیابی

آیا میتوانیم ارزیابی امنیت فایروال را خودمان با ابزارهای رایگان انجام دهیم؟

بله، میتوانید. اما باید بدانید که تفسیر نتایج اسکن ها و شناسایی False Positive ها نیاز به تجربه عملی دارد. اگر تیم داخلی شما تجربه کافی در تست نفوذ و تحلیل پکت دارد، ابزارهای رایگان مثل Nmap و Wireshark کاملا کار راه انداز هستند. اما اگر این تخصص را ندارید، خروجی یک اسکنر خودکار میتواند بیشتر از اینکه کمک کند، گمراه کننده باشد.

هر چند وقت یک بار باید فایروال را ارزیابی کنیم؟

حداقل یک ارزیابی کامل سالانه و یک ارزیابی سبک هر سه ماه. اما بعد از هر تغییر عمده در شبکه (اضافه شدن سرویس جدید، تغییر Rule Base، یا یک Incident امنیتی) باید یک ارزیابی موضعی انجام دهید. فایروال یک موجود زنده است که با هر تغییر پیکربندی، رفتارش عوض میشود.

آیا ارزیابی امنیتی باعث اختلال در شبکه میشود؟

اگر اصولی انجام شود، خیر. اما اسکن های تهاجمی با نرخ بالا میتوانند باعث کندی یا حتی قطعی موقت سرویس ها شوند. به همین دلیل، ارزیابی باید در یک پنجره زمانی مشخص و با هماهنگی کامل انجام شود. ما در متااندیش همیشه یک Plan B برای بازگشت سریع به حالت قبل داریم.

تفاوت ارزیابی فایروال با تست نفوذ چیست؟

تست نفوذ یک قدم فراتر از ارزیابی فایروال است. در ارزیابی فایروال، تمرکز بر بررسی پیکربندی، Rule Base، و رفتار فایروال در برابر ترافیک های مختلف است. اما تست نفوذ، یک حمله کامل شبیه سازی شده است که هدفش نفوذ واقعی به شبکه و دسترسی به دارایی های اطلاعاتی است. ارزیابی فایروال زیرمجموعه ای از تست نفوذ محسوب میشود.

اگر بودجه محدودی داریم، از کجا شروع کنیم؟

اولویت اول: بازبینی و پاکسازی Rule Base. این کار تقریبا هیچ هزینه ای جز زمان ندارد و بیشترین تاثیر امنیتی را دارد. اولویت دوم: یک اسکن پورت کامل با Nmap از یک VPS خارجی. اولویت سوم: بررسی آپدیت بودن Firmware و Signature ها. این سه گام، بیشترین بازدهی را با کمترین هزینه دارند.

آیا فایروال های ایرانی هم نیاز به ارزیابی دارند؟

قطعا. امنیت فایروال ربطی به کشور سازنده ندارد، بلکه به پیکربندی و نگهداری آن مربوط است. فایروال های ایرانی هم دقیقا به همان اندازه نیاز به Rule Base Review، تست نفوذپذیری، و بررسی مداوم دارند. ضمن اینکه برخی از آنها از پلتفرم های opensource استفاده میکنند که خودشان نیازمند دقت بیشتری در تنظیمات هستند.

چطور بفهمیم که نتیجه ارزیابی معتبر است و False Positive نیست؟

اعتبارسنجی نتایج، مهمترین بخش ارزیابی است. هر یافته باید با حداقل دو روش مختلف تایید شود. مثلا اگر اسکنر میگوید پورت ۲۲ باز است، حتما با یک Telnet یا Netcat دستی به آن پورت متصل شوید و پاسخ را ببینید. False Positive ها معمولا از پاسخ های غیرعادی فایروال یا دستگاه های میانی ناشی میشوند و فقط با بررسی دستی قابل تشخیص هستند.