El caràcter universal de les aplicacions web va portar a la seva proliferació. Diverses s'executen en paral·lel: un webmail, un wiki, algun sistema de treball en grup, fòrums, una galeria de fotos, un blog, etc. Moltes d'aquestes aplicacions es basen en la pila «LAMP» (Linux, Apache, MySQL, PHP). Lamentablement, moltes d'aquestes aplicacions també van ser escrites sense tenir molt en compte els problemes de seguretat. Les dades procedents de fora s'utilitzen massa sovint amb poca o cap validació. Es poden utilitzar valors especialment elaborats per subvertir una crida a una ordre perquè se n'executi una altra. Molts dels problemes més obvis s'han solucionat a mesura que ha passat el temps, però els nous problemes de seguretat apareixen regularment.

L'actualització regular de les aplicacions web és, per tant, una obligació, per evitar que qualsevol «cracker» (ja sigui un atacant professional o un «script kiddy») pugui explotar una vulnerabilitat coneguda. El risc real depèn del cas, i va des de la destrucció de dades fins a l'execució arbitrària de codi, incloent la desconfiguració del lloc web.

Una vulnerabilitat en una aplicació web s'utilitza sovint com a punt de partida per a intents d'intrusió. El que segueix és una breu revisió de les possibles conseqüències.

Les conseqüències d'una intrusió tindran diversos nivells d'obvietat depenent de les motivacions de l'atacant. Els «Script-kiddies» només apliquen receptes que troben en llocs web; la majoria de vegades desmunten una pàgina web o n'eliminen dades. En casos més subtils, afegeixen continguts invisibles a les pàgines web per tal de millorar les referències als seus propis llocs en els motors de cerca.

Un atacant avançat anirà més enllà. Un escenari desastrós podria anar de la següent manera: l'atacant guanya la capacitat d'executar ordres com l'usuari www-data, però executar una ordre requereix moltes manipulacions. Per fer la seva vida més fàcil, instal·len altres aplicacions web especialment dissenyades per executar remotament molts tipus d'ordres, com ara navegar pel sistema de fitxers, examinar permisos, carregar o descarregar arxius, executar ordres, i fins i tot proporcionar un intèrpret de comandes via xarxa. Sovint, la vulnerabilitat permet executar una ordre wget que descarregarà algun programari maliciós a /tmp/, per després executar-lo. El programari maliciós es descarrega sovint des d'un lloc web extern compromès anteriorment, per amagar pistes i fer més difícil d'esbrinar l'origen real de l'atac.

En aquest punt, l'atacant té prou llibertat de moviments que sovint instal·la un bot d'IRC (un robot que connecta a un servidor d'IRC i que pot ser controlat per aquest canal). Aquest bot s'utilitza sovint per compartir arxius il·legals (còpies no autoritzades de pel·lícules o programari, etc.). Un atacant determinat pot voler anar encara més lluny. El compte www-data no permet l'accés complet a la màquina, i l'atacant intentarà obtenir privilegis d'administrador. Ara bé, això no hauria de ser possible, però si l'aplicació web no estava actualitzada, les possibilitats són que el nucli i altres programes també estan obsolets; això a vegades deriva d'una decisió de l'administrador que, malgrat saber sobre la vulnerabilitat, ignorar actualitzar el sistema, ja que no hi ha usuaris locals. L'atacant pot aprofitar-se d'aquesta segona vulnerabilitat per obtenir accés de superusuari.

Ara l'atacant és propietari de la màquina; normalment intentaran mantenir aquest accés privilegiat el màxim temps possible. Això implica la instal·lació d'un «rootkit», un programa que substituirà alguns components del sistema perquè l'atacant pugui tornar a obtenir els privilegis d'administrador més endavant (vegeu ULLADA RÀPIDA Els paquets checksecurity i chkrootkit/rkhunter); el «rootkit» també intenta amagar la seva pròpia existència, així com qualsevol rastre de la intrusió. Un subvertit ps ometrà llistar alguns processos, netstat no llistarà algunes de les connexions actives, i així successivament. Utilitzant els permisos de superusuari, l'atacant podia observar tot el sistema, però no va trobar dades importants; així que intentaran accedir a altres màquines de la xarxa corporativa. Analitzant el compte de l'administrador i els arxius d'història, l'atacant troba a quines màquines s'hi accedeix de manera rutinària. En substituir sudo o ssh per un programa subvertit, l'atacant pot interceptar algunes de les contrasenyes de l'administrador, que utilitzaran en els servidors detectats... i des d'allà la intrusió pot anar-se propagant.

Es tracta d'un escenari de malson que pot evitar-se amb diverses mesures. Les següents seccions descriuen algunes d'aquestes mesures.

Una vegada que es coneixen els possibles problemes de seguretat, s'han de tenir en compte en cada pas del procés de desplegament d'un servei, especialment quan es triï el programari per instal·lar. Molts llocs web mantenen una llista de vulnerabilitats recentment descobertes, que poden donar una idea d'un registre de l'historial de seguretat abans que es desplegui algun programari en particular. Per descomptat, aquesta informació ha d'estar equilibrada contra la popularitat d'aquest programari: un programa més àmpliament utilitzat és un objectiu més temptador, i per tant serà objecte d'un examen més detallat. D'altra banda, un programa “de nínxol” pot estar ple de forats de seguretat que mai són publicats a causa de la falta d'interès en una auditoria de seguretat.

En el món del programari lliure hi ha un ampli marge d'elecció, i triar una peça de programari sobre una altra hauria de ser una decisió basada en els criteris que s'apliquen localment. Més característiques impliquen un major risc d'una vulnerabilitat amagada en el codi; triar el programa més avançat per a una tasca pot ser contraproduent, i un millor enfocament és normalment triar el programa més simple que compleix els requisits.

La majoria de distribucions de Linux instal·len per defecte una sèrie de serveis Unix i moltes eines. En molts casos, aquests serveis i eines no són necessàries per als propòsits reals per als quals l'administrador va configurar la màquina. Com a directriu general en qüestions de seguretat, el programari no necessari és millor si està desinstal·lat. De fet, no té cap sentit assegurar un servidor FTP, si una vulnerabilitat en un altre servei no utilitzat es pot utilitzar per obtenir privilegis d'administrador en tota la màquina.

Amb el mateix raonament, els tallafocs sovint es configuraran per permetre només l'accés als serveis que estan destinats a ser accessibles públicament.

Els ordinadors actuals són prou potents per permetre l'allotjament de diversos serveis en la mateixa màquina física. Des d'un punt de vista econòmic, aquesta possibilitat és interessant: només un ordinador per administrar, un consum d'energia més baix, etc. No obstant això, des del punt de vista de la seguretat, aquesta elecció pot ser un problema. Un servei compromès pot portar accés a tota la màquina, que al seu torn compromet els altres serveis allotjats en el mateix ordinador. Aquest risc es pot mitigar aïllant els serveis. Això es pot aconseguir ja sigui amb virtualització (cada servei està allotjat en una màquina virtual o un contenidor dedicat), o amb AppArmor/SELinux (tenint cada dimoni de servei un conjunt de permisos adequadament dissenyat).

El debat sobre la seguretat ens porta immediatament al cap la protecció contra els atacs de les «crackers» anònims que s'amaguen en la jungla d'Internet; però un fet que sovint s'oblida és que els riscos també venen de dins: un empleat que està a punt de sortir de l'empresa podria descarregar arxius sensibles dels projectes importants i vendre'ls a competidors; un venedor negligent podria deixar el seu escriptori sense tancar la sessió durant una reunió amb un nou prospecte; un usuari maldestre podria eliminar el directori equivocat per error, etc.

La resposta a aquests riscos pot implicar solucions tècniques: no s'han de concedir més dels permisos requerits als usuaris i les còpies de seguretat regulars són una obligació. Però en molts casos, la protecció adequada implicarà la formació dels usuaris per a evitar riscos.

No té sentit assegurar els serveis i les xarxes si els propis ordinadors no estan protegits. Les dades importants mereixen ser emmagatzemades en discs durs d'intercanvi en calent en matrius RAID, perquè els discs durs fallen eventualment i la disponibilitat de dades és una necessitat. Però si un noi repartidor de pizzes pot entrar a l'edifici, entrar a la sala del servidor i fugir amb uns quants discs durs seleccionats, una part important de la seguretat no es compleix. Qui pot entrar a la sala del servidor? Està controlat l'accés? Aquestes preguntes mereixen consideració (i una resposta) quan s'està avaluant la seguretat física.

La seguretat física també inclou tenir en compte els riscos d'accidents com els incendis. Aquest risc particular és el que justifica l'emmagatzematge dels mitjans de còpia de seguretat en un edifici separat, o almenys en una caixa forta a prova de foc.

Un administrador és, més o menys implícitament, de confiança pels seus usuaris, així com dels usuaris de la xarxa en general. Per tant, hauria d'evitar qualsevol negligència que les persones malèvoles puguin explotar.

Un atacant que prengui el control de la vostra màquina i després l'utilitzi com a base avançada (conegut com a «relay system» o “sistema de transmissió”) a partir de la qual realitzi altres activitats nefastes podria comportar problemes legals, ja que la part atacada inicialment veuria l'atac procedent del vostre sistema, i per tant podeu ser considerats atacants (o còmplices). En molts casos, l'atacant utilitzarà el vostre servidor com a relé per enviar correu brossa, que no hauria de tenir gaire impacte (excepte el potencial ingrés en llistes negres que podria restringir la vostra capacitat d'enviar correus electrònics legítims), però no serà agradable. En altres casos, es poden causar problemes més importants des de la vostra màquina, per exemple, atacs de denegació de servei. A vegades això provocarà pèrdues d'ingressos, ja que els serveis legítims no estaran disponibles i les dades poden ser destruïts; a vegades això també implicarà un cost real, perquè la part atacada pot iniciar procediments legals contra vós. Els titulars de drets poden demandar-vos si una còpia no autoritzada d'una obra protegida per la llei de drets d'autor és compartida des del vostre servidor, així com altres empreses obligades per acords de nivell de servei si estan obligades a pagar sancions després de l'atac des de la vostra màquina.

Quan es produeixen aquestes situacions, alegar innocència no sol ser suficient; com a mínim, necessitareu proves convincents que mostrin l'activitat sospitosa en el vostre sistema procedent d'una adreça IP donada. Això no serà possible si descureu les recomanacions d'aquest capítol i deixeu que l'atacant aconsegueixi accés a un compte privilegiat («root», en particular) i l'utilitzi per amagar les seves traces.