Diciamo che stiamo eseguendo un servizio associato a localhost (127.0.0.1), e l'obiettivo è di consentire solo client locali (cioè solo dalla stessa macchina)
Quali tecniche potrebbero essere utilizzate per infrangere questa sicurezza? Esistono ulteriori misure che potrebbero essere utilizzate per rafforzarla?
La prima cosa principale è assicurarsi che il firewall sull'host sia configurato per eliminare correttamente i pacchetti in arrivo con l'indirizzo di origine o di destinazione impostato su 127.0.0.1.
In circostanze normali, non dovrebbe esserci alcun pacchetto proveniente dalla rete e che mostri tali indirizzi. Tuttavia, un utente malintenzionato può tentare di contraffare tali pacchetti per raggiungere i servizi di ascolto locali.
Non so quale tipo di altri servizi sono in ascolto sulla tua macchina, ma se qualsiasi servizio può essere usato come relay devi assicurarti che sia configurato correttamente per impedire di inoltrare nulla ai servizi di ascolto locali.
Ad esempio, se si dispone di un proxy HTTP in esecuzione su questo host, un utente malintenzionato può utilizzare questo proxy per richiedere l'host "127.0.0.1": dal punto di vista del firewall questa sarà una connessione valida proveniente dalla rete al proxy servizio, e localmente questa sarà una comunicazione legittima tra due servizi locali (il proxy e la porta locale designata). Il proxy HTTP qui è solo un esempio, tale tecnica può anche funzionare con altri servizi, inclusi i servizi in cui le connessioni di inoltro non sono la funzionalità principale (il L'attacco di rimbalzo FTP , ad esempio, è un classico esempio di tale minaccia).
Una potenziale vulnerabilità sarebbe quella di compromettere un account / servizio con privilegi limitati e usarlo come pivot per accedere al servizio associato a localhost.
Di solito preferisco i socket UNIX per questo scopo poiché puoi applicare permessi utente / gruppo su di essi (che saranno gestiti in modo trasparente dal sistema operativo, l'utente non dovrà mantenere ancora un'altra password). Inoltre, sono anche un po 'più veloci, il che li rende preferibili per IPC sulla stessa macchina.
Nota che le autorizzazioni di socket non sono sempre rispettate su alcune varianti UNIX e potrebbe essere necessaria una sintonizzazione specifica del sistema operativo (come aumentare il numero di connessioni consentite per socket).
Se il servizio fornisce un'interfaccia web potrebbe essere vulnerabile agli attacchi CSRF, agli attacchi XSS o allo script "stesso sito" . Tutti questi possono essere attivati semplicemente visitando il sito Web degli aggressori esterno, che di per sé potrebbe essere causato da malvertising o phishing. Per questi attacchi non importa se il servizio è in ascolto solo su localhost, poiché è solo necessario che l'host sia raggiungibile dal browser web locale. Gli stessi problemi esistono con l'attacco di host intranet dall'esterno.
Considera anche che hostname localhost non è esattamente uguale a IP 127.0.0.1 (naturalmente deve essere risolto per primo) e nella maggior parte delle situazioni si basa su una voce nel file hosts o su un server resolver / dns in grado di risolvere 127.0.0.1. Quindi, assicurati di specificare rigorosamente 127.0.0.1 invece di localhost quando si implementano misure di sicurezza, altrimenti dovrai fare un passo indietro e prendere in considerazione anche i problemi di sicurezza nel risolutore.
La risposta dipende da diversi fattori. Alcuni che possono o non possono essere applicati:
Leggi altre domande sui tag routing dns dns-spoofing