اگر قرار است Cisco Firepower Threat Defense را در یک شبکه سازمانی راهاندازی کنید، باید بدانید با یک فایروال ساده طرف نیستید. FTD ترکیبی از قابلیتهای Stateful Firewall، IPS، URL Filtering، Malware Protection و کنترل اپلیکیشن است که در قالب یک سیستم یکپارچه ارائه میشود. همین یکپارچگی باعث میشود فرآیند نصب و راهاندازی اولیه آن نسبت به ASA کلاسیک پیچیدهتر اما در عوض بسیار ساختاریافتهتر باشد.
در این مقاله، نصب و راهاندازی اولیه Cisco FTD را از مرحله روشن کردن دستگاه تا ایجاد اولین Access Control Policy به صورت عملی و پروژهمحور بررسی میکنیم. تمرکز ما روی سناریویی است که FTD توسط Firepower Management Center مدیریت میشود، چون در محیطهای سازمانی این روش رایجتر و حرفهایتر است.
آشنایی سریع با معماری FTD
برای اینکه نصب و راهاندازی FTD را درست انجام دهید، باید معماری آن را دقیق درک کنید. FTD فقط یک فایروال لایه 3 و 4 نیست، بلکه یک پلتفرم امنیتی چندلایه است که چند موتور مختلف را در یک سیستمعامل یکپارچه ترکیب کرده است. درک این لایهها باعث میشود هنگام طراحی Policy یا عیبیابی، بدانید هر تصمیم در کدام بخش گرفته میشود.
در قلب FTD، موتور تحلیل ترافیک Snort قرار دارد. این موتور مسئول بازرسی عمیق بستهها یا Deep Packet Inspection است و قابلیتهایی مانند Intrusion Prevention System، شناسایی الگوهای حمله، و تحلیل رفتار ترافیک را ارائه میدهد. اما Snort به تنهایی تصمیم نهایی برای عبور یا مسدودسازی ترافیک نمیگیرد. تصمیم نهایی در لایه Access Control گرفته میشود که ترکیبی از Zone، Network Object، Application، User Identity و Intrusion Policy را بررسی میکند.
از نظر منطقی، معماری FTD را میتوان به دو بخش اصلی تقسیم کرد: Control Plane و Data Plane. Data Plane جایی است که ترافیک واقعی کاربران عبور میکند و شامل اینترفیسهای فیزیکی، Zoneها، NAT Engine و موتور Snort است. Control Plane شامل مدیریت، مانیتورینگ، Policy Definition و Deploy میشود که معمولاً از طریق Firepower Management Center انجام میگیرد. این تفکیک اهمیت زیادی دارد چون ممکن است Policy در FMC تغییر کند اما تا زمانی که Deploy انجام نشود، در Data Plane اعمال نمیشود.
در FTD، اینترفیسها در Zoneها گروهبندی میشوند. برخلاف ASA کلاسیک که اغلب بر اساس نام اینترفیس قانون مینویسید، در FTD تمرکز روی Zone است. این طراحی باعث میشود اگر در آینده اینترفیس جدیدی اضافه شود، فقط آن را به Zone موجود متصل کنید و نیازی به بازنویسی کامل Policy نداشته باشید. این موضوع در محیطهایی با چندین لینک WAN یا چندین VLAN داخلی اهمیت زیادی دارد.
یکی دیگر از اجزای مهم معماری FTD، لایه Identity است. FTD میتواند با Active Directory یکپارچه شود و ترافیک را نه فقط بر اساس IP بلکه بر اساس کاربر یا گروه کاربری تحلیل کند. این یعنی Access Control میتواند ترکیبی از شبکه، کاربر و اپلیکیشن باشد. چنین قابلیتی در طراحیهای Zero Trust یا شبکههای سازمانی بزرگ بسیار ارزشمند است.
در سطح پردازش ترافیک، ترتیب منطقی به این شکل است که ابتدا NAT اعمال میشود، سپس Access Control Rule تطبیق داده میشود، و در صورت فعال بودن، Intrusion Policy و سایر بازرسیها اجرا میشوند. اگر ترافیک از همه این مراحل عبور کند، اجازه خروج داده میشود و یک Connection در جدول Session ایجاد میشود. این رفتار stateful مشابه ASA است، اما با این تفاوت که لایههای تحلیل بیشتری در مسیر قرار دارند.
از نظر استقرار، FTD میتواند روی سختافزار فیزیکی سری 1000، 2100، 4100 و 9300 اجرا شود یا به صورت مجازی روی پلتفرمهایی مانند VMware پیادهسازی شود. در هر دو حالت، منطق معماری یکسان است اما ظرفیت پردازشی و تعداد Sessionهای همزمان به مدل سختافزاری وابسته است. بنابراین هنگام طراحی اولیه باید بدانید چه میزان ترافیک، چه تعداد کاربر و چه Featureهایی فعال خواهند بود تا دستگاه دچار Bottleneck نشود.
سناریوی راهاندازی اولیه
برای اینکه فرآیند نصب و راهاندازی اولیه FTD صرفاً یک لیست از دستورات نباشد، بهتر است آن را در قالب یک سناریوی واقعی ببینیم. فرض کنید یک سازمان متوسط با حدود 150 کاربر دارید که تاکنون از یک روتر ساده برای اتصال به اینترنت استفاده میکرده و حالا تصمیم گرفته یک فایروال نسل جدید در مرز شبکه مستقر کند. هدف این است که اینترنت کاربران از طریق FTD عبور کند، لاگگیری متمرکز انجام شود، و در آینده قابلیتهایی مانند IPS و کنترل اپلیکیشن نیز فعال شوند.
در این سناریو، یک دستگاه FTD فیزیکی در لبه شبکه قرار میگیرد. پشت آن یک سوئیچ Core وجود دارد که VLAN کاربران روی آن تعریف شده است. یک لینک اینترنت از ISP دریافت شده که شامل یک IP عمومی برای اینترفیس خارج و یک رنج کوچک برای NAT یا Publish سرویسها است. همچنین در شبکه داخلی یک سرور برای Firepower Management Center وجود دارد که در VLAN مدیریت قرار گرفته است.
اولین تصمیم مهم در این سناریو طراحی منطقی Zoneهاست. حداقل به سه Zone نیاز داریم. یکی برای inside که کاربران در آن قرار دارند، یکی برای outside که به ISP متصل است، و یکی برای management که ارتباط با FMC از طریق آن انجام میشود. اگر از ابتدا Zoneها به درستی طراحی نشوند، در آینده هنگام افزودن DMZ یا لینک دوم اینترنت مجبور به بازنویسی بخش زیادی از Policy خواهید شد.
مرحله بعدی تعیین محل قرارگیری فیزیکی FTD است. در بسیاری از پروژهها FTD به صورت Inline بین Core و روتر ISP قرار میگیرد. یعنی ترافیک کاربران قبل از رسیدن به روتر، از FTD عبور میکند. در برخی سناریوها نیز FTD جایگزین مستقیم روتر مرزی میشود و خودش وظیفه Routing را انجام میدهد. انتخاب بین این دو روش به طراحی شبکه و قابلیتهای مورد نیاز بستگی دارد. اگر قرار است FTD نقش Default Gateway کاربران را داشته باشد، باید Routing داخلی نیز روی آن تنظیم شود.
در راهاندازی اولیه، هدف این نیست که تمام قابلیتهای امنیتی فعال شود. بلکه باید یک مسیر پایدار برای عبور ترافیک ایجاد کنیم. بنابراین در سناریو ابتدا اینترفیس outside با IP عمومی تنظیم میشود و Default Route به سمت ISP تعریف میشود. سپس اینترفیس inside با IP داخلی که Gateway کاربران خواهد بود پیکربندی میشود. بعد از آن NAT پایه تعریف میشود تا کاربران بتوانند با Dynamic PAT به اینترنت دسترسی داشته باشند.
در این مرحله هنوز هیچ Policy پیچیدهای تعریف نشده است. یک Access Control Rule ساده ایجاد میکنیم که ترافیک از Zone inside به Zone outside را Allow کند. اما حتی در همین قانون ساده نیز بهتر است Logging فعال باشد تا بتوانیم رفتار ترافیک را ببینیم. بعد از Deploy، از یک کلاینت داخلی تست میگیریم و اطمینان حاصل میکنیم که DNS و HTTP و HTTPS به درستی کار میکنند.
در یک پروژه واقعی، این تست اولیه بسیار حیاتی است. اگر بدون تست مرحلهای، تمام کاربران را به FTD منتقل کنید و بعد متوجه شوید NAT یا Route اشتباه است، کل سازمان با قطعی اینترنت مواجه خواهد شد. بهترین روش این است که ابتدا یک VLAN آزمایشی یا چند کاربر محدود را از طریق FTD عبور دهید و رفتار سیستم را مانیتور کنید.
مرحله اول: اتصال فیزیکی و دسترسی به کنسول
پس از نصب دستگاه در رک و اتصال برق، کابل کنسول را به لپتاپ متصل میکنیم و با نرمافزارهایی مانند PuTTY یا SecureCRT به دستگاه وصل میشویم. تنظیمات معمول سریال 9600 8N1 است مگر اینکه مدل خاصی متفاوت باشد.
در اولین بوت، سیستم از شما اطلاعات اولیه مانند IP مدیریت، subnet mask، gateway و DNS را میپرسد. این IP باید در شبکهای باشد که FMC نیز به آن دسترسی دارد. برای مثال:
Management IP: 10.10.10.20
Netmask: 255.255.255.0
Gateway: 10.10.10.1
DNS: 8.8.8.8
پس از تکمیل این مرحله، میتوانید از طریق HTTPS به آدرس مدیریت متصل شوید یا ادامه تنظیمات را از CLI انجام دهید.
مرحله دوم: ثبت FTD در Firepower Management Center
برای اینکه FMC بتواند FTD را مدیریت کند، باید دستگاه را Register کنیم. ابتدا در FMC وارد بخش Devices شوید و گزینه Add Device را انتخاب کنید. در اینجا IP مدیریت FTD و یک Registration Key دلخواه وارد میکنید.
سپس در CLI دستگاه FTD دستور زیر را اجرا میکنید:
در این دستور، 10.10.10.10 آدرس FMC و REGKEY123 همان کلیدی است که در FMC تعریف کردهاید. اگر ارتباط شبکه درست باشد، دستگاه پس از چند دقیقه در FMC به وضعیت Registered تغییر میکند.
یکی از خطاهای رایج در این مرحله، مشکل DNS یا NTP است. اگر زمان دستگاه و FMC همگام نباشد، گاهی فرآیند ثبت با خطا مواجه میشود. همیشه NTP را در هر دو سمت بررسی کنید.
مرحله سوم: تنظیم اینترفیسهای دیتاپلین
پس از ثبت موفق، از طریق FMC وارد بخش Device Management میشویم و اینترفیسهای FTD را تنظیم میکنیم. معمولاً اینترفیسها به صورت پیشفرض Shutdown هستند و باید Enable شوند.
برای مثال اینترفیس GigabitEthernet1/1 را به عنوان outside و GigabitEthernet1/2 را به عنوان inside تنظیم میکنیم. روی outside IP عمومی از ISP و روی inside IP داخلی مانند 192.168.1.1 قرار میدهیم. سپس هر اینترفیس را در یک Zone قرار میدهیم. تعریف Zone اهمیت زیادی دارد چون در Access Control Policy بر اساس Zoneها قانون مینویسیم نه صرفاً اینترفیسها.
پس از اعمال تغییرات، باید Deploy انجام شود تا تنظیمات روی دستگاه اعمال گردد.
مرحله چهارم: تعریف NAT Policy پایه
بدون NAT، کاربران داخلی نمیتوانند به اینترنت دسترسی داشته باشند. در FMC به بخش NAT Policies میرویم و یک Policy جدید ایجاد میکنیم. سپس یک قانون Dynamic PAT تعریف میکنیم که ترافیک از inside به outside با IP اینترفیس outside ترجمه شود.
Source Zone را inside و Destination Zone را outside قرار میدهیم. Source Network را شبکه داخلی و ترجمه را Dynamic PAT روی Interface Address تنظیم میکنیم. بعد از ذخیره، Deploy را انجام میدهیم.
در پروژههای واقعی اگر NAT درست تنظیم نشود، حتی اگر Access Policy صحیح باشد، کاربران اینترنت نخواهند داشت. همیشه بعد از Deploy NAT، با تست عملی یا ابزارهای مانیتورینگ صحت آن را بررسی کنید.
مرحله پنجم: ایجاد Access Control Policy اولیه
اکنون باید یک Access Control Policy تعریف کنیم. وارد بخش Policies شده و Access Control را انتخاب میکنیم. یک Policy جدید ایجاد میکنیم و آن را به دستگاه FTD اعمال میکنیم.
در داخل Policy یک قانون جدید اضافه میکنیم که ترافیک از Zone داخل به Zone خارج را Allow کند. در این مرحله میتوانیم صرفاً برای شروع همه ترافیک را Allow کنیم، اما در محیط حرفهای بهتر است فقط سرویسهای مشخص مانند HTTP، HTTPS و DNS مجاز شوند.
همچنین میتوانیم در همین قانون، Intrusion Policy را فعال کنیم تا ترافیک از نظر تهدیدات بررسی شود. این یکی از تفاوتهای کلیدی FTD با ASA کلاسیک است که لایه امنیتی عمیقتری ارائه میدهد.
در انتهای لیست قوانین، Default Action معمولاً Block است. این یعنی هر ترافیکی که با قوانین بالا match نشود، مسدود میشود.
پس از ذخیره Policy، Deploy را انجام میدهیم.
مرحله ششم: تست و عیبیابی اولیه
بعد از Deploy، باید از یک کلاینت داخلی تست بگیریم. اگر اینترنت برقرار نبود، چند نکته را بررسی کنید. ابتدا NAT Policy را چک کنید. سپس Access Control Policy و ترتیب قوانین را بررسی کنید. در FMC بخش Analysis و سپس Connections میتواند نشان دهد ترافیک مجاز بوده یا Block شده است.
همچنین بخش Intrusion Events نشان میدهد آیا ترافیک به دلیل IPS مسدود شده است یا خیر. در بسیاری از موارد، مشکل از ترتیب قوانین یا عدم تطابق Zoneها ناشی میشود.
نکات عملی در پروژههای واقعی
در محیط عملیاتی، توصیه میشود از همان ابتدا NTP و DNS را به درستی تنظیم کنید. بدون زمان دقیق، لاگها قابل اعتماد نخواهند بود. همچنین بهتر است قبل از انتقال کامل ترافیک سازمان به FTD، یک دوره تست با بخشی از کاربران انجام دهید.
فعالسازی بیش از حد Featureها بدون بررسی ظرفیت سختافزار نیز میتواند باعث افزایش latency شود. همیشه Load و CPU دستگاه را بعد از Deploy Policyهای سنگین بررسی کنید.
جمعبندی
راهاندازی اولیه Cisco Firepower Threat Defense فقط روشن کردن دستگاه و نوشتن یک قانون Allow نیست. این فرآیند شامل ثبت صحیح در FMC، طراحی Zoneها، تعریف NAT، ساخت Access Control Policy و در نهایت Deploy و تست دقیق است. اگر این مراحل با درک معماری FTD انجام شود، پایهای پایدار برای پیادهسازی قابلیتهای پیشرفتهتر مانند IPS، URL Filtering و کنترل اپلیکیشن ایجاد خواهد شد.
در پروژههای سازمانی، کیفیت راهاندازی اولیه تعیین میکند که در آینده با یک زیرساخت پایدار و قابل توسعه روبهرو هستید یا با سیستمی که هر تغییر کوچک در آن باعث اختلال میشود. بنابراین نصب اولیه را صرفاً یک کار ابتدایی نبینید، بلکه آن را به عنوان مرحله طراحی بنیادین در نظر بگیرید.
