È sicuro usare * nessuna autenticazione * per servizi di ascolto solo su localhost?

Question

È sicuro usare * nessuna autenticazione * per servizi di ascolto solo su localhost?

#1 da (5 voti)
#2 da (2 voti)
#3 da (2 voti)
#4 da (2 voti)

9

Ho molte applicazioni installate sul mio server che usano un front web webui per controllare l'applicazione.

Dato che sono l'unico utente del server, di solito lego queste applicazioni a 127.0.0.1.

Poiché i servizi sono legati a localhost, ho assunto che io possa disabilitare l'autenticazione (solitamente username + password), per queste applicazioni, perché nessuno al di fuori della mia macchina locale può nemmeno accedere ai servizi.

Accedo ai servizi utilizzando un tunnel SSH; quindi essenzialmente mi dà accesso ai servizi locali del server da qualsiasi macchina.

Un esempio: ho installato BitTorrent Sync. L'app utilizza un webui che leghiamo a 127.0.0.1. Quindi disabilito l'autenticazione username + password per questo webui e accedendo utilizzando un tunnel SSH dalla mia postazione remota.

La mia domanda è, è sicuro? Sarebbe una pratica migliore per abilitare lo schema di autenticazione dell'applicazione? (Suppongo di no, dal momento che è legato localhost). E 'possibile che un utente malintenzionato in qualche modo possa spoofare 127.0.0.1 e ottenere l'accesso?

authentication ssh web-service

posta BBedit 19.05.2014 - 12:07

fonte

4 risposte

Leggi altre domande sui tag authentication ssh web-service

Docker fornisce la stessa sicurezza di un vm [duplicato] In dettaglio, come funziona la ripartizione / accelerazione / terminazione SSL?

score 5 · Answer 1

Potrebbero provare lo spoofing 127.0.0.1 (non sono sicuro che la scheda di rete lo accetterebbe o meno, non dovrebbero, ma chissà se ogni installazione lo gestisce correttamente), ma anche se potessero non lo farebbero ottenere una risposta fintanto che si tratta di un webui. Potrebbe essere un problema per le connessioni UDP, ma le richieste web non sono UDP.

La preoccupazione più grande sarebbe che se un utente malintenzionato avesse mai raggiunto un certo livello di accesso locale al proprio server, sarebbe quindi in grado di accedere ai propri servizi più facilmente. Ad esempio, se potessero ottenere qualche tipo di proxy sul tuo server, avrebbero accesso completo dato che sarebbero in grado di comportarsi come localhost.

Se ottengono l'accesso completo al server, probabilmente siete probabilmente uguali, ma l'autenticazione sui servizi, specialmente se si spinge fino a essere utilizzata per proteggere gli archivi stessi, potrebbe limitare il danno di un server compromesso.

score 2 · Answer 2

Is it possible for an attacker to somehow spoof 127.0.0.1 and get access?

Non ne sono a conoscenza.

Tuttavia, qualsiasi applicazione in esecuzione sul tuo computer potrebbe essere in grado di accedere ai servizi associati a localhost . Esecuzione di un'applicazione dannosa o compromessa potrebbe essere al di fuori del modello di minaccia, ma vale la pena segnalarlo. È probabile che se qualcuno ha accesso al tuo computer, ciò che potrebbe accadere ai tuoi torrent potrebbe non essere rilevante.

score 2 · Answer 3

Una funzionalità del kernel Linux chiamata Reverse Path Filtering elimina o registra i pacchetti in arrivo su un'interfaccia (in questo caso network) in cui la risposta dovrebbe andare su un'interfaccia diversa (in questo caso loopback).

Un tipico ambiente server ha molti privilegi per utenti e servizi in esecuzione su quel server. Qualunque sia l'accesso locale su quel server, ha accesso al loopback e ai servizi non autenticati in esecuzione su di esso. Un account guest potrebbe avere privilegi minimi di file, ma ha lo stesso privilegio di qualsiasi altro utente quando si tratta di accedere ai servizi locali.

In un ambiente utente desktop e in cui hai un'applicazione Web su localhost, qualcuno che intercetta la tua comunicazione HTTP trasparente (ne hai definitivamente alcuni), può inserire JavaScript e quindi utilizzare il browser come un proxy per l'accesso all'interno la tua rete e il localhost. Lo stesso vale quando cadi vittima di XSS su qualsiasi applicazione web a cui accedi o se la tua applicazione locale è vulnerabile a CSRF. Questo è stato interessantemente illustrato in una storia recente e popolare chiamata Come ho hackerato il router . E ci sono altri servizi locali come SMTP che usano la comunicazione testuale e sono accessibili tramite XSS e CSRF. Gli scenari Man-In-The-Browser verranno visualizzati anche sui tuoi dati locali.

score 2 · Answer 4

C'è un attacco abbastanza poco conosciuto chiamato rebinding DNS che può essere usato per sfruttare una situazione del genere. Qui è un grande video di Robert "RSnake" Hansen che spiega le sue basi. Guardalo. Ora.

... ok, fatto? Quindi, ecco lo scenario: supponiamo tu abbia un'interfaccia utente Web per un servizio privato in esecuzione su 127.0.0.1:80 senza alcuna autenticazione di alcun tipo che lo protegga. E supponiamo che il servizio non si preoccupi delle intestazioni host. Nella maggior parte dei casi, i tipi di servizi che eseguiresti lì non lo faranno, almeno per impostazione predefinita.

Entra nel diavolo. Imposta una pagina Web sul suo server a 123.123.123.123:80 e associa il suo nome di dominio, www.evil.com , all'IP. Quindi ti invia un'email: "Hey, check out this cool website I found: http://www.evil.com/" . E tu, non avendo idea di cosa sta succedendo, apri il link. La pagina mostra un divertente video gatto, ma in realtà fa una richiesta XHR costringendo il nome del dominio a rebind al tuo indirizzo IP locale, 127.0.0.1 .

Ora c'è una pagina web a http://www.evil.com/ con gli script di Evil Guy in esecuzione su di esso, ma il nome di dominio effettivamente punta alla tua interfaccia utente web privata. Ciò significa che gli script nella pagina hanno accesso completo al tuo strumento interno. Normalmente la politica della stessa origine impedirebbe tale accesso, ma ora i protocolli, i nomi di dominio e le porte corrispondono, quindi non c'è nulla che possa fare. E così, sei fregato.

La soluzione: usa l'autenticazione. O assicurati che i tuoi servizi web rispettino l'intestazione host e falliscano quando ricevi richieste di host sconosciuti. O, per sicurezza, fai entrambe le cose.