Firewall和流量過濾

（部分： 技術和基礎設施）

簡短的摘要

Faervol不是外圍的一個盒子，而是從L3-L4到L7的分層過濾模型：雲安全組/NACL，Kubernetes中的網絡策略，egress控制（出口），WAF和邊緣機器人管理以及mTLS/來源真實性服務到服務。對於iGaming來說，關鍵是保護支付流和遊戲提供商，地理策略，DNS控制和可觀察性（誰，何時，何時）。

1）目標和原則

Default deny：默認情況下不允許,我們允許最低要求。
深度防禦：在外圍、雲、群集和應用程序中具有相同的策略。
Egress-first：輸出流量與輸入流量相同的風險（PSP、遊戲提供商、郵件、分析師）。
身份>地址：在可能的情況下,我們通過身份（mTLS/Spiffe）進行授權,而不是裸露的IP。
可觀察性和審計：決策邏輯（allow/deny），跟蹤，事件相關性。

2）過濾圖層

1.Edge：CDN/WAF/DDoS/機器人保護，L7規則，TLS終端。
2.雲：VPC/子網/VM 級別的安全組/NACL/Firewall規則。
3.集群：Kubernetes NetworkPolicy，帶有mTLS和L7過濾器的服務-mesh（Envoy/Istio）。
4.主機：iptables/nftables/ufw, agent eBPF過濾器。
5.附錄：rate-limit/idempotency/WAF附錄，egress域列表。
6.DNS： split-horizon、allowlist resolver、風險域/類型塊。

3）外圍： WAF，DDoS和機器人管理

WAF：API下的基本簽名+定制規則（JSON方案，方法/內容類型）。
機器人：行為得分，設備指紋，異常時的動態卡普查。
DDoS：L3/4（轉/突觸）和L7（HTTP floods）-自動丟棄到邊緣。
Geo/ASN：將區域/自主系統限制在風險目的地（例如admin面板）。

示例（NGINX+ModSecurity，JSON-API的想法）：

nginx
Разрешаем только JSON POST/GET на /api/
location /api/ {
limit_req zone=rl_api burst=50 nodelay;
if ($request_method!~ ^(GET    POST)$) { return 405; }
if ($http_content_type!~ "application/json") { return 415; }
proxy_pass http://api_upstream;
}
ModSecurity CRS + собственные правила modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/crs.conf;

4）雲： 安全組和NACL

安全組（stateful）-跨端口/協議/段的過濾器。
NACL（無狀態）是粗網狀子網過濾。

API的示例（有條件YAML）SG：

yaml security_group:
name: api-sg ingress:
- proto: tcp; port: 443; cidr: 0.0.0.0/0 # через CDN/WAF egress:
- proto: tcp; port: 443; cidr: 203.0.113.0/24  # PSP-X
- proto: tcp; port: 443; cidr: 198.51.100.0/24 # ProviderA
- proto: udp; port: 53; cidr: 10.10.0.10/32  # только наш DNS

實踐：在特定的PSP/遊戲提供商中保留單獨的 SG和egress-allowlist的付款。更新-通過IaC和咆哮。

5） Kubernetes： NetworkPolicy和service-mesh

NetworkPolicy限制了群集中的L3/4；默認情況下,「每個人都與所有人交談」-關閉。

Deny-all+只允許使用：

yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: { name: deny-all, namespace: prod }
spec:
podSelector: {}
policyTypes: [Ingress, Egress]
ingress: []
egress: []
---
Разрешаем API разговаривать с платежным сервисом и DNS apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: { name: api-allow-specific, namespace: prod }
spec:
podSelector: { matchLabels: { app: api } }
policyTypes: [Ingress, Egress]
egress:
- to:
- namespaceSelector: { matchLabels: { name: prod } }
podSelector: { matchLabels: { app: payments } }
ports: [{ protocol: TCP, port: 8080 }]
- to:
- ipBlock: { cidr: 10.10.0.10/32 }
ports: [{ protocol: UDP, port: 53 }]

服務-mesh（Istio/Linkerd/Consul）添加：

mTLS無處不在（身份驗證服務而不是IP）。
L7過濾器（方法/主機/路徑/標題），電路斷路器，outlier-ejection。
服務憑證/Spiffe ID訪問策略。

示例（Istio AuthorizationPolicy的想法）：

yaml apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: { name: api-to-payments, namespace: prod }
spec:
selector: { matchLabels: { app: payments } }
action: ALLOW rules:
- from:
- source:
principals: ["spiffe://prod/ns/prod/sa/api-sa"]
to:
- operation:
methods: ["POST"]
paths: ["/deposit","/withdraw"]

6）主機faervols： iptables/nftables/eBPF

nftables示例（statful，deny-all）：

nft table inet filter {
sets {
psp { type ipv4_addr; elements = { 203.0.113.10, 203.0.113.11 } }
}
chains {
input { type filter hook input priority 0; policy drop;
ct state established,related accept iifname "lo" accept tcp dport {22,443} accept
}
output { type filter hook output priority 0; policy drop;
ct state established,related accept udp dport 53 ip daddr 10.10.0.10 accept  # только наш DNS tcp dport 443 ip daddr @psp accept    # egress к PSP
}
forward { type filter hook forward priority 0; policy drop; }
}
}

