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. دریافت مشاوره تخصصی:

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

نتیجه‌گیری:

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

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

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

زاگریو22 آذر 1403

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

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

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

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

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

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

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

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

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

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

sudo dnf install dnf-automatic

1	sudo dnf install dnf-automatic

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

sudo nano /etc/dnf/automatic.conf

1	sudo nano /etc/dnf/automatic.conf

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

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

systemctl enable --now dnf-automatic.timer

1	systemctl enable --now dnf-automatic.timer

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

systemctl list-timers 'dnf-*'

1	systemctl list-timers 'dnf-*'

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

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/

[emitters]
emit_via = email
[email]
# The address to send email messages from.
email_from = noreply@zagrio.com
# List of addresses to send messages to.
email_to = support@zagrio.com
# Name of the host to connect to to send email messages.
email_host = localhost

[emitters]

emit_via = email

[email]

# The address to send email messages from.

email_from = noreply@zagrio.com

# List of addresses to send messages to.

email_to = support@zagrio.com

# Name of the host to connect to to send email messages.

email_host = localhost

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

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

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

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

sudo dnf install auter

1	sudo dnf install auter

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

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

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

auter --apply

1	auter --apply

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

auter --disable

1	auter --disable

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

اطلاع رسانی

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

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

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

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

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

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

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

زاگریو6 خرداد 1403

مقدمه

سربرگ‌های پاسخ 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 را انتخاب کنید.

در پنل “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 در ادامه بیان می کند:

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

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

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

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

زاگریو15 اردیبهشت 1401

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 شما در زمان ارتباط اولیه توسط یک کلید ۴۰۹۶ بیتی به شدت افزایش پیدا خواهد کرد.
مرورگرها در اثر تبادل یک کلید با سایز بیشتر کمی بیشتر زمان خواهند برد و سایت شما کمی کندتر خواهد شد.

RDP و RDS چیست؟

Saman Yazdannik1 خرداد 1400

2.8kviews

در این مطلب شما با مفهوم کلی (Remote Desktop Services) RDS و (Remote Desktop Protocol) RDP و همچنین اجزای آن، به طور کامل آشنا خواهید شد، احتمالا شما با کلمه Remote آشنایی دارید و از Remote Desktop Connection موجود در ویندوز 7 استفاده کرده‌اید و حداقل یک بار به گوشتان خورده است. در زاگریو به بررسی این مطالب خواهیم پرداخت.

RDP/RDS چیست؟

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

RDP/RDS

در گذشته TSE (Terminal Services) و حالا RDS (Remote Desktop Services) یک نقش بومی یا نیتیو در Windows Server 2008, 2012/2012R2, 2016 و 2019 می‌بود و مجموعه‌ای از سرویس‌هاست که به یک یا چند کاربر اجازه می‌دهد از طریق پروتکل RDP به برنامه‌های (RemoteApp Programs), Windows Desktop (Remote Desktop Sessions) یا دسکتاپ مجازی (VDI) دسترسی همزمان داشته باشند. این اتصال و دسترسی با استفاده از شبکه داخلی درون یک مجموعه یا اینترنت صورت می‌گیرد.

اجزای RDS

RDS شامل شش سرویس است:

1 . Remote Desktop Session Host (RDSH): به شما اجازه می دهد چندین دسکتاپ را با اتصال همزمان از راه دور مدیریت کنید.

2 . Remote Desktop Virtualization Host (RDVH): سرور RDVH با “Microsoft Hyper-V” ادغام می شود تا دسکتاپ‌های مجازی یا ویرچوآل ماشین‌ها را بر اساس تقاضا توزیع نماید. نقش RDVH نشان دهنده زیرساخت Microsoft VDI می‌باشد.

3 . Remote Desktop License Server (RDLS): این نقش نصب و توزیع کلیه RDS CAL را مدیریت می کند. (برای هر کاربر و هر دستگاه)

4 . Remote Desktop Connection Broker (RDCB): برای مدیریت لود بالانس و سشن‌های اتصال مجدد RDS بکار می‌رود.

5 . Remote Desktop Gateway (RDG): RDG به عنوان یک فایروال RDP برای تمامی کاربران از راه دور دسکتاپ عمل می‌کند. RDG فقط از HTTPS / 443 استفاده می کند و برای ایمن سازی، RDP را روی HTTPS انتقال می‌دهد.

6 . Remote Desktop Web Access (RDWA): این یک پورتال دسترسی به وب RDS است که به شما امکان انتشار منابع (ریسورس‌های) داخلی RDS و توزیع‌ها را از طریق یک پورتال وب را به شما می‌دهد.

معماری RDS

در یک نگاه، معماری استاندارد RDS ویندوز سرور از نسخه 2008 تا 2019 با اجزای ذکر شده در بالا به صورت تصویر زیر اجرایی می‌گردند:

RDP Components

آیا RDP یک پروتکل امن است؟

پیکربندی پیش فرض RDP هنگام فعال بودن، آن را در برابر چند حمله متفاوت آسیب پذیر می‌کند. با این حال، برخی از پیشرفت های امنیتی در نسخه جدید RDS برای Windows Server ارائه شده است.

به طور پیش فرض، چندین حمله امکان پذیر است:

Denial of Service 🙁DoS) یا همان داس
Man-in-The-Middle 🙁MiTM)
Brute-Force: بروت فورس

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

هنگام سروکله زدن با پروتکل RDP، به طور پیش فرض چندین آسیب پذیری و خطر امنیتی وجود دارد که باید آن‌ها را بشناسید و آن‌ها را در نظر بگیرید:

