Sve što trebate znati o Apache Basic autorizaciji. Podrška za sesiju u Perlu i PHP-u. Primjena logike i reda

Osim ovih modula, tu su i mod_authn_core i mod_authz_core. Ovi moduli implementiraju temeljne direktive koje su ključne za sve module autentifikacije.

Vjerojatno također želite pogledati Kontrolu pristupa, koja raspravlja razne načine kontrolirati pristup vašem poslužitelju.

Uvod

Ako na svojoj web stranici imate informacije koje su osjetljive ili namijenjene samo maloj skupini ljudi, tehnike u ovom članku pomoći će vam da budete sigurni da su ljudi koji vide te stranice ljudi kojima ste ih namjeravali vidjeti.

Ovaj članak govori o "standardnom" načinu osiguravanja dijelova vaše web stranice koje će većina vas koristiti.

Napomena:

Ako vaši podaci stvarno moraju biti sigurni, razmislite o korištenju mod_ssl uz bilo koju provjeru autentičnosti.

Preduvjeti

Upute o kojima se govori u ovom članku morat će se poslati u konfiguracijsku datoteku glavnog poslužitelja (obično pod ), ili u konfiguracijskim datotekama svakog direktorija (.htaccess datoteke).

Ako planirate koristiti .htaccess datoteke, morat ćete imati konfiguraciju poslužitelja koja dopušta postavljanje direktiva za provjeru autentičnosti u tim datotekama. To se radi pomoću direktive AllowOverride, koja navodi koje se direktive, ako ih ima, mogu staviti u konfiguracijske datoteke po direktoriju.

Budući da ovdje govorimo o autentifikaciji, trebat će vam direktiva AllowOverride poput ove:

AllowOverride AuthConfig

Ili, ako jednostavno namjeravate specificirati direktive izravno u glavnoj konfiguracijskoj datoteci poslužitelja, morat ćete naravno imati dozvolu za pisanje u tu datoteku.

I morate znati nešto o strukturi direktorija vašeg poslužitelja da biste znali gdje su neke datoteke pohranjene. Ne mora biti strašno teško i pokušat ću to shvatiti kad dođemo do ove točke.

Također morate osigurati da su moduli mod_authn_core i mod_authz_core ugrađeni u binarna datoteka httpd ili učitan s httpd.conf konfiguracijskom datotekom. Oba ova modula daju osnovne direktive i funkcionalnost, koji su ključni za konfiguraciju i korištenje provjere autentičnosti i autorizacije na web poslužitelju.

Dobivanje posla

Ovdje su osnovni principi za zaštitu lozinkom imenika na vašem poslužitelju.

Najprije morate izraditi datoteku zaporke. Točno kako ćete to učiniti ovisit će o tome kojeg davatelja autentifikacije odaberete. Više o ovome kasnije. Za početak ćemo koristiti tekstualna datoteka lozinke.

Ova datoteka mora biti smještena negdje nedostupno s Interneta. To znači da ljudi ne mogu preuzeti datoteku zaporke. Na primjer, ako se vaši dokumenti poslužuju iz /usr/local/apache/htdocs, možda biste željeli smjestiti datoteke s lozinkama u /usr/local/apache/passwd.

Da biste stvorili datoteku, upotrijebite uslužni program htpasswd koji se isporučuje uz Apache. Ovo će se nalaziti u direktoriju bin gdje god ste instalirali Apache. Ako ste instalirali Apache iz paketa treće strane, to se može nalaziti na vašem putu izvršavanja.

Za izradu datoteke unesite:

htpasswd -c /usr/local/apache/passwd/lozinke rbowen

Pružanje više od jedne osobe s

Gornje upute dopuštaju samo jednoj osobi (konkretno, nekome s korisničkim imenom rbowen) da uđe u imenik. U većini slučajeva, trebat ćete AuthGroupFile više od jedne osobe. Ovdje se nalazi AuthGroupFile.

Ako želite uključiti više od jedne osobe, morate stvoriti grupnu datoteku koja povezuje nazive grupe s popisom korisnika u toj grupi. Format ove datoteke je prilično jednostavan i možete ga izraditi koristeći svoj omiljeni editor. Sadržaj datoteke će izgledati ovako:

Naziv grupe: rbowen dpitts sungo rshersey

To je samo popis članova grupe u dugom retku odvojenih razmacima.

Da biste dodali korisnika u postojeću datoteku zaporke, unesite:

htpasswd /usr/local/apache/passwd/passwords dpitts

Dobit ćete isti odgovor kao i prije, ali će biti dodan postojeću datoteku umjesto stvaranja nove datoteke. (Ovo -c stvara novu datoteku lozinke).

Sada trebate promijeniti .htaccess datoteku ili blok da izgleda ovako:

