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

لاگ حمله دقیقاً چیست؟

لاگ حمله، فایلی است که وب‌سرور شما برای هر درخواست HTTP (Hypertext Transfer Protocol) ثبت می‌کند — چه از طرف کاربران واقعی و چه از طرف مهاجمان. هر خط لاگ، اطلاعاتی مثل آدرس IP، مسیر درخواستی، کد وضعیت، User-Agent و زمان را شامل می‌شود. تحلیل این لاگ‌ها، به شما می‌گوید چه کسی سعی کرده به سایت شما نفوذ کند و از کدام نقطه. برای درک کلی حمله‌ها، حملات سایبری چیست و چه انواعی دارد نقطه شروع خوبی است.

لاگ‌ها کجا ذخیره می‌شوند؟

در cPanel، لاگ‌ها در چند مکان قابل دسترسی هستند:

نوع لاگمسیر یا بخش cPanelکاربرد
Access LogRaw Access / ~/logs/همه درخواست‌های وب
Error LogErrors / ~/logs/error_logخطاهای سرور و وردپرس
Auth LogSSH یا سرورتلاش‌های ورود به سرور
WAF Logافزونه امنیتیدرخواست‌های مسدودشده

برای دسترسی دقیق‌تر، cPanel چیست و آموزش cPanel مسیر را نشان می‌دهند.

لاگ‌ها فقط داده نیستند؛ صدای سایتی هستند که نمی‌تواند حرف بزند. مهارت خواندن این صدا، تفاوت بین مهاجمِ موفق و مهاجمِ ناکام است.

آناتومی یک لاگ: چه چیزی را باید بخوانید؟

یک خط لاگ استاندارد به شکل زیر است:

192.168.1.10 - - [19/Sep/2026:14:25:33 +0000] "POST /wp-login.php HTTP/1.1" 200 4532 "-" "Mozilla/5.0 (X11; Linux x86_64) Python-Requests/2.28"

هر بخش، یک معنای مشخص دارد:

  • آدرس IP: منبع درخواست (نشانه اول)
  • زمان: الگوهای حمله معمولاً در ساعات مشخص رخ می‌دهند
  • متد و مسیر: POST به /wp-login.php نشانه احتمالی Brute Force است
  • کد وضعیت: 200 موفق، 401 رد‌شده، 403 مسدود، 500 خطای سرور
  • User-Agent: ابزار مهاجم را لو می‌دهد — مثلاً Python-Requests در جای مرورگر

اگر با حمله Brute Force آشنا نیستید، حمله brute force چیست را بخوانید؛ چرا که رایج‌ترین الگویی است که در لاگ‌ها می‌بینید.

الگوهای حمله در لاگ: چه چیزی طبیعی نیست؟

در تجربه من، این الگوها بیشترین شیوع را دارند:

  1. تلاش‌های پرتکرار ورود: ده‌ها درخواست POST به wp-login.php در مدت کوتاه از یک IP.
  2. User-Agent غیرمرورگر: ابزارهایی مثل curl، Python-Requests، یا اسکریپت‌های خودکار.
  3. درخواست به فایل‌های حساس: مثل wp-config.php، .env، adminer.php.
  4. پیمایش مسیرها: درخواست‌های پشت‌سرهم به مسیرهای تصادفی، نشانه اسکن آسیب‌پذیری است.
  5. متدهای غیرعادی: PUT، DELETE، OPTIONS که کاربر عادی از آن‌ها استفاده نمی‌کند.
  6. کوئری‌های مشکوک: پارامترهایی مثل ?author=1 یا ?s= با مقادیر طولانی.

در یک سایت آموزشی، لاگ‌ها نشان دادند که یک ربات، روزانه حدود ۲۰۰۰ درخواست به مسیرهای تصادفی می‌فرستد. این نشانه اسکنر خودکار بود که چند هفته بعد به حمله هدفمند تبدیل شد. برای مقابله با این نوع تهدیدها، چگونه سایت را از حملات سایبری محافظت کنیم راهنمای کاملی است.

ابزارهای تحلیل لاگ

خواندن دستی لاگ‌ها برای سایت‌های کوچک ممکن است، اما در سایت‌های پرترافیک کارایی ندارد. ابزارهای زیر را توصیه می‌کنم:

  • GoAccess: ابزار متن‌باز و سریع برای تحلیل لاگ‌های Apache و Nginx.
  • AWStats: در cPanel به‌صورت پیش‌فرض موجود است.
  • افزونه‌های امنیتی وردپرس: مثل Wordfence یا Sucuri که لاگ اختصاصی WAF (Web Application Firewall) دارند. مقایسه در بهترین افزونه‌های امنیتی وردپرس آمده.

در محیط‌های سرور اختصاصی، ترکیب grep، awk و sort می‌تواند همان کاری را انجام دهد که ابزارهای گرافیکی می‌کنند. یک دستور نمونه برای شمارش تلاش‌های ورود:

grep "POST /wp-login.php" access_log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

روال هفتگی بررسی لاگ