نمایش RDS بر روی اینترنت
Man-in-the Middle (MiTM)
حمله رمزگذاری
حمله داس Denial of Service (DOS)
تخلیه هش‌های رمزعبور
پیکربندی اشتباه RDS
باج افزار
حمله بروت فورس
استفاده از RDSH فضای اشتراک گذاشته‌ شده‌‌‌‌‌‌‌‌‌‌‌‌‌ی RDS
استفاده از KEY LOGGERها

نمایش RDS بر روی اینترنت

هیچ ضرورتی وجود ندارد که سرویس Remote Desktop را در در معرض اینترنت و اتصال از طریق اینترنت قرار دهید، اتصال از طریق اینترنت و خارج از شبکه داخلی باعث می‌شود کاربران خطرناک و افرادی که قصد حمله به RDS شما را دارند از این فرصت استفاده کنند و بیشتر نیز سعی می‌نمایند اکانت administrator را هدف قرار دهند. در این میان اگر هکرها موفق شوند رمز عبور با موفقیت حدس بزنند و پیدا کنند، دسترسی حاصل می‌تواند پیامدهای قابل توجهی برای سازمان شما داشته باشد و حملات بیشتر علیه زیرساخت های قابل اعتماد شما یا متصل به شما را تسهیل کند.

حمله Man-in-the Middle (MiTM)

اگرچه سرویس Remote Desktop رمزگذاری داده را بین کاربر و سرور به طور پیش فرض فراهم می‌کند ، اما تأیید هویت سرور Terminal / RDSH را تأیید نمی‌کند. این عدم تأیید هویت به هکر اجازه می دهد، با به کارگیری سایر روش‌های حمله و نفوذ، کلیه ارتباطات ارسالی بین کاربر و Terminal Server را رهگیری کند. احتمال این نوع حمله به توانایی هکر در کنترل ارتباطات بین سرویس گیرنده(کاربر) و Terminal Server بستگی دارد. به طور معمول، هکر نیاز به حملات دیگری مانند جعل ARP (پروتکل حل آدرس) یا جعل اطلاعات DNS (Domain Name System) دارد که اطلاعات را قبل از ارسال به سرور اصلی به سرور خود هدایت کند.

حمله رمزگذاری

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

حمله داس Denial of Service (DOS)

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

تخلیه هش‌های رمزعبور

باید اطمینان حاصل کنید ک هیچ یک از کاربران ریموت دسکتاپ شما “Local Administrators” نیستند زیرا اگر چندین Local Admin داشته باشید، این مدیران می‌توانند با استفاده از ابزارهای dump hash password رمز دیگر adminها را بر روی شبکه متوجه شوند. برای جلوگیری از هرگونه خطر مربوط به استفاده از ابزار dump hash password مانند Mimikatz، باید از AppLocker استفاده شود.

پیکربندی اشتباه RDS

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

باج افزار

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

حمله بروت فورس

اگر از پسوردهای ضعیف استفاده می‌نمایید امکان آسیب پذیری شما در مقابل حملات بروت فورس بسیار بالاست. برای جلوگیری از این نوع حمله بهترین راه حل اطمینان از رمز عبور قدرتمند برای تمامی افرادی است که به RDS شما متصل می‌گردند. یکی دیگر از نکات مفید کم کردن تعداد افرادی است که به RDSHشما دسترسی دارند، هیچگاه از تنظیمات « illimited » با تعداد نامعلومی کاربر برای اتصال به سرور استفاده نکنید.

فضای اشتراک گذاشته‌ شده‌‌‌‌‌‌‌‌‌‌‌‌‌ی RDS

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

مجموعه RDS اغلب برای میزبانی از همه نوع برنامه‌ها یک شرکت (منابع انسانی، امور مالی، IT … ) استفاده می شود و هیچ استثنا و تغییری از لحاظ محدودیت دسترسی برنامه‌ها وجود ندارد در واقع همه برنامه‌ها در یک محیط “مشترک” / سرورهای میزبان RD اجرا می‌گردند. و این امر باعث ایجاد حمله و نفوذ می‌شود. برای حل این موضوع بهتر است هر برنامه یا هر محیطی بر یک مجموعه RDS جداگانه اجرا شود.

حمله با استفاده از Keyloggerها به RDP

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

تمهیدات امنیتی مهم برای RDP:

فعال کردن HA (High Availability) برای تمامی سرویس‌های RDS: فعال کردن برای RDSH/RDCB/RDWA/RDG/RDLS و SQL server
ایجاد یک مجموعه جدید RDS برای هر کاربر و هر برنامه
نصب RDG (Remote Desktop Gateway) برای همه کاربران خارج از مجموعه
فعال کردن MFA (یا 2FA)
فعال کردن NLA (Network Level Authentication) برای تمام مجموعه‌های RDS
رمزگذاری سطح بالا برای کلیه ارتباطات RDP (رمزگذاری 128 بیتی)
استفاده از احراز هویت TLS برای همه RDSH ها
AppLocker را در تمام سرورهای میزبان RD سشن‌ها تعریف و اعمال کنید
ایجاد پسورد قوی برای همه استفاده کنندگان
تغییر پورت پیش فرض RDP
عدم دسترسی حضوری به سرورهای RD
محدود کردن تعداد کاربران
تمام لاگ‌های RDباید ذخیره گردد و به صورت مداوم آنالیز شود

فعال کردن HA (High Availability) برای RDP

کلیه سرویس‌ها و اجزای RD باید در دسترس باشند:

1 . RD Session Host Server: حداقل دو سرور RDSH باید بخشی از یک مجموعه اختصاصی RDS باشند

2 . RD Connection Broker: حداقل دو سرور RDCB باید مستقر و پیکربندی شوند، حالت HA (SQL Server مورد نیاز است)

3 . RD Web Access: حداقل دو سرور RD Web Access باید در کنار Load balancer مستقر و پیکربندی شوند

4 . RD Gateway: حداقل دو سرور RD Gateway باید در حالت HA و کنار Load Balancer مستقر و پیکربندی شوند

5 . RD Licensing Server: حداقل دو سرور لایسنس RD در حالت HA باید مستقر و پیکربندی شوند

ایجاد یک مجموعه جدید RDS برای هر کاربر و هر برنامه

ابتدا باید تمام برنامه های منتشر شده خود را لیست کنید (RemoteApps) سپس، باید یک لیست دسته‌بندی از برنامه های خود ایجاد کنید. هر گروه برنامه باید از طریق یک مجموعه اختصاصی RDS Session (سرورهای اختصاصی RDSH) منتشر و توزیع شود. RD Web Access & RD Gateway را می توان برای همه کاربران ریموت دسکتاپ به اشتراک گذاشت (حالت اشتراکی برای سرویس های وب RD مجاز است).

نصب RDG (Remote Desktop Gateway) برای RDP

توصیه می شود برای همه کاربران ریموت دسکتاپ یک RD Gateway مستقر کنید و یک CAP قوی (خط مشی های دسترسی اتصال) و RAP (خط مشی های دسترسی به منابع) را برای بهبود سطح امنیت محیط RDS تعریف کنید. RD Gateway برای کار کردن به یک گواهینامه SSL معتبر نیاز دارد، گواهی SSL که به RD Gateway تحویل داده می شود باید توسط CA معتبر/معتمد (مرجع صدور گواهینامه) ارائه شده باشد.

فعال کردن MFA (یا 2FA)

توصیه می شود MFA (احراز هویت چند عاملی) را برای همه کاربران ریموت دسکتاپ فعال کنید که از خارج به منابع داخلی RDS شما متصل می‌شوند. سرویس MFA برای کارکرد به یک RD Gateway نیاز دارد. کاربران ریموت دسکاپ برای تکمیل فرآیند MFA باید حداقل یک دستگاه فیزیکی (تلفن هوشمند و …) داشته باشند.

فعال کردن NLA (Network Level Authentication)

تأیید اعتبار سطح شبکه (یا NLA) از ارائه دهنده CredSSP برای ارائه اعتبارنامه کاربر به سرور، قبل از اینکه سرور یک سشن ایجاد کند استفاده می‌کند. این امر با جلوگیری از هرگونه خطر امنیتی مربوط به حمله DOS، سطح امنیتی محیط RDS را بهبود می‌بخشد. توصیه می شود NLA را در همه مجموعه‌های RDS خود فعال کنید.

رمزگذاری سطح بالا برای کلیه ارتباطات RDP (رمزگذاری 128 بیتی)

به طور پیش فرض، سرویس Remote Desktop از تنظیمات رمزگذاری متوسط سازگار با کلاینت استفاده می‌کند. این سطح از رمزگذاری، اطلاعات ارسالی بین کاربر و سرور را با حداکثر قدرت کلید پشتیبانی شده توسط کاربر رمزگذاری می کند. به طور کلی در چنین محیطی تعدادی از کاربرها از نسخه‌های اولیه کلاینت استفاده می‌کنند که خود ریسک‌را افزایش می‌دهد. بنابراین توصیه می‌شود از سطح رمزنگاری “High”برای رمزنگاری استفاده نمایید.

استفاده از احراز هویت TLS برای همه RDSH ها

تمامی سرورهای ایجاد کننده سشن RD باید توسط TLS برای RDS احرازهویت شوند، این کار برای جلوگیری از به سرقت رفتن هویت کاربران از راه دور اجباری است. گواهینامه های SSL که برای تأیید اعتبار سرورهای RDSH استفاده می شوند باید توسط CA معتبر (مرجع صدور گواهینامه) یا PKI داخلی شما تایید و تحویل گردند.

اعمال AppLocker

شما باید RD Session Host خود را که میزبان جلسات و برنامه های منتشر شده است را قفل کنید. یک سیاست یا پالیسی قوی AppLocker باید برای همه سرورهای میزبان RD شما تعریف و اعمال شود. ابتدا باید برنامه های خود را بررسی کرده و تمام اطلاعات مورد نیاز مانند “Apps Thumbprint” را برای تعریف و استفاده از AppLocker خود جمع آوری و ارسال کنید. در آخر توصیه می‌کنیم که یک لیست سفید از اپلیکیشن‌هایی که می‌توانند اجرا شوند ایجاد کنید.

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

ایجاد یک رمز قوی و یا یک سیاست رمز برای ایجاد آن توسط کاربران ریموت بسیار مهم و تاثیرگذار است. با استفاده از AD Group Policy Object ، می توانید سیاست گذرواژه خود را ایجاد ، پیکربندی و اعمال کنید (به عنوان مثال: RDS-USERS).

تغییر پورت پیش فرض RDP

به طور پیش فرض ، پروتکل RDP با پورت 3389 کار می‌کند. و این پورت توسط چندین نرم افزار مخرب/باج افزار هدف قرار می‌گیرد. هکرها نیز در مرحله Footprinting این پورت پیش فرض را هدف قرار می دهند پس توصیه ما تغییر این پورت به پورتی مانند 33381 می‌باشد. برای این تغییر می‌توانید از این اسکریپت استفاده کنید.

