هاردنینگ تجهیزات شبکه اگر فقط به چند دستور پراکنده محدود شود، در عمل دوام نمیآورد. امروز یک روتر یا فایروال تنظیم میشود، چند ماه بعد یک تغییر فوری روی آن مینشیند، بعد یک دسترسی موقت اضافه میشود و کمکم همان تجهیزی که قرار بود نقطه کنترل باشد، خودش به نقطه ریسک تبدیل میشود. Baseline هاردنینگ یعنی قبل از بحث ابزار و محصول، حداقلهای روشن و قابل بررسی برای هر تجهیز داشته باشیم.
من Baseline را سند تزئینی نمیبینم. باید چیزی باشد که تیم عملیات بتواند با آن کار کند: چه دسترسیهایی مجاز است، لاگها کجا میروند، backup چطور گرفته میشود، چه چیزی باید تغییر کند، چه چیزی نباید بدون change window دست بخورد، و اگر فردا دستگاه عوض شد، چطور همان سطح امنیت دوباره ساخته شود. این نگاه برای FortiGate، Juniper، Cisco، F5 و حتی سوئیچهای ساده یک اصل مشترک است؛ فقط دستورها و جزئیات فرق میکند.
دسترسی مدیریتی نقطه شروع است
اولین بخش هر Baseline باید دسترسی مدیریتی باشد. دسترسی به پنل یا CLI نباید از هر subnet و هر کاربری ممکن باشد. بهتر است شبکه مدیریت جدا باشد، دسترسی از اینترنت مستقیم بسته باشد، SSH جایگزین Telnet شود، حسابهای مشترک حذف شوند و اگر زیرساخت آماده است، AAA با RADIUS یا TACACS پیاده شود. حتی اگر فعلاً AAA کامل ندارید، حداقل باید حسابها، سطح دسترسی و مسیر ورود مشخص باشد.
در پروژههای واقعی، مشکل همیشه از یک آسیبپذیری پیچیده شروع نمیشود. گاهی یک حساب قدیمی، یک SNMP community ساده، یا یک management interface باز کافی است. برای همین Baseline باید بتواند موارد کوچک را هم جدی بگیرد. اگر فهرست فقط شامل تنظیمات پیشرفته باشد، همان ضعفهای ساده باقی میمانند.
لاگ و زمان درست، بدون سر و صدا
لاگگیری هم باید بخشی از Baseline باشد، نه کاری که بعد از حادثه یادمان بیفتد. هر تجهیز باید NTP درست داشته باشد تا زمان لاگها قابل مقایسه باشد. رویدادهای ورود مدیر، تغییر configuration، up/down شدن interface، تغییر policy، خطاهای VPN و eventهای امنیتی باید به مقصد مشخص بروند. اما لاگ زیاد و بیکیفیت هم مفید نیست؛ اگر همه چیز با severity اشتباه ارسال شود، تیم بعد از مدتی دیگر به لاگ نگاه نمیکند.
- ورود و خروج مدیران باید ثبت شود.
- تغییر config باید زمان، کاربر و توضیح داشته باشد.
- خطاهای VPN، HA، routing و policy باید قابل فیلتر باشند.
- NTP باید از منبع قابل اعتماد و ترجیحاً داخلی باشد.
- مقصد log نباید فقط حافظه خود دستگاه باشد.
Backup فقط وقتی ارزش دارد که برگشتپذیر باشد
داشتن فایل backup کافی نیست. باید بدانیم backup از چه دستگاهی، با چه نسخهای، در چه تاریخی و بعد از کدام تغییر گرفته شده است. بهتر است قبل و بعد از تغییرهای مهم backup جدا داشته باشیم. روی تجهیزات Juniper، commit history و rollback کمک میکند، اما باز هم export بیرونی لازم است. روی FortiGate و Firepower هم باید configuration backup و خروجی policy قابل بررسی باشد.
بخش مهم دیگر، تست برگشت است. اگر هیچوقت backup را در محیط آزمایش یا حداقل با چشم فنی بررسی نکردهایم، در روز حادثه نباید مطمئن باشیم که قابل استفاده است. Baseline خوب میگوید backup کجا نگهداری میشود، چه کسی دسترسی دارد، چقدر نگه داشته میشود و برای برگشت چه مراحلی لازم است.
چطور این Baseline را عملی کنیم؟
بهتر است از همه چیز شروع نکنیم. اول تجهیزات حیاتی را انتخاب کنیم: فایروال مرزی، VPN، core switch، load balancer، WAF و دستگاههای مدیریت. برای هر کدام یک چک کوتاه اما واقعی تهیه شود: دسترسی، حسابها، SNMP، NTP، log، backup، نسخه نرمافزار، سرویسهای فعال، و مستندات تغییر. بعد همین Baseline در چرخه روزانه یا هفتگی بررسی شود.
این موضوع به نقشه راه هاردنینگ شبکه و طراحی و هاردنینگ امنیت شبکه وصل است. اگر مسئله شما FortiGate است، امنسازی دسترسی مدیریتی FortiGate نمونه عملیتری از همین نگاه است. هدف نهایی این نیست که چکلیست طولانی بسازیم؛ هدف این است که هیچ تجهیز مهمی بدون حداقل دفاع پایه در شبکه نماند.
چطور Baseline را زنده نگه داریم؟
Baseline اگر فقط یک بار نوشته شود و کنار بماند، بعد از چند تغییر دیگر قابل اعتماد نیست. بهتر است هر تغییر مهم روی فایروال، سوئیچ، WAF یا load balancer یک اثر مشخص روی Baseline داشته باشد: آیا دسترسی مدیریتی عوض شده؟ آیا مقصد لاگ تغییر کرده؟ آیا backup بعد از تغییر گرفته شده؟ آیا سرویس جدیدی فعال شده که باید در بازبینی دورهای بیاید؟ این پیگیری کوچک باعث میشود هاردنینگ از یک پروژه مقطعی به یک عادت عملیاتی تبدیل شود.
برای شروع هم لازم نیست همه تجهیزات یکباره کامل شوند. میتوان از پنج تجهیز حیاتی شروع کرد، خروجی فعلی را با baseline مقایسه کرد و هر هفته چند مورد کمریسک را اصلاح کرد. نکته مهم این است که تغییرها قابل برگشت و قابل توضیح باشند. اگر تیم بداند چرا یک سرویس غیرفعال شده یا چرا دسترسی مدیریتی محدود شده، احتمال برگشت دادن تنظیمات امن کمتر میشود.
برای اینکه این موضوع در اجرا هم نتیجه بدهد، بهتر است بعد از هر تغییر یک شاخص ساده برای موفقیت داشته باشیم: آیا سرویس سالم مانده، آیا لاگ کافی داریم، آیا مسیر rollback روشن است، و آیا تیم فنی میتواند سه ماه بعد دلیل این تصمیم را بفهمد؟ اگر جواب این سؤالها مثبت نباشد، حتی تغییر درست هم در نگهداری روزمره دردسر میسازد.
همین نگاه ساده جلوی کارهای نمایشی را میگیرد. معیار موفقیت باید در شبکه واقعی قابل مشاهده باشد، نه فقط در متن گزارش.
در کار اجرایی، یک نکته دیگر هم مهم است: هر پیشنهاد باید صاحب، زمان بازبینی و سطح ریسک داشته باشد. اگر پیشنهادی این سه مورد را ندارد، احتمالاً هنوز برای اجرا آماده نیست. این کار متن را از توصیه عمومی جدا میکند و به برنامهای تبدیل میکند که تیم فنی میتواند آن را مرحلهبهمرحله دنبال کند.
