ვებ აპლიკაცია Firewall და თავდასხმებისგან დაცვა

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

WAF/WAAP ფილტრაციას უწევს და აკონტროლებს HTTP (S )/WebSocket ტრაფიკს განაცხადის დონეზე: ბლოკავს დაუცველების ოპერაციას (OWASP Top 10), ავტორიზაციის გვერდის ავლით, სკანირებით, ავტომატიზირებული ბო-ტრაფიკით და L7 DDDDoS oS oS oS - ით. თანამედროვე დასტის ავსებს ანტი-ბოტი ძრავა, API დაცვა, სიმტკიცე, ვირტუალური პატჩები, ასევე CI/CD- სთან მჭიდრო ინტეგრაცია ისე, რომ წესები უსაფრთხოა, როგორც კოდი.

როლები და ადგილი არქიტექტურაში

Edge/CDN WAF (ღრუბელი): დაბალი ლატენტობა, გლობალური რეპუტაცია/მმართველი Rules, L7 DDoS.
Self-hosted WAF (on-prem/K8s): ღრმა ინტეგრაცია შიდა ქსელებთან, თხელი კონფიგურაცია.
WAAP მიდგომა: WAF + API-Gateway ფუნქციები (schema-validation, authZ), ანტი-ბოტი, L7 DoS, mTLS.
ჩართვის სქემები: Reverse-proxy განაცხადის წინ; Ingress კონტროლერი K8s; Service Mesh ფილტრები; sidecar.

თავდაცვის მოდელი

ნეგატიური უსაფრთხოება (ხელმოწერები/CRS): ცნობილი ტექნიკის სწრაფი გაშუქება (SQLI/XSS/SSRF/RCE).
პოზიტიური უსაფრთხოება: ჩვენ ვუშვებთ მხოლოდ „ნამდვილ“ მოთხოვნებს (მეთოდები/მარშრუტები/სქემები/შინაარსის ტიპები).
ვირტუალური პატჩინგი: ექსპოზიციის ოპერატიული ბლოკირება fix კოდამდე.
კონტექსტურობა: სხვადასხვა პოლიტიკა სტატიკური შინაარსისთვის, API, ადმირალები, დატვირთვები, ვებჰუკები.

ტიპიური საფრთხეები და ზომები

OWASP Top 10: SQLI, XSS, IDOR/BOLA, SSRF, ინექციები შაბლონიზატორებში, დესერიალიზაციაში, მოსკონფიგებში.
L7 DDoS: ნელი მოთხოვნები/სათაურები, ბურსტი ცხელ ენდოინტებზე - დაცვა: rate-limits, challenge, ავტო-ბლოკი.
ბოტები/სკრეიპერები: ქცევა, სიხშირე, „არაადამიანური“ ნიმუშები, მოწყობილობები-fingerprinting, დინამიური ნიშნები.
Credential Stuffing/ATO: ლოგინების ჩარევა/გადამოწმება IP/ASN, velocity rules, დამატებითი ფაქტორები.
ჩატვირთვა: ტიპი/ზომა/მულტიკანი ანტივირუსული, „გამოსახულება-მხოლოდ“ მედია ზონებში.
API/GraphQL: schema-validation, 'maxDepth '/' maxCost ", უცნობი ველური ბარათების აკრძალვა, მეთოდებისა და სათაურების კონტროლი.

პოლიტიკა და წესების დიზაინერები

ნებისმიერი განაცხადის ძირითადი „ჩონჩხი“:

1. ტრანსპორტი: TLS 1. 2+/1. 3, HSTS, mTLS მგრძნობიარე ზურგჩანთებზე.

2. მეთოდები: ალოუ-სია ('GET, POST, PUT, DELETE, PATCH, OPTIONS') უნიკალურია რესურსისთვის.

3. ბილიკები: მკაცრი ნიღბები/რეჯექსები; ადმინკა/ბილინგი - ცალკე პრეფიქსი/დომენისთვის.

