کشتن همه‌ی پروسس های دیتابیس mysql

سلام

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

اگر همچین دستوری رو روی یک دیتابیس slave بزنید، یادتون نره که باید مجدد وارد دیتابیس بشید و کاری کنید که کارش رو ادامه بده (START SLAVE) در غیر اینصورت دیتابیس از سینک خارج خواهد شد.

haproxy و ردیس کلاستر

ردیس یک محدودیت خیلی مهمی داره و اون اینکه single thread  و برای همین نمی‌تونه  بیشتر از  یک core از پردازشگر رو استفاده کنه. یکی از راه‌حل‌های روتین استفاده از کلاستر ردیس که عملا اطلاعات بین چند node ردیس پخش میشه(sharding)‌. نکته مهم اینه که در این مدل شما چند نود ردیس به شکل master  دارید که هر کدوم از اونها باید دست کم یک slave داشته باشند تا در صورتیکه یک نود به هر دلیل از دسترس خارج شد، نود slave به صورت خودکار وارد بازی بشه.

در این پروسه  هیچ تضمینی برای اینکه اطلاعات از دست نره (در زمان از دست رفتن نود master)‌ وجود نداره! دلیلش اینه که شما اطلاعات رو روی node مستر می‌نویسید، نود مستر به کلاینت میگه اوکی دیتا رو دارم و بعد تازه میره دنبال اینکه دیتا  روی نود slave هم ذخیره بشه. :)‌

این رو هم بگم که برای اینکه دیتا به شکل مساوی بین node های مستر پخش بشه، کلاستر ردیس از چیزی به اسم SLOT استفاده میکنه. در مجموع ۱۶۳۸۴ اسلات ردیس کلاستر داره که بسته به تعداد node هایی که داریم میاییم اسلات ها رو بین نودها تقسیم میکنیم.

کلاینت در صورتی که به یک node (مستر) درخواست بده واطلاعات روی اون  نباشه، بجای اینکه کلید درخواستی رو بده، اطلاعات nodeی رو  که کلید داره رو میده و دوباره کلاینت باید به اون دومی درخواست بده 🙂  و  این میشه همون سربار یا overhead که ردیس کلاستر به ردیس معمولی داره بعلاوه اینکه یک سری محدودیت ها رو هم خواهید داشت مثل اینکه نمیشه از قابلیت Geo location ردیس استفاه کنید .

حالا نکته اینجاس که اگر کلاینت به یک نود مستر وصل شه و اون نود به هر دلیل داون بشه، هر چند slave به شکل خودکار تبدیل به مستر میشه، اما دیگه کلاینت از اون نود اطلاعی نداره!‌ برای حل این مشکل از لودبالانس HAPROXY استفاده میکنیم.

خودم haproxy رو به دلایل خیلی زیادی با داکر همیشه بالا میارم که کار رو خیلی ساده میکنه و برای اینکار هم لازم نیست همه چی رو از اول بسازیم، از یک داکر اماده استفاده میکنیم.

و بعد باید اون رو build کنیم.

قبل از اجرای تنظیمات باید یک کانفیگ haproxy ایجاد کنیم که اون رو به خورد کانتینر بدیم.

بخش frontend باعث میشه haproxy روی پورت  ۶۳۷۹ لیستن کنه و هر ترافیکی هم که به سمتش بیاد رو به  backend پیشفرضی که تعریف کردیم، بفرسته.

در بخش backend که قلب اصلی سیستم، haproxy  به نودهای فقط master ترافیک رو می‌فرسته. نکته قشنگ کار اینه که در اینجا همه نود های redis چه مستر و چه slave رو میدیم و از haproxy میخوایم بره وضعیت نودها رو خوش در بیاره. haproxy هم هر یک ثانیه میره از نودهای ردیس میپرسه که شما مسترسی یا salve  و اونها هم اگر جواب بدند مستر، به رنگ سبز در میان و اگر slave باشند دیگه از دور خارج میشند و عملا ترافیکی به سمت اونها نمیره 🙂