eBPF代理（Cilium等）產生微妙的L3-L7策略和可見性（flows，DNS，HTTP元數據）。

7） Egress控制和目的地目錄

異議域列表/IP用於外部調用（PSP，郵件，KYC，遊戲提供商）。
DNS 定位/SNI策略：僅通過受信任的resolver；禁止原始IP egress。
分開的VPC/VNet egress用於支付，遊戲和共享輪廓。
非PII流量具有TLS檢查的代理；支付流-沒有MITM，只有直接mTLS/PII-safe。

8） TLS/mTLS和密碼政策

TLS 1.2+，現代密碼，OCSP stapling，HSTS。
內部的mTLS-綁定到Spiffe ID/服務認證。
定期輪換證書和驗證信任鏈。
L7代理上的CORS/CSP切入前線的攻擊源。

9）限額和L7配額

IP/ASN/前綴的邊緣限制；應用限制-通過身份（帳戶/tenant/密鑰）。
Idempotency-keys用於POST支付操作，以免中繼創建倍數。
Leaky/Token bucket帶有叮當聲；降解-「灰色響應「/kapcha/減速。

10） DNS安全性

只允許使用企業級反火器（VPC反火器/提升的CoreDNS）。
Split-horizon：內部名稱不會在外面響起。
一組有害的TLD/類別，禁止將DoH/DoT從下擺中移出。
通過異常（新域，常見NXDOMAIN）進行查詢和排序。

11） Logi、可觀察性和測試

Faervols標誌（allow/deny，規則，字節），WAF審計，DNS標誌→ SIEM/SOAR。
Exemplars：帶有「trace_id」的鎖定度量→快速跳入問題請求的軌道。
合成：定期檢查來自所需地區的PSP/遊戲提供商的可用性。
網絡混沌測試：packet loss、RTT、DNS錯誤-檢查規則響應和自動還原。

12）自動化和IaC

所有規則都像代碼（Terraform/Ansible/Helm/Kyverno/Gatekeeper）一樣。
使用安全策略（OPA）進行全面請求。
測試和註釋：任何規則更改都會標記在圖表上。
金絲雀變化：逐步推出網絡策略（namespace/label，5-10% pods）。

13） iGaming的細節

支付路線（PSP）：單獨的egress組，嚴格的allowlist，代碼監控/時間表。
遊戲提供商：whitelisting CDN域,防止突然重定向。

地理規則： 符合當地限制,區域塊在邊緣.

Backoffice/KYC：僅從受信任的網絡/通過bastion+MFA訪問。
Phrod：對L7的速度限制以及對異常源API的「嚴重」請求。

14）快速規則的例子

UFW（主機）

bash ufw default deny incoming ufw default deny outgoing ufw allow 22/tcp ufw allow 443/tcp ufw allow out to 10.10.0.10 port 53 proto udp ufw allow out to 203.0.113.0/24 port 443 proto tcp

Istio EnvoyFilter（禁止非標準方法，想法）

yaml typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router до роутера — Lua/Match для блокировки методов not in [GET,POST,OPTIONS]

NGINX rate-limit

nginx limit_req_zone $binary_remote_addr zone=rl_api:10m rate=10r/s;
server {
location /api/ { limit_req zone=rl_api burst=50 nodelay; proxy_pass http://api; }
}

15）實施支票

1.雲層（SG/NACL）、群集（NetworkPolicy）和主機級別的默認降級。
2.Egress-allowlist到PSP/提供程序，僅通過受信任的DNS進行解析。
3.邊緣的WAF/機器人管理/DDoS，REST/JSON下的L7規則和下載。
4.服務之間的mTLS，身份授權（Spiffe/SA）。
5.Edge和App上的rate-limit/quotas，用於付款的idempotency-keys。
6.DNS策略：禁止DoH/DoT, split-horizon, Loging。
7.Logs和SIEM：集中的集合allow/deny/WAF/DNS,異常變量。
8.IaC過程：規則代碼，公關評論，金絲雀滾動，註釋。
9.測試/混亂：RTT/loss/DNS故障、後退路由和自動腳本檢查。
10.定期修訂：審核未使用的規則，輪換PSP/CDN地址。

16）反模式

「打開一切，希望WAF」--外圍不會挽救國內交通。
缺少egress 控制是用於泄漏/C2的燈向外隧道。
Kubernetes中的Allow-all NetworkPolicy-保證橫向移動。
在動態CDN/PSP世界中僅通過IP 過濾而無需域/DNS控制。
內部唯一沒有mTLS的TLS終端點是替代服務。
在沒有IaC/審核的情況下手動編輯銷售規則-不可生產性和債務。
Faervol logi「無處可去」-沒有可觀察性，它只是「黑匣子」。

三.成果

有效的流量過濾是平臺的架構結構：從edge-WAF和基於雲的SG到NetworkPolicy和mTLS，在集群內對PSP/提供商進行嚴格的 egress控制，並通過IaC進行管理。這樣的系統可以降低泄漏和攻擊的風險，在SLO內保留付款和遊戲，並通過全面的審計和可觀察性幫助快速調查事件。

Firewall和流量過濾

簡短的摘要

UFW（主機）

Istio EnvoyFilter（禁止非標準方法，想法）

NGINX rate-limit

三.成果

與我們聯繫

快速聯繫

影片即將更新

我們目前正忙於各項專案