Regola IPTables per consentire connessioni SSH in entrata

Lo scopo di questo script è consentire solo il traffico tramite VPN, ad eccezione del traffico localhost <-> localhost e SSH in entrata. Ma quando eseguo lo script su SSH sono disconnesso e costretto a riavviare il VM. Cosa c'è di sbagliato nella mia sceneggiatura?

#!/bin/bash
iptables -F

#Allow over VPN
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A OUTPUT -o tun+ -j ACCEPT

#Localhost
iptables -A INPUT -s 127.0.0.1/8 -j ACCEPT
iptables -A OUTPUT -d 127.0.0.1/8 -j ACCEPT

#VPN
iptables -A INPUT -s 123.123.123.123 -j ACCEPT
iptables -A OUTPUT -d 123.123.123.123 -j ACCEPT

#SSH
iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#Default Deny
iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP

iptables

— Steven
fonte

Risposte:

La catena di output è responsabile dell'eventuale uscita di pacchetti.

Lo script consente solo ai pacchetti in uscita di eseguire il tunneling dell'interfaccia, dell'host locale e dell'host remoto al 123.123.123.123.

Se ci si connette al server in un modo che richiede il demone SSH per inviare pacchetti alla destinazione diversa da una delle precedenti, il traffico non sarà autorizzato a uscire.

Per consentire i pacchetti in uscita dal demone SSH al client SSH è necessario aggiungere la seguente regola:

iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT

Potresti anche voler aggiungere i criteri IP di destinazione alla regola sopra, se ti connetti solo da una singola posizione. Questa regola deve precedere la regola definitiva "DROP qualcos'altro" per la catena di output.

— hellodanylo
fonte

+1 Funzionerà ed è più specifico dell'uso di una regola correlata stabilita (rendendola più o meno utile a seconda del contesto).

— Riccioli d'oro,

Entrambe le grandi risposte, ho imparato molto! Ho testato la risposta @SkyDan e funziona bene!

— Steven,

Nitpick: la catena di output non è responsabile per i pacchetti inoltrati .

— Björn Lindqvist,

La tua #SSHregola implica che ssh è una forma di comunicazione a senso unico, che non lo è. I dati vengono inviati avanti e indietro.

Il modo normale di gestirlo, dal momento che non è possibile conoscere in anticipo il numero di porta sul lato client, è consentire connessioni considerate "stabilite" o "correlate" a una connessione stabilita. Per fare questo è necessario:

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Prima delle tue DROPregole (e preferibilmente all'inizio, poiché le regole vengono elaborate in ordine e questi due si applicheranno alla maggior parte dei pacchetti).

C'è una spiegazione di come viene stabilita una connessione TCP qui ; in sostanza, il fatto che il server risponda al pacchetto consentito dalla #SSH INPUTregola lo rende tale.

— goldilocks
fonte

Questo non funzionerà. Stabilito significa che sono stati visti i pacchetti in entrambe le direzioni per una determinata connessione TCP. Se aggiungi solo questa regola, il primo pacchetto in uscita verrà comunque bloccato.

— hellodanylo,

@SkyDan Ecco un riferimento per questo . Si noti sul diagramma che quando il server invia un syn / ack al client dopo aver ricevuto il syn di apertura, viene stabilita la connessione, il che significa che iptables lascerà passare quel pacchetto di risposta: "Una volta che ha visto un pacchetto (il SYN), considera la connessione come NUOVA. Una volta che vede il pacchetto di ritorno (SYN / ACK), considera la connessione ESTABLISHED. " -> di nuovo: iptables vede il pacchetto di ritorno che il server vuole inviare, imposta la connessione come stabilito e lascia passare la risposta.

— Riccioli d'oro,

Ok, capisco perché funzionerà. È un po 'oscuro, dal momento che l'uomo iptables parla solo di vedere i pacchetti in entrambe le direzioni, non una parola sui pacchetti di handshake TCP che fanno eccezione. Grazie per il riferimento!

— hellodanylo,

@SkyDan In effetti, la logica non si applica solo a tcp - ho sbagliato a -p tcpfare alcuna differenza in questo senso, e guarda la spiegazione successiva per UDP su quella pagina (è la stessa). Il punto è che il server risponde senza sapere se iptables lo consentirà o meno, e quando iptables riceve quella risposta dal server sul sistema locale , ora ha visto il traffico in entrambe le direzioni (anche se il client non lo ha ancora), considera la connessione stabilita e consente la risposta. Il "tecnicismo" qui dipende dal firewall che si trova nel mezzo delle due parti.

— Riccioli d'oro,

Hai ragione lì. Qualcuno dovrebbe probabilmente includere queste informazioni nell'uomo iptables.

— hellodanylo,