4. სათაურები: თეთრი სიები, საშიში აკრძალვა („X-Original-URL“, არასტანდარტული) საჭიროების გარეშე.

5. ცხედრები: JSON-only/მრავალფუნქციური გზა მარშრუტის გასწვრივ; Limites 'Content-Length', ბინარული ბლოკი „ლოგინი/ძებნა“.

6. Rate limits: per-IP/ASN/გასაღები/ორგანიზაცია; ცალკეული ლიმიტები „ძვირადღირებული“ მოთხოვნებისთვის.

7. ანტი-ბოტი: ქცევითი სკორინგი, „განუყოფელი“ ჩელენჯი, იდენტურობის წებოვანი (ქუქი-ნიშნები, JA3/TLS FP).

8. CRS/მენეჯერი Rules: ჩართულია, tuning FP- ის ქვეშ.

9. Virt Patchi: ცნობილი პარამეტრების/თავდასხმის შაბლონების სწრაფი დაბლოკვა.

10. Logs/მეტრიკა: ერთი ფორმატი, კორელაცია „trace _ id“, მოხსენებები FP/TP.

Tuning პრაქტიკა: როგორ შევამციროთ ყალბი სამუშაო

დაიწყეთ ახალი წესები Detect-only/Count-mode (shadow) ტრაფიკის ნიმუშით.
გამონაკლისების შექმნა კონტექსტით ('path =/search', 'param = q' სპეციალური სიმბოლოების დაშვება).
გაზიარეთ ზონა: „საზოგადოებრივი გვერდები“ „მგრძნობიარე ოპერაციები“ (აგრესიულობის ბარიერი სხვადასხვა).
კონვეიერი: stajing-canareika (1-5%) - prod; rollback FP მეტრებში.
„ყალბი“ payload- ის კატალოგის ჩატარება რეგრესიული ტესტებისთვის.

ინტეგრაცია DevSecOps- ში

CI: სტატიკური წესები Git- ში; ტესტები: რეალური თხოვნების ფრაგმენტები + სინთეზური შეტევების კატალოგიდან.
CD: კანარის გამოთვლები, ფიჩების დროშები; „პოლიტიკური“ მონიტორინგი (წესების ცვლილება = change).
RASP და SAST/DAST: WAF ავსებს, მაგრამ არ ცვლის კოდის კორექტირებას.

დაკვირვება და SLO

მეტრიკა:

p95/99 ლატენტობა WAF- ის საშუალებით; დაბლოკილი/გამოტოვებული წილი; share Managed Rules vs custom; «attack rate».
ანტი-ბოტი: ჩელენჯის/გადაცემის წილი, FP/TP.
L7 DDoS: burst-rate, auto-mitigation events.

SLO მაგალითები:

"არა უმეტეს 0. 5% FP უფლებამოსილ ოპერაციებზე/დღეში."
«p95 overhead WAF ≤ 10 мс».
„TTR ვირტუალური პატჩი 30 წუთი“.
ალარმები: წესების გამოშვების შემდეგ 4xx/5xxx- ის ზრდა; ზრდა FP; ხაფანგის გავლის ვარდნა; JWKS/MTLS სავალდებულო დეგრადაცია.

კონფიგურაციის მაგალითები

ModSecurity + OWASP CRS (Nginx)

nginx
Enabling ModSecurity modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main. conf;

`/etc/nginx/modsec/main. conf`:

apache
SecRuleEngine On
Include /usr/local/owasp-modsecurity-crs/crs-setup. conf
Include /usr/local/owasp-modsecurity-crs/rules/.conf

Example of an exception for a search parameter
SecRule REQUEST_URI "@beginsWith /search" "id:900100,phase:1,pass,nolog,ctl:ruleRemoveByTag=attack-xss"
SecRule REQUEST_URI "@beginsWith /search" "id:900101,phase:2,pass,ctl:ruleRemoveTargetById=942100; ARGS:q"

AWS WAF (JSON, rate limit + ქვეყნების სიის ბლოკი)