امن کردن دستگاه کاربران متصل به RDP

اگر خط مشی امنیتی شما محدود کردن کلیه تغییر مسیر منابع محلی (درایو محلی، چاپگرها، کلیپ بورد و… ) می‌باشد، باید تمام گزینه های تغییر مسیر منابع محلی را بر روی سرورهای RD Session Hosts خود (از طریق GPO) را انجام دهید و همین سیاست را نیز برای دستگاه‌های متصل از راه دور کاربران در پیش بگیرید. کلید رجیستری ذکر شده در بخش “ضمیمه” را می توان از طریق GPO پیکربندی کرد تا تمام تغییر مسیر منابع محلی RDC را غیرفعال کند> MSTSC.exe

محدود کردن تعداد کاربران

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

تمام لاگ‌های RDباید ذخیره و آنالیز گردند

تمام عملیات انجام شده در محیط RDS شما باید ثبت شوند: اتصالات ، اتصال مجدد ، تغییر/اصلاح ها تجزیه و تحلیل شوند تا ارتباطات مشکوک یا رفتارهای غیرعادی اگر وجود دارد کشف و رهگیری شود. در کمترین حالت حداقل باید سیاست WEF (Windows Event Forwarding) تعریف و پیکربندی شود.

تست نفوذ محیط RDS

پس از استقرار RDS، باید آزمایشات نفوذ را در محیط RDS خود انجام دهید، این HLV به شما امکان می دهد قبل از ادغام آن در محیط پروداکشن، سطح امنیتی بستر RDS خود را تأیید کنید. برای تأیید وضعیت امنیتی RDS باید چندین آزمایش زیر انجام شود:

امنیت تمام اجزای RDS شامل: RDG, RD Web Access
روند احراز هویت
حمله رمزگذاری
احراز هویت TLS
حمله MiMT
حمله D/DoS
انزوای شبکه
خط مشی محدودیت برنامه ها
مجموعه RDS Multi-tenancy

ضمیمه: (محدود کردن تغییر مسیر منابع محلی(MSTSC.exe))

برای غیرفعال کردن تغییر مسیر کلیپ بورد، کلید رجیستری زیر باید در دستگاه های ریموت دسکتاپ/لپ تاپ های کاربر ایجاد شود:

Key Path : HKLM\SOFTWARE\Microsoft\Terminal Server Client
Registry Key Name : DisableClipboardRedirection
Key Type : REG_DWORD
Data Value : 1

برای غیرفعال کردن تغییر مسیر Local Drive، باید کلید رجیستری زیر در دستگاه های ریموت دسکتاپ/لپ تاپ های کاربر ایجاد شود:

Key Path : HKLM\SOFTWARE\Microsoft\Terminal Server Client
Registry Key Name : DisableDriveRedirection
Key Type : REG_DWORD
Data Value : 1

برای غیرفعال کردن تغییر مسیر پرینترها، اید کلید رجیستری زیر در دستگاه های ریموت دسکتاپ/لپ تاپ های کاربر ایجاد شود:

Key Path : HKLM\SOFTWARE\Microsoft\Terminal Server Client
Registry Key Name : DisablePrinterRedirection
Key Type : REG_DWORD
Data Value : 1

قفل کردن سرورهای RDSH

RDP 2

RDP 4

هرچیزی که در مورد Firewalld باید بدانید

Saman Yazdannik19 اردیبهشت 1400

504views

در بعضی موقعیت‌ها استفاده از firewalld بر روی سیستم‌های systemd از مدیریت و پیکربندی iptableها راحت تر است. برای بیشتر بخش‌ها دیگر به یادگیری و به خاطر سپردن پرش‌ها، قبول کردن‌ها و رد کردن‌ها نمی‌باشید. قوانین راه‌اندازی firewalld بسیار ساده‌تر و در دسترس تر می‌باشند. اما همزمان این مورد باعث نمی‌شود که به قدرت و امکانات iptables دسترسی نداشته باشید.

firewalld چیست؟

firewalld از یک کامندلاین با نام firewall-cmd برای پیکربندی و تغییر قوانین استفاده می‌کند. قبل از اینکه firewalld را پیکربندی کنیم نیاز است که مطمئن شویم سرویس درحال اجراست، با استفاده از دستور systemctl شما سرویس firewalld را راه‌اندازی، متوقف، شروع، پایان یا راه‌اندازی مجدد می‌نمایید. متاسفانه برای تمامی استفاده‌های ذکر شده هیچ خروجی متفاوتی توسط systemctl نمایش داده نمی‌شود که بتوان میان آن‌ها تمایز قائل شد. پس نیاز است که بعد از هربار استفاده از این دستور از وضعیت firewalld آگاه شوید.

firewalld

Systemctl و Firewalld

فعال‌سازی Firewalld

برای اینکه مطمئن شوید firewalld بصورت اتوماتیک با سرور راه‌اندازی شده از دستور زیر استفاده نمایید.

systemctl enable firewalld

شروع firewalld

بعد از اینکه firewalld فعال شد، نیاز است که برای بار اول آن را راه‌اندازی(شروع یا استارت) نماییدو برای این کار نیاز است که از دستور زیر استفاده نمایید:

systemctl start firewalld

توقف firewalld

