Nginx ile Basic Authentication ve htpasswd Kullanarak Dizin Koruma

Yazar:komut.io ekibi Nginx Web Sunucusu Kurulum ve Yönetimi
0 Yorum

Bazen bir web uygulamasinin admin panelini, geliştirme aşamasındaki bir siteyi ya da izleme araclarinizin (Prometheus, Grafana, Kibana gibi) arayuzunu internete acmaniz gerekir ama herkesin erisebilmesini istemezsiniz. Iste tam bu noktada Nginx’in basit ama etkili silahi devreye girer: Basic Authentication. Karmasik bir OAuth sistemi kurmadan, birkac dakika icinde bir dizini ya da tum siteyi kullanici adi ve parola arkasina alabilirsiniz.

Bu yazida htpasswd ile kullanici olusturmayi, Nginx tarafinda bu korumayi devreye almayi, birden fazla senaryoyu (belirli dizin, belirli location, IP istisnasi vs.) ve gercek dunyada karsilasacaginiz sorunlari adim adim ele alacagiz. Yıllarca sunucu yonettiyseniz bu yontemin hala ne kadar pratik oldugunu bilirsiniz.

Basic Authentication Nedir ve Ne Zaman Kullanilir

Basic Authentication, HTTP protokolunun icinde yer alan en eski kimlik dogrulama yontemlerinden biridir. Calisma mantigi oldukca basittir: Sunucu bir kaynagi korudugunda, tarayiciya “401 Unauthorized” yaniti doner ve WWW-Authenticate basligini gonderir. Tarayici da kullanicidan kullanici adi ve parola ister, bunlari base64 ile kodlayarak Authorization basliginda sunucuya gonderir.

Burada dikkat edilmesi gereken kritik nokta sudur: base64 sifreleme degildir, sadece kodlamadir. Yani HTTPS kullanmiyorsaniz, kullanici adi ve parola aciktan network uzerinde gider. Bu yuzden Basic Auth’u mutlaka SSL/TLS ile birlikte kullanmalisiniz.

Basic Authentication’in ideal oldugu senaryolar:

  • Staging/test ortamlari: Musteriye gostermeden once siteyi arama motorlarindan ve meraklı gozlerden gizlemek
  • Admin panelleri: WordPress wp-admin, phpMyAdmin gibi hassas dizinleri ekstra bir katmanla korumak
  • Izleme araclari: Grafana, Prometheus, Kibana gibi kendi kimlik dogrulamasi olmayan ya da yetersiz olan araclar
  • Internal API’ler: Kucuk ekiplerde hizli bir koruma katmani

Kullanmamaniz gereken durumlar da var: Yuksek trafikli, cok kullanicili son kullanici uygulamalari icin Basic Auth uygun degildir. Cikis yapma (logout) mekanizmasi tarayici tarafinda dogru duzgun calismaz ve kullanici deneyimi kotudur.

htpasswd Aracini Kurmak

htpasswd araci, Apache’nin apache2-utils (Debian/Ubuntu) ya da httpd-tools (RHEL/CentOS/Rocky) paketi icinde gelir. Nginx kullaniyor olsak bile bu araca ihtiyacimiz var cunku parola dosyalarini bu arac uretir.

Debian ve Ubuntu tabanli sistemlerde:

sudo apt update
sudo apt install apache2-utils -y

RHEL, CentOS, Rocky Linux ve AlmaLinux’ta:

sudo dnf install httpd-tools -y

Kurulumu dogrulamak icin:

htpasswd -h

Bu komut htpasswd’nin yardim ciktisini gosterir. Eger komut bulunamadi hatasi aliyorsaniz paket kurulumu basarisiz olmustur, tekrar deneyin.

htpasswd kurmak istemiyorsaniz alternatif olarak OpenSSL ile de parola hash’i uretebilirsiniz, buna yazinin ilerleyen kismindaki OpenSSL bolumunde deginecegim.

Parola Dosyasi Olusturmak

Simdi ilk kullanicimizi olusturalim. Parola dosyalarini genellikle Nginx yapilandirma dizini icinde saklamak temiz bir pratiktir. Ben /etc/nginx/ altinda tutmayi tercih ederim.

