امنیت سرور به تنظیمات سیستمعامل، سرویسها و کنترلپنل بستگی دارد و روی بسیاری از سرورها این تنظیمات هنوز همان حالت پیشفرض است. در خدمت امنسازی سرور، کانفیگ سرور این تنظیمات را مرحلهبهمرحله میبندد، برای هر تغییر راه بازگشت آماده میکند و گزارش مکتوب تحویل میدهد تا بدانید چه چیزی روی سرور باز مانده و چرا.
این تلاشها از حملات brute-force خودکار میآیند و در این وضعیت فقط قدرت رمز عبور جلوی نفوذ را گرفته است. ورود با رمز را غیرفعال میکنیم، ورود مستقیم root را میبندیم و مسدودسازی خودکار IPهای مهاجم را راه میاندازیم.
ایمیجهای آماده معمولاً پورتهای باز، سرویسهای بیاستفاده و کاربر root با رمز دارند. هاردنینگ سرور پیش از انتقال سایت و دادههای واقعی سادهتر است، چون تغییرات را میتوان بدون نگرانی از قطع سرویس انجام داد.
پاکسازی بدافزار نیمی از کار است. اگر مسیر نفوذ، مثلاً یک افزونه قدیمی یا دسترسی نوشتن اشتباه روی پوشهها، باز بماند، آلودگی برمیگردد و امنسازی برای بستن همین مسیرهاست.
دسترسیها را محدود میکنیم، پورتهای بیاستفاده را میبندیم، کرنل و سرویسها را سختسازی میکنیم، برای بهروزرسانی سیاست میگذاریم و وبسرور، دیتابیس و کنترلپنل را ایمن میکنیم. جزئیات هر بخش به سیستمعامل و نقش سرور شما بستگی دارد.
ورود به سرور فقط با کلید انجام میشود و هر کاربر همان دسترسیای را میگیرد که برای کارش لازم است.
فقط پورتهایی باز میمانند که سرویسی واقعی پشت آنها کار میکند.
سرویسها و بستههایی که استفاده نمیشوند حذف میشوند و تنظیمات کرنل و مجوزها برای بقیه سختتر میشود.
آسیبپذیریهای شناختهشده رایجترین راه نفوذند، پس نصب وصله باید برنامه زمانی مشخص داشته باشد.
این لایه درخواستهای کاربران اینترنت را مستقیم دریافت میکند و تنظیمات پیشفرضش باید بازبینی شود.
سرورهای دارای کنترلپنل و ویندوز سرور هم چکلیست هاردنینگ خودشان را دارند.
امنیت سرور از چند تصمیم مشخص ساخته میشود: چه کسی و از کجا وارد سرور میشود، کدام پورت باز میماند، وصلهها چه زمانی نصب میشوند و اگر تغییری سرویس را از کار انداخت، چطور به حالت قبل برمیگردید. هاردنینگ همین تصمیمها را روی خود سرور اعمال میکند. هر سروری که از اینترنت در دسترس است به آن نیاز دارد، چه سرور مجازی با یک سایت وردپرسی باشد، چه سرور دیتابیس یا ویندوز سروری که RDP آن باز است.
کار با فهرست کردن وضعیت فعلی شروع میشود. دستور ss روی خود سرور نشان میدهد کدام پورتها باز هستند و چه برنامهای پشت هر کدام گوش میدهد، و nmap از بیرون نشان میدهد کدامیک واقعاً از اینترنت در دسترس است. فهرست کاربران، کلیدهای داخل authorized_keys، سرویسهای فعال و نسخه بستهها را هم کنار آن بگذارید. بدون این فهرست، بستن پورت یا حذف سرویس بر اساس حدس انجام میشود. ترتیبی که بعد از بررسی دنبال میکنیم این است:
تغییرات دسترسی و فایروال بیشترین خطر قفل شدن پشت در را دارند، به همین دلیل اول و با یک راه دسترسی جایگزین انجام میشوند. کارهای بعدی روی سروری انجام میشود که دیگر برای رباتهای brute-force باز نیست. سختسازی وبسرور و دیتابیس آخر میآید، چون بیشتر از بقیه روی سایت اثر میگذارد و بعد از هر تغییر باید سایت، ایمیل و کنترلپنل آزمایش شوند.
یک خطای رایج، بستن ورود با رمز پیش از آزمایش ورود با کلید است. تا وقتی نشست فعلی SSH باز است همهچیز درست به نظر میرسد و مشکل وقتی معلوم میشود که نشست بسته شده و راهی به سرور نمانده است. همین اتفاق برای فایروالی میافتد که سیاست drop آن پیش از باز کردن پورت SSH فعال شده باشد. کنسول VNC یا KVM پنل دیتاسنتر را پیش از این تغییرات امتحان کنید و بعد از هر ویرایش sshd_config، فایل را با sshd -t بررسی کنید.
پیش از تغییر تنظیمات SSH یا فایروال، نشست فعلی را باز نگه دارید و ورود را در یک نشست تازه آزمایش کنید. تا این آزمایش موفق نشده، نشست قبلی را نبندید.
تغییر پورت SSH تعداد تلاشهای ثبتشده در لاگ را کم میکند، ولی رباتها پورتهای دیگر را هم اسکن میکنند و تا ورود با رمز باز است، خطر سر جایش میماند. سرویسهای داخلی هم گاهی از قلم میافتند: MySQL با bind-address روی همه اینترفیسها یا Redis بدون رمز که از اینترنت در دسترس است، حتی کنار SSH امن راه نفوذ باز میگذارد. خطای دیگر، خاموش کردن کامل SELinux یا AppArmor بهخاطر یک خطای مجوز است. درستتر این است که context فایل یا قاعده مربوط اصلاح شود و محافظت برای بقیه سیستم فعال بماند.
روی سرورهای cPanel و DirectAdmin بخش بزرگی از هاردنینگ از داخل خود پنل انجام میشود، چون پنل بعضی فایلهای پیکربندی را خودش مدیریت میکند و تغییر دستی ممکن است با بهروزرسانی بعدی بازنویسی شود. در WHM، cPHulk جلوی تلاشهای مکرر ورود را میگیرد و CSF همراه LFD فایروال و مسدودسازی IP را یکجا مدیریت میکند؛ در DirectAdmin، Brute Force Monitor همین کار را انجام میدهد. حسابهای میزبانی را هم ایزوله میکنیم تا سایت آلوده در یک حساب به فایلهای حسابهای دیگر دسترسی نداشته باشد. جزئیات این تنظیمات را در راهنماهای افزایش امنیت سی پنل و افزایش امنیت دایرکت ادمین نوشتهایم.
در ویندوز سرور، RDP همان نقشی را دارد که SSH در لینوکس دارد و هدف همان حملات خودکار است. NLA را فعال کنید، دسترسی به پورت 3389 را در Windows Firewall به IPهای مشخص محدود کنید و برای ورودهای ناموفق پیاپی سیاست قفل حساب بگذارید. ممیزی رویدادهای ورود را هم روشن کنید تا تلاشهای ناموفق در Event Viewer ثبت شوند و دیده شوند.
هاردنینگ وضعیت سرور را در روز تحویل درست میکند، اما سرور بعد از آن ثابت نمیماند. آسیبپذیری تازه منتشر میشود، برنامهنویسی پورتی را برای آزمایش باز میکند و کاربر جدیدی با sudo اضافه میشود. unattended-upgrades در Ubuntu و Debian و dnf-automatic در AlmaLinux و Rocky وصلههای امنیتی را خودکار نصب میکنند، ولی کرنل جدید معمولاً تا ریبوت اثر نمیکند و ریبوت باید پنجره زمانی مشخص داشته باشد. نسخههای پایانعمر مثل CentOS 7 دیگر وصله نمیگیرند و برای آنها برنامه ارتقا لازم است.
در بازبینی دورهای، پورتهای باز را با فهرست روز تحویل مقایسه کنید، کاربران و کلیدهای SSH را مرور کنید و گزارشهای fail2ban و auditd را بخوانید. اگر تیم داخلی برای این کار وقت ندارد، نگهداری و پایش مستمر را میتوانید به خدمت پشتیبانی و مدیریت سرور بسپارید. سروری که پیش از هاردنینگ هک شده، اول به رفع هک و پاکسازی مالور نیاز دارد، چون هاردنینگ درِ پشتیای را که مهاجم گذاشته حذف نمیکند.
تعداد سرورها و نقش هر کدام، وجود کنترلپنل، تعداد سایتها و سرویسها و حساسیت سرویس به قطعی، زمان کار را تعیین میکنند. سروری که تازه تحویل گرفته شده و هنوز داده واقعی ندارد سریعتر امن میشود، چون تغییرات را میتوان بدون پنجره زمانی اعمال کرد. روی سرور عملیاتی با چند سایت، هر مرحله در زمان هماهنگشده اجرا میشود و بعد از آن سرویسها آزمایش میشوند. سیستمعامل پایانعمر هم کار را به برنامه ارتقا گره میزند. قیمت پس از ارزیابی اولیه و مشخص شدن همین موارد اعلام میشود.
پورتهای باز را با ss و nmap بررسی میکنیم و کاربران و کلیدها، نسخه بستهها، سرویسهای فعال و لاگهای ورود را مرور میکنیم. فهرست ریسکها را به ترتیب اولویت در اختیار شما میگذاریم.
برای هر تغییر مشخص میکنیم روی کدام سرویس اثر دارد، چه زمانی اجرا شود و چطور برگردانده شود. تغییرات حساس مثل SSH و فایروال را با یک راه دسترسی جایگزین، مثل کنسول VNC یا KVM دیتاسنتر، انجام میدهیم تا دسترسی شما قطع نشود.
تنظیمات را گامبهگام اعمال میکنیم و بعد از هر گام سایت، ایمیل، کنترلپنل و دیتابیس را تست میکنیم. از فایلهای پیکربندی اصلی نسخه پشتیبان نگه میداریم تا هر تغییر قابل برگشت باشد.
گزارشی شامل تغییرات انجامشده، پورتها و کاربران مجاز، محل فایلهای پیکربندی و کارهای دورهای که باید ادامه پیدا کنند تحویل میگیرید، همراه با مقایسه وضعیت قبل و بعد.
کانفیگ سرور (ConfigServer.cloud) روی همان ترکیبهایی کار میکند که در سرورهای ایرانی رایج است: لینوکس با کنترلپنل، وبسرورهای مختلف و ویندوز سرور. در گزارش ما برای هر تغییر نوشته میشود که چه چیزی عوض شد و به چه دلیل.
Ubuntu، Debian، AlmaLinux، Rocky، Windows Server، cPanel، DirectAdmin، Nginx، Apache، LiteSpeed و MySQL/MariaDB.
پیش از هر تغییر از پیکربندی پشتیبان میگیریم و راه برگرداندن آن را مشخص میکنیم تا اگر تغییری سرویسی را مختل کرد، بتوان آن را برگرداند.
پیش از همکاری، راهنماهای ما مثل افزایش امنیت سی پنل و افزایش امنیت دایرکت ادمین را بخوانید و سطح فنی تیم را بسنجید.
وضعیت سرور را در تلگرام شرح دهید تا پیش از هر تعهدی، اولویتهای امنسازی را با شما مرور کنیم.
هاردنینگ یعنی کوچککردن سطح حمله با بستن دسترسیها، پورتها و تنظیمات ناامن، پیش از آنکه مهاجم از آنها استفاده کند. آنتیویروس فایلهای مخرب شناختهشده را پس از رسیدن به سرور پیدا میکند. این دو جایگزین هم نیستند، ولی روی سروری که هاردنینگ نشده، آنتیویروس معمولاً دیر خبر میدهد. برای استقرار آنتیویروس با مدیریت مرکزی، آنتی ویروس سازمانی را ببینید.
اگر بیبرنامه انجام شود ممکن است. به همین دلیل تغییرات را مرحلهای، در زمان هماهنگشده و با پشتیبان پیکربندی اجرا میکنیم و بعد از هر گام سرویسها را تست میکنیم. در بیشتر موارد فقط ریاستارت چند سرویس لازم است و اگر کرنل بهروز شود، یک ریبوت برنامهریزیشده.
خیر. اگر روی سرور هنوز درِ پشتی یا بدافزار باشد، هاردنینگ آن را پاک نمیکند و مهاجم دسترسیاش را حفظ میکند. اول باید سرور پاکسازی و مسیر نفوذ پیدا شود؛ این کار در رفع هک و مالور انجام میشود و امنسازی مرحله بعد از آن است.
چکلیست ما بر پایه مستندات رسمی توزیعها و نرمافزارها و توصیههای رایج امنیتی است، اما گواهی انطباق رسمی صادر نمیکنیم. اگر سازمان شما الزام ممیزی مشخصی دارد، آن را پیش از شروع اعلام کنید تا موارد و گزارش بر همان اساس تنظیم شوند.
امنسازی اولیه یک بار انجام میشود، اما بازبینی آن باید تکرار شود. بعد از تحویل، آسیبپذیری تازه منتشر میشود، کاربر جدید اضافه میشود و نرمافزار جدید روی سرور نصب میشود. پیشنهاد میکنیم وصلهها طبق سیاست تعریفشده اعمال شوند و تنظیمات بهصورت دورهای بازبینی شوند.
نوع و نسخه سیستمعامل، کنترلپنل اگر دارید، سرویسهایی که روی سرور اجرا میشوند و یک راه دسترسی جایگزین مثل کنسول پنل دیتاسنتر کافی است. رمز عبور را در پیام اولیه نفرستید؛ روش امن انتقال دسترسی پس از مشاوره هماهنگ میشود.
سیستمعامل، کنترلپنل و نگرانی اصلی خود را در تلگرام بنویسید. کارشناس کانفیگ سرور ارزیابی اولیه رایگان انجام میدهد و اولین اقدامهای امنسازی را پیشنهاد میکند.