زمانی که به اصلاح قوانین یا رفع اشکال اتصالات(کانکشن‌ها) می‌پردازید لازم است که firewalld را متوقف کنید، برای منظور می‌توانید از دستور زیر استفاده نمایید.

systemctl stop firewalld

راه‌اندازی مجدد firewalld

اگر به هر دلیلی مجبور شدید تا firewalld را راه اندازی مجدد نمایید می‌توانید از دستور زیر در systemctl استفاده نمایید:

systemctl restart firewalld

وضعیت firewalld

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

systemctl status firewalld

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

[root@centos-7 ~]# systemctl status firewalld ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2019-01-22 22:50:32 EST; 1h 0min ago Main PID: 808 (firewalld) CGroup: /system.slice/firewalld.service └─808 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

مدیرت firewalld و پیکربندی آن

حال که با دستورات ابتدایی اجرایی firewalld آشنا شدیم و firewalld خود را راه‌اندازی نمودیم‌ میتوانیم به مبحث مدیریت و پیکربندی firewalld بپردازیم بعنوان مثال یک پورت را باز کینم، به سرویس‌ها اجازه فعالیت دهیم، IPها را در لیست سفید قرار دهیم و کارهایی از این قبیل. در تمامی این مثال‌ها ما از پرچم یا فلگ –permanent استفاده می‌کنیم این مهم به این معنی است که قانون وضع شده شما ذخیره می‌گردد حتی بعد از راه اندازی مجدد Firewalld یا ریبوت کردن سرور. بعد از اضافه کردن قوانین جدید لازم است که شما firewall خود را راه اندازی مجدد نمایید تا قوانین جدید اجرا شوند.

اضافه کردن پورت برای UDP یا TCP

برای اضافه کردن یا باز کردن یک پورت در UDP یا TCP نیاز است تا به صورت جداگانه آن دستورات را برای هر نوع پروتکل اجرا نمایید:

firewall-cmd --permanent --add-port=22/TCP

firewall-cmd --permanent --add-port=53/UDP

حذف کردن پورت برای UDP یا TCP

دستور زیر که برای حذف یا بستن یک پورت در پروتکل‌های ذکر شده کاربرد دارد بسیار شبیه به دستورات بالاست با تفاوتی اندک:

firewall-cmd --permanent --remove-port=444/tcp

اضافه کردن سرویس

سرویس‌ها به صورت پیشفرض از پورت‌هایی که در بخش /etc/services پیکربندی شده استفاده می‌نمایند، اما اگر نیاز دارید تا از پورتی خارج از پورت‌های پیش‌فرض برای سرویس‌های خود استفاده نمایید باید آن پورت را باز کنید برای این منظور می‌توانید از دستور زیر استفاده نمایید:

firewall-cmd --permanent --add-service=ssh

firewall-cmd --permanent --add-service=http

حذف کردن یک سرویس

با دستور زیر می‌توانید یک سرویس و پورت گشوده شده برای آن را پاک کنید/ ببندید:

firewall-cmd --permanent --remove-service=mysql

اضافه کردن یک IP به لیست سفید

برای اضافه کردن یک IP یا یک رنج از IPها کافیست با دستور زیر این IPها را به لیست مورد اعتماد firewall اضافه نمایید:

firewall-cmd --permanent --add-source=192.168.1.100

برای اضافه کردن بک رنج از IPها نیز می‌توانید از دستور زیر بهره جویید:

firewall-cmd --permanent --add-source=192.168.1.0/24

حذف کردن یک IP از لیست سفید

برای حذف کردن یک IP یا یک رنج IP می‌توانید از –remove-source مانند مثال زیر استفاده کنید:

firewall-cmd --permanent --remove-source=192.168.1.100

بلاک کردن یک IP

به صورت عمومی firewall-cmd برای اجازه دسترسی و بلاک کردن دسترسی استفاده می‌شود و یکی از بیشترین استفاده‌ها نیز بلاک کردن دسترسی یک IP است برای این منظور ما نیاز به rich rule داریم که بسیار شبیه به قوانینی است که برای iptable استفاده می‌کنیم:

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='192.168.1.100' reject"

برای بلاک کردن یک رنج IP نیز همانند بالا می‌توانیم از دستور CIDR زیر استفاده کنیم:

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='192.168.1.0/24' reject"

اضافه کردن یک IP به لیست سفید در یک پورت مشخص

برای این عمل نیاز به اعمال قوانین بیشتر یا rich rule بیشتر می‌باشد، برای این منظور باید به iptable برگردیم و از قوانین خود استفاده نماییم و در پایان از accept استفاده می‌کینم تا IP به لیست سفید افزوده گردد نه اینکه reject شود.

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port protocol="tcp" port="3306" accept'

حذف یک Rich Rule

برای حذف یک rich rule از آپشن —remove-rich-rule استفاده می‌نماییم هرچند که در این فرایند باید مشخص نمایید که چه قانونی قرار است حذف گردد، توصیه ما کپی کردن و پیست کردن کامل آن قانون است تا انکه آن را تایپ نمایید زیر ممکن است آن را کامل به یاد نیاورید و دچار مشکل شوید:

firewall-cmd --permanent --remove-rich-rule='rule family="ipv4" source address="192.168.1.100" port protocol="tcp" port="3306" accept'

ذخیره قوانین Firewall

بعد از اینکه تمامی قوانین مورد نظر خود را اضافه نمودید و تصمیمی گرفتید که آنها را اجرایی کنید نیاز است که فایروال خود را بار دیگر راه‌اندازی نمایید برای این منظور باید دستور زیر را با firewall-cmdاجرا نمایید.

