Come disabilitare il port forwarding locale SSH?

20

Ho un server che esegue Ubuntu e il demone OpenSSH. Chiamiamolo S1.

Uso questo server da macchine client (chiamiamone una C1) per fare un tunnel inverso SSH usando il port forwarding remoto, ad es .:

ssh -R 1234:localhost:23 login@S1

Su S1, uso il file predefinito sshd_config. Da quello che posso vedere, chiunque abbia le carte in regola {accesso, pwd} su S1 può accedere S1 e sia fare il port forwarding remoto e il port forwarding locale. Tali credenziali potrebbero essere un certificato in futuro, quindi, a mio avviso, chiunque afferrasse il certificato può accedere a S1 da qualsiasi altra parte (non necessariamente C1) e quindi creare port forwarding locali.

Per me, consentire il port forwarding locale è troppo pericoloso, poiché consente di creare una sorta di proxy pubblico. Sto cercando un modo per disabilitare solo gli inoltri -L.

Ho provato quanto segue, ma questo disabilita l'inoltro sia locale che remoto:

AllowTcpForwarding No

Ho anche provato quanto segue, questo consentirà solo -L a SX: 1. È meglio di niente, ma non è ancora quello di cui ho bisogno, che è un'opzione "nessuna".

PermitOpen SX:1

Quindi mi chiedo se c'è un modo, in modo da poter vietare a tutti i port forward locali di scrivere qualcosa del tipo:

PermitOpen none:none

La seguente è una bella idea?

PermitOpen localhost:1

ssh port-forwarding local

— SCO
fonte

quindi, come sempre, arriviamo alla radice di questo: qual è il tuo vero problema, perché vuoi configurare qualcosa del genere per dispositivi mobili / incorporati, cosa vuoi risolvere?

— Akira,

Il problema da risolvere qui è quello di poter aprire una sessione Telnet, ovunque da Internet, a un dispositivo mobile / incorporato connesso a Internet, tenendo conto che il dispositivo potrebbe essere NAT o firewall, quindi non raggiungibile da Internet.

— SCO

telnet .. per cosa? per aver praticato buchi nel firewall di Google per "stordire"

— Akira il

16

chiunque abbia le credenziali di accesso può visualizzare la propria istanza di sshd, in esecuzione su una porta casuale e consentire tutto ciò che desidera, inclusi gli inoltri locali -L:

% /usr/sbin/sshd -d -f mysshd.config -p 12345

se non ti fidi che gli utenti facciano qualcosa con la tua macchina, non dovresti consentire loro di accedere in primo luogo.

(a proposito, il flag -D è anche un tipo di "proxy problematico")

— Akira
fonte

