🔔 آسیب‌پذیری بحرانی در وب‌سرور Nginx

وب‌سرور Nginx در هسته‌ی خود از یک زبان اسکریپتی با نام Njs پشتیبانی می‌کند که به کاربران اجازه‌ی گسترش کارکرد nginx (مثل دستکاری سرآیندهای پاسخ و کنترل دسترسی‌های یک درخواست HTTP قبل از اینکه به سرور بالادستی برسد) را می‌دهد.
به نظر می‌رسد در ساختار این زبان، باگ‌های خطرناکی همچون Integer Overflow وجود دارد که تخریب حافظه Heap را در بر می‌دارد. این تهدید به مهاجمین امکان توسعه‌ی اکسپلویت و دسترسی از راه دور را فراهم می‌آورد. پیشنهاد موکد می‌شود که در اسرع وقت نسبت به به‌روزرسانی، اقدامات لازم انجام شود.
#security #nginx @unixmnes

زمانیکه تعداد کاربران سایت بیشتر میشود و ترافیک سایت افزایش می‌یابد عموما یک نمونه ( instance ) از برنامه نمیتواند پاسخگوی همه درخواست‌ها باشد و مجبور هستیم چندین نمونه برنامه را بر روی چند سرور اجرا کنیم. با این حال نیازمند یک وب سرور هستیم که درخواست‌های ارسال شده را در بین instance های موجود پخش کند. با انجام این کار تعداد ریکوئست‌ها در بین instance ها تقسیم میشوند. برای انجام اینکار میتوانیم از nginx استفاده کنیم. nginx قابلیت load balancing را دارد. برای پیاده سازی load balancing در nginx باید در فایل nginx.conf یک گروه از نوع upstream ایجاد کنید در کانتکست http.

http {
upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
}

در کانفیگ بالا یک گروه به نام backend ایجاد کرده‌ایم ...

#nginx #proxy #reverseproxy #reverse_proxy #load #loadbalancing #load_balancing

نحوه کامپایل ماژول های 3rd party در nginx , nginx plus

https://www.nginx.com/blog/compiling-dynamic-modules-nginx-plus/


#nginx

HIGH-
PERFORMANCE
CACHING
with NGINX & NGINX Plus

#nginx #performance

@unixmens

#nginx #nginx_plus #nginxplus #devops #devsecops #netops #appdev

ا nginx و ماژول های آن و پیاده سازی naxsi

#security #waf #nginx #naxsi #yashar_esmaildokht #linux #centos

ا nginx و ماژول های آن و پیاده سازی naxsi

#security #waf #nginx #naxsi #yashar_esmaildokht #linux #centos

NGINX Cookbook


#nginx #book

@unixmens

HIGH-
PERFORMANCE
CACHING
with NGINX & NGINX Plus

#nginx #performance

@unixmens

#nginx #nginx_plus #nginxplus #devops #devsecops #netops #appdev

ا nginx و ماژول های آن و پیاده سازی naxsi

#security #waf #nginx #naxsi #yashar_esmaildokht #linux #centos

NGINX Cookbook - Advanced Recipes for High-Performance Load Balancing

#nginx #linux #net #book

https://t.me/unixmens

Mastering NGINX
An in-depth guide to configuring NGINX for any
situation, including numerous examples and
reference tables describing each directive

#linux #nginx #network #web #book
https://t.me/unixmens

▎Introduction

Health checks are vital for ensuring high availability and fault tolerance in web applications. NGINX, a powerful web server, provides various methods for implementing health checks. This guide explores how to configure NGINX for both active and passive health checks, enhancing the robustness and reliability of your services.

▎What are Health Checks?

Health checks are tests conducted by load balancers or reverse proxies to assess if a backend server can handle requests. Active health checks proactively test servers at regular intervals, while passive health checks monitor ongoing traffic and flag servers as unhealthy when errors exceed a specified threshold.

▎Active Health Checks

