Ho accidentalmente vietato la connessione SSH a un server remoto ... Quali sono le prospettive?

61

Diciamolo di nuovo, tutti commettiamo errori e ne ho appena fatto uno.

Una breve storia: stavo facendo alcune cose su un VPS (Debian) che sto noleggiando, quando ho notato uno strano comportamento. Usando il netstatcomando ho visto una connessione non autorizzata tramite SSH. Non sapevo cosa fare, quindi ho deciso di chiudere la sua connessione usando iptables:

iptables -A INPUT -p tcp --dport ssh -s IP -j DROP

Ma sono stanco e ho scritto

iptables -A INPUT -p tcp --dport ssh -j DROP

e ho cacciato me stesso (e tutti gli altri) ...

Come posso risolvere questo problema?

— tomatoGuy
fonte

possibile duplicato di È possibile accedere a un server SSH con una sottorete non configurata correttamente?

— Kasperd,

1

no, perché sta bloccando tutti i pacchetti ssh sulla macchina. su una sottorete configurata in modo errato, avresti semplicemente tcpdump per quell'indirizzo mac, prendi la sottorete su cui si sta installando, quindi configura un nic virtuale nella stessa sottorete e ne parli.

— jfalcon aka Don Fanning,

50

Bene, almeno hai rimosso l'accesso per l'individuo non autorizzato.

— un CVn

2

Per la prossima volta, forse il passaggio di un uomo morto sarebbe utile.

— Wayne Conrad,

2

Chi è il tuo host? Molti host di macchine virtuali offrono una console seriale che consente SSH nei casi in cui non è possibile farlo da una posizione remota.

— Jon,

60

Esistono diverse alternative:

Verifica se dispongono dell'accesso IPMI / "KVM" / console al server che ti consente di controllarlo come se fosse stata inserita una tastiera fisica.
Se non lo offrono, vedere se è possibile avviare la VM su un CD di ripristino di Linux (alcuni provider offrono questo) e quindi correggere le regole del firewall in quel modo e quindi avviarlo come di consueto.
Se non si dispone dell'accesso alla console, prima di avviare il ripristino o collegare il volume a un'altra macchina virtuale (come nel caso Amazon, accreditare la risposta dell'utente 3550767), è possibile provare la risposta di Ankh2054 di riavviare prima se non si sono salvate le regole ( probabilmente il caso da quando ti sei buttato fuori prima di avere la possibilità di salvare). Usa il pannello di controllo o chiedi a qualcuno di spegnere e riaccendere usando un reset / poweroff non grazioso (alias riavvio o spegnimento forzato) nel caso in cui lo script init salvi automaticamente le regole quando si riavvia con garbo (credit @jfalcon, @joshudson).

Pesa gli svantaggi di questo (come i dati che vengono scritti durante il riavvio potrebbero andare persi e potrebbe essere necessario il controllo del filesystem all'avvio, quindi un tempo di avvio più lungo, anche se tale ritardo potrebbe essere inferiore all'avvio al ripristino).

— g491
fonte

1

a seconda del server vps, potrebbe non esserci un accesso remoto che può raggiungere. i sistemi come vmware, kvm, xen, ecc. hanno console ma non sono predisposti per il consumo pubblico. si chiude che consente questa forma di controllo pubblico è openstack.

— jfalcon aka Don Fanning,

4

detto questo, se si trova nello spazio amazon / google, potrebbe eseguire l'istantanea dell'unità e montarla da un'altra macchina virtuale per fare la correzione.

— jfalcon aka Don Fanning,

47

Se non hai ancora salvato la regola IPtables, puoi riavviare il server su VPS (se disponibile) e la regola dovrebbe scomparire.

— Ankh2054
fonte

a meno che lo script init non salvi gli iptables durante l'arresto.

— jfalcon aka Don Fanning,

3

@jfalcon: ecco perché puoi chiedere loro di staccare la spina virtuale.

— joshudson,

22

@jfalcon Questo è anche il motivo per cui è una cattiva idea salvare automaticamente allo spegnimento ... rendere il salvataggio una decisione consapevole da parte dell'amministratore, non qualcosa eseguito alla cieca dal sistema.

— un CVn il

@joshudson: Devi dire alla scimmia di riavvio esattamente cosa fare e forzare lo spegnimento. Non solo avviare un arresto.

— jfalcon aka Don Fanning,

@ MichaelKjörling: anche questa filosofia è sbagliata. Questo è un VPS che probabilmente sta eseguendo il sandbox delle sue applicazioni e non ha alcun controllo su chi preme l'interruttore di alimentazione. E non hai idea di come l'hosting VPS abbia configurato le loro build. Non c'è nulla di sbagliato nel salvare allo spegnimento. Il suo errore è stato il suo errore. La mossa intelligente in primo luogo sarebbe stata quella di mettere SSH su una porta non standard o utilizzare fail2ban invece di reagire con una reazione di panico.

— jfalcon aka Don Fanning,

30

Questo è ciò che serve per le linee di aiuto con personale umano. Chiama il fornitore di servizi e chiedi a uno dei loro operatori di rimuovere la regola per te.

— RobertG
fonte

3

Un modo generale per correggere un'istanza interrotta è chiuderlo e collegare il volume principale a un'istanza funzionante. È quindi possibile montare il volume lì e visualizzare i registri o modificare i file di configurazione. È quindi possibile scollegare il volume e avviarlo nella propria istanza.

— user3550767
fonte

2

Vero per i VPS AWS; non è generalmente vero.

— MadHatter,

@MadHatter I dettagli esatti possono variare, ma se un provider VPS non offre alcun metodo per l'avvio con un'immagine funzionante nota da cui è possibile montare e riparare il file system di root, mi aspetterei che cessino di funzionare una volta che i clienti imparato a conoscere questa limitazione.

— Kasperd,

Di solito, lo fanno offrendo l'accesso alla console, quindi è possibile eseguire l'avvio in modalità utente singolo o da un supporto di salvataggio (di solito estratto come ISO). Sottolineo che ciò è in realtà molto più normale rispetto allo strano modo di AWS di gestire il problema, in cui un secondo VPS è (temporaneamente) un requisito.

— MadHatter,

@MadHatter Quale dei due approcci sembra strano può benissimo dipendere da ciò che conosci di più. E entrambi gli approcci portano a termine il lavoro. Qual è il più comune su cui non posso davvero commentare, dal momento che finora ho solo bisogno di tale accesso su un singolo provider VPS.

— Kasperd,

@kasperd: No, che usi dipende da quale supporto di un determinato provider VPS; non è una questione di scelta. Se stai usando AWS, monti il volume su un altro VPS; se si utilizza un provider VPS più normale, si avvia un singolo utente o dal supporto di ripristino. Non voglio che questo punto sia un cazzo (beh, non del tutto) ma perché è importante capire che si deve scoprire quali sono i metodi supportati dal proprio provider, quindi usarli. Cercare di usare il metodo AWS con, diciamo, Hetzner semplicemente non funzionerà , perché un vs server Hetzner non può vedere il FS di un altro (afaik).

— MadHatter,

3

Risposta formale: vai al pannello di gestione VPS, ottieni l'accesso locale (KVM virtuale) in qualche modo o chiamali.

Spiegazione di passaggi / regole per evitare di ricadere nuovamente:

Esistono modifiche alle regole di ip, routing e firewall che potrebbero andare male e bloccare l'accesso.
e si applica anche alla configurazione del dispositivo di rete dedicata, non solo ai VPS

Quindi, se non si è sicuri al 100% che è possibile recuperare .. vi consiglio di fare sempre un modo per ripristinare config rete al suo stato precedente .. come, sessione di fondo aperto con uno screen, nohupo tmux, addirittura cronpuò lavorare per questo, e aggiungere iptables -Fo altro desiderato significa ripristinare qualsiasi cosa allo stato precedente.

— kagali-san
fonte