در بخش stats هم که صرفا امار haproxy رو فعال کردیم و کار مهمی انجام نمیده، بخش اول nbproc هم نمایانگر تعداد core های سرور و اینجا با فرض اینکه سرور هفت core پردازشی داره، شش تا از اونها رو بدین شکل به خورد haproxy میدیم 🙂 haproxy هم مشابه nginx میاد به تعداد core هایی که مشخص کردیم child میسازه.

و در نهایت داکر ha رو با کامند زیر اجرا می‌کنیم.

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

 

و در نهایت اینکه اگر سرورتون زیر بار خیلی زیادی حتما تنظیمات زیر داخل sysctl فراموش نشه.

 

مقایسه‌ی سه هارد ssd

در این مطلب سه هارد ssd مدل اینتل VK0480GEYJR (تحت برند HPE)  و سامسونگ مدل MZ7KM480 و   SSD 960 PRO 512GB رو مقایسه می‌کنیم.

MZ7KM480

دو مدل اول به ریدکنترلر متصل هستند و برای دیدن نتایج واقعی  cahce ریدکنترلر خاموش است. مدل سوم روی pci express سرور سوار  است و فقط os اون رو می‌بینه.

دو  تست روی هاردهای ssd انجام می‌دیم.در تست اول برای کاری که تخصص دارند و اون نوشتن و خواندن Random هست و دیگری حالت Sequential که برای دیسک‌های معمولی هم کار راحتی و معمولا حیف برای اینجور کارها بخوایم از ssd استفاده کنیم.

هارد ssd اینتل

نکته اول اینکه با fio سعی کردیم حالت واقعی سرور رو شبیه‌سازی کنیم ۷۵ درصد read و ۲۵ درصد write. مهمترین بخش هم iops هست.

iops=48009 برای read و iops=16010 برای رایت.

برای تست دوم از dd استفاده میکنیم. نکته مهم اینه که oflag=dsync   به ازای هر تیکه‌ای که میخواد روی هارد بنویسه (۵۱۲ بار می‌پرسه) تاییدیه از os میگره. اما conv=fdatasync تنها یکبار در انتهای نوشتن و هنگام خروج از dd تاییدیه از os گرفته میشه.

 

هارد ssd سامسونگ مدل MZ7KM480

iops=67811 برای read و iops=22613 برای رایت. که نشون میده در میون هاردهای ssd سرور  سامسونگ از مدل اینتل پیشی گرفته.

در این تست هم سامسونگ برنده شده.

 

و اما مدل دیگه سامسونگ pro 960 که از پیش حدس می‌زنیم سرعت خیلی بالاتری داشته باشه.

سامسونگ pro 960

این هارد خوب iops=176350 برای read و iops=58808 رو برای نوشتن به ما میده که البته فاصله خیلی زیادی با اعدادی داره که سامسونگ ادعا میکنه :)‌

و در کمال تعجب میشه دید که این ssd  در حالت sequential خیلی هم خوب کار نمیکنه 🙂

 

ویرایش فایل‌های درون کانتینر داکر از روی هاست اصلی

سلام سلام

نمی‌دونم چی شد چطور شد یکهو دوباره یاد به روز کردن وبلاگ افتادم 🙂 به هر حال آدمیزاد دیگه و کاریش نمیشه کرد.

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

اما این وسط یک نکته خیلی مسخره‌ وجود داره، وقتی داکر اجراست، هر چی فایل موجود روی هاست اصلی (در اینجا  haproxy.cfg)  رو  تغییر بدید، تغییرات رو داخل کانتینر مشاهده نمی‌کنید و مجبور می‌شید که داکر رو استاپ کنید و دوباره اجرا که برای یک کانتینر مثل haproxy که نقش لودبالانس رو داره این گزینه اصلا خوب نیست.

