Firewall და ტრაფიკის ფილტრაცია

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

Faervol არ არის ერთი ყუთი პერიმეტრზე, არამედ ფენიანი ფილტრაციის მოდელი L3-L4- დან L7- მდე: ღრუბლოვანი უსაფრთხოება Groups/NACL, ქსელის პოლიტიკა Kubernetes- ში, egress კონტროლი (გარეთ გასასვლელი), WAF და edge bot მენეჯმენტი, და MTTTTLLs ჭეშმარიტება მომსახურების მომსახურებისთვის. IGaming- ისთვის მთავარია გადახდის ნაკადების დაცვა და თამაშის პროვაიდერები, გეო-პოლიტიკა, DNS კონტროლი და დაკვირვება (ვინ, სად, როდის და რატომ).

1) მიზნები და პრინციპები

Default deny: აკრძალულია, ჩვენ ვუშვებთ მინიმალურ საჭიროებას.
Defense-in-depth: იგივე პოლიტიკოსები პერიმეტრზე, ღრუბელში, კლასტერში და განაცხადში.
Egress-first: გამომავალი ტრაფიკი იგივე რისკია, როგორც შეყვანა (PSP, თამაშების პროვაიდერები, ფოსტა, ანალიტიკა).
პირადობა> მისამართი: სადაც შესაძლებელია, ჩვენ ავტორიზაციას ვაძლევთ იდენტურობას (mTLS/Spiffe) შიშველი IP- ის ნაცვლად.
დაკვირვება და აუდიტი: გადაწყვეტილებების ლოგიკა (allow/deny), კვალი, კორელაცია ინციდენტებთან.

2) ფილტრაციის ფენების რუკა

1. Edge: CDN/WAF/DDoS/bot დაცვა, L7 წესები, TLS ტერმინალი.
2. ღრუბელი: Security Groups/NACL/Firewall Rules VPC/ქვესადგურების/VM დონეზე.
3. მტევანი: Kubernetes NetworkPolicy, Mesh Mesh (Envoy/Istio) mTLS და L7 ფილტრებით.
4. მასპინძელი: iptables/nftables/ufw, აგენტის eBPF ფილტრები.
5. პროგრამა: rate-limit/idempotence/WAF in-app, egress დომენების სიები.
6. DNS: split-horizon, allowlist რეზერვისტები, რისკის დომენების ბლოკი/ტიპები.

3) პერიმეტრი: WAF, DDoS და ბოტანიკური მენეჯმენტი

WAF: ძირითადი ხელმოწერები + კასტომიური წესები API- სთვის (JSON სქემები, მეთოდები/შინაარსის ტიპი).
ბოტები: ქცევითი მორიელი, მოწყობილობა fingerprint, დინამიური ქუდი ანომალიებში.
DDoS: L3/4 (ვოლიუმი/სინაფსი) და L7 (HTTP floods) - edge ავტომატური გადაყრა.
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) ღრუბელი: Security Groups და NACL

Securiteful Group (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

პრაქტიკა: გადახდისთვის, შეინახეთ ინდივიდუალური SG და egress-allowlist სპეციფიკური PSP/თამაშის პროვაიდერები. განახლებები - IaC- ით და შურისძიებით.

5) Kubernetes: 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) მასპინძელი farervols: 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 პოლიტიკას და ხილვადობას (ყვავილები, DNS, HTTP მეტამონაცემები).

7) Egress კონტროლი და დანიშნულების კატალოგები

Allowlist დომენები/IP გარე გამოწვევებისთვის (PSP, ფოსტა, KYC, თამაშების პროვაიდერები).
DNS pinning/SNI პოლიტიკა: რეზერვაცია მხოლოდ ენდობა რეზერვუარის საშუალებით; აკრძალეთ ნედლეული IP-egress.
ცალკეული VPC/VNet egress გადახდის, თამაშის და ზოგადი კონტურების მისაღებად.
TLS შემოწმების მარიონეტული არა-PII ტრეფიკისთვის; გადახდის ნაკადები - MITM- ის გარეშე, მხოლოდ პირდაპირი mTLS/PII-safe.

8) TLS/mTLS და კრიპტოპოლიტიკა

TLS 1. 2 +, თანამედროვე შიფრები, OCSP stapling, HSTS.
შიგნით mTLS არის Spiffe ID/სერვისის ანგარიშების სერტიფიკაცია.
სერთიფიკატების რეგულარული როტაცია და ნდობის ჯაჭვების შემოწმება.
CORS/CSP L7- ზე, ფრონტზე თავდასხმის წყაროების მოსაშორებლად.

9) Rate-limit და L7 კვოტები

Edge ლიმიტები IP/ASN/პრეფიქსი; დანართი ლიმიტები - იდენტურობით (ანგარიში/ტენანტი/გასაღები).
Idempotence-keys POST გადახდის ოპერაციებისთვის ისე, რომ retrais არ შექმნან დუბლი.
ლეიკი/ტოკენ ბუკეტი ჯიტერთან; დეგრადაციის დროს - „ნაცრისფერი პასუხები „/კაპჩა/შენელება.

10) DNS უსაფრთხოება

