ملاحضات امنیتی مربوط به Squid بخش اول

(1079 مجموع کلمات موجود در متن)
(8406 بار مطالعه شده است)  

ملاحضات امنیتی در رابطه با پراکسی سرور Squid (بخش اول)

اکثر کاربران دنیای یونیکس با پراکسی سرور قدرتمند Squid آشنایی کامل دارند٬ در مــورد نصب و راه اندازی آن نیز تاکنون مقالات بسیاری نیز ارائه گردیده است که مستند بر اهمیت و کارایی فوق العاده این پرکسی سرور می‌باشند٬ مقاله‌ای که در پیش رو دارید ملاحظات امنیتی در رابطه با بالا بردن امنیت کلی سیستم Squid را دربر خواهد گرفت. قابل ذکر است که مسائلی نظیر پارامتر‌های تنظیم Squid ٬ فیلترینگ و لاگ نمودن رخداد‌ها نیز در ادامه در نظر گرفته خواهد شد ٬ به علت اینکه اکثر موارد بدون توضیحات نصب ارائه می‌گردد مطالعه این مقاله را به دوستانی توصیه می‌کنم که آشنایی کامل با سیستم عامل یونیکس را دارند.

Squid در واقع جهت اجرا در پلاتفورم یونیکس طراحی شده بود ٬ هنگام نصب اکثر سیستم عامل‌های یونیکس ٬ تعداد زیادی از سرویس‌های ناخواسته به صورت پیش فرض همراه آن نصب می‌شد و در واقع اغلب٬ نفــوذگــر‌ها فعالیت‌های مخرب خود را از طریق این سرویسها انجام می‌دادند. به عنوان مثال٬ بسیاری از سیستم عامل‌های یونیکس هنگام نصب٬ سرویس sendmail را به صورت پیش فرض فعال می‌کنند در صورتی که نسخه‌های قدیمی‌ sendmail همیشه ضعف و آسیب پذیری‌هایی را پذیرا بوده است!

از این جهت این مطلب را عنوان نمودم که چنانچه فقط تصمیم به راه اندازی یک پراکسی سرور دارید٬ سرویس‌های دیگر را که منجر به ریسک امنیتی می‌گردند را غیرفعال کنید. هنگامی‌که مراحل نصب را پشت سر گذاشتید یک کاربر Sandbox ( اصطلاح Sandbox در امنیت شبکه ٬ یک مکانیزم امنیتی جهت اجرای برنامه‌ها به صورت ایمن است و اغلب جهت اجرای کدهای تست نشده و یا برنامه‌هایی از طرف کاربران تایید نشده به کار می‌رود) مختص به Squid ایجاد نمایید٬ یک شل Invalid را به کاربر Sandbox اختصاص دهید و یا از برنامه‌ای رایگان به نام noshell استفاده نمایید .

دلیل استفاده از از یک کاربر Sandbox ایجاد محدودیت در رابطه با دسترسی به Squid است تا اینکه مانعی جهت حملات Buffer OverFlow ایجاد گردد . به عنوان مثال ورژن 2.4 Squid به علت مشکلات بافر سرریز شناخته شده است و نفوذگر می‌تواند با ارسال یک URL خاص٬ کد اجرایی مدنظر خود را در با سطح کاربری Squid اجرا نماید. برای اطلاعات بیشتر در رابطه با این آسیب پذیری می‌توانید به اینجا [۱] مراجعه نمایید.

Squid جهت ذخیره اطلاعات cache به صورت local نیازمند دسترسی به فولدرهاست٬ اطمینان حاصل نمایید که کاربر Squid دسترسی خواندن / نوشتن / اجرا را به این فولدر‌ها را دارد. یک switched network راه کارهایی را جهت محافظت در مقابل حملاتی نظیر اسنیفینگ و همین طور اطلاعات مهم ٬ مانند کلمه‌های عبور و نام کاربری ارائه می‌دهد. در مورد این مطلب مقاله‌هایی را می‌توانید با جستجو در اینترنت پیدا نمایید که به زودی مقاله‌ای نیز در رابطه باswitched network نیز ارائه خواهم داد.

جهت ایمنی بیشتر در Squid می‌توان هنگام دریافت کدهای منبع آن، از قابلیت بررسی MD5 CHECKSUM نیز استفاده کرد٬ جهت اطلاعات بیشتر به اینجا [۲] مراجعه فرمایید. صحت دریافت سورس فایل‌ها همیشه بایستی تایید گردد ٬ این روش تنها چند دقیقه زمان می‌برد و از مشکلات احتمالی جلوگیری نمی‌نماید. یک مثال بارز آن وجود یک تروجان در sendmail بود که می‌توانید نامه خبری آن را در اینجا [۳] دنبال نمایید.

تنظیمات

همان طور که مطلع هستید Squid از تعداد زیادی پارامتر در فایل پیکربندی خود برخوردار است٬ اما در مقاله فقط به مهم ترین پارامترها که به ایمن سازی این پراکسی سرور کمک می‌نمایند اشاره خواهد شد .

http_port

