GNU/Linux >> Linux Esercitazione >  >> Linux

Posso fidarmi ciecamente di 127.0.0.1?

La comunicazione tramite 127.0.0.1 può essere considerata solo come un altro meccanismo IPC, ma che riutilizza i protocolli esistenti. Proprio come la memoria condivisa oi socket o pipe di dominio UNIX, è uno degli innumerevoli modi in cui due processi possono comunicare su un singolo sistema. Se ritieni che i processi sul tuo sistema non siano stati compromessi, puoi fidarti "ciecamente" delle connessioni che passano attraverso 127.0.0.1.


Se sai che l'indirizzo IP all'altra estremità di un socket TCP è 127.0.0.1, ciò garantisce che l'amministratore di sistema ha configurato il firewall per reindirizzare questa particolare connessione o che l'altra estremità del socket TCP è un processo in esecuzione su la stessa macchina. Quindi, se ti fidi della tua macchina server nel suo insieme, puoi fidarti di 127.0.0.1. Tuttavia, ci sono dei vantaggi nel non utilizzare un socket TCP, per una difesa approfondita.

Devi stare attento a come implementi il ​​controllo localhost. Localhost è 127.0.0.1 fino al giorno in cui non lo è, ad esempio perché passi a una versione di una libreria che utilizza IPv6 per impostazione predefinita o perché decidi di aggiungere una qualche forma di proxy di inoltro al mix per consentirti di eseguire il due servizi su macchine o contenitori differenti. Se inizi a utilizzare un proxy, fai attenzione a controllare nel posto giusto. E ovviamente devi assicurarti di non ospitare nient'altro che potrebbe essere pericoloso sulla stessa macchina (anche se perché dovresti farlo in quei giorni di VM e container).

Sapere che stai parlando con la stessa macchina ti dice solo che alcuni processo sulla stessa macchina si trova all'altra estremità della connessione. Non ti dice che è il processo giusto. Durante il normale funzionamento, presumibilmente, entrambi i processi sono in esecuzione. Ma se accade qualcosa di sbagliato, come un processo che si arresta in modo anomalo dopo aver esaurito la memoria a causa di un attacco denial-of-service, la porta sarebbe libera per l'ascolto di un altro processo. E in qualsiasi momento, qualsiasi processo locale può connettersi a un server in esecuzione. Ciò richiede che l'attaccante sia in grado di eseguire un processo localmente, ma potrebbe trattarsi di un processo senza privilegi che altrimenti non sarebbe in grado di fare molto. Quindi, anche se fare affidamento su 127.0.0.1 non è una vulnerabilità, ti lascia aperto all'escalation dei privilegi.

Se puoi, usa invece un socket Unix. I socket Unix e TCP funzionano allo stesso modo tranne che per specificare l'indirizzo a cui connettersi o ascoltare, quindi non richiederebbe molte modifiche al codice. Un socket Unix può avere autorizzazioni o può essere creato dal supervisore genitore e nient'altro può connettersi ad esso. Con un socket Unix, hai la garanzia che non solo ciò che si trova all'altra estremità del socket sia in esecuzione sulla stessa macchina, ma che sia il processo previsto. Ciò ti rende vulnerabile solo a una violazione della sicurezza nel servizio di autenticazione o nel servizio principale, piuttosto che a una violazione in qualsiasi cosa in esecuzione sulla stessa macchina.


Linux
  1. Posso utilizzare GDB per eseguire il debug di un processo in esecuzione?

  2. exit() può non riuscire a terminare il processo?

  3. Postgres non consente localhost ma funziona con 127.0.0.1

  4. Come posso sapere quale processo sta usando lo scambio?

  5. Come posso fermare un processo symfony che è in ascolto su http://127.0.0.1:8000

L'ID thread di un processo multithread può essere uguale all'ID processo di un altro processo in esecuzione?

Perché non posso terminare questo processo su Linux?

Un processo può essere eseguito indipendentemente da qualsiasi shell?

Un processo può avere un proprietario? Cosa significa?

Posso eseguire il nohup/screening di un processo già avviato?

Non riesco a connettermi a MySQL usando 'localhost' ma usando '127.0.0.1' va bene?