تصویر شاخص تبدیل کانفیگ FortiGate به Juniper با Python؛ تجربه یک مهاجرت واقعی فایروال
در شبکه عملیاتی همیشه قرار نیست همه کارها دستی انجام شود. بعضی کارها زمان مشخص دارند: ذخیره کردن running-config، گرفتن خروجی ساده، ریبوت کنترلشده در یک maintenance window یا اجرای یک دستور تکراری روی تجهیز. در IOS سیسکو برای این نوع کارهای زمانبندیشده میتوان از Kron استفاده کرد.
Kron شبیه cron لینوکس نیست و امکاناتش محدودتر است، اما برای چند کار ساده و قابل پیشبینی روی خود روتر یا سوییچ کاربرد دارد. اگر قرار است یک دستور privilege mode در زمان مشخص یا به صورت تکراری اجرا شود، Kron میتواند کار را بدون وابستگی به سرور بیرونی انجام دهد.
نمونه رایج استفاده از Kron، ذخیره دورهای تنظیمات است. مثلاً اگر در یک محیط چند نفر روی تجهیزات کار میکنند و احتمال فراموش شدن write memory وجود دارد، میشود هر شب running-config را در startup-config ذخیره کرد. این کار جای change management درست را نمیگیرد، ولی برای بعضی شبکهها یک محافظ ساده است.
کارهای دیگری مثل اجرای دستورهای show، clear کردن برخی counterها یا انجام یک action ساده هم ممکن است با Kron انجام شود، به شرطی که دستور در محدوده مجاز Kron باشد و اثر جانبی خطرناک نداشته باشد.
اول یک policy-list تعریف میکنیم. داخل policy-list دستورهایی قرار میگیرد که Kron باید اجرا کند:
kron policy-list CopyRunToStart
cli copy running-config startup-configبعد occurrence را تعریف میکنیم تا مشخص شود این policy چه زمانی اجرا شود. مثلاً اجرای روزانه در ساعت ۲۲:
kron occurrence CopyRunToStart at 22:00 recurring
policy-list CopyRunToStartبرای بررسی زمان اجرای بعدی میشود از دستور زیر استفاده کرد:
show kron scheduleخروجی معمولاً نشان میدهد occurrence فعال است یا نه و اجرای بعدی چه زمانی انجام میشود. اگر policy قبلاً fail شده باشد، باید علت fail شدن را بررسی کنید؛ چون ترتیب و نوع دستورها در Kron مهم است.
مهمترین محدودیت Kron این است که برای همه دستورهای configuration مناسب نیست. معمولاً دستورهایی که در privilege EXEC mode اجرا میشوند گزینه بهتری هستند. اگر لازم است وارد global configuration شوید، EEM معمولاً انتخاب مناسبتری است.
نکته دوم این است که بعد از تعریف commandها، ویرایش آنها همیشه مثل یک اسکریپت آزاد نیست. اگر ترتیب دستورها اشتباه باشد یا دستور تعاملی شود، اجرای Kron fail میشود. مثلاً بعضی دستورهای copy ممکن است confirmation بخواهند و باید قبل از استفاده در production تست شوند.
اگر فقط یک کار زمانبندیشده ساده دارید، Kron کافی است. اما اگر قرار است بر اساس event، تغییر وضعیت interface، track، syslog یا شرط خاصی دستور اجرا شود، بهتر است سراغ EEM بروید. Kron زمانمحور است؛ EEM رویدادمحور و انعطافپذیرتر است.
برای شبکههای حساس، اجرای خودکار دستور باید مستند باشد. مشخص کنید چه دستوری، چرا، چه زمانی و با چه اثر احتمالی اجرا میشود. automation بدون مستندات، بعد از چند ماه خودش تبدیل به ریسک عملیاتی میشود.
مسیر عملی راهاندازی FortiWeb از monitor تا block؛ بررسی لاگ، کاهش false positive، ساخت exception…
راهنمای عملی طراحی Health Monitor در F5 BIG-IP؛ تفاوت TCP و HTTP Monitor، خطاهای رایج،…
راهنمای عملی عیبیابی Deploy نشدن Policy در Cisco FMC و FTD با بررسی health، connectivity،…
راهنمای عملی کاهش False Positive در FortiWeb WAF با بررسی لاگ، rule، parameter، exception محدود…
راهنمای عملی Persistence در F5 BIG-IP؛ تفاوت Source Address و Cookie Persistence، زمان استفاده، خطاهای…
چکلیست عملی امنسازی دسترسی مدیریتی FortiGate؛ محدودسازی WAN، trusted hosts، MFA، حسابهای جداگانه، لاگ ورود…