firewall-cmd --reload

مشاهده قوانین firewall

بعد از اینکه فایروال را راه‌اندازی مجدد نمایید بهتر است که مطمئن شویم تمامی قوانین مورد نظر ما در جای خودشان قرار گرفتته‌اند برای این منظور می‌توان از دستور زیر استفاده نمود:

firewall-cmd --list-all

مثال زیر یک نمونه از خروجی آپشن –list-all می‌باشد، در مثال زیر می‌توانید پورت‌ها، rich ruleها و سرویس‌های باز را مشاهده نمایید.

[root@centos-7 ~]# firewall-cmd --list-all public (default, active) interfaces: enp1s0 sources: 192.168.1.0/24 services: dhcpv6-client dns http https mysql nfs samba smtp sshports: 443/tcp 80/tcp 5900-5902/tcp 83/tcp 444/tcp 3260/tcp masquerade: no forward-ports: icmp-blocks: rich rules: rule family="ipv4" source address="192.168.1.0/24" forward-port port="5423" protocol="tcp" to-port="80"

پیکربندی Firewalld به صورت تصویری

اگرچه مطلب نوشته شده تمرکزش بیشتر بر روی اجرای دستورات و استفاده از firewall-cmd بود اما راه دیگر ایجاد قوانین و اجرای دستورات استفاده از رابط گرافیکی firewalld می‌باشد که می‌توانید آن را در قسمت Applications > Sundry در CentOS 7 و RedHat 7.x پیدا کنید. برای نصب این رابط گرافیکی می‌توانید از دستور زیر استفاده نمایید:

sudo yum install firewall-config

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

قوانین مستقیم Firewalld

قوانین مستقیم نوعی از قوانین هستند که به صورت مخصوصی از دیگر قوانین جدا شده‌اند، برای این هستند که به صورت مستقیم با firewall ارتباط برقرار شود این قوانین را می‌توانید در فایلی به آدرس /etc/firewalld/direct.xml ویرایش نمایید. هرچند این قوانین نیز مانند دیگر قوانین نیاز است که فایروال برای اجرای این قوانین راه اندای دوباره گردد. این قوانین مانند rich ruleها یا قوانین iptables می‌باشند فقط در یک فایل XML نوشته شده‌اند. رابط کاربری قوانین مستقیم بیشتر توسط سرویس‌‍ها و اپلیکیشن‌ها برای اضافه کردن قوانین مخصوصی استفاده می‌گردد. در مثال زیر تعدای IP را می‌بینید که برخلاف لیست سیاه می‌باشند و به فایروال می‌گوید که با بررسی IPها و مچ شدن با آن‌ها کانکشن را قطع نماید، باید توجه داشت که شما می‌توانید برای اضافه کردن قوانین مستقیم از firewall-cmd استفاده نمایید اما باید در انتهای دستور از –direct استفاده نمایید.

<?xml version="1.0" encoding="utf-8"?> <direct> <chain ipv="ipv4" table="raw" chain="blacklist"/> <rule ipv="ipv4" table="raw" chain="PREROUTING" priority="0">-s 192.168.1.0/24 -j blacklist</rule> <rule ipv="ipv4" table="raw" chain="PREROUTING" priority="1">-s 192.168.5.0/24 -j blacklist</rule> <rule ipv="ipv4" table="raw" chain="blacklist" priority="0">-m limit --limit 1/min -j LOG --log-prefix "blacklisted: "</rule> <rule ipv="ipv4" table="raw" chain="blacklist" priority="1">-j DROP</rule></direct>

کلام آخر..

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

ولی اگر به هرگونه مشکلی برخوردید، کارشناسان زاگریو، به صورت ۲۴ ساعته جواب‌گوی سوالات شما عزیزان هستند.

دیتابیس‌های NoSQL: افزایش امنیت و بررسی امنیت آنها

Saman Yazdannik15 مهر 1399

425views

حملات SQL injection از شایع ترین و مورد استفاده ترین حملات سالهای اخیر بوده اند. اما فقط SQL (relational database) ها نیستند که آسیب پذیرند بلکه NoSQL (non-SQL دیتابیس‌های غیر ارتباطی) نیز در معرض خطر می‌باشند.

احتمالا شاید ندانید که هم اکنون بالای 100 نوع مختلف NoSQL وجود دار اما بیشتر ما با Redis و MongoDB آشنا هستیم و این نیز به لطف جامعه نرم افزار آزاد است که تعداد از بهترین NoSQL را توسعه داده اند.

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

اگر از دیتابیس های NoSQL مانند MongoDB استفاده می‌کنید و نمی دانید که آیا برای پروژه شما مناسب است و آیا مشکلات امنیتی می‌تواند در آینده بلای جان شما شود بهتر است این مطلب را تا پایان بخوانید و از ابزار معرفی شده آن استفاده نمایید.

NoSQLMap

این ابزار یک ابزار کوچک توسعه داده شده با پایتون است، که توانایی بررسی پیکربندی شما برای یافتن پیکربندی اشتباه و خودکارسازی تست انجکشن را دارد و به شما می‌گوید که آیا NoSQL خود را اشتباه پیکربندی نموده‌اید یا نه. این ابزار پر استفاده را می‌توان برای دیتابیس‌های زیر استفاده نمود:

MongoDB
CouchDB
Redis
Cassandra

برای نصب NoSQLMap شما به پایتون، گیت و Setuptools module نیاز دارید که با دستور زیر می‌توانید در اوبونتو آ« را نصب نمایید.