Here's a basic configuration for active health checks in NGINX:

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
        check interval=3000 rise=2 fall=5 timeout=1000 type=http;
        check_http_send "HEAD /health HTTP/1.1rnHost: localhostrnConnection: closernrn";
        check_http_expect_alive http_2xx http_3xx;
    }

    server {
        location / {
            proxy_pass http://backend;
        }
    }
}

In this setup, NGINX sends a HEAD request to the /health endpoint every 3 seconds. A server is deemed healthy if it returns a 2xx or 3xx HTTP status code twice in succession (rise=2). If it fails to respond correctly 5 times consecutively (fall=5), it is marked unhealthy.

▎Passive Health Checks

For passive health checks, NGINX analyzes live traffic. Here’s the configuration:

stream {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com max_fails=2 fail_timeout=30s;
    }

    server {
        listen 80;
        proxy_pass backend;
        proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
    }
}

In this configuration, if a backend server fails to respond correctly twice within 30 seconds (max_fails=2, fail_timeout=30s), it is temporarily removed from the pool. The proxy_next_upstream directive specifies which errors will trigger a retry with a different server.

▎Advanced Health Check Configurations

For more complex scenarios, consider this advanced configuration using shared memory zones and custom failure detection:

http {
    upstream backend {
        zone backend 64k;
        server backend1.example.com;
        server backend2.example.com;

        health_check
        match=healthy
        interval=2000
        fails=3
        passes=1
        uri=/custom_check;
    }

    match healthy {
        status 200-399;
    }

    server {
        location / {
            proxy_pass http://backend;
            proxy_set_header Host $host;
        }
    }
}

This example includes a health_check block that conducts checks every 2 seconds, with specific conditions for failing and passing. The status codes that indicate a healthy server are defined in a separate match block labeled healthy.

▎Testing and Troubleshooting Health Checks

To verify your health checks, use NGINX’s logging capabilities:

server {
    location / {
        proxy_pass http://backend;
        access_log /var/log/nginx/backend_access.log;
        error_log /var/log/nginx/backend_error.log;
    }

    location /health {
        access_log /var/log/nginx/health_access.log;
        proxy_pass http://backend;
    }
}

By directing access logs for the health check endpoint to a separate file, you can easily monitor their status. The error log is useful for troubleshooting any issues.

▎Automating Health Checks with NGINX Plus

NGINX Plus users benefit from dynamic health checks and an intuitive dashboard for management. The configuration process is straightforward:

[Continue with configuration details specific to NGINX Plus.]





#nginx #ha #load #balancing #linux #net

https://t.me/unixmens

NGINX as kubernetes #ingress #controller

#devops #kubernetes #nginx #linux #network

https://t.me/unixmens

ماژول stream در Nginx یکی از ماژول‌های قدرتمند و در عین حال کمتر شناخته‌شده است که برای پراکسی کردن (proxying) ترافیک لایه‌ی چهارم (TCP/UDP) به کار می‌رود. برخلاف ماژول http که برای سرویس‌های لایه‌ی هفتم طراحی شده، ماژول stream مخصوص لایه‌ی انتقال است (لایه چهارم در مدل OSI).
🎯 کاربرد اصلی Stream Module

ا Load Balancing برای دیتابیس‌ها (مثل MySQL, PostgreSQL)

ا TCP-level reverse proxy (مثلاً برای SSH، Redis، MQTT)

پراکسی کردن ترافیک UDP (مثل DNS، VoIP)

ساخت TLS passthrough proxy (برخلاف termination در http)

استفاده به عنوان ورودی برای SSL offloading

🧩 فعال‌سازی ماژول Stream

ماژول stream به‌طور پیش‌فرض در نسخه‌های pre-built رسمی Nginx فعال نیست. برای استفاده از آن باید:

از نسخه‌ی Nginx Plus استفاده کنید
یا

از سورس با --with-stream کامپایل کنید

بررسی فعال بودن:

nginx -V 2>&1 | grep -- --with-stream

📜 نمونه پیکربندی
✅ پراکسی TCP ساده

stream {
    upstream backend {
        server 192.168.1.10:3306;
        server 192.168.1.11:3306;
    }

    server {
        listen 3306;
        proxy_pass backend;
    }
}

✅ پراکسی UDP

stream {
    server {
        listen 53 udp;
        proxy_pass 8.8.8.8:53;
    }
}

ا ✅ SSL passthrough برای mail server

stream {
    map $ssl_preread_server_name $backend {
        mail.example.com   mail_backend:993;
        default            default_backend:993;
    }

    server {
        listen 993;
        proxy_pass $backend;
        ssl_preread on;
    }
}

نکته: قابلیت ssl_preread در stream شبیه SNI sniffing در TLS است.

⚙️ دستورات مهم Stream Module

proxy_pass  تعریف مقصد
upstream  تعریف سرورهای backend
listen  تعریف پورت/پروتکل ورودی
ssl_preread  فعال‌سازی خواندن SNI بدون decryption
proxy_timeout  تایم‌اوت بین Nginx و سرور مقصد
proxy_connect_timeout  تایم‌اوت برای اتصال اولیه
proxy_protocol  فعال‌سازی PROXY protocol (برای انتقال IP کلاینت)

📌 محدودیت‌ها


امکان دستکاری محتوا وجود ندارد (چون لایه ۴ است)

نمی‌توان از rewrite, headers, gzip, cache استفاده کرد

لاگ‌گیری محدود به connection-level است، نه request-level

🧠 جمع‌بندی

ماژول stream در Nginx به شما اجازه می‌دهد به‌جای لایه‌ی اپلیکیشن (HTTP)، روی لایه‌ی انتقال (TCP/UDP) تمرکز کنید و خدماتی مانند load balancing، SSL passthrough، reverse proxy برای سرویس‌های غیروبی ارائه دهید. این قابلیت برای طراحی زیرساخت‌های حرفه‌ای بسیار حیاتی است، به‌خصوص در محیط‌هایی مثل:

ا Kubernetes ingress برای TCP/UDP

انتقال ترافیک دیتابیس‌ها

پیاده‌سازی reverse proxy با امنیت بالا

🎯 امکانات ماژول stream در NGINX

پشتیبانی از TCP و UDP Reverse Proxy

ا Load Balancing برای TCP/UDP با الگوریتم‌های:

ا round-robin (پیش‌فرض)

ا least_conn (در نسخه Plus)

ا hash-based routing

پشتیبانی از Health Checks (در نسخه NGINX Plus)

ا SSL Passthrough با قابلیت ssl_preread

ا SNI-based Routing بدون decrypt کردن TLS

پشتیبانی از PROXY Protocol (برای انتقال IP کلاینت)

کنترل دسترسی با allow / deny

لاگ‌گیری سفارشی برای TCP/UDP connections

تنظیم Timeoutهای مختلف:

proxy_timeout

proxy_connect_timeout

پشتیبانی از متریک‌های ساده‌ی اتصال

تعریف upstream blocks برای backend سرورها

🧠 کاربردهای ماژول stream

پراکسی و Load Balancing برای دیتابیس‌ها (PostgreSQL, MySQL, Redis)

ا SSL passthrough برای HTTPS با SNI routing

پراکسی سرویس‌های VoIP و UDP-based (مانند RTP، SIP)

ا Reverse Proxy برای DNS (TCP و UDP)

پراکسی و مسیردهی ترافیک mail servers (IMAP, POP3, SMTP)

ا Bastion SSH Host برای هدایت کاربران SSH به سرورهای مختلف

پراکسی برای پروتکل‌های خاص TCP مانند MQTT، FIX، یا custom protocols

استفاده در Kubernetes Ingress Controller برای TCP/UDP Services




#nginx #stream #linux #network

https://t.me/unixmens