شب ۲۷: ایمن‌سازی Traefik¶

بخش ۲۷ از مجموعهٔ آموزش Traefik در ۳۰ شب؛ هر جلسه برای ۶۰ تا ۹۰ دقیقه مطالعه، تمرین عملی، بررسی نتیجه و تمرین رفع خرابی طراحی شده است. مثال‌ها مطابق منبع با Traefik Proxy v3.7 نوشته شده‌اند؛ برای محیط عملیاتی نسخهٔ اصلاحی آزموده‌شده یا digest مشخصی را ثابت کنید. تمرین‌ها را روی میزبان یا کلاستر آزمایشگاهی اجرا کنید.

فهرست کامل دورهٔ ترافیک در ۳۰ شب

هدف‌های یادگیری¶

• کاهش سطح حملهٔ ارائه‌دهنده، محیط اجرا، شبکه، داشبورد و مسیریابی.
• اعتماد به هدرهای forwarded فقط از پراکسی‌های بالادستی شناخته‌شده.
• اعمال سیاست لایه‌ای درخواست و TLS با بررسی اثر آن بر برنامه‌ها.

تمرین عملی: خط پایهٔ راه‌اندازی و مسیریابی¶

entryPoints:
  websecure:
    address: ":443"
    forwardedHeaders:
      trustedIPs: ["10.10.0.0/16", "192.0.2.10/32"]
    proxyProtocol:
      trustedIPs: ["192.0.2.10/32"]
    transport:
      respondingTimeouts:
        readTimeout: 30s
        writeTimeout: 30s
        idleTimeout: 90s
providers:
  docker:
    exposedByDefault: false
    constraints: "Label(`edge.owner`,`platform`)"
api: {dashboard: true, insecure: false}

Proxy Protocol را فقط وقتی فعال کنید که بالادست مستقیم واقعاً آن را می‌فرستد. تنظیم نادرست ممکن است ترافیک را رد کند یا اطلاعات مبدأ جعلی را معتبر بداند.

http:
  middlewares:
    public-policy:
      chain: {middlewares: [request-cap, rate, headers]}
    request-cap:
      inFlightReq: {amount: 100}
    rate:
      rateLimit: {average: 50, burst: 100, period: 1s}
    headers:
      headers:
        contentTypeNosniff: true
        frameDeny: true
        referrerPolicy: strict-origin-when-cross-origin
        stsSeconds: 31536000
        stsIncludeSubdomains: true
tls:
  options:
    default:
      minVersion: VersionTLS12
      sniStrict: true

HSTS را فقط پس از اطمینان از کارکرد دائمی HTTPS روی تمام نام‌های میزبان تحت پوشش اعمال کنید؛ includeSubDomains می‌تواند زیردامنه‌های نامرتبط را مختل کند.

ss -lntup
docker inspect TRAEFIK_CONTAINER --format '{{json .HostConfig.SecurityOpt}}'
curl -I --resolve whoami.example.test:443:127.0.0.1 \
  --cacert certs/lab-ca.crt https://whoami.example.test/
openssl s_client -connect 127.0.0.1:443 -servername whoami.example.test -tls1_1 </dev/null
rg -n '(password|token|secret|BEGIN .*PRIVATE KEY|api\.insecure)' .

فهرست ایمن‌سازی¶

• Docker API فیلتر و احراز هویت دارد یا ریسک انتشار آن رسماً پذیرفته شده است؛ RBAC و ACL در Kubernetes و Nomad حداقل دسترسی را دارند.
• هرجا پلتفرم و راهبرد پورت اجازه می‌دهد، Traefik با کاربر غیر root، بدون capability اضافه، با فایل‌سیستم فقط‌خواندنی و سیاست seccomp، AppArmor یا SELinux اجرا می‌شود.
• شبکه‌ها و entrypointهای عمومی، خصوصی، پشت‌صحنه و مدیریت جدا هستند.
• داشبورد، API و متریک‌ها احراز هویت یا مجوز شبکه می‌خواهند.
• دامنهٔ ارائه‌دهنده به فعال‌سازی صریح و مالکیت محدود است.
• ایمیج و digest، فهرست اجزای نرم‌افزار یا SBOM و هشدارها، افزونه‌ها و وصله‌های پلتفرم پایه بازبینی شده‌اند.
• محدودیت نرخ، بدنه و هم‌زمانی با بارهای کاری مجاز آزموده شده است.

نکته‌های عیب‌یابی¶

• همهٔ کلاینت‌ها با IP متعادل‌کنندهٔ بار دیده می‌شوند: زنجیرهٔ اعتماد forwarded header ناقص است یا برنامه هدر دیگری می‌خواند.
• IP کلاینت جعل می‌شود: forwarded header در حالت insecure است یا CIDRهای مورد اعتماد بیش از حد گسترده‌اند.
• ورود یا callback پس از افزودن هدر خراب می‌شود: سیاست CSP، HSTS یا frame تعارض دارد؛ برای هر برنامه جداگانه اعمال و آزمایش کنید.
• پاسخ 429 زیر بار عادی: مدل نرخ و هم‌زمانی، تجمع پشت NAT، جهش بار یا درخواست طولانی را لحاظ نمی‌کند.

خودآزمایی¶

1. چرا اعتماد به تمام forwarded headerها ناامن است؟ کلاینت می‌تواند دادهٔ مبدأ و پروتکل مورد استفادهٔ احراز هویت، تغییرمسیر و لاگ را جعل کند.
2. چه چیزی باید داشبورد را محافظت کند؟ محدودیت شبکه همراه احراز هویت، مجوزدهی و TLS.
3. چرا میان‌افزار را برای هر برنامه می‌آزماییم؟ سیاست امنیتی با رفتار مجاز مرورگر و API تعامل دارد.
4. اثبات کنید: X-Forwarded-For جعلی از مبدأ نامطمئن نادیده گرفته می‌شود و TLS 1.1 شکست می‌خورد.