AuthType Basic AuthName "By Invitation Only" # Izborni redak: AuthBasicProvider datoteka AuthUserFile "/usr/local/apache/passwd/passwords" AuthGroupFile "/usr/local/apache/passwd/groups" Zahtijevaj grupu GroupName

Sada će svatko tko je naveden u GroupName i ima unos u datoteci zaporke biti uključen ako unese ispravnu lozinku.

Postoji još jedan način da više korisnika bude manje specifično u vezi s tim. Umjesto stvaranja grupna datoteka možete jednostavno koristiti sljedeću direktivu:

Zahtijeva valjanog korisnika

Korištenje ove umjesto retka Require user rbowen omogućit će bilo kome navedenom u datoteci zaporke da ispravno unese svoju lozinku.

Mogući problemi

Zbog načina na koji je specificirana osnovna provjera autentičnosti, vaše korisničko ime i lozinka moraju se provjeriti svaki put kada tražite dokument od poslužitelja. To vrijedi čak i ako ponovno učitate istu stranicu i za svaku sliku na stranici (ako dolaze iz zaštićenog imenika). Kao što možete zamisliti, ovo malo usporava stvari. Količina koju usporava proporcionalna je veličini datoteke zaporke, jer mora otvoriti tu datoteku i proći kroz popis korisnika dok ne dobije vaše ime. I to bi trebao učiniti svaki put kada se stranica učita.

Posljedica toga je da postoji praktično ograničenje broja korisnika koje možete staviti u jednu datoteku zaporke. Ovo ograničenje ovisit će o performansama vašeg specifičnog poslužitelja, ali možete očekivati ​​usporavanje nakon što primite nekoliko stotina unosa i možda biste trebali razmotriti drugu metodu provjere autentičnosti u međuvremenu.

Alternativna pohrana lozinki

Budući da pohranjivanje lozinki u tekstualne datoteke ima gore navedene probleme, možda biste trebali pohraniti svoje lozinke na neko drugo mjesto, kao što je baza podataka.

Korištenje više dobavljača

S implementacijom nova arhitektura Autentifikacija i autorizacija temeljena na pružatelju usluga, više niste isključeni iz nijedne metode autentifikacije ili autorizacije. Zapravo, bilo koji broj pružatelja usluga može se miješati i uskladiti kako bi vam pružili točnu shemu koja odgovara vašim potrebama. Sljedeći primjer koristi pružatelje provjere autentičnosti temeljene na datotekama i LDAP.

AuthName "Private" AuthType Basic AuthBasicProvider file ldap AuthUserFile "/usr/local/apache/passwd/passwords" AuthLDAPURL ldap://ldaphost/o=yourorg Require valid-user

U ovom primjeru, davatelj datoteke prvo će pokušati autentifikirati korisnika. Ako ne može autentificirati korisnika, bit će pozvan LDAP provider. To vam omogućuje da proširite opseg provjere autentičnosti ako vaša organizacija implementira više prodavaonica provjere autentičnosti. Drugi scenariji autentifikacije i autorizacije mogu uključivati ​​miješanje jedne vrste autentifikacije s drugom vrstom autorizacije. Na primjer, provjera autentičnosti datoteke lozinke koja je ovlaštena prema LDAP direktoriju.

Baš kao što se može implementirati više pružatelja autentifikacije, može se koristiti više metoda autorizacije. Ovaj primjer koristi autorizaciju grupe datoteka kao i autorizaciju LDAP grupe.

AuthName "Private" AuthType Basic AuthBasicProvider file AuthUserFile "/usr/local/apache/passwd/passwords" AuthLDAPURL ldap://ldaphost/o=yourorg AuthGroupFile "/usr/local/apache/passwd/groups" Zahtijevaj grupu GroupName Zahtijevaj ldap- grupa cn=mojagrupa,o=vašaorg

Da bismo autorizaciju odveli malo dalje, direktive spremnika dopuštenja kao što su I omogućuju primjenu logike tako da se redoslijed autorizacije može u potpunosti kontrolirati kroz konfiguraciju. Pogledajte spremnike za autorizaciju za primjer kako se mogu koristiti.

Osim samo ovlaštenja

Primjena logike i reda

Kontrola kako i kojim redoslijedom će se autorizacija primjenjivati ​​bila je misterija u prošlosti. Apache 2.2 uveo je mehanizam provjere autentičnosti temeljen na pružatelju usluga za odvajanje stvarnog procesa provjere autentičnosti od vjerodajnica za autorizaciju i podršku. Jedna sporedna prednost bila je ta da se pružatelji autentifikacije mogu konfigurirati i pozivati ​​određenim redoslijedom, koji je bio neovisan o redoslijedu učitavanja samog modula autentifikacije. Taj isti mehanizam temeljen na pružatelju usluga također je prenesen na autorizaciju. To znači da direktiva Require ne samo da specificira koje metode autorizacije treba koristiti, već također specificira redoslijed kojim se pozivaju. Nekoliko autorizacijskih metoda poziva se istim redoslijedom kojim se u konfiguraciji pojavljuju naredbe Require.