اما اگه توی مسیر خونگی فایل ‫.vimrc رو ایجاد کنید و داخلش خط زیر رو بگذارید و البته اگر ادیتور vim استفاده کنید این مشکل رو دیگه نخواهید داشت :)‌

 

کاری هم که این یک خط انجام میده رو اینجا کامل توضیح دادند. خلاصه‌ش اینه که هر فایلی که روی هارد وجود داره یک inode داره و وقتی با vim فایل رو ادیت میکنید، inode فایل هم تغییر میکنه اما فایلی که داخل کانتینر وجود داره هنوز به همون inode قبلی اشاره میکنه و برای همین هر چی هم که فایل رو تغییر میدیم، هیچ اثری از تغییر وجود نداره (مگر اینکه کانتینر رو به کل استاپ کنیم و بعد دوباره اجرا کنیم)‌. اما با اضافه کردن این یک خط ادیتور vim رو مجبور میکنیم که تغییرات رو روی همون inode قبلی ذخیره کنه 🙂

 

اما یک نکته بامزه دیگه هم وجود داره و اون اینکه اگر پرمیشن  فایل روی هاست اصلی رو به ۷۷۷  تغییر بدید یک جورایی مشکل حل میشه که باز دلیلش رو میتونید از اینجا بخونید :))

 

 

چقدر از کاربرای خونگی در خطر از دست دادن اطلاعات شخصی‌شون هستن؟

توی پست قبلی مطلبی در مورد امنیت ضعیف مودم‌های تی‌پی‌لینک نوشته بودم که به نظر اونطور که باید و شاید توجه رو به سمت خودش جلب نکرد.

برای همین در ادامه‌ی اون پست، این مطلب رو اینجا میذارم تا یک مقدار بیشتر با خطراتی که کاربران خونگی رو تهدید میکنه آشنا کنم.

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

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

Selection_026

با رفتن به آدرس http://ping.eu/ns-whois و دادن آی‌پی ولید خودتون، می‌تونید یک رنج از آی‌پی‌های ولید isp  رو بدست بیارید.

Selection_024

با کمی جستجو در اینترنت به اسکریپت زیر می‌رسیم که رنج ابتدایی و انتهایی ip رو میگیره و در انتها تمام ipهای بینش رو برامون تولید میکنه (خروجی برنامه‌ی زیر سی و پنج هزار آی‌پی هست). 
Selection_025

حالا کافیه به طریقی این آی‌پی‌ها رو به خورد اسکریپت اصلی بدیم که پسوردها رو قراره در بیاره برامون.

برای اینکار از برنامه‌ی xargs استفاده می‌کنیم. xargs خروجی یک برنامه رو میگیره و به صورت آرگومان به برنامه‌ای که مدنظرمونه میده. حالت پیشفرض xargs،‌ خروجی  به آخر برنامه اضافه میکنه. اگه بخوایم خروجی رو به وسط  کامندی که اجرا میکنیم، اضافه کنه از خروجی -I به همراه یک نام (place holder) استفاده مینیم.

 

کامند بالا علارغم ظاهر خیلی پیچیده‌ای که داره خیلی ساده عمل میکنه.

قلب اصلی  همون novid.py که فقط یک ip میگیره و قراره پسورد رو بهمون برگردونه. با اسکریپت Ip.sh و کمک برنامه xargs تعداد زیادی ip رو داریم به خوردش می‌دیم.

اما به دلایل مختلف ممکنه برنامه پیغام‌های خطایی رو برگردونه که اونها رو داریم به dev/null میریزیم (به جای نمایش اونها در صفحه نمایش). سر بعضی از آی‌پی‌ها برنامه کلا متوقف میشه و دیگه جلو نمیره. برای جلوگیری از این اتفاق از timeout استفاده میکنیم و  میگیم حالت نرمال برای پیدا کردن پسورد یک روتر زیر ۲۰ ثانیه‌ست. اگه بیشتر از این زمان برد، بیخیال اون آی‌پی بشو و برو سراغ بعدی.

