ایرادات فنی سیستم فیلترینگ جدید مخابرات

به نظر میاد که مخابرات سیستم فیلترینگ جدیدش رو نصب کرده به طوری که می تواند از این پس بر اساس URL و DOMAIN فیلتر کند و نه مانند قبل بر اساس IP Address . خوب این پیشرفت خوبی هستش . اما در این راستا یک سری ایراد فنی در سیستم فعلی به نظرم میرسه که واقعا ایرادهای بزرگی هستش که باید رفع کنند چرا که اینطوری مشکلاتی به بار می آورد که در ذیل بیشتر توضیح دادم :
مهمترین ایرادی که به نظر من خیلی هم بزرگ است و یکمی که بگذره صدای همه وب سایت داران را در خواهد آورد این است که همه کسانی که از خطوط مخابرات برای بازدید صفحات وب استفاده می کنند از دید log فایلهای مربوط به access این سایتها و سایتهای تولید کنند آمارهای بازدید به عنوان چند IP مانند :
217.218.127.70
217.218.127.71
217.218.127.72
217.218.127.73
217.218.127.74
217.218.127.75
شناخته می شوند !!!!! فکر می کنم فهمیدید چه مشکل وحشتناکی است !!! شوخی که نیست 300 مگابیت پهنای باند با بیش از 2 کلاس B آدرس معتبر در اینترنت به عنوان چندین آدرس خاص در log فایلها و تولید کنندگان آمارهای مختلف شناخته می شود که کمی که بگذرد صدای همه در می آید که آقا آمارهای ما همه به هم ریخته است . حالا در حد یک ISP شاید چنان محسوس نباشد ، اما در سطح 300 مگابیت فکر کنم خیلی محسوس باشد . البته راه حل هم دارد ! علت این موضوع استفاده از squid است که در اصل یک proxy و web cache هستش و بنده خدا تقصیری هم ندارد برای اینکه اصلا کارش چیز دیگری است و برای filtering ساخته نشده ! حالا بعدا یه بنده خدایی پیدا شده و squidGuard رو براش نوشته که کار filtering رو هم در کنارش انجام بده و الا در حقیقت ایراد از squid نیست . برای رفع این مشکل باید سیستم filtering ای تهیه کنند که با استفاده از IP Spoofing بتواند درخواستهای web رو فیلتر کند . به این معنا که هنگامی که درخواستی برای یک صفحه وب به این سیستم filtering ارجاع داده شد ، آن درخواست را باز کند و بر اساس تعاریفی که در آن شده است تشخیص دهد که آیا این درخواست مجاز است یا خیر . در صورتی که این درخواست مجاز بود باید این درخواست را برای سایت میزبان آن صفحه با آدرس خود Clinet و نه با آدرس خودش ( یعنی دستگاه filtering ) ارسال کند . این کار را همان IP Spoofing می گویند . در حال حاضر این سیستم غلط که پیاده شده است اینگونه نیست ! یعنی درخواست وقتی به filter ارجاع شد نگاه می کند اگر مجاز بود آنرا با آدرس خودش ( یعنی IP دستگاه filtering ) برای سایت میزبان ارسال می کند . تنها کاری که می کند این است که یک Header به درخواست با عنوان X-Forwarded-For اضافه می کند که در آن آدرس اصلی Client درخواست کننده را قرار می دهد ( آن هم برای اینکه جوابش که برگشت بداند باید آنرا به چه کسی تحویل دهد ) . با این کار در حقیقت از دید وب سرور میزبان درخواست کننده همان دستگاه filtering است و نه IP آدرس client ای که دارد از خطوط مخابرات استفاده می کند . پس از دید نرم افزارهای تولید کننده آمار بینندگان وب ، بازدیدکنندگان وب ایرانی یعنی چند IP محدود !!! :)
روش رفع مشکل را که گفتم ، همانا استفاده از IP Spoofing هستش . فکر می کنم در PIX محصول شرکت Cisco می توان این کار را کرد ( یعنی شنیده ام ) . اما من خودم بر روی Squid این کار کرده ام :) البته نه همینطوری !! برای اینکه نه Squid آنرا پشتیبانی می کند و Netfilter و نه Kernel محترم Linux که در حالت عادی ضد IP Spoofing هم هست ( Router های Cisco هم ضد آن هستند در حالت عادی ، برای اینکه یکی از روش های شناخته شده Hacker های اینترنتی برای DoS و ... می باشد ) . اما استفاده از آن در یک VLAN که شما خودتان می خواهید از خاصیت آن به صورت کنترل شده استفاده کنید مشکلی را ایجاد نمی کند . برای این منظور یک سری Patch برای Squid و Iptabes و Kernel لازم است . من خودم این رو بر روی Linux با همین قضیه IP Spoofing راه انداختم و خوب هم کار می کرد . چون از اینجا شنیدم که مخابرات هم از Linux و Squid و SquidGuard و احتمالا هم Iptables برای filter کردن درخواستها استفاده می کند ، آنها هم می توانند با همینها این مشکل را حل کنند . البته ابزارهای تخصصی Content Filtering فکر می کنم به صورت آماده وجود دارند که این کار می کنند . در ضمن مشکل دیگر این روش این است که در صورتیکه چندین مسیر دریافت جداگانه داشته باشند که به صورت Load Balance از آنها استفاده نکنند و هر کدام مخصوص یک سری لینک باشد ( که نمی دانم اینطوری هستش یا نه ) آنوقت فقط همان مسیری که IP فیلترینگ آنها از آن range است برای receive استفاده می شود ! ( قابل توجه ICP هایی که خطوط send می فروشند و می خواهند بر روی آنها نیز filter بگذارند . solution مشترک است )
نکته دیگری که فکر کنم این را دیگر اشتباه نکرده باشند ( که اگر کرده باشند دیگر هیچ !!! ) این است که باید سیستم Caching مربوط به Squid را غیر فعال کنند . چرا که اگر اینکار را نکنند هم Load وحشتناکی بر روی سیستم های filtering اضافه می شود و هم اینکه هیچ موقع و نه در هیچ کجای دنیا بر روی 300 مگابیت لینک اینترنت Cache نمی گذارند . Cache فقط برای End User است ( یعنی در سطح ISP ، گویی که filter هم هینطور اما در ایران به دلیل مسائل قانونی انگار مخابرات باید filter بگذارد ، اما Cache را که دیگر مجبور نیست ) .
در مورد نکاتی هم که ITIran در اینجا گفته است چند توضیح می دهم :
1- چرا فکر می کنند برای آن Load بالا نمی توان از Linux استفاده کرد ؟! مگر قرار است که همه Load را بر روی یک دستگاه Linux بریزند . توسط Protocol هایی مانند WCCP می توانند Load Balance کنند ( کاری که همین الان به نظر میاد که کردند ) و در صورت ایراد در یکی از این سیستمها مشکلی به وجود نمی آید و بقیه جبران می کنند . نکته ای که باید اشاره کنند این است که کسی در این پهنای باند عظیم Filter نمی گذارد که جواب آن هم در کشور ما مشخص است :)
2- حرفشان درست است ! filtering در هسته مرکزی باعث می شود که یک خرج گنده برای یک Load بالا بشود و در صورت بروز مشکل همه Link های مخابرات صدمه ببینند . می توانستند لااقل این را در مراکز خود تقسیم کنند .
3- نمی دانم چگونه فهمیده اند که سرور ها به درستی Configure نشده ! اما اونی که مسلمه Spoofing و Request Attack همیشه وجود دارد و خیلی راحت می توان جلوی آنها را گرفت . ( گویی که در router های Cisco که مخابرات هم از آنها استفاده می کند به صورت پیش فرض خیلی از این مشکلات مانند Spoofing را ندارد )
4- این مشکل squidGuard نیست !! در squidGuard خیلی راحت می توان با یک config درست این مشکل را حل کرد . البته من تست نکردم ! اما بعید بدونم الان اینطوری باشه ! چون اگه می خواستند IP را ببندند دیگر نیازی به squid و squidGuard نبود !! یک Access List در Cisco کار را تمام می کرد :)
در آخر هم گفته که Squid ها به صورت Parent کار می کنند که احتمالا منظورش Sibling بوده ! چون Parent اصلا در اینجا معنی نمی دهد و فکر کنم منظورش از Traffic Shaping همان Load Balancing بوده است