Ilk kullaniciyi olustururken -c parametresini kullaniyoruz. Bu parametre dosyayi olusturur (create):

sudo htpasswd -c /etc/nginx/.htpasswd admin

Bu komut calistiktan sonra sizden parola girmenizi ve tekrar dogrulamanizi ister:

New password:
Re-type new password:
Adding password for user admin

Cok onemli uyari: -c parametresi dosyayi sifirdan olusturur. Eger dosya zaten varsa ve icinde kullanicilar varsa, -c kullanirsaniz tum icerik silinir ve dosya sadece yeni kullaniciyla bastan yazilir. Bu yuzden ilk kullanicidan sonra asla -c kullanmayin.

Ikinci kullaniciyi eklerken -c olmadan calistiriyoruz:

sudo htpasswd /etc/nginx/.htpasswd developer

Olusan dosyanin icerigine bakalim:

sudo cat /etc/nginx/.htpasswd

Cikti su sekilde gorunur:

admin:$apr1$k8sJ2m1p$Xz9fY7wKqLmN3vBcD4eFg1
developer:$apr1$p9mNx2Ld$Ht6yU8iOpQrS5tWvX7zAb0

Her satir kullanici:hash formatindadir. Buradaki $apr1$ on eki, Apache’nin ozel MD5 tabanli hash algoritmasini gosterir.

Parolayi Komut Satirindan Vermek

Eger interaktif olmayan bir sekilde, script icinden kullanici eklemek istiyorsaniz -b parametresini kullanabilirsiniz. Bu parametre parolayi dogrudan komut satirindan almanizi saglar:

sudo htpasswd -b /etc/nginx/.htpasswd otomasyon Gizli.Parola123

Ancak bunun bir guvenlik riski var: Parola shell gecmisinizde (bash history) duz metin olarak kalir. Otomasyon senaryolarinda bunu goz onunde bulundurun, script sonunda history temizligi yapmak isteyebilirsiniz.

Daha Guvenli Hash Algoritmalari

Varsayilan $apr1$ MD5 tabanlidir ve gunumuz standartlarina gore zayiftir. Daha guclu bcrypt hash’i kullanmak icin -B parametresini kullanabilirsiniz:

sudo htpasswd -B -c /etc/nginx/.htpasswd admin

bcrypt kullaniyorsaniz -C parametresiyle maliyet faktorunu (cost) da ayarlayabilirsiniz. Deger ne kadar yuksek olursa hash’in hesaplanmasi o kadar yavas ve kaba kuvvet saldirilarina karsi o kadar dayanikli olur:

sudo htpasswd -B -C 12 /etc/nginx/.htpasswd admin

Ben production ortamlarinda mumkun oldugunca bcrypt tercih ediyorum. Cost degeri olarak 10-12 arasi genellikle dengeli bir tercihtir.

Nginx Tarafinda Korumayi Devreye Almak

Parola dosyamiz hazir, simdi Nginx’e bu dosyayi kullanmasini soyleyecegiz. Iki temel direktif kullaniyoruz:

  • auth_basic: Koruma alanini aktif eder ve tarayicida gorunen mesaji (realm) belirler
  • auth_basic_user_file: Kullanici/parola dosyasinin yolunu belirtir

En basit ornekle, tum siteyi korumak icin server blogu icine su satirlari ekleriz:

server {
    listen 80;
    server_name ornek.com;

    root /var/www/html;
    index index.html;

    auth_basic "Yetkili Erisim";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        try_files $uri $uri/ =404;
    }
}

Buradaki "Yetkili Erisim" metni, tarayici parola sordugunda kullaniciya gosterilen mesajdir. Turkce karakter kullanmaktan kacinin, bazi tarayicilar bunlari dogru gostermeyebilir. Basit ve anlasilir tutun.

Yapilandirmayi test etmeyi asla atlamayin:

sudo nginx -t

Cikti su sekilde olmali:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Ardindan Nginx’i yeniden yukleyin:

sudo systemctl reload nginx