S uvođenjem direktiva spremnika autorizacije kao što su I Konfiguracija također ima kontrolu nad time kada se pozivaju metode autorizacije i koji kriteriji određuju kada je pristup odobren. Pogledajte spremnike za autorizaciju za primjer kako se mogu koristiti za izražavanje složena logika ovlaštenje.

Predmemoriranje provjere autentičnosti

Mogu postojati slučajevi u kojima provjera autentičnosti predstavlja neprihvatljivo opterećenje pružatelju usluga ili vašoj mreži. To će najvjerojatnije utjecati na korisnike mod_authn_dbd (ili treće strane/prilagođenih pružatelja). Kako bi se to riješilo, HTTPD 2.3/2.4 uvodi novog pružatelja predmemoriranja, mod_authn_socache, za predmemoriranje vjerodajnica i smanjenje opterećenja izvornog(ih) pružatelja(a).

Ovo može značajno poboljšati produktivnost za neke korisnike.

Više informacija

Također biste trebali pročitati dokumentaciju za mod_auth_basic i mod_authz_host koja sadrži Dodatne informacije o tome kako sve to funkcionira. Direktiva također može pomoći u pojednostavljenju određenih konfiguracija provjere autentičnosti.

Različite šifre koje Apache podržava za podatke za provjeru autentičnosti objašnjene su u odjeljak "Šifriranje lozinke".

A možda biste željeli pogledati Kontrolu pristupa, koja raspravlja o nizu povezanih tema.

Često je potrebno ograničiti korisnički pristup određenim područjima vaše stranice. Na primjer, u administrativni dio. To se često radi stvaranjem vlastitog mehanizma autorizacije. Međutim, postoji način da zaštitite dijelove stranice pomoću ugrađenih alata poslužitelja i preglednika. Najjednostavnija autorizacija zove se Apache Osnovno ovlaštenje. Ovo će biti dugačak članak, pa se pripremite na puno čitanja. Ali sadržavat će sve što će vam ikada trebati za rad s ovom vrstom ovlaštenja.

Kako radi

Prvo stavljamo .htaccess datoteku na poslužitelj. U njemu označavamo koju zonu (ili određenu datoteku) želimo zaštititi lozinkom. To bi moglo izgledati otprilike ovako:

AuthType Basic #vrsta autorizacije
AuthName "Ime" #ime autorizacije
#lokacija datoteke zaporke
AuthUserFile /usr/host/mysite/.htpasswd
#preskoči bilo kojeg korisnika,
#tko je unio ispravno korisničko ime i lozinku

zahtijeva valjanog korisnika

Osim toga, stranica može sadržavati datoteku zaporke. Ima jednostavnu strukturu:

prijava: šifrirana lozinka
prijava: šifrirana lozinka
...

Put do ove datoteke naveden je u htaccess.

Razgovor s poslužiteljem pod povećalom

Pretpostavimo sada da je netko upisao adresu imenika zaštićenog lozinkom. Što će se dogoditi? Evo što:

1. Preglednik traži od poslužitelja stranicu na http://site/secret.
Poslužitelj vidi da je ova stranica zaštićena. Šalje zaglavlja preglednika:

WWW-Autentifikacija: Osnovno područje="Moje područje"
Status: 401 Neovlašteno
HTTP status: 401 neovlašteno

Ovdje se mora reći da zona (područje) - važan parametar. Ako trebate voditi korisnika kroz nekoliko zona zaštićenih lozinkom, od kojih korisnik ne bi trebao imati pristup svim, tada će naziv zone odrediti je li korisnik prijavljen na ovo mjesto ili ne.

2. Nakon što primi ova zaglavlja, preglednik na zaslonu iscrtava obrazac zahtjeva za prijavu i lozinku. Ako korisnik klikne "Odustani", preglednik prikazuje sve podatke koji slijede nakon ovih zaglavlja.

3. Ako je korisnik unio prijavu i lozinku, oni se šalju na poslužitelj. Uđe u datoteku s lozinkama i tamo pogleda sljedeći par. Ako ga pronađe, šalje natrag stranicu koju je preglednik tražio na samom početku. Ako nije, ponovno šalje zaglavlja autorizacije.

4. Ako je korisnik unio ispravnu prijavu i lozinku, a poslužitelj je odgovorio sa traženom stranicom, preglednik pamti unesenu prijavu i lozinku za ovu zonu.

5. Zatim, ako preglednik pošalje bilo koji (!!!) zahtjev poslužitelju, prilaže mu par - prijavu i lozinku. Ovako izgleda:

Autorizacija: Basic base64(login:pass)

