The latest articles on DEV Community by Mahdi Noorolahi (@mahdi_noorolahi_6c397e0d0). https://dev.to/mahdi_noorolahi_6c397e0d0 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4239788%2Fe9f19380-8e7b-4ee8-8bf6-be1e5ae17a6e.png https://dev.to/mahdi_noorolahi_6c397e0d0 en Mahdi Noorolahi Wed, 11 Nov 2026 20:10:00 +0000 https://dev.to/mahdi_noorolahi_6c397e0d0/syt-hkh-shd-chkhlyst-khml-24-st-wl-dr-1405-4kon https://dev.to/mahdi_noorolahi_6c397e0d0/syt-hkh-shd-chkhlyst-khml-24-st-wl-dr-1405-4kon <p>صبح، پیش از هر کار دیگر، یک پیام مشتری: «سایتتون رو باز کردم، گوگل نوشته ممکن است هک شده باشد.» یا بدتر: سایت به یک آدرس ناشناس ریدایرکت می‌شود، یا در جستجوی site:yourdomain.ir صفحاتی با موضوع دارو و کازینو ظاهر شده‌اند. این دقیقاً لحظه‌ای است که بیشتر صاحبان سایت یکی از دو اشتباه بزرگ را مرتکب می‌شوند: با عجله شروع به پاک‌کردن فایل‌ها می‌کنند یا اولین بکاپی را که پیدا می‌شود برمی‌گردانند — و هک چند روز بعد، بی‌سروصدا، برمی‌گردد.<br> این مقاله همان ترتیب کاری است که برای پاسخ اضطراری به هک استفاده می‌کنم، در قالب چک‌لیست ۲۴ ساعت اول؛ برای هر نوع سایتی — وردپرس، فروشگاه اینترنتی یا سایت با کد اختصاصی. هر مرحله را کوتاه و قابل اجرا نوشته‌ام؛ نه آمار خشک، نه توصیه‌های کلیِ «مراقب رمزهایتان باشید».<br> برای واقع‌بینی، دو عدد از گزارش ۲۰۲۳ شرکت امنیتی Sucuri: از میان آلودگی‌های شناسایی‌شده برای کاربرانشان، ۹۵.۵ درصد سایت‌های وردپرسی بودند و اسکنرهایشان اسپم سئوی شرط‌بندی را روی ۸۷٬۲۰۱ سایت شناسایی کرده‌اند — ۲۰۰ درصد بیشتر از سال قبل از آن. یعنی فقط وردپرس هک می‌شود؟ نه؛ یعنی نمونه‌های آن گزارش عمدتاً وردپرس بوده‌اند. سایت با کد اختصاصی هم — از راه رمز ضعیف، سرور بی‌به‌روزرسانی یا سِرِ لو رفته — دقیقاً به همین راحتی می‌افتد.<br> اول بفهم مهاجم دنبال چیست<br> تقریباً همه هک‌های سایت‌های کوچک و متوسط برای یکی از این پنج هدف اتفاق می‌افتد. دانستنِ هدف، تصمیم‌های فاز بعدی را ساده می‌کند، چون می‌دانید کجا را باید بگردید:<br> اسپم سئو و ریدایرکت: مهاجم صفحات جعلی با موضوع دارو، شرط‌بندی یا محتوای ژاپنی و چینی به دامنه شما اضافه می‌کند تا در گوگل رتبه بگیرد، یا ترافیک شما را به سایت خودش می‌فرستد. رایج‌ترین نوع است و برای همین گوگل ابزارهای کشفش را خودش در اختیارتان گذاشته است.<br> بدافزار برای بازدیدکننده: صفحه برای شما سالم به نظر می‌رسد، ولی در پس‌زمینه اسکریپتی لود می‌شود که مرورگر بازدیدکننده را هدف می‌گیرد.<br> فیشینگ روی دامنه شما: صفحه‌ای شبیه صفحه ورود بانک یا درگاه پرداخت روی دامنه شما بالا می‌آید؛ دامنه معتبر شما به صفحه جعلی اعتبار می‌دهد.<br> ماینر و بات‌نت: سرور شما بی‌سروصدا برای استخراج رمزارز یا حمله به مقصدهای دیگر استفاده می‌شود؛ تنها نشانه‌اش معمولاً کندی و مصرف بالای منابع است.<br> سرقت داده: اطلاعات کاربران، سفارش‌ها و فرم‌ها هدف است؛ در فروشگاه‌ها خطرناک‌ترین سناریوست.<br> نکته مهم این است که بیشتر هک‌ها صفحه اصلی را عوض نمی‌کنند، چون مهاجم می‌خواهد مدت طولانی از سایت شما استفاده کند. برای همین «تا دیروز خوب بود» یک نشانه نیست؛ وجودش را باید جست‌وجو کنید.<br> نشانه‌های هک شدن سایت — از قطعی تا مشکوک<br> همه نشانه‌ها یک وزن ندارند. به ترتیب قطعیت بررسی کنید:<br> نشانه‌های قطعی<br> برچسب «این سایت ممکن است هک شده باشد» در نتایج گوگل: طبق تعریف رسمی گوگل، محتوای هک‌شده یعنی محتوایی که بدون اجازه شما و به دلیل ضعف امنیتی سایتتان روی سایت قرار گرفته است. گوگل به مالکانی که Search Console را تأیید کرده‌اند، وقتی به نفوذ مشکوک شود اعلان می‌دهد — این گزارش را از قبل تماشا کنید، نه بعد از حادثه.<br> هشدار قرمز مرورگر: صفحه‌ای که می‌گوید این سایت خطرناک است (فهرست Safe Browsing). گوگل همین فهرست را به اکثر مرورگرهای اصلی می‌دهد.<br> گزارش Security Issues پر در Search Console: گوگل نوع مشکل را دقیق می‌گوید: بدافزار، تزریق کد، تزریق محتوا، تزریق URL یا صفحات گمراه‌کننده. همین دقیق‌گویی نقشه راه پاکسازی شماست.<br> هشدار رسمی هاستینگ: محدود شدن حساب به دلیل ارسال اسپم یا مصرف غیرعادی منابع، معمولاً یعنی اسکریپت مخربی روی سرور در حال اجراست.<br> نشانه‌های تقریباً قطعی<br> ریدایرکتی که فقط بعضی‌ها می‌بینند: بخشی از ریدایرکت‌های مخرب فقط برای کاربری فعال می‌شوند که از گوگل و با گوشی می‌آید و برای مدیری که مستقیم آدرس را می‌زند دیده نمی‌شوند. برای تست، از یک گوشی و اینترنت دیگر، در گوگل اسم برند را جست‌وجو کنید و روی نتیجه کلیک کنید — آدرس را تایپ نکنید.<br> صفحات ناشناس در جستجوی site:دامنه: با جستجوی site:yourdomain.ir همراه کلماتی مثل casino یا pill دنبال صفحات اسپم بگردید.<br> کاربر ادمین یا مالک ناشناس: هم در پنل سایت، هم در کاربران Search Console — بعضی مهاجمان خودشان را «مالک» سایت ثبت می‌کنند تا صفحاتشان سریع‌تر ایندکس شود.<br> نقشه سایت جعلی: فایل سایت‌مپی که شما نساخته‌اید و صفحات اسپم را به گوگل معرفی می‌کند تا سریع‌تر ایندکس شوند.<br> نشانه‌های مشکوک — نیاز به بررسی فنی دارند<br> کندی ناگهانی و مصرف بالای CPU یا RAM بدون دلیل مشخص<br> ایمیل‌های خروجی عجیب به نام دامنه شما؛ مثلاً پیام‌های «Mail Delivery Failed» برای ایمیلی که نفرستاده‌اید<br> فایل یا کار زمان‌بندی‌شده (cron) که یادتان نیست ساخته باشید<br> تغییرات محتوایی که هیچ‌کس انجام نداده است<br> و یک هشدار معکوس: اگر تنها نشانه «کندی» است و هیچ مورد دیگری ندارید، اول دلایل عادی کندی را بررسی کنید؛ قرار نیست هر مشکل فنی را با چکش امنیت بکوبیم.<br> چک‌لیست ۲۴ ساعت اول — چهار فاز<br> قاعده طلایی را همین‌جا بگویم: ساعت اول برای مهار است، نه پاکسازی. عجله برای پاک‌کردن، شواهد را می‌سوزاند و معمولاً پاکسازی ناقص می‌سازد. چهار فاز، به همین ترتیب:<br> فاز ۱ — ساعت ۰ تا ۲: مهار و حفظ شواهد<br> جلوی آسیب به بازدیدکننده را بگیرید. اگر ریدایرکت مخرب، بدافزار یا فیشینگ فعال است، سایت را در حالت تعمیر بگذارید یا با کمک هاستینگ دسترسی عمومی را موقتاً ببندید. این کار پنهان‌کردن مشکل نیست؛ جلوگیری از این است که مشتری به صفحه مخرب برود و اطلاعات بیشتری لو برود.<br> از وضعیت آلوده نسخه پشتیبان بگیرید. عجیب به نظر می‌رسد ولی حیاتی است: فایل‌ها، دیتابیس و در صورت امکان لاگ‌های سرور، بیرون از همان سرور. بدون شواهد، سؤال «راه نفوذ چه بود؟» همیشه بی‌جواب می‌ماند و همان حفره دوباره باز می‌شود.<br> از پشتیبان‌گیری خودکار موقتاً بگذرید. اگر بکاپ‌گیر خودتان روی چند نسخه محدود است، فعلاً متوقفش کنید تا نسخه‌های سالم قدیمی با نسخه آلوده بازنویسی نشوند؛ این بکاپ‌های قدیمی نجات‌دهنده فردای شما هستند.<br> همه رمزها را از یک دستگاه سالم عوض کنید. پنل مدیریت سایت، هاست و SSH، دیتابیس، FTP/SFTP، ایمیل مرتبط با دامنه، پنل ثبت دامنه و پنل پیامک. اگر همان لپ‌تاپی را استفاده کنید که احتمالاً خودش آلوده است، رمز جدید هم دزدیده می‌شود.<br> اگر ربات تلگرام یا هر سرویس ابری متصل دارید، سِرش را همان‌جا بچرخانید. توکن ربات را باطل (Revoke) کنید و کلیدهای API سرویس‌های بیرونی را بازتولید کنید؛ مهاجمی که کد سایت را خوانده، این توکن‌ها را هم خوانده است.<br> یک فایل رویداد بنویسید. ساعت اولین نشانه، چه دیدید، چه کردید و چه تغییری اخیراً روی سایت رخ داده (به‌روزرسانی، افزونه جدید، کارمند جدید با دسترسی، انتقال سرور). همین متن ساده، بعداً ماده اولیه درخواست بررسی گوگل و گزارش پاکسازی می‌شود.<br> فاز ۲ — ساعت ۲ تا ۶: پیدا کردن راه نفوذ<br> هدف این فاز یک پاسخ است: «مهاجم از کجا وارد شد؟» بدون این پاسخ، پاکسازی فقط جاروی جلوی در است.<br> لاگ دسترسی را بخوانید. دنبال درخواست‌های POST غیرعادی به فایل‌های آپلود، آدرس‌های عجیب و فعالیت‌های اطراف زمان اولین نشانه باشید. اگر لاگ فعال نیست، از هاستینگ بخواهید؛ بیشتر هاست‌ها لاگ وب‌سرور را نگه می‌دارند.<br> فایل‌های تازه تغییر‌کرده را فهرست کنید. تاریخ تغییر فایل‌ها را با نقطه زمانی حمله مقایسه کنید. در پوشه‌هایی مثل uploads که نباید کد اجرایی داشته باشند، وجود فایل PHP خبر بد است.<br> با نسخه تمیز مقایسه کنید. در سایت اختصاصی این کار برق‌آساست: اگر کد در مخزن Git نگهداری می‌شود، یک مقایسه با آخرین نسخه سالم، دقیقاً فایل‌های دست‌کاری‌شده را نشان می‌دهد — یکی از قوی‌ترین دلایلی که می‌گویم هر سایت اختصاصی باید مخزن کدی به نام خود صاحب سایت داشته باشد. در وردپرس، هسته و افزونه‌ها را با نسخه رسمی مقایسه کنید.<br> کاربران و نقش‌ها را چک کنید — هم در پنل سایت، هم در جدول کاربران دیتابیس.<br> کلیدهای سرویس‌های بیرونی را فهرست کنید: درگاه پرداخت، پنل پیامک، SMTP و هر وب‌هوکی که سایتتان دارد.<br> اگر راه نفوذ پیدا نشد، صادقانه بنویسید «پیدا نشد». این را در گزارش ثبت کنید، نه پنهان؛ تصمیم درست در این حالت معمولاً بازسازی تمیز است، نه پاکسازی خوش‌بینانه.<br> فاز ۳ — ساعت ۶ تا ۱۲: پاکسازی<br> دو مسیر جلوی شماست و انتخاب بین این دو به معیارهای ساده‌ای بستگی دارد:<br> پاکسازی دستی مسیر درست است وقتی: راه نفوذ پیدا شده و مشخص است، آلودگی محدود است و بکاپ سالمِ تاریخ‌دار دارید.<br> بازسازی تمیز مسیر امن‌تر است وقتی: راه نفوذ پیدا نشده، هک تکراری است، سایت سال‌ها بدون نگهداری مانده یا از افزونه و قالب نال‌شده استفاده می‌کند، یا کد اختصاصی‌ای بدون مخزن و بدون مستندات دارید.<br> اگر سراغ پاکسازی رفتید، حداقل‌های یک پاکسازی کامل این‌هاست:<br> فایل‌های هسته، قالب و افزونه‌ها را از منبع رسمی جایگزین کنید؛ هیچ‌وقت از روی فایل آلوده «ترمیم» نکنید. افزونه و قالب نال‌شده را حذف کنید، نه به‌روزرسانی.<br> بک‌دورها را جست‌وجو کنید — بخشی که تقریباً همه جا رد می‌شود. مهاجم معمولاً بیش از یک در پشت‌سر می‌گذارد: فایلی با نام شبیه فایل‌های اصلی، کد مبهم‌شده در پوشه آپلود، تزریق در دیتابیس، کاربر مخفی. حذف فقط بخش‌های آشکار یعنی هکِ تضمینیِ برمی‌گردد.<br> دیتابیس را هم بررسی کنید، نه فقط فایل‌ها را: جدول کاربران، محتوای نوشته‌ها و تنظیمات برای کد تزریق‌شده و ریدایرکت‌های دیتابیسی.<br> تنظیمات وب‌سرور (ریدایرکت‌ها و فایل‌های پیکربندی) و کارهای زمان‌بندی‌شده سرور را بازبینی کنید.<br> از بیرون هم چک بگیرید: جستجوی site:دامنه و ابزار URL Inspection در Search Console — این ابزار صفحه را همان‌طور که گوگل می‌بیند نشان می‌دهد و ریدایرکت‌ها و محتوای پنهان را می‌گیرد.<br> فاز ۴ — ساعت ۱۲ تا ۲۴: بازیابی و بستن پرونده<br> همه اجزا را به‌روز کنید و اجزای بلااستفاده را حذف کنید؛ به‌روزرسانی، نصف راه بستن همان حفره است.<br> سخت‌سازی حداقلی را انجام دهید: ورود دومرحله‌ای برای پنل، محدودسازی تلاش‌های ورود، دسترسی حداقلی برای هر کاربر و بستن اجازه اجرای کد در پوشه آپلود.<br> در Search Console درخواست بررسی بدهید — اما درست. سه نکته از سند رسمی گوگل: اول، رفع باید در «کل سایت» انجام شده باشد، نه فقط چند صفحه نمونه؛ دوم، متن درخواست خوب سه چیز را می‌گوید — مشکل چه بود، چه کردید، نتیجه چه شد؛ سوم، بررسی «از چند روز تا چند هفته» طول می‌کشد و تا جواب نیامده درخواست را دوباره نفرستید؛ ارسال مکرر با مشکل رفع‌نشده می‌تواند روند پرونده‌تان را طولانی‌تر کند.<br> صفحات اسپم را ۴۰۴ یا ۴۱۰ کنید، نه ریدایرکت به صفحه اصلی. ریدایرکتِ صفحات جعلی به خانه، آنها را از نتایج بیرون نمی‌برد و گاهی به کل دامنه آسیب می‌زند.<br> سرویس‌های بیرونی را ببندید: کلید درگاه، توکن پیامک و رمز SMTP همه نو شود، و یک دور تست واقعیِ پرداخت و فرم‌ها بگیرید.<br> حالت تعمیر را بردارید، ولی پرونده را «بسته» تلقی نکنید؛ پایشِ چند هفته‌ای هنوز جلوی شماست.<br> پنج اشتباهی که هک را برمی‌گرداند<br> برگرداندن بکاپ بدون پیدا کردن راه نفوذ. بکاپ همان رمز لو رفته و همان حفره را هم برمی‌گرداند؛ مهاجم چند روز بعد از همان در می‌آید، این بار شاید با بکاپ‌های خودتان.<br> پاک کردن فقط فایل‌های آشکار. بک‌دور دوم، کاربر مخفی و تزریق دیتابیسی باقی می‌ماند و هک «معجزه‌آسا» برمی‌گردد.<br> پاک کردن یا چرخش‌نکردن لاگ‌ها و شواهد. لاگ، تنها شاهدی است که مسیر نفوذ و دامنه داده‌های در معرض خطر را نشان می‌دهد؛ پاک کردنش یعنی کور‌کردن چشم خودتان.<br> ریدایرکت کردن صفحات اسپم به صفحه اصلی. پاسخ درست ۴۰۴ یا ۴۱۰ است؛ نه انتقال به خانه.<br> گفتن «درست شد» بدون پایش. پاکسازیِ بدون دو تا سه هفته پایش — گزارش‌های گوگل، جستجوی site: و لاگ‌ها — قابل قبول نیست؛ آلودگی‌ها اغلب با چند روز فاصله برمی‌گردند.<br> اگر سایت فروشگاهی است یا درگاه پرداخت دارد<br> فروشگاه، پشت همین چک‌لیست یک دور جدی‌تر می‌خواهد، چون چیزی که در خطر است فقط سایت نیست؛ داده مشتری و تراکنش است:<br> درگاه را با هماهنگی سرویس‌دهنده موقتاً تعطیل کنید و کلید یا توکن درگاه را بازتولید کنید. تعطیلی کوتاهِ کنترل‌شده، بهتر از ادامه فروش روی سایتی است که ممکن است اطلاعات کارت بگیرد.<br> لاگ تراکنش‌ها را با گزارش درگاه مقایسه کنید تا پرداخت‌های غیرعادی مشخص شود و بتوانید به سرویس‌دهنده گزارش دقیق بدهید.<br> تعیین کنید مهاجم به داده‌ها دسترسی داشته یا نه: دیتابیس مشتریان، فرم‌ها و فایل‌های سفارش. همین تعیین می‌کند که اطلاع‌رسانی به مشتری لازم است یا نه.<br> در صورت نشت احتمالی داده، صادقانه اطلاع‌رسانی کنید: چه اتفاقی افتاد، چه اطلاعاتی در خطر بود، چه کردید و مشتری مراقب چه چیزی باشد — مثل پیامک‌های جعلی به نام شما. مشتری معمولاً از خودِ حادثه کمتر ناراحت می‌شود تا از کشف پنهان‌کاری.<br> در پروژه‌های فروشگاهی‌ای که توسعه داده‌ام — مثل نمونه‌کار فروشگاه AliBandana و نمونه‌کار چاپ صدر — اولویت من در همه‌شان همین بوده: جداسازی بخش پرداخت و چرخش‌پذیری کلیدها، تا اگر روزی اتفاقی افتاد، بتوان در چند دقیقه همه سِرها را نو کرد.<br> از میدان: درسی که خودم گرفتم<br> بگذارید این چک‌لیست را از جنس خودش تعریف کنم: از تجربه. توکن رباتی که خودم ساخته بودم، یک بار جایی عمومی لو رفت. آن لحظه یادم داد که در پاسخ اضطراری، چرخش سِرها باید در ساعت صفر باشد، نه در فهرستِ «بعداً انجام می‌دهیم»؛ اگر اول به سراغ فایل‌ها و بکاپ می‌رفتم، احتمالاً مسیر نفوذ را هم با شواهدش می‌سوزاندم. از آن روز هر چک‌لیست پاسخ به حادثه‌ای که می‌نویسم، با ابطال و چرخش کلیدها شروع می‌شود، نه با پاکسازی.<br> همین تجربه‌ها انگیزه ساختن ربات اسکنر امنیتی من شد؛ رباتی با ۱۶ ابزار بررسی امنیتی که برای چک‌های دوره‌ای خودم استفاده می‌شود. پاسخ اضطراری، نصفش مهارت و ترتیب است، نصفش ابزار و آمادگیِ قبل از حادثه.<br> بعد از ۲۴ ساعت: پایش و پیشگیری<br> سه هفته پایش:<br> گزارش Security Issues در Search Console تا برداشته شدن هشدار<br> جستجوی site:دامنه هر چند روز یک‌بار<br> لاگ سرور و فایل‌های تازه تغییر‌کرده<br> ترافیک ارگانیک: برگشت تدریجی طبیعی است، نه یک‌شبه<br> پیشگیری — فهرست کوتاه ولی جدی:<br> به‌روزرسانی منظم همه اجزا و حذف اجزای بلااستفاده<br> بکاپ خارج از سرور، تاریخ‌دار، و آزمون دوره‌ای بازیابی<br> ورود دومرحله‌ای برای همه دسترسی‌های مدیریتی<br> اصل حداقل دسترسی: هر کس فقط دسترسی‌ای که واقعاً لازم دارد<br> مانیتورینگ لاگ و اعلان تغییر فایل<br> اگر ترجیح می‌دهید این‌ها به‌جای نگرانی روزانه شما، به یک قرارداد نگهداری و بررسی امنیتی سپرده شود، صفحه امنیت را ببینید؛ چک‌لیست کامل سخت‌سازی آنجا آمده است.<br> سؤال‌های رایج<br> خودم پاکسازی کنم یا متخصص بگیرم؟<br> اگر سایت معرفی‌ای دارید با بکاپ سالم و راه نفوذ روشن، پشتیبانی هاستینگ یا خودتان با همین چک‌لیست کافی است. ولی اگر فروشگاه با داده مشتری دارید، هک تکراری است یا سایت اختصاصیِ بدون مخزن کد است، متخصصی بگیرید که گزارش کتبی بدهد. اولین سؤال شما از هر تیمی این باشد: «راه نفوذ را چطور پیدا می‌کنید و اگر پیدا نشد چه؟» تیمی که جواب این را ندارد، فقط اسکن می‌کند و می‌رود.<br> هشدار گوگل چه زمانی برداشته می‌شود؟<br> طبق سند رسمی گوگل، بعد از رفع کامل مشکل در کل سایت و ارسال درخواست بررسی در Security Issues، بررسی «از چند روز تا چند هفته» طول می‌کشد و تا جواب نیامده نباید درخواست را دوباره فرستاد. زمان دقیق را هیچ‌کس تضمین نمی‌کند؛ ولی هرچه پاکسازی کامل‌تر و متن درخواست شفاف‌تر باشد، پرونده سریع‌تر بسته می‌شود.<br> بکاپ را برگردانم یا نه؟<br> بعد از پیدا کردن راه نفوذ، با تمیزترین بکاپ ممکن، و بعد از چرخش همه رمزها. برگرداندن بکاپ به‌عنوان اولین کار، رایج‌ترین اشتباهی است که هک را دوباره برمی‌گرداند — بکاپ همان حفره و همان رمز لو رفته را هم همراهش می‌آورد.<br> بعد از هک باید کل سایت را از نو بسازم؟<br> معمولاً نه. بازسازی وقتی منطقی است که راه نفوذ پیدا نشود، هک چند بار تکرار شده باشد یا سایت سال‌ها بدون نگهداری مانده باشد. اگر پروژه اصلی ربات یا پنل تلگرامی بوده و باید از نو ساخته شود، بازه‌های واقعی هزینه را در مقاله هزینه ساخت ربات تلگرام نوشته‌ام.<br> وردپرس امن‌تر است یا کد اختصاصی؟<br> هر دو هک می‌شوند؛ تفاوت در ساختار نگهداری است، نه در برچسب. بحث کامل معایب و مزایا را در مقاله کد اختصاصی یا وردپرس نوشته‌ام. خلاصه‌اش: هر سایتی که به‌روز و مدیریت‌شده بماند، امن می‌ماند — و هر سایتی که سال‌ها بی‌نگهداری بماند، مستقل از تکنولوژی، بالاخره می‌افتد.<br> باید به مراجعی مثل پلیس فتا اطلاع بدهم؟<br> اگر روی دامنه شما فیشینگ راه‌اندازی شده یا داده مشتریان احتمالاً نشت کرده، گزارش به مراجع ذی‌صلاح و مشورت حقوقی، تصمیم درستی است — هم برای مستندسازی حادثه و هم برای حفظ اعتماد مشتری. تشخیص اینکه داده‌ای در معرض خطر بوده یا نه، به همان بررسی‌های فاز ۲ برمی‌گردد؛ برای همین شواهد را از ساعت اول نگه دارید.<br> جمع‌بندی<br> اگر فقط یک جمله از این مقاله یادتان بماند: ساعت اول برای مهار است، نه پاکسازی. ترتیب کامل: مهار → حفظ شواهد → چرخش رمزها و سِرها → پیدا کردن راه نفوذ → پاکسازی کامل فایل و دیتابیس → سخت‌سازی → درخواست بررسی گوگل → پایش سه‌هفته‌ای.<br> و اگر در میانه راه زمین‌گیر شدید یا ترجیح می‌دهید کسی با گزارش کتبی و پایش، این کار را انجام دهد، از طریق صفحه تماس در خدمتم؛ از بررسی امنیتی سایت تا پاکسازی و سخت‌سازی بعد از حادثه.<br> <a href="https://atrincode.ir/" rel="noopener noreferrer"></a></p> cybersecurity security wordpress