وقتی یک Cisco ASA را وارد شبکه سازمانی میکنید، اولین لایهای که باید با دقت و نگاه مهندسی طراحی شود، Access Policy است. خیلی از مشکلات عملیاتی، اختلالهای مقطعی سرویسها و حتی رخنههای امنیتی، ریشه در سیاست دسترسیای دارند که یا بیش از حد باز نوشته شده یا بدون درک دقیق رفتار ASA پیادهسازی شده است. در این مقاله قرار نیست صرفاً چند دستور ACL بنویسیم. هدف این است که دقیق بفهمیم ASA چطور تصمیم میگیرد، در چه ترتیبی NAT و ACL را بررسی میکند، و چطور یک Basic Access Policy بنویسیم که هم کنترلپذیر باشد، هم قابل توسعه، و هم در زمان عیبیابی به ما کمک کند.
در این آموزش تمرکز روی Cisco ASA با CLI کلاسیک است و سناریویی را پیاده میکنیم که در بسیاری از پروژههای واقعی سازمانی وجود دارد. ساختار شبکه شامل یک اینترفیس inside با سطح امنیتی 100 و یک اینترفیس outside با سطح امنیتی 0 است. شبکه داخلی 192.168.10.0/24 در نظر گرفته شده و ASA روی inside دارای IP برابر 192.168.10.1 است. روی سمت خارج یک IP عمومی مانند 203.0.113.2 داریم و گیتوی ISP نیز 203.0.113.1 است. همچنین یک وبسرور داخلی با IP برابر 192.168.10.10 داریم که باید روی اینترنت فقط از طریق HTTPS منتشر شود. هدف این است که کاربران داخلی فقط بتوانند DNS و HTTP و HTTPS به اینترنت داشته باشند، هیچ سرویس اضافی مجاز نباشد، و از سمت اینترنت نیز فقط دسترسی HTTPS به وبسرور داخلی باز باشد.
قبل از اینکه حتی یک خط ACL بنویسید، باید دقیق بدانید Cisco ASA چطور درباره هر بسته تصمیم میگیرد. اگر این ترتیب پردازش را درک نکنید، ممکن است ساعتها ACL را تغییر دهید در حالی که مشکل در NAT، مسیریابی یا حتی state table باشد. در پروژههای واقعی، بیشتر خطاهای عیبیابی به این دلیل رخ میدهد که مهندس شبکه فقط به ACL نگاه میکند و ترتیب کامل پردازش را در ذهن ندارد.
وقتی یک بسته وارد ASA میشود، ابتدا از نظر صحت ساختاری و وضعیت اینترفیس بررسی میشود. اگر اینترفیس down باشد یا IP اشتباه تنظیم شده باشد، بسته حتی وارد چرخه پردازش منطقی نمیشود. بعد از آن ASA بررسی میکند که آیا قبلاً برای این اتصال state وجود دارد یا خیر. اگر این بسته بخشی از یک اتصال قبلاً مجاز باشد، معمولاً بدون بررسی مجدد ACL عبور داده میشود چون ASA یک فایروال stateful است. این موضوع بسیار مهم است چون گاهی در زمان تست، شما ACL را تغییر میدهید ولی اتصال قبلی هنوز در state table فعال است و نتیجه تست شما گمراهکننده میشود. در چنین شرایطی باید با دستوراتی مثل clear conn یا clear local-host تست را از ابتدا انجام دهید.
اگر اتصال جدید باشد، ASA وارد مرحله تطبیق NAT میشود. در نسخههای جدیدتر ASA، ترتیب NAT اهمیت زیادی دارد چون Auto NAT و Manual NAT و Twice NAT هر کدام اولویت متفاوتی دارند. اگر ترجمه آدرس به درستی انجام نشود، حتی اگر ACL اجازه بدهد، بسته به مقصد مورد نظر نخواهد رسید. به عنوان مثال، در سناریوی inside به outside، اگر dynamic PAT تعریف نشده باشد، بسته با IP خصوصی از ASA خارج میشود و در اینترنت route نمیشود. در چنین حالتی ممکن است در packet-tracer ببینید که ACL اجازه داده ولی مرحله بعدی شکست خورده است.
بعد از اعمال NAT، نوبت به بررسی ACL روی اینترفیس ورودی میرسد. این نکته بسیار حیاتی است که ACL همیشه روی اینترفیس ورودی بررسی میشود، نه خروجی. بسیاری از مهندسان تازهکار به اشتباه ACL را روی اینترفیس خروجی اعمال میکنند و انتظار دارند ترافیک فیلتر شود. در ASA منطق به این صورت است که وقتی بسته وارد یک اینترفیس میشود، همانجا تصمیم گرفته میشود که اجازه عبور داشته باشد یا نه. اگر ACL تعریف نشده باشد، رفتار پیشفرض بر اساس security-level اعمال میشود، اما در محیط حرفهای توصیه میشود این رفتار پیشفرض جای خود را به ACLهای صریح بدهد.
پس از عبور از ACL، ASA مسیریابی را بررسی میکند تا مشخص شود بسته از کدام اینترفیس باید خارج شود. اگر route وجود نداشته باشد، بسته Drop میشود حتی اگر ACL آن را مجاز کرده باشد. در برخی پروژهها دیده میشود که تیم امنیت روی ACL تمرکز کرده ولی تیم شبکه default route را تغییر داده و ترافیک به سمت اشتباهی هدایت میشود.
در نهایت اگر همه مراحل موفق باشد، ASA یک state برای اتصال ایجاد میکند و بسته را عبور میدهد. از این لحظه به بعد، ترافیک برگشتی بر اساس state اجازه عبور خواهد داشت و نیازی به تعریف ACL مجزا برای پاسخها نیست. این رفتار stateful یکی از تفاوتهای اساسی ASA با فایروالهای stateless قدیمی است.
نکته مهم دیگر این است که ASA علاوه بر ACL لایه 3 و 4، موتور inspection نیز دارد که میتواند رفتار برخی پروتکلها را بررسی کند. برای مثال، پروتکلهایی مانند FTP یا SIP ممکن است نیاز به inspection policy داشته باشند تا پورتهای دینامیک به درستی مدیریت شوند. اگر inspection مناسب فعال نباشد، ممکن است اتصال ظاهراً مجاز باشد اما در لایه کاربردی با مشکل مواجه شود.
برای اینکه Access Policy معنا داشته باشد ابتدا باید اینترفیسها و مسیر پیشفرض تنظیم شده باشند. فرض میکنیم ASA تازه راهاندازی شده است. وارد حالت تنظیمات میشویم و اینترفیسها را تعریف میکنیم.
بعد از این مرحله با دستور show interface ip brief و show route بررسی میکنیم که همه چیز در وضعیت up باشد و default route به درستی ثبت شده باشد. اگر route اشتباه باشد، حتی ACL صحیح هم مشکل را حل نخواهد کرد.
یکی از اشتباهات رایج در پروژهها نوشتن ACL با IP خام است. این کار در کوتاهمدت ساده به نظر میرسد اما در بلندمدت نگهداری را سخت میکند. بهترین روش استفاده از object و object-group است. ابتدا شبکه داخلی و سرور وب را تعریف میکنیم.
با این کار اگر در آینده subnet تغییر کند، فقط کافی است object را ویرایش کنیم و نیازی به تغییر در ACLهای متعدد نخواهد بود.
در اغلب سناریوهای اینترنتی، کاربران داخلی نیاز به NAT دارند. بدون NAT، بستهها با IP خصوصی از ASA خارج میشوند و در اینترنت route نمیشوند. سادهترین و رایجترین روش برای کاربران، dynamic PAT روی IP اینترفیس outside است.
این دستور به ASA میگوید تمام آدرسهای داخل NET_INSIDE_USERS هنگام خروج به outside با IP اینترفیس outside ترجمه شوند. با دستور show nat و سپس show xlate میتوانیم بررسی کنیم که ترجمهها در زمان ایجاد session ساخته میشوند.
در پروژههای واقعی اگر NAT درست کار نکند، مهندس ممکن است ساعتها روی ACL وقت بگذارد در حالی که مشکل از مرحله ترجمه آدرس است. همیشه در زمان عیبیابی، NAT را همزمان با ACL بررسی کنید.
اکنون به سراغ نوشتن Basic Access Policy میرویم. فرض میکنیم کاربران فقط باید بتوانند DNS و HTTP و HTTPS به اینترنت داشته باشند. ابتدا یک object-group برای سرویسها تعریف میکنیم تا خوانایی و توسعهپذیری حفظ شود.
اضافه کردن TCP برای پورت 53 اهمیت دارد چون در برخی پاسخهای بزرگ DNS از TCP استفاده میشود و اگر فقط UDP مجاز باشد، بعضی queryها شکست میخورند.
سپس ACL مربوطه را مینویسیم.
در اینجا ابتدا اجازه دسترسی به سرویسهای مشخص داده شده و سپس یک deny کلی با گزینه log تعریف شده است. وجود log در انتهای ACL در پروژههای عملی بسیار ارزشمند است چون هر ترافیکی که خارج از سیاست تعریفشده باشد ثبت میشود و در تحلیلهای بعدی قابل بررسی است.
با دستور show access-list ACL_INSIDE_OUT میتوانیم hitcount را ببینیم. اگر کاربران گزارش دهند که مثلاً FTP کار نمیکند و در hitcount مربوط به deny افزایش مشاهده شود، به سرعت مشخص میشود که دلیل، محدودیت تعریفشده در policy است نه خرابی لینک یا DNS.
اکنون میخواهیم وبسرور داخلی را روی اینترنت منتشر کنیم اما فقط از طریق HTTPS. ابتدا باید Static NAT تعریف کنیم تا IP عمومی به سرور داخلی نگاشت شود.
پس از این مرحله با show nat بررسی میکنیم که قانون static ثبت شده باشد. سپس باید ACL روی اینترفیس outside بنویسیم تا فقط پورت 443 به این IP عمومی مجاز باشد.
در این سناریو ACL به IP عمومی اشاره میکند. اگر ACL نوشته شود ولی NAT اشتباه باشد، ترافیک هرگز به سرور داخلی نمیرسد. این یکی از رایجترین خطاها در پروژههای واقعی است.
یکی از قدرتمندترین ابزارهای ASA برای عیبیابی، packet-tracer است. فرض کنید میخواهیم بررسی کنیم یک کاربر داخلی میتواند HTTPS به اینترنت بزند یا نه.
خروجی این دستور نشان میدهد بسته از چه مراحلی عبور کرده، آیا NAT موفق بوده، آیا ACL اجازه داده، و در صورت Drop شدن در کدام مرحله متوقف شده است. برای تست inbound نیز میتوانیم این دستور را اجرا کنیم.
در پروژههای عملی، packet-tracer اغلب سریعتر از بررسی لاگهای طولانی شما را به نتیجه میرساند.
یکی از خطاهای متداول این است که مهندس تصور میکند چون security-level داخل 100 است، نیازی به ACL ندارد. این دیدگاه در شبکههای کوچک شاید قابل قبول باشد اما در محیط سازمانی باعث از دست رفتن کنترل میشود. خطای دیگر، باز گذاشتن کامل inside به any است که بعداً باعث پیچیدگی در تحلیل ترافیک میشود. همچنین فراموش کردن TCP در کنار UDP برای DNS یا اعمال نکردن ACL روی اینترفیس صحیح از دیگر اشتباهات پرتکرار است.
در برخی پروژهها نیز مشاهده میشود که ISP هنوز IP عمومی را به سمت ASA route نکرده و تیم شبکه ساعتها روی فایروال عیبیابی انجام میدهد در حالی که مشکل در upstream است. همیشه باید سناریو را انتها به انتها بررسی کرد.
Basic Access Policy در Cisco ASA صرفاً نوشتن چند خط ACL نیست. این کار ترکیبی از طراحی درست، استفاده از object برای مدیریتپذیری، تعریف صحیح NAT، اعمال دقیق ACL روی اینترفیس مناسب، و در نهایت تست و لاگگیری اصولی است. اگر این سیاست به شکل حداقلی اما کنترلشده نوشته شود، هم امنیت شبکه حفظ میشود و هم در زمان توسعه سرویسهای جدید، افزودن دسترسیها به سادگی انجام خواهد شد.
یک Access Policy خوب باید قابل خواندن، قابل توسعه، و قابل عیبیابی باشد. اگر بعد از شش ماه نتوانید به راحتی بفهمید چرا یک ترافیک مجاز یا غیرمجاز است، یعنی policy از ابتدا مهندسی نشده است.
پیادهسازی اصولی Access Policy در Cisco ASA زمانی ارزش واقعی خود را نشان میدهد که در مقیاس سازمانی، با چندین VLAN، DMZ، سرویسهای منتشرشده، VPNها و سناریوهای پیچیدهتر ترکیب شود. تجربه عملی در طراحی و تحلیل رفتار NAT و ACL تفاوت بین یک کانفیگ ساده و یک معماری پایدار و امن را مشخص میکند.
در این مسیر، وینو سرور میتواند به عنوان یک مرجع تخصصی در حوزه پیادهسازی، آموزش و طراحی سناریوهای پیشرفته فایروالهای Cisco ASA شناخته شود. رویکرد وینو سرور مبتنی بر تجربه پروژههای واقعی، تحلیل دقیق رفتار فایروال و ارائه راهکارهای مهندسی است، نه صرفاً ارائه دستورات خام. اگر به دنبال این هستید که Access Policy را نه فقط اجرا کنید بلکه آن را عمیقاً درک کنید و در سناریوهای پیچیده سازمانی به درستی پیادهسازی کنید، وینو سرور میتواند نقطه اتکای تخصصی شما در این مسیر باشد.
وینو سرور، اولین استارتاپ ارائه تجهیزات و سیستم های سخت افزاری، به صورت مستقیم از تولید کننده به مصرف کننده است. همواره تلاش مجموعه بر این اصل استوار بوده است تا مشتریان بتوانند بهترین سیستم را برای پروژه خود انتخاب کرده و با مناسبترین قیمت، آن را تهیه کنند. تیم وینو سرور، همواره سعی میکند تا جامعترین خدمات را به مشتریان ارائه دهد تا خرید را برای شما به کاری لذتبخش و آسان تبدیل کند.
مطلع شدن از پست های جدید
میخواهم اولین نفری باشم که از مقالههایی که در وینو سرور منتشر میشود، آگاه شوم.