To jest, par prijava-lozinka šifriran je u base64. Dopustite mi da vam još jednom skrenem pozornost - prijava i lozinka sada se šalju sa svakim zahtjevom preglednika. Za slike, stilske datoteke, skripte, favico i sve ostalo. U biti, da biste primili svaku datoteku, prolazite kroz autorizaciju. Samo preglednik to radi umjesto vas.

6. Kada poslužitelj primi zahtjev, provjerava dolazi li i s prijavom i lozinkom. Ako to učine, odmah provjeravaju autorizaciju.

Zahtjev za autorizaciju u Perlu i PHP-u

Sada je vrijeme da shvatite kako prikazati prozor za autorizaciju Apachea ne koristeći htaccess, već koristeći skriptu u Perlu ili PHP-u. Ova dva rješenja sam posebno stavio na dva različiti jezici pod jednim naslovom. Jer sada, poznavajući mehaniku, možemo brzo doći do zaključka da za pojavljivanje prozora zahtjeva za autorizacijom trebamo samo poslati potrebna zaglavlja. To je ono što ćemo učiniti.

#Perl
print "WWW-Authenticate: Basic realm=\"My Realm\"\n";
print "Status: 401 Neovlašteno\n";
print "HTTP-status: 401 neovlašteno\n";
print "Content-type: text/html\n\nCancel";

#PHP
header("WWW-Authenticate: Basic realm=\"My Realm\"");
zaglavlje ("Status: 401 neovlašteno");
zaglavlje ("HTTP-status: 401 neovlašteno");
print "Kliknuli ste Odustani";

Rezultat u oba slučaja bit će obrazac zahtjeva za autorizaciju.

Presretanje autorizacije u Perlu

Recimo da je korisnik unio korisničko ime i lozinku. Šalju se na poslužitelj. Ali tu nastaje problem. Činjenica je da kada Apache primi prijavu i lozinku, želi ih provjeriti u datoteci s lozinkama. Ali što ako se prijave i lozinke ne pohranjuju u datoteci s lozinkama, već u bazi podataka? U ovom slučaju, morate autorizirati skriptu prije nego što Apache to učini.

Pojavljuje se poteškoća: Apache ne prosljeđuje unesenu prijavu i lozinku u varijable okruženja. To jest, pristup njima iz Perla je problematičan. Ali vjerojatno. Najjednostavnije rješenje je koristiti mod_rewrite. Dodaj u htaccess datoteku linije:

RewriteEngine uključen
RewriteCond %(HTTP:Authorization) ^(.*)
RewriteRule ^(.*) —

Dodat će novu varijablu okoline. Iz Perla će biti vidljiv kao $ENV(HTTP_CGI_AUTHORIZATION). Sadržavat će par login-password kodiran u base64. Naravno, morat ćete se malo petljati da ih ponovno kodirate, ali i to je nešto. Štoviše, tu zapravo i nema puno frke:

$ENV(HTTP_CGI_AUTHORIZATION) =~ s/basic\s+//i;
moj ($REMOTE_USER,$REMOTE_PASSWD) = split(/:/,decode_base64($ENV(HTTP_CGI_AUTHORIZATION)));

Sada imamo dvije varijable $REMOTE_USER i $REMOTE_PASSWD, s kojima se možete autorizirati pomoću skripte, provjeravajući prijavu i lozinku što god vam srce poželi.

Presretanje autorizacije u PHP-u

Podrška za sesiju u Perlu i PHP-u

Između ostalog, nakon uspješne autorizacije, u varijabla okoline postojat će prijava ovlaštenog korisnika koji poziva izvršnu skriptu. Odnosno, uvijek ćete znati tko je točno pokrenuo skriptu. Prijava je sadržana u varijablama:

#perl
$ENV(REMOTE_USER)
#php
$_SERVER

To je to

Članak je ispao odličan, kao što sam i obećao. Ali ispituje osnovne principe rada Apache baze autorizacije, a također sadrži rješenja za neke probleme koji se mogu pojaviti pri radu s njim. Da budem iskren, proveo sam više od sat vremena tražeći odgovore na neka od pitanja razriješena u ovom članku. Nadam se da će pomoći uštedjeti vrijeme drugim programerima.

Povezani Linkovi

  • htaccess i htpasswd - kako autorizirati samo Apache
  • htaccess.net.ru - stranica posvećena mogućnostima upravljanja poslužiteljem pomoću htaccess datoteka

Ako želite pustiti više od jedne osobe, morat ćete stvoriti grupnu datoteku koja povezuje nazive grupe s popisom korisnika u toj grupi. Format ove datoteke je prilično jednostavan i možete je izraditi sa svojim omiljenim urednik. Sadržaj datoteke će izgledati ovako:

Naziv grupe: rbowen dpitts sungo rshersey

To je samo popis članova grupe u dugom redu odvojenih razmacima.

Za dodavanje korisnika vašoj već postojećoj datoteci zaporke upišite:

htpasswd /usr/local/apache/passwd/passwords dpitts

