mongodb --auth opzione

Question

mongodb --auth opzione

#1 da (2 voti)

0

Supponiamo che eseguo mongodb come servizio con l'opzione --auth (che richiede un nome utente e una password per i dati CRUD) in una shell AWS EC2 (che non richiede una password quando sudo )

Ora, supponiamo che qualcuno abbia violato il terminale del mio stack via SSH e non possano ancora interrogare mongodb a causa dell'opzione --auth. (irrilevante come, ma diciamo che ha rubato il file .pem, rubato la password di amministratore di AWS e cambiato i permessi di sicurezza in modo che chiunque può ssh in da qualsiasi indirizzo IP, comunque è successo, sono dentro)

Questa persona non può semplicemente uccidere il processo mongodb, cambiare il file di configurazione (o semplicemente non usare affatto il file di configurazione) e avviare mongodb senza l'opzione --auth?

A quel punto, potevano CRUD tutto ciò che volevano. Se questo è il caso, ho 2 domande:

Quali sono i suggerimenti per prevenirlo come un rischio per la sicurezza? (possedere forse il processo mongodb da parte di un utente / gruppo che nemmeno sudo permetterebbe di spegnersi ?, un'altra combinazione di username / password sconosciuta che l'hacker avrebbe bisogno di crack forzato?)
L'uso di --auth matter a tutti (supponiamo che abbia già protetto il mio database attraverso l'uso di endpoint pubblici basati su token - perché non voglio che le persone inviino nomi utente e password i miei punti finali. Vedo che è meno sicuro rispetto all'utilizzo di un token)

molte grazie

authentication mongodb aws ssh

posta user1709076 10.02.2017 - 01:02

fonte

1 risposta

Leggi altre domande sui tag authentication mongodb aws ssh

Limitare l'accesso ai file per l'amministrazione e l'applicazione su Windows 10? Connessione proxy non crittografata con connessione backend crittografata

score 2 · Answer 1

1) What are suggestions on preventing this as a security risk? (perhaps owning the mongodb process by a user/group that not even sudo would a allow shutting down? i.e another unknown username/password combination that the hacker would need to brute-force crack?)

Difesa in profondità richiede più livelli di sicurezza. Hai ragione nel ritenere che un utente malintenzionato che accede a un superutente abbia un accesso ampio al tuo server, ma sembra che stia banalizzando lo sforzo per farlo. Nello scenario suggerito ci sono diversi gravi problemi di sicurezza: un utente malintenzionato ha accesso alle credenziali AWS, al client .pem file e all'accesso senza password sudo . Con questo livello di accesso, un utente malintenzionato ha il pieno controllo dell'infrastruttura AWS.

Un elenco non completo di misure di sicurezza proattive da considerare include:

Blocca l'account ec2-user SSH predefinito in modo che possa essere utilizzato solo localmente o da un set limitato di IP affidabili.
Aggiorna la configurazione sudoers (utilizzando visudo ) per evitare o limitare il login senza password. L'accesso sudo può essere limitato a un sottoinsieme di comandi con o senza richiesta di conferma per la password dell'utente. Una configurazione NOPASSWD per alcuni o tutti i comandi sudo è una comodità, ma certamente non è un requisito.
Limita l'esposizione alla rete SSH tramite firewall o wrapper TCP (vedi: Mantenendo sicuro l'accesso SSH ).
Crea un account SSH con accesso più limitato per l'accesso remoto.
Aggiungi monitoraggio / avviso per tentativi di accesso remoto (riuscito e non riuscito)

2) Does using --auth matter at all (supposing i've already secured my database through the use-of public facing token-based end-points - because I don't want people sending usernames & passwords to my end-points. I see that as less secure than using a token)

La protezione degli endpoint API pubblici è un esercizio correlato (ma separato) dalla protezione del database. Un'analogia nella vita reale potrebbe essere: "se hai un lucchetto sul tuo cancello anteriore, dovresti bloccare anche la porta principale o mettere i tuoi oggetti di valore in una cassastrong?"

Avere autenticazione e amp; il controllo di accesso abilitato fa parte della strategia di difesa in profondità e rappresenta un primo passo nella lista di controllo di sicurezza MongoDB . Se qualcuno ha compromesso il proprio server applicazioni o un altro host di rete attendibile, non dovrebbe automaticamente ottenere pieno accesso alla distribuzione del database. Il controllo dell'accesso può anche prevenire alcuni errori logici dell'applicazione: ad esempio, assicurando che l'API sia limitata alle operazioni CRUD e non possa essere utilizzata (ab) per inviare comandi di riconfigurazione del cluster. È necessario considerare la sicurezza tra gli utenti finali e l'API, l'API e la distribuzione del database e tutti gli altri aspetti dell'infrastruttura. Una buona strategia di difesa approfondita includerà il monitoraggio e il rilevamento delle intrusioni in modo da essere a conoscenza di quando le tue difese sono state testate e potenzialmente compromesse.