Simdi tarayicidan siteye girdiginizde kullanici adi ve parola isteyen bir pencere karsiniza cikacaktir.

Sadece Belirli Bir Dizini Korumak

Cogu zaman tum siteyi degil, sadece belirli bir dizini korumak isteriz. Ornegin /admin dizinini korumak istiyorsak location blogu icine auth direktiflerini yerlestiririz:

server {
    listen 80;
    server_name ornek.com;

    root /var/www/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }

    location /admin {
        auth_basic "Admin Panel";
        auth_basic_user_file /etc/nginx/.htpasswd;
        try_files $uri $uri/ =404;
    }
}

Bu yapilandirmada sadece /admin yolu koruma altindadir, sitenin geri kalani herkese aciktir.

PHP Uygulamalarinda Dizin Korumasi

WordPress gibi PHP tabanli uygulamalarda dizin korurken dikkat etmeniz gereken bir detay var. Ornegin wp-admin dizinini korumak istiyorsunuz ama ayni zamanda PHP dosyalarinin da calismasi gerekiyor:

location ^~ /wp-admin {
    auth_basic "Yonetim Alani";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location ~ .php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }
}

Burada ^~ on eki, bu location blogunun regex location’larindan once eslesmesini saglar. Ic ice location tanimlanmasi ise PHP isleme icin gereklidir. Bu tur senaryolarda dikkatli olmazsaniz ya PHP calismaz ya da koruma bypass edilebilir.

Bir onemli not: WordPress’te admin-ajax.php dosyasi frontend tarafindan da cagrilir. Eger tum wp-admin dizinini korursaniz, bazi eklentilerin ajax istekleri bozulabilir. Bu durumda admin-ajax.php icin istisna tanimlamaniz gerekebilir:

location = /wp-admin/admin-ajax.php {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}

Belirli IP’leri Muaf Tutmak

Cok yaygin bir senaryo: Ofis IP’nizden gelenlerin parola sormadan girmesini, disaridan gelenlerin ise parola girmesini istiyorsunuz. Bunu satisfy any direktifiyle cozeriz.

satisfy direktifi, birden fazla erisim kontrolu kosulunun nasil degerlendirileceğini belirler:

  • satisfy all: Tum kosullar saglanmali (varsayilan)
  • satisfy any: Kosullardan herhangi biri saglanirsa yeter

Ofis IP’sini muaf tutmak icin:

location /admin {
    satisfy any;

    allow 203.0.113.10;
    allow 192.168.1.0/24;
    deny all;

    auth_basic "Kisitli Alan";
    auth_basic_user_file /etc/nginx/.htpasswd;

    try_files $uri $uri/ =404;
}

Bu yapilandirmada:

  • 203.0.113.10 ve 192.168.1.0/24 aginan gelenler dogrudan (parolasiz) girer
  • Diger tum IP’lerden gelenler parola girmek zorunda kalir

Eger tam tersini isterseniz, yani hem IP kontrolu hem de parolayi birlikte zorlamak isterseniz satisfy all kullanirsiniz. Bu durumda hem izinli IP’den gelmeli hem de dogru parolayi girmelidir. Bu, cok hassas ortamlar icin ideal bir “iki katmanli” savunmadir.

Ayni Sunucuda Farkli Dizinler Icin Farkli Kullanicilar

Bazen farkli ekiplerin farkli dizinlere erisimini istersiniz. Bu durumda birden fazla htpasswd dosyasi olusturursunuz.

Once ayri dosyalar olusturalim:

sudo htpasswd -c -B /etc/nginx/.htpasswd_dev developer
sudo htpasswd -c -B /etc/nginx/.htpasswd_ops sysadmin

Sonra Nginx yapilandirmasinda her location icin farkli dosya gosteririz:

location /gelistirme {
    auth_basic "Gelistirme Ekibi";
    auth_basic_user_file /etc/nginx/.htpasswd_dev;
    try_files $uri $uri/ =404;
}

location /operasyon {
    auth_basic "Operasyon Ekibi";
    auth_basic_user_file /etc/nginx/.htpasswd_ops;
    try_files $uri $uri/ =404;
}

