انتشار پایدار سرور پروکسی Squid 5

پس از سه سال توسعه، یک نسخه پایدار از سرور پروکسی Squid 5.1 ارائه شده است که برای استفاده در سیستم‌های تولید آماده است (نسخه‌های 5.0.x وضعیت نسخه‌های بتا را داشتند). پس از اینکه به شاخه 5.x وضعیت پایدار داده شد، از این پس تنها رفع آسیب پذیری ها و مشکلات پایداری در آن انجام می شود و بهینه سازی های جزئی نیز مجاز است. توسعه ویژگی های جدید در شاخه آزمایشی جدید 6.0 انجام خواهد شد. به کاربران شاخه پایدار قبلی 4.x توصیه می شود که برای مهاجرت به شاخه 5.x برنامه ریزی کنند.

نوآوری های کلیدی در Squid 5:

  • اجرای ICAP (پروتکل تطبیق محتوای اینترنتی) که برای ادغام با سیستم‌های تأیید محتوای خارجی استفاده می‌شود، پشتیبانی از مکانیزم پیوست داده (تریلر) را اضافه کرده است که به شما امکان می‌دهد سرصفحه‌های اضافی را با ابرداده به پاسخ، که بعد از پیام قرار می‌گیرد، پیوست کنید. بدن (به عنوان مثال، می توانید یک چک سام و جزئیات مربوط به مشکلات شناسایی شده را ارسال کنید).
  • هنگام تغییر مسیر درخواست ها، از الگوریتم "Happy Eyeballs" استفاده می شود که بلافاصله از آدرس IP دریافتی استفاده می کند، بدون اینکه منتظر بمانید تا تمام آدرس های هدف IPv4 و IPv6 بالقوه موجود حل شوند. به جای در نظر گرفتن تنظیم "dns_v4_first" برای تعیین اینکه آیا از یک خانواده آدرس IPv4 یا IPv6 استفاده می شود، ترتیب پاسخ DNS اکنون در نظر گرفته می شود: اگر پاسخ DNS AAAA ابتدا در زمان انتظار برای حل شدن آدرس IP برسد، سپس آدرس IPv6 حاصل استفاده خواهد شد. بنابراین، تنظیم خانواده آدرس ترجیحی اکنون در فایروال، DNS یا سطح راه اندازی با گزینه "--disable-ipv6" انجام می شود. تغییر پیشنهادی به ما این امکان را می‌دهد که زمان راه‌اندازی اتصالات TCP را تسریع کنیم و تأثیر عملکرد تأخیر در رزولوشن DNS را کاهش دهیم.
  • برای استفاده در دستورالعمل "external_acl"، کنترل کننده "ext_kerberos_sid_group_acl" برای احراز هویت با بررسی گروهی در Active Directory با استفاده از Kerberos اضافه شده است. برای جستجوی نام گروه، از ابزار ldapsearch ارائه شده توسط بسته OpenLDAP استفاده کنید.
  • پشتیبانی از فرمت Berkeley DB به دلیل مسائل مربوط به مجوز منسوخ شده است. شعبه Berkeley DB 5.x چندین سال است که حفظ نشده است و با آسیب‌پذیری‌های اصلاح‌نشده باقی می‌ماند، و انتقال به نسخه‌های جدیدتر با تغییر مجوز به AGPLv3 که الزامات آن برای برنامه‌هایی که از BerkeleyDB در قالب استفاده می‌کنند نیز اعمال می‌شود. یک کتابخانه - Squid تحت مجوز GPLv2 عرضه می شود و AGPL با GPLv2 سازگار نیست. به جای Berkeley DB، پروژه به استفاده از TrivialDB DBMS منتقل شد که بر خلاف Berkeley DB، برای دسترسی موازی همزمان به پایگاه داده بهینه شده است. پشتیبانی Berkeley DB در حال حاضر حفظ شده است، اما کنترل‌کننده‌های "ext_session_acl" و "ext_time_quota_acl" اکنون به جای "libdb" از نوع ذخیره‌سازی "libtdb" استفاده می‌کنند.
  • پشتیبانی اضافه شده برای هدر CDN-Loop HTTP، تعریف شده در RFC 8586، که به شما امکان می‌دهد حلقه‌ها را هنگام استفاده از شبکه‌های تحویل محتوا شناسایی کنید (سرصفحه محافظت در برابر موقعیت‌هایی را فراهم می‌کند که درخواستی در فرآیند تغییر مسیر بین CDN به دلایلی به آن بازمی‌گردد. CDN اصلی، تشکیل یک حلقه بی پایان).
  • مکانیسم SSL-Bump، که به شما امکان می دهد محتویات جلسات HTTPS رمزگذاری شده را رهگیری کنید، پشتیبانی را برای هدایت مجدد درخواست های HTTPS جعلی (رمزگذاری شده) از طریق سایر سرورهای پراکسی مشخص شده در cache_peer، با استفاده از یک تونل معمولی بر اساس روش HTTP CONNECT اضافه کرده است. انتقال از طریق HTTPS پشتیبانی نمی شود، زیرا Squid هنوز نمی تواند TLS را در TLS منتقل کند. SSL-Bump به شما امکان می دهد پس از دریافت اولین درخواست HTTPS رهگیری شده، یک اتصال TLS با سرور مورد نظر برقرار کنید و گواهی آن را دریافت کنید. پس از این، Squid از نام میزبان از گواهی واقعی دریافت شده از سرور استفاده می کند و یک گواهی ساختگی ایجاد می کند که با آن سرور درخواستی را هنگام تعامل با مشتری تقلید می کند، در حالی که همچنان از اتصال TLS ایجاد شده با سرور هدف برای دریافت داده ها استفاده می کند. برای اینکه جایگزینی منجر به هشدارهای خروجی در مرورگرهای سمت مشتری نشود، باید گواهی خود را که برای تولید گواهی‌های ساختگی استفاده می‌شود به فروشگاه گواهی ریشه اضافه کنید.
  • دستورالعمل‌های mark_client_connection و mark_client_pack برای اتصال علامت‌های Netfilter (CONNMARK) به اتصالات TCP مشتری یا بسته‌های فردی اضافه شد.

نسخه‌های Squid 5.2 و Squid 4.17 منتشر شد که در آن آسیب‌پذیری‌ها برطرف شد:

  • CVE-2021-28116 - نشت اطلاعات هنگام پردازش پیام های WCCPv2 ساخته شده ویژه. این آسیب پذیری به مهاجم اجازه می دهد تا لیست روترهای WCCP شناخته شده را خراب کند و ترافیک را از کلاینت های سرور پروکسی به میزبان خود هدایت کند. مشکل فقط در تنظیمات با فعال بودن پشتیبانی WCCPv2 و زمانی که امکان جعل آدرس IP روتر وجود دارد ظاهر می شود.
  • CVE-2021-41611 - مشکلی در تأیید گواهی TLS امکان دسترسی با استفاده از گواهینامه های غیرقابل اعتماد را فراهم می کند.

منبع: opennet.ru

اضافه کردن نظر