<\/span><\/h3>\nModSecurity kural\u0131 (genellikle SecRule<\/b> direktifi ile ba\u015flar), gelen veya giden HTTP trafi\u011finin belirli bir b\u00f6l\u00fcm\u00fcn\u00fc incelemek, bu b\u00f6l\u00fcm \u00fczerinde bir veya daha fazla ko\u015ful uygulamak ve bu ko\u015fullar e\u015fle\u015fti\u011finde belirli bir eylemi tetiklemek i\u00e7in tasarlanm\u0131\u015f bir talimatt\u0131r. Basit\u00e7e ifade etmek gerekirse, her kural “E\u011fer bu ko\u015ful do\u011fruysa, \u015funu yap” mant\u0131\u011f\u0131yla \u00e7al\u0131\u015f\u0131r. \u00d6rne\u011fin, bir istek parametresinde “SELECT * FROM” gibi bir SQL enjeksiyon ifadesi varsa, bu iste\u011fi engellemek i\u00e7in bir kural yaz\u0131labilir.<\/p>\n<\/span>Bir Kural\u0131n Bile\u015fenleri: Direktifler, De\u011fi\u015fkenler, Operat\u00f6rler ve Eylemler<\/span><\/h3>\nHer ModSecurity kural\u0131 d\u00f6rt ana bile\u015fenden olu\u015fur. Bu bile\u015fenler, kural\u0131n neyi, nerede, nas\u0131l kontrol edece\u011fini ve sonu\u00e7 olarak ne yapaca\u011f\u0131n\u0131 tan\u0131mlar.<\/p>\n
\n
\n\n\n| Bile\u015fen<\/th>\n | A\u00e7\u0131klama<\/th>\n | \u00d6rnek<\/th>\n<\/tr>\n<\/thead>\n |
\n\nDirektif (Directive)<\/strong><\/td>\nKural\u0131n t\u00fcr\u00fcn\u00fc ve nas\u0131l \u00e7al\u0131\u015faca\u011f\u0131n\u0131 belirten ana komuttur. En yayg\u0131n direktif SecRule<\/code>‘dur.<\/td>\nSecRule<\/code>, SecRuleUpdateTargetById<\/code><\/td>\n<\/tr>\n\nDe\u011fi\u015fkenler (Variables)<\/strong><\/td>\n| HTTP iste\u011finin hangi b\u00f6l\u00fcm\u00fcn\u00fcn incelenece\u011fini belirtir. \u00d6rne\u011fin, URL, istek g\u00f6vdesi, \u00e7erezler veya belirli bir parametre.<\/td>\n | REQUEST_URI<\/code>, ARGS<\/code>, REQUEST_COOKIES<\/code>, REQUEST_HEADERS<\/code><\/td>\n<\/tr>\n\nOperat\u00f6rler (Operators)<\/strong><\/td>\n| De\u011fi\u015fken \u00fczerinde hangi mant\u0131ksal kontrol\u00fcn yap\u0131laca\u011f\u0131n\u0131 tan\u0131mlar. Genellikle d\u00fczenli ifadeler (regular expressions) kullan\u0131l\u0131r.<\/td>\n | @rx<\/code> (RegEx e\u015fle\u015fmesi), @eq<\/code> (e\u015fitlik), @contains<\/code> (i\u00e7erir)<\/td>\n<\/tr>\n\nEylemler (Actions)<\/strong><\/td>\n| Operat\u00f6r\u00fcn ko\u015fulu sa\u011fland\u0131\u011f\u0131nda ne yap\u0131laca\u011f\u0131n\u0131 belirtir. Bu, iste\u011fi engellemek, loglamak, ba\u015fka bir kurala ge\u00e7mek gibi i\u015flemler olabilir.<\/td>\n | deny<\/code>, log<\/code>, pass<\/code>, chain<\/code>, id<\/code>, msg<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/span>Kural Zincirleri (Chaining Rules) ve Mant\u0131\u011f\u0131<\/span><\/h3>\nBazen tek bir ko\u015ful, karma\u015f\u0131k bir sald\u0131r\u0131 modelini tespit etmek i\u00e7in yeterli olmayabilir. \u0130\u015fte bu noktada kural zincirleri devreye girer. Bir kural\u0131n eylemlerine `chain`<\/b> eylemi eklendi\u011finde, bu kural\u0131n hemen ard\u0131ndan gelen kural bir \u00f6ncekiyle mant\u0131ksal bir “VE” (AND) ili\u015fkisi kurar. Zincirdeki t\u00fcm kurallar\u0131n ko\u015fullar\u0131 s\u0131rayla do\u011fru oldu\u011funda, zincirin en sonundaki kural\u0131n eylemleri tetiklenir. Bu, birden \u00e7ok ko\u015fulun ayn\u0131 anda sa\u011flanmas\u0131 gereken durumlar\u0131 (\u00f6rne\u011fin, belirli bir URL’ye yap\u0131lan istekte hem X hem de Y parametrelerinin \u015f\u00fcpheli i\u00e7erik ta\u015f\u0131mas\u0131) tespit etmek i\u00e7in g\u00fc\u00e7l\u00fc bir mekanizma sunar.<\/p>\n<\/span>A\u015fama (Phase) Kavram\u0131 ve HTTP \u0130stek Ya\u015fam D\u00f6ng\u00fcs\u00fcndeki Yeri<\/span><\/h3>\nModSecurity, bir HTTP iste\u011fini ba\u015f\u0131ndan sonuna kadar farkl\u0131 a\u015famalarda inceler. Bu a\u015famalar (Phases), bir kural\u0131n ne zaman \u00e7al\u0131\u015ft\u0131r\u0131laca\u011f\u0131n\u0131 belirler. Her a\u015fama, HTTP ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fcn belirli bir noktas\u0131na kar\u015f\u0131l\u0131k gelir. Bu yap\u0131, do\u011fru zamanda do\u011fru kontrol\u00fc yapmay\u0131 sa\u011flar. \u00d6rne\u011fin, istek ba\u015fl\u0131klar\u0131 (headers) tamamen al\u0131nd\u0131ktan sonra ba\u015fl\u0131klar\u0131 kontrol eden bir kural \u00e7al\u0131\u015ft\u0131rmak mant\u0131kl\u0131d\u0131r.<\/p>\n \n- Phase 1 (REQUEST_HEADERS):<\/strong> \u0130stek ba\u015fl\u0131klar\u0131 al\u0131nd\u0131ktan hemen sonra \u00e7al\u0131\u015f\u0131r.<\/li>\n
- Phase 2 (REQUEST_BODY):<\/strong> \u0130stek g\u00f6vdesi (POST verisi) al\u0131nd\u0131ktan ve i\u015flendikten sonra \u00e7al\u0131\u015f\u0131r.<\/li>\n
- Phase 3 (RESPONSE_HEADERS):<\/strong> Uygulamadan yan\u0131t ba\u015fl\u0131klar\u0131 olu\u015fturulduktan sonra, istemciye g\u00f6nderilmeden \u00f6nce \u00e7al\u0131\u015f\u0131r.<\/li>\n
- Phase 4 (RESPONSE_BODY):<\/strong> Yan\u0131t g\u00f6vdesi olu\u015fturulduktan sonra, istemciye g\u00f6nderilmeden \u00f6nce \u00e7al\u0131\u015f\u0131r.<\/li>\n
- Phase 5 (LOGGING):<\/strong> T\u00fcm i\u015flemler tamamland\u0131ktan ve loglama yap\u0131lmadan hemen \u00f6nce \u00e7al\u0131\u015f\u0131r.<\/li>\n<\/ul>\n
Bir kural\u0131n hangi a\u015famada \u00e7al\u0131\u015faca\u011f\u0131n\u0131 belirtmek, performans ve do\u011fruluk a\u00e7\u0131s\u0131ndan kritik \u00f6neme sahiptir. \u00d6rne\u011fin, dosya y\u00fcklemelerini analiz eden bir kural\u0131n Phase 2’de \u00e7al\u0131\u015fmas\u0131 gerekirken, bilgi s\u0131z\u0131nt\u0131lar\u0131n\u0131 kontrol eden bir kural\u0131n Phase 4’te \u00e7al\u0131\u015fmas\u0131 daha uygundur.<\/p>\n <\/span>OWASP Core Rule Set (CRS): End\u00fcstri Standard\u0131 Kural Seti<\/span><\/h2>\nModSecurity’yi tek ba\u015f\u0131na kurmak, g\u00fc\u00e7l\u00fc bir koruma sa\u011flamak i\u00e7in yeterli de\u011fildir. ModSecurity, bir motor gibidir; as\u0131l g\u00fcc\u00fcn\u00fc ve zekas\u0131n\u0131, ona ne yapaca\u011f\u0131n\u0131 s\u00f6yleyen kural setlerinden al\u0131r. Bu noktada, end\u00fcstri standard\u0131 haline gelmi\u015f olan OWASP Core Rule Set (CRS) devreye girer. CRS, ModSecurity’yi an\u0131nda etkili bir g\u00fcvenlik kalkan\u0131na d\u00f6n\u00fc\u015ft\u00fcren, topluluk taraf\u0131ndan geli\u015ftirilmi\u015f, kapsaml\u0131 ve s\u00fcrekli g\u00fcncellenen bir kural setidir.<\/p>\n <\/span>OWASP Core Rule Set Nedir ve Neden Kullan\u0131lmal\u0131d\u0131r?<\/span><\/h3>\nOWASP (Open Web Application Security Project), web uygulama g\u00fcvenli\u011fi konusunda fark\u0131ndal\u0131k yaratmay\u0131 ve standartlar olu\u015fturmay\u0131 ama\u00e7layan, kar amac\u0131 g\u00fctmeyen k\u00fcresel bir kurulu\u015ftur. OWASP Core Rule Set (CRS), bu projenin en ba\u015far\u0131l\u0131 \u00e7\u0131kt\u0131lar\u0131ndan biridir. CRS, bilinen bir\u00e7ok sald\u0131r\u0131 vekt\u00f6r\u00fcn\u00fc genel kal\u0131plarla tespit etmek ve engellemek i\u00e7in tasarlanm\u0131\u015f, ModSecurity ile uyumlu \u00fccretsiz bir kural setidir. S\u0131f\u0131rdan y\u00fczlerce kural yazma zahmetinden kurtararak, kan\u0131tlanm\u0131\u015f ve test edilmi\u015f bir g\u00fcvenlik taban\u0131 sunar. Bu nedenle, ModSecurity kullanan hemen hemen her sistemin temelini CRS olu\u015fturur.<\/p>\n <\/span>CRS’nin Kapsad\u0131\u011f\u0131 Ba\u015fl\u0131ca Sald\u0131r\u0131 T\u00fcrleri<\/span><\/h3>\nCRS, OWASP Top 10 listesinde yer alan zafiyetler ba\u015fta olmak \u00fczere, \u00e7ok geni\u015f bir yelpazedeki siber tehditlere kar\u015f\u0131 koruma sa\u011flar. Bu korumalar, katmanl\u0131 bir yap\u0131da sunulur ve uygulaman\u0131z\u0131 bir\u00e7ok farkl\u0131 a\u00e7\u0131dan g\u00fcvence alt\u0131na al\u0131r.<\/p>\n SQL Injection (SQLi) Korumas\u0131<\/h4>\nSald\u0131rganlar\u0131n web uygulamas\u0131 arac\u0131l\u0131\u011f\u0131yla veritaban\u0131na zararl\u0131 SQL komutlar\u0131 g\u00f6ndermesini engeller. CRS, SQL komutlar\u0131na \u00f6zg\u00fc anahtar kelimeleri (SELECT<\/code>, UNION<\/code>, DROP<\/code>), yorum karakterlerini (--<\/code>, #<\/code>) ve s\u0131k kullan\u0131lan sald\u0131r\u0131 kal\u0131plar\u0131n\u0131 HTTP istekleri i\u00e7inde arayarak SQLi giri\u015fimlerini tespit eder.<\/p>\nCross-Site Scripting (XSS) Korumas\u0131<\/h4>\nSald\u0131rganlar\u0131n, di\u011fer kullan\u0131c\u0131lar\u0131n taray\u0131c\u0131lar\u0131nda zararl\u0131 JavaScript kodlar\u0131 \u00e7al\u0131\u015ft\u0131rmas\u0131n\u0131 \u00f6nler. CRS, <script><\/code> etiketleri, olay dinleyicileri (onerror<\/code>, onload<\/code>) ve di\u011fer HTML\/JavaScript enjeksiyon tekniklerini i\u00e7eren istekleri filtreleyerek XSS sald\u0131r\u0131lar\u0131na kar\u015f\u0131 koruma sa\u011flar.<\/p>\nLocal File Inclusion (LFI) \/ Remote File Inclusion (RFI) Korumas\u0131<\/h4>\nUygulaman\u0131n, sunucudaki hassas yerel dosyalar\u0131 (\u00f6rn. \/etc\/passwd<\/code>) veya uzak sunuculardaki zararl\u0131 dosyalar\u0131 okumas\u0131n\u0131 veya \u00e7al\u0131\u015ft\u0131rmas\u0131n\u0131 engelleyen sald\u0131r\u0131 t\u00fcrleridir. CRS, dosya yolu ge\u00e7i\u015fi (..\/<\/code>) kal\u0131plar\u0131n\u0131 ve URL tabanl\u0131 dosya dahil etme giri\u015fimlerini izleyerek bu t\u00fcr zafiyetlerin s\u00f6m\u00fcr\u00fclmesini \u00f6nler.<\/p>\nCommand Injection Korumas\u0131<\/h4>\nSald\u0131rganlar\u0131n, web uygulamas\u0131 arac\u0131l\u0131\u011f\u0131yla temel i\u015fletim sisteminde keyfi komutlar (\u00f6rn. ls -la<\/code>, rm -rf<\/code>) \u00e7al\u0131\u015ft\u0131rmas\u0131n\u0131 engeller. CRS, i\u015fletim sistemi komutlar\u0131na \u00f6zg\u00fc karakterleri ve komutlar\u0131 tespit ederek bu tehlikeli sald\u0131r\u0131 t\u00fcr\u00fcne kar\u015f\u0131 bir savunma hatt\u0131 olu\u015fturur.<\/p>\nProtokol \u0130hlalleri ve K\u00f6t\u00fc Niyetli Bot Tespiti<\/h4>\nCRS sadece bilinen sald\u0131r\u0131 t\u00fcrlerini de\u011fil, ayn\u0131 zamanda standartlara uymayan veya \u015f\u00fcpheli davran\u0131\u015flar sergileyen trafikleri de hedefler. Ge\u00e7ersiz HTTP metotlar\u0131 kullanan, eksik veya hatal\u0131 ba\u015fl\u0131klar g\u00f6nderen istekleri ve agresif tarama yapan k\u00f6t\u00fc niyetli botlar\u0131 tespit ederek genel bir anomali tespiti sa\u011flar.<\/p>\n <\/span>Paranoya Seviyeleri (Paranoia Levels) ile G\u00fcvenlik Ayarlar\u0131n\u0131 Hassasla\u015ft\u0131rma<\/span><\/h3>\nHer web uygulamas\u0131 farkl\u0131d\u0131r ve tek bir g\u00fcvenlik seviyesi her senaryoya uymayabilir. CRS, bu sorunu “Paranoya Seviyeleri” (Paranoia Levels) ad\u0131 verilen zekice bir mekanizma ile \u00e7\u00f6zer. Bu seviyeler, kural setinin ne kadar kat\u0131 veya hassas olaca\u011f\u0131n\u0131 ayarlaman\u0131za olanak tan\u0131r:<\/p>\n \n- Paranoya Seviyesi 1 (PL1):<\/strong> Varsay\u0131lan seviyedir. Y\u00fcksek bir g\u00fcvenle k\u00f6t\u00fc niyetli olarak tan\u0131mlanabilen ve en az yanl\u0131\u015f alarm (false positive) \u00fcreten temel kurallar\u0131 i\u00e7erir.<\/li>\n
- Paranoya Seviyesi 2 (PL2):<\/strong> Daha fazla kural\u0131 etkinle\u015ftirir ve g\u00fcvenli\u011fi art\u0131r\u0131r, ancak me\u015fru baz\u0131 isteklerin de engellenme olas\u0131l\u0131\u011f\u0131n\u0131 (yanl\u0131\u015f alarm) y\u00fckseltir.<\/li>\n
- Paranoya Seviyesi 3 (PL3):<\/strong> Daha da kat\u0131 kurallar i\u00e7erir ve daha ezoterik sald\u0131r\u0131 tekniklerini engellemeyi hedefler. Bu seviyede yanl\u0131\u015f alarm olas\u0131l\u0131\u011f\u0131 belirgin \u015fekilde artar.<\/li>\n
- Paranoya Seviyesi 4 (PL4):<\/strong> En y\u00fcksek g\u00fcvenlik seviyesidir. Y\u00fcksek g\u00fcvenlik gerektiren ortamlar i\u00e7in tasarlanm\u0131\u015ft\u0131r ancak \u00f6nemli \u00f6l\u00e7\u00fcde yanl\u0131\u015f alarm y\u00f6netimi ve istisna tan\u0131mlamas\u0131 gerektirir.<\/li>\n<\/ul>\n
Paranoya seviyelerini art\u0131rmak, g\u00fcvenli\u011fi g\u00fc\u00e7lendirir ancak ayn\u0131 zamanda uygulaman\u0131n i\u015fleyi\u015fini etkileyebilecek yanl\u0131\u015f alarmlar\u0131n say\u0131s\u0131n\u0131 da art\u0131r\u0131r. Bu nedenle, do\u011fru seviyeyi se\u00e7mek ve istisnalar\u0131 dikkatle y\u00f6netmek esast\u0131r.<\/p>\n <\/span>Yanl\u0131\u015f Alarmlar (False Positives) ve \u0130stisna Y\u00f6netiminin \u00d6nemi<\/span><\/h2>\nModSecurity ve OWASP CRS gibi g\u00fc\u00e7l\u00fc g\u00fcvenlik ara\u00e7lar\u0131, web uygulamalar\u0131n\u0131 korumak i\u00e7in vazge\u00e7ilmezdir. Ancak, bu ara\u00e7lar\u0131n a\u015f\u0131r\u0131 hassas olmas\u0131, bazen zarars\u0131z ve me\u015fru kullan\u0131c\u0131 isteklerini de tehdit olarak alg\u0131lamalar\u0131na neden olabilir. “Yanl\u0131\u015f alarm” veya “false positive” olarak adland\u0131r\u0131lan bu durum, etkili bir WAF y\u00f6netiminin en zorlu y\u00f6nlerinden biridir. Bu b\u00f6l\u00fcmde, yanl\u0131\u015f alarmlar\u0131n ne oldu\u011funu, neden olu\u015ftuklar\u0131n\u0131 ve neden proaktif bir istisna y\u00f6netiminin kritik oldu\u011funu ele alaca\u011f\u0131z.<\/p>\n <\/span>Yanl\u0131\u015f Alarm (False Positive) Nedir ve Neden Olu\u015fur?<\/span><\/h3>\nBir yanl\u0131\u015f alarm (false positive), bir g\u00fcvenlik sisteminin (bu durumda ModSecurity) asl\u0131nda zarars\u0131z olan bir eylemi veya veri giri\u015fini hatal\u0131 bir \u015fekilde k\u00f6t\u00fc niyetli olarak tan\u0131mlamas\u0131 ve engellemesidir. \u00d6rne\u011fin, bir blog yaz\u0131s\u0131n\u0131n i\u00e7eri\u011finde <script><\/code> kelimesinin kod \u00f6rne\u011fi olarak ge\u00e7mesi, XSS filtresi taraf\u0131ndan ger\u00e7ek bir sald\u0131r\u0131 giri\u015fimi olarak alg\u0131lanabilir. Yanl\u0131\u015f alarmlar genellikle a\u015fa\u011f\u0131daki nedenlerden kaynaklan\u0131r:<\/p>\n\n- A\u015f\u0131r\u0131 Genel Kurallar:<\/strong> Baz\u0131 kurallar, bilinen sald\u0131r\u0131 kal\u0131plar\u0131n\u0131 yakalamak i\u00e7in \u00e7ok geni\u015f tan\u0131mlanm\u0131\u015f olabilir ve bu da me\u015fru kullan\u0131mlarla \u00e7ak\u0131\u015fabilir.<\/li>\n
- S\u0131ra D\u0131\u015f\u0131 Uygulama Davran\u0131\u015flar\u0131:<\/strong> Web uygulamas\u0131n\u0131n standart d\u0131\u015f\u0131 bir veri format\u0131 (\u00f6rne\u011fin, base64 ile kodlanm\u0131\u015f JSON) kullanmas\u0131, ModSecurity kurallar\u0131 taraf\u0131ndan anomali olarak yorumlanabilir.<\/li>\n
- Y\u00fcksek Paranoya Seviyeleri:<\/strong> OWASP CRS’de paranoya seviyesini art\u0131rd\u0131k\u00e7a, kurallar daha kat\u0131 hale gelir ve me\u015fru istekleri engelleme olas\u0131l\u0131\u011f\u0131 artar.<\/li>\n
- Zengin Metin Edit\u00f6rleri:<\/strong> Kullan\u0131c\u0131lar\u0131n i\u00e7erik girmesine olanak tan\u0131yan (WYSIWYG edit\u00f6rleri gibi) uygulamalar, s\u0131kl\u0131kla HTML etiketleri veya \u00f6zel karakterler i\u00e7erir ve bu da yanl\u0131\u015f alarmlara yol a\u00e7abilir.<\/li>\n<\/ul>\n
<\/span>Yanl\u0131\u015f Alarmlar\u0131n Uygulama Performans\u0131 ve Kullan\u0131c\u0131 Deneyimine Olumsuz Etkileri<\/span><\/h3>\nYanl\u0131\u015f alarmlar sadece teknik bir problem de\u011fil, ayn\u0131 zamanda i\u015f s\u00fcre\u00e7lerini ve kullan\u0131c\u0131 memnuniyetini do\u011frudan etkileyen ciddi bir sorundur. Me\u015fru bir kullan\u0131c\u0131n\u0131n bir formu g\u00f6nderememesi, bir makaleyi kaydedememesi veya bir \u00fcr\u00fcn\u00fc sepetine ekleyememesi, hayal k\u0131r\u0131kl\u0131\u011f\u0131na ve g\u00fcvensizli\u011fe yol a\u00e7ar. S\u00fcrekli olarak engellenen kullan\u0131c\u0131lar, web sitenizi terk edebilir ve bu da m\u00fc\u015fteri kayb\u0131, itibar zedelenmesi ve gelir d\u00fc\u015f\u00fc\u015f\u00fc anlam\u0131na gelebilir. Ayr\u0131ca, her yanl\u0131\u015f alarm, sistem y\u00f6neticilerinin zaman\u0131n\u0131 ve enerjisini alarak ger\u00e7ek tehditlere odaklanmalar\u0131n\u0131 zorla\u015ft\u0131r\u0131r.<\/p>\n <\/span>\u0130stisna (Exception\/Whitelisting) Y\u00f6netimi Neden Kritik Bir S\u00fcre\u00e7tir?<\/span><\/h3>\nG\u00fcvenlik ile kullan\u0131labilirlik aras\u0131nda bir denge kurmak zorunludur. Bir WAF’\u0131 sadece “a\u00e7\u0131p unutmak” m\u00fcmk\u00fcn de\u011fildir. \u0130stisna y\u00f6netimi, bu dengeyi kurman\u0131n anahtar\u0131d\u0131r. Yanl\u0131\u015f alarmlar\u0131 tamamen ortadan kald\u0131rmak i\u00e7in g\u00fcvenlik kurallar\u0131n\u0131 toptan devre d\u0131\u015f\u0131 b\u0131rakmak, kap\u0131y\u0131 sald\u0131rganlara ard\u0131na kadar a\u00e7mak anlam\u0131na gelir. Bunun yerine, istisna y\u00f6netimi ile hedefe y\u00f6nelik ve kontroll\u00fc bir yakla\u015f\u0131m benimsenir. Bu s\u00fcre\u00e7te, belirli bir kural\u0131n, belirli bir URL veya belirli bir parametre i\u00e7in devre d\u0131\u015f\u0131 b\u0131rak\u0131lmas\u0131 sa\u011flan\u0131r. Bu, genel g\u00fcvenlik seviyesini d\u00fc\u015f\u00fcrmeden, sadece sorun yaratan spesifik durumlar i\u00e7in bir “beyaz liste” (whitelist) olu\u015fturmakt\u0131r. Etkili bir istisna y\u00f6netimi olmadan, bir WAF ya i\u015flevsiz (\u00e7ok fazla yanl\u0131\u015f alarm nedeniyle) ya da etkisiz (\u00e7ok fazla kural devre d\u0131\u015f\u0131 b\u0131rak\u0131ld\u0131\u011f\u0131 i\u00e7in) hale gelir.<\/p>\n <\/span>ModSecurity’de Kural \u0130stisnas\u0131 Tan\u0131mlama Y\u00f6ntemleri<\/span><\/h2>\nYanl\u0131\u015f alarmlar\u0131 (false positives) tespit ettikten sonraki en \u00f6nemli ad\u0131m, bu sorunlar\u0131 genel g\u00fcvenli\u011fi zay\u0131flatmadan \u00e7\u00f6zmektir. ModSecurity, istisnalar\u0131 (exceptions) y\u00f6netmek i\u00e7in son derece esnek ve gran\u00fcler y\u00f6ntemler sunar. Bu y\u00f6ntemler, t\u00fcm bir kural\u0131 devre d\u0131\u015f\u0131 b\u0131rakmaktan, bir kural\u0131n sadece belirli bir parametreye uygulanmas\u0131n\u0131 engellemeye kadar geni\u015f bir yelpazeyi kapsar. \u0130\u015fte ModSecurity’de en s\u0131k kullan\u0131lan istisna tan\u0131mlama teknikleri.<\/p>\n <\/span>Kural ID’si Kullanarak Belirli Bir Kural\u0131 Pasif Hale Getirme (SecRuleRemoveById)<\/span><\/h3>\nEn basit ve en yayg\u0131n istisna y\u00f6ntemidir. Bir yanl\u0131\u015f alarma neden olan kural\u0131, benzersiz kimlik numaras\u0131 (ID) \u00fczerinden tamamen devre d\u0131\u015f\u0131 b\u0131rakman\u0131z\u0131 sa\u011flar. ModSecurity loglar\u0131n\u0131 inceledi\u011finizde, tetiklenen her kural\u0131n ID’sini g\u00f6rebilirsiniz. \u00d6rne\u011fin, loglarda 942100 ID’li kural\u0131n s\u00fcrekli olarak me\u015fru bir formu engelledi\u011fini fark ederseniz, a\u015fa\u011f\u0131daki direktifi kullanarak bu kural\u0131 pasif hale getirebilirsiniz:<\/p>\n SecRuleRemoveById 942100<\/code><\/p>\nBu y\u00f6ntem etkilidir ancak kural\u0131 sitenin tamam\u0131 i\u00e7in devre d\u0131\u015f\u0131 b\u0131rakt\u0131\u011f\u0131ndan, potansiyel bir g\u00fcvenlik a\u00e7\u0131\u011f\u0131 olu\u015fturabilir. Bu nedenle, yaln\u0131zca kural\u0131n uygulaman\u0131z i\u00e7in hi\u00e7bir ge\u00e7erli senaryoda tehdit olu\u015fturmad\u0131\u011f\u0131ndan eminseniz kullan\u0131lmal\u0131d\u0131r.<\/p>\n <\/span>Belirli Bir URL veya Konum (Location) \u0130\u00e7in Kurallar\u0131 Devre D\u0131\u015f\u0131 B\u0131rakma<\/span><\/h3>\nGenellikle yanl\u0131\u015f alarmlar sitenin tamam\u0131nda de\u011fil, belirli bir sayfa veya y\u00f6netici paneli gibi \u00f6zel bir b\u00f6l\u00fcmde ortaya \u00e7\u0131kar. Bu durumlarda, istisnay\u0131 sadece ilgili URL veya dizinle s\u0131n\u0131rlamak \u00e7ok daha g\u00fcvenli bir yakla\u015f\u0131md\u0131r. Apache veya Nginx yap\u0131land\u0131rman\u0131zda <Location><\/code> veya location<\/code> bloklar\u0131n\u0131 kullanarak, o konuma \u00f6zel istisnalar tan\u0131mlayabilirsiniz. \u00d6rne\u011fin, \/admin\/editor.php<\/code> sayfas\u0131nda 941100 ve 942100 numaral\u0131 kurallar sorun \u00e7\u0131kar\u0131yorsa:<\/p>\n<Location \/admin\/editor.php><\/code>
SecRuleRemoveById 941100<\/code>
SecRuleRemoveById 942100<\/code>
<\/Location><\/code><\/p>\nBu yap\u0131land\u0131rma, belirtilen kurallar\u0131 yaln\u0131zca \/admin\/editor.php<\/code> URL’si i\u00e7in devre d\u0131\u015f\u0131 b\u0131rak\u0131r, sitenin geri kalan\u0131nda ise aktif kalmalar\u0131n\u0131 sa\u011flar.<\/p>\n
| | | | | | | | |