Lars Sommer\u00a0< lasg@lasg.dk >\u00a018. november 2006
Noter til bogen Mastering FreeBSD and OpenBSD Security del 2<\/p>\n\n\n\n
1.1 Angreb<\/p>\n\n\n\n
En webserver st\u00e5r ofte \u00e5ben for hele verden, s\u00e5 folk kan komme og se p\u00e5 hjem- mesiderne. Dette medf\u00f8rer at webservere ofte er udsat for angreb. \u00c5rsagerne til angreb mod webservere kan eksempelvis v\u00e6re:<\/p>\n\n\n\n
Der er mange forskellige midler til at opn\u00e5 disse m\u00e5l. Hvordan de enkelte fungerer, er ikke s\u00e5 relevant i denne sammenh\u00e6ng.<\/p>\n\n\n\n
1.2 S\u00e6rlige trusler<\/p>\n\n\n\n
1.2.1 Arbitr\u00e6r programk\u00f8rsel<\/p>\n\n\n\n
Denne truselstype er meget udbredt og meget skadelig. Angriberen kan f\u00e5 lov at k\u00f8re programmer eller kode efter eget valg, via huller i, typisk, cgi- programmer eller php-kode. Angriberen kan enten k\u00f8re de programmer der allerede ligger p\u00e5 serveren (og give sig selv ssh-, eller telnet-adgang), eller selv uploade rootkits og lignende. Selv hvis angriberen ikke kan k\u00f8re en shell umiddelbart, kan alle exploits der normalt kun g\u00e6lder for lokalt brug, pludselig v\u00e6re lige s\u00e5 skadelige som de til fjernbrug.<\/p>\n\n\n\n
1.2.2 Programmisbrug<\/p>\n\n\n\n
SQL-, HTML-, Java-script-kode og XSS kan bruges helt uden operativsyste- met eller netv\u00e6rket er klar over det. Derfor er det ekstremt vigtigt, at man stoler p\u00e5 de webapplikationer man benytter sig af, og sp\u00e6rrer disse i chroot eller jails, hvis de ikke er 100% til at stole p\u00e5.<\/p>\n\n\n\n
M\u00e5ske kan angriberen ikke direkte f\u00e5 adgang til serveren gennem s\u00e5- danne programmer, men i stedet \u001cske andre brugere cookies med login- informationer, sende spam via f.eks. en formmail.pl og lignende.<\/p>\n\n\n\n
1.2.3 Fill\u00e6kage<\/p>\n\n\n\n
Nogle webservere eller webapplikationer er ikke opm\u00e6rksomme p\u00e5 alle typer af encoding, og kan m\u00e5ske narres til at lade angriberen downloade bruger- databasen, n\u00e5r den bare encodes korrekt.<\/p>\n\n\n\n
Mulighed for upload af data er lige s\u00e5 slemt. Der kan eksempelvis uploa- des ondsindede programmer, som kan ramme enten lokale, eller fjernsystemer hvor tra\u001ckken s\u00e5 kommer fra din server. Der kan overskrives vigtige \u001cler, og sidst kan der l\u00e6gges ulovligt materiale op, som andre s\u00e5 kan hente fra dig.<\/p>\n\n\n\n
<\/p>\n\n\n\n
1.3 Apache<\/p>\n\n\n\n
Hvis du kan n\u00f8jes med en lille simpel webserver, uden SSL, store dynamiske sider osv, er thttpd m\u00e5ske mere attraktiv. Men ellers apache.<\/p>\n\n\n\n
Der er to store versioner; 1.3 og 2. Hvis du allerede k\u00f8rer et stort og stabilt site med 1.3, er det ok at blive, men starter du noget nyt, s\u00e5 brug endelig version 2. Et par fordele ved 2, er at threading og generel performance er stort forbedret. Den underst\u00f8tter multitr\u00e5dede moduler, og har en del moduler inkluderet som standard (SSL f.eks.) Kon\u001cgurationen af 2 er ogs\u00e5 nemmere. Moduler kan sl\u00e5es til og fra med een enkelt linje pr modul, og beh\u00f8ver ikke st\u00e5 i korrekt r\u00e6kkef\u00f8lge som i version 1.<\/p>\n\n\n\n
1.3.1 Installation<\/p>\n\n\n\n
I OpenBSD er det stadig en chrooted apache 1.3 der f\u00f8lger med. Version 2 \u001cndes ikke endgang i ports. I FreeBSD er der ingen med som standard, men adskillige forskellige versioner i ports. Et godt valg i FreeBSD, vil v\u00e6re www\/apache2.<\/p>\n\n\n\n
“make show-options”viser en hel del installationsparametre. For at bygge apache med disse, k\u00f8res f.eks. “make WITH_SUEXEC SUEXEC_UIDMIN=500 SUEXEC_DOCROOT=\/var\/www”<\/p>\n\n\n\n
Efter installationen, er det smart at s\u00e6tte “WITH_APACHE2=YES”i \/etc\/make.conf, s\u00e5ledes diverse webapplikationer ved de b\u00f8r bygge til version 2, og ikke 1, som de ellers defaulter til, hvis denne option ikke er sat.<\/p>\n\n\n\n
1.3.2 Kon\u001cguration<\/p>\n\n\n\n
Generelt g\u00e6lder det om at tillade mindst muligt globalt, og s\u00e5 tillade de enkelte ting brugerne har behov for, i deres respektive visual hosts.<\/p>\n\n\n\n
Brugertilladelser<\/p>\n\n\n\n
Mange globale options kan \u00e6ndres af den enkelte bruger, gennem .htaccess. Hvis du har sat en r\u00e6kke globale regler i httpd.conf, kan brugerne \u00e6ndre disse via .htaccess, hvilket n\u00e6ppe er \u00f8nskeligt. Derfor er det smart at n\u00e6gte<\/p>\n\n\n\n
<\/p>\n\n\n\n
brugen af .htaccess, med AllowOverride None.<\/p>\n\n\n\n
Hvis du \u00f8nsker at php kun skal v\u00e6re tilg\u00e6ngeligt for de brugere, der har behov for det, kan du sl\u00e5 php fra globalt med “php_\u001dag engine o\u001b”, og s\u00e5 tilsvarende “php_\u001dag engine on”i de enkelte virtual hosts hvor det er kr\u00e6vet.<\/p>\n\n\n\n
Beskyt kritiske \u001cler<\/p>\n\n\n\n
Nogle \u001cler b\u00f8r beskyttes ekstra godt. Dette g\u00e6lder bl.a. SSL-\u001cler, httpd.conf, .ht*.<\/p>\n\n\n\n
SSL-\u001clerne server.key (Den private n\u00f8gle) og server.crt (Det o\u001bentlige certi\u001ckat) b\u00f8r kun v\u00e6re l\u00e6sbare af root. Det kan med fordel s\u00e6ttes med ACL, og dern\u00e6st et \u001clesystem \u001dag som system immutable. Men husk at server.crt m\u00e5ske skal fornyes om et \u00e5r eller to, alt efter ens CA.<\/p>\n\n\n\n
Med hensyn til httpd.conf, kan man f.eks. have alle de statiske linjer i httpd.conf, og l\u00e5se denne \u001cl ned til det n\u00f8dvendige, ogs\u00e5 med schg-\u001daget. Og s\u00e5 have alt det der ofte \u00e6ndres, vhosts f.eks., i en \u001cl for sig, som s\u00e5 er inkluderet med Include direktivet i httpd.conf<\/p>\n\n\n\n
.ht*-\u001clerne (.htaccess, .htpasswd, .htgroup og lign.) b\u00f8r beskyttes mod download. F.eks. med dette i httpd.conf:<\/p>\n\n\n\n
<Files ~ \"^\\.ht\">\n Order allow,deny\n Deny from all\n Satisfy All\n<\/pre>\n\n\n\n<\/Files><\/p>\n\n\n\n
Derudover kan det v\u00e6re en lille (obskuritets)forbedring, at give de \u001cler man benytter til .ht*-form\u00e5l andre navne, og opbevare dem udenfor Docu- mentRoot.<\/p>\n\n\n\n
DoS-beskyttelse<\/p>\n\n\n\n
Mange (mail)serverprogrammer har indbyggede funktioner til tar-pitting, som beskyttelse mod DoS-angreb. Det har apache ikke. Som lille hj\u00e6lp, kan man justere optionen MaxClients i httpd.conf<\/p>\n\n\n\n
<\/p>\n\n\n\n
Ved at tr\u00e6kke en r\u00e6kke tunge sider fra apache, og dermed give den lidt arbejde, kan man se et relativt realistisk ram-forbrug med top. Start top, og se p\u00e5 RES (resident). Se hvad de gennemsnitsligt bruger, og vurder hvor meget ram du h\u00f8jst vil have apache m\u00e5 bruge. Del denne m\u00e6ngde med gennemsnitsm\u00e6ngden for en httpd-tr\u00e5d, og s\u00e6t da MaxClients til noget n\u00e6r dette resultat. Det kan self. afvige en del, hvis du k\u00f8rer sider med specielle krav for CPU eller ram.<\/p>\n\n\n\n
1.3.3 Moduler<\/p>\n\n\n\n
Der er mange moduler, og mange meget usikre og meget anvendte. Nogle af de prim\u00e6re beskrives kort her. I stedet for at tage en standardkon\u001cgura- tion, og sl\u00e5 de moduler fra, du ikke lige mener du har behov for, s\u00e5 start i stedet med ingenting, og s\u00e6t kun de til, som du ved du har behov for nu og her. Filen highperformance.conf f\u00f8lger med apache, og indeholder en minimalkon\u001cguration, for h\u00f8j ydeevne. Man kan f.eks. tage udgangspunkt i denne.<\/p>\n\n\n\n
mod_cgi<\/p>\n\n\n\n
Normalt har \/cgi-bin\/ en rimelig kon\u001cguration i httpd.conf, men v\u00e6r sikker p\u00e5 at AllowOverride None og Options None er sat, s\u00e5ledes man ikke kan tilg\u00e5 listevisning for denne mappe.<\/p>\n\n\n\n
Generelt er det smart at k\u00f8re cgi-programmerne som almindelige brugere. Det kan mod_suexec og cgiwrap hj\u00e6lpe med. Disse omtales senere.<\/p>\n\n\n\n
mod_php<\/p>\n\n\n\n
Der er enormt mange webapplikationer i php, der er meget anvendte og meget d\u00e5rligt og usikkert skrevet.<\/p>\n\n\n\n
PHP k\u00f8res normalt som brugeren www, og d\u00e5rlig kode kan resultere i at brugeren kan det samme som www. Normalt kan www kun skrive i \/tmp, men det kan ogs\u00e5 v\u00e6re nok til at inds\u00e6tte diverse exploits og lignende. Derfor kan det v\u00e6re smart udelukkende at benytte databaser som mysql til php’s skrivebehov.<\/p>\n\n\n\n
<\/p>\n\n\n\n
PHP kan ogs\u00e5 bruges som interpreter gennem CGI, og alts\u00e5 ikke med modulet mod_php. Dette er meget muligt langsommere, men mere sikkert. P\u00e5 denne m\u00e5de kan PHP afvikles gennem mod_suexec eller cgiwrap, som andre cgi-programmer.<\/p>\n\n\n\n
PHP-kon\u001cgurationen ligger i php.ini, men der kan laves overrides af den- ne i httpd.conf, og igen i .htaccess, hvis det tillades. Derfor er det vigtigt at s\u00e6tte AllowOverride til None, s\u00e5 brugerne ikke bare kan s\u00e6tte om p\u00e5 ens valgte PHP-options.<\/p>\n\n\n\n
Et par options, der kan v\u00e6re smarte at s\u00e6tte i PHP-kon\u001cgurationen, er: register_globals=o\u001b, s\u00e5 variable i URL’en, ikke direkte indvirker i PHP- scriptet. display_errors=o\u001b, uddybende fejlmeddelelser er guld v\u00e6rd for an- gribere. Selv med denne sl\u00e5et fra, kan administratorerne se fejllog i apaches error log. variables_order=”GPCS”, Get Post Cookie Server. Hvis du f.eks. aldrig skal bruge Get, kan denne sikres lidt med kun at s\u00e6tte til “PCS”<\/p>\n\n\n\n
mod_perl<\/p>\n\n\n\n
Perl er meget fornuftigt anvendt til meget cgi. Mange moduler er skrevet i C(++), og kan derfor nemt byde p\u00e5 diverse bu\u001ber over\u001dows og lign., hvis disse er skrevet d\u00e5rligt. Perl kan k\u00f8res som cgi, men det giver en noget d\u00e5rlig performance, n\u00e5r interpreteren skal loades hver gang et script skal k\u00f8res. Derfor er mod_perl smart. Det loader perl ind, n\u00e5r webserveren startes, og giver dermed ret store performanceforbedringer.<\/p>\n\n\n\n
Som ekstra sikkerhed b\u00f8r PerlTaintCheck On s\u00e6ttes i httpd.conf, for at sikre at ting der g\u00e5r gennem mod_perl, overholder perls “taint-regler (perl -t). Disse kontrollerer at scriptet behandler alle input-data, f\u00f8r de bruges. Det sikrer imod en del input-baserede angreb. Se “man perlsec”for mere info om perls tainting.<\/p>\n\n\n\n
Andre moduler<\/p>\n\n\n\n
mod_dav giver mulighed for HTTP options SEARCH, PROPFIND og lign. Der har v\u00e6ret mange sikkerhedsm\u00e6ssige problemer med disse, s\u00e5 tag det endelig v\u00e6k, med mindre du har behov for det.<\/p>\n\n\n\n
<\/p>\n\n\n\n
mod_include giver SSI-mulighed. F.eks. #include og #exec. Sidstn\u00e6vnte kan hurtigt resultere i skadelige kommandoer. Sl\u00e5 det fra hvis du ikke har behov for det.<\/p>\n\n\n\n
mod_info og mod_status giver en del brugbar debugging-information, men ogs\u00e5 en masse god information for en angriber. Sl\u00e5 dem fra, s\u00e5l\u00e6nge du ikke debugger systemet. N\u00e5r du bruger dem, s\u00e5 tilf\u00f8j IP-baseret tilgang, og gerne login.<\/p>\n\n\n\n
mod_autoindex giver mulighed for listevisning, n\u00e5r \u001cler som index.html og index.php ikke \u001cndes. Det kan give angribere adgang til vigtig infor- mation, hvis brugerne ikke er opm\u00e6rksomme p\u00e5 listevisningsmulighederne. Derfor b\u00f8r dette v\u00e6re sl\u00e5et fra globalt, og s\u00e5 blot tilladt de enkelte steder der er behov for det.<\/p>\n\n\n\n
mod_userdir giver brugerne mulighed for at oprette sider i deres hjemme- mapper, i public_html, som f\u00e5r adresserne dom\u00e6ne.tld\/ brugernavn. Dette b\u00f8r ligeledes v\u00e6re sl\u00e5et fra globalt, og s\u00e5 kun sat p\u00e5 de enkelte vhosts hvor brugerne har behov for det.<\/p>\n\n\n\n
1.3.4 \u00c6ndr informationsbannere<\/p>\n\n\n\n
For at minimere informationsl\u00e6kager, er det smart at \u00e6ndre de bannere a- pache kommer med. Som standard sendes banner med apache-version, samt aktive moduler og deres versioner, ud i alle HTTP-responses, og apache- versionen i autogenererede dokumenter, som listevisning og fejlmeldinger. I Sendmail og Bind er det nemt at s\u00e6tte et banner selv, men det kr\u00e6ver kil- dekode\u00e6ndring i apache. Derimod kan ServerTokens s\u00e6ttes til ProductOnly, og ServerSignature s\u00e6ttes til O\u001b i httpd.conf.<\/p>\n\n\n\n
1.3.5 K\u00f8r CGI-programmer som normale brugere<\/p>\n\n\n\n
Normalt k\u00f8rer alle cgi-programmer, som den samme bruger som apache, nem- lig www. Det f\u00e5r mange begynderbrugere til at oprette mapper og \u001cler med helt gale permissions, s\u00e5 deres cgi-programmer kan b\u00e5de l\u00e6se og skrive. Det kan nemt resultere i at een brugers cgi-program, kan skade andre brugeres.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Det vil v\u00e6re smart at lade en brugers cgi-program k\u00f8re som denne bruger. Det kan man via cgiwrap eller mod_suexec.<\/p>\n\n\n\n
cgiwrap<\/p>\n\n\n\n
Kan installeres fra www\/cgiwrap, og giver \u001clerne cgiwrap og cgiwrapd som begge er setuid root. Disse kan l\u00e6gges i \/usr\/local\/www\/cgi-bin\/, og b\u00f8r v\u00e6re eksekverbare, men ikke l\u00e6sbare, for alle.<\/p>\n\n\n\n
For at k\u00f8re et script gennem cgiwrap, bruges URL’en domain.tld\/cgi- bin\/cgiwrap\/username\/scriptname. cgiwrapd er en debugger-udgave, som giver en masse brugbar information. Denne information er guld v\u00e6rd for en angriber, og derfor b\u00f8r man kun s\u00e6tte cgiwrapd op n\u00e5r man selv har behov for den.<\/p>\n\n\n\n
mod_suexec<\/p>\n\n\n\n
Modulet laver 20 tjek, der prim\u00e6rt omhandler hvorvidt cgi-programmet har lov til at k\u00f8re. Idet modulet er t\u00e6t integreret i apache, til forskel fra c- giwrap, har det visse fordele. Det giver to nye direktiver, der kan bruges i vhosts i httpd.conf; User og Group. Disse siger hvilken bruger og gruppe cgi-programmer for den enkelte vhost skal k\u00f8res som.<\/p>\n\n\n\n
Ulempen er at apache skal restartes n\u00e5r der er \u00e6ndret p\u00e5 kon\u001cgurationen, men fordelene er den t\u00e6ttere integration, og det at kon\u001cgurations\u00e6ndringer kan laves af \u001dere administratorer, hvor cgiwrap kr\u00e6ver man kan \u00e6ndre setuid root-\u001cler<\/p>\n\n\n\n
1.4 TLS<\/p>\n\n\n\n
Det vi normalt kalder SSL, er i dag ofte TLS. Det er en transportlagsprotokol, lige over HTTP. Det sikrer at tra\u001ckken mellem klient og v\u00e6rt er krypteret, og det forsikrer klienten om at v\u00e6rten er den denne udgiver sig for at v\u00e6re.<\/p>\n\n\n\n
For at bruge TLS, skal du have en privat n\u00f8gle (server.key) og et o\u001bentligt certi\u001ckat. Certi\u001ckatet skal signeres. Det kan k\u00f8bes dyrt hos Verisign, billigt hos InstantSSL, gratis med CAcert, eller ved at signere det selv. Selvsignerede certi\u001ckater sikrer ikke at andre har godkendt \u00e6gtheden af en. Hvis ikke<\/p>\n\n\n\n
<\/p>\n\n\n\n
klienternes browsere har godkendt ens CA, f\u00e5r brugerne en del advarsler n\u00e5r de tilg\u00e5r ens side, hvilket m\u00e5ske ikke er smart.<\/p>\n\n\n\n
Eksempel p\u00e5 brug af TLS(\/SSL) i en vhost i apache:<\/p>\n\n\n\n
<VirtualHost *:443>\n DocumentRoot \/usr\/local\/www\/data\/\n SSLEngine On\n SSLCertificateFile \/usr\/local\/etc\/apache2\/ssl.crt\/server.crt\n SSLCertificateKeyFile \/usr\/local\/etc\/apache2\/ssl.key\/server.key\n<\/pre>\n\n\n\n<\/VirtualHost>\n<\/pre>\n\n\n\nHvis du f\u00f8ler at serveren cpu-forbrug er for h\u00f8jt, n\u00e5r man forbindelser med TLS er igang, er det m\u00e5ske relevant at s\u00e6tte et kryptoakseleratorkort i serveren. B\u00e5de Open- og FreeBSD underst\u00f8tter en stor m\u00e6ngde kort, og det er normalt blot at s\u00e6tte kortet i, og s\u00e5 k\u00f8rer det.<\/p>\n\n\n\n
1.4.1 Udeluk svage algoritmer<\/p>\n\n\n\n
Du kan s\u00e6tte direktivet SSLCipherSuite til et m\u00f8nster, der afspejler hvilke krypteringsalgoritmer du ikke tillader, foretr\u00e6kker osv. Hvis du er for h\u00e5rd, risikerer du at gamle versioner af IE ikke kan forbinde til dig, og dette vil ikke endgang blive vist i log\u001clerne.<\/p>\n\n\n\n
Denne kan m\u00e5ske bruges: TLSv1:!ADH:!EXP:!NULL:!MD5:!LOW:+HIGH:+MEDIUM, som siger ja til TLS-ciphers, nej til Di\u001ee-Hellman, exportniveau-algoritmer, NULL-algoritmer og de der i “man ciphers”er markederde som svage algo-
ritmer. Dern\u00e6st siger den ja til de der er h\u00f8jtmarkerede, og til sidst ja til mellemmarkerede.<\/p>\n\n\n\n<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Lars Sommer\u00a0< lasg@lasg.dk >\u00a018. november 2006Noter til bogen Mastering FreeBSD and OpenBSD Security del 2 1.1 Angreb En webserver st\u00e5r ofte \u00e5ben for hele verden, s\u00e5 folk kan komme og se p\u00e5 hjem- mesiderne. Dette medf\u00f8rer at webservere ofte er udsat for angreb. \u00c5rsagerne til angreb mod webservere kan eksempelvis v\u00e6re: Der er mange forskellige midler til at opn\u00e5 disse m\u00e5l. Hvordan de enkelte fungerer, er ikke s\u00e5 relevant i denne sammenh\u00e6ng. 1.2 S\u00e6rlige trusler 1.2.1 Arbitr\u00e6r programk\u00f8rsel Denne truselstype er meget udbredt og meget skadelig. Angriberen kan f\u00e5 lov at k\u00f8re programmer eller kode efter eget valg, via huller i, typisk, cgi- programmer eller php-kode. Angriberen kan enten k\u00f8re de programmer der allerede ligger p\u00e5 serveren (og give sig selv ssh-, eller telnet-adgang), eller selv uploade rootkits og lignende. Selv hvis angriberen ikke kan k\u00f8re en shell umiddelbart, kan alle exploits der normalt kun g\u00e6lder for lokalt brug, pludselig v\u00e6re lige s\u00e5 skadelige som de til fjernbrug. 1.2.2 Programmisbrug SQL-, HTML-, Java-script-kode og XSS kan bruges helt uden operativsyste- met eller netv\u00e6rket er klar over det. Derfor er det ekstremt vigtigt, at man stoler p\u00e5 de webapplikationer man benytter sig af, og sp\u00e6rrer disse i chroot eller jails, hvis de ikke er 100% til at stole p\u00e5. M\u00e5ske kan angriberen ikke direkte f\u00e5 adgang til serveren gennem s\u00e5- danne programmer, men i stedet \u001cske andre brugere cookies med login- informationer, sende spam via f.eks. en formmail.pl og lignende. 1.2.3 Fill\u00e6kage Nogle webservere eller webapplikationer er ikke opm\u00e6rksomme p\u00e5 alle typer af encoding, og kan m\u00e5ske narres til at lade angriberen downloade bruger- databasen, n\u00e5r den bare encodes korrekt. Mulighed for upload af data er lige s\u00e5 slemt. Der kan eksempelvis uploa- des ondsindede programmer, som kan ramme enten lokale, eller fjernsystemer hvor tra\u001ckken s\u00e5 kommer fra din server. Der kan overskrives vigtige \u001cler, og sidst kan der l\u00e6gges ulovligt materiale op, som andre s\u00e5 kan hente fra dig. 1.3 Apache Hvis du kan n\u00f8jes med en lille simpel webserver, uden SSL, store dynamiske sider osv, er thttpd m\u00e5ske mere attraktiv. Men ellers apache. Der er to store versioner; 1.3 og 2. Hvis du allerede k\u00f8rer et stort og stabilt site med 1.3, er det ok at blive, men starter du noget nyt, s\u00e5 brug endelig version 2. Et par fordele ved 2, er at threading og generel performance er stort forbedret. Den underst\u00f8tter multitr\u00e5dede moduler, og har en del moduler inkluderet som standard (SSL f.eks.) Kon\u001cgurationen af 2 er ogs\u00e5 nemmere. Moduler kan sl\u00e5es til og fra med een enkelt linje pr modul, og beh\u00f8ver ikke st\u00e5 i korrekt r\u00e6kkef\u00f8lge som i version 1. 1.3.1 Installation I OpenBSD er det stadig en chrooted apache 1.3 der f\u00f8lger med. Version 2 \u001cndes ikke endgang i ports. I FreeBSD er der ingen med som standard, men adskillige forskellige versioner i ports. Et godt valg i FreeBSD, vil v\u00e6re www\/apache2. “make show-options”viser en hel del installationsparametre. For at bygge apache med disse, k\u00f8res f.eks. “make WITH_SUEXEC SUEXEC_UIDMIN=500 SUEXEC_DOCROOT=\/var\/www” Efter installationen, er det smart at s\u00e6tte “WITH_APACHE2=YES”i \/etc\/make.conf, s\u00e5ledes diverse webapplikationer ved de b\u00f8r bygge til version 2, og ikke 1, som de ellers defaulter til, hvis denne option ikke er sat. 1.3.2 Kon\u001cguration Generelt g\u00e6lder det om at tillade mindst muligt globalt, og s\u00e5 tillade de enkelte ting brugerne har behov for, i deres respektive visual hosts. Brugertilladelser Mange globale options kan \u00e6ndres af den enkelte bruger, gennem .htaccess. Hvis du har sat en r\u00e6kke globale regler i httpd.conf, kan brugerne \u00e6ndre disse via .htaccess, hvilket n\u00e6ppe er \u00f8nskeligt. Derfor er det smart at n\u00e6gte brugen af .htaccess, med AllowOverride None. Hvis du \u00f8nsker at php kun skal v\u00e6re tilg\u00e6ngeligt for de brugere, der har behov for det, kan du sl\u00e5 php fra globalt med “php_\u001dag engine o\u001b”, og s\u00e5 tilsvarende “php_\u001dag engine on”i de enkelte virtual hosts hvor det er kr\u00e6vet. Beskyt kritiske \u001cler Nogle \u001cler b\u00f8r beskyttes ekstra godt. Dette g\u00e6lder bl.a. SSL-\u001cler, httpd.conf, .ht*. SSL-\u001clerne server.key (Den private n\u00f8gle) og server.crt (Det o\u001bentlige certi\u001ckat) b\u00f8r kun v\u00e6re l\u00e6sbare af root. Det kan med fordel s\u00e6ttes med ACL, og dern\u00e6st et \u001clesystem \u001dag som system immutable. Men husk at server.crt m\u00e5ske skal fornyes om et \u00e5r eller to, alt efter ens CA. Med hensyn til httpd.conf, kan man f.eks. have alle de statiske linjer i httpd.conf, og l\u00e5se denne \u001cl ned til det n\u00f8dvendige, ogs\u00e5 med schg-\u001daget. Og s\u00e5 have alt det der ofte \u00e6ndres, vhosts f.eks., i en \u001cl for sig, som s\u00e5 er inkluderet med Include direktivet i httpd.conf .ht*-\u001clerne (.htaccess, .htpasswd, .htgroup og lign.) b\u00f8r beskyttes mod download. F.eks. med dette i httpd.conf: <Files ~ “^\\.ht”> Order allow,deny Deny from all Satisfy All <\/Files> Derudover kan det v\u00e6re en lille (obskuritets)forbedring, at give de \u001cler man benytter til .ht*-form\u00e5l andre navne, og opbevare dem udenfor Docu- mentRoot. DoS-beskyttelse Mange (mail)serverprogrammer har indbyggede funktioner til tar-pitting, som beskyttelse mod DoS-angreb. Det har apache ikke. Som lille hj\u00e6lp, kan man justere optionen MaxClients i httpd.conf Ved at tr\u00e6kke en r\u00e6kke tunge sider fra apache, og dermed give den lidt arbejde, kan man se et relativt realistisk ram-forbrug med top. Start top, og se p\u00e5 RES (resident). Se hvad de gennemsnitsligt bruger, og vurder hvor meget ram du h\u00f8jst vil have apache m\u00e5 bruge. Del denne m\u00e6ngde med gennemsnitsm\u00e6ngden for en httpd-tr\u00e5d, og s\u00e6t da MaxClients til noget n\u00e6r dette resultat. Det kan self. afvige en del, hvis du k\u00f8rer sider med specielle krav for CPU eller ram. 1.3.3 Moduler Der er mange moduler, og mange meget usikre og meget anvendte. Nogle af de prim\u00e6re beskrives kort her. I stedet for at tage en standardkon\u001cgura- tion, og sl\u00e5 de moduler fra, du ikke lige mener du har behov for, s\u00e5 start i stedet med ingenting, og s\u00e6t kun de til, som du ved du har behov for nu og her. Filen highperformance.conf f\u00f8lger med apache, og indeholder en minimalkon\u001cguration, for h\u00f8j ydeevne. Man kan f.eks. tage udgangspunkt i denne. mod_cgi Normalt har \/cgi-bin\/ en rimelig kon\u001cguration i httpd.conf, men v\u00e6r sikker p\u00e5 at AllowOverride None og Options None er sat, s\u00e5ledes man ikke kan tilg\u00e5 listevisning for denne mappe. Generelt er det smart at k\u00f8re cgi-programmerne som almindelige brugere. Det kan mod_suexec og cgiwrap hj\u00e6lpe med. Disse omtales senere. mod_php Der er enormt mange webapplikationer i php, der er meget anvendte og meget d\u00e5rligt og usikkert skrevet. PHP k\u00f8res normalt som brugeren www, og d\u00e5rlig kode kan resultere i at brugeren kan det samme som www. Normalt kan www kun skrive i \/tmp, men det kan ogs\u00e5 v\u00e6re nok til at inds\u00e6tte diverse exploits og lignende. Derfor kan det v\u00e6re smart udelukkende at benytte databaser som mysql til php’s skrivebehov. PHP kan ogs\u00e5 bruges som interpreter gennem CGI, og alts\u00e5 ikke med modulet mod_php. Dette er meget muligt langsommere, men mere sikkert. P\u00e5 denne m\u00e5de kan PHP afvikles gennem mod_suexec eller cgiwrap, som andre cgi-programmer. PHP-kon\u001cgurationen ligger i php.ini, men der kan laves overrides af den- ne i httpd.conf, og igen i .htaccess, hvis det tillades. Derfor er det vigtigt at s\u00e6tte AllowOverride til None, s\u00e5 brugerne ikke bare kan s\u00e6tte om p\u00e5 ens valgte PHP-options. Et par options, der kan v\u00e6re smarte at s\u00e6tte i PHP-kon\u001cgurationen, er: register_globals=o\u001b, s\u00e5 variable i URL’en, ikke direkte indvirker i PHP- scriptet. display_errors=o\u001b, uddybende fejlmeddelelser er guld v\u00e6rd for an- gribere. Selv med denne sl\u00e5et fra, kan administratorerne se fejllog i apaches error log. variables_order=”GPCS”, Get Post Cookie Server. Hvis du f.eks. aldrig skal bruge Get, kan denne sikres lidt med kun at s\u00e6tte til “PCS” mod_perl Perl er meget fornuftigt anvendt til meget cgi. Mange moduler er skrevet i C(++), og kan derfor nemt byde p\u00e5 diverse bu\u001ber over\u001dows og lign., hvis disse er skrevet d\u00e5rligt. Perl kan k\u00f8res som cgi, men det giver en noget d\u00e5rlig performance, n\u00e5r interpreteren skal loades hver gang et script skal k\u00f8res. Derfor er mod_perl smart. Det loader perl ind, n\u00e5r webserveren startes, og giver dermed ret store performanceforbedringer. Som ekstra sikkerhed b\u00f8r PerlTaintCheck On s\u00e6ttes i httpd.conf, for at sikre at ting der g\u00e5r gennem mod_perl, overholder perls “taint-regler (perl -t). Disse kontrollerer at scriptet behandler alle input-data, f\u00f8r de bruges. Det sikrer imod en del input-baserede angreb. Se “man perlsec”for mere info om perls tainting. Andre moduler mod_dav giver mulighed for HTTP options SEARCH, PROPFIND og lign. Der har v\u00e6ret mange sikkerhedsm\u00e6ssige problemer med disse, s\u00e5 tag det endelig v\u00e6k, med mindre du har behov for det. mod_include giver SSI-mulighed. F.eks. #include og #exec. Sidstn\u00e6vnte kan hurtigt resultere i skadelige kommandoer. Sl\u00e5 det fra hvis du ikke har behov for det. mod_info og mod_status giver en del brugbar debugging-information, men ogs\u00e5 en masse god information for en angriber. Sl\u00e5 dem fra, s\u00e5l\u00e6nge du ikke debugger systemet. N\u00e5r du bruger dem, s\u00e5 tilf\u00f8j IP-baseret tilgang, og gerne login. mod_autoindex giver mulighed for listevisning, n\u00e5r \u001cler som index.html og index.php ikke \u001cndes. Det kan give angribere adgang til vigtig infor- mation, hvis brugerne ikke er opm\u00e6rksomme p\u00e5 listevisningsmulighederne. Derfor b\u00f8r dette v\u00e6re sl\u00e5et fra globalt, og s\u00e5 blot tilladt de enkelte steder der er behov for det. mod_userdir giver brugerne mulighed for at oprette sider i deres hjemme- mapper, i public_html, som f\u00e5r adresserne dom\u00e6ne.tld\/ brugernavn. Dette b\u00f8r ligeledes v\u00e6re sl\u00e5et fra globalt, og s\u00e5 kun sat p\u00e5 de enkelte vhosts hvor brugerne har behov for det. 1.3.4 \u00c6ndr informationsbannere For at minimere informationsl\u00e6kager, er det smart at \u00e6ndre de bannere a- pache kommer med. Som standard sendes banner med apache-version, samt aktive moduler og deres versioner, ud i alle HTTP-responses, og apache- versionen i autogenererede dokumenter, som listevisning og fejlmeldinger. I Sendmail og Bind er det nemt at s\u00e6tte et banner selv, men det kr\u00e6ver kil- dekode\u00e6ndring i apache. Derimod kan ServerTokens s\u00e6ttes til ProductOnly, og ServerSignature s\u00e6ttes til O\u001b i httpd.conf. 1.3.5 K\u00f8r CGI-programmer som normale brugere Normalt k\u00f8rer alle cgi-programmer, som den samme bruger som apache, nem- lig www. Det f\u00e5r mange begynderbrugere til at oprette mapper og \u001cler med helt gale permissions, s\u00e5 deres cgi-programmer kan b\u00e5de l\u00e6se og skrive. Det kan nemt resultere i at een brugers cgi-program, kan skade andre brugeres. Det vil v\u00e6re smart at lade en brugers cgi-program k\u00f8re som denne bruger. Det kan man via cgiwrap eller mod_suexec. cgiwrap Kan installeres fra www\/cgiwrap, og giver \u001clerne cgiwrap og cgiwrapd som begge er setuid root. Disse kan l\u00e6gges i \/usr\/local\/www\/cgi-bin\/, og b\u00f8r v\u00e6re eksekverbare, men ikke l\u00e6sbare, for alle. For at k\u00f8re et script gennem cgiwrap, bruges URL’en domain.tld\/cgi- bin\/cgiwrap\/username\/scriptname. cgiwrapd er en debugger-udgave, som giver en masse brugbar information. Denne information er guld v\u00e6rd for en angriber, og derfor b\u00f8r man kun s\u00e6tte cgiwrapd op n\u00e5r man selv har behov for den. mod_suexec Modulet laver 20 tjek, der prim\u00e6rt omhandler hvorvidt cgi-programmet har lov til at k\u00f8re. Idet modulet er t\u00e6t integreret i apache, til forskel fra c- giwrap, har det visse fordele. Det giver to nye direktiver, der kan bruges i vhosts i httpd.conf; User og Group. Disse siger hvilken bruger og gruppe cgi-programmer for den enkelte vhost skal k\u00f8res som. Ulempen er at apache skal restartes n\u00e5r der er \u00e6ndret p\u00e5 kon\u001cgurationen, men fordelene er den t\u00e6ttere integration, og det at kon\u001cgurations\u00e6ndringer kan laves af \u001dere administratorer, hvor cgiwrap kr\u00e6ver man kan \u00e6ndre setuid root-\u001cler 1.4 TLS Det vi normalt kalder SSL, er i dag ofte TLS. Det er en transportlagsprotokol, lige over HTTP. Det sikrer at tra\u001ckken mellem klient og v\u00e6rt er krypteret, og det forsikrer klienten om at v\u00e6rten er den denne udgiver sig for at v\u00e6re. For at bruge TLS, skal du have en privat n\u00f8gle (server.key) og et o\u001bentligt certi\u001ckat. Certi\u001ckatet skal signeres. Det kan k\u00f8bes dyrt hos Verisign, billigt hos InstantSSL, gratis med CAcert, eller ved at signere det selv. Selvsignerede certi\u001ckater sikrer ikke at andre har godkendt \u00e6gtheden af en. Hvis ikke klienternes browsere har godkendt ens CA, f\u00e5r brugerne en del advarsler n\u00e5r de tilg\u00e5r ens side, hvilket m\u00e5ske ikke er smart. Eksempel p\u00e5 brug af TLS(\/SSL) i en vhost i apache: <VirtualHost *:443> DocumentRoot \/usr\/local\/www\/data\/ SSLEngine On SSLCertificateFile \/usr\/local\/etc\/apache2\/ssl.crt\/server.crt SSLCertificateKeyFile \/usr\/local\/etc\/apache2\/ssl.key\/server.key <\/VirtualHost>…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[25],"tags":[24,45,35,46,44],"class_list":["post-502","post","type-post","status-publish","format-standard","hentry","category-computer","tag-computer","tag-freebsd","tag-it-sikkerhed","tag-openbsd","tag-unix"],"acf":[],"_links":{"self":[{"href":"https:\/\/lasg.dk\/wp\/wp-json\/wp\/v2\/posts\/502","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lasg.dk\/wp\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lasg.dk\/wp\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lasg.dk\/wp\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lasg.dk\/wp\/wp-json\/wp\/v2\/comments?post=502"}],"version-history":[{"count":1,"href":"https:\/\/lasg.dk\/wp\/wp-json\/wp\/v2\/posts\/502\/revisions"}],"predecessor-version":[{"id":504,"href":"https:\/\/lasg.dk\/wp\/wp-json\/wp\/v2\/posts\/502\/revisions\/504"}],"wp:attachment":[{"href":"https:\/\/lasg.dk\/wp\/wp-json\/wp\/v2\/media?parent=502"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lasg.dk\/wp\/wp-json\/wp\/v2\/categories?post=502"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lasg.dk\/wp\/wp-json\/wp\/v2\/tags?post=502"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}