30/05/2019, 10:33
(Questo messaggio è stato modificato l'ultima volta il: 20/07/2020, 18:47 da Tiger.)
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:
scorrere verso il basso e aggiungere le voci:
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:
fatto ciò verificate di avere tutte le librerie corrette per la compressione del collegamento SSh
con il comando:
riavviamo il demone ssh con il comando:
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
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