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-horizo​​n、allowlist resolver、风险域/类型块。

3）外围： WAF，DDoS和机器人管理

WAF：API下的基本签名+定制规则（JSON方案，方法/内容类型）。
机器人：行为得分，设备指纹，异常时的动态卡普查。
DDoS：L3/4（转/突触）和L7（HTTP floods）-自动丢弃到边缘。
Geo/ASN：将区域/自主系统限制在风险目的地（例如admin面板）。

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（无状态）是粗网状子网过滤。

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；默认情况下,"每个人都与所有人交谈"-关闭。

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 }]

• mTLS无处不在（身份验证服务而不是IP）。
• L7过滤器（方法/主机/路径/标题），电路断路器，outlier-ejection。
• 服务凭证/Spiffe ID访问策略。

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

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-horizo​​n：内部名称不会在外面响起。
一组有害的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内保留付款和游戏，并通过全面的审计和可观察性帮助快速调查事件。