نوشته شده توسط: علی آخی و بردیا اکبری
چطور کار میکند؟!
ابزار TCP Load Balancer برای برنامه هایی است که از HTTP استفاده نمی کنند. یک TCP Load Balancer وقتی که در مقابل یک کلاستر پایگاه داده (database cluster) مستقر می شود ، درخواست ها را در تمام پیکربندی های موجود در سرور پخش می کند. هر نوع برنامه کاربردی برای سرور از طریق اتصال جدید TCP به سرور موجود ارسال می شود. در Separating یا (proxying) مشتری با اتصالات سرور امکان افزایش امنیت ، از جمله پاکسازی پروتکل TCP یا کاهش DoS را فراهم می کند. همچنین عملکرد بهتر سرور و اتصالات client را فراهم می کند.
پس فرق بین HTTP Load Balancer و TCP Load Balancer در چیست؟
تعادل بار HTTP یک معماری ساده درخواست / پاسخ HTTP برای ترافیک HTTP است. اما یک تعادل بار TCP برای برنامه هایی است که در آنها از HTTP صحبت نشده است.
درمورد UDP Load Balancer NGINX:
اتصالات UDP فقط مدت کوتاهی طول می کشند ، به همین دلیل ترافیک مبتنی بر UDP شامل جستجوی آدرس های کوتاه مدت سیستم, نام دامنه (DNS) و پروتکل زمان شبکه (NTP) می باشد. پروتکل UDP از شماره گذاری توالی اتصال برای نظارت بر انتقال و دریافت داده ها استفاده نمی کند. اما اتصالات UDP از طریق آدرس IP و شماره پورت قابل ردیابی است. اما این تعیین نمی کند که داده ها به کدام ارتباط تعلق دارند. این امر به دلیل کمبود جزئیات در مورد سرورهای ارسال درخواست ، چالشی برای توازن بار است. از آنجا که UDP بی سیم است ، بسته های داده مستقیماً به سرور Load Balancer منتقل می شوند. تصمیم تعادل بار در اولین بسته از مشتری گرفته می شود و آدرس IP منبع به آدرس IP متعادل کننده بار تغییر می یابد.
تعادل بار UDP نوعی از load balancer ها است که از پروتکل UserDatagram استفاده می کند ، که در لایه 4 (لایه حمل و نقل) در مدل اتصال سیستم های باز (OSI) عمل می کند. ترافیک UDP در یک سطح متوسط بین یک برنامه کاربردی و پروتکل اینترنت (IP) برقرار می شود.
خب کاربرد استفاده از این پروتکل برای کارهایی است که سرعت انتقال داده فوق العاده مهم است، مثلا در پخش های زنده یا بازی های آنلاین که کاربر باید با کمترین تاخیر سرویس خود را دریافت کند یا سایر پلتفرم ها که سرویس آنلاین و فوری می دهند.
اما فرق TCP Load Balancer با UDP Load Balancer در چیست؟
بزرگترین تفاوت بین آنها نحوه ردیابی داده ها است. TCP انتقال و دریافت داده ها را با سفارش و شماره گذاری data packet ها تضمین می کند. سپس گیرنده تحویل data packet را تأیید می کند. یک TCP Load Balancer همچنین بسته های داده را برای خطا بررسی می کند.
یک TCP Load Balancer مطمئن تر است زیرا داده ها در هنگام انتقال ردیابی می شوند تا اطمینان حاصل شود که هیچ گونه گم شدن یا خرابی اطلاعاتی صورت نگرفته.
در حالی که:
یک UDP Load Balancer فقط داده را ارسال می کند و هیچ تأییدی در مورد دریافت وجود ندارد.پس هیچ ردیابی خطایی هم در کار نیست و تمام داده ها ، چه داده های خراب و چه داده های سالم، به سادگی وارد می شوند. نکته ترسناک اینجاست که اگر داده ها روی سرورهای UDP از بین رفته باشند، راهی برای یافتن آنها وجود ندارد. البته عدم تأیید صحت داده ها سبب می شود تا عمل load balancing سریع تر انجام شود و زمانی که صرف تایید صحت داده ها می شود ذخیره شود.
ابزار NGINX Plus همچنین می تواند برنامه های TCP مانند MySQL و برنامه های UDP مانند DNS و RADIUS را به تعادل برساند. ابزار NGINX Plus اتصالات TCP را خاتمه می دهد و اتصالات جدیدی را به backend ایجاد می کند.
ابزار NGINX Web application firewall در حقیقت یک فایروال مبتنی بر ModSecurance 3.0 است.NGINX WAF می تواند برای متوقف کردن طیف گسترده ای از حملات لایه ی 7 و پاسخ به تهدیدات جدید با وصله ی مجازی استفاده شود!
توجه: قبل از هر توضیح دیگری لازم است تا با یکسری مفاهیم به طور مختصر آشنا شویم !
اول باید با مفهومی بنام firewall آشنا می شویم:
خب Firewall یا دیوار آتش چیست؟
چه کاری انجام می دهد؟
به زبان ساده Firewall اولین خط دفاعی در امنیت شبکه قلمداد می شود و در شبکه کار کنترل و نظارت بر ترافیکی که دریافت و یا فرستاده می شود را انجام می دهد، حال این شبکه می تواند یک شبکه خصوصی که از تعداد کمی دستگاه تشکیل شده باشد، می تواند بزرگترین شبکه ی جهان یعنی اینترنت باشد. این کنترل و نظارت منطبق بر مجموعه ای از قوانین انجام می گیرد که در ادامه، بیشتر راجع به آنها توضیح می دهیم.
در ضمن Firewall ها می توانند به صورت نرم افزاری، سخت افزاری و یا هر دو، وجود داشته باشند.
مدل (Open System Interconnection):
در سال 1980، سازمان استاندارد سازی، مدل OSI را معرفی کرد، در این مدل ارتباطات میان دستگاه های یک شبکه، بدون در نظر گرفتن اینکه از چه تکنولوژی هایی در آنها استفاده شده است، به هفت لایه تقسیم بندی شده است:
7. لایه ی کاربرد – فراهم کردن رابط برای سایر لایه ها از طریق دادن دسترسی به نرم افزار ها برای استفاده از منابع شبکه.
6. لایه ی نمایش – این لایه وظیفه فشرده سازی، وافشاری، رمزنگاری و رمزگشایی داده را بر عهده دارد و داده را در لایه کاربرد نمایش می دهد.
5. لایه ی نشست – این لایه اطمینان حاصل می کند که داده درخواست شده در شبکه به همان برنامه درخواست کننده برسد و میان برنامه ها پخش نمی شود.
4. لایه ی انتقال – در این لایه است که با استفاده از پروتکل های TCP و UDP، داده در شبکه از یک دستگاه به دستگاه دیگری ارسال می شود.
3. لایه ی شبکه – این لایه با مشخص کردن مکان دستگاه ها در شبکه مسیر داده ها برای رسیدن به دستگاه مربوطه را مشخص می کند. پروتکل های IP و IPv6 در این لایه مورد استفاده قرار می گیرند.
2. لایه ی پیوند داده – این لایه با استفاده از آدرس سخت افزاری MAC عمل انتقال فیزیکی داده را انجام داده و آن را به بیت هایی جهت انتقال در لایه ی فیزیکی تبدیل می کند.
1. لایه ی فیزیکی – در این لایه انتقال داده در پایین ترین سطح یعنی سیگنال ها و بیت ها انجام می شود، مانند استفاده از ولتاژ low و high.
خب Web Application Firewall و تفاوت آن با Network Firewall:
اما Network Firewall ها در لایه های 3 و 4 مدل OSI قرار می گیرند و همانطور که گفته شد کاربرد اصلی آنها نظارت و کنترل درخواست ها و ترافیک داخل شبکه می باشد، این عمل نظارت و کنترل در Network Firewall ها بر اساس اطلاعات پروتکلی درخواست ها انجام می شود.
به بیان دیگر، تمرکز فیلتر هایی که برای اجازه، قطع و کنترل دسترسی ها در Network Firewall ها وجود دارند، بر روی مجموعه قوانینی (Rule Sets) می باشد که در آن IP Range ها، پورت های TCP و UDP، انواع ICMP و ... تعریف شده است، که برخی اجازه دسترسی دارند و به برخی دیگر اجازه داده نمی شود.
برای مثال یک Network Firewall را در نظر بگیرید که در Rule Set آن قانونی تعیین کرده ایم که به IP های از قبل تعیین شده، اجازه دسترسی به پورت TCP 80 و یا 443 را بدهد، حال اگر یک IP که در قانون ذکر نشده است اقدام به اتصال به پورت 80 کند، Network Firewall از آن جلوگیری می کند.
اما Network Firewall ها یک مشکل اساسی داشتند، اگر درخواستی طبق Rule Set اجازه دسترسی داشت ولی در محتوای درخواست اطلاعات مخربی بود چطور؟ برای مثال حملاتی همچون HTTP Flood، Slow Loris و حملات لیست شده در OWASP Top 10، رفتار یک درخواست HTTP مشروع را از خود نشان می دهند و چون هدف اصلی آنها برنامه ها وب می باشد و نه خود شبکه، Network Firewall با توجه به Rule Set تعریف شده و ماهیت طراحی خود، قادر به جلوگیری و متوقف کردن اینگونه حملات نمی باشد.
در نتیجه نیاز به حضور Firewall هایی که بصورت جداگانه و انحصاری به اینگونه حملات رسیدگی و از بروز آنها جلوگیری کنند، منجر به ایجاد WAF ها شد.
قبل از پرداختن به WAF ها نیاز داریم تعریفی از Reverse Proxy ها داشته باشیم، Reverse Proxy یا پراکسی معکوس، یک سرور است که برخلاف پراکسی های معمولی که جلوی یک و یا گروهی از کاربران قرار می گیرند، در جلوی یک و یا گروهی از سرور ها قرار گرفته و درخواست های کاربران به سرور ها را در لبه ی شبکه قطع کرده و آن ها را از جانب سرور ها دریافت می کند. از کاربرد های پراکسی معکوس می توان به: Load Balancing، حافظه پنهان سازی یا Caching، محافظت از سرور ها در مقابل حملات، اشاره کرد که نهایتاً به بالا بردن امنیت، عملکرد و اطمینان پذیری سرور ها کمک می کنند.
در واقع Web Application Firewall یک نوع Reverse Proxy می باشند که در مدل OSI در لایه های 3 تا 7 کار کرده و با قرار گرفتن بین یک و یا چندین برنامه وب و ترافیک ورودی، از بروز حملاتی که هدف آنها منحصراً لایه ی هفتم است، جلوگیری می کند.
در‌واقع WAF ها با فیلتر کردن، بررسی و آنالیز محتوای درخواست های HTTP می توانند درخواست هایی را که ممکن است حاوی کد های مخرب باشند را از رسیدن به برنامه وب باز می دارند و حملاتی که Network Firewall ها توان مقابله با آنها را نداشتند، در همان سطح WAF و خارج از برنامه وب متوقف کرده و به آنها اجازه گذر نخواهند داد.
یکی از راه های جالبی که می توان از WAF ها استفاده کرد، دادن نقش بافر مانند به آن است، به شکل که برنامه وبی را در نظر بگیرید که در آن باگ امنیتی کشف شده و هر لحظه امکان سو استفاده از آن توسط مهاجمان وجود دارد و رفع این مشکل ممکن است زمان بر باشد، در نتیجه می توان در WAF قانونی را تعریف کرد که دسترسی تمام ترافیک ورودی به قسمتی که دارای مشکل است قطع کند و به نحوی آن را ایزوله کند، بدون اینکه دیگر بخش های برنامه وب از دسترس خارج شود، در این مدت توسعه دهندگان می توانند مشکل را برطرف کنند.
عمل فیلتر کردن درخواست ها مخرب توسط WAF همچون دیگر Firewall ها از طریق مجموعه قوانین از قبل تعیین شده انجام می پذیرد، این Rule Set ها هستند که به WAF می گویند که در چه بخش هایی از درخواست های HTTP به دنبال چه چیزی بگردند و چه قسمت هایی را مخرب تشخیص دهند.
این Rule Set ها در WAF با استفاده از سه مدل، پیاده سازی می شوند:
اول: Whitelisting (لیست سفید) : در این روش WAF بصورت پیشفرض تمامی درخواست ها را متوقف کرده و تنها به درخواست هایی اجازه گذر می دهد که از قبل ثابت شده هستند، و از طرف IP هایی آمده اند که به آنها اطمینان داریم.
این روش از منابع کمتری نسبت به روش لیست سیاه استفاده می کند اما نکته منفی آن این است امکان جلوگیری از درخواست هایی که مشکل امنیتی نداشته زیاد است و کاملا دقیق نمی باشد.
دوم: Blacklisting (لیست سیاه): این روش برخلاف روش لیست سفید، بصورت پیشفرض به تمامی درخواست های ورودی اجازه گذر می دهد و تنها از عبور درخواست هایی جلوگیری کرده که طبق الگو های تعیین شده، مخرب تشخیص داده شوند
این روش برای برنامه های وبی که مخاطبان زیادی دارند مناسب است، زیرا اینگونه برنامه ها درخواست های بسیاری از IP های ناشناخته دریافت می کنند و استفاده از روش لیست سفید در اینجا کارآمد نیست، نکته منفی این روش وابستگی زیاد آن به منابع است.
سوم: Hybrid Security (امنیت ترکیبی): در این روش عنصر هایی از هر دو روش لیست سفید و لیست سیاه با هم تلفیق شده و استفاده می شوند.
گفتیم که تمرکز WAF ها بیشتر بر روی حملات لایه هفتم است، این لیست شامل چه حملاتی می شود و آیا از حملات دیگری جلوگیری می شود؟
در ادامه چند مورد از حملاتی را ذکر می کنیم که می توان از WAF برای مقابله و جلوگیری
از آنها استفاده کرد:
حملات Distributed Denial of Service => Ddos
حملات SQL Injection
حملاتCross-Site Scripting <=XSS
حملات Zero-day
حملات Business Logic
حملات Man-in-the-middle
بدافزار ها
و Defacement ها
خب WAF ها بطور کلی به سه گروه دسته بندی می شوند:
اول Network-Based WAFs : این نوع از WAF ها بر روی شبکه محلی و تا جای ممکن نزدیک به برنامه نصب می شوند و اکثر آنها منطبق بر سخت افزار می باشند، به همین دلیل تاخیر بسیار کمی را در پردازش درخواست ها فراهم می کنند. اینگونه از WAF ها همراه با هزینه بالا خرید و نگهداری می باشند.
دوم Host-Based WAFs : اینگونه از WAF ها اکثراً به عنوان ماژول هایی برای وب سرور ها به وجود آمده اند، و هزینه بسیار کمتری نسبت به Network-Based ها ارائه
می دهند. هرچند نرم افزاری بودن این نوع از WAF ها به استفاده بیشتر از منابع سرور و کاهش کارایی منجر شود...
سوم Cloud-Hosted WAFs : در این نوع از WAF ها، همان داشتن هزینه پایین و نیاز نداشتن به نگهداری محلی که درباره Host-Based ها بیان شد، مشاهده می شود، اما برخلاف آنها از منابع بسیار کمتری برای پیاده سازی و مدیریت استفاده می کند و در بیشتر موارد تنها به یک DNS و یا تغییر پروکسی برای راه اندازی و Redirect کردن ترافیک برنامه وب، به خود نیاز دارد.
در نهایت می توان نتیجه گرفت که WAF ها نقشی اساسی در مدل امنیتی برنامه های وب ایفا می کنند که توسط Network Firewall ها قابل جبران نیست. البته لازم به ذکر است که WAF به هیچ عنوان جایگزینی برای Network Firewall ها نمی باشد، بلکه می توان گفت که مکمل یکدیگر می باشند و همواره پیشنهاد می شود که از هر دو آنها استفاده شود.
نیاز به وجود WAF چه در راه حل های امنیتی شرکت های بزرگ و سازمان ها و چه در برنامه های وب کوچک و شخصی احساس شده و با توجه به افزایش سرسام آور آمار حملات به برنامه های وب در لایه هفتم، به نوعی ضرورت تبدیل شده است.
و این مطلب ادامه دارد...
با تشکر از شما!
