اگر سایت وردپرس ناگهان به صفحات تبلیغاتی ناشناس هدایت می‌شود، فایل‌های مشکوک روی هاست ظاهر شده‌اند، حساب مدیر جدیدی ساخته شده یا گوگل سایت را به‌عنوان خطرناک شناسایی کرده است، ممکن است سایت هک شده باشد. در این شرایط، حذف چند فایل یا نصب یک افزونه امنیتی به‌تنهایی کافی نیست. اگر مسیر ورود مهاجم همچنان باز باشد، آلودگی می‌تواند دوباره برگردد.
برای رفع هک وردپرس باید ابتدا خسارت را محدود کنید، از وضعیت فعلی سایت و شواهد فنی بکاپ نگه دارید، دسترسی‌های غیرمجاز را مسدود و سپس فایل‌ها، پایگاه داده و تنظیمات سرور را بررسی کنید. در این راهنما، مراحل را به ترتیبی توضیح می‌دهیم که احتمال از بین رفتن اطلاعات مهم یا بازگشت آلودگی کمتر شود.
اول مشخص کنید با چه نوع نفوذی روبه‌رو هستید
هر رفتار غیرعادی حتما به معنی هک شدن سایت نیست، اما بعضی نشانه‌ها باید جدی گرفته شوند. پیش از هر تغییری، نشانه‌هایی را که مشاهده کرده‌اید ثبت کنید.
- صفحات سایت به دامنه‌های ناشناس هدایت می‌شوند یا محتوای اسپم در نتایج جستجو دیده می‌شود.
- حساب کاربری مدیر جدیدی ساخته شده یا نقش یکی از کاربران بدون اجازه تغییر کرده است.
- فایل‌های PHP ناشناس یا کدهای غیرقابل‌توضیح در فایل‌های قالب، افزونه یا پوشه آپلودها پیدا می‌شوند.
- صفحات، لینکهای داخلی، تنظیمات وردپرس یا کدهای سایت بدون اطلاع شما تغییر کرده‌اند.
- هاست به دلیل ارسال اسپم، توزیع بدافزار یا فعالیت مشکوک، سایت را محدود کرده است.
- مصرف CPU، تعداد درخواست‌ها یا ارسال ایمیل‌ها به شکل غیرعادی افزایش یافته است.
- مرورگر، ابزار امنیتی یا موتور جستجو درباره خطرناک بودن سایت هشدار می‌دهد.
اگر فقط سایت کند شده یا خطای 500 نمایش داده می‌شود، این موارد به‌تنهایی اثبات‌کننده نفوذ نیستند. لاگ‌ها، تغییرات فایل‌ها و فعالیت کاربران را بررسی کنید تا بین مشکل فنی و رخداد امنیتی تفاوت بگذارید.
مرحله اول، در دقایق ابتدایی خسارت را محدود کنید
وقتی احتمال نفوذ جدی است، هدف اول این نیست که سایت را در سریع‌ترین زمان ممکن دوباره آنلاین کنید. هدف این است که مهاجم نتواند به فعالیت ادامه دهد و اطلاعات بیشتری از دست نرود.
۱. اگر حمله فعال است، دسترسی عمومی را موقتا محدود کنید
اگر سایت به بازدیدکنندگان بدافزار تحویل می‌دهد، کاربران را به صفحات جعلی هدایت می‌کند یا از سرور برای ارسال اسپم استفاده می‌شود، با کمک پشتیبانی هاست دسترسی عمومی را به طور موقت محدود کنید. می‌توان از صفحه نگهداری امن، محدودسازی دسترسی در وب‌سرور یا قرنطینه حساب میزبانی استفاده کرد.
در سایت فروشگاهی یا سامانه‌ای که سفارش و پرداخت فعال دارد، پیش از قطع کامل دسترسی، پیامدهای آن را در نظر بگیرید. در صورت مشاهده نشانه‌های سرقت اطلاعات پرداخت یا داده‌های شخصی، موضوع را به مسئول امنیت و ارائه‌دهنده درگاه پرداخت اطلاع دهید و الزامات قانونی مرتبط را بررسی کنید.
۲. اگر سرور یا چند سایت درگیرند، از هاست کمک بگیرید
اگر به SSH یا کنترل‌پنل دسترسی ندارید، یا احتمال می‌دهید حساب میزبانی و سایر سایت‌های همان حساب آلوده شده‌اند، موضوع را فوری به شرکت هاستینگ اعلام کنید. از آن‌ها بخواهید لاگ‌های وب‌سرور، ورود به کنترل‌پنل، دسترسی SSH و FTP، وضعیت پردازش‌های مشکوک و نسخه‌های بکاپ موجود را حفظ کنند.
مرحله دوم، قبل از پاک‌سازی شواهد را حفظ کنید
یکی از اشتباه‌های رایج این است که مدیر سایت بلافاصله فایل‌های مشکوک را حذف می‌کند، همه افزونه‌ها را پاک نموده یا وردپرس را از نو نصب می‌کند. این کار ممکن است بعضی آثار نفوذ را از بین ببرد و تشخیص زمان و مسیر ورود مهاجم را دشوارتر کند.
پیش از پاک‌سازی، در صورت امکان این موارد را نگه دارید:
- نسخه کامل فایل‌های سایت: شامل فایل‌های مخفی، پوشه‌های وردپرس، فایل‌های خارج از مسیر عمومی و تنظیمات مرتبط، در صورت دسترسی.
- نسخه پایگاه داده: از پایگاه داده فعلی خروجی بگیرید تا کاربران، تنظیمات، محتوای تغییرکرده و داده‌های مشکوک قابل بررسی باشند.
- لاگ‌های سرور: لاگ دسترسی و خطای وب‌سرور، لاگ PHP، ورودهای SSH یا FTP و گزارش‌های کنترل‌پنل را در صورت موجود بودن ذخیره کنید.
- اطلاعات رخداد: زمان مشاهده اولین نشانه، تغییرات اخیر، هشدارهای دریافتی، IPهای مشکوک و نام فایل‌های غیرعادی را یادداشت کنید.
- نسخه‌های بکاپ قدیمی: بکاپ‌های پیش از زمان احتمالی نفوذ را جدا نگه دارید و بدون بررسی، آن‌ها را روی سایت اصلی بازگردانی نکنید.
نسخه شواهد را در محلی جدا از حساب مشکوک نگه دارید و تا حد امکان دسترسی نوشتن به آن را محدود کنید. اگر امکان دارد، تاریخ تهیه نسخه و هش فایل‌های آرشیو را ثبت کنید. فایل‌های آلوده را روی رایانه روزمره اجرا نکنید و اگر احتمال سرقت اطلاعات مشتریان یا دسترسی سطح سرور وجود دارد، بررسی تخصصی را در اولویت قرار دهید.
مرحله سوم، دسترسی‌های مهاجم را از مسیر درست ببندید
تغییر رمز عبور وردپرس مفید است، اما اگر مهاجم به ایمیل مدیر، حساب هاست، کلید SSH یا کامپیوتری که رمزها در آن ذخیره شده‌اند دسترسی داشته باشد، تغییر یک رمز به‌تنهایی مشکل را حل نمی‌کند. بهتر است ابتدا از یک دستگاه سالم و قابل اعتماد اقدام کنید.
ترتیب پیشنهادی برای ایمن‌سازی حساب‌ها
- ایمیل مدیر و حساب‌های بازیابی: رمز عبور ایمیل مرتبط را تغییر دهید، نشست‌های فعال ناشناس را ببندید و روش‌های بازیابی یا قوانین انتقال ایمیل مشکوک را بررسی کنید.
- کنترل‌پنل و حساب میزبانی: رمز ورود کنترل‌پنل، حساب مشتری شرکت هاستینگ و دسترسی‌های مدیریتی مرتبط را تغییر دهید. ورودهای ناشناس و کاربران اضافی را بررسی کنید.
- SSH، SFTP و FTP: رمزهای استفاده‌شده را تعویض کنید، کلیدهای SSH ناشناس را حذف کنید و حساب‌هایی را که دیگر لازم نیستند غیرفعال کنید. اگر FTP بدون رمزنگاری استفاده می‌شده، به SFTP یا روش امن مورد پشتیبانی هاست مهاجرت کنید.
- کاربران وردپرس: حساب‌های مدیر ناشناس را ثبت و بررسی کنید، سپس دسترسی غیرمجاز را لغو کنید. کاربران معتبر را با مالک سایت تطبیق دهید.
- پایگاه داده: اگر احتمال افشای اطلاعات اتصال وجود دارد، رمز کاربر پایگاه داده را تغییر دهید و مقدار متناظر آن را در فایل
wp-config.phpبه‌روز کنید. - کلیدهای امنیتی وردپرس: پس از مهار نفوذ، کلیدها و saltهای احراز هویت را با مقادیر تصادفی جدید جایگزین کنید تا نشست‌های ورود قبلی باطل شوند.
اگر هنوز فایل‌های آلوده یا دسترسی پنهان در سایت وجود دارد، ممکن است مهاجم بتواند دوباره رمزها یا حساب‌ها را تغییر دهد. به همین دلیل، بعد از مهار اولیه، پاک‌سازی و بررسی مسیر نفوذ را کامل کنید و سپس یک بار دیگر اعتبارنامه‌ها را تغییر دهید. راهنمای رسمی وردپرس هم بر تغییر دوباره رمزها پس از پاک شدن سایت تاکید می‌کند.
مرحله چهارم، فایل‌های آلوده و تغییرات مشکوک را پیدا کنید
فایل آلوده همیشه نام عجیب یا پسوند غیرمعمول ندارد. مهاجم ممکن است کد مخرب را به انتهای یک فایل معتبر اضافه کند، فایل هسته وردپرس را تغییر دهد یا اسکریپتی با نامی شبیه فایل‌های عادی بسازد. بنابراین، فقط حذف فایل‌هایی که نام تصادفی دارند کافی نیست.
از این مسیرها شروع کنید
- ریشه سایت: فایل‌های تازه‌ساخته‌شده، فایل‌های مخفی و تغییرات غیرمنتظره در
.htaccess،index.phpو فایل‌های پیکربندی را بررسی کنید. - هسته وردپرس: فایل‌های
wp-adminوwp-includesرا با نسخه رسمی و همسان وردپرس مقایسه کنید. تغییرات ناشناخته در این مسیرها نیازمند بررسی دقیق‌اند. - قالب فعال و فرزند: فایل‌های
functions.php،header.php،footer.phpو فایل‌های PHP دیگر را از نظر تغییرات غیرمجاز بررسی کنید. - افزونه‌ها: افزونه‌های ناشناس، نسخه‌های قدیمی، افزونه‌های غیرفعال اما باقی‌مانده و فایل‌هایی را که خارج از بسته اصلی افزونه قرار گرفته‌اند بررسی کنید.
- پوشه آپلودها: در
wp-content/uploadsدنبال فایل‌های اجرایی غیرمنتظره، به‌ویژه فایل‌های PHP باشید. البته وجود هر فایل خاص به‌تنهایی اثبات‌کننده آلودگی نیست و باید با ساختار سایت تطبیق داده شود. - فایل‌های خارج از وردپرس: اگر چند سایت در یک حساب میزبانی قرار دارند، مسیرهای مشترک، اسکریپت‌های زمان‌بندی‌شده و فایل‌های سطح حساب را هم بررسی کنید.
برای تشخیص بهتر، تاریخ تغییر فایل‌ها را با زمان رخداد و لاگ‌های دسترسی تطبیق دهید. تاریخ فایل به‌تنهایی مدرک قطعی نیست، چون می‌تواند تغییر کند یا هنگام انتقال سایت بازنویسی شود. فایل‌های هسته و افزونه‌ها را با نسخه سالم و رسمی همان نسخه مقایسه کنید، نه با نسخه‌ای متفاوت که ممکن است تغییرات طبیعی داشته باشد.
بررسی اولیه از طریق SSH
اگر SSH دارید و مسیر نصب وردپرس را می‌شناسید، می‌توانید برای فهرست کردن فایل‌های PHP که اخیرا تغییر کرده‌اند از دستور زیر استفاده کنید. در این مثال، مسیر را با مسیر واقعی سایت جایگزین کنید:
find /path/to/wordpress -type f -name '*.php' -mtime -7 -printاین دستور فقط فایل‌های PHP تغییرکرده در هفت روز گذشته را فهرست می‌کند و به معنی آلوده بودن آن‌ها نیست. اگر زمان نفوذ را نمی‌دانید یا فایل‌ها از قبل تغییر کرده‌اند، بازه زمانی را تنظیم نموده و نتیجه را با نسخه سالم، لاگ‌ها و تغییرات شناخته‌شده مقایسه کنید.
برای بررسی تغییرات هسته وردپرس، در صورت نصب بودن WP-CLI و دسترسی مناسب می‌توانید اجرا کنید:
wp core verify-checksums --include-rootاین بررسی می‌تواند تفاوت فایل‌های هسته با چک‌سام‌های رسمی را نشان دهد، اما جایگزین بررسی دستی همه فایل‌ها، افزونه‌ها، قالب‌ها و پایگاه داده نیست. اگر وردپرس به‌صورت سفارشی تغییر کرده باشد، تفاوت‌ها را پیش از جایگزینی بررسی کنید.
مرحله پنجم، پایگاه داده را از قلم نیندازید
گاهی فایل‌های سایت سالم به نظر می‌رسند، اما محتوای مخرب همچنان در دیتابیس باقی مانده است. مهاجم ممکن است کاربران مدیر ایجاد کرده باشد، کد یا پیوند اسپم به محتوا اضافه کرده باشد یا تنظیمات سایت را تغییر داده باشد.
- کاربران دارای نقش مدیر را با فهرست کاربران مجاز مقایسه کنید.
- تنظیمات نشانی سایت، صفحه اصلی، افزونه‌های فعال و گزینه‌های غیرمنتظره را بررسی کنید.
- نوشته‌ها، برگه‌ها، ابزارک‌ها و محتوای قابل نمایش در سایت را از نظر پیوندها و اسکریپت‌های ناشناس بررسی کنید.
- اگر سایت فروشگاهی است، تغییرات غیرمجاز در تنظیمات پرداخت، کاربران و داده‌های سفارش را جدی بگیرید.
- برای جستجوی کد مخرب در پایگاه داده از بکاپ و ابزارهای مناسب استفاده کنید. جایگزینی گروهی عبارت‌ها بدون بررسی می‌تواند داده‌های معتبر را خراب کند.
در صورت نیاز به اصلاح مستقیم پایگاه داده، ابتدا از آن Export بگیرید و تغییرات را در محیط آزمایشی بررسی کنید. حذف گسترده رکوردها یا اجرای کوئری‌هایی که مفهوم آن‌ها را نمی‌دانید می‌تواند باعث از دست رفتن اطلاعات یا از کار افتادن سایت شود.
مرحله ششم، سایت را از منبع سالم بازیابی کنید
پس از مشخص شدن دامنه آلودگی، باید تصمیم بگیرید فایل‌ها را بازسازی کنید یا نسخه بکاپ سالم را برگردانید. هیچ روشی برای همه سایت‌ها مناسب نیست، اما چند اصل در هر دو حالت اهمیت دارد.
چه زمانی بازگردانی بکاپ مناسب است؟
اگر نسخه‌ای از سایت دارید که با شواهد موجود، پیش از نفوذ تهیه شده است، بازگردانی آن می‌تواند مسیر بازیابی را کوتاه کند. با این حال، قبل از بازگردانی بررسی کنید که بکاپ واقعا سالم باشد، تاریخ آن با زمان احتمالی نفوذ هم‌خوانی داشته باشد و مسیر ورود مهاجم در نسخه بازیابی‌شده همچنان باز نماند.
اگر از زمان بکاپ تا زمان حادثه سفارش، فرم، عضویت یا محتوای جدید ثبت شده، برای جلوگیری از حذف داده‌های معتبر، روش بازیابی را با دقت انتخاب کنید. در سایت‌های فروشگاهی، بازگردانی کل پایگاه داده قدیمی ممکن است سفارش‌های ثبت‌شده پس از تاریخ بکاپ را از بین ببرد.
چه زمانی فایل‌ها باید از نو جایگزین شوند؟
اگر فایل‌های هسته وردپرس تغییر کرده‌اند، می‌توان آن‌ها را با نسخه رسمی و سازگار جایگزین کرد. افزونه‌ها و قالب‌ها را از منبع معتبر و نسخه سالم تهیه کنید. فایل‌های اختصاصی، قالب فرزند و تغییرات سفارشی باید جداگانه بررسی شوند تا قابلیت‌های سالم سایت از بین نروند.
از کپی کردن دوباره کل پوشه سایت آلوده روی یک نصب تازه خودداری کنید. چنین کاری ممکن است همان فایل مخرب را به محیط جدید منتقل کند. به‌جای آن، اجزای مورد نیاز را انتخابی و پس از بررسی منتقل کنید و فایل‌های اجرایی ناشناس را از بکاپ قدیمی به سایت جدید بازنگردانید.
مرحله هفتم، راه بازگشت مهاجم را ببندید
حذف بدافزار تنها زمانی نتیجه پایداری دارد که علت نفوذ هم برطرف شود. در غیر این صورت، ممکن است چند ساعت یا چند روز بعد دوباره همان علائم ظاهر شوند.
- به‌روزرسانی هدفمند: وردپرس، افزونه‌ها، قالب و نسخه PHP را به نسخه‌های پشتیبانی‌شده و سازگار ارتقا دهید. افزونه یا قالب بدون منبع معتبر را حذف کنید.
- حذف دسترسی‌های اضافی: کاربران ناشناس، حساب‌های قدیمی، کلیدهای SSH و دسترسی‌های FTP غیرضروری را حذف یا غیرفعال کنید.
- بررسی وظایف زمان‌بندی‌شده: کران وردپرس و cronهای سطح سرور را برای دستورهای ناشناس یا اجرای فایل‌های مشکوک بررسی کنید.
- بررسی تنظیمات میزبانی: فایل‌های پیکربندی، قوانین بازنویسی، فایل‌های مخفی و تنظیمات PHP را بازبینی کنید.
- محدود کردن مجوز نوشتن: مجوز فایل‌ها و پوشه‌ها را مطابق ساختار واقعی میزبانی تنظیم کنید. مجوزهای بیش از حد باز مانند
777را بدون دلیل فنی استفاده نکنید. - ایمن‌سازی حساب‌ها: احراز هویت دومرحله‌ای را برای مدیران فعال کنید، رمزهای تکراری را کنار بگذارید و ویرایش فایل‌های قالب و افزونه از پیشخوان را در صورت سازگاری با روند مدیریت سایت محدود کنید.
اگر سایت روی هاست اشتراکی است و احتمال می‌دهید حساب دیگری در همان محیط درگیر شده باشد، از شرکت میزبانی بخواهید محدوده رخداد را بررسی کند. پاک‌سازی یک نصب وردپرس نمی‌تواند آسیب‌پذیری احتمالی در حساب، سرور یا سایت دیگری را برطرف کند.
چه زمانی می‌توان سایت را دوباره آنلاین کرد؟
بازگشت سایت به دسترس عموم باید پس از بررسی انجام شود، نه فقط به این دلیل که صفحه اصلی باز می‌شود. پیش از پایان کار، این موارد را بررسی کنید:
- فایل‌های اصلی، قالب و افزونه‌ها با نسخه‌های سالم مقایسه شده‌اند و فایل مشکوک حل‌نشده باقی نمانده است.
- کاربران مدیر، تنظیمات مهم و داده‌های پایگاه داده بررسی شده‌اند.
- رمزها و کلیدهای لازم تغییر کرده‌اند و دسترسی‌های ناشناس لغو شده‌اند.
- مسیر نفوذ تا حد امکان شناسایی و عامل آن، مانند افزونه آسیب‌پذیر یا اعتبارنامه افشاشده، برطرف شده است.
- صفحات مهم، فرم‌ها، ورود کاربران، سفارش‌ها و فرایند پرداخت آزمایش شده‌اند.
- گزارش‌های سرور پس از بازگشت سایت برای نشانه‌های تکرار حمله بررسی می‌شوند.
اگر گوگل سایت را به‌عنوان خطرناک علامت‌گذاری کرده است، پس از پاک‌سازی و اطمینان از رفع مشکل، وضعیت امنیتی را در Google Search Console بررسی کنید و در صورت وجود هشدار امنیتی، درخواست بازبینی ثبت کنید. ثبت درخواست به‌تنهایی تضمین نمی‌کند که هشدار فورا برداشته شود.
اگر سایت دوباره هک شد، چه چیزی را بررسی کنید؟
بازگشت آلودگی معمولا نشانه آن است که بخشی از مشکل حل نشده است. ممکن است فایل مخرب دیگری باقی مانده باشد، دسترسی مهاجم هنوز فعال باشد، افزونه آسیب‌پذیر به‌روزرسانی نشده باشد یا منبع آلودگی خارج از پوشه وردپرس قرار داشته باشد.
در این وضعیت، به‌جای تکرار پاک‌سازی سطحی، زمان ایجاد دوباره فایل‌ها را با لاگ‌های سرور تطبیق دهید، حساب‌های سطح هاست را بررسی کنید و مشخص کنید آیا فایل‌ها از یک درخواست وب، وظیفه زمان‌بندی‌شده، حساب کاربری یا سایت دیگری بازسازی می‌شوند. در رخدادهای پیچیده، تحلیل تخصصی سرور و پایگاه داده می‌تواند از پاک‌سازی‌های تکراری و پرهزینه جلوگیری کند.
چه زمانی رفع هک وردپرس را به متخصص بسپارید؟
اگر سایت شما اطلاعات مشتریان را نگهداری می‌کند، درگاه پرداخت دارد، چند سایت روی یک حساب میزبانی قرار گرفته‌اند یا پس از پاک‌سازی دوباره آلوده می‌شود، بهتر است بررسی را به متخصص امنیت و بازیابی سایت بسپارید. همین موضوع درباره شرایطی صدق می‌کند که به لاگ‌های سرور دسترسی ندارید، فایل‌های زیادی تغییر کرده‌اند یا احتمال نفوذ به حساب میزبانی وجود دارد.
در فرایند بازیابی، فقط حذف بدافزار مهم نیست. شناسایی مسیر نفوذ، بررسی فایل‌ها و پایگاه داده، بستن دسترسی‌های غیرمجاز و کنترل رفتار سایت پس از بازگشت به دسترس عمومی، بخش‌های اصلی یک پاک‌سازی قابل اعتماد هستند.
اگر سایت شما هک شده و برای شناسایی آلودگی یا بازیابی امن آن به کمک نیاز دارید، با سایت افزون تماس بگیرید و نشانه‌هایی را که مشاهده کرده‌اید توضیح دهید. اگر امکان دارد، زمان شروع مشکل و پیام‌های دریافتی از شرکت هاستینگ را هم آماده داشته باشید.
آیا با نصب افزونه امنیتی می‌توان سایت هک‌شده را پاک‌سازی کرد؟
افزونه امنیتی می‌تواند در شناسایی بعضی فایل‌های مشکوک و جلوگیری از حملات کمک کند، اما تضمینی برای کشف همه آلودگی‌ها نیست. فایل‌های خارج از وردپرس، تغییرات پایگاه داده و دسترسی‌های سطح سرور ممکن است به بررسی جداگانه نیاز داشته باشند.
آیا حذف فایل‌های مشکوک کافی است؟
خیر. باید مشخص شود فایل چگونه ایجاد شده و آیا نسخه دیگری از بدافزار، کاربر غیرمجاز یا دسترسی فعال باقی مانده است. بدون رفع مسیر نفوذ، امکان بازگشت آلودگی وجود دارد.
آیا باید وردپرس را از ابتدا نصب کنم؟
در بعضی رخدادها جایگزینی فایل‌های هسته و اجزای آلوده با نسخه سالم منطقی است، اما نصب مجدد به‌تنهایی تضمین‌کننده پاک شدن سایت نیست. پایگاه داده، پوشه آپلودها، افزونه‌ها، قالب‌ها، فایل‌های خارج از ریشه وردپرس و دسترسی‌های هاست هم باید بررسی شوند.
بعد از پاک‌سازی چه زمانی رمزها را تغییر دهم؟
دسترسی‌های مشکوک را در مرحله مهار اولیه محدود کنید، اما پس از پاک‌سازی و اطمینان از رفع مسیر نفوذ، رمزها و کلیدهای مرتبط را دوباره تغییر دهید. این کار احتمال استفاده دوباره از اطلاعات افشاشده را کاهش می‌دهد.
چطور از هک شدن دوباره سایت جلوگیری کنم؟
به‌روزرسانی منظم وردپرس و افزونه‌ها، استفاده از منابع معتبر، رمزهای یکتا، احراز هویت دومرحله‌ای، بکاپ‌های مستقل و قابل آزمایش، محدود کردن دسترسی‌ها و بررسی لاگ‌ها احتمال تکرار رخداد را کاهش می‌دهند. امنیت سایت یک اقدام یک‌باره نیست و به نگهداری مستمر نیاز دارد.
