مدیریت سرور توسط زاگریو

12 مزیت برون سپاری مدیریت سرور

مدیریت سرور، چرا و چگونه؟

در این مطلب قصد داریم به شما کمک کنیم که تصمیم بگیرید که آیا تامین خدمات مدیریت سرور توسط یک مجموعه تخصصی تاثیر و مزایایی برای کسب و کار شما خواهد داشت یا خیر

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

یک سرویس مدیریت شده از زبان PCMagazine بصورت خلاصه به معنای انجام زحمت کار بصورت حرفه ای و با تجهیزات و سامانه های به روز توسط مجموعه ای تخصصی در خارج از سازمان شماست.


1. صرفه‌جویی در زمان

مدیریت سرور نیازمند زمان زیادی برای نصب، پیکربندی، نظارت و رفع اشکال است. اگر بخواهید خودتان این کار را انجام دهید:

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

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


2. بهینه‌سازی هزینه‌ها

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

  • استخدام یک مدیر سرور داخلی هزینه بیشتری دارد (حقوق ثابت، مزایا و غیره).
  • ابزارها و نرم‌افزارهای نظارتی و امنیتی گران‌قیمت هستند، اما شرکت‌های تخصصی به‌صورت اشتراکی از این ابزارها استفاده می‌کنند و هزینه آن‌ها در بین مشتریان تقسیم می‌شود.
  • هزینه‌های ناشی از خرابی سرور یا از دست رفتن داده‌ها به‌مراتب بیشتر از هزینه خدمات مدیریت سرور است.

3. دسترسی به دانش و تخصص پیشرفته

مدیریت سرور شامل موارد پیچیده‌ای مانند امنیت، بهینه‌سازی عملکرد، تنظیمات پیشرفته، و نظارت 24/7 است. شرکت‌های تخصصی تیم‌هایی دارند که:

  • با جدیدترین تکنولوژی‌ها و پروتکل‌های امنیتی آشنا هستند.
  • تجربه زیادی در مدیریت سناریوهای مختلف دارند.
  • در مواقع بحرانی می‌توانند سریع‌تر و دقیق‌تر عمل کنند.

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


4. امنیت بالاتر

امنیت داده‌ها و سرور از حیاتی‌ترین دغدغه‌های هر کسب‌وکاری است. شرکت‌های مدیریت سرور:

  • نظارت مداوم بر سرور دارند و به‌سرعت تهدیدات را شناسایی می‌کنند.
  • از ابزارهای پیشرفته امنیتی استفاده می‌کنند که ممکن است هزینه خرید آن‌ها برای شما به‌صرفه نباشد.
  • به‌طور منظم به‌روزرسانی‌ها و پچ‌های امنیتی را اعمال می‌کنند.

اگر امنیت سرور خود را به‌درستی مدیریت نکنید، ممکن است قربانی هک، سرقت داده‌ها یا حملات سایبری شوید که می‌تواند خسارات مالی و اعتباری سنگینی به همراه داشته باشد.


5. پشتیبانی 24/7

سرورها ممکن است در هر لحظه از شبانه‌روز دچار مشکل شوند. شرکت‌های مدیریت سرور معمولاً تیم‌های پشتیبانی 24/7 دارند که:

  • به‌صورت دائمی سرور شما را زیر نظر دارند.
  • در صورت بروز مشکل به‌سرعت وارد عمل می‌شوند.
  • اطمینان می‌دهند که حداکثر زمان آپتایم (Uptime) برای سرور شما فراهم باشد.

اگر بخواهید خودتان این کار را انجام دهید، باید دائماً آماده باشید و حتی در نیمه‌شب نیز احتمالاً مجبور به رفع مشکلات خواهید شد.


6. بهبود عملکرد و کارایی

شرکت‌های مدیریت سرور به دلیل تجربه و تخصص خود می‌توانند سرور شما را به‌گونه‌ای پیکربندی کنند که بهترین عملکرد را داشته باشد:

  • بهینه‌سازی منابع سرور (CPU، RAM و فضای دیسک).
  • کاهش زمان بارگذاری (Load Time) که تأثیر مستقیم بر تجربه کاربری و سئو دارد.
  • ارائه پیشنهاداتی برای ارتقاء یا تغییر منابع در صورت رشد کسب‌وکار شما.

اگر خودتان این کار را انجام دهید، ممکن است پیکربندی نادرستی انجام دهید که باعث هدررفت منابع یا کاهش کارایی شود.


7. تمرکز بر کسب‌وکار اصلی

وقتی مدیریت سرور را به یک شرکت تخصصی بسپارید:

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

8. دسترسی به SLA (توافق‌نامه سطح خدمات)

بیشتر شرکت‌های مدیریت سرور SLA ارائه می‌دهند که در آن تعهد می‌کنند خدمات باکیفیت ارائه دهند. این شامل:

  • تضمین زمان پاسخ‌گویی.
  • تعهد به حل مشکلات در زمان معین.
  • جبران خسارت در صورت عدم رعایت SLA.

در مقابل، اگر خودتان مدیریت را بر عهده داشته باشید، هیچ ضمانتی برای رفع سریع مشکلات وجود ندارد.


9. مقایسه در سناریوهای واقعی

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

10. کاهش ریسک و خطا

انجام تنظیمات و مدیریت سرور توسط افراد غیرمتخصص می‌تواند منجر به:

  • خرابی‌های غیرمنتظره.
  • از دست رفتن داده‌ها.
  • تنظیمات امنیتی ضعیف و آسیب‌پذیری در برابر حملات.

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


11. ارتقای سئو

  • به دلیل پایداری بهتر سایت شما رتبه بالاتری دریافت خواهد کرد.
  • بهینه سازی سرویس ها منجر به افزایش سرعت فراخوانی سایت و یا برنامه شما خواهد شد که باعث افزایش رتبه سایت شما خواهد شد.

12. دریافت مشاوره تخصصی:

  • با حضور یک تیم تخصصی در کنار خود، در زمان های ضروری می توانید از تخصص ایشان برای استفاده در توسعه کسب و کار خود مشاوره بگیرید.
  • در دسترس بودن مشاور متخصص در حوزه فن آوری اطلاعات به شما کمک شایانی در تصمیم گیری های مهم برای سایت و یا برنامه شما خواهد بود.

نتیجه‌گیری:

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

تامین امنیت سرورهای لینوکسی به واسطه به‌روزرسانی خودکار

به‌روزرسانی خودکار سرور برای تامین امنیت

تامین امنیت سرورهای لینوکسی از طریق به‌روزرسانی اتوماتیک


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

یک قانون عمومی اغلب برای استفاده از به روزرسانی خودکار وجود دارد:

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

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

 

نحوه راه اندازی به‌روزرسانی خودکار


شما میتوانید از این سرویس برای دانلود و نصب خودکار هر نوع به روزرسانی استفاده کنید (مثلا به روزرسانی های امنیتی)

بسته dnf-automatic مبنی بر RPM به عنوان یک افزونه به DNF اضافه می شود سرویسی برای به روزرسانی خودکار فراهم می کند.

 

نصب و تنظیم dnf-automatic

بر روی سیستم عامل خود بسته مذکور را به روش ذیل نصب کنید:

 

بصورت پیشفرض فایل تنظیمات خود را در مسیر etc/dnf/automatic.conf/ ایجاد می کند. این تنظیمات بصورتی است که فقط بسته ها را دانلود می کند و آنها را نصب نمی کند. برای تغییر و یا افزودن هر نوع تنظیماتی، فایل مذکور را با کاربر دارای دسترسی root توسط ویرایشگر دلخواهتان باز کنید.

 

نصب و راه اندازی dnf-automatic

پس از نصب دستور زیر را برای فعالسازی وارد کنید:

سپس با دستور ذیل وضعیت سرویس را بررسی کنید:

در نسخ فعلی سه تایمر برای این سرویس وجود دارد:

dnf-automatic-download.timer که فقط دانلود را انجام می دهد.

dnf-automatic-install.timer که عملیات دانلود و نصب را انجام میدهد.

