Apache drošība

Ventspils Augstskola

Referāts

Apache drošība

Izstrādātājs: Dairis Kuciks

3. kursa students

Ekonomikas un pārvaldības fakultāte

Ventspils 2002

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.

Options Indexes FollowSymLinks Options Includes

Š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 -.

Options Indexes FollowSymLinks Options +Includes –Indexes

Šajā piemērā katalogam /web/docs/spec tiek uzstādīts papildus esošajām options Includes un noņemts Indexes.

Sintakse: ... Konteksts: server config, virtual host, directory, .htaccess

Liedz pieeju minētajām HTTP metodēm.

Require valid-user

Š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.

Sintakse: ... 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 .

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.

AuthType Basic     AuthName "Admin area"     AuthUserFile /etc/httpd/conf/pass.txt     AuthGroupFile /etc/httpd/conf/group.txt     require group admin     require user director    …

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:

AllowOverride None

Servera failu aizsargāšana

Galvenajā konfigurācijas failā ievieto sekojošu:

Order Deny,Allow Deny from all

Tas aizliegs pieju visiem failiem. Lai ļautu pieeju lietot failus kurus vēlas, tad lieto blokus.

Order Deny,Allow Allow from all

Jāpievērš uzmanība tam ka bloks var pārrakstī uzstādījumus, pat ja 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

AddType application/x-httpd-php  .php                 RemoveType   .php

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.