Beh, immagino di poter configurare un account molto restrittivo per questo scopo (es. Attaccare l'utente alla sua home, nessun elenco, nessuna navigazione nel filesystem), in modo che non possa avviare e sshd (o installare e avviare un binario sshd). Il punto è che i client dovrebbero essere dispositivi embedded. Ma dal momento che probabilmente incorporeranno i certificati e la loro memoria flash può essere scaricata, è possibile che i certificati perdano, consentendo quindi a chiunque di accedere a S1.

— SCO

L'uso di ChrootDirectory per quel particolare utente farà il trucco, ci proverà!

— SCO

1

In authorized_keys, impostare command="/sbin/nologin". Ciò dovrebbe impedire loro di eseguire qualsiasi comando sul server.

— justis

L'affermazione "chiunque abbia le credenziali di accesso può far apparire il proprio <whatever>" è falso. sshpuò essere utilizzato per connettersi ad account che hanno severamente limitato le shell di accesso che non lo consentono. Il port forwarding è una falla di sicurezza in tali shell ristrette. Oltre a eseguire un comando consentito, l'utente può creare tunnel.

— Kaz,

3

Citazione dalla sshd_configpagina man: Notare che la disabilitazione dell'inoltro TCP non migliora la sicurezza a meno che agli utenti non venga negato l'accesso alla shell , poiché possono sempre installare i propri server d'inoltro. (Enfasi mia).

— Kaz,

17

Un'altra soluzione sarebbe quella di consentire il port forwarding solo agli utenti specifici:

Da SSH: la guida definitiva

Il port forwarding può essere abilitato o disabilitato a livello globale in sshd. Questo viene fatto con la parola chiave di configurazione a livello di server AllowTcpForwarding in / etc / sshd_config. La parola chiave può avere il valore yes (impostazione predefinita, abilitazione dell'inoltro) o no (disabilitazione dell'inoltro):

# SSH1, SSH2, OpenSSH
AllowTcpForwarding no

Inoltre, SSH2 ha le seguenti opzioni:

# SSH2 only
AllowTcpForwardingForUsers
AllowTcpForwardingForGroups

La sintassi di questi è la stessa delle opzioni AllowUsers e AllowGroups. [Sezione 5.5.2.1, "Controllo dell'accesso all'account"] Specifica un elenco di utenti o gruppi a cui è consentito utilizzare il port forwarding; il server rifiuta di onorare le richieste di port forwarding per chiunque altro. Si noti che si riferiscono all'account di destinazione della sessione SSH, non al nome utente client (che spesso non è noto).

...

È importante rendersi conto che le direttive in questa sezione non impediscono effettivamente il port forwarding, a meno che non si disabiliti anche gli accessi interattivi e si limiti quali programmi possono essere eseguiti sul lato remoto. Altrimenti, gli utenti esperti possono semplicemente eseguire la propria applicazione di port forwarding sulla sessione SSH. Queste impostazioni da sole potrebbero essere un deterrente sufficiente in una comunità non tecnica, ma non fermeranno qualcuno che sa cosa sta facendo.

— cristiano
fonte

1

Fondamentalmente avrò un solo utente fornito su S1. AFAIU, in questo caso specifico, l'utilizzo di AllowTcpForwardingForUsers / AllowTcpForwardingForGroups non farà il trucco, giusto? Vietare l'accesso interattivo è una buona idea poiché renderà gli utenti non in grado di avviare i binari. Ma a qualsiasi client sarà ancora permesso di usare la sintassi -L, giusto? Quindi per ora, le migliori opzioni sarebbero: 1 / Disabilita login interattivo, 2 / PermitOpen con un nome host falso: port. Ho dimenticato qualcosa ?

— SCO

Il modo migliore per verificarlo sarebbe provare l'installazione.

— Christian,

Non riesco a vedere queste opzioni nel software OpenSSH gratuito. Un google per AllowTcpForwardingForUsersrivela che è configurato in un sshd2_config, che viene utilizzato in alcuni programmi commerciali. Guarda una delle risposte a: superuser.com/questions/384643/…

— Kaz

^ OpenSSH ha Matchblocchi nella configurazione. Puoi Matchsu utenti e gruppi e racchiudere l' AllowTcpForwardinginterno.

— Kaz,

2

Ora esiste un'opzione per consentire solo l'inoltro locale / remoto.

AllowTcpForwarding Specifica se è consentito l'inoltro TCP. Le opzioni disponibili sono "yes" o "all" per consentire l'inoltro TCP, "no" per impedire tutto l'inoltro TCP, "local" per consentire solo l'inoltro locale (dal punto di vista di ssh (1)) o "remoto" per consentire remoto solo inoltro . L'impostazione predefinita è "sì". La disabilitazione dell'inoltro TCP non migliora la sicurezza a meno che agli utenti non venga negato l'accesso alla shell, poiché possono sempre installare i propri server di inoltro.

Quindi, come già detto, dovresti impostare anche la shell su nologin.

— Markus Rathgeb
fonte

0

La mia soluzione a questo problema era aggiungere: PermitOpen fo.local: 80 nella sezione principale di sshd_config.

Ciò nega semplicemente qualsiasi richiesta di inoltro locale oltre a fo.local: 80.

— MrMisu
fonte

0

Sto cercando un modo per disabilitare solo gli inoltri -L

Se ti capisco correttamente, i tuoi utenti hanno accesso completo alla shell, ma non vuoi che siano in grado di aprire connessioni verso il resto della rete.

Il "port forwarding locale" consentito da SSH è solo uno dei modi possibili per farlo. Altri includono il lancio di un'istanza di socat, netcato qualsiasi altro numero di strumenti.

Il modo migliore per controllare le connessioni in uscita e in entrata in Linux è Netfilter, noto anche come IPTables.

Ha un modulo speciale chiamato proprietario ( ipt_owner) che consente di abbinare varie caratteristiche del creatore di pacchetti, per i pacchetti generati localmente. È valido nelle catene OUTPUTe POSTROUTING.

Puoi usarlo per negare i pacchetti in uscita generati da determinati gruppi di utenti, impedendo così qualsiasi tipo di port forwarding, non solo l' -Lopzione di SSH.

— Tobia
fonte