Dobit ćete isti odgovor kao i prije, ali on će biti pridodan postojećoj datoteci, umjesto stvaranja nove datoteke. (To je -c što omogućuje stvaranje nove datoteke lozinke).

Mod_auth_basic i mod_authz_host koji sadrže još neke informacije o tome kako sve ovo funkcionira. Direktiva također može pomoći u pojednostavljenju određenih konfiguracija provjere autentičnosti.

Različite šifre koje Apache podržava za podatke za provjeru autentičnosti objašnjene su u Šifriranje lozinki.

Možda ćete htjeti pogledati upute za kontrolu pristupa, koje raspravljaju o nizu povezanih tema.

Prvo što sam pokušao učiniti bilo je koristiti Apache modul authnz_ldap_module, o čijoj upotrebi ima dosta informacija na internetu. Prvo sam se suočio s činjenicom da autorizacija nije uspjela i da je poslužitelj odgovorio na zahtjev stranice interna greška. Nakon nekog kopanja, shvatio sam da je sve u kodiranju: moja lokalizacija je koi8-r, a AD, kao što znate, koristi utf8. Nakon što sam skicirao malu skriptu u perlu, pretvorio sam Apache konfiguraciju u utf8 kodiranje. Nakon ove operacije mogao sam autorizirati bilo kojeg korisnika domene (Zahtijeva valjanog korisnika), konkretnog korisnika domena (Zahtijeva ldap-korisnika), ali iz nekog razloga nije moguće autorizirati prema grupi. Nakon što sam potrošio n vremena, shvatio sam da korisnik mora biti u istoj OU kao i grupa. To me jako iznenadilo, jer nije sasvim jasno zašto je potrebna tako čudna autorizacija. Možda sam nešto pogriješio, ali sam na kraju odlučio prestati koristiti authnz_ldap_module modul i napraviti autorizaciju otprilike na istoj osnovi kao Squid autorizacija, koristeći Sambu i auth_ntlm_winbind_module modul.

Odmah ću reći da nisam našao gotov paket za FreeBSD i morao sam koristiti ono što sam našao na Internetu, ali više o tome u nastavku.

Da bih uspješno riješio problem, morao sam instalirati Apache, heimdal, Samba 3 iz portova i pronaći arhivu na internetu s auth_ntlm_winbind_module modulom. Dakle, redom.

Prvi je Apache instalacija. U ovome nema ništa komplicirano ili strašno, posebno kada instalirate portove: napravite konfiguraciju i napravite instalaciju čistom.

Sada manipuliramo konfiguracijskim datotekama. Hajdemo prvo razumjeti Kerberos stvaranjem /etc/krb5.conf datoteke, ispunjavajući je približno sljedećim sadržajem:


vijek trajanja karte = 24000
default_realm = DOMAIN.RU
dns_lookup_realm = lažno
dns_lookup_kdc = lažno


DOMAIN.RU = (
kdc = server1.domain.ru:88
kdc = server2.domain.ru:88
}


.domena.ru = DOMENA.RU
domena.ru = DOMAIN.RU


pam = (
debug = false
vijek trajanja karte = 36000
renew_lifetime = 36000
prosljeđivanje = istina
krb4_pretvori = lažno
}

Imam dva kontrolera domene, redom, pa sam u odjeljku realms naveo dva kdc-a. Također treba napomenuti da su velika i velika slova u ovoj datoteci vrlo važna.

Sljedeća datoteka je datoteka postavki Sambe. Ne trebaju mi ​​sve Samba funkcije, pa sam preimenovao zadanu konfiguracijsku datoteku u smb.conf.old i stvorio novi /usr/local/etc/smb.conf:


radna grupa = DOMENA
netbios ime = svn
područje = domena.ru
poslužiteljski niz = svn
domaćini dopuštaju = 192.168 127.0.0.1

winbind separator =+

winbind koristi zadanu domenu = da
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind enum korisnici = da
winbind enum grupe = da

predložak homedir = /tmp/winnt/%D/%U
shell predloška = /bin/bash

maksimalna veličina trupca = 50
sigurnost = ADS
metode autentifikacije = winbind

poslužitelj lozinke = poslužitelj1 poslužitelj2
passdb backend = smbpasswd
osjetljivo na velika i mala slova = ne

Sada morate dobiti Kerberos ulaznicu pomoću naredbe kinit:

kinit –p administrator

Sada dodajte Apache autostart (ako nije prethodno dodan) i Samba demone u datoteku /etc/rc.conf:

apache22_enable="DA"
smbd_enable="DA"
nmbd_enable="DA"
winbindd_enable="DA"

I pokušavamo ručno pokrenuti smbd, nmbd, winbindd. Sada provjeravamo rad winbindd-a pomoću naredbe wbinfo –p, na što je točan odgovor "Ping to winbindd uspio na fd 4".

Sljedeći korak je dodavanje stroja u domenu. Ovaj jednostavan rad izvršava se sljedećom naredbom:

net rpc join –S server1 –w DOMAIN –U administrator

Dakle, naš je stroj sada punopravni član domene.

Kao što sam rekao gore, nije bilo moguće pronaći modul za FreeBSD, ali je pronađen modul za Debian. Najvažnije je da pronađena arhiva sadrži datoteku mod_auth_ntlm_winbind.c koju je potrebno prevesti i instalirati. Mi to radimo ovako:

/usr/local/sbin/apxs -DAPACHE2 -c -i mod_auth_ntlm_winbind.c

Sada prijeđimo na posljednju fazu - konfiguraciju. konfiguracijska datoteka Apache. Prije toga kreiramo testni direktorij /usr/local/www/apache22/data/test, u kojem kreiramo testnu datoteku index.html s bilo kojim sadržajem. Dakle, dodajemo liniju za učitavanje za naš modul u config /usr/local/etc/apache22/httpd.conf:

LoadModule auth_ntlm_winbind_module libexec/apache22/mod_auth_ntlm_winbind.s o

i pravila za pristup našem testnom direktoriju, u obliku ovog bloka:


Opcije Indeksi FollowSymLinks
AllowOverride Ništa
Narudžba dopusti, odbij
Dopusti od svih
AuthName "NTLM provjera autentičnosti"
AuthType NTLM
NTLMAuth uključen
NTLMAuthHelper "/usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --require-membership-of= SID"
NTLMBasicAuthoritative
AuthType NTLM
zahtijeva valjanog korisnika

Gdje je SID SID grupe koja treba pristup ovoj mapi.

I na kraju ću vam pokazati kako Pomoć za PowerShell brzo dobiti SID grupe koja nam je potrebna:

$sid = (new-object system.security.principal.NtAccount("gro up_name "))
$sid.translate() | Format-Popis vrijednosti

Zaštita web stranice pomoću samog Apache poslužitelja jedna je od najjednostavnijih, au isto vrijeme prilično pouzdanih metoda. U ovom slučaju ne morate temeljito promišljati svoju sigurnosnu strategiju, dizajnirati je i implementirati u kod. Osim toga, da biste stvorili dobar sustav zaštite, morate imati dovoljno kvalifikacija u ovom pitanju. Upotrebom ugrađene zaštite Apache WEB poslužitelja uvelike si pojednostavljujete svoj zadatak - dovoljno je izvršiti jednostavan niz radnji i vaša će stranica biti dovoljno zaštićena. Ovaj će članak detaljno opisati korake i radnje koje trebate poduzeti. A na kraju članka bit će primjeri .htaccess datoteka.

Osnovna autentifikacija

Ovaj članak će raspravljati o najjednostavnijim i pristupačan način sigurnost - osnovna autentifikacija.

Komentar

Autentifikacija je proces kojim se potvrđuje da je netko ono za što se predstavlja. Obično provjera uključuje unos korisničkog imena i lozinke.

Pogledajmo kako funkcionira osnovna provjera autentičnosti.
Kada posjetitelj pristupi zaštićenom imeniku, Apache poslužitelj odgovara na zahtjev zaglavljem s kodom 401 (401 zaglavlje zahtijeva autentifikaciju). Preglednik posjetitelja prihvaća 401 zaglavlje i prikazuje prozor s poljima za unos korisničkog imena i lozinke. Nakon unosa korisničkog imena i lozinke, ti se podaci šalju natrag na poslužitelj, koji provjerava korisničko ime da vidi je li u posebna lista, a lozinka je ispravna. Ako je sve ispravno, tada posjetitelj dobiva pristup resursu. Zajedno sa zaglavljem, pregledniku se šalje poseban naziv koji se zove opseg. Preglednik predmemorira ne samo korisničko ime i lozinku tako da se prosljeđuju uz svaki zahtjev, već i opseg. Zahvaljujući tome, unos imena i lozinke u zaštićeni imenik provodi se samo jednom. U protivnom bi ih trebalo unijeti sa svakim zahtjevom u zaštićeni imenik. Predmemoriranje parametara provjere autentičnosti (ime, lozinka, opseg) obično se događa samo unutar jedne sesije.

Komentar

Na osnovna autentifikacija Korisničko ime i lozinka šalju se na mrežu u otvorena forma tijekom cijele sesije kada posjetitelj radi sa zaštićenim imenikom. Haker može presresti ove informacije pomoću mrežni analizator paketi. Ovaj tip provjera autentičnosti ne bi se trebala koristiti tamo gdje je potrebna stvarna zaštita komercijalno vrijednih informacija.

Komentar

