هاردنینگ Cisco؛ فیلتر کردن بستههای TTL پایین در مرز شبکه

در تجهیزات Cisco هر بستهای مثل ترافیک عادی و سریع از مسیر CEF عبور نمیکند. بعضی بستهها به دلایل خاص باید توسط CPU پردازش شوند. اگر تعداد این بستهها زیاد شود، همان تجهیزی که باید کار routing و switching را آرام انجام دهد، درگیر پردازشهای غیرضروری میشود.
یکی از نمونههای مهم، بستههایی هستند که TTL آنها در مسیر به صفر میرسد. وقتی TTL صفر شود، روتر بسته را drop میکند و معمولا یک پیام ICMP Time Exceeded به مبدا برمیگرداند. ساختن همین پاسخ ICMP کاری است که میتواند CPU را درگیر کند.
TTL پایین چرا مهم است؟
TTL برای این طراحی شده که packet برای همیشه در شبکه نچرخد. هر روتر در مسیر، TTL را یک عدد کم میکند. اگر TTL به صفر برسد، packet دیگر forward نمیشود.
در حالت عادی این رفتار طبیعی و مفید است. اما اگر مهاجم عمدا تعداد زیادی packet با TTL پایین به سمت شبکه بفرستد، روترهای مرزی یا داخلی مجبور میشوند تعداد زیادی بسته را drop کنند و برای آنها ICMP Time Exceeded بسازند. اینجا موضوع از یک رفتار طبیعی به یک فشار غیرضروری روی control plane تبدیل میشود.
فقط TTL نیست
TTL پایین تنها موردی نیست که ممکن است CPU را درگیر کند. بستههای fragment شده، بستههایی که IP Options دارند، و بعضی exception packetها هم میتوانند از مسیر سریع خارج شوند. برای همین hardening مرز شبکه فقط یک دستور نیست؛ مجموعهای از کنترلهای کوچک است که کنار هم ریسک را کم میکند.
قبلا درباره IP Options و IP Fragments جداگانه نوشتم. TTL filtering هم در همان خانواده قرار میگیرد: کم کردن packetهایی که ارزش عبور ندارند ولی میتوانند منابع تجهیز را مصرف کنند.
کجا TTL را فیلتر کنیم؟
بهتر است این کنترل در ورودی شبکه و نزدیک مرز اعمال شود، نه وسط شبکه داخلی. هدف این است که packet مشکوک قبل از اینکه وارد مسیرهای داخلی شود حذف شود.
عدد TTL باید با شناخت topology انتخاب شود. اگر بین مرز شبکه و تجهیزات مهم چند hop دارید، نباید عدد را بیحساب پایین بگذارید. عدد اشتباه میتواند ترافیک سالم را هم قطع کند. اول مسیرهای واقعی را بررسی کنید، بعد threshold بگذارید.
نمونه ACL برای فیلتر TTL پایین
در این نمونه، بستههایی که TTL آنها کمتر از ۶ است در ورودی مرز شبکه drop میشوند. بعد از آن، ترافیک به سمت infrastructure address space کنترل میشود و در انتها transit traffic مجاز میماند.
ip access-list extended ACL-INFRASTRUCTURE-IN
remark Drop packets with TTL too low to safely traverse the network
deny ip any any ttl lt 6
remark Block direct access to infrastructure addresses
deny ip any <infrastructure-address-space> <wildcard-mask>
remark Permit normal transit traffic
permit ip any any
این ACL باید روی interface ورودی مناسب اعمال شود:
interface GigabitEthernet0/0
description Internet edge
ip access-group ACL-INFRASTRUCTURE-IN in
قبل از اعمال در production
قبل از اینکه چنین ACLای را در شبکه اصلی بگذارید، counterها و مسیرهای واقعی را بررسی کنید. اگر چند مسیر internet edge، tunnel، یا routing نامتقارن دارید، تصمیمگیری باید دقیقتر باشد.
show access-lists ACL-INFRASTRUCTURE-IN
show ip cef switching statistics
show processes cpu sorted
بعد از اعمال هم فقط up بودن interface کافی نیست. باید ببینید counter مربوط به deny بالا میرود یا نه، CPU چه رفتاری دارد، و آیا کاربران یا سرویسهای واقعی دچار مشکل نشدهاند.
جمعبندی عملی
فیلتر کردن TTL پایین یک کنترل کوچک ولی مفید در hardening تجهیزات مرزی است. این کار قرار نیست جای firewall، CoPP یا طراحی درست perimeter را بگیرد، اما میتواند جلوی بخشی از فشارهای بیارزش روی CPU را بگیرد.
قاعده اصلی ساده است: هر packetی که منطقا نباید بتواند مسیر شبکه شما را طی کند، بهتر است همان ورودی حذف شود.

SegmentSmack؛ آسیبپذیری TCP در کرنل لینوکس و ریسک DoS
کنترل امنیت شماره ۱۴: دسترسی بر اساس نیاز کاری، نه اعتماد کلی
قابلیت بازیابی اطلاعات؛ Backup امن در برابر حادثه و باجافزار
لیست دستگاههای مجاز و غیرمجاز؛ پایه Inventory در امنیت شبکه
پیکربندی امن تجهیزات شبکه؛ کنترل تغییرات، دسترسی و سختسازی
کنترل امنیت شماره ۲۰: تست نفوذ و Red Team؛ آزمون واقعی کنترلها