HTTPS è sicuro o più sicuro di SSH se entrambi hanno una whitelist di indirizzi IP?

Question

HTTPS è sicuro o più sicuro di SSH se entrambi hanno una whitelist di indirizzi IP?

Naviga le tue risposte

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

2

Mi chiedo se un endpoint dell'API HTTPS sia sicuro o più sicuro di SSH.

Endpoint API

L'endpoint dell'API richiederebbe HTTPS
L'autenticazione API utilizza una chiave API POST'd.
La lunghezza minima richiesta della chiave API potrebbe essere arbitrariamente lunga
L'endpoint dell'API accetta solo le connessioni dagli indirizzi IP autorizzati.
L'URL dell'endpoint dell'API non sarebbe pubblicamente disponibile o collegato da nessuna parte. Solo l'applicazione client saprebbe di cosa si tratta.
L'applicazione client che si connette all'endpoint non accetta i cyphers SSL deboli.

Connessione SSH

Ai fini di questa domanda, faremo le seguenti ipotesi sulla connessione SSH a cui stiamo confrontando.

La lunghezza minima della password richiesta è di 8 caratteri con lettere maiuscole, minuscole e numeri richiesti.
Il dominio a cui ti colleghi è il dominio pubblico (ad es. per link ti connetti usando ssh domain.com)

Considerazioni

Alcune considerazioni a cui ho pensato quali potrebbero influire sul fatto che uno sia più sicuro dell'altro sono:

Il rilevamento dell'indirizzo IP da parte di HTTPS è affidabile quanto lo fa SSH? Suppongo che entrambi guardino solo a ciò che il client li invia e quindi non possono essere fidati al 100%, ma forniscono comunque un certo livello di sicurezza.
Credo che SSH abbia un meccanismo integrato per prevenire tentativi rapidi di riprovare. So che HTTPS da solo non lo fa, ma in molti casi in cui la sicurezza è fondamentale per la sua integrazione nel livello del servizio web.

La mia impressione

La mia impressione sarebbe che l'endpoint dell'API sarebbe effettivamente più sicuro di SSH per i seguenti motivi - ma non sono un esperto di sicurezza da nessuna parte, quindi mi piacerebbe avere un risposta solida:

Con SSH, il potenziale utente malintenzionato sa quale dominio indirizzare (ad es. dominio ssh.com). Ma con l'API, l'URL non sarebbe conosciuto così per poter iniziare a provare ad attaccarlo, prima dovevano capire qual era l'URL.
Il livello di sicurezza della password dell'API è maggiore

Contesto

Il motivo per cui sto chiedendo questo è che sto prendendo in considerazione la costruzione di un endpoint API che consentirebbe a un utente affidabile e autenticato di accedere a molti dati potenzialmente sensibili. Sarebbe un potente strumento che consentirebbe di scrivere molto rapidamente la logica di business dell'applicazione disaccoppiata.

Il motivo per cui sto chiedendo se è sicuro come SSH è perché suppongo che i potenziali utenti di questa applicazione abbiano SSH abilitato con al massimo una whitelist di indirizzi IP come ulteriore livello di sicurezza.

Quindi ciò significa che le funzionalità di questo endpoint dell'API sono già presenti tramite SSH. Se l'endpoint non presentasse alcun rischio aggiuntivo oltre al rischio che è presente con SSH, allora considererei un livello accettabile di rischio. Ma se fosse meno sicuro, probabilmente non lo considererei accettabile.

UPDATE: aggiunta di note sui cyphers deboli all'endpoint API.

http ssh tls

posta kalenjordan 16.05.2014 - 05:49

fonte

2 risposte

Leggi altre domande sui tag http ssh tls

In che modo le grandi aziende assicurano che altre persone non registrino un nuovo dominio di primo livello con il loro nome? Identificazione del traffico crittografato sospetto [duplicato]

score 5 · Answer 1

Is HTTPS's detection of IP address as reliable as how SSH does it?