من در پروژه‌های واقعی، یک روال ساده اما منظم دارم:

  1. روز اول هفته: مرور لاگ‌های Access هفته گذشته با GoAccess.
  2. روز سوم: بررسی لاگ‌های WAF افزونه امنیتی برای درخواست‌های مسدودشده.
  3. روز پنجم: بررسی خطاهای ۴۰۴ و ۵۰۰ در Error Log.
  4. روز هفتم: بروزرسانی لیست IP‌های مسدودشده و تنظیمات فایروال.

این روال هفتگی، هفته‌ای ۳۰ تا ۴۵ دقیقه وقت می‌گیرد، اما در چند پروژه واقعی جلوی نفوذی را گرفته که می‌توانست هفته‌ها هزینه پاکسازی ایجاد کند.

وقتی حمله را در لاگ دیدید، چه کنید؟

سه سناریوی رایج و پاسخ پیشنهادی:

  1. حمله در حال جریان: IP را مسدود کنید (در cPanel با IP Deny Manager یا افزونه امنیتی).
  2. حمله پایان‌یافته با نفوذ موفق: فوری اسکن بدافزار انجام دهید. راهنما در بدافزار مخفی در وردپرس چگونه پیدا می‌شود.
  3. حمله DDoS یا سیل درخواست: ابتدا در CDN (Content Delivery Network) یا فایروال ابری، فیلتر فعال کنید. برای درک این تهدید، حمله DDoS چیست را بخوانید.

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

پیشگیری: کاهش حجم حمله در لاگ

هرچه حمله کمتری اتفاق بیفتد، لاگ کم‌حجم‌تر و تحلیل ساده‌تر است. راهکارهای مؤثر:

  • محدودسازی تلاش ورود در امن‌سازی لاگین ادمین وردپرس.
  • فعال‌سازی 2FA (Two-Factor Authentication) برای همه حساب‌های مدیریتی.
  • استفاده از فایروال ابری برای فیلتر ترافیک پیش از رسیدن به سرور.
  • غیرفعال‌سازی XML-RPC (XML Remote Procedure Call) اگر استفاده نمی‌کنید.
  • به‌روزرسانی منظم وردپرس، قالب و افزونه‌ها.

برای رویکرد کلی به امنیت، راهنمای امنیت وردپرس برای مبتدیان و بهترین افزونه‌های امنیتی مراجع اصلی من هستند.

اشتباهات پرهزینه در تحلیل لاگ

اشتباهاتی که در پروژه‌ها دیده‌ام و باید از آن‌ها اجتناب کرد:

  1. حذف سریع لاگ‌ها: بدون تحلیل، اطلاعات حیاتی از دست می‌رود.
  2. محدود کردن بررسی به یک لاگ: Access و Error و WAF را باید با هم دید.
  3. نادیده گرفتن خطاهای کوچک ۴۰۴: حجم بالای ۴۰۴ از یک IP، نشانه اسکن است.
  4. مسدودسازی کامل IP‌های اشتراکی: ممکن است کاربران واقعی را هم از دست بدهید.
  5. اعتماد به تعداد کلیک‌ها به‌جای الگوها: یک IP با ۱۰ درخواست هدفمند، خطرناک‌تر از یک IP با ۱۰۰۰ درخواست تصادفی است.

برای جزئیات بیشتر در مورد آسیب‌پذیری‌ها، CVE چیست و اولویت‌بندی رفع آسیب‌پذیری‌ها را بخوانید.

پرسش‌های پرتکرار درباره بررسی لاگ حملات

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

آیا می‌توانم لاگ‌ها را به‌صورت خودکار تحلیل کنم؟ بله. ابزارهایی مثل GoAccess و افزونه‌های امنیتی، تحلیل خودکار ارائه می‌دهند. اما مرور دستی هفتگی همچنان لازم است.

لاگ‌ها چه مدت باید نگه داشته شوند؟ حداقل ۳۰ روز. برای سایت‌های حساس، ۹۰ روز.

آیا حمله از IP معتبر ایران می‌تواند باشد؟ بله. بسیاری از حملات از سرورهای آلوده ایران یا VPN (Virtual Private Network) انجام می‌شوند. مسدودسازی کامل جغرافیایی راه‌حل قطعی نیست.

اگر سایت روی CDN باشد، لاگ‌ها کجا هستند؟ در این حالت، باید IP واقعی کاربر در هدرهای X-Forwarded-For یا CF-Connecting-IP بررسی شود. راهنما در هدرهای امنیتی HTTP موجود است.

لاگ‌ها، صدای سایت شما در برابر تهدیدها

بررسی لاگ حملات، شبیه معاینه دوره‌ای پزشکی است — تا وقتی درد ندارید، به‌نظر بی‌اهمیت می‌رسد؛ اما وقتی درد شروع می‌شود، دیر شده. اگر امروز فقط یک کار انجام دهید، این باشد: از هفته آینده یک قرار ثابت هفتگی برای بررسی لاگ‌ها بگذارید. اگر تجربه‌ای از یک حمله واقعی دارید که لاگ‌ها جلوی آن را گرفتند، یا برعکس، حمله‌ای که از چشم لاگ‌ها پنهان ماند، در دیدگاه‌ها بنویسید. تجربه‌های شما، برای صاحبان سایت بعدی، ارزشمندتر از هر کتاب امنیتی است. 🔍