Näiden moduulien lisäksi on myös mod_authn_core ja mod_authz_core. Nämä moduulit toteuttavat ydinkäskyt, jotka ovat kaikkien todennusmoduulien ydin.
Haluat luultavasti myös tutustua Access Controliin, jossa käsitellään eri tavoilla hallita pääsyä palvelimellesi.
Johdanto
Jos verkkosivustollasi on tietoja, jotka ovat arkaluontoisia tai tarkoitettu vain pienelle ihmisryhmälle, tämän artikkelin tekniikat auttavat sinua varmistamaan, että ihmiset, jotka näkevät kyseiset sivut, ovat juuri niitä henkilöitä, joille tarkoitit heidän näkevän.
Tässä artikkelissa tarkastellaan "tavanomaista" tapaa suojata verkkosivustosi osia, joita useimmat teistä aikovat käyttää.
Muistilappu:
Jos tietojesi on todella oltava turvassa, harkitse mod_ssl:n käyttöä todennuksen lisäksi.
Edellytykset
Tässä artikkelissa käsitellyt ohjeet on lähetettävä joko pääpalvelimesi asetustiedostoon (yleensä alle
Jos aiot käyttää .htaccess-tiedostoja, sinulla on oltava palvelinkokoonpano, joka sallii todennusohjeiden asettamisen näihin tiedostoihin. Tämä tehdään AllowOverride-direktiivillä, joka määrittää, mitkä direktiivit voidaan sijoittaa hakemistokohtaisiin asetustiedostoihin.
Koska puhumme tässä todentamisesta, tarvitset seuraavanlaisen AllowOverride-käskyn:
AllowOverride AuthConfig
Tai jos aiot yksinkertaisesti määrittää käskyt suoraan pääpalvelimen asetustiedostoon, sinulla on tietysti oltava kirjoitusoikeus kyseiseen tiedostoon.
Ja sinun on tiedettävä hieman palvelimesi hakemistorakenteesta tietääksesi, mihin tiedostoja on tallennettu. Sen ei tarvitse olla hirveän vaikeaa, ja yritän selvittää sen, kun pääsemme tähän pisteeseen.
Sinun on myös varmistettava, että moduulit mod_authn_core ja mod_authz_core on joko sisäänrakennettu binääritiedosto httpd tai ladattu httpd.conf-määritystiedostolla. Molemmat moduulit tarjoavat perusohjeet ja toiminnallisuutta, jotka ovat kriittisiä verkkopalvelimen todennuksen ja valtuutuksen määrittämisessä ja käytössä.
Saada työ
Tässä ovat perusperiaatteet palvelimesi hakemiston suojaamiseksi salasanalla.
Ensin sinun on luotava salasanatiedosto. Kuinka teet tämän tarkalleen, riippuu valitsemastasi todennuspalveluntarjoajasta. Tästä lisää myöhemmin. Aluksi käytämme tekstitiedosto salasanat.
Tämä tiedosto on sijoitettava jonnekin, johon ei pääse Internetistä. Tämä tarkoittaa, että ihmiset eivät voi ladata salasanatiedostoa. Jos asiakirjasi toimitetaan esimerkiksi hakemistosta /usr/local/apache/htdocs , saatat haluta sijoittaa salasanatiedostot kansioon /usr/local/apache/passwd.
Luo tiedosto käyttämällä Apachen mukana toimitettua htpasswd-apuohjelmaa. Tämä sijaitsee bin-hakemistossa missä tahansa Apachen asentamisessa. Jos asensit Apachen kolmannen osapuolen paketista, tämä saattaa olla suorituspolussasi.
Luo tiedosto kirjoittamalla:
htpasswd -c /usr/local/apache/passwd/passwords rbowen
Tarjoaa useamman kuin yhden henkilön
Yllä olevat direktiivit sallivat vain yhden henkilön (erityisesti jonkun, jonka käyttäjätunnus on rbowen) päästä hakemistoon. Useimmissa tapauksissa haluat useamman kuin yhden henkilön AuthGroupFile-tiedoston. Täällä AuthGroupFile sijaitsee.
Jos haluat sisällyttää useamman kuin yhden henkilön, sinun on luotava ryhmätiedosto, joka yhdistää ryhmien nimet kyseisen ryhmän käyttäjäluetteloon. Tämän tiedoston muoto on melko yksinkertainen ja voit luoda sen suosikkieditorillasi. Tiedoston sisältö näyttää tältä:
Ryhmän nimi: rbowen dpitts sungo rshersey
Se on vain luettelo ryhmän jäsenistä pitkällä rivillä välilyönneillä erotettuna.
Lisää käyttäjä olemassa olevaan salasanatiedostoon kirjoittamalla:
htpasswd /usr/local/apache/passwd/passwords dpitts
Saat saman vastauksen kuin ennenkin, mutta se lisätään olemassa oleva tiedosto uuden tiedoston luomisen sijaan. (Tämä -c saa sen luomaan uuden salasanatiedoston).
Nyt sinun on vaihdettava .htaccess-tiedosto tai -lohko
AuthType Basic AuthName "Vain kutsulla" # Valinnainen rivi: AuthBasicProvider-tiedosto AuthUserFile "/usr/local/apache/passwd/passwords" AuthGroupFile "/usr/local/apache/passwd/groups" Vaadi ryhmän nimi
Nyt kaikki, jotka on listattu GroupName-luetteloon ja joilla on merkintä salasanatiedostoon, otetaan mukaan, jos he syöttävät oikean salasanan.
On toinenkin tapa, jolla useat käyttäjät voivat olla vähemmän tarkkoja. Luomisen sijaan ryhmätiedosto voit yksinkertaisesti käyttää seuraavaa ohjetta:
Vaadi kelvollinen käyttäjä
Kun käytät tätä Require user rbowen -rivin sijaan, kaikki salasanatiedostossa mainitut voivat syöttää salasanansa oikein.
Mahdolliset ongelmat
Perustodennustavasta johtuen käyttäjätunnuksesi ja salasanasi on vahvistettava aina, kun pyydät asiakirjaa palvelimelta. Tämä pätee vaikka lataat saman sivun uudelleen ja jokaiselle sivulla olevalle kuvalle (jos ne tulevat suojatusta hakemistosta). Kuten voit kuvitella, tämä hidastaa asioita hieman. Sen hidastuminen on verrannollinen salasanatiedoston kokoon, koska sen on avattava tiedosto ja selattava käyttäjäluetteloa, kunnes se saa nimesi. Ja sen pitäisi tehdä tämä aina, kun sivu ladataan.
Tästä seuraa, että yhteen salasanatiedostoon mahtuvien käyttäjien lukumäärällä on käytännössä raja. Tämä raja riippuu tietyn palvelimesi suorituskyvystä, mutta voit odottaa hidastuvan muutaman sadan merkinnän jälkeen ja sinun kannattaa harkita toista todennusmenetelmää sillä välin.
Vaihtoehtoinen salasanan tallennus
Koska salasanojen tallentamisessa tekstitiedostoihin liittyy yllä mainittuja ongelmia, saatat haluta tallentaa salasanasi toiseen paikkaan, kuten tietokantaan.
Useiden toimittajien käyttäminen
Toteutuksen kanssa uutta arkkitehtuuria Palveluntarjoajaan perustuva todennus ja valtuutus, sinua ei enää suljeta pois todennus- tai valtuutusmenetelmistä. Itse asiassa mikä tahansa määrä palveluntarjoajia voidaan sekoittaa ja sovittaa, jotta saat tarkan järjestelmän, joka sopii tarpeisiisi. Seuraava esimerkki käyttää sekä tiedostopohjaisia että LDAP-todennustarjoajia.
Tässä esimerkissä tiedoston tarjoaja yrittää ensin todentaa käyttäjän. Jos se ei pysty todentamaan käyttäjää, LDAP-palveluntarjoaja kutsutaan. Tämän avulla voit laajentaa todennuksen laajuutta, jos organisaatiosi käyttää useita todennusvarastoja. Muut todennus- ja valtuutusskenaariot voivat sisältää yhden tyyppisen todennustyypin sekoittamisen toisen valtuutustyypin kanssa. Esimerkiksi todennus salasanatiedostoa vastaan, joka on valtuutettu LDAP-hakemistoa vastaan.
Aivan kuten useita todennustarjoajia voidaan toteuttaa, voidaan käyttää useita valtuutusmenetelmiä. Tässä esimerkissä käytetään tiedostoryhmän valtuutusta sekä LDAP-ryhmävaltuutusta.
Jos haluat viedä valtuutuksen hieman pidemmälle, käyttöoikeussäiliödirektiivit, kuten
Pelkän valtuutuksen lisäksi
Logiikan soveltaminen ja järjestys
Valtuutuksen soveltamisen valvonta on ollut mysteeri aiemmin. Apache 2.2 esitteli palveluntarjoajapohjaisen todennusmekanismin, joka erottaa varsinaisen todennusprosessin valtuutus- ja tukitiedoista. Yksi sivuetu oli, että todennuspalveluntarjoajat voitiin konfiguroida ja kutsua tietyssä järjestyksessä, joka oli riippumaton itse todennusmoduulin latausjärjestyksestä. Tämä sama palveluntarjoajapohjainen mekanismi on siirretty myös valtuutukseen. Tämä tarkoittaa, että Require-direktiivi ei ainoastaan määrittele, mitä valtuutusmenetelmiä tulee käyttää, vaan myös määrittelee niiden kutsumisjärjestyksen. Useita valtuutusmenetelmiä kutsutaan samassa järjestyksessä, jossa Require-käskyt näkyvät kokoonpanossa.
Ottamalla käyttöön lupasäiliödirektiivit, kuten
Todennuksen välimuisti
Todennus saattaa joissakin tapauksissa asettaa palveluntarjoajalle tai verkollesi kohtuuttoman taakan. Tämä vaikuttaa todennäköisesti mod_authn_dbd:n (tai kolmannen osapuolen/mukautetun palveluntarjoajan) käyttäjiin. Tämän ratkaisemiseksi HTTPD 2.3/2.4 esittelee uuden välimuistin tarjoajan, mod_authn_socache, joka tallentaa valtuustiedot välimuistiin ja vähentää alkuperäisen palveluntarjoajien kuormitusta.
Tämä voi parantaa merkittävästi joidenkin käyttäjien tuottavuutta.
Lisää tietoa
Sinun tulee myös lukea mod_auth_basic- ja mod_authz_host-dokumentaatio, jotka sisältävät Lisäinformaatio siitä, miten se kaikki toimii. Direktiivi voi myös auttaa yksinkertaistamaan tiettyjä todennusmäärityksiä.
Apachen tukemat eri salaukset todennustiedoille selitetään artikkelissa osio "Salasanan salaus".
Ja saatat haluta tutustua Access Controliin, jossa käsitellään useita aiheeseen liittyviä aiheita.
Usein on tarpeen rajoittaa käyttäjien pääsyä tietyille sivustosi alueille. Esimerkiksi hallinnolliseen osaan. Tämä tehdään usein luomalla oma valtuutusmekanismi. On kuitenkin olemassa tapa suojata sivuston alueita sisäänrakennetuilla palvelin- ja selaintyökaluilla. Yksinkertaisin valtuutus on nimeltään Apache Perusvaltuutus. Tästä tulee pitkä artikkeli, joten ole valmis lukemaan paljon. Mutta se sisältää kaiken, mitä tarvitset työskennelläksesi tämäntyyppisten valtuuksien kanssa.
Kuinka se toimii
Ensin laitamme .htaccess-tiedoston palvelimelle. Siinä ilmoitamme minkä vyöhykkeen (tai tietyn tiedoston) haluamme suojata salasanalla. Se voi näyttää jotain tältä:
AuthType Basic #valtuutustyyppi
AuthName "Nimi" #valtuutuksen nimi
#salasanatiedoston sijainti
AuthUserFile /usr/host/mysite/.htpasswd
#ohita mikä tahansa käyttäjä,
#joka antoi oikean käyttäjätunnuksen ja salasanan
vaadi kelvollista käyttäjää
Lisäksi sivusto voi sisältää salasanatiedoston. Sillä on yksinkertainen rakenne:
login:salattu salasana
login:salattu salasana
...
Tämän tiedoston polku on määritetty htaccessissa.
Keskustelua palvelimen kanssa suurennuslasin alla
Oletetaan nyt, että joku on kirjoittanut salasanalla suojatun hakemiston osoitteen. Mitä tapahtuu? Tässä on mitä:
1.
Selain pyytää palvelimelta sivua osoitteessa http://site/secret.
Palvelin näkee, että tämä sivu on suojattu. Se lähettää selaimen otsikot:
WWW-Authenticate: Basic realm="My Realm"
Tila: 401 Luvaton
HTTP-tila: 401 Luvaton
Tässä on sanottava, että vyöhyke (valtakunta) - tärkeä parametri. Jos haluat ohjata käyttäjää useiden salasanalla suojattujen vyöhykkeiden läpi, joista kaikkiin käyttäjällä ei pitäisi olla pääsyä, vyöhykkeen nimi määrittää, onko käyttäjä kirjautunut tähän paikkaan vai ei.
2. Saatuaan nämä otsikot selain piirtää ruudulle sisäänkirjautumis- ja salasanapyyntölomakkeen. Jos käyttäjä napsauttaa "Peruuta", selain näyttää kaikki tiedot, jotka seurasivat näitä otsikoita.
3. Jos käyttäjä on antanut käyttäjätunnuksen ja salasanan, ne lähetetään palvelimelle. Hän menee tiedostoon salasanojen kanssa ja katsoo siellä seuraavaa paria. Jos se löytää sen, se lähettää takaisin sivun, jota selain pyysi heti alussa. Jos ei, se lähettää valtuutusotsikot uudelleen.
4. Jos käyttäjä syötti oikean käyttäjätunnuksen ja salasanan ja palvelin vastasi pyydetyllä sivulla, selain muistaa syötetyn kirjautumistunnuksen ja salasanan tälle vyöhykkeelle.
5. Sitten, jos selain lähettää minkä tahansa (!!!) pyynnön palvelimelle, se liittää siihen parin - kirjautumistunnuksen ja salasanan. Se näyttää tältä:
Valtuutus: Basic base64(login:pass)
Eli kirjautumissalasana-pari on salattu base64:ssä. Haluan vielä kerran kiinnittää huomionne - käyttäjätunnus ja salasana lähetetään nyt minkä tahansa selainpyynnön kanssa. Kuville, tyylitiedostoille, skripteille, favicolle ja kaikelle muulle. Pohjimmiltaan jokaisen tiedoston vastaanottaminen käy läpi valtuutuksen. Vain selain tekee tämän puolestasi.
6. Kun palvelin vastaanottaa pyynnön, se tarkistaa, onko sen mukana myös käyttäjätunnus ja salasana. Jos he tekevät, he tarkistavat välittömästi valtuutuksen.
Valtuutuspyyntö Perlissä ja PHP:ssä
Nyt on aika selvittää, kuinka Apache-valtuutusikkuna näytetään ilman htaccessia, vaan käyttämällä komentosarjaa Perlissä tai PHP:ssä. Laitoin nimenomaan nämä kaksi ratkaisua kahdelle eri kieliä yhden otsikon alla. Koska nyt mekaniikka tuntemalla voimme nopeasti tulla siihen tulokseen, että valtuutuspyyntöikkunan ilmestymiseksi meidän tarvitsee lähettää vain tarvittavat otsikot. Näin teemme.
#Perl
print "WWW-Authenticate: Basic realm=\"My Realm\"\n";
tulosta "Tila: 401 Luvaton\n";
tulosta "HTTP-tila: 401 Luvaton\n";
tulosta "Content-type: text/html\n\nPeruuta";
#PHP
header("WWW-Authenticate: Basic realm=\"Oma alue\"");
header("Tila: 401 Luvaton");
header("HTTP-tila: 401 Luvaton");
tulosta "Napsautit Peruuta";
Molemmissa tapauksissa tuloksena on valtuutuspyyntölomake.
Valtuutuksen sieppaus Perlissä
Oletetaan, että käyttäjä on antanut käyttäjätunnuksen ja salasanan. Ne lähetetään palvelimelle. Mutta tässä syntyy ongelma. Tosiasia on, että kun Apache vastaanottaa kirjautumistunnuksen ja salasanan, se haluaa tarkistaa ne salasanatiedostosta. Mutta entä jos kirjautumistunnuksia ja salasanoja ei tallenneta salasanatiedostoon, vaan tietokantaan? Tässä tapauksessa sinun on valtuutettava komentosarja ennen kuin Apache tekee sen.
Syntyy ongelma: Apache ei välitä syötettyä kirjautumistunnusta ja salasanaa ympäristömuuttujiin. Eli pääsy niihin Perlistä on ongelmallista. Mutta luultavasti. Yksinkertaisin ratkaisu on käyttää mod_rewrite. Lisätä htaccess tiedosto rivit:
RewriteEngine päällä
RewriteCond %(HTTP:Authorization) ^(.*)
Uudelleenkirjoitussääntö ^(.*) —
Ne lisäävät uuden ympäristömuuttujan. Perlistä se näkyy muodossa $ENV(HTTP_CGI_AUTHORIZATION). Se sisältää kirjautumissalasana-parin, joka on koodattu base64:ssä. Tietenkin sinun täytyy hieman näpertää niitä koodataksesi ne uudelleen, mutta se on jotain. Lisäksi siellä ei itse asiassa ole paljon meteliä:
$ENV(HTTP_CGI_AUTHORIZATION) =~ s/basic\s+//i;
minun ($REMOTE_USER,$REMOTE_PASSWD) = split(/:/,decode_base64($ENV(HTTP_CGI_AUTHORIZATION)));
Nyt meillä on kaksi muuttujaa $REMOTE_USER ja $REMOTE_PASSWD, joilla voit valtuuttaa skriptin avulla tarkistamalla kirjautumistunnuksen ja salasanan millä tahansa sydämelläsi.
Valtuutuksen sieppaus PHP:ssä
Istuntotuki Perlissä ja PHP:ssä
Muun muassa sen jälkeen, kun valtuutus on onnistunut, sisään ympäristömuuttuja siellä on valtuutetun käyttäjän sisäänkirjautuminen, joka kutsuu suoritettavaa komentosarjaa. Eli tiedät aina, kuka tarkalleen käynnisti käsikirjoituksen. Kirjautuminen sisältyy muuttujiin:
#perl
$ENV(REMOTE_USER)
#php
$_SERVER
Se siitä
Artikkelista tuli loistava, kuten lupasin. Mutta se tarkastelee Apachen perusvaltuuksien toiminnan perusperiaatteita ja sisältää myös ratkaisuja joihinkin ongelmiin, joita voi syntyä sen kanssa työskennellessä. Ollakseni rehellinen, vietin yli tunnin etsiessäni vastauksia joihinkin tässä artikkelissa ratkaistuihin kysymyksiin. Toivottavasti se säästää muiden ohjelmoijien aikaa.
Liittyvät linkit
- htaccess ja htpasswd - kuinka valtuutetaan vain Apache
- htaccess.net.ru - sivusto, joka on omistettu palvelimen hallinnan mahdollisuuksille käyttämällä htaccess-tiedostoja
Jos haluat päästää sisään useamman kuin yhden henkilön, sinun on luotava ryhmätiedosto, joka yhdistää ryhmien nimet kyseisen ryhmän käyttäjäluetteloon. Tämän tiedoston muoto on melko yksinkertainen, ja voit luoda sen suosikkisi kanssa. editori. Tiedoston sisältö näyttää tältä:
Ryhmän nimi: rbowen dpitts sungo rshersey
Se on vain luettelo ryhmän jäsenistä pitkässä rivissä välilyönneillä erotettuna.
Jos haluat lisätä käyttäjän jo olemassa olevaan salasanatiedostoosi, kirjoita:
htpasswd /usr/local/apache/passwd/passwords dpitts
Saat saman vastauksen kuin ennenkin, mutta se liitetään olemassa olevaan tiedostoon uuden tiedoston luomisen sijaan. (Se on -c, joka saa sen luomaan uuden salasanatiedoston).
Mod_auth_basic ja mod_authz_host, jotka sisältävät lisätietoja siitä, miten tämä kaikki toimii. Direktiivi voi myös auttaa yksinkertaistamaan tiettyjä todennuskonfiguraatioita.
Apachen tukemat eri salaukset todennustiedoille selitetään artikkelissa Salasanasalaukset.
Ja saatat haluta tarkastella Access Control -ohjetta, jossa käsitellään useita aiheeseen liittyviä aiheita.
Ensimmäinen asia, jonka yritin tehdä, oli käyttää Apache moduuli authnz_ldap_module, jonka käytöstä Internetissä on paljon tietoa. Aluksi kohtasin sen tosiasian, että valtuutus epäonnistui ja palvelin vastasi sivupyyntöön sisäinen virhe. Pienen kaivamisen jälkeen tajusin, että kyse oli koodauksista: maa-alueeni on koi8-r ja AD, kuten tiedät, käyttää utf8:aa. Luonnosteltuani pienen skriptin perlissä muunsin Apache-konfiguraation utf8-koodaukseksi. Tämän toimenpiteen jälkeen pystyin valtuuttamaan minkä tahansa verkkotunnuksen käyttäjän (Require valid-user), tietty käyttäjä domain (Edellyttävä ldap-user), mutta jostain syystä ei voitu valtuuttaa ryhmäkohtaisesti. Vietettyään n aikaa tajusin, että käyttäjän on oltava samassa organisaatioyksikössä kuin ryhmä. Tämä yllätti minut suuresti, koska ei ole täysin selvää, miksi niin outoa lupaa tarvitaan. Ehkä tein jotain väärin, mutta lopulta päätin lopettaa authnz_ldap_module-moduulin käytön ja tehdä valtuutuksen suunnilleen samalla perusteella kuin Squid-valtuutus käyttäen Sambaa ja auth_ntlm_winbind_module-moduulia.
Sanon heti, että en löytänyt valmista pakettia FreeBSD:lle ja piti käyttää Internetistä löytämiäni, mutta siitä lisää alla.
Onnistuneen ongelman ratkaisemiseksi minun piti asentaa Apache, heimdal, Samba 3 porteista ja löytää arkisto Internetistä auth_ntlm_winbind_module-moduulilla. Siis järjestyksessä.
Ensimmäinen on Apache asennus. Tässä ei ole mitään monimutkaista tai kauheaa, varsinkin portteja asennettaessa: tee config ja tee asennus puhtaiksi.
Nyt käsittelemme asetustiedostoja. Ymmärretään ensin Kerberos luomalla /etc/krb5.conf-tiedosto ja täyttämällä se suunnilleen seuraavalla sisällöllä:
lipun käyttöikä = 24000
oletusalue = DOMAIN.RU
dns_lookup_realm = false
dns_lookup_kdc = false
DOMAIN.RU = (
kdc = server1.domain.ru:88
kdc = server2.domain.ru:88
}
.domain.ru = DOMAIN.RU
domain.ru = DOMAIN.RU
pam = (
debug = false
lipun käyttöikä = 36000
uusimisaika = 36000
edelleenlähetettävä = tosi
krb4_convert = false
}
Minulla on vastaavasti kaksi toimialueohjainta, joten määritin realms-osiossa kaksi kdcs:tä. On myös huomattava, että kirjainten kirjainkoko tässä tiedostossa on erittäin tärkeä.
Seuraava tiedosto on Samba-asetustiedosto. En tarvitse kaikkia Samba-toimintoja, joten nimesin oletusasetustiedoston uudelleen muotoon smb.conf.old ja loin uuden /usr/local/etc/smb.conf:
työryhmä = DOMAIN
netbios nimi = svn
realm = domain.ru
palvelinmerkkijono = svn
isännät sallivat = 192.168 127.0.0.1
winbind-erotin =+
winbind käytä oletusverkkotunnusta = kyllä
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind enum käyttäjät = kyllä
winbind enum ryhmät = kyllä
mallin kotihakemisto = /tmp/winnt/%D/%U
mallin kuori = /bin/bash
enimmäiskoko = 50
turvallisuus = ADS
todennusmenetelmät = winbind
salasanapalvelin = palvelin1 palvelin2
passdb backend = smbpasswd
isot ja pienet kirjaimet = ei
Nyt sinun on hankittava Kerberos-lippu kinit-komennolla:
kinit –p ylläpitäjä
Lisää nyt Apachen automaattinen käynnistys (jos sitä ei ole aiemmin lisätty) ja Samba-daemonit /etc/rc.conf-tiedostoon:
apache22_enable="YES"
smbd_enable="KYLLÄ"
nmbd_enable="KYLLÄ"
winbindd_enable="KYLLÄ"
Ja yritämme käynnistää smbd, nmbd, winbindd manuaalisesti. Nyt tarkistetaan winbindd:n toiminta komennolla wbinfo –p, johon oikea vastaus on "Ping to winbindd onnistui fd 4:llä".
Seuraava vaihe on lisätä kone toimialueeseen. Tämä yksinkertainen toiminta suoritetaan seuraavalla komennolla:
net rpc join –S-palvelin1 –w DOMAIN –U-järjestelmänvalvoja
Joten koneemme on nyt verkkotunnuksen täysjäsen.
Kuten edellä sanoin, FreeBSD:lle ei ollut mahdollista löytää moduulia, mutta moduuli Debianille löytyi. Tärkeintä on, että löydetty arkisto sisältää mod_auth_ntlm_winbind.c-tiedoston, joka on käännettävä ja asennettava. Teemme sen näin:
/usr/local/sbin/apxs -DAPACHE2 -c -i mod_auth_ntlm_winbind.c
Siirrytään nyt viimeiseen vaiheeseen - konfigurointiin. asetustiedosto Apache. Ennen tätä luomme testihakemiston /usr/local/www/apache22/data/test, johon luomme minkä tahansa sisällön testitiedoston index.html. Joten lisäämme moduulimme latausrivin konfiguraatioon /usr/local/etc/apache22/httpd.conf:
LoadModule auth_ntlm_winbind_module libexec/apache22/mod_auth_ntlm_winbind.s o
ja säännöt testihakemistoomme pääsystä tämän lohkon muodossa:
Asetukset Indeksit FollowSymLinks
SalliOverride Ei mitään
Tilaa salli, estä
Salli kaikilta
AuthName "NTLM-todennus"
AuthType NTLM
NTLMAuth päällä
NTLMAuthHelper "/usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --require-membership-of= SID"
NTLMBasicAuthoritative
AuthType NTLM
vaadi kelvollista käyttäjää
Missä SID on sen ryhmän SID, joka tarvitsee pääsyn tähän kansioon.
Ja lopuksi näytän sinulle kuinka PowerShell-apua hanki nopeasti tarvitsemamme ryhmän SID:
$sid = (uusi-objekti system.security.principal.NtAccount("group_name"))
$sid.translate() | Format-List Value
Sivuston suojaaminen itse Apache-palvelimella on yksi yksinkertaisimmista ja samalla melko luotettavimmista tavoista. Tässä tapauksessa sinun ei tarvitse miettiä perusteellisesti tietoturvastrategiaasi, suunnitella sitä ja toteuttaa sitä koodissa. Lisäksi hyvän suojajärjestelmän luomiseksi sinulla on oltava riittävä pätevyys tässä asiassa. Käyttämällä Apache WEB -palvelimen sisäänrakennettua suojausta yksinkertaistat tehtävääsi huomattavasti - sinun tarvitsee vain suorittaa yksinkertainen toimintosarja ja sivustosi on riittävän suojattu. Tässä artikkelissa kuvataan yksityiskohtaisesti vaiheet ja toimet, jotka sinun on suoritettava. Ja artikkelin lopussa on esimerkkejä .htaccess-tiedostoista.
Perustodennus
Tässä artikkelissa käsitellään yksinkertaisinta ja edullinen tapa turvallisuus - perustodennus.
Kommentti
Todennus on prosessi, jolla varmistetaan, että joku on se, jota he sanovat olevansa. Tyypillisesti vahvistus sisältää käyttäjänimen ja salasanan syöttämisen.
Katsotaanpa, miten perustodennus toimii.
Kun vierailija käyttää suojattua hakemistoa, Apache-palvelin vastaa pyyntöön otsikolla, jonka koodi on 401 (401-todennusta vaadittava otsikko). Vierailijan selain hyväksyy 401-otsikon ja näyttää ikkunan, jossa on kentät käyttäjätunnuksen ja salasanan syöttämistä varten. Käyttäjätunnuksen ja salasanan syöttämisen jälkeen nämä tiedot lähetetään takaisin palvelimelle, joka tarkistaa käyttäjänimen onko se erikoislista, ja salasana on oikea. Jos kaikki on oikein, vierailija saa pääsyn resurssiin. Yhdessä otsikon kanssa selaimeen lähetetään erityinen nimi, jota kutsutaan soveltamisalaksi. Selain tallentaa välimuistiin paitsi käyttäjänimen ja salasanan, jotta ne välitetään jokaisen pyynnön mukana, myös laajuuden. Tämän ansiosta nimen ja salasanan syöttäminen suojattuun hakemistoon suoritetaan vain kerran. Muussa tapauksessa ne on syötettävä jokaisen suojatun hakemiston pyynnön yhteydessä. Todennusparametrien (nimi, salasana, laajuus) välimuistiin tallentaminen tapahtuu yleensä vain yhden istunnon aikana.
Kommentti
klo perustodennus Käyttäjätunnus ja salasana lähetetään verkkoon sisään avoin lomake koko istunnon ajan, kun vierailija työskentelee suojatun hakemiston kanssa. Hakkeri voi siepata nämä tiedot käyttämällä verkko-analysaattori paketteja. Tämä tyyppi todennusta ei pitäisi käyttää, jos kaupallisesti arvokkaan tiedon todellista suojaa tarvitaan.
Kommentti
Apache WEB-palvelin tukee toisen tyyppistä suojausta - tiivistelmätodennusta. Tiivistelmätunnistuksen aikana salasanaa ei välitetä selkeänä tekstinä, vaan MD5-algoritmilla laskettuna hash-koodina. Siksi salasanaa ei voida siepata liikennettä skannattaessa. Mutta valitettavasti, jotta voit käyttää tiivistelmätodennusta, sinun on asennettava palvelimelle erityinen moduuli - mod_auth_digest. Ja tämä kuuluu vain palvelimen hallinnon toimivaltaan. Myöskään kaikki selaimet eivät viime aikoihin asti tukeneet tiivistelmätodennusta.
Sivuston suojaus on tehty helpoksi
Sivuston suojaamiseksi sinun on tehtävä seuraava sekvenssi toiminnot: luo tiedosto salasanoilla, kopioi se palvelimelle, luo .htaccess-tiedosto ja kopioi se myös palvelimelle.
Tarvitset suojauksen järjestämiseen.
- WWW-sivusto ja FTP-yhteys siihen.
- Oikeudet luoda .htpaccess-tiedostoja ja järjestää suojausta niiden avulla.
- Salasanan luontiapuohjelma htpasswd.exe
Tarkistetaan .htaccess-tiedoston toimintaa palvelimella
Luo tekstitiedosto nimeltä .htaccess (ensimmäinen merkki on piste, tunnistetta ei ole) tarkistaaksesi, onko sinulla oikeudet järjestää suojaus .htaccess-tiedostoilla.
Kommentti
On kätevää luoda .htaccess-tiedostoja käyttämällä sisäänrakennettua editoria Far-, WindowsCommander-, TotalCommander- jne. kuorissa sekä Muistio-editorissa.
Kommentti
Jotta muistilehtiö ei korvaa automaattisesti txt laajennus, valitse tallennusvalintaikkunan avattavasta "tiedostotyyppi"-luettelosta "Kaikki tiedostot" -vaihtoehto.
Riisi..htaccess-tiedostojen tallentaminen muistioon
Tarkistetaan .htaccess-tiedoston toimintaa
AuthType Basic
AuthName-järjestelmänvalvoja
vaadi kelvollista käyttäjää
Kirjoita sitten FTP-yhteyden kautta uudelleen sivuston .htaccess-tiedosto hakemistoon, jonka haluat suojata.
Kommentti
.htaccess-tiedostojen vaikutus ei ulotu vain hakemistoon, jossa tiedosto sijaitsee, vaan myös kaikkiin alihakemistoihin, jotka sijaitsevat alemmalla tasolla.
Siirry seuraavaksi tähän hakemistoon selaimesi kautta. Jos suojaat admin-hakemistoa ja olet kopioinut sinne .htaccess-tiedoston, sinun tulee tarkistaaksesi kirjoittamalla seuraava URL-osoite selaimesi osoiteriville: http://www.mysite.ru/admin/.
Jos tämän jälkeen sinua pyydetään syöttämään käyttäjätunnus ja salasana alla olevan kuvan mukaisesti, testi onnistui ja voit jatkaa hakemiston suojaamista.
Riisi. Kirjautumis- ja salasanansyöttöikkuna
Jos teit kaiken oikein, mutta salasanan syöttöikkuna ei tule näkyviin, tämä tarkoittaa, että palvelinasetukset estävät sinua käyttämästä .htaccess-tiedostoja hakemistojen suojaamiseen. Ratkaisuja varten tästä asiasta Ota yhteyttä palvelimen hallintaan tai käytä muuta suojaustyyppiä.
Kun on todettu, että .htaccess-tiedostot toimivat, sinun tulee poistaa juuri kirjoittamasi testitiedosto sivustosta.
Kommentti
Jos et jostain syystä voi poistaa .htaccess-tiedostoa, luo tyhjä .htaccess-tiedosto ja korvaa se palvelimella olevalla tiedostolla.
Luodaan tiedosto salasanalla.htpasswd
Salasanatiedoston luo htpasswd.exe-apuohjelma. Jos koneellesi on asennettu Apache WEB -palvelin, niin tämä apuohjelma sijaitsee hakemistossa, jossa on asennettuna Apache-syö alihakemistossa roskakori.
Kommentti
Jos sinulla ei ole Apachea asennettuna, voit ladata htpasswd.exe-apuohjelman linkistä: .
Jotta voit työskennellä htpasswd.exe-apuohjelman kanssa, tarvitset komentoriviliittymän. Ohjelmissa, kuten Far, WindowsCommander jne., on komentorivikäyttöliittymä. Tässä tarkastellaan komentorivin käyttöä cmd-apuohjelmalla, joka sisältyy Windows 2000/XP:hen jne.
Klikkaus "Aloita" -> "Suorita", kirjoita syöttöriville cmd ja paina OK. CMD-apuohjelman ikkuna avautuu.
Riisi. CMD-apuohjelmaikkuna
Seuraavaksi sinun on siirryttävä hakemistoon, jossa htpasswd.exe-apuohjelma sijaitsee. Oletetaan, että Apache-palvelin on asennettu hakemistoon c:/Apache2, ja kirjoita sitten sisään komentorivi komento: cd../../apache2/bin ja paina enter.
Olet siirtynyt hakemistoon: Apache2in. Nyt sinun on annettava komento luodaksesi tiedoston salasanalla. Kirjoita komentoriville seuraava:
Htpasswd -cm .htpasswd admin
- -cm ovat apuohjelman kytkimet. Avain c - osoittaa, mitä on luotava uusi tiedosto salasanojen kanssa. Jos samanniminen tiedosto on jo olemassa, se korvataan. Avain m - määrittää salauksen MD5-algoritmin avulla.
.htpasswd - salasanatiedoston nimi (voit käyttää mitä tahansa nimeä).
admin - vierailijan nimi, jolle annetaan pääsy sivuston rajoitetulle alueelle.
Vastauksena sinua tulee pyytää antamaan salasana ja toistamaan se. Jos kaikki on oikein, seuraava viesti tulee näkyviin loppuun: Lisätään salasana käyttäjän adminille. Ja c: Apache2in -hakemistossa on tiedosto .htpasswd, joka sisältää rivin käyttäjänimen ja salasanan hash-koodin. Jos haluat lisätä toisen käyttäjän samaan .htpasswd-tiedostoon, poista -c-kytkin htpasswd.exe-apuohjelman käynnistyskomennosta.
Htpasswd -m .htpasswd admin
Kommentti
Jos salasanoja sisältävää tiedostoa ei ole luotu, on mahdollista, että joitain apuavaimia ei tueta käyttöjärjestelmä. Joskus esimerkiksi m-näppäintä ei tueta. Tässä tapauksessa sinun on syötettävä htpasswd -c .htpasswd admin
Voit tarkastella apuohjelman avaimia ja parametreja kirjoittamalla htpasswd.exe /? Saat käyttöliittymän kuvauksen.
Joten salasanatiedosto on luotu. Nyt sinun on kirjoitettava se uudelleen palvelimelle. On erittäin suositeltavaa sijoittaa salasanoilla varustetut tiedostot sivuston juurihakemiston yläpuolelle - minne kävijät eivät pääse käsiksi.
Jos tämä ei ole mahdollista, salasanoilla varustetut tiedostot on suojattava. Tämä voidaan tehdä käyttämällä .htaccess-tiedostoja. Suojaa tiedostot salasanoin luomalla tiedosto, jossa on seuraavassa luettelossa näkyvät rivit.
Tiedoston suojaus.htpasswd
kieltää kaikilta
Ja laita se hakemistoon, jossa salasanatiedostosi sijaitsee. Nyt sivuston vierailijat eivät voi käyttää sitä.
Salasanatiedosto on luotu ja suojattu luvattomalta käytöltä. Nyt sinun on luotava .htaccess-tiedosto, jota käytetään suojatussa hakemistossa.
Luodaan .htaccess-tiedosto
Seuraavia ohjeita voidaan käyttää hakemiston suojaamiseen:
- AuthType – käytettävä todennustyyppi. Perustodennusta varten tämän käskyn tulee olla: Basic
AuthName – Todennusalueen nimi. Teksti, joka auttaa vierailijaa ymmärtämään, minne hän yrittää päästä. Se voi olla esimerkiksi kirjoitettu: "Yksityinen vyöhyke. Vain ylläpitäjälle!"
AuthUserFile - polku salasanatiedostoon (.htpasswd).
AuthGroupFile - polku ryhmätiedostoon, jos se on olemassa.
Vaadi - Yksi tai useampi vaatimus, joka on täytettävä päästäkseen rajoitetulle alueelle.
Esimerkki .htaccess-tiedostosta
AuthType Basic
vaatii ryhmän ylläpitäjiä
AuthUserFile- ja AuthGroupFile-käskyt tulisi kuvata yksityiskohtaisemmin. Ne sisältävät absoluuttiset polut vastaaviin tiedostoihin palvelimen juuresta.
Huomio!
Suhteelliset polut ei toimi!
Voit selvittää polun palvelimen juurilta kysymällä palvelimen ylläpitäjältä tai voit yrittää selvittää sen itse. Voit tehdä tämän suorittamalla phpinfo()-funktion. Näytölle tulee violetti taulukko. Palvelimen juuresta tulevan absoluuttisen polun arvoa voi tarkastella muuttujissa: doc_root, open_basedir, DOCUMENT_ROOT.
Require-direktiivi määrittää, kenellä on pääsy rajoitetulle alueelle. Esimerkiksi,
- vaadi valid-user - pääsy on sallittu kaikille vahvistetuille käyttäjille
- vaatia käyttäjän järjestelmänvalvojan alex mango - vain vierailijat, joiden nimet ovat admin, alex, mango, voivat käyttää. Luonnollisesti ne on varmennettava.
AuthName "Yksityinen vyöhyke. Vain ylläpitäjälle!"
AuthUserFile /usr/host/mysite/.htpasswd
vaadi kelvollista käyttäjääPääsy vain admin- ja root-käyttäjille
AuthType Basic
AuthName "Yksityinen vyöhyke. Vain ylläpitäjälle!"
AuthUserFile /usr/host/mysite/.htpasswd
vaativat käyttäjän admin rootinPääsy vain järjestelmänvalvojaryhmän käyttäjille
AuthType Basic
AuthName "Yksityinen vyöhyke. Vain ylläpitäjälle!"
AuthUserFile /usr/host/mysite/.htpasswd
AuthGroupFile /usr/host/mysite/group
vaatii ryhmän ylläpitäjiäVain private.zip-tiedoston käyttö estetään
AuthType Basic
AuthName "Yksityinen vyöhyke. Vain ylläpitäjälle!"
AuthUserFile /usr/host/mysite/.htpasswd
vaadi kelvollista käyttäjää