dnf-automatic-notifyonly.timer که فقط برا اساس تنظیمات فایل فوق؛ اطلاع رسانی را انجام می دهد.

شما می توانید از download_updates و apply_updates در داخل etc/dnf/automatic.conf/ بهره ببرید.

 

آیا بروزرسانی های DNF قابل اطمینان هستند؟


در سیستم های مبتنی بر Fedora و REHL بررسی کلید های GPG بصورت پیشفرض فعال هستند. با فرض اینکه شما کلید صحیح را در سیستم خودتان تعریف کرده باشید و مقدار gpgcheck=1 را در فایل dnf.conf وارد کرده باشید، میتوان اینگونه تصور کرد که فایلهای به روزرسانی خراب و یا تغییر داده شده نیستند و اصالت آنها را تایید کرد. در صورت فعال بودن این گزینه، یک خرابکار به هیچ وجه نمیتواند بسته ای را تولید و برای سرور شما ارسال کند که سیستم شما آن را قبول کند (مگر اینکه آنها کلید خصوصی متناظر با آنچه شما نصب کرده اید را داشته باشند) و در زمان دانلود سیستم فایلهای معیوب را شناسایی خواهد کرد.

هرچند، این پرسش هنوز مطرح است که آیا بسته به روزرسانی بصورت کامل و یا صحیح است؟ آیا با نصب آن سیستم شما دچار مشکل نخواهد شد؟ متاسفانه ما نمیتوانیم به این پرسش پاسخ درستی بدهیم و شما باید در طی یک پروسه آزمون و خطا صحت عملکرد بسته های به روزرسانی را متناسب با نیاز و شرایط خود بررسی کنید. هر بسته به روزرسانی توسط تیم های “کنترل کیفیت” بررسی می شود اما مشکلات همیشه بوجود می آید. خطای انسانی و یا بروز یک ناسازگاری ممکن است سیستم شما را با مشکل مواجه کند که این موارد خصوصا در آپدیت های سرورها و سیستم های ویندوزی به دلیل خودکار بودن بسیار رخ داده و خبرساز شده است. رویه استاندارد در صنعت IT و برنامه های حساس و سیستم های “در حال اجرا” این است که شما همواره قبل از به روزرسانی این بسته ها را بر روی سرورهای تستی خود اصالت سنجی و از صحت عملکرد سرور و سرویس خود اطمینان حاصل فرمائید.

 

چرا از به‌روزرسانی خودکار استفاده کنیم؟


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

در عین حال که می‌بایست در استفاده از به روزرسانی های خودکار، خصوصا در محیط های Production محتاط باشید، بررسی این موضوع حداقل در برخی شرایط ارزش بررسی دارد.

دلایل استفاده از به‌روزرسانی خودکار

هر چند کسی نمی تواند بصورت تضمینی این اطمینان را به شما بدهد که سرور شما کاندید مناسبی برای دریافت به روزرسانی های خودکار هست یا نه، بررسی چندین مورد می تواند در تصمیم گیری به شما کمک کند.

برخی از مواردی که در این خصوص می تواند به شما کمک کند به شرح ذیل است:

  • شما قادر به نصب بسته های به روزرسانی بصورت دستی نیستید (به هر دلیلی)
  • سیستم ها حاوی یک برنامه حیاتی نیست و قطعی های کوتاه برنامه ریزی نشده برای شما مشکلی ایجاد نمی کند.
  • اگر دسترسی از راه دور به سیستم شما قطع شد مشکل خاصی بوجود نمی آید و شما می توانید بصورت فیزیکی به سرور دسترسی پیدا کنید.
  • شما داده غیرقابل جایگزین شدن بر روی سرور ندارید و یا حداقل نسخه پشتیبان خوبی در اختیار دارید.

اگر تمامی موارد بالا برای شما صدق می کند ممکن است استفاده از این ویژگی برای شما گزینه خوبی باشد تا امنیت سرور خود را تامین کنید و اگر تمامی موارد بالا برای شما وجود نداشت حداقل می توانید ریسک انجام این کار را برآورد کنید و در این خصوص تصمیم گیری کنید.

 

دلایل عدم استفاده از به‌روزرسانی خودکار

همانطور که در بالا گفتیم، کسی نیز نمیتواند بگوید که سیستم شما کاندید خوبی برای عدم به روزرسانی خودکار نیست، با این حال موارد زیر در تصمیم گیری به شما کمک می کند:

  • عملکرد دائمی سیستم شما به قدری حیاتی است که شما و یا سازمان نمیتوانید لحظه ای قطعی سرویس را تحمل کنید.
  • شما برنامه های دست نویس را استفاده می کنید، از سورس یک برنامه را compile کرده اید و یا عملکرد سرویس شما نیازمند یک نسخه خاص از یک پیش نیاز نرم افزاری است.
  • شما از یک kernel خاص و یا یک ماژول اختصاصی در kernel خود بهره می برید و یا برنامه شما از یک ویژگی منحصر به نسخه خاصی از kernel بهره می برد. (شما می توانید آپدیت های kernel را محدود کنید)
  • محیط کاری و نرم افزاری شما نیازمند بررسی دقیق هرگونه تغییر و یا نظارت بر عملکرد هر بخش از سرویس می باشد.
  • از یک مخزن (Repository) غیر استاندارد استفاده می کنید که ممکن است با برنامه هایی که در مخزن اصلی وجود دارند تداخل نسخه ای داشته باشند.

همچنین برخی موارد هستند که بررسی به روزرسانی ها قبل از نصب آنها قطعا روش درستی برای کار نیست که چند نمونه مثال خواهیم زد:

  • نیاز به بکاپ گیری قبل از اعمال به‌روزرسانی: حتی بهترین برنامه ها می‌تواند دارای ایراد باشند. ممکن است تنظیماتی داخل یک فایل داشته باشید که با آپدیت، آن تغییرات از دست بروند. یا ممکن است نسخه جدید یک برنامه نحوه تنظیمات آن فرق کرده باشد و یا برخی از flag ها در آن حذف و یا اضافه شده باشد که عدم وجود و یا وجود آنها منجر به خطا در سرویس شما بشود. بهتر است قبل از به روزرسانی سرویس هایی مانند وب سرور، بانک اطلاعاتی و پست الکترونیکی؛ حتما از فایلهای تنظیمات خود یک نسخه پشتیبان تهیه کنید.
  • عوارض پیش بینی نشده: برخی از برنامه ها ممکن است دارای عوارضی جانبی باشند مانند برنامه هایی که از ویژگی cron jobs بهره می‌برند. به روزرسانی بسته هایی مانند openssl، openldap و sql به روزرسانی های متعددی برای برنامه هایی که به نظر بی ربط می‌رسند دارند.
  • باگ: برخی از بسته ها ممکن است اسکریپت آپدیت کننده آن دارای ایراد باشد که بعد از نصب ممکن است با خطاهای ناشناخته و یا عجیب روبرو شوید. نمونه ای از این خطا ها قبلا در Mozilla مشاهده شده است که بعضا آیکن ها حذف شده و برای کاربران دچار اعصاب خوردی و یا مشکلات کاربری ایجاد کرده است.
  • به روزرسانی خودکار ممکن است تمامی مراحل لازم برای ارتقای امنیت سیستم را انجام ندهد. برای مثال DNF می تواند آپدیت های kernel را نصب کند اما تغییرات اعمال نمی شوند. بسیاری از اینگونه تغییرات نیازمند ریستارت شدن سرویس (daemon) و یا ریستارت سرور است. این موارد ممکن است برای کاربر شائبه این را ایجاد کند که سیستم امن شده است در صورتی که به‌روزرسانی اصلا اعمال نشده است.

 

روش استاندارد برای انجام به‌روزرسانی خودکار


اگر تصمیم به استفاده از این ویژگی دارید باید حداقل موارد ذیل را برای اطمینان از صحت عملکرد آن انجام دهید.

بسته هایی به روزرسانی را کنترل کنید که آیا بصورت کامل نصب شده اند و یا نیازمند انجام عملیات دستی هستند و یا خیر، که برای این مهم میتوانید لاگ را در مسیر var/log/dnf.log/ بررسی کنید.

شما می توانید موجودیت بسته به روزرسانی را به واسطه ایمیل اطلاع رسانی دریافت و بررسی کنید. با اعمال تنظیمات در فایل etc/dnf/automatic.conf/

 

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

تنظیمات فوق به این معناست که به محض اجرا شدن عملیات به روزرسانی؛ اطلاعات بسته های به روزرسانی موجود و همچنین لاگ بسته های دانلود شده و یا نصب شده مطابق تنظیمات فایل automatic.conf برای شما ارسال خواهد شد.

 

راهکارهای جایگزین


بجای استفاده از dnf-automatic می توانید از auter نیز استفاده کنید. عملکرد آن بسیار مشابه به dnf-automatic است اما انعطافپذیری بیشتری برای تنظیمات زمانبندی اجرا دارد و همچنین امکانات اضافه ای برای تنظیمات اجرای اسکریپ هایی قبل و بعد از اجرای به روزرسانی ها دارد که شامل ریستارت سرور نیز می شود. با این حال پیاده سازی این ویژگی ها نیازمند تنظیمات پیچیده تری می باشد.

پس از نصب می بایست فایل تنظیمات آن در مسیر etc/auter/auter.conf/ را ویرایش کنید.

Auter بصورت پیشفرض هیچگونه عملیاتی انجام نمی دهد و برای تنظیم باید از کد prep-- (برای دانلود) و همچنین apply-- (برای نصب) استفاده کنید. تنظیمات اجرای آن درون فایلهای cron که در مسیر etc/cron.d/auter/ وجود دارد که شامل تعداد بسیاری از مثال های قابل انجام می باشد.

برای تست فوری عملکرد آن می توانید از دستور زیر استفاده کنید:

برای غیرفعال سازی آن می توانید از دستور زیر استفاده کنید. این دستور برای Cron Job ها نیز عمل میکند:

 

راهکار جایگزین استفاده از به‌روزرسانی خودکار برای تامین امنیت


اطلاع رسانی

بجای انجام آپدیت ها از ویژگی های فوق فقط جهت دریافت اطلاع از وجود بسته به روزرسانی استفاده کنید و در اولین فرصت نسبت به نصب دستی آنها اقدام کنید.

زمانبندی به روزرسانی ها

یکی از مشکلات دیگر انجام این به روزرسانی ها در روزهای تعطیل و یا آخرهفته ها هست که به هیچ وجه مورد تایید نیست و ممکن است مشکلاتی بواسطه آنها ایجاد شود که به دلیل عدم حضور پرسنل مشکلات به شکل بدتری گسترده شوند.

روش‌های دیگر تامین امنیت

اگر انجام این به روزرسانی ها را در دستور کار خود ندارید میتوانید از روش های دیگری به منظور تامین امنیت سرور اختصاصی و یا سرور ابری خودتان نیز استفاده کنید تا در مقابله با تهدیدات سایبری، نفوذ هکر ها و نشت داده های خود آسوده خاطر باشید. از جمله این موارد می‌توان به نصب دیوار آتش سخت افزاری و یا نرم افزاری (iptables, ipchains, tcp wrappers) اشاره نمود، همچنین عدم نصب برنامه های اضافی و عدم انجام کارهای پرخطر توسط سیستم سرور (استفاده از اینترنت، کنترل ایمیل و ..) به همراه کنترل و نظارت ورود غیرمجاز (بررسی لاگ های ورود، استفاده از سیستم های IDS و..) از جمله راه کار هایی است که می توانید برای افزایش امنیت و حفاظت از ماشین کاری خود انجام دهید.

 

منبع: مقالات آموزشی فدورا

 

تقویت امنیت HTTP response headers

مقدمه

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

سربرگ‌های اضافی

گام اول در تقویت سربرگ‌های پاسخ HTTP شما، نگاه کردن به سربرگ‌های اضافی است که می‌توانید از آنها استفاده کنید تا سایت خود را ایمن‌تر کنید. در زیر توضیح داده شده است، این سربرگ‌ها به مرورگر اطلاعات بیشتری درباره نحوه رفتار کردن شما درباره سایت می‌دهند. آنها می‌توانند برای ارسال سیاست‌های امنیتی، تنظیم گزینه‌های پیکربندی و غیرفعال کردن ویژگی‌های مرورگری که نمی‌خواهید برای سایت خود فعال شود، استفاده شوند. بعد از راه‌اندازی هر سربرگ، آن را با استفاده از SecurityHeaders.io بررسی کنید.

Content Security Policy – سیاست امنیت محتوا (CSP)

سربرگ CSP به شما اجازه می‌دهد تا یک لیست سفید از منابع تأییدشده برای محتوای سایت خود تعریف کنید. با محدود کردن منابعی که یک مرورگر می‌تواند برای سایت شما بارگیری کند، مانند فایل‌های js و css، CSP می‌تواند به عنوان یک پاسخ مؤثر به حملات XSS عمل کند. در اینجا یک سیاست ابتدایی برای اجبار TLS بر روی همه منابع و جلوگیری از هشدارهای محتوای مخلوط (Mixed-Content) آورده شده است.

Nginx:

add_header Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'" always;

Apache:

Header always set Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'"

IIS:

در سرورهای ویندوزی، IIS Manager را باز کنید و بر روی سایت مورد نظر کلیک کنید و سپس گزینه HTTP Response Headers را انتخاب کنید.

iis-response-headers

در پنل “Actions” بر روی دکمه “Add” کلیک کنید و سپس جزئیات سربرگ را وارد کنید.

CSP دارای ویژگی متعددی است که من در بالا شرح داده‌ام و همچنین می‌توانید از تحلیل‌گر CSP و سازنده CSP در report-uri.io استفاده کنید. این ابزاربه شما کمک کنند تا یک سیاست سفارشی برای سایت خود ایجاد کنید.

HTTP Strict Transport Security – امنیت انتقال سختگیرانه HTTPS

این سربرگ به سرور اجازه می‌دهد تا مرورگرها را به اتصال امن HTTPS به جای HTTP برای درخواست‌های آینده به وب‌سایت الزام کند. این اقدام می‌تواند از حملات MITM (Man-in-the-Middle) جلوگیری کند و امنیت ارتباطات را تأمین کند. بهترین راه برای اعمال آن این است که سرور این سربرگ را به همراه سیاست‌های امنیتی مناسبی تنظیم کند تا مرورگرها برای مدت زمان مشخصی (مثلا یک سال) تنها از اتصال HTTPS استفاده کنند و از هیچگونه سویه اینترنتی تلاش برای از پایین آوردن اتصال HTTPS جلوگیری شود.

Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubdomains" always;

Apache:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

IIS:

پین‌کردن کلید عمومی HTTP (HTTP Public Key Pinning)

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

یکی دیگر از ابزارهای امنیتی موجود برای تقویت امنیت ارتباطات وب، فناوری HSTS (HTTP Strict Transport Security) است که به مرورگرها می‌گوید که باید همیشه از اتصال HTTPS استفاده کنند، به جای HTTP غیرامنیتی. این تکنولوژی باعث کاهش موارد ممکن حمله MITM (Man-in-the-Middle) می‌شود و از تهدیدات امنیتی حمایت می‌کند.

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

Nginx:


add_header Public-Key-Pins "pin-sha256='X3pGTSOuJeEVw989IJ/cEtXUEmy52zs1TZQrU06KUKg='; pin-sha256='MHJYVThihUrJcxW6wcqyOISTXIsInsdj3xK8QrZbHec='; pin-sha256='isi41AizREkLvvft0IRW4u3XMFR2Yg7bvrF7padyCJg='; includeSubdomains; max-age=2592000" always;


Apache:

Header always set Public-Key-Pins "pin-sha256='X3pGTSOuJeEVw989IJ/cEtXUEmy52zs1TZQrU06KUKg='; pin-sha256='MHJYVThihUrJcxW6wcqyOISTXIsInsdj3xK8QrZbHec='; pin-sha256='isi41AizREkLvvft0IRW4u3XMFR2Yg7bvrF7padyCJg='; includeSubdomains; max-age=2592000"


IIS:

X-Frame-Options

سربرگ X-Frame-Options (RFC)، یا همان سربرگ XFO، بازدیدکنندگان شما را در برابر حملات کلیک‌جکینگ محافظت می‌کند. یک حمله‌کننده می‌تواند یک فریم (iframe) را در وب‌سایت خود بارگیری کرده و وب‌سایت شما را به عنوان منبع تنظیم کند، که کاری بسیار آسان است. با استفاده از CSS ماهرانه، می‌توانند وب‌سایت شما را در پس‌زمینه پنهان کنند و اشکال‌هایی با نمایی واقعی ایجاد کنند. وقتی بازدیدکنندگان شما روی لینکی که فکر می‌کنند بی‌خطر است کلیک می‌کنند، در واقع روی لینک‌هایی در وب‌سایت شما در پس‌زمینه کلیک می‌کنند. این ممکن است به نظر نیاید که این امر اشکالی داشته باشد تا زمانی که متوجه شویم مرورگر این درخواست‌ها را در محیط کاربر اجرا می‌کند، که ممکن است شامل ورود و احراز هویت کاربر به وب‌سایت شما شود!

سربرگ X-Frame-Options به مرورگرها اجازه می‌دهد که بدانند آیا محتوای وب‌سایت شما می‌تواند در یک فریم داخلی یک صفحه وب دیگر نمایش داده شود یا خیر. مقادیر معتبر شامل DENY به معنای اینکه وب‌سایت شما نمی‌تواند در فریم‌ها قرار گیرد، SAMEORIGIN که به شما اجازه می‌دهد وب‌سایت خود را فریم کنید یا ALLOW-FROM https://zagrio.com/ که به شما اجازه می‌دهد وب‌سایت‌هایی را که مجاز به فریم کردن وب‌سایت خود هستند مشخص کنید.

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

Nginx:

add_header X-Frame-Options "SAMEORIGIN" always;

Apache:


Header always set X-Frame-Options "SAMEORIGIN"

IIS:

X-XSS-Protection

این سربرگ برای پیکربندی حفاظت از XSS (Cross-Site Scripting) داخلی که در مرورگرهای اینترنت اکسپلورر، کروم و سافاری (وب‌کیت) وجود دارد، استفاده می‌شود. تنظیمات معتبر برای این سربرگ شامل 0 که حفاظت را غیرفعال می‌کند، 1 که حفاظت را فعال می‌کند و 1؛ mode=block که به مرورگر می‌گوید اگر یک حمله را شناسایی کند، پاسخ را مسدود کند به جای اجازه دادن به اجرای اسکریپت است. این سربرگ به مرورگر اجازه می‌دهد تا در برابر حملات XSS (Cross-Site Scripting) محافظت شود. در حملات XSS، حمله‌کننده کدهای جاوااسکریپت مخرب را به وب‌سایت شما تزریق می‌کند تا اطلاعات کاربران را بدزدد یا به مخاطبان مورد نظر خود هدایت کند. با فعال‌سازی این سربرگ و تنظیم مقدار آن به “1”، مرورگرها می‌توانند به طور خودکار اقداماتی را انجام دهند تا از حملات XSS جلوگیری کنند. این امر به افزایش امنیت وب‌سایت شما کمک می‌کند.

Nginx:


add_header X-Xss-Protection "1; mode=block" always;

Apache:


Header always set X-Xss-Protection "1; mode=block"

IIS:

X-Content-Type-Options

این سربرگ برای کنترل نحوه‌ی تفسیر محتوای فایل‌ها توسط مرورگر استفاده می‌شود. مقادیر معتبر برای این سربرگ عبارتند از “nosniff” که به مرورگر می‌گوید که نوع محتوای فایل را از هدر Content-Type استخراج کند و از فایل‌هایی که نوع محتوایشان مشخص نیست استفاده نکند. این سربرگ از mime-sniffing توسط Google Chrome و اینترنت اکسپلورر برای تعیین نوع محتوای پاسخ، مستقیماً به دور از آنچه توسط سرور اعلام شده است، جلوگیری می‌کند.

Nginx:

add_header X-Content-Type-Options "nosniff" always;

Apache:


Header always set X-Xss-Protection "1; mode=block"

IIS:

حذف سربرگ‌ها

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

سربرگ Server

سربرگ Server یکی از رایج‌ترین سربرگ‌هایی است که احتمالاً در یک وب‌سایت مشاهده خواهید کرد. در RFC تعریف شده است:

سربرگ پاسخ Server شامل اطلاعاتی درباره نرم‌افزار استفاده شده توسط سرور منبع برای پردازش درخواست است. این فیلد می‌تواند شامل چندین نشانه محصول (بخش 3.8) و توضیحاتی درباره سرور و هر زیرمحصول مهم باشد. نشانه‌های محصول به ترتیب اهمیت برای شناسایی برنامه فهرست شده‌اند.

این سربرگ طراحی شده است تا اطلاعاتی درباره برنامه وب‌سرور خاصی که بر روی سرور اجرا می‌شود، ارائه دهد، و مقادیر رایج به مایکروسافت IIS، NginX یا Apache اشاره می‌کنند. با این حال، RFC در ادامه بیان می کند:

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

با این حال، بسیاری از تامین کنندگان، این کار را آنقدر آسان نمی‌کنند تا امکان تغییر مقدار سربرگ یا در ایده‌آل، حذف آن را فراهم کنند.

ادامه این مقاله به زودی منتشر خواهد شد …

public key و private key: آموزش ایجاد در cPanel

public key و private key: آموزش ایجاد در cPanel

1.3kviews

در این آموزش با public key و private key که یکی از راه‌های اتصال به سرور استفاده از SSH می‌باشد. و از این راه می‌توانید با گذرواژه و نام کاربری خود به سرور متصل گردید. اما این امر باعث خطراطی نیز هست برای افزایش امنیت می‌توانید از پیر کرد key استفاده نمایید. این کلید‌ها می‌توانند عمومی یا خصوصی باشند. که در این فرایند کلید عمومی بر روی سرور شماست و کلید خصوصی بر روی سیستم شما و زمانی که شما مبادرت به اتصال به سرور می‌نمایید کلیدها باهم مقایسه می‌شوند و اگر کلید درست باشد شما به سرور متصل خواهید شد.

آموزش ایجاد در cPanel

ما در این آموزش public key و private key به شما یاد می‌دهیم که چگونه کلید عمومی و خصوصی را ایجاد نمایید و آن‌ها را به سرور خود توسط PuTTY متصل نمایید.

مرحله اول آموزش public key و private key :برای ایجاد و استفاده از کلید عمومی و خصوصی در cPanel :

قدم اول: با گذرواژه و نام کاربری خود وارد پنل cPanel خود شوید.

قدم دوم: بخش SECURITY را پیدا نمایید و وارد آن شوید. سپس وارد بخش SSH Access شوید.public key و private key

قدم سوم: بر دکمه Manage SSH Keys کلیک نمایید.

public key و private key

قدم چهارم: در مرحله بعدی بر کلید +Generate a New Key کلیک نمایید.

public key و private key

قدم پنجم: شما فعلا در بخش Generating a Public Key قرار دارید و حالا می‌توانید اطلاعات کلید عمومی خود را تکمیل نمایید.

public key

قدم ششم: حالا اگر بر کلید Generate Key کلیک نمایید کلید شما ساخته‌ خواهد شد و اطلاعاتی مانند زیر به شما نمایش داده خواهد شد.

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
The key fingerprint is:
b7:9a:55:59:c1:a7:6a:31:5c:9a:40:50:e9:73:24:a0

قدم هفتم: به صفحه قبل باز می‌گردیم.

قدم هشتم: حالا نیاز است که شما کلید ساخته شده را تایید نمایید این امر باید از طریق Manage به صورت تصویر زیر صورت گیرد.private keypublic key و private key

قدم نهم: باز هما به صفحه قبل باز می‌گردیم اینبار برای کلید خصوصی به صفحه View/Download می رویم.

public key و private key

قدم دهم: در این بخش کلید عمومی ساخته شده را باید تبدیل نماییم برای این امر باید از کلید Convert استفاده نماییم.

ssh key چیست

قدم یازدهم: می‌بینید که کلید شما با موفقیت تبدیل می‌شود و شما حالا می‌توانید آن را دانلود نمایید Download key با استفاده از این گزینه.

قدم دوازدهم: حالا PuTTY را در کامپیوتر خود اجرا نمایید و به بخش Connection->SSH->Auth بروید.

private and public key

قدم سیزدهم: بر روی کلید Open مانند تصویر بالا کلیک نمایید و سپس Passphrase را زمانی که از شما خواسته شد وارد نمایید.

ssh -i private key

بعد از وارد کردن شما وارد سرور شده‌اید.

زاگریو

مسدودسازی IP های حمله کننده به MySQL, MSSQL, RDP

مسدودسازی IP های حمله کننده به MySQL ,MSSQL ,RDP

758views

یکی دیگر از مواردی که قصد داریم در زاگریو به آن بپردازیم، مسدودسازی IP های حمله کننده به MySQL ،MSSQ ،RDP، است. تا مدیریت سرور شما، توسط این آی‌پی‌ها دیگر مورد حمله قرار نگیریند و امنیت سرور شما، همیشه برقرار باشد.

مسدودسازی IP های حمله کننده به MySQL, MSSQL, RDP ️

اگر سرویس‌هایی بر روی سرور خود دارید، که باید از بیرون از سازمان شما به آن منابع دسترسی پیدا کرد، ممکن است شما نیز قربانی حملات بی‌پایان و تلاش‌های هکرها برای Brute Force باشید، راه حل این موضوع مسدودسازی IP های حمله کننده به MySQL, MSSQL, RDP.

سرویس‌هایی نظیر RDP ،MYSQL ،MSSQL از امثال این سرویس‌ها هستند و مسدودسازی IP های حمله کننده تنها راه است.

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

مسدودسازی IP

در این آموزش سعی داریم تا با استفاده از پاورشل، لاک‌های درج شده در Event Log را استخراج و پس از جدا کردن قسمت‌های آدرس IP که برای فرض مثال بیش از ۳ بار خطای ورود ناموفق داشته‌اند یک Rule با شرط Block در سیستم فایروال ویندوز ایجاد کنیم.

ما در این روش، به منظور امکان بررسی IP هایی که مسدود شده‌اند، تمامی آدرس‌ها را در فایل ذخیره کرده و برای استفاده‌های آتی نگهداری می‌کنیم.

️نکته️:
– می‌توان لاگ‌ها را حذف نکرد و در ابتدا تاریخ و ساعت مشخص کرد که اسکریپت صرفا لاگ‌های یک روز پیش را جستجو کند.
– می‌توانید هیچ گونه فایلی نگهداری نکنید و مستقیما آن‌ها را در فایروال مسدود کنید.
– در یک بخش از کد مقداری تحت عنوان “{ $_.Count -gt 3 }” آمده است، که با افزایش یا کاهش این عدد می‌توانید به تعداد خطاهای لاگین مورد نظر برسید.
– برای اتوماتیک کردن پروسه، می‌توانید در Scheduled Tasks یک TASK با عنوان و زمان‌بندی مورد نظر خود ایجاد کنید.
– فایل دوم صرفا وظیفه وارد کردن آدرس IP ها از یک فایل برای ایجاد RULE های BLOCK را دارد و می‌توانید از آن در موارد دیگر نیز استفاده کنید و مسدودسازی IP را انجام دهید.

فایل شماره ۱- Block-Brute.ps1 | مسدودسازی IP

$datetime = (((get-date).ToUniversalTime()).ToString("yyyyMMddhhmmss"))
$regex = ‘\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b’

## MySQL ##
$input_path = "C:\BLOCK\mysql-raw.txt"
$output_file = "C:\BLOCK\mysql-all-ip.txt"
$output_unique = "C:\BLOCK\MySQL-Bruteforce-$datetime.txt"
Get-EventLog -Source MySQL -LogName Application | select Message | Out-File $input_path
Select-String -Path $input_path -Pattern $regex -AllMatches | % { $_.Matches } | % { $_.Value } > $output_file
Get-Content $output_file | sort | Group-Object | Where-Object { $_.Count -gt 3 } | Select -ExpandProperty Name | Get-Unique > $output_unique
c:\BLOCK\import-firewall-blocklist.ps1 -inputfile $output_unique
Remove-Item $input_path
Remove-Item $output_file

## MSSQL ###
$MSSQLinput_path = "C:\BLOCK\mssql-raw.txt"
$MSSQLoutput_file = "C:\BLOCK\mssql-all-ip.txt"
$MSSQLoutput_unique = "C:\BLOCK\MSSQL-Bruteforce-$datetime.txt"
Get-EventLog -LogName Application | Where-Object { $_.eventid -eq 18456 } | select Message | Out-File $MSSQLinput_path
Select-String -Path $MSSQLinput_path -Pattern $regex -AllMatches | % { $_.Matches } | % { $_.Value } > $MSSQLoutput_file
Get-Content $MSSQLoutput_file | sort | Group-Object | Where-Object { $_.Count -gt 3 } | Select -ExpandProperty Name | Get-Unique > $MSSQLoutput_unique
c:\BLOCK\import-firewall-blocklist.ps1 -inputfile $MSSQLoutput_unique
Remove-Item $MSSQLinput_path
Remove-Item $MSSQLoutput_file

Clear-EventLog -LogName Application

 

فایل شماره ۲- import-firewall-blocklist.ps1 | مسدودسازی IP

####################################################################################
#.Synopsis
# Block all IP addresses listed in a text file using the Windows Firewall.
#
#.Description
# Script will create inbound and outbound rules in the Windows Firewall to
# block all the IPv4 and/or IPv6 addresses listed in an input text file. IP
# address ranges can be defined with CIDR notation (10.4.0.0/16) or with a
# dash (10.4.0.0-10.4.255.255). Comments and blank lines are ignored in the
# input file. The script deletes and recreates the rules each time the
# script is run, so don't edit the rules by hand. Requires admin privileges.
# Multiple rules will be created if the input list is large. Requires
# Windows Vista, Windows 7, Server 2008 or later operating system. Blocking
# more than 5000 IP address ranges does delay initial connections, will slow
# the loading of the Windows Firewall snap-in, and will lengthen the time
# to disable/enable a network interface. This script is just a wrapper for
# the netsh.exe tool. You can block individual IP addresses too, you do not
# need to use CIDR notation for this (10.1.1.1/32), though this does work.
#
#.Parameter InputFile
# File containing IP addresses and ranges to block; IPv4 and IPv6 supported.
# By default, the script will look for and use a file named 'blocklist.txt'.
#
#.Parameter RuleName
# (Optional) Override default firewall rule name; default based on file name.
# When used with -DeleteOnly, just give the rule basename without the "-#1".
#
#.Parameter ProfileType
# (Optional) Comma-delimited list of network profile types for which the
# blocking rules will apply: public, private, domain, any (default = any).
#
#.Parameter InterfaceType
# (Optional) Comma-delimited list of interface types for which the
# blocking rules will apply: wireless, ras, lan, any (default = any).
#
#.Parameter DeleteOnly
# (Switch) Matching firewall rules will be deleted, none will be created.
# When used with -RuleName, leave off the "-#1" at the end of the rulename.
#
#.Example
# import-firewall-blocklist.ps1 -inputfile IpToBlock.txt
#
#.Example
# import-firewall-blocklist.ps1 -inputfile iptoblock.txt -profiletype public
#
#.Example
# import-firewall-blocklist.ps1 -inputfile iptoblock.txt -interfacetype wireless
#
#.Example
# import-firewall-blocklist.ps1 -inputfile IpToBlock.txt -deleteonly
#
#.Example
# import-firewall-blocklist.ps1 -rulename IpToBlock -deleteonly
#
#Requires -Version 1.0
#
#.Notes
# Author: Jason Fossen (http://www.sans.org/windows-security/)
# Version: 1.2
# Updated: 20.Mar.2012
# LEGAL: PUBLIC DOMAIN. SCRIPT PROVIDED "AS IS" WITH NO WARRANTIES OR GUARANTEES OF
# ANY KIND, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY AND/OR FITNESS FOR
# A PARTICULAR PURPOSE. ALL RISKS OF DAMAGE REMAINS WITH THE USER, EVEN IF
# THE AUTHOR, SUPPLIER OR DISTRIBUTOR HAS BEEN ADVISED OF THE POSSIBILITY OF
# ANY SUCH DAMAGE. IF YOUR STATE DOES NOT PERMIT THE COMPLETE LIMITATION OF
# LIABILITY, THEN DELETE THIS FILE SINCE YOU ARE NOW PROHIBITED TO HAVE IT.
####################################################################################

