این متن تقدیم می شود به تمام پشتیبان های صبور شبکه که ساعت 2 بامداد وقتی از یک IP پینگ می گیرند متوجه می شوند که ICMP روی آن IP بسته شده است.
مشکل :
اغلب کارشناسان امنیت شبکه گمان می کنند که ICMP یک ریسک امنیتی هست و در سمت فایروال باید بسته شود. درست است که ICMP آسیب پذیری هایی دارد و در برخی از حملات هم کاربرد دارد اما هیچ دلیلی ندارد که تمام ترافیک های ICMP را بلاک کنید.
پروتکل ICMP پروتکلی بسیار مفید جهت خطایابی شبکه و عملکرد درست شبکه است. از پروتکل ICMP در دستور ping و trace در ویندوز استفاده می شود و در لینوکس و سیسکو و یونیکس هم می توان با تنظیماتی trace را از طریق ICMP انجام داد. هرچند به صورت پیش فرض این اتفاق روی نمی دهد.
Echo Request,Reply
همه می دانیم که ping مهمترین ابزار مشکل یابی در شبکه است. وقتی آن را فعال می کنیم یعنی host مان قابل کشف شدن خواهد بود. اما به هرحال مگر وب سرورتان در حال گوش دادن به بسته های داده ورودی از پورت 80 نیست ؟
اگر می خواهید می توانید پینگ را از edge شبکه به DMZ برقرار نمایید اما بستن پینگ در داخل شبکه برای شما هیچ سودی نخواهد داشت و تنها مشکل یابی را سخت می کند.
دقت کنید که شما می توانید پینگ را از یک جهت باز و از جهتی دیگر ببندید. می توانید تصمیم بگیرید درخواست echo را از شبکه خود به اینترنت و پاسخ های echo را از اینترنت به شبکه باز بگذارید اما در جهت معکوس ببندید.
نیاز به سگمنت بندی (IPv4)
این بخش بسیار مهم است. ICMP یک جز اساسی در کشف سایز MTU لینک های ارتباطی هستند که بخش مهمی از TCP است که به دو هاست مبدا و مقصد اجازه می دهد که مقدار حداکثر سایز سگمنت TCP (MSS) خود را به کوچکترین MTU لینک ارتباطی بین مبدا و مقصد تنظیم کنند.
اگر دو هاست MTU پایین تری نسبت به لینک خود داشته باشند و راهی برای کشف این موضوع نداشته باشند ترافیک بی سر و صدا محو خواهد شد. در واقع به بدترین شکل ممکن به مشکل خواهید خورد.
دقت کنید که در IPV6 در روتر هیچ سگمنت بندی ای انجام نمی شود و در IPV4 هم اگر بیت DF یک باشد (که نود درصد مواقع یک است ) به معنی Don’t Fragment است به این معنی است که در مسیر نباید فرگمنت بندی انجام شود.
در IPV4 با بیت DF و در IPV6 اگر روتر به دلیل بزرگی بسته دیتا نتواند آن را بخواند بسته را دور می اندازد. و در این مواقع پروتکل ICMP با پیام fragmentation needed در IPv4 و packet Too Big در IPv6 می تواند این مشکل را اعلام کند.
اگر این پیام به فرستنده نرسد فرستنده فقط فکر میکند به هر دلیلی Ack (بخشی از 3 مرحله TCP) را دریافت نکرده و دوباره بدون رفع مشکل بسته را مجدد ارسال می کند.
مشکل یابی چنین مشکلاتی در شبکه با وجود 3way handshake در TCP همچنان پردردسر خواهد بود اگر ICMP در کنارتان نباشد و با آمدن هر بسته بزرگی session بدون دلیل مشخصی بسته خواهد شد.
اما برای این مشکل راه حل دیگری نیز وجود دارد که بدون نیاز به ICMP است و در RFC شماره 4821 معرفی شده است. به این تکنیک Packetization Layer Path MTU Discovery می گویند و به این ترتیب است که با افزایش طول MSS به ترتیب سعی در کشف طول MTU دارد و این روال افزایش MSS در هاست را ادامه می دهد تا طول MTU لینک را کشف کند و این پروتکل در اکثر سیستم عامل ها نیز ساپورت می شود. اما این تکنیک به خوبی ICMP نیست که مستقیما می گوید ماکزیمم MTU چقدر باید باشد. بنابراین لطفا اجازه دهید این بسته های ICMP کار خود را انجام دهند.
Time Exceed
Trace نیز به مانند ping ابزاری بسیار کاربردی در مشکل یابی شبکه است که جزئیات درباره node های مسیر می دهد.
اگر در ویندوز باشیم به صورت پیش فرض و اگر در سیستم عاملی لینوکسی یا یونیکسی باشیم به صورت انتخابی می توانیم از ICMP برای اینکار استفاده کنیم. به صورتی که ابتدا بسته ای با TTL = 1 ارسال می کنیم و وقتی به روتری برخورد کرد TTL یکی کم می شود و پروتکل ICMP یک پیام time exceed برای فرستنده ارسال می کند که حاوی IP اش هم است و سپس فرستنده بسته ای با TTL = 2 ارسال می کند که از روتر اول عبور کرده و در روتر دوم به این مشکل برخورد و همین روال تا رسیدن به مقصد ادامه می یابد.
دقت کرده اید که وقتی از مقصدی trace می گیرید بعضی از روتر های مسیر نامشخص هستند ؟ این به این دلیل هست که متخصص شبکه آن روتر پروتکل ICMP را روی روترش بسته است ؟ شرم بر او باد!!!
این متن (آیا باید ICMP را ببندم ؟) برگرفته از منبع shouldiblockICMP بود که به بررسی پروتکل ICMP پرداخت. البته نظرات شخصی و یک سری توضیحات اضافی به متن اضافه گردید.
دیدگاهتان را بنویسید