json
{
"Name": "prod-web-acl",
"Scope": "CLOUDFRONT",
"DefaultAction": { "Allow": {} },
"Rules": [
{
"Name": "BurstLogin",
"Priority": 1,
"Statement": {
"RateBasedStatement": {
"Limit": 100,
"AggregateKeyType": "IP",
"ScopeDownStatement": { "ByteMatchStatement": {
"SearchString": "/login",
"FieldToMatch": { "UriPath": {} },
"TextTransformations": [{ "Priority": 0, "Type": "NONE" }],
"PositionalConstraint": "CONTAINS"
}}
}
},
"Action": { "Block": {} },
"VisibilityConfig": { "MetricName": "BurstLogin", "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true }
}
]
}

Cloudflare (Expression Rules)


(http. request. uri. path contains "/admin" and ip. geoip. country ne "UA")
or (http. request. uri. path eq "/login" and cf. threat_score > 10)
or (http. request. uri. path contains "/api" and not http. request. headers["authorization"][0] contains "Bearer ")

NGINX: მარტივი წესი მეთოდების/ორგანოების მიხედვით

nginx location /api/withdraw {
limit_except POST { deny all; }
if ($request_method = POST) {
set $cl $http_content_length;
if ($ cl = "") {return 411;} # length is required if ($ cl> 1048576) {return 413;} # ≤ 1MB add_header X-Idempotency-Required "true";
}
}

GraphQL: შეზღუდვები

'maxDepth = 6', 'maxCost = 1000', აკრძალვა '_ _ schema' გაყიდვაში, allow-list ოპერაციების, სათაურების შესაბამისობა ('Content-Type: Application/json').

ანტი-ბოტი და მეგობრული შემოწმებები

Invisible challenge (JS-Challenge გარეშე challenge), proof-of-work „ძვირადღირებულ“ მარშრუტებზე, ქცევითი ანალიტიკა (მოძრაობები/ტაიმინგი).
TLS/JA3-fingerprinting, IP/ASN რეპუტაცია, მარიონეტული/VPN სიები (გონივრულ ფარგლებში).
ხაფანგები (honeypot ველები) ფორმებზე, ფორმის/სესიის დინამიური ნიშნები.
კონფიდენციალურობის დაცვა: ტრეკინგის შემცირება, გამჭვირვალე პოლიტიკოსები, opt-out ვარიანტები.

API ხრიკი

Schema-first: OpenAPI/JSON Schema ხელმისაწვდომობისთვის; ზედმეტი მინდვრების აკრძალვა.
Auth: აუცილებლად Bearer JWT ან mTLS; reject без `Authorization`.
Rate/Quota: per-key/per-org; ჭარბი - „რბილი ბლოკი „/slowing.
Webhooks: HMAC ხელმოწერა, 'timestamp + nonce', მოკლე მისაღები ფანჯარა.
GraphQL: იხ. უფრო მაღალი შეზღუდვები; ოპერაციის სახელი/ნიშანი.

დატვირთვა და მედია

ზომების ლიმიტი, whitelists MIME/გაფართოება, ფაილების შეცვლა;

AV სკანი (მრავალ ძრავა), ImageMagick პოლიტიკა (საშიში დეკოდირების გარეშე);

Thumb სერვისი ცალკეულ დომენზე, serve-only-images.

ადმირალებისა და კრიტიკული ზონების უსაფრთხოება

ცალკე დომენი/გზა, mTLS/აკრძალვა საერთო ASN/ქვეყნებიდან, მკაცრი ზღვარი, JIT წვდომა, IP ალოუ-სია.
დამატებითი სიგნალები (მოწყობილობის შეტყობინება, risk score) მეორე შემოწმების მოთხოვნით.

ოპერაციები, ინციდენტები და ვირტუალური პატჩი

Runbook: block წესების სწრაფი გამოშვება, TTL შეზღუდვა, ბრძანების შეტყობინება.
დაბრუნების კრიტერიუმები: 4xx/5xx> ბარიერი, FP> ბარიერი, p95 ლატენტობა.
Post-mortem: ტესტის დამატება რეგრესიულ წესებში, SIGMA ალერტის დაფიქსირება SIEM- ში.

შესაბამისობა და კონფიდენციალურობა

გააკეთეთ მინიმალური: გზა/მეთოდი/კოდი/ბლოკის მიზეზი/იდენტიფიკატორი; არ შეინახოთ PII/სხეულის საიდუმლოებები.
პოლიტიკის ლოგოების შენახვის ვადები; წვდომა - როლებზე; დაშიფვრა დისკზე.

მახასიათებლები iGaming/fintech

გადახდა/გადახდა/საფულე: per-org კვოტები, mTLS PSP, მკაცრი ალოუ ფურცლები, HMAC PSP ვებჰუკებისთვის.
ATO/ბონუს აბიუსი: velocity წესები ლოგინის/რეგისტრაციისთვის/სარეკლამო კოდებისთვის, ქცევითი ლიმიტები და ანტი-ბოტი.
შინაარსის პროვაიდერები/სტუდიები: ინდივიდუალური დომენები/პოლიტიკა, IP/ASN allow-list, Time-to-Wallet/კონვერტაციის მონიტორინგი WAF- ის გავლენაზე.
რეგიონალური მოთხოვნები: გეო-პოლიტიკა (ქვეყნები/რეგიონები), GDPR- ის დამუშავების გამჭვირვალობა.

გზის განხორციელების რუკა

1. ზონების ინვენტარიზაცია (საზოგადოებრივი, API, adminka, ჩამოტვირთვა).
2. ძირითადი პროფილი: TLS, allow-list მეთოდები/გზები, მენეჯმენტი Rules/CRS.
3. Rate limits + ანტი-ბოტი მგრძნობიარე გზებზე.
4. ვირტუალური პატჩი და გადაუდებელი წესების პროცესი (SLA - 30 წთ).
5. CI/CD წესებისთვის, stajing/canarey/shadow-mode.
6. ტელემეტრია, SLO, რეგრესიული ტესტები.
7. გამონაკლისის პერიოდული მიმოხილვა და შემოვლითი „გაწმენდა“.

ტიპიური შეცდომები

„ყველა CRS ჩართულია მაქსიმუმ“ - FP ზვავი და გუნდის დამწვრობა.
წესები კანარის და shadow რეჟიმის გარეშე.
სეგმენტის ნაკლებობა: ერთი პოლიტიკა ყველაფრისთვის.
API/GraphQL სპეციფიკის უგულებელყოფა (schema/limits).
ლოგოები კორელაციის გარეშე („trace _ id“) და ხარისხის მეტრიკის გარეშე.

FAQ

WAF ცვლის უსაფრთხო კოდს?
არა. ეს არის შემსუბუქების ფენა და „ვირტუალური პატჩი“, მაგრამ კოდის ტექნიკური მოვალეობა უნდა აღმოიფხვრას.

როგორ გავიგოთ, რომ დროა ჩართოთ მკაცრი ბლოკები?
როდესაც Shadow რეჟიმის ანგარიში აჩვენებს დაბალ FP- ს და არსებობს რეგრესიული წესების ტესტები.

საჭიროა ცალკე WAF API- სთვის?
უკეთესია WAAP/ინტეგრაცია API კარიბჭესთან: სქემა, ლიმიტები, ავთენტიფიკაცია, ვებჰუკების ხელმოწერები.

შედეგი

ეფექტური WAF/WAAP არის ძირითადი CRS/მენეჯმენტის Rules კომბინაცია, პოზიტიური მოდელი, ანტი-ბოტი, ლიმიტები და ვირტუალური პატჩი, რომელსაც მხარს უჭერს DevSecOps პროცესები, ტელემეტრია და მკაფიო SLO. ეს მიდგომა უზრუნველყოფს სწრაფ რეაქციას დაუცველობაზე, ავტომატიზირებული შეტევების წინააღმდეგობას და პროგნოზირებულ გავლენას UX- ზე და პროდუქტიულობაზე.