xargs با استفاده از خروجی -I  به جای اینکه هر آی‌پی رو  انتهای کامند یعنی grep Router بیاره، اونها رو وسط کامند دونه دونه به برنامه میده! {}صرفا یک نام هست که می‌دونیم در کامندی که قراره بارها اجرا بشه هیچ استفاده‌ای نمیشه، میشه به جای اون هر چیز دیگه‌ای هم استفاده کرد.

اون بخش grep رو برای این گذاشتم که برنامه بعد از پیدا کردن پسورد روتر چند خط رو به عنوان خروجی بر میگردونه. پسورد نیز در خطی قرار داره که کلمه‌ی Router وجود داره.

بعد چند ساعت صبر و بسته به سرعت اینترنت، به کلی پسورد روتر خواهید رسید!

Selection_028جالبه در خیلی پسوردها، نام isp داتک رو میتونستم ببینم که مشخص بود تنظیمات رو خود داتک بر روی روتر طرف انجام داده. بسیاری هم شماره تلفن خونه‌شون رو به عنوان پسورد انتخاب کرده بودن که خیلی راحت میشه به اطلاعات بیشتری از فرد دست پیدا کرد.

کار قشگ دیگه ای که میشه انجام داد اینه که ببینیم بیشترین پسوردی رو که ملت استفاده میکنن چیه؟

برای اینکار با کمی جستجو به اسکریپت count_all_words.py میرسیم.

کافیه همه پسوردها رو در یک فایل به نام PASSWDUSERS.txt ذخیره کنیم و بعد اسکریپت رو اجرا کنیم. برای استخراج پسورد از لیستی که در اختیار داریم، کامند زیر رو اجرا میکنیم.

و برای شمارش تعداد پسوردها نیز اسکریپت count_all_words.py رو اجرا کنیم.

 

جامعه‌ی کاربری بالا ۶۵۵ مورد و همگی از isp داتک بوده. جستجو هم روی ۸۲۰۰ آی‌پی صورت گرفته. نکته اما اینه که همه‌ی این ۸۲۰۰  ip بالا نبودن و اگه آی‌پی‌هایی که در زمان جستجو داون بودن رو حذف کنیم به درصد خیلی خیلی بالایی میرسیم که آسیب‌پذیر هستن. در یک رنج آی‌پی ۲۵۶ تایی تقریبا صد تا از کاربران آنلاین هستن و از این تعداد پسورد ۴۰ تا کاربر رو میشه در اورد. با تقریب خوبی میشه گفت ۴۰ درصد کاربرای داتک این مشکل رو دارن و احتمالا خودشون هم اطلاعی از این وضعیت ندارند!‌

خب حالا اینکه مشخص شد که تعداد خیلی زیادی از روترها مشکل دارن که چی؟ اول اینکه تا جای ممکن سعی کنید دسترسی به روتر از دنیای اینترنت رو غیر ممکن کنید.  هیچ دلیلی نداره که یک کاربر خونگی روترش از بیرون قابل دیدن باشه. برای اینکار روترها گزینه‌های متنوعی دارن. تعدادی مشخصا گزینه‌ای دارن که دسترسی به روتر رو خیلی ساده غیرممکن میکنه از دنیای اینترنت. بعضی نیز بخشی به نام ACL دارن و بخشی نیز از طریق فایروال و بستن ترافیک ورودی این امکان رو برای شما فراهم میکنن. یک راه نیز اینه که تمام ترافیک ورودی به روتر رو به سمت یک آی‌پی داخل شبکه‌تون که وجود خارجی نداره هدایت کنید! برای اینکار در بخش dmz روتر باید یک آی‌پی در رنج شبکه داخلی بدید که البته وجود خارجی نداشته باشه.

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