ნებადართულია მხოლოდ კორპორატიული რეზერვები (VPC resolver/ამაღლებული CoreDNS).
Split-horizon: შიდა სახელები არ იშლება გარეთ.
მავნე TLD/კატეგორიების ბლოკი, DoH/DoT აკრძალვა ქვესადგურებიდან.
მოთხოვნა და ალერტინგი ანომალიებში (ახალი დომენები, ხშირი NXDOMAIN).

11) ლოგები, დაკვირვება და ტესტირება

Faerwall- ის ლოგოები (allow/deny, წესები, ბაიტი), WAF აუდიტი, DNS ლოგები - SIEM/SOAR.
Exemplars: 'trace _ id' საკეტების მეტრიკა - სწრაფი გადახტომა პრობლემური მოთხოვნის ტრასაზე.
სინთეზური: PSP/თამაშის პროვაიდერების ხელმისაწვდომობის რეგულარული შემოწმება სასურველი რეგიონებიდან.
ქსელის ქაოსის ტესტები: packet loss, RTT, DNS შეცდომები - ჩვენ ვამოწმებთ წესებისა და მანქანის რემედიაციის რეაქციას.

12) ავტომატიზაცია და IaC

ყველა წესი კოდია (Terraform/Ansible/Helm/Kyverno/Gatekeeper).
Pull-request-review უსაფრთხოების პოლიტიკოსებთან (OPA).
ვერსია და ვიდეო: წესების ნებისმიერი ცვლილება აღინიშნება გრაფიკებზე.
კანარის ცვლილებები: თანდათანობით გააფართოვოს ქსელის პოლიტიკოსები (namespace/label, 5-10% სუბსიდიები).

13) iGaming სპეციფიკა

გადახდის მარშრუტები (PSP): ცალკეული egress ჯგუფები, მკაცრი allowlist, კოდების/ტაიმაუტების მონიტორინგი.
თამაშების პროვაიდერები: CDN დომენების whitelisting, დაცვა მოულოდნელი რედაქციებისგან.
გეო წესები: ადგილობრივი შეზღუდვების შესაბამისობა, რეგიონების ბლოკები edge.
Backoffice/KYC: წვდომა მხოლოდ სანდო ქსელებიდან/bastion + MFA- ს საშუალებით.
Frode: velocity ლიმიტები 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. Default deny ღრუბლის დონეზე (SG/NACL), მტევანი (ქსელის პოლიტიკა) და მასპინძლები.
2. Egress-allowlist in PSP/პროვაიდერები, რომლებიც მხოლოდ ენდობიან DNS- ს.
3. WAF/bot მენეჯმენტი/DDoS edge, L7 წესები REST/JSON და ჩამოტვირთვა.
4. mTLS სერვისებს შორის, პირადობის მოწმობა (Spiffe/SA).
5. Rate-limit/ítas edge და განაცხადში, idempotence-keys გადახდისთვის.
6. DNS პოლიტიკოსები: აკრძალვა DoH/DoT, split-horizon, ლოგიკა.
7. ლოგოები და SIEM: ცენტრალიზებული ალოუ/დენის/WAF/DNS შეგროვება, ანომალიების ალერტები.
8. IaC პროცესები: წესების კოდი, PR review, კანარის მონაცვლეობა, ვიდეო.
9. ტესტები/ქაოსი: RTT/loss/DNS ჩავარდნები, fallback მარშრუტების და ავტო სკრიპტების შემოწმება.
10. რეგულარული აუდიტი: გამოუყენებელი წესების აუდიტი, PSP/CDN მისამართების როტაცია.

16) ანტი შაბლონები

„ყველაფრის გახსნა და WAF- ის იმედი“ - პერიმეტრი არ დაზოგავს შიდა ტრაფიკს.
Egress კონტროლის არარსებობა - მილის გვირაბი გარეთ გაჟონვისთვის/C2.
Allow-all NetworkPolicy Kubernetes- ში - გვერდითი მოძრაობა გარანტირებულია.
მხოლოდ IP ფილტრაცია დინამიური CDN/PSP სამყაროში დომენის კონტროლის გარეშე/DNS.
TLS ტერმინალის ერთადერთი წერტილი შიგნით mTLS- ის გარეშე არის მომსახურების შეცვლა.
IaC/აუდიტის გარეშე გაყიდვის წესების სახელმძღვანელო რედაქტირება არის არაპროგნოზირებადი და დავალიანება.
Faervol- ის ლოგოები „არსად“ - დაკვირვების გარეშე, ეს უბრალოდ „შავი ყუთია“.

შედეგები

ეფექტური ტრაფიკის ფილტრაცია არის პლატფორმის არქიტექტურული ქსოვილი: edge-WAF და ღრუბლოვანი SG- დან NetworkPolicy და mTLS კლასტერში, მკაცრი egress კონტროლით PSP/პროვაიდერებზე და IaC- ის საშუალებით კონტროლირებად. ასეთი სისტემა ამცირებს გაჟონვისა და შეტევების რისკს, ინახავს გადასახადებსა და თამაშებს SLO- ს ფარგლებში და ეხმარება სწრაფად გამოიძიოს ინციდენტები სრული აუდიტის და დაკვირვებების წყალობით.