پارامتر http_port این گونه می‌نماید ٬ هنگامی‌که Squid می‌خواهد منتظر درخواستی بماند از کدام درگاه استفاده نماید . درگاه پیش فرض 3128 است که جهت ایمنی بیشتر بهتر است شماره درگاه را به شماره‌ای بالا تر تغییر داد . از این جهت که بعضی از ابزارهای پورت اسکنینگ این گونه تنظیم شده‌اند که شماره پورت‌هایی نظیر ۳۱۲۸ و ۸۰۸۰ را به عنوان پراکسی سرور در نظر بگیرند.

چنانچه سرور شما از چندین کارت شبکه استفاده می‌نماید شما می‌توانید IPهایی که Squid جهت جوابگویی به درخواست‌ها در نظر می‌گیرد را محدود کنید ٬ به عنوان مثال این پارامتر :

http_port 10.50.3.2:6754

Squid را این گونه تنظیم می‌نماید که فقط از کارت شبکه با ای پی 10.50.3.2 منتظر درخواست بماند و دیگر درخواست‌هایی که از دیگر کارت شبکه وارد می‌گردند Ignore می‌شود .

dns_nameservers value

Squid از name server‌هایی که در فایل etc/resolv.conf/ لیست گردیده‌اند استفاده می‌کند. می‌توان با استفاده از دایرکتیو dns_nameservers ٬ name server‌های متفاوت را نیز لیست نمود .

NameServer‌هایی که توسط Squid استفاده می‌گردد بایستی از سورس‌های تایید شده و معتبر باشند یک DNS Server تایید نشده که توسط نفوذگر استفاده می‌گردد می‌تواند به شخص این امکان را بدهد که پرکسی سرور‌ها را دایورت نموده و بعضی از ورژن‌های Squid با دریافت یک جواب DNS Server نفوذگر کرش می‌گردند. اطلاعات بیشتر در مورد این مشکل امنیتی Squid در اینجا [۴] قابل دریافت است.

maximum_object_size value

minimum_object_size value

از اطلاعاتی که توسط یک پراکسی سرور به صورت local ذخیره می‌گردد اغلب به عنوان object یاد می‌شود . پارامترهایی که در بالا به آن‌ها اشاره گردید به شما این امکان را می‌دهد که به صورت force بر روی اطلاعات کش شده محدودیت بگذارید ٬ هدف اصلی این تنظیم بهبود cache/HIT ست . این تنظیم ٬ از دید امنیتی نیز قابل توجه است از آن جهت که در مقابل حملات DoS نیز محافظ ایجاد می‌نماید .

چنانچه مقدار پارامتر maximum_object_size را بسیار زیاد بگذارید این امکان برای نفوذگر فراهم می‌شود که با دادن درخواست‌های سنگین پراکسی سرور شما را overload نموده و باعث گردید که سرعت دیگر کاربران Squid پایین برود . هم چنین انجام یک حمله DoS به سادگیست هنگامی‌که تنظیمات پراکسی سرور شما به گونه‌ای باشد که به بارگذاری object‌ها ادامه دهد در صورتی که کاربر مورد نظر نیز درخواست خود را لغو نموده ست . متاسفانه موردی که اشاره شد جزء تنظیمات پیش فرض Squid بود ولی با این پارامتر‌ها قابل تغییر است :

quick_abort_min

quick_abort_max

quick_abort_pct

authenticate_ttl value

authenticate_ip_ttl value

هنگامی‌که از حالت authenticate استفاده می‌شود ٬ پارامتر authenticate_ttl تعریف کننده این مورد است که تا چه مدت زمان Squid اطلاعات Authenticate کلاینت را به خاطر بسپارد . این تنظیم در واقع کلاینت را وادار می‌نماید که تا بعد از یک دوره زمانی خود را دوباره authenticate کند.

request_header_max_size value

این پارامتر در این رابطه استفاده می‌شود که تا مقدار سایز قابل پذیرش HTTP Header را محدود نماید . مقدار پیش فرض در اینجا ۱۰ کیلو بایت بوده که از مقدار منطقی بیشتر به نظر میرسد به این دلیل که سایز متوسط header ۵۱۲ بایت است در صورتی که سنگین ترین header ممکن است در حد کیلوبایت باشند. بیشتر حملات DoS نسبت به پراکسی سرورها اینگونه رخ می‌دهد که header‌هایی برای آن‌ها فرستاده شود که از مقداری که پراکسی سرور می‌تواند جوابگو باشد بیشتر باشد.

client_lifetime value

pconn_timeout value

پارامتر client_lifetime بیشترین زمانی است که کلاینت می‌تواند به عنوان یک پروسه Squid قرار کرفته باشد. در واقع این تنظیم سرور شما را از باز بودن تعداد زیادی سوکت محافظت می‌نماید . بستگی به شرایط شما ٬ ممکن است ۶ ساعت مناسب باشد در صورتی که ۲۴ ساعت کمی‌زیاد به نظر می‌رسد. با بررسی در مورد وصل شدن کلاینت‌ها می‌توان زمان مناسب را تشخیص داد ٬ یک نفوذگر می‌تواند با استفاده از lifetime طولانی تعداد زیادی سوکت را باز نماید و این خود باعث نوعی حمله DoS می‌گردد. اما پارامتر pconn_timeout شبیه به client_lifetime می‌باشد با این تفاوت که فقط شامل Idle Connection‌ها می‌گردد.

احسان امیدوار Ehsan.Omidvar@gmail.com