Entrambi sono protocolli su TCP, in cui si verifica l'indirizzo IP quando l'handshake TCP è completato. (Con un indirizzo IP completamente falso i pacchetti probabilmente non verrebbero indirizzati a te, quindi non potresti completare l'handshake TCP (o più precisamente avere 1 su 4 miliardi di possibilità di indovinarlo) che richiede di rispondere con un numero di sequenza di bit che il server ha indirizzato a te). Un potente avversario che ha il controllo su un server sulla rete tra il client e il server può falsificare il tuo indirizzo IP e raccogliere e non inoltrare i pacchetti destinati a un indirizzo IP simulato, ma richiede loro di avere il controllo completo di un server sulla rotta effettiva scelto attraverso la rete.

I believe that SSH has a built in mechanism to prevent rapid retry attempts

In realtà non è davvero necessario configurare fail2ban per farlo. (Sì, ci sono alcune opzioni per inserire i ritardi all'interno dei tentativi di password ripetute all'interno di una sessione ssh, ma non sono così grandiosi).

Ancora non capisco la configurazione. Sia SSH che HTTPS comprendono un'ampia varietà di configurazioni. Ad esempio, l'utilizzo della connessione HTTPS autofirmata in cui non si effettua il controllo dei certificati non attendibili sarà vulnerabile agli attacchi man in the middle (almeno con SSH avvisa molto strong quando i certificati host cambiano). Allo stesso modo ci sono alcuni protocolli HTTPS deboli - non si dovrebbe usare SSLv2 o cifratura debole.

La connessione HTTPS / SSH utilizza certificati client? Questo non dovrebbe essere automatizzato?

Se hai un'API che deve essere eseguita da un server web, farlo in modo sicuro con HTTPS è la via naturale. SSH è progettato per la connessione remota a un altro computer riga di comando. Sì, è possibile utilizzarlo per altre operazioni come l'esecuzione di comandi remoti o il traffico di rete di tunneling, ma se si desidera offrire un'API basata sul Web sicura ha molto più senso utilizzare TLS con il controllo dei certificati client e server (anche se sono self-signed).

score 1 · Answer 2

Cercherò di offrire alcuni puntatori / contrappunti:

The API endpoint would require HTTPS

Quale può essere MITM se la tua rete non è sicura. Penso che sia necessario esaminare la progettazione della rete prima del livello applicazione / presentazione.

The API authentication would use a POST'd API key. The minimum required length of the API key could basically be arbitrarily long

Se la tua rete non è sicura, una chiave API potrebbe essere sniffata, modificata, ecc., quindi se crei dire una chiave di 200 caratteri, a che serve, se è visibile in testo chiaro perché la tua rete è vulnerabile ?

The API endpoint would only accept connections from whitelisted IP addresses.

La lista bianca / lista nera non funziona poiché gli autori di attacchi possono forzare i trigger per ottenere nella lista nera gli indirizzi autorizzati. Lo spiegherò con il tuo commento fail2ban.

The API endpoint's URL would not be publicly available or linked from anywhere. Only the client application would know what it was.

Ora tutto ciò di cui ti devi preoccupare è assicurarti che l'applicazione client non si trovi su una macchina vulnerabile.

The minimum required password length is 8 characters with upper case, lower case, and number required.

SSH non è la soluzione di sicurezza "end all" in cui, solo perché lo stai eseguendo, non sarai attaccato o compromesso. Le password complesse, sebbene utili, saranno poco efficaci contro un utente la cui macchina è stata infettata da un programma di registrazione della sequenza di tasti che rende inutilizzabile qualsiasi password.

Is HTTPS's detection of IP address as reliable as how SSH does it? I'm guessing both of them just look at what the client sends them and therefore can't be 100% trusted

Un IP è un IP è un nauseam annuncio IP. La ricerca avviene a livello di rete, ed è lì che si desidera spostare la messa a fuoco. Quindi senza andare riga per riga:

In uno scenario fail2ban: quello che stai facendo qui sta dicendo: " Guarda, vai nei miei file di log, vedi se c'è qualcosa di sospetto, se è così, allora devi aggiungere l'indirizzo dei criminali a una lista nera perché voglio fermarlo. "

Scenario: "In qualità di utente malintenzionato, produco rumore utilizzando netcat. Eseguo la scansione del server utilizzando l'indirizzo di 0.0.0.0 che ora ho bloccato il mondo. Come stesso aggressore, pre-generi pacchetti che ti scandiscono come percorso predefinito. .. Il tuo socio in affari che ho raccolto dai comunicati stampa sul tuo sito ... Indirizzi casuali. " Questi sono ora tutti bloccati. Per non parlare, più regole hai sul tuo firewall, più tempo ci vuole per elaborare i pacchetti. Per capire di più, leggi " Failed2Ban "

La tua scommessa BEST è quella di creare BLOCK ALL e ALLOW IN SPECIFICS in questo modo non devi preoccuparti dei randoms (indirizzi falsificati, ecc.)

Nell'istanza che hai descritto, stai cercando di eseguire attività che dovrebbero essere sul livello di rete, stai cercando di ottenere responsabilità di livello diverso per risolvere i problemi. Non funzionerà.

Se fossi io dal punto di vista dell'equazione, se possibile, mirerei a una connessione basata su VPN.

Client --> send data --> only using a tunnel --> server
Connection established/made --> decrypt data from the tunnel, give it to the right application

In questa istanza (tunnel IPSEC VPN) hai un po 'più di protezione dagli attacchi di replay (se usi AH), quindi è più difficile per MITM che gli attacchi su SSL. Con SSL, aggiungi l'overhead per "errori del certificato" (che la maggior parte delle persone ignorerà, ecc.)

Il che mi fa chiedere, questa connessione è per i clienti dedicati, il mondo, ecc., chiedo perché questo tipo di configurazione (tunnel VPN) non funzionerà per le connessioni dinamiche. Ad esempio, ottieni un nuovo client casuale che si è registrato, ora hai bisogno di un tunnel * 100.000 nuovi clienti, contro la creazione di 24 tunnel per i clienti dedicati.

È necessario pensare molto al tuo scenario, ma per la maggior parte è questo che mi è venuto in mente leggendo la tua domanda.