• Benvenuti su RaspberryItaly!
Benvenuto ospite! Login Login con Facebook Registrati Login with Facebook


Valutazione discussione:
  • 0 voto(i) - 0 media
  • 1
  • 2
  • 3
  • 4
  • 5

[-]
Tags
vulnerabilità ssh sistemare

Sistemare Vulnerabilità SSH
#1
Dopo Giorni di test, ho potuto verificare che sebbene avessi impostato il collegamento ssh con chiave Pubblica/Privata.

il demone ssh rilasciava possibilità di criptazione anche con protocolli obsoleti vedi sha1 e con possibili back-door della NSA

questo per mantenere una retro-compatibilità con alcuni client ssh ormai non più usati.

se andate su questo sito:

https://sshcheck.com/

noterete come molte basi di criptazione siano rischiose e obsolete e andrebbero eliminate.

per fare ciò oltre all'impostazione di collegamento ssh a chiave pubblica/privata (se volete ne faccio un post)

vanno aggiunte le voci qui di seguito per far stabilire al demone ssh quale sistemi di criptazione usare. 

Questo in abbinamento ad un sistema di compressione ritardato della comunicazione.

PROCEDURA:

editare il file sshd config con il comando:

Codice:
sudo nano /etc/ssh/sshd_config

scorrere verso il basso e aggiungere le voci:

Codice:
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

KexAlgorithms sntrup4591761x25519-sha512@tinyssh.org,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256

HostKeyAlgorithms ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com

MACs umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512

in  HostKeyAlgorithms sk-ssh-ed25519@openssh.com ed sk-ecdsa-sha2-nistp256@openssh.com vanno usati solo con openssh8.2

in  KexAlgorithms sntrup4591761x25519-sha512@tinyssh.org  vanno usati solo con openssh8.2

abilitiamo il collegamento compresso lzib aggiungendo sempre alla fine la voce:

Codice:
Compression delayed

fatto ciò verificate di avere tutte le librerie corrette per la compressione del collegamento SSh
con il comando:

Codice:
sudo apt install libgcrypt11-dev zlib1g-dev

riavviamo il demone ssh con il comando:

Codice:
sudo service ssh restart

avremo una situazione del genere:

       

in questo modo eviteremo tutte le possibili vulnerabilità esistenti sul nostro collegamento ssh,

Ricordo che è sempre bene cambiare la porta di default 22 ad una a vostro piacimento.
e se volete installare servizio fail2ban per attacchi ddos ma di loro ve ne parlerò appena possibile.

see you Ti@er
Risposta
#2
interessante. grazie.
Coltiva linux, che windows si pianta da solo! (cit.)
Risposta
#3
Guida Aggiornata con nuovi algoritmi supportati a partire da openssh 8.2

in HostKeyAlgorithms sk-ssh-ed25519@openssh.com ed sk-ecdsa-sha2-nistp256@openssh.com supporto token hardware

in KexAlgorithms sntrup4591761x25519-sha512@tinyssh.org algoritmo scambio chiave che inibisce futuri attacchi Pc quantici era post-quantistica.
non è lontano ciò, già abbiamo strutture di ibm e Google con alcuni server funzionanti a quanti.

Per verificare quali chiavi host supporta la tua versione openssh digitare:

"HostKeyAlgorithm"

# ssh -Q key

Per verificare quale algoritmo scambio chiavi supporta la tua versione openssh digitate:

"KexAlgorithms"

# ssh -Q Kex
Risposta
  


Vai al forum:


Navigazione: 1 Ospite(i)
Forum con nuovi Post
Forum senza nuovi post
Forum bloccato
Forum Redirect