Apache WEB poslužitelj podržava drugu vrstu zaštite - digest autentifikaciju. Tijekom digest autentifikacije, lozinka se ne prenosi u čistom tekstu, već kao hash kod izračunat korištenjem MD5 algoritma. Stoga se lozinka ne može presresti prilikom skeniranja prometa. Ali, nažalost, da biste koristili provjeru autentičnosti sažetka, trebate instalirati poseban modul na poslužitelj - mod_auth_digest. A to je samo u nadležnosti administracije poslužitelja. Također, donedavno provjeru autentičnosti sažetka nisu podržavale sve vrste preglednika.

Pojednostavljena zaštita web stranice

Kako biste zaštitili stranicu, morate učiniti sljedeći niz akcije: kreirajte datoteku s lozinkama, kopirajte je na poslužitelj, kreirajte .htaccess datoteku i također je kopirajte na poslužitelj.
Za organiziranje zaštite trebat će vam.

  1. WEB stranica i FTP pristup istoj.
  2. Prava za stvaranje .htpaccess datoteka i organizaciju zaštite pomoću njih.
  3. Pomoćni program za generiranje lozinke htpasswd.exe

Provjera rada .htaccess datoteke na poslužitelju

Kako biste provjerili imate li pravo organizirati zaštitu pomoću .htaccess datoteka, kreirajte tekstualnu datoteku pod nazivom .htaccess (prvi znak je točka, nema ekstenzije).

Komentar

Prikladno je stvoriti .htaccess datoteke pomoću ugrađenog uređivača u školjkama Far, WindowsCommander, TotalCommander itd., kao iu uređivaču Notepad.

Komentar

Kako se bilježnica ne bi automatski zamijenila txt proširenje, u dijaloškom okviru za spremanje, na padajućem popisu "vrsta datoteke" odaberite opciju "Sve datoteke".


Riža. Spremanje .htaccess datoteka u notepad

Provjera rada .htaccess

AuthType Basic
AuthName admin
zahtijeva valjanog korisnika

Zatim, preko FTP pristupa, prepišite .htaccess datoteku na stranici, u direktoriju koji želite zaštititi.

Komentar

Učinak .htaccess datoteka proteže se ne samo na direktorij u kojem se datoteka nalazi, već i na sve poddirektorije koji se nalaze na nižoj razini.

Zatim pristupite ovom direktoriju putem svog preglednika. Ako štitite admin direktorij i tamo ste kopirali .htaccess datoteku, tada za provjeru trebate unijeti sljedeći URL u adresnu traku svog preglednika: http://www.mysite.ru/admin/.

Ako se nakon toga od vas zatraži da unesete svoje korisničko ime i lozinku, kao na slici ispod, testiranje je bilo uspješno i možete nastaviti sa zaštitom imenika.

Riža. Prozor za unos prijave i lozinke


Ako ste sve učinili ispravno, ali se prozor za unos lozinke ne pojavljuje, to znači da vam postavke poslužitelja zabranjuju korištenje .htaccess datoteka za zaštitu direktorija. Za rješenja ovo pitanje Trebali biste kontaktirati administraciju poslužitelja ili koristiti drugu vrstu zaštite.
Nakon što se utvrdi da .htaccess datoteke rade, trebate ukloniti testnu datoteku koju ste upravo napisali sa stranice.

Komentar

Ako iz nekog razloga ne možete izbrisati datoteku .htaccess, stvorite praznu datoteku .htaccess i zamijenite je datotekom na poslužitelju.

Stvaranje datoteke s lozinkama.htpasswd

Datoteku lozinke stvara uslužni program htpasswd.exe. Ako na vašem računalu imate instaliran Apache WEB poslužitelj, tada ovaj uslužni program nalazi se u imeniku s instaliranim Apache-jesti u poddirektoriju kanta za smeće.

Komentar

Ako nemate instaliran Apache, uslužni program htpasswd.exe možete preuzeti s poveznice: .

Za rad s uslužnim programom htpasswd.exe potrebno vam je sučelje naredbenog retka. Programi kao što su Far, WindowsCommander itd. imaju sučelje naredbenog retka. Ovdje ćemo pogledati rad s naredbenim redom pomoću uslužnog programa cmd, koji je uključen u sustav Windows 2000/XP, itd.
Klik "Start" -> "Run", unesite u redak za unos cmd i pritisnite u redu. Otvorit će se prozor uslužnog programa CMD.

Riža. Prozor uslužnog programa CMD


Zatim morate otići u direktorij u kojem se nalazi uslužni program htpasswd.exe. Recimo da je Apache poslužitelj instaliran u direktoriju c:/Apache2, a zatim unesite naredbeni redak naredba: cd../../apache2/bin i pritisnite enter.


Premjestili ste se u direktorij s: Apache2in. Sada trebate dati naredbu za stvaranje datoteke s lozinkom. U naredbeni redak upišite sljedeće:

Htpasswd -cm .htpasswd admin

  • -cm su prekidači za utility. Tipka c - označava što treba kreirati nova datoteka s lozinkama. Ako datoteka s istim nazivom već postoji, bit će prebrisana. Ključ m - određuje šifriranje pomoću MD5 algoritma.
    .htpasswd - naziv datoteke zaporke (možete koristiti bilo koji naziv).
    admin - ime posjetitelja kojem će biti dopušten pristup ograničenom području stranice.

Kao odgovor, od vas bi se trebalo tražiti da unesete lozinku i ponovite je. Ako je sve ispravno, na kraju će se pojaviti sljedeća poruka: Dodavanje lozinke za korisničkog administratora. A u direktoriju c: Apache2in bit će datoteka .htpasswd, koja će sadržavati redak s korisničkim imenom i hash kodom njegove lozinke. Kako biste dodali drugog korisnika u istu .htpasswd datoteku, uklonite prekidač -c iz naredbe za pokretanje uslužnog programa htpasswd.exe

Htpasswd -m .htpasswd administrator


Komentar

Ako datoteka s lozinkama nije stvorena, moguće je da neki ključevi pomoćnih programa nisu podržani u vašem operacijski sustav. Na primjer, ponekad tipka m nije podržana. U tom slučaju trebate unijeti htpasswd -c .htpasswd admin
Za prikaz ključeva i parametara uslužnog programa unesite htpasswd.exe /? Dobit ćete opis sučelja.

Dakle, datoteka lozinke je stvorena. Sada ga trebate prepisati na poslužitelju. Vrlo je preporučljivo postaviti datoteke s lozinkama iznad korijenskog direktorija stranice - gdje posjetitelji neće imati pristup.
Ako to nije moguće, datoteke s lozinkama moraju biti zaštićene. To se može učiniti pomoću .htaccess datoteka. Kako biste zaštitili datoteke lozinkama, stvorite datoteku s redcima prikazanim u sljedećem popisu.

Zaštita datoteke.htpasswd


odbiti od svih

I stavite je u direktorij u kojem se nalazi vaša datoteka zaporke. Sada mu posjetitelji stranice neće moći pristupiti.
Datoteka zaporke je stvorena i zaštićena je od neovlaštenog pristupa. Sada morate stvoriti .htaccess datoteku koja će se koristiti u zaštićenom direktoriju.

Stvaranje .htaccess datoteke

Za zaštitu imenika mogu se koristiti sljedeće upute:

  • AuthType - Vrsta autentifikacije koja se koristi. Za osnovnu provjeru autentičnosti ova direktiva mora biti postavljena na: Osnovna
    AuthName - naziv opsega provjere autentičnosti. Tekst koji posjetitelju pomaže razumjeti gdje pokušava pristupiti. Na primjer, može biti napisano: "Privatna zona. Samo za administratora!"
    AuthUserFile - put do datoteke lozinke (.htpasswd).
    AuthGroupFile - put do datoteke grupa, ako postoji.
    Zahtjev - jedan ili više zahtjeva koji moraju biti ispunjeni da bi se dobio pristup ograničenom području.

Primjer .htaccess datoteke

AuthType Basic



zahtijevaju administratore grupe

Direktive AuthUserFile i AuthGroupFile trebale bi biti detaljnije opisane. Oni sadrže apsolutne staze do odgovarajućih datoteka iz korijena poslužitelja.

Pažnja!

Relativni putovi neće raditi!

Možete saznati put iz korijena poslužitelja pitajući administraciju poslužitelja ili ga možete pokušati pronaći sami. Da biste to učinili, pokrenite funkciju phpinfo(). Na ekranu će se prikazati ljubičasta tablica. Vrijednost apsolutnog puta od korijena poslužitelja može se vidjeti u varijablama: doc_root, open_basedir, DOCUMENT_ROOT.
Direktiva Require određuje kome je dopušten pristup ograničenom području. Na primjer,

  • zahtijevaju valid-user - pristup je dopušten svim verificiranim korisnicima
  • zahtijevaju korisnika admin alex mango - dopušten je pristup samo posjetiteljima s imenima admin, alex, mango. Naravno, oni moraju biti ovjereni.
    AuthName "Privatna zona. Samo za administratora!"
    AuthUserFile /usr/host/mysite/.htpasswd
    zahtijeva valjanog korisnika

    Pristup samo administratorima i root korisnicima

    AuthType Basic
    AuthName "Privatna zona. Samo za administratora!"
    AuthUserFile /usr/host/mysite/.htpasswd
    zahtijeva root korisnika admin

    Pristup samo korisnicima iz grupe administratora

    AuthType Basic
    AuthName "Privatna zona. Samo za administratora!"
    AuthUserFile /usr/host/mysite/.htpasswd
    AuthGroupFile /usr/host/mysite/group
    zahtijevaju administratore grupe

    Odbijanje pristupa samo datoteci private.zip


    AuthType Basic
    AuthName "Privatna zona. Samo za administratora!"
    AuthUserFile /usr/host/mysite/.htpasswd
    zahtijeva valjanog korisnika