param ($InputFile = "BlockList.txt", $RuleName, $ProfileType = "any", $InterfaceType = "any", [Switch] $DeleteOnly)

# Look for some help arguments, show help, then quit.
if ($InputFile -match '/[?h]') { "nPlease run 'get-help .\import-firewall-blocklist.ps1 -full' for help on PowerShell 2.0 and later, or just read the script's header in a text editor.n" ; exit }

# Get input file and set the name of the firewall rule.
$file = get-item $InputFile -ErrorAction SilentlyContinue # Sometimes rules will be deleted by name and there is no file.
if (-not $? -and -not $DeleteOnly) { "nCannot find $InputFile, quitting...n" ; exit }
if (-not $rulename) { $rulename = $file.basename } # The '-#1' will be appended later.

# Description will be seen in the properties of the firewall rules.
$description = "Rule created by script on $(get-date). Do not edit rule by hand, it will be overwritten when the script is run again. By default, the name of the rule is named after the input file."

# Any existing firewall rules which match the name are deleted every time the script runs.
"nDeleting any inbound or outbound firewall rules named like '$rulename-#*'n"
$currentrules = netsh.exe advfirewall firewall show rule name=all | select-string '^[Rule Name|Regelname]+:\s+(.+$)' | foreach { $_.matches[0].groups[1].value }
if ($currentrules.count -lt 3) {"nProblem getting a list of current firewall rules, quitting...n" ; exit }
# Note: If you are getting the above error, try editing the regex pattern two lines above to include the 'Rule Name' in your local language.
$currentrules | foreach { if ($_ -like "$rulename-#*"){ netsh.exe advfirewall firewall delete rule name="$_" | out-null } }

# Don't create the firewall rules again if the -DeleteOnly switch was used.
if ($deleteonly -and $rulename) { "nReminder: when deleting by name, leave off the '-#1' at the end of the rulename.n" }
if ($deleteonly) { exit }

# Create array of IP ranges; any line that doesn't start like an IPv4/IPv6 address is ignored.
$ranges = get-content $file | where {($_.trim().length -ne 0) -and ($_ -match '^[0-9a-f]{1,4}[\.\:]')}
if (-not $?) { "nCould not parse $file, quitting...n" ; exit }
$linecount = $ranges.count
if ($linecount -eq 0) { "nZero IP addresses to block, quitting...n" ; exit }

# Now start creating rules with hundreds of IP address ranges per rule. Testing shows
# that netsh.exe errors begin to occur with more than 400 IPv4 ranges per rule, and
# this number might still be too large when using IPv6 or the Start-to-End format, so
# default to only 100 ranges per rule, but feel free to edit the following variable:
$MaxRangesPerRule = 100

$i = 1 # Rule number counter, when more than one rule must be created, e.g., BlockList-#001.
$start = 1 # For array slicing out of IP $ranges.
$end = $maxrangesperrule # For array slicing out of IP $ranges.
do {
$icount = $i.tostring().padleft(3,"0") # Used in name of rule, e.g., BlockList-#042.

if ($end -gt $linecount) { $end = $linecount }
$textranges = [System.String]::Join(",",$($ranges[$($start - 1)..$($end - 1)]))

"nCreating an inbound firewall rule named '$rulename-#$icount' for IP ranges $start - $end"
netsh.exe advfirewall firewall add rule name="$rulename-#$icount" dir=in action=block localip=any remoteip="$textranges" description="$description" profile="$profiletype" interfacetype="$interfacetype"
if (-not $?) { "
nFailed to create '$rulename-#$icount' inbound rule for some reason, continuing anyway..."}

"nCreating an outbound firewall rule named '$rulename-#$icount' for IP ranges $start - $end"
netsh.exe advfirewall firewall add rule name="$rulename-#$icount" dir=out action=block localip=any remoteip="$textranges" description="$description" profile="$profiletype" interfacetype="$interfacetype"
if (-not $?) { "
nFailed to create '$rulename-#$icount' outbound rule for some reason, continuing anyway..."}

$i++
$start += $maxrangesperrule
$end += $maxrangesperrule
} while ($start -le $linecount)

# END-O-SCRIPT

# Incidentally, testing shows a delay of 2-5 seconds sometimes for the initial
# connection when there are more than 5000 IP address ranges total in the various
# outbound rules (once established, there is no delay). However, it does not seem
# consistent. Also, at 5000+ subnets in one's rules, it delays the opening of the
# Windows Firewall snap-in, and at 9000+ subnets it sometimes prevents the WF snap-in
# from opening successfully at all. However, this behavior is not consistent either.

بهترین سایز کلید RSA برای گواهینامه امنیتی SSL

بهترین سایز کلید RSA برای گواهینامه امنیتی SSL

2.8kviews

درصورتیکه می‌خواهید یک گواهینامه SSL ایجاد کنید، یکی از سوالاتی که برای شما ایجاد می‌شود اندازه سایز کلید RSA است. شاید یک عنوان دیگر این مقاله می‌توانست این باشد که چرا سایز کلید ۴۰۹۶ را استفاده نکنیم؟

بهترین سایز کلید RSA چیست؟

  • OpenSSL به صورت پیش‌فرض از کلید ۲۰۴۸ بیتی استفاده می‌کند.
  • سیستم عامل ویندوز از شما می‌خواهد که دقیقا انتخاب کنید سایز مورد نظر شما چیست؟
  • اگر می‌خواهید یک گواهینامه امنیتی با آدرس سبز رنگ EV داشته باشید باید حتما سایز کلید حداقل ۲۰۴۸ باشد.

به چه دلیل لازم است در خصوص کلیدهای ۴۰۹۶ اطلاعات بیشتری داشته باشید؟

  • اکثر توسعه‌دهندگان آنلاین مثل GitHub, Stripe, nmp و Mozilla از کلیدهای ۲۰۴۸ بیتی برای گواهینامه‌های امنیتی EV خود در زمان نگارش این مقاله استفاده می‌کنند.
  • GnuPG اعتقاد دارد که کلیدهای ۴۰۹۶ بیتی غیرضروری هستند.
  • اما SSL Labs برای اعطای امتیاز ۱۰۰% به شما، از شما می‌خواهد که کلید ۴۰۹۶ بیتی داشته باشید.

measuring-ssl-rsa-keys-1حتما در جریان هستید که با داشتن یک کلید ۴۰۹۶ بیتی:

  • قدرت کدگذاری شما افزایش می یابد.
  • ارتباط اولیه (Handshake) گواهینامه امنیتی شما به ازای هر ارتباط کندتر خواهد بود.
  • میزان مصرف CPU در زمان Handshake بیشتر خواهد بود.

اما ممکن است از تاثیرات دقیق هر یک از موارد فوق بی‌اطلاع باشید، هم اکنون با شما این موارد را بررسی می کنیم.

محاسبه قدرت کدگذاری برای سایز کلید RSA

بر خلاف الگوریتم‌های متقارن، الگوریتم غیرمتقارن RSA (متاسفانه) با افزایش یک بیت اضافه امنیت شما را دو برابر نمی‌کند.
کلیدهای RSA توسط موسسه ملی استاندارد و تکنولوژی محاسبه شده‌اند به این صورت که یک کلید ۲۰۴۸ بیتی RSA معدل با یک کلید ۱۱۲ بیتی متقارن هم‌تراز است.
به این صورت که امکان هک کردن یک کلید با شرایط فوق به میزان ۲ به توان ۱۱۲ از نظر تئوری امکان‌پذیر است.

تصویر زیر یک نمونه محاسباتی قدرت کدگذاری کلیدها را به شما نشان می‌دهد:

measuring-ssl-rsa-keys-2

مقایسه میزان مصرف CPU در سایز کلید RSA

یک کلید بزرگتر به معنای زمان بیشتر از نظر ارتباط اولیه با وب‌سایت شما از نظر کاربران است. در سیستم عامل‌های Mac و Linux با دستور ساده openssl speed rsa می‌توانید محاسبات زیر را بررسی کنید:

sign verify sign/s verify/s
rsa 512 bits 0.000210s 0.000014s 4772.1 69667.5
rsa 1024 bits 0.000727s 0.000035s 1375.3 28508.9
rsa 2048 bits 0.003778s 0.000092s 264.7 10899.5
rsa 4096 bits 0.022637s 0.000305s 44.2 3275.4

سایز کلید RSA

مشاهده این آمار کاملا گویای این است که میزان مصرف CPU در مقایسه یک کلید ۲۰۴۸ بیتی با یک کلید ۴۰۹۶ بیتی کاملا محسوس است.
به یاد داشته باشید که این ارتباط اولیه خیلی کوتاه است، بعد از به توافق رسیدن مرورگر و سرور در خصوص ارتباط کلید، از یک الگوریتم متقارن مثل AES بهره خواهند برد.


مقایسه ارتباط اولیه مرورگرها

شما می‌توانید یک مقایسه عملی را با تعریف دو کلید ۲۰۴۸ و ۴۰۹۶ بیتی بر روی یک سرور انجام دهید و نتایج را همان‌طور که ما در مرورگر Chrome بررسی کرده‌ایم مشاهده کنید:

measuring-ssl-rsa-keys-4ما ۵ تست با هر دو سایز کلید انجام دادیم و هر بار مرورگر را باز و بسته کردیم تا کلید حذف شود و نتیجه این‌که:

  • میانگین زمان Handshake برای کلید ۲۰۴۸ بیتی ۵۰ میلی ثانیه
  • میانگین زمان Handshake برای کلید ۴۰۹۶ بیتی ۷۶ میلی ثانیه

سایز کلید RSA

میزان زمان اضافه شده در کلید ۴۰۹۶ بیتی قطعا محسوس است با این حال این ارتباط کماکان سریع است.

گوگل انتظار دارد که صفحات شما در کمتر از ۱۰۰ میلی ثانیه محاسبه شوند، آمازون معتقد است هر ۱۰۰ میلی ثانیه اضافه‌تر باعث کاهش فروش خواهد شد! اگر سایت شما بر مبنای HTTPS باشد هیچ یک از محتوای شما نمایش داده نخواهند شد مگراینکه این Handshake انجام شده باشد.
اما این‌که ۲۵ میلی ثانیه – ۲۵ هزارم یک ثانیه برای شما تاثیرگذار است یا خیر کاملا به وب‌سایت شما بستگی دارد. بسیاری از وب‌سایت‌ها – همچنین وب‌سایت زاگریو – بهینه‌سازی‌های بسیاری را قبل از در نظر گرفتن این میزان زمان نیاز دارد به همین دلیل این موضوع باعث مشکل برای ما نمی‌شود.
این تست را ما بعدا بر روی یک موبایل ضعیف تر از نظر پردازشی انجام خواهیم داد.

نگرانی در خصوص سازگاری کلیدهای ۴۰۹۶ بیتی

باید در نظر داشته باشید که سرویس‌هایی مثل Amazon CloudFront فقط از کلید های ۲۰۴۸ بیتی پشتیبانی می‌کنند. همچنین Cisco IOS XE در نسخه‌های قدیمی تر از ۲٫۴ و Cisco IOS قبل از ۱۵٫۱(۱)T از کلید های ۴۰۹۶ بیتی پشتیبانی نمی‌کنند.


خلاصه

به نظر ما – میزبانی زاگریو – همانطور که در ابتدا توضیح داده شد انتخاب شما قطعا باید حداقل یک کلید ۲۰۴۸ بیتی باشد. گسترش دهندگان OpenSSL, Microsoft و تمامی مرورگرها اکیدا توصیه می‌کنند که حداقل از کلید ۲۰۴۸ بیتی استفاده کنید.
آیا می‌خواهید کماکان از یک کلید ۴۰۹۶ بیتی استفاده کنید؟ این آمار را در نظر داشته باشید:

  • یک کلید ۴۰۹۶ بیتی به نسبت یک کلید ۲۰۴۸ بیتی قدرت امنیت شما را تا حد منطقی افزایش می‌دهد.
  • میزان مصرف CPU شما در زمان ارتباط اولیه توسط یک کلید ۴۰۹۶ بیتی به شدت افزایش پیدا خواهد کرد.
  • مرورگرها در اثر تبادل یک کلید با سایز بیشتر کمی بیشتر زمان خواهند برد و سایت شما کمی کندتر خواهد شد.

زاگریو

راه اندازی DNSSEC در سرور BIND DNS

راه اندازی DNSSEC در سرور BIND DNS

999views

راه اندازی DNSSEC در سرور BIND DNS، مهم‌ترین موردی است که شما باید اطلاعات لازم برای راه‌اندازی آن را داشته باشید، در زاگریو به بررسی تخصصی این موضوع مهم خواهیم پرداخت.

DNS و DNSSEC به چه معناست؟

می‌دانیم که DNS یک پروتکل برای تبدیل نام دامنه‌ها به IP addressهای آن‌هاست، اما چگونه می‌توان از صحت IP آدرس بازگشتی مطمئن شد؟ آیا ممکن است که یک هکر DNS را آلوده نماید و IP آدرسی بازگشت دهد که کاربر را به یک سایت مخرب بفرستد، با اینکه نامی که در آدرس بار مرورگر نشان می‌دهد صحیح است؟

خرید دامنه

در اینجا ما از افزونه امنیتی DNS با نام DNSSEC استفاده می‌کنیم که هدف آن حفظ امنیت DNS است. DNSSEC با استفاده از PKI ( کلید عمومی) تمام سوابق منابع DNS (A ،MX ،CNAME و …) بررسی می‌کند و اکنون DNS می‌تواند با فعال کردن DNS resolverهایی مانند Google Public DNS صحت dns مورد نظر از لحاظ IP آدرس و دیگر مشخصه ها را با رکوردهای DNSKEY بررسی نماید.

DNSSEC Resource Records

Resource Record (RR)ها دارای اطلاعات خاصی از دامین می‌باشند. بعضی از رکوردهای عمومی A دارای اطلاعاتی مانند IP address دامنه، بعضی از AAAA دارای اطلاعات IPv6 و MX دارای اطلاعات Mail server دامنه می‌باشند.

لیست کامل RRها را می‌توانید در این صفحه مشاهده نمایید.

List of DNS record types

DNSSEC Resource Records

DNSSEC به تعدادی RR نیاز دارد:

DNSKEY کلید عمومی را که DNS resolverها برای تأیید استفاده می کنند، در خود نگه می دارد.

RRSIG برای هریک از RR وجود دارد و حاوی امضای دیجیتالی رکورد است.

DS – Delegation Signer این رکورد در نام سرورهای TLD وجود دارد. اگر ZAGRIO.COM را در نظر بگیریم. TLD همان .com است nameserver شامل a.gtld-servers.net تا m.gtld-servers.net می‌باشد.

را‌ه‌اندازی

Domain Name: zagrio.com

برای این منظور شما از نام دامنه خود استفاده نمایید.

Master Nameserver:
IP Address: 1.1.1.1
Hostname: master.zagrio.com

OS: Debian 7

Slave Nameserver:
IP Address: 2.2.2.2
Hostname: slave.zagrio.com
OS: CentOS

محل فایل‌ها و نام‌ آن‌ها

نام فایل‌های شما و محل ذخیرسازی آن‌ها بر اساس نوع توزیع لینوکسی که استفاده می‌کنید ممکن است، متفاوت باشد.

Debian/Ubuntu

نام سرویس:
bind9
فایل اصلی پیکربندی:
/etc/bind/named.conf.options
Zone names file:
/etc/bind/named.conf.local
Default zone file location:
/var/cache/bind/

CentOS/Fedora

Sنام سرویس:
named
فایل اصلی پیکربندی و zone names file:
/etc/named.conf
Default zone file location:
/var/named/

این نام‌ها و محل‌ها اگر از bind-chroot استفاده می‌کنید ممکن است متفاوت باشند.

پیکربندی DNSSEC Master

پیکربندی DNSSEC Master

DNSSEC را می‌توان با اضافه کردن دستور العمل‌های پیکربندی در options{ } فعال نمود.

nano /etc/bind/named.conf.options

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

با دستور زیر به zone file خود بروید:

و با دستور زیر Zone Signing Key(ZSK) را بسازید.

اگر haveged را نصب کرده باشید برای ایجاد این key فقط چند ثانیه لازم است. در غیر این صورت زمان بیشتی طول خواهد کشید. خروجی به شکل زیر است:

با دستور زیر نیز می‌توانید Key Signing Key(KSK) را بسازید:

نمونه خروجی به شکل زیر است:

دایرکتوری حالا 4 key دارد. ما public key را هم اضافه کردیم که دارای DNSKEY در zone است، حلقه زیر این کار را برای ما انجام می‌دهد.

با کامند زیر dnssec-signzone را نشانه گذاری و sign می‌نماییم.

salt را با یک چیز رندم عوض کنید نمونه خروجی شما مانند زیر خواهد بود:

یک عبارت string شانزده کاراکتری باید به جای salt وارد شود مانند کامند زیر:

با کامند زیر یک فایل با نام example.com.zone.signed می‌سازیم که رکوردهای RRSIG  در ن جای دارند.

تنظیمات فایل را در بخش zone { } تغییر دهید.

فایل را ذخیره کنید و bind را دوباره بارگذاری نمایید.

بررسی کنید که آیا DNSKEY از dig بر یک سرور مشابه استفاده می‌نماید.

نمونه خروجی:

برای وجود رکورد RRSIG  آن را بررسی کنید.

پیکربندی Master Server به پایان رسیده است.

پیکربندی DNSSEC Slave

برای این منظور نیاز است خط‌های زیر را به فایل کانفیگ اضافه نمایید.

و تنظیمات file را در zone { } تغییر دهید.

BIND را دوباره بارگذاری کنید.

بررسی کنید که آیا فایل جدیدی از .signed داخل ZONE وجود دارد یا خیر.

این بخش هم تمام شد و می‌توانید مانند بخش بالا با dig آن را بررسی نمایید.

پیکربندی رکوردهای DS با استفاده از register

وقتی که کامند dnssec-signzone را خارج از فایل های .signed zone اجرا می‌کنید. یک فایل با نام dsset-zagrio.com نیز ساخته می‌شود. که این فایل شامل رکوردهای DS می‌شود.

این‌ها در کنترل پنل رجیستر دامین وارد شده‌اند. تصاویر زیر این روند را برای سایت GoDaddy نشان می‌دهد.

وارد کنترل پنل رجیستر دامنه‌ی خود شوید. دامنه خود را انتخاب کنید. گزینه manage DS records را انتخاب کنید.

پیکربندی رکوردهای DS با استفاده از register

این ها نیز بکاپ ما در dsset-example.com می‌باشد.

DS record 1:

Key tag: 62910
Algorithm: 7
Digest Type: 1
Digest: 1D6AC75083F3CEC31861993E325E0EEC7E97D1DD

DS record 1

DS record 2:

Key tag: 62910
Algorithm: 7
Digest Type: 2
Digest: 198303E265A856DE8FE6330EDB5AA76F3537C10783151AEF3577859FFFC3F59D

DS record 2

رکورد دوم dsset-example.com دارای اسپیس داخل digest می‌باشد. ولی زمانی که آن را import کنید باید آن را حذف نمایید.

DS record 2

چند دقیقه طول می‌کشد تا تغییرات ذخیره شوند. بعد از تایید می‌توانید با سرویس‌های آنلاینی مانند سرویس‌های زیر DNSSEC خود را بررسی کنید.

http://dnssec-debugger.verisignlabs.com/

http://dnsviz.net/

سایت اول بسیار ساده است. اما سایت دوم به صورت ویژوآل و تصویری به شما نشان می‌دهد. در زیر تصویری از سایت اول قرار گرفته است.

http://dnssec-debugger.verisignlabs.com/

خط اولی که با قرمز نشان داده شده Key tag مقدار DS رکوردها را نشان می‌دهد. خط دوم مقدار key id که مربوط به ZSK می‌باش را نشان می‌دهد.

زاگریو

مسدود کردن دسترسی ربات های مخرب با htaccess

مسدود کردن دسترسی ربات‌های مخرب با htaccess

790views

 

 

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

به آدرس /home/username/public_html/.htaccess بروید و فایل رامطابق زیر ویرایش نمایید.

تمامی ربات‌های ذکر شده در خطوط بالا زمانی که قصد مراجعه به سایت شما را داشته باشند با ارور 403 مواجه خواهند شد.

با استفاده از htaccess  حتی می‌توانید IPهای مخرب را هم به صورت زیر بلاک نمایید.

در زیر به شیوه ویرایش htaccess در cPANEL می‌پردازیم:

در قدم اول با یک کلاینت FTP به سرور خود متصل شوید کلاینتی مانند FileZilla  استفاده نمایید تا فایل را ویرایش نمایید.

در قدم بعدی به cPanel File Manager خود بروید

قراردادن رمز برای دایرکتوری‌های متفاوت در cPanel

قراردادن رمز برای دایرکتوری‌های متفاوت در cPanel

 

 

ممکن است نیاز داشته باشید یک دایرکتوری در cPanel را با پشورد محافظت نمایید. برای اینمنظور پیشنهاد ما این است که این آموزش کوتاه را تا انتخا بخوانید و با این امر آشنا شوید.

قدم اول: با گذرواژه و نام کاربری خود وارد پنل cPanel  خود شوید که معمولا آدرس مانند yourdomain.com/cpanel دارد.

قدم دوم: به دنبال گزینه Directory Privacy  بگردید و بر روی آن کلیک نمایید.

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

قدم چهارم: با کلیک شما صفحه ای جدید باز می‌شود که Enter a name for the protected directory پیغامی مانند آنچه آورده شده به شما نشان می‌دهد در این بخش می‌توانید نام دلخواه خود را بر بخش محافظت شده قرار دهید.

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

فعال کردن ModSecurity در cPanel

فعال کردن ModSecurity در cPanel

601views

 

 

در نسخه‌ جدید cPanel شما توانایی فعال کردن یا غیرفعال کردن ModSecurity را از طریق اکانت خود دارید. حتی ممکن است که این قابلیت در cPanle شما فعال نشده باشد. ModSecurity که به Modsec نیز معروف است، یک Web application firewall یا به اختصار WAF اوپن سورس می‌باشد. که به صورت پیش فرض بعنوان یگ ماژول برای Apache HTTP Server توسعه داده شده است.

برای فعال کردن یا غیرفعال کردن ModSecurity باید مانند زیر عل نمایی:

قدم اول: وارد آدرس yourdomain.com/cpanel خود شوید.

قدم دوم: به بخش Security بروید و به دنبال ModSecurity بگردید.

قدم سوم: در این بخش می‌توانید ModSecurity را برای تمام دامین‌های خود فعال یا غیر فعال نمایید.

غیر فعال کردن ModSecurity برای یک یا چند دامنه فقط برای زمانی که شما در حال رفع یک مشکل هستید مناسب است، این اقدام باعث رفع لایه‌ی محافظتی سایت شما می‌شود.