Il sabotare un account di hosting web condiviso minaccia la sicurezza degli account di pari livello essendo condivisi sullo stesso server?
Sia che si tratti di configurazioni htaccess, di posting di credenziali di accesso e specifiche di configurazione pubblicamente, o simili, quali sono le principali vulnerabilità che un client di hosting condiviso può affrontare da account maligni di pari livello? O dai loro completi errori di noob.
Dipende dal grado di isolamento tra gli account. Semplificando quello che altrimenti sarebbe un argomento abbastanza ampio:
Il server web viene eseguito come, diciamo, wwwrun:wwwdata , tutti i siti Web sono di gruppo riscrivibili, gli account sono ftp-chroot nel proprio web-root. Uno script dannoso sul sito A viene quindi eseguito come gruppo wwwdata e può leggere e scrivere file su altri Webroot. Si potrebbe dire che tali account sono nati compromessi .
Tuttavia, alcune piccole imprese che mantengono siti Web per i clienti (completo outsourcing) potrebbero scegliere di operare in questo modo, dal momento che "siamo gli unici ad accedere al server". Mancanza di manutenzione, dipendenti scontenti e installazione di strutture vulnerabili di terze parti, di solito non in questo ordine, sono i principali rischi. Cioè se il cliente A non vuole aggiornare una versione pesantemente personalizzata di MyNiceBlog 1.0 a fixed 1.5 di sicurezza perché il porting delle personalizzazioni sarebbe costoso, sta mettendo in pericolo tutti gli altri siti sulla stessa macchina.
Il server web viene eseguito come sopra ma esistono dei limiti ("modalità sicure") che provano impedendo a uno script di uscire dal suo web jail. Il problema è che il processo si sta astenendosi volontariamente dall'usare alcuni dei diritti e dei poteri che ha ancora . Quindi è necessario anche rimuovere alcune funzioni e funzionalità (ad esempio, l'esecuzione di uno script di shell) che potrebbe portare uno script malevolo a poter utilizzare nuovamente quei poteri. Il sito è solo marginalmente più sicuro, e perde molte caratteristiche e prestazioni nell'affare.
Il server web viene eseguito con le autorizzazioni complete, quindi per ogni richiesta che riceve, genera una copia di se stesso con autorizzazioni ridotte. Ogni webroot è quindi anche di proprietà di un utente specifico con un proprio gruppo e non vi è alcun accesso incrociato. L'utente viene inserito nel sito Web. Se tutto funziona come dovrebbe, questa configurazione è ragionevolmente sicura - quindi è necessario diffidare degli exploit di escalation dei privilegi che potrebbero far funzionare le cose in quanto non dovrebbero . A seconda della piattaforma e del software installato, la superficie di attacco potrebbe essere abbastanza grande. Alcune funzioni (ad esempio il caricamento di moduli dinamici) potrebbero ancora richiedere il blocco.
Inoltre, i processi non sono isolati a livello di rete; quindi per esempio qualsiasi richiesta proveniente dal sito A sarebbe vista dal sito B come proveniente dallo stesso host, il che può essere negativo per (diciamo) server di database. Se il sito A ha un GRANT ALL PRIVILEGES ON mydb.* TO root@localhost , il sito B può connettersi a quel database sullo stesso "localhost" con accesso completo e A none the wiser.
Ogni istanza del server web viene eseguita in ciò che equivale a una macchina virtuale a sé stante, con una rete indipendente. I siti non possono vedersi e, se lo fanno, lo fanno con indirizzi IP esterni, quindi il server DB A non può scambiare una richiesta di accesso dal sito B per una richiesta dal suo interno. Tuttavia, il contenimento delle risorse potrebbe essere un problema, e le connessioni al esterno potrebbero essere NATted in modo che siano indistinguibili. Il sito A potrebbe quindi inviare e-mail fingendo di essere il sito B, ad esempio, oppure potrebbe tentare di recuperare tutti gli slot di I / O di memoria, larghezza di banda o disco per influire negativamente sul sito A. Alcune funzioni di basso livello potrebbero essere condivise tra macchine e possono essere usato per montare attacchi, ad es lettura dell'orologio e della casualità per sconfiggere gli schemi di autenticazione.
Questo è principalmente per la società che fornisce l'hosting condiviso, poiché ovviamente i modi in cui queste aziende hanno impostato l'hosting condiviso possono essere diversi. Una potenziale strada per l'attacco si trova all'interno del filesystem e degli account.
Un sistema operativo multiutente adatto come Linux si basa su un approccio fondamentalmente sicuro alle autorizzazioni dell'utente. File un set di permessi per ogni file. Ciò si ottiene assegnando a ciascun file sia la proprietà di utenti e gruppi sia un insieme di privilegi per tre gruppi di persone:
Come utente su un server web host condiviso, è probabile che non sarai in grado di leggere, tanto meno scrivere all'esterno della tua home directory. Certamente non dovresti essere in grado di navigare nella directory home o nella root dei documenti di altri utenti. Tuttavia, vi è un rischio fondamentale nell'uso degli account app. Prendiamo ad esempio l'account nobody per eseguire apache, se qualcuno guadagnasse i privilegi di nobody , avrebbe accesso alle configurazioni di Apache di interi server. Quindi, tutti i siti, ecc.
Spesso, sì, questo è il caso.
A seconda del meccanismo per la separazione dell'account in uso, i malintenzionati potrebbero essere in grado di eludere la protezione fornita dall'host e attaccare altri siti. La sicurezza in quest'area è in genere abbastanza scarsa che la maggior parte degli attaccanti tenterà movimenti laterali tra i siti sullo stesso server. Funziona abbastanza spesso per farne parte della loro strategia. Ecco alcuni dei livelli di isolamento in uso oggi e la protezione che forniscono. Assumerò apache, poiché è ciò che è comune. Sebbene questi stessi principi si applichino con altri software server.
Se non vengono apportate personalizzazioni di sicurezza, il server Web eseguirà un singolo utente ("apache" o "nessuno" o "www-data") condiviso tra tutti i siti, mentre i file saranno di proprietà di specifici utenti FTP. L'intenzione è di limitare il tipo di accesso pubblico (apache) assicurandosi che non abbia accesso in scrittura ai file. Sfortunatamente, questo accordo non è compatibile con la maggior parte delle attuali applicazioni Web che si aspettano che gli utenti possano caricare file, incluso il codice eseguibile, consentendo all'aggiornamento automatico, all'installazione di estensioni e ad altre attività amministrative eseguite attraverso il sito. / p>
In questa configurazione, il codice in esecuzione su qualsiasi sito ha lo stesso accesso ai file di un altro sito come quello stesso sito. Questa configurazione porta facilmente a compromessi per molte applicazioni Web.
Con SuExec, le applicazioni CGI vengono eseguite con le autorizzazioni del proprietario del sito anziché utilizzare le autorizzazioni proprie di Apache. suPHP e suhosin estendono questo comportamento anche a PHP (che tradizionalmente non funziona come eseguibile CGI). Anche FastCGI, incluso fcgid, fornisce questo stesso comportamento.
Sotto questo regime, i file sono in genere ancora leggibili dall'account utente di Apache, ma solo scrivibili dall'account del proprietario del sito. Questo limita la maggior parte dei tipi di spostamenti laterali, ma consente comunque un numero limitato di attacchi.
Uno di questi attacchi che ho osservato è tale che l'autore dell'attacco crea collegamenti simbolici ai file di configurazione per altri siti sul server, in questo modo:
/home/user1/public_html/foo.txt -> /home/user2/public_html/wp-config.php
L'utente quindi esplora direttamente quel file e la configurazione che contiene (comprese le password del database) viene visualizzata all'utente malintenzionato.
Un nuovo modulo sperimentale di Apache chiamato mod_ruid2 di Kees Monshouwer esegue il processo di apache stesso sotto le autorizzazioni dell'utente. Questo modulo è ora disponibile sui server cPanel, il che significa che è ampiamente distribuito dagli ambienti di hosting condiviso. Ciò protegge contro l'attacco descritto in precedenza, ma non protegge da autorizzazioni e gestione improprie, vulnerabilità di escalation dei privilegi e altri problemi a livello di sistema. Inoltre, non è compatibile con numerose funzionalità ed estensioni comuni.
È possibile eseguire il server in un regime di isolamento utilizzando chroot e funzionalità simili (come cgroup) per offrire isolamento e sicurezza aggiuntivi senza le spese della virtualizzazione. Questa opzione non è stata tradizionalmente portata avanti molto lontano, però.
Senza dare a ciascun utente il proprio server, dare a ciascun utente il proprio server virtuale è la cosa migliore. Questo è il nucleo dell'hosting "cloud" e offre una sicurezza relativamente strong, ma a costi piuttosto elevati.
Leggi altre domande sui tag server webserver shared-hosting