سوال دیگه‌ای که پیش میاد اینه که با وارد شدن به روتر،‌فرد مهاجم میتونه چیکار کنه؟ جواب اینه که میتونه برنامه‌ای رو بنویسه که به صورت خودکار علاوه بر در اوردن پسورد روتر، به صورت گروهی بره و dns روتر رو هم تغییر بده. با تغییر dns عملا شما متوجه هیچ مورد مشکوکی نخواهید شد. کافیه فرد مهاجم dns چند ده هزار روتر رو تغییر بده. در زمان حمله نهایی، فرد مهاجم صفحه اول تمام بانکهای معروف رو میسازه و در یک زمان، میاد و ترافیک مثلا بانک‌ سامان و پارسیان و دیگر بانکها رو به سمت سرور خودش تغییر میده! و اینطوری میشه که بجای اینکه وارد سایت اصلی بانک سامان بشید، وارد نسخه‌ای میشید که هکر اون رو طراحی کرده. طبیعتا کسی وارد سایت دستکاری میشه که از dns سرور فرد مهاجم استفاده کنه. پس توصیه مهم دیگه اینه که همیشه برید dns های داخل روتر رو خودتون به شکلی دستی تنظیم کنید. اگه dns رو به صورت دستی تنظیم نکنید،‌ به صورت خودکار روتر اونها رو از سمت isp دریافت میکنه که به نظرم این گزینه هم عاقلانه نیست. اینجور حملات در گذشته در بسیاری از کشورهای دنیا هم اتفاق افتاده.

2014-02-mitr-en

یادتون نره حتی در صورت بستن راه ورود به روتر از طریق اینترنت، مهاجم میتونه حمله رو از طریق خودتون انجام بده. بدین صورت که با وارد شدن به یک سایت آلوده، خودتون تبدیل به یک مهاجم میشید و پسورد مودم خودتون رو ریست میدید! بعد برنامه‌ دیگه‌ای میتونه وارد روتر بشه و از طریق پسوردی که معلوم و مشخصه، dns رو تغییر بده! :)‌

csrf-router-attack-640x410راهکار چیه؟ جواب اینه که فرم‌ویر روتر خودتون رو به dd-wrt تغییر بدید. dd-wrt یک فرم‌ویر اپن سورس مبتنی بر کرنل لینوکس که با دنگ و فنگ و کمی خوش شانسی باید بتونید روی روتر خودتون نصب کنید. ریسک اینکار رو هم قبلش باید بپذیرید که دیگه روتر قابل استفاده نباشه. برای اینکه بفهمید dd-wrt روی روتر شما کار میکنه یا خیر کافیه به این آدرس برید و نام روتر خودتون رو وارد کنید.

راهکار دیگه استفاده از روتر در حالت بریج هست. و اینکه از روتر خوتون در حالت bridge استفاده کنید. در این صورت تنظیمات pppoe که بر روی روترهای ADSL وجود داره به روی سیستم متصل به روتر منتقل میشه و مودم تنها نقش یک پل رو خواهد داشت!‌ افراد داخل شبکه در اینحالت باید از طریق سرور متقل به روتر، ip بگیرن. دیوایسی که برای اینکار در نظر میگیرید باید دو تا پورت لن یا یک پورت لن و یک وایرلس داشته باشه. حالت قشنگش اینه که از رزبری پای استفاده کنید. رزبری پای کلا یک پورت Lan بیشتر نداره. بنابراین باید یک مبدل usp به lan یا wireless نیز داشته باشید. برای os هم می‌تونید از ipfire یا OpenWRT استفاده کنید که هر دوی اونها نسخه مخصوص ARM رو دارن.

openwrt-raspi-network

امنیت پایین روترهای تی‌پی‌لینک

بعد مدت‌ها عید فرصت خوبی ایجاد کرد که بالاخره دستی به وبلاگ بزنم و چه موضوعی بهتر از موضوع اسفناک مشتری ispهای ایران…

سالهاست که خودم کاربر داتک هستم و روز به روز شاهد افت کیفیت این شرکت ارائه دهنده‌ی اینترنت بودم که حالا مشکلات امنیتی هم به اون اضافه شد.