Bu yaklasim, farkli erisim gruplarini net bir sekilde ayirmanizi saglar. Bir kullanicinin erisimini iptal etmek istediginizde sadece ilgili dosyadan silmeniz yeterlidir.

Reverse Proxy Arkasindaki Servisleri Korumak

Grafana, Prometheus, Kibana gibi araclari Nginx ile proxy’lerken Basic Auth koymak cok yaygin bir kullanimdir. Ornegin arka planda 3000 portunda calisan Grafana’yi disari acarken:

server {
    listen 443 ssl;
    server_name izleme.ornek.com;

    ssl_certificate /etc/letsencrypt/live/izleme.ornek.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/izleme.ornek.com/privkey.pem;

    location / {
        auth_basic "Izleme Sistemi";
        auth_basic_user_file /etc/nginx/.htpasswd_izleme;

        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Burada onemli bir noktaya dikkat cekmek istiyorum: Bazi backend servisler kendi kimlik dogrulamalarini yapar ve Authorization basligini bekler. Nginx Basic Auth, Authorization basligini tuketir ve backend’e gecirmez. Eger backend’in de bu basliga ihtiyaci varsa (ornegin bir API), catisma yasarsiniz. Bu durumda ya backend’in kendi auth’unu kullanmali ya da farkli bir yaklasim benimsemelisiniz.

Prometheus icin benzer bir yapilandirma:

location / {
    auth_basic "Metrik Sunucusu";
    auth_basic_user_file /etc/nginx/.htpasswd;

    proxy_pass http://127.0.0.1:9090;
    proxy_set_header Host $host;
}

OpenSSL ile Parola Hash Uretmek

htpasswd kurmak istemedigimiz durumlarda, ornegin minimal bir container icinde, OpenSSL ile de htpasswd uyumlu satir uretebiliriz. Bu, ozellikle Docker imajlarinda ekstra paket kurmak istemediginizde ise yarar.

Asagidaki komut, kullaniciadi icin bir hash uretir:

printf "kullaniciadi:$(openssl passwd -apr1 'GizliParola')n" | sudo tee -a /etc/nginx/.htpasswd

Burada:

  • openssl passwd -apr1: Apache uyumlu MD5 hash uretir
  • printf: kullaniciadi ve hash’i birlestirir
  • tee -a: Ciktiyi dosyaya ekler (append)

Eger parolayi komut satirinda gormek istemiyorsaniz, openssl passwd -apr1 komutunu parametresiz calistirin, sizden interaktif olarak parola isteyecektir:

openssl passwd -apr1

Loglama ve 401 Hatalarini Izlemek

Basic Auth ile korunan bir alana yapilan basarisiz giris denemeleri, Nginx erisim loglarinda 401 durum koduyla gorunur. Kaba kuvvet saldirilarini fark etmek icin bu loglari izlemek onemlidir.

401 doneni hizlica gormek icin:

sudo grep " 401 " /var/log/nginx/access.log | tail -20

Hangi IP’lerin en cok 401 aldigini gormek icin:

sudo grep " 401 " /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -10

Bu ciktida ayni IP’nin cok sayida 401 aldigini goruyorsaniz, muhtemelen otomatik bir tarayicinin ya da kaba kuvvet saldirisinin hedefisinizdir. Bu durumda fail2ban ile bu IP’leri otomatik banlamak iyi bir savunmadir.

fail2ban ile Otomatik Koruma

fail2ban icin basit bir jail tanimi olusturabilirsiniz. Once fail2ban’in Nginx auth filtresi genellikle hazir gelir. /etc/fail2ban/jail.local dosyasina sunu ekleyin:

[nginx-http-auth]
enabled = true
filter = nginx-http-auth
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 5
bantime = 3600
findtime = 600

Bu yapilandirma, 10 dakika icinde 5 basarisiz giris yapan IP’yi 1 saat boyunca banlar. fail2ban’i yeniden baslatin:

sudo systemctl restart fail2ban
sudo fail2ban-client status nginx-http-auth

Basic Auth’un basarisiz denemeleri Nginx’in error.log dosyasina yazar, bu yuzden logpath olarak error.log gostermek onemlidir.

Gercek Dunya Senaryosu: Staging Sitesi Korumak

Simdi butun bunlari birlestiren gercekci bir ornek yapalim. Bir e-ticaret sitesinin staging (test) ortamini kuruyorsunuz. Bu sitenin:

  • Google tarafindan indekslenmemesi
  • Sadece ekip ve musterinin erisebilmesi
  • Ofis IP’sinden parolasiz erisilebilmesi
  • HTTPS uzerinden calismasi

gerekiyor. Iste tam yapilandirma:

server {
    listen 80;
    server_name staging.magaza.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name staging.magaza.com;

    ssl_certificate /etc/letsencrypt/live/staging.magaza.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/staging.magaza.com/privkey.pem;

    root /var/www/staging;
    index index.php index.html;

    add_header X-Robots-Tag "noindex, nofollow" always;

    location / {
        satisfy any;
        allow 203.0.113.10;
        deny all;

        auth_basic "Staging Ortami";
        auth_basic_user_file /etc/nginx/.htpasswd_staging;

        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ .php$ {
        satisfy any;
        allow 203.0.113.10;
        deny all;

        auth_basic "Staging Ortami";
        auth_basic_user_file /etc/nginx/.htpasswd_staging;

        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }
}

Bu yapilandirmada dikkat cekilmesi gereken birkac nokta var:

  • X-Robots-Tag basligi arama motorlarina bu siteyi indekslememelerini soyler
  • HTTP’den HTTPS’e yonlendirme yapiyoruz
  • Hem statik dosyalar hem de PHP dosyalari icin auth uyguluyoruz, cunku sadece birini korursaniz PHP dosyalari korumasiz kalabilir
  • Ofis IP’si (203.0.113.10) parolasiz gecebiliyor

Onemli bir hata kaynagi: Eger sadece location / icin auth koyup location ~ .php$ icin koymazsaniz, saldirgan dogrudan bir PHP dosyasina istek atarak korumayi bypass edebilir. Bu yuzden her iki blokta da auth tanimlamak kritik onem tasir.

Sik Karsilasilan Sorunlar ve Cozumleri

Parola dogru ama surekli sorup duruyor. Bu genellikle auth_basic_user_file yolunun yanlis olmasindan ya da dosya izinlerinden kaynaklanir. Nginx worker prosesinin dosyayi okuyabildiginden emin olun:

sudo ls -la /etc/nginx/.htpasswd
sudo chown root:www-data /etc/nginx/.htpasswd
sudo chmod 640 /etc/nginx/.htpasswd

Dosya izinlerini kontrol ettikten sonra hala sorun varsa, error.log’a bakin:

sudo tail -f /var/log/nginx/error.log

Eger “no user/password was provided” ya da “password mismatch” gibi mesajlar goruyorsaniz, sorun htpasswd dosyasinda ya da kullanicinin girdigi bilgide.

Auth calismiyor, herkes girebiliyor. Bu genellikle location blogu onceliginden kaynaklanir. Nginx’te location eslesmesi belirli bir sıralama izler. Regex location’lar (~) prefix location’lardan (/admin gibi) once eslesir. Eger daha genel bir regex location’iniz varsa, sizin auth koydugunuz blok hic calismayabilir. ^~ on ekini kullanarak oncelik verebilirsiniz.

Ic ice location’da auth kayboluyor. Nginx’te bir location blogu icinde baska bir location acarsaniz, dis blogun auth_basic direktifi ic bloga miras kalmaz. Yani ic location’da tekrar auth tanimlamaniz gerekebilir:

location /panel {
    auth_basic "Panel";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location ~ .php$ {
        auth_basic "Panel";
        auth_basic_user_file /etc/nginx/.htpasswd;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }
}

Belirli bir yolu auth’tan muaf tutmak istiyorum. Bir dizini koruyup icindeki tek bir dosyayi muaf tutmak icin auth_basic off kullanabilirsiniz:

location /korumali {
    auth_basic "Korumali Alan";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location /korumali/genel.html {
        auth_basic off;
    }
}

Bu, ornegin bir healthcheck endpoint’ini ya da webhook alici bir dosyayi auth’tan muaf tutmak istediginizde ise yarar.

Kullanici Yonetimi Islemleri

Zaman icinde kullanici eklemeniz, cikarmaniz ya da parola degistirmeniz gerekecek. Iste temel islemler.

Mevcut bir kullanicinin parolasini degistirmek, aslinda kullaniciyi tekrar eklemekle ayni seydir (-c olmadan):

sudo htpasswd /etc/nginx/.htpasswd developer

Bir kullaniciyi silmek icin -D parametresini kullaniriz:

sudo htpasswd -D /etc/nginx/.htpasswd developer

Dosyadaki kullanicilari listelemek icin (parolalari degil, sadece kullanici adlarini gormek icin):

sudo cut -d: -f1 /etc/nginx/.htpasswd

htpasswd dosyasinda degisiklik yaptiktan sonra Nginx’i yeniden yuklemenize gerek yoktur. Nginx bu dosyayi her istekte okur, dolayisiyla degisiklikler aninda etkili olur. Bu, kullanici yonetimini oldukca pratik hale getirir.

Guvenlik Ipuclari

Basic Auth basit bir mekanizma olsa da guvenlik acisindan dikkat etmeniz gereken noktalar var:

  • Mutlaka HTTPS kullanin. HTTP uzerinde Basic Auth, parolalarin duz metin gitmesine yol acar. Let’s Encrypt ile ucretsiz sertifika alabilirsiniz.
  • bcrypt tercih edin. Varsayilan MD5 yerine -B parametresiyle bcrypt kullanin.
  • htpasswd dosyasini web root’un disina koyun. Dosyayi /var/www icine koyarsaniz yanlislikla erisilebilir hale gelebilir. /etc/nginx/ altinda tutmak daha guvenlidir.
  • Guclu parolalar kullanin. Basic Auth kaba kuvvet saldirilarina acik oldugu icin kisa parolalar kolayca kirilabilir.
  • fail2ban entegre edin. Tekrarlayan basarisiz denemeleri otomatik banlayin.
  • Rate limiting ekleyin. Nginx’in limit_req direktifiyle istek hizini sinirlayarak kaba kuvvet saldirilarini yavaslatabilirsiniz.

Nokta ile baslayan dosya adi (.htpasswd) kullanmak da iyi bir aliskanliktir cunku bircok yapilandirma nokta ile baslayan dosyalara erisimi zaten engeller. Yine de garanti icin Nginx’te bu tur dosyalara erisimi acikca engelleyebilirsiniz:

location ~ /.ht {
    deny all;
}

Sonuc

Nginx ile Basic Authentication, dogru senaryolarda hala en pratik koruma yontemlerinden biridir. Karmasik bir kimlik dogrulama altyapisi kurmadan, birkac komut ve birkac satir yapilandirma ile bir dizini ya da tum siteyi kilitleyebilirsiniz. Ozellikle staging ortamlari, admin panelleri ve kendi kimlik dogrulamasi olmayan izleme araclari icin bu yontem gercek bir zaman kazandiricidir.

Ozetle akilda tutmaniz gerekenler: htpasswd ile parola dosyasini olustururken ilk kullanici disinda asla -c kullanmayin, production’da bcrypt tercih edin, Basic Auth’u mutlaka HTTPS ile birlikte kullanin ve location oncelik kurallarina dikkat edin ki koruma bypass edilmesin. Ic ice location kullaniyorsaniz auth direktiflerini tekrar tanimlamayi unutmayin ve PHP uygulamalarinda hem statik dosyalari hem de PHP islemcisini korumaya alin.

Son olarak, Basic Auth guvenlik zincirinizin tek halkasi olmamali. fail2ban ile kaba kuvvet korumasi, rate limiting ile istek sinirlamasi ve mumkunse IP kisitlamalarini birlikte kullanarak katmanli bir savunma olusturmak, sistemlerinizi cok daha saglam hale getirir. Basit gorunen bu araci dogru kullandiginizda, sunucularinizin guvenligine ciddi bir katki saglar.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir