Product SiteDocumentation Site

14.6. Altres consideracions de seguretat

La seguretat no és només un problema tècnic; més que res, es tracta de bones pràctiques i de comprendre els riscos. Aquesta secció revisa alguns dels riscos més comuns, així com algunes bones pràctiques que, depenent del cas, haurien d'augmentar la seguretat o reduir l'impacte d'un atac amb èxit.

14.6.1. Riscs inherents de les aplicacions web

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.
Updating web applications regularly is therefore a must, lest any cracker (whether a professional attacker or a “script kiddy“) can exploit a known vulnerability. The actual risk depends on the case, and ranges from data destruction to arbitrary code execution, including web site defacement.

14.6.2. Saber què esperar

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.
The consequences of an intrusion will have various levels of obviousness depending on the motivations of the attacker. “Script-kiddies“ only apply recipes they find on web sites; most often, they deface a web page or delete data. In more subtle cases, they add invisible contents to web pages so as to improve referrals to their own sites in search engines.
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.
Now the attacker owns the machine; they will usually try to keep this privileged access for as long as possible. This involves installing a rootkit, a program that will replace some components of the system so that the attacker will be able to obtain the administrator privileges again at a later time (see also ULLADA RÀPIDA Els paquets checksecurity i chkrootkit/rkhunter); the rootkit also tries hiding its own existence as well as any traces of the intrusion. A subverted ps program will omit to list some processes, netstat will not list some of the active connections, and so on. Using the root permissions, the attacker was able to observe the whole system, but didn't find important data; so they will try accessing other machines in the corporate network. Analyzing the administrator's account and the history files, the attacker finds what machines are routinely accessed. By replacing sudo or ssh with a subverted program, the attacker can intercept some of the administrator's passwords, which they will use on the detected servers… and the intrusion can propagate from then on.
Es tracta d'un escenari de malson que pot evitar-se amb diverses mesures. Les següents seccions descriuen algunes d'aquestes mesures.

14.6.3. Triar el programari sàviament

Once the potential security problems are known, they must be taken into account at each step of the process of deploying a service, especially when choosing the software to install. Many web sites keep a list of recently-discovered vulnerabilities, which can give an idea of a security track record before some particular software is deployed. Of course, this information must be balanced against the popularity of said software: a more widely-used program is a more tempting target, and it will be more closely scrutinized as a consequence. On the other hand, a niche program may be full of security holes that never get publicized due to a lack of interest in a security audit.
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.

14.6.4. Gestió d'una màquina com un tot

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

14.6.5. Els usuaris també juguen

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.

14.6.6. Seguretat física

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.

14.6.7. Responsabilitat legal

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.