هر کاربر متصل به اینترنت یک ip ولید توی اینترنت داره که برای بدست اوردنش کافیه توی گوگل سرچ بزنید what is my ip.

اگه فرض  کنیم ای‌پی من در اینترنت ۱۷۶٫۴۶٫۱۳۶٫۱۲۸ باشه ، با تقریب خوبی میشه گفت که آی‌پی‌های در رنج ۱۷۶٫۴۶٫۱۳۶٫۱/۲۴  همه‌گی مشتری‌های داتک هستن. حالا کافیه بیاییم چک کنیم چه مقدار از این آی‌پی‌ها پورت ۸۰ شون بازه. برای اینکار از برنامه nmap استفاده میکنیم.

این لیست، کاربرایی رو شامل میشه که صفحه‌ی اصلی روترشون توسط مرورگر قابل مشاهده است. مگه اینکه پورت ۸۰ شون رو از طریق nat انتقال داده باشن به وب‌سرور داخلی. وقتی این آی‌پی‌ها رو توی مرورگر وارد کنید  فرم یوزر و پسورد براتون ظاهر میشه. مهاجم  در ساده‌ترین حالت با یوزر و پسورد پیش‌فرض admin میتونه وارد تنظیمات روتر بشه.

اما در مورد روترهایی که پسورد پیش‌فرض اونها admin نیست، یک روش استفاده از  brute force با استفاده از برنامه‌ی Hydra است. این برنامه می‌تونه با استفاده از یک دیکشنری،‌ دونه، دونه پسوردها رو با سرعت خیلی زیادی تست کنه.

 

با کامند بالا، برنامه‌ هیدرا به سرعت ۵۰۰ تا از بدترین پسوردهایی که کاربرا خیلی علاقه به انتخابشون رو دارن با یوزر admin به روش سعی و خطا تست میکنه و نتیجه کار رو بهتون میگه. طبیعیه که اگه لیست پسوردا خیلی طولانی باشه زمان اینکار هم بیشتر میشه (احتمالا).

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

برای پیدا کردن یوزر و پسورد در حالت ssh هم به شکل زیر از برنامه استفاده کنید.

 

لیستی از دیکشنری‌های معروف رو هم میتونید از اینجاها بگیرید.

http://trac.kismac-ng.org/wiki/wordlists
http://www.room362.com/projects/hugelist.txt
https://wiki.skullsecurity.org/Passwords

اما موضوعی که هست وجود یک exploit یا به عبارتی حفره در مودم‌های TP-Link که باعث میشه فرد مهاجم به راحتی بتونه هر پسوردی رو که ست کرده باشید در بیاره.

 


اسکریپت کارش اینه که بعد از بدست آوردن پسورد، روتر رو از کار میندازه و در اصل اون رو ریست میده! ولی خب بعد از روئیت پسورد خیلی راحت میشه از برنامه خارج شد تا روتر ریست نشه.

با اجرا کامند بالا همچین خروجی رو خواهیم داشت. Selection_002 دقت کنید در هنگامی که اسکریپت به سوال Decrypt the rom-0 file locally میرسه، y رو تایپ کنید تا پسورد رو در بیاره براتون. و بعد هم کافیه Ctrl + c رو بزنید تا از برنامه خارج شید.

و خب همه‌ی اینا رو گفتم که بدونید وضعیت چقدر داغونه. داتک فخیمه میتونه با یک فایروال خیلی ساده، پورت ۸۰ رو ببنده، همونطور که پورت ۸۰۸۰ رو الان بسته (احتمالا بخاطر وجود backdoor که روی این مودم‌ها و روی این پورت وجود داره) ! و البته خود کاربرا هم میتونن کلا دسترسی به روتر از طریق وب رو کاملا مسدود کنن که این امر نیاز به آگاه‌رسانی اونها داره.