apt-get install python
apt-get install python-setuptools

1 2	apt-get install python apt-get install python-setuptools

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

git clone https://github.com/codingo/NoSQLMap.git
python setup.py install

1 2	git clone https://github.com/codingo/NoSQLMap.git python setup.py install

زمانی که نصب به پایان رسید، باید ./nosqlmap.py را از گیت اجرا نمایید که نتیجه ای مانند زیر برای شما به همراه خواهد داشت:

_ _ ___ ___ _ __ __
| \| |___/ __|/ _ \| | | \/ |__ _ _ __
| .` / _ \__ \ (_) | |__| |\/| / _` | '_ \
|_|\_\___/___/\__\_\____|_| |_\__,_| .__/
v0.7 codingo@protonmail.com |_|
1-Set options
2-NoSQL DB Access Attacks
3-NoSQL Web App attacks
4-Scan for Anonymous MongoDB Access
5-Change Platform (Current: MongoDB)
x-Exit
Select an option:

_ _ ___ ___ _ __ __

| \| |___/ __|/ _ \| | | \/ |__ _ _ __

| .` / _ \__ \ (_) | |__| |\/| / _` | '_ \

|_|\_\___/___/\__\_\____|_| |_\__,_| .__/

v0.7 codingo@protonmail.com |_|

1-Set options

2-NoSQL DB Access Attacks

3-NoSQL Web App attacks

4-Scan for Anonymous MongoDB Access

5-Change Platform (Current: MongoDB)

x-Exit

Select an option:

Mongoaudit

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

نصب Mongoaudit بسیار ساده است کافیست با استفاده از pip دستور زیر را اجرا نمایید:

pip install mongoaudit

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

دیتابیس‌های NoSQL

YubiKey محصولی برای احراز هویت شما به صورت سخت افزاری

Saman Yazdannik14 مهر 1399

477views

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

yubikey

در این میان کانسپت تایید دو مرحله‌ای و authenticatorها مطرح شد که به صورت نرم‌افزاری پسوردهای زمانی برای شما ایجاد می‌نمایند و شما در طی زمانی معین باید از آن پسوردها استفاده کنید در غیر این صورت پسورد جدیدی ایجاد می‌شود. اما تمام این اپلیکیشن‌ها در معرض فیشینگ‌ قرار دارند و پسوردهایی که برای شما به صورت sms نیز ارسال می‌شود می‌تواند hijack یا دزدیده شود که معروف ترین مثال آن نیز هک شدن حساب کاربری توییتر مدیرعامل توییتر جک دورسی بود که نشان از غیرقابل اعتماد بودن و بازدهی کم شیوه‌های نرم افزاری می‌باشد.

YubiKey یک دستگاه احراز هویت سخت افزاری است که دو پروتکل TOTP و HOTP را برای امنیت بیشتر باهم استفاده می‌کند و از طریق پروتکل HID USB رمز را برای شما محیا می‌کند. استفاده از دستگاه های احراز هویت سخت افزاری این اطمینان را به شما می‌دهد که حملات فیشینگ و hijack تاثیری بر امنیت شما نداشته باشد و بتوانید با خیال راحت از حساب‌های کاربری خود مراقبت کنید، YubiKey فقط مخصوص قشر خاصی نیست و همه اقشار از کاربران عادی تا شرکت‌های بزرگ که امنیت را در اولویت خود قرار داده‌اند می‌توانند از آن استفاده نمایند، حتی توسعه دهندگانی که قصد دارند پشتیبانی از احراز هویت سخت افزاری مانند YubiKey را به نرم افزار یا سرویس خود اضافه کنند می‌توانند با خرید و ثبت نام در سایت YubiKey از داکیومنتیشن و پشتیبانی فنی برای توسعه سرویس خود بهره مند گردند.

yubikey

اولین محصول YubiKey سال 2008 عرضه گردید بعد از 12 سال از عرضه این محصول یک مورد از نقص امنیتی یا هک شدن اکانتی که با YubiKey محافظت می‌‍شود گزارش نشده است.

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

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

آموزش استفاده از Nmap (بخش اول)

Saman Yazdannik1 مهر 1399

در ادامه مقاله قبلی و نحو آموزش نصب Nmap قصد داریم در این مطلب به تعدادی از کامندهای Nmap و استفاده‌های آنها بپردازیم. سینتکس Nmap بسیار ساده است و مانند: nmap [Scan Type(s)] [Options] {target specification} می‌باشد. که در اینجا target specifiction همان IP آدرس یا هسات نیمی است که می‌خواهید بر روی آن Nmap را اجرا نمایید.

اسکن یک دامنه

کامند اسکن مانند مثال زیر است:

nmap scanme.nmap.org

1	nmap scanme.nmap.org

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

$nmap scanme.nmap.org
Starting Nmap 7.80 ( https://nmap.org ) at 2020-09-18 20:14 UTC
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.025s latency).
Other addresses for scanme.nmap.org (not scanned): 2600:3c01::f03c:91ff:fe18:bb2f
Not shown: 995 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp filtered smtp
80/tcp open http
9929/tcp open nping-echo
31337/tcp open Elite

$nmap scanme.nmap.org

