خروجی اسکنر را باز کرده‌اید و ۴۷ مورد قرمز زیر چشم‌تان است. یکی از آنها «Critical» است و ساعت ۱۱ شب است. سؤال واقعی این نیست که اسکنر چه گفت؛ سؤال این است که از این ۴۷ مورد، کدام‌یک واقعاً روی سرور شما قابل بهره‌برداری است. اگر همین حالا شروع کنید به بستن همه‌شان به ترتیب حروف الفبا، دو روز وقت می‌گذارید و ممکن است حفره اصلی دست‌نخورده بماند.
اسکن آسیب پذیری یک عکس لحظه‌ای است، نه تشخیص. ابزار فقط می‌گوید «نسخه‌ای که دیدم، الگویش با یک CVE شناختهشده جور است». این با «این سرور قابل نفوذ است» فاصله دارد. کل کار شما در روز اول، تبدیل آن ادعا به یک بله یا خیر قابل دفاع است.
قبل از اسکن، محدوده را روی کاغذ بیاورید
اسکنر بدون محدوده، فقط نویز تولید میکند. سه چیز را قبل از اولین اجرا مشخص کنید: دامنه‌ها و زیردامنه‌هایی که مالکشان هستید، پورت‌هایی که واقعاً سرویس میدهند، و سرویسهایی که اجازه دارید روی آنها تست کنید. اگر روی زیرساخت اجاره‌ای کار می‌کنید، اسکن سنگین بدون هماهنگی می‌تواند از دید ارائه‌دهنده شبیه حمله دیده شود و به بلاک شدن IP منجر شود.
یک نکته عملی: زیردامنه‌های فراموش‌شده بیشتر از دامنه اصلی حفره دارند. یک staging.example.com که شش ماه پیش ساخته شده و هنوز با نسخه قدیمی وردپرس بالا می‌آید، معمولاً راحت‌ترین ورود است. فهرست زیردامنه‌ها را از گواهی‌های SSL و رکوردهای DNS بسازید؛ ابزارهای بررسی DNS و شبکه برای همین مرحله‌اند.
ابزار رایگان را چطور و با چه فلگ‌هایی اجرا کنیم
برای سطح وب، Nmap و Nuclei ترکیب کاری خوبی هستند. Nmap برای دیدن سطح حمله، Nuclei برای تطبیق الگوهای شناختهشده.
nmap -sV -Pn -T3 --top-ports 1000 -oA scan-web example.comفلگ -sV نسخه سرویس را می‌خواند، -Pn از ping اولیه صرف‌نظر میکند (بسیاری از فایروال‌ها ICMP را می‌بندند و بدون این فلگ اسکن خالی برمی‌گردد)، و -T3 سرعت را روی حالت محافظه‌کارانه نگه می‌دارد. با -T4 سریع‌تر می‌شود ولی روی لینک‌های اشتراکی، بسته‌ها را از دست می‌دهید و نتیجه ناقص می‌شود.
برای Nuclei، اول قالب‌ها را به‌روز کنید و بعد با شدت مشخص اجرا کنید:
nuclei -update-templates
nuclei -u https://example.com -severity critical,high -rl 30 -o nuclei-out.txtفلگ -rl 30 نرخ درخواست را روی ۳۰ در ثانیه نگه می‌دارد. بدون آن، Nuclei می‌تواند روی یک سایت کوچک به‌اندازه یک حمله کوچک درخواست بفرستد و خودش باعث خطای ۵۰۳ شود. اگر سایت پشت محافظت در برابر DDoS است، این نرخ را پایین‌تر بیاورید تا خودتان بلاک نشوید.
اسکن داخل سرور، نه فقط از بیرون
اسکن بیرونی فقط پورت‌های باز را میبیند. برای دیدن بسته‌های قدیمی، سرویس‌های listen روی لوکالهاست، و مجوزهای فایل، باید از داخل هم نگاه کنید:
ss -tulpn
apt list --upgradable 2>/dev/null | grep -i securityخروجی ss اغلب چیزهایی نشان میدهد که هیچ اسکنر بیرونی نمیبیند: یک MySQL که روی 0.0.0.0:3306 گوش میدهد در حالی که باید فقط روی 127.0.0.1 باشد. این یک یافته واقعی است و بستنش پنج دقیقه وقت می‌گیرد.
چرا هر یافته، یک آسیبپذیری واقعی نیست
سه دسته یافته دارید و باید جداگانه برخورد کنید.
| نوع یافته | مثال | اقدام درست |
|---|---|---|
| قابل بهره‌برداری مستقیم | نسخه آسیب‌پذیر افزونه با مسیر عمومی | همان امروز وصله یا غیرفعال شود |
| وابسته به شرایط | افشای نسخه در هدر Server | ریسک پایین؛ فقط بخشی از سخت‌سازی |
| مثبت کاذب | هشدار روی مسیری که ۴۰۴ میدهد | تأیید دستی، سپس بستن مورد |
مثبت کاذب را دست‌کم نگیرید و بزرگش هم نکنید. اسکنری که نسخه وردپرس را از متاتگ می‌خواند، وقتی شما نسخه را در functions.php پاک کرده‌اید ولی کش هنوز نسخه قدیمی را سرو میکند، هشدار اشتباه میدهد. راه تأیید، درخواست دستی است:
curl -sI https://example.com/wp-content/plugins/foo/readme.txt | head -5اگر 404 گرفتید، یافته بسته است. اگر 200 با شماره نسخه گرفتید، یافته واقعی است و باید برود بالای لیست.
اینجا اشتباه می‌کنند
شایع‌ترین خطایی که دیده‌ام این است: تیم همه یافته‌های «High» را می‌بندد و فراموش میکند که اسکنر هیچ‌وقت منطق کسب‌وکار را نمیبیند. نتیجه‌اش این می‌شود که سه هفته بعد، یک ادمین با رمز ضعیف از یک پنل بدون محدودیت تلاش ورود، کل سایت را می‌برد. اسکنر آن مسیر را «سالم» علامت زده بود چون هیچ CVE شناخته‌شده‌ای نداشت.
علامتش هم مشخص است: داشبورد امنیتی سبز است، ولی در لاگ ورود، صدها تلاش ناموفق از یک IP دیده می‌شود. اگر لاگ ممیزی را دست‌نخورده نگه نمی‌دارید، همین را هم نمی‌بینید؛ نگهداری لاگ ممیزی پیش‌نیاز هر اسکن دوره‌ای است، نه یک کار جانبی.
ترتیب درست رفع، وقتی وقت کم است
- هر چیزی که از اینترنت قابل دسترسی است و احراز هویت ندارد: پنل ادمین باز، phpMyAdmin عمومی، فایل پشتیبان با نام قابل حدس.
- نسخه‌های آسیب‌پذیر با اکسپلویت عمومی منتشرشده. این‌ها را مهاجم بدون دانش خاص اجرا میکند.
- پیکربندی اشتباه: مجوز فایل، هدرهای امنیتی، دسترسی REST API.
- افشای اطلاعات جزئی: نسخه سرویس، پیام خطای کامل، فهرست دایرکتوری.
این ترتیب را عوض نکنید. بستن مورد چهارم قبل از مورد اول، حس پیشرفت میدهد ولی ریسک واقعی را کم نمیکند.
یک تذکر درباره هزینه: اسکن دوره‌ای خودکار، نویز زیاد و نگهداری کم دارد؛ اسکن دستی با تفسیر انسانی، دقیق‌تر است ولی هر بار چند ساعت وقت می‌برد. اگر سایت شما کمتر از ده سرویس دارد، من اسکن دستی ماهانه را انتخاب می‌کنم. اگر بیش از پنجاه سرویس دارید، خودکارسازی اجباری است، ولی باید یک نفر خروجی را هفتگی مرور کند، وگرنه گزارش‌ها خوانده‌نشده انبار می‌شوند.
بعد از رفع، دوباره اسکن کنید و تفاوت را ثبت کنید
هر رفع بدون اسکن تأییدی، یک فرض است. بعد از بستن یک یافته، همان دستور را دوباره اجرا کنید و خروجی قبل و بعد را کنار هم نگه دارید. این کار دو فایده دارد: تأیید میکند رفع واقعاً کار کرده، و به شما نشان میدهد کدام یافته‌ها هر بار برمی‌گردند. یافته‌ای که سه اسکن پشت‌سرهم برمی‌گردد، یعنی ریشه‌اش را نبسته‌اید؛ فقط علامتش را پاک کرده‌اید.
اگر روی وردپرس کار می‌کنید، بخش بزرگی از این یافته‌ها از دو جا می‌آید: افزونههای رهاشده و REST API باز. امن‌سازی REST API وردپرس و سخت‌سازی وردپرس را قبل از اسکن بعدی انجام دهید تا لیست کوتاه‌تر شروع شود.
و یک نکته که اغلب نادیده می‌ماند: اگر سرور شما پشت یک لایه محافظت شبکه‌ای نیست، اسکن فقط بخشی از تصویر است. بخشی از حملاتی که در گزارش نمی‌بینید، همان‌هایی هستند که قبل از رسیدن به اپلیکیشن باید فیلتر شوند. محافظت در برابر DDoS این لایه را پوشش میدهد و مکمل اسکن است، نه جایگزین آن.
اگر می‌خواهید این چرخه را به یک روال تبدیل کنید، از یک اسکن کوچک و محدود شروع کنید، خروجی را دستی تفسیر کنید، و فقط بعد از اینکه فهمیدید کدام یافته‌ها برای زیرساخت شما معنا دارند، سراغ خودکارسازی بروید. برای سرویسهایی که در همین مسیر به آنها نیاز پیدا می‌کنید، خدمات امنیت سرورنت نقطه شروع مناسبی است.
پرسش‌های پرتکرار
آیا اسکن آسیب پذیری سایت را کند میکند؟
بله، اگر نرخ درخواست را محدود نکنید. اسکنرهایی مثل Nuclei بدون فلگ -rl می‌توانند صدها درخواست در ثانیه بفرستند و روی سرورهای کوچک باعث بالا رفتن زمان پاسخ یا خطای ۵۰۳ شوند. با نرخ ۲۰ تا ۳۰ درخواست در ثانیه و اجرای اسکن در ساعات کم‌ترافیک، اثر محسوسی روی کاربران واقعی نمی‌بینید.
چرا اسکنر چیزی پیدا نمیکند ولی سایت هک شده است؟
چون اسکنر فقط الگوهای شناختهشده را میبیند. اگر نفوذ از طریق رمز ضعیف، افشای توکن، یا یک آسیبپذیری منطقی در کد اختصاصی شما انجام شده باشد، هیچ CVEای برای تطبیق وجود ندارد. در این حالت باید سراغ لاگهای دسترسی، فایلهای تغییریافته و حسابهای کاربری مشکوک بروید، نه سراغ اسکنر.
هر چند وقت یک بار باید اسکن کنم؟
برای سایتهای پویا با افزونههای متعدد، ماهی یک بار حداقل. بعد از هر بهروزرسانی بزرگ یا نصب افزونه جدید، یک اسکن هدفمند هم لازم است. اسکن روزانه روی زیرساخت ثابت معمولاً نویز تولید میکند و کسی خروجی را نمیخواند.
اسکن از بیرون کافی است یا باید از داخل سرور هم اجرا کنم؟
هر دو لازم است. اسکن بیرونی سطح حمله واقعی را نشان میدهد، ولی سرویسهایی که فقط روی لوکالهاست گوش میدهند یا مجوزهای فایل اشتباه را نمیبیند. دستور ss -tulpn روی خود سرور، در چند ثانیه چیزهایی را لو میدهد که هیچ اسکنر بیرونی به آنها دسترسی ندارد.
دیدگاه‌ها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!