Saturs
INSTALĀCIJA 2
APACHE SĀKNĒŠANA 4
FAILS ACCESS.CONF 5
AR DROŠĪBU SAISTĪTĀS DIREKTĪVAS 6
AUTENTIFIKĀCIJA 10
DROŠĪBAS IETEIKUMI 13
Atļaujas ServerRoot katalogam 13
Server Side Includes 14
Servera uzstādījumu aizsargāšana 15
Servera failu aizsargāšana 15
PIELIKUMI 17
Pielikums 1. Servisu startēšana chroot vidē 18
Pielikums 2. Servera startēša ar Root lietotāju 18
Pielikums 3. Saites 19
Instalācija
Instalācija notiek uz Linux Mandrake 8.2. Apache instalācijai izmanto bināro .rpm instalāciju, versiju 1.4. Instalācijas fails ir pieejams Mandrake instalācijas kompaktdiskā. Rpm ir iepriekš sagatavota pakete, kuru startējot instalācija tālāk notiek automātiski. Šāda veida instalēšana ir vienkārša, bet tai ir trūkums, nevar zināt visas darbības kas notiek instalēšanas procesā. Šajā gadījumā to nevarētu uzskatīt par drošības trūkumu, jo Linux ir atvērtā koda programma un līdz ar to nav iespējams noslēpt kādu nedokumentētu darbību instalācijas procesā. Eksistē brīvi pieejami Apache servera izejas kodi, kurus var kompilēt, tad pašrocīgi uzstādīt apache serveri. Pie kompilēšanas ir iespējams uzstādīt daudzus parametrus, kas maina noklusētās vērtības, kuras ir pielietotas veidojot rpm paketi.
Instalācijas (ServerRoot) katalogs ir /etc/httpd. Instalācijas katalogā atrodas konfigurācijas faili, un dažādi Apache moduļi.
Dokumentu katalogs (DocumentRoot) ir /var/www/html.
Apache sāknēšana
Apache serveris tiek startēts pēc operētājsistēmas ielādēšanas. Automātisku startēšanu nodrošina /etc/init.d/httpd fails. Šajā failā ir norādīts lietotājs zem kura tiek sākumā startēts Apache (parasti root). Ja sāknēšanas failā ir norādīts cits lietotājs, tad var būt problēmas ar 80 porta rezervēšanu. Ja nevēlas startēt Apache ar root, tad jāizmanto kāds no augstajiem portiem (virs 1024), piemēram, 8080.
Pēc tam, kad Apacche ir ielādēts un uzdarītas dažas sākuma darbības, atvērti log faili, tas startē dažus apakšprocesus, kuri klausās 80 portu un atbild kientam, tai skaitā darbojas ar CGI un SSI.
Turpmāk Apache kodols darbojas kā root, bet apakšprocesi ar mazāk priviliģētu lietotāju.
Sīkāk par Apache startēšanu ar root pielikumā 2.
Fails access.conf
Fails access.conf ir galvenais konfigurācijas fails, tas atrodas ServerRoot katalogā. Serveris to nolasa tikai startējoties. Ja ir veiktas izmaiņas konfigurācijas failā, tad ir nepieciešams pārstartēt Apache. Faila nosaukums ir noteikts kompilējot Apache, bet to var mainīt no komandrindas ar –f.
/usr/local/apache/bin/httpd -f /usr/local/apache/conf/httpd.conf
Var pievienot papildus konfigurācijas failus lietojot Include direktīvu.
Include
Sintakse: Include file-path|directory-path
Konteksts: server config, virtual host, directory
Ja Include norāda uz katalogu, tad Apache nolasa visus failus šajā katalogā un apakškatalogos un uzskata tos par konfigurācijas failiem. Ērti lietot ja operē ar virtuālajiem hostiem.
Sīkāk par konfigurācijas faila sintaksi: http://httpd.apache.org/docs-2.0/configuring.html
Ar drošību saistītās direktīvas
User
Sintakse: User unix-userid
Konteksts: server config, virtual host
Lietotājs zem kura apache servers darbojas. Ieteicams izveidot jaunu lietotāju kuram nav tiesību. Lai varētu lietotu šo direktīvu serverim sākumā ir jāstartējas kā root. Iespējams, ka var norādīt kā lietotāju nobody. Virtuāliem hostiem var notiekt citu lietotāju.
Group
Sintakse: Group unix-group
Konteksts: server config, virtual host
Grupa zem kuras serveris darbojas. Ieteicams izveidot jaunu grupu kuram nav tiesību. Iespējams ka var norādīt kā grupu nobody.
Allow
Sintakse: Allow from all|host|env=env-variable [host|env=env-variable] …
Konteksts: directory, .htaccess
Nosaka kuri host var piekļūt noteiktiem dokumentiem uz servera.
Pieeju var kontrolēt pēc pilna vai daļēja domēna vārda vai IP adreses, pēc tikla/tīkla maskas (Allow from 10.1.0.0/255.255.0.0), pēc A network/nnn CIDR specification (Allow from 10.1.0.0/16)
Deny
Sintakse: Deny from all|host|env=env-variable [host|env=env-variable] …
Konteksts: directory, .htaccess
Nosaka kādi hosti nevar pieslēgties serverim
Deny ir identiska Allow.
Order
Sintakse: Order ordering
Konteksts: directory, .htaccess
Nosaka kādā secībā tiek izvērtētas Allow from un Deny from direktīvas.
Order Deny,Allow . Nosākuma izvērtē Deny, tad Allow. Šajā secībā stiprākas ir Allow tiesības.
Order Allow,Deny Nosākuma izvērtē Allow, tad Deny. Šajā secībā stiprākas ir Deny tiesības. Stiprākai drošībai šāda secība ir piemērotāka.
AllowOverride
Sintakse: AllowOverride All|None|directive-type [directive-type] …
Konteksts: directory
Nosaka kādas direktīvas ir atļautas lietot .htaccess failā (vai cits nosaukums, kas norādīts AccessFileName direktīvā).
Serverim atrodot failu .htaccess ir jāzina kādas direktīvas, kas noteiktas iepriekš, var pārrakstīt.
Ja AllowOverride ir uzstādīts kā none, tad .htaccess faili tiek ignorēti, serveris tos pat nelasa no diska.
Ja AllowOverride ir uzstādīts kā All, tad jebkuru direktīvu var pārrakstīt ar .htaccess failu.
Kā directive-type var būt:
– AuthConfig
Ļauj lietot autorizācijas direktīvas. (AuthDBMGroupFile, AuthDBMUserFile, AuthGroupFile, AuthName, AuthType, AuthUserFile, Require, un citas.).
– FileInfo
Ļauj lietot direktīvas, kas kontrolē dokumentu tipus (DefaultType, ErrorDocument, ForceType, LanguagePriority, SetHandler, SetInputFilter, SetOutputFilter, and mod_mime Add* and Remove* directives, un citas.).
– Indexes
Ļauj lietot direktīvas, kas kontrolē katalogu nolasīšanu (AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName, un citas.).
– Limit
Ļauj lietot direktīvas, kas kontrolē pieeju resursam pēc hostiem (Allow, Deny and Order).
– Options
Ļauj lietot direktīvas, kas kontrolē specifiskas kataloga īpašības (Options and XBitHack). Atļaujot ietot šo direktīvu lietotājs pat sev var piešķirt atļauju izpildīt CGI un SSI.
Options
Sintakse: Options [+|-]option [[+|-]option] …
Konteksts: server config, virtual host, directory, .htaccess
Nosaka kādas īpašības ir konkrētajam katalogam.
Option None, neviena īpašība nepiemīt folderim. Maksimāla drošība.
Sekojošus option var uzstādīt:
All- visas īpašības.
ExecCGI – atļauj izpildīt CGI skriptus.
FollowSymLinks
Includes – ļauj izpildīt Server-side includes
IncludesNOEXEC – ļauj izpildīt Server-side includes, bet #exec komanda un #exec CGI ir aizliegts.
Indexes
MultiViews
SymLinksIfOwnerMatch
Ja vienam katalogam ir definēts options vairākās vietās, tad tiek ņemts vērā specifiskākā norāde. Tas ir, ja katalogu struktūrā options ir definēts augstākajam līmenim un tai pašā laikā options ir definēts apakškatalogam, tad options tiek ņemts no apakškataloga.
<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options Includes
</Directory>
Šajā piemērā katalogam /web/docs/spec tiek uzstādīts tikai Includes. Parasti options netiek apvienoti, bet ir iespējams apvienot options ar + un -.
<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options +Includes –Indexes
</Directory>
Šajā piemērā katalogam /web/docs/spec tiek uzstādīts papildus esošajām options Includes un noņemts Indexes.
<Limit>
Sintakse: <Limit method [method] … > … </Limit>
Konteksts: server config, virtual host, directory, .htaccess
Liedz pieeju minētajām HTTP metodēm.
<Limit POST PUT DELETE>
Require valid-user
</Limit>
Šis piemērs liedz pieeju POST, PUT un DELETE , atstājot pārējās metodes nepasargātas. Metodes var būt GET, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, un UNLOCK. Metode ir reģistrjūtīga.
<LimitExcept>
Sintakse: <LimitExcept method [method] … > … </LimitExcept>
Konteksts: server config, virtual host, directory, .htaccess
Liedz pieejeu visām HTTP direktīvām izņemot minētās. Šī direktīva ir pretēja <Limit>.
Autentifikācija
Ar autentifikāciju saistītās direktīvas.
AuthType
Sintakse: AuthType Basic|Digest
Konteksts: directory, .htaccess
Autentifikācijas tips. Digest ir daudz stiprāka par Basic, bet Digest autentisikācija ir ieviesta tikai jaunākajās pārlūkprogrammās.
AuthName
Sintakse: AuthName auth-domain
Konteksts: directory, .htaccess
Autentifikācijas vietas nosaukums. To rāda web pārlūkprogramma lietotāja autentifikācijas logā.
AuthUserFile
Sintakse: AuthUserFile file-path
Konteksts: directory, .htaccess
Uzstāda faila vārdu, kurā glabājas lietotāju saraksts ar parolēm. Jāuzmanās, lai AuthUserFile ir novietots ārpus web katalogu koka. Citādi klientiem ir iespēja ta redzēt.
Piemērs:
bob: nfF/iXiQjaip6
joe:rzNNm.uDYrq0U
Parole ir šifrēta ar funkciju crypt(), piemēram, crypt(“manaparole”,”nf”);. Kā otro argumentu norāda sāli no diviem simboliem. Šo funkciju var izmantot PHP.
AuthGroupFile
Sintakse: AuthGroupFile file-path
Konteksts: directory, .htaccess
Uzstāda faila vārdu, kurā glabājas lietotāju grupas.
Piemērs:
mygroup: bob joe anne
Lietotājus atdala ar tukšumu.
Require
Sintakse: Require entity-name [entity-name] …
Konteksts: directory, .htaccess
Nosaka kuri autentificēti lietotāji var piekļūt. Tikai require iedarbina lietotāja autentifikāciju uz noteiktiem resursiem.
require group admin
require user director
Šajā gadījumā piekļuve ir atļauta visiem lietotājiem no grupas admin un lietotājam director.
Require valid-user atļauj piekļuvi jebkuram autentificētam lietotājam.
Satisfy
Sintakse: Satisfy any|all
Noklusētā vērtība: Satisfy all
Konteksts: directory, .htaccess
Saistība starp host-līmeņa piekļuves kontroli un lietotāju autentifikāciju.
Satisfy direktīvai ir nozīme, ja izmanto abus Allow un Require.
Satisfy all. Lai piekļūtu resursam nepieciešams ievadīt paroli un būt no atļautā hosta. Satidfy all nodrošina stiprāku drošibu.
Satisfy any. Piekļuve resursam tiek atļauta, ja ir no atlautā hosta vai arī ir ievadīta pareizs lietotājs.
Lai nodrošināti Basic autentifikāciju katalogam /var/www/html.
<Directory /var/www/html>
AuthType Basic
AuthName “Admin area”
AuthUserFile /etc/httpd/conf/pass.txt
AuthGroupFile /etc/httpd/conf/group.txt
require group admin
require user director
…
</Directory>
Fails pass.txt
dairis:nfF/iXiQjaip6
director:rzNNm.uDYrq0U
Paroļu failu var vaidot no komandrindas ar htpasswd. Šī programma instalējas reizē ar Apache serveri.
Lai izveidotu jaunu failu:
htpasswd -c /etc/httpd/comf/pass.txt director, kur
-c norāda veidot jaunu failu;
/etc/httpd/comf/pass.txt faila vārds;
director lietotāja vārds.
htpasswd prasīs ievadīt paroli, un vēlreiz apstiprināt to.
Fails group.txt
admin: dairis
Informāciju par lietotājiem un grupām ir iespējams glabāt DBM datubāzē, jo daudzu lietotāju glabāšana teksta failā ir neefektīva un serverim prasa vairāk resursus. DBM lietotāju datubāzi var lietot ar programmu dbmmanage, kas iekļauta Apache instalācijā. Dbmmanage var izveidot jaunu DBM lietotāju datubāzi.
Drošības ieteikumi
Atļaujas ServerRoot katalogam
Liela uzmanība ir jāvērš katalogam, kur atrodas ServerRoot.
To maximize security, you should adopt a strict “need to know” policy for both the document root (where HTML documents are stored) and the server root (where log and configuration files are kept). It’s most important to get permissions right in the server root because it is here that CGI scripts and the sensitive contents of the log and configuration files are kept.
You need to protect the server from the prying eyes of both local and remote users. The simplest strategy is to create a “www” user for the Web administration/webmaster and a “www” group for all the users on your system who need to author HTML documents. On Unix systems edit the /etc/passwd file to make the server root the home directory for the www user. Edit /etc/group to add all authors to the www group.
The server root should be set up so that only the www user can write to the configuration and log directories and to their contents. It’s up to you whether you want these directories to also be readable by the www group. They should _not_ be world readable. The cgi-bin directory and its contents should be world executable and readable, but not writable (if you trust them, you could give local web authors write permission for this directory). Following are the permissions for a sample server root:
drwxr-xr-x 5 www www 1024 Aug 8 00:01 cgi-bin/
drwxr-x— 2 www www 1024 Jun 11 17:21 conf/
-rwx—— 1 www www 109674 May 8 23:58 httpd
drwxrwxr-x 2 www www 1024 Aug 8 00:01 htdocs/
drwxrwxr-x 2 www www 1024 Jun 3 21:15 icons/
drwxr-x— 2 www www 1024 May 4 22:23 logs/
The document root has different requirements. All files that you want to serve on the Internet must be readable by the server while it is running under the permissions of user “nobody”. You’ll also usually want local Web authors to be able to add files to the document root freely. Therefore you should make the document root directory and its subdirectories owned by user and group “www”, world readable, and group writable:
drwxrwxr-x 3 www www 1024 Jul 1 03:54 contents
drwxrwxr-x 10 www www 1024 Aug 23 19:32 examples
-rw-rw-r– 1 www www 1488 Jun 13 23:30 index.html
-rw-rw-r– 1 lstein www 39294 Jun 11 23:00 resource_guide.html
Many servers allow you to restrict access to parts of the document tree to Internet browsers with certain IP addresses or to remote users who can provide a correct password (see below). However, some Web administrators may be worried about unauthorized _local_ users gaining access to restricted documents present in the document root. This is a problem when the document root is world readable.
One solution to this problem is to run the server as something other than “nobody”, for example as another unprivileged user ID that belongs to the “www” group. You can now make the restricted documents group- but not world-readable (don’t make them group-writable unless you want the server to be able to overwrite its documents!). The documents can now be protected for prying eyes both locally and globally. Remember set the read and execute permissions for any restricted server scripts as well.
The CERN server generalizes this solution by allowing the server to execute under different user and group privileges for each part of a restricted document tree. See the CERN documentation for details on how to set this up.
If your server starts up as root but runs as another user, then it’s especially important that the logs directory not be writable by the user that the server runs as. For example, both the Netscape FastTrack and SuiteSpot servers come with the logs directory writable by the user that the server runs as (i.e. as “nobody” if you choose the default configuration values). This can make the effect of some CGI bugs much worse than they would normally be. For example if a CGI bug enables a remote user to run arbitrary commands on the server, then the remote user can also gain root access to the server by exploiting the bug to replace a log file with a symlink to /etc/passwd. When the server restarts, the symlink will result in /etc/passwd being chown’d to the server user. The remote user can now exploit the CGI bug again to add an entry to /etc/passwd. The suggested workaround is to change the ownership of the logs directory so that it’s not writable by the server user, and then create empty log and pid files that are owned by the server user (the server won’t start up if it can’t open these files.) Although this solution is less than optimal, because it allows crackers to tamper with the log files, it is much better than the default configuration. This bug may also be present in other commercial servers. (Thanks to Laura Pearlman for this information.)
Server Side Includes
Server Side Includes (SSI) present a server administrator with several potential security risks.
The first risk is the increased load on the server. All SSI-enabled files have to be parsed by Apache, whether or not there are any SSI directives included within the files. While this load increase is minor, in a shared server environment it can become significant.
SSI files also pose the same risks that are associated with CGI scripts in general. Using the “exec cmd” element, SSI-enabled files can execute any CGI script or program under the permissions of the user and group Apache runs as, as configured in httpd.conf. That should definitely give server administrators pause.
There are ways to enhance the security of SSI files while still taking advantage of the benefits they provide.
To isolate the damage a wayward SSI file can cause, a server administrator can enable suexec as described in the CGI in General section.
Enabling SSI for files with .html or .htm extensions can be dangerous. This is especially true in a shared, or high traffic, server environment. SSI-enabled files should have a separate extension, such as the conventional .shtml. This helps keep server load at a minimum and allows for easier management of risk.
Another solution is to disable the ability to run scripts and programs from SSI pages. To do this replace Includes with IncludesNOEXEC in the Options directive. Note that users may still use <–#include virtual=”…” –> to execute CGI scripts if these scripts are in directories desginated by a ScriptAlias directive.
Servera uzstādījumu aizsargāšana
Tas nozīmē neļaut lietotājiem mainīt uzstādījumus ar .htaccess faila palīdzību.
Galvenajā konfigurācijas failā ievieto sekojošu:
<Directory />
AllowOverride None
</Directory>
Servera failu aizsargāšana
Galvenajā konfigurācijas failā ievieto sekojošu:
<Directory />
Order Deny,Allow
Deny from all
</Directory>
Tas aizliegs pieju visiem failiem. Lai ļautu pieeju lietot failus kurus vēlas, tad lieto <directory> blokus.
<Directory /usr/local/httpd>
Order Deny,Allow
Allow from all
</Directory>
Jāpievērš uzmanība tam ka <location> bloks var pārrakstī uzstādījumus, pat ja <Directory /> liedz visur pieeju.
Ļoti rekomendē lietot sekojošu direktīvu:
UserDir disabled root
.httaccess faila aizsargāšana
Nepieciešams uzstādīt, lai servers nerādītu caur web .httaccess failu, kā arī paroļu failu.
PHP scenāriju izpildīšana
Apache ir izveidots modulis mod_php4. mod_php4 atsķiras no php CGI varianta ar to, ka mod_php4 tiek ielādēts atmiņā reizē ar apache, bet php CGI tiek izsaukts un ielādēts atmiņā, katru reizi, kad tiek izpildīts php scenārijs. Lai varētu lietot php CGI, scenārija failā pirmajā rindiņā ir jānorāda kur atrodas php CGI izpildāmais fails, piemēram, #!/usr/local/bin/php.
Lai kontrolētu php scenāriju izpildīšanu dažādos katalogos, tad var piešķirt atsevišiem katalogiem atpazīt .php paplašinājumu kā senāriju kuru vajag izpildīt ar mod_php4.
Piemēram, nepieciešams atļaut .php scenārijus zem /var/html/vea un neatļaut zem /var/html/vea/user
<Directory /var/html/vea>
<IfModule mod_php4.c>
AddType application/x-httpd-php .php
</IfModule>
</Directory>
<Directory /var/html/vea/user>
<IfModule mod_php4.c>
RemoveType .php
</IfModule>
</Directory>
RemoveType
Sintakse: RemoveType extension [extension] …
Konteksts: directory, .htaccess
Ar RemoveType noņem paplašinājumam piesaistīto
AddHandler
Sintakse: AddHandler handler-name extension [extension] …
Konteksts: server config, virtual host, directory, .htaccess
Ar AddHandler direktīvu var pievienot handleri, kas apstrādā failu. Piemēram, lai aktivizētu CGI scenāriju izpildi lieto:
AddHandler cgi-script .cgi
vai
AddHandler server-parsed .shtml
RemoveHandler
Sintakse: RemoveHandler extension [extension] …
Konteksts: directory, .htaccess
Lai noņemtu CGI scenāriju izpildi lieto
RemoveHandler .cgi
Vai
RemoveHandler .shtml
Pielikumi
Pielikums 1. Servisu startēšana chroot vidē
Several network services can now be configured to run in a restricted environment, called a “chroot jail”. This is an isolated environment seperated from the “real” operating system. Services such as Apache or bind can be operated in this environment. A special root directory is created, with a complete installation of all programs and libraries necessary to execute the service. The intention is to prevent someone from obtaining root privilege on the “real” operating system, due to a bug in the service that is operating in the chroot jail.
This should not be treated as a panacea, however. It may help to restrict a process’ filesystem access, but it doesn’t affect its ability to make privileged system calls (e.g. init_module, modify_ldt, bind to a priviliged port, etc.) So ultimately a root process can break out of a chroot environment; it just makes the necessary shellcode more involved than just “exec(“/bin/sh”)”. You can find more information on it’s advantages and disadvantages at http://www.ssc.com/lg/issue30/tag_chroot.html This isn’t explicitly a chroot discussion, but is helpful, nevertheless.
Pielikums 2. Servera startēša ar Root lietotāju
This has been the source of some misunderstanding and disagreement on the Net. Most servers are launched as root so that they can open up the low numbered port 80 (the standard HTTP port) and write to the log files. They then wait for an incoming connection on port 80. As soon as they receive this connection, they fork a child process to handle the request and go back to listening. The child process, meanwhile, changes its effective user ID to the user “nobody” and then proceeds to process the remote request. All actions taken in response to the request, such as executing CGI scripts or parsing server-side includes, are done as the unprivileged “nobody” user.
This is not the scenario that people warn about when they talk about “running the server as root”. This warning is about servers that have been configured to run their _child processes_ as root, (e.g. by specifying “User root” in the server configuration file). This is a whopping security hole because every CGI script that gets launched with root permissions will have access to every nook and cranny in your system.
Some people will say that it’s better not to start the server as root at all, warning that we don’t know what bugs may lurk in the portion of the server code that controls its behavior between the time it starts up and the time it forks a child. This is quite true, although the source code to all the public domain servers is freely available and there don’t seem to be any bugs in these portions of the code. Running the server as an ordinary unprivileged user may be safer. Many sites launch the server as user “nobody”, “daemon” or “www”. However you should be aware of two potential problems with this approach:
You won’t be able to open port 80 (at least not on Unix systems). You’ll have to tell the server to listen to another port, such as 8000 or 8080.
You’ll have to make the configuration files readable by the same user ID you run the server under. This opens up the possibility of an errant CGI script reading the server configuration files. Similarly, you’ll have to make the log files both readable and writable by this user ID, making it possible for a subverted server or CGI script to alter the log. See the discussion of file permissions above.
Pielikums 3. Saites
http://httpd.apache.org/ Apache web serveris. Lielāko daļu nepieciešamās informācijas par Apache ir iespējams sameklēt tieši šeit.
http://www.w3.org/Security/Faq/ klienta un servera daļas drošība, CGI drošība.