Starting Nmap 7.80 ( https://nmap.org ) at 2020-09-18 20:14 UTC

Nmap scan report for scanme.nmap.org (45.33.32.156)

Host is up (0.025s latency).

Other addresses for scanme.nmap.org (not scanned): 2600:3c01::f03c:91ff:fe18:bb2f

Not shown: 995 closed ports

PORT STATE SERVICE

22/tcp open ssh

25/tcp filtered smtp

80/tcp open http

9929/tcp open nping-echo

31337/tcp open Elite

Nmap done: 1 IP address (1 host up) scanned in 1.73 seconds

Nmap به صورت پیشفرض 1000 پورت را بررسی می‌نماید و درخواست‌های ICMP echo requests ارسال می‌کند تا متوجه شود که هدف مورد بررسی یک سرور فعال است یا خیر.

در نتیجه بالا می‌بینید که 995 پورت بسته داریم و 5 پورت باز و پورت‌هایی که مشخص نیستند که آیا باز هستند یا بسته به این دلیل است که یا Nmap توانایی بررسی را ندارد یا این پورت‌ها توسط فایروال محافظت می‌شوند.

اسکن IP Address

برای این منظور از دستور زیر استفاده می‌کنیم:

nmap 192.168.0.7

1	nmap 192.168.0.7

و با نتیج زیر مواجه خواهیم شد:

$nmap 192.168.0.7
Starting Nmap 7.80 ( https://nmap.org ) at 2020-09-18 20:12 UTC
Nmap scan report for server-1.geekflare.com (192.168.0.7)
Host is up (0.034s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
22/tcp open ssh
Nmap done: 1 IP address (1 host up) scanned in 0.62 seconds

$nmap 192.168.0.7

Starting Nmap 7.80 ( https://nmap.org ) at 2020-09-18 20:12 UTC

Nmap scan report for server-1.geekflare.com (192.168.0.7)

Host is up (0.034s latency).

Not shown: 999 closed ports

PORT STATE SERVICE

22/tcp open ssh

Nmap done: 1 IP address (1 host up) scanned in 0.62 seconds

اسکن subnet

برای این منظور از کامند زیر استفاده می‌کنیم:

nmap 192.168.0.0/24

1	nmap 192.168.0.0/24

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

$nmap 192.168.0.0/24
Starting Nmap 7.80 ( https://nmap.org ) at 2020-09-18 20:15 UTC
Nmap scan report for server-1.geekflare.com (192.168.0.7)
Host is up (0.044s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
22/tcp open ssh
Nmap scan report for server-2.geekflare.com (192.168.0.8)
Host is up (0.046s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
22/tcp open ssh
Nmap scan report for server-3.geekflare.com (192.168.0.9)
Host is up (0.043s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
22/tcp open ssh
Nmap scan report for server-4.geekflare.com (192.168.0.10)
Host is up (0.044s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
22/tcp open ssh
Nmap done: 256 IP addresses (4 hosts up) scanned in 4.67 seconds

$nmap 192.168.0.0/24

Starting Nmap 7.80 ( https://nmap.org ) at 2020-09-18 20:15 UTC

Nmap scan report for server-1.geekflare.com (192.168.0.7)

Host is up (0.044s latency).

Not shown: 999 closed ports

PORT STATE SERVICE

22/tcp open ssh

Nmap scan report for server-2.geekflare.com (192.168.0.8)

Host is up (0.046s latency).

Not shown: 999 closed ports

PORT STATE SERVICE

22/tcp open ssh

Nmap scan report for server-3.geekflare.com (192.168.0.9)

Host is up (0.043s latency).

Not shown: 999 closed ports

PORT STATE SERVICE

22/tcp open ssh

Nmap scan report for server-4.geekflare.com (192.168.0.10)

Host is up (0.044s latency).

Not shown: 999 closed ports

PORT STATE SERVICE

22/tcp open ssh

Nmap done: 256 IP addresses (4 hosts up) scanned in 4.67 seconds

هدایت کاربر از صفحه 403 به 404

Saman Yazdannik26 شهریور 1399

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

روش‌های اجرای تکنیک در Nginx، Apache و وردپرس

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

هدایت کاربر از صفحه 403 به 404

Apache HTTP | هدایت کاربر از صفحه 403 به 404

در اولین قدم لاز است تا فایلی با نام پیشنهادی 404 در پوشه DocumentRoot بسازید.

حال در فایل httpd.conf خط زیر را اضافه نمایید.

<span class="s1">ErrorDocument</span><span class="s2"> 403 /404</span>

1	<span class="s1">ErrorDocument</span><span class="s2"> 403 /404</span>

کاری که در این خط انجام داده‌ایم این است که ارور 403 را به صفحه 404 بازگشت داده‌ایم.

حال فایل را ذخیره نمایید و Apache را دوباره راه اندازی نمایید.

هدایت کاربر از صفحه 403 به 404

Nginx

در قدم اول فایلی با نام 404.html بسازید. سپس در فایل پیکربندی Nginx و در زیر بخش server خط زیر را اضافه نمایید.

<span class="s1">error_page 404 /404.html;</span>
<span class="s1">error_page 403 =404 /404.html;</span>

1 2	<span class="s1">error_page 404 /404.html;</span> <span class="s1">error_page 403 =404 /404.html;</span>

در این دستورات زمانی که Nginx صفحه مورد نظر را پیدا نکند، کاربر را به 404 سوق خواهد داد و زمانی نیز که کاربر با صفحه 403 روبرو شود کاربر را به صفحه 404 سوق خواهد داد.

WordPress

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

کلام آخر…

در این مقاله در مورد هدایت کاربر از صفحه 403 به 404، صحبت کردیم. اگر هرگونه سوال و مشکل در این راه برای شما بوجود آمد، کارشناسان ما به صورت حرفه‌ای و ۲۴ ساعته به شما خدمات خواهند داد.