Προς το περιεχόμενο

protect from ssh attack


miza

Προτεινόμενες αναρτήσεις

Έχω ένα debian server ο οποιος έχει ssh.

Κοιτώντας το auth.log διαπίστωσα ότι κάποιος προσπαθεί επίμονα να συνδεθεί στον server, με παρα πολλές προσπάθειες και σχεδόν κάθε μέρα.

 

>Sep 11 01:29:48 Mizerv sshd[4286]: Invalid user zzz from 62.173.39.252
Sep 11 01:29:48 Mizerv sshd[4286]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 01:29:48 Mizerv sshd[4286]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=39-252.rv.ipnxtelecoms.com 
Sep 11 01:29:50 Mizerv sshd[4286]: Failed password for invalid user zzz from 62.173.39.252 port 46736 ssh2
Sep 11 01:29:51 Mizerv sshd[4288]: Invalid user frank from 62.173.39.252
Sep 11 01:29:51 Mizerv sshd[4288]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 01:29:51 Mizerv sshd[4288]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=39-252.rv.ipnxtelecoms.com 
Sep 11 01:29:54 Mizerv sshd[4288]: Failed password for invalid user frank from 62.173.39.252 port 47226 ssh2
Sep 11 01:29:55 Mizerv sshd[4290]: Invalid user dan from 62.173.39.252
Sep 11 01:29:55 Mizerv sshd[4290]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 01:29:55 Mizerv sshd[4290]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=39-252.rv.ipnxtelecoms.com 
Sep 11 01:29:57 Mizerv sshd[4290]: Failed password for invalid user dan from 62.173.39.252 port 47844 ssh2
Sep 11 01:29:59 Mizerv sshd[4292]: Invalid user james from 62.173.39.252
Sep 11 01:29:59 Mizerv sshd[4292]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 01:29:59 Mizerv sshd[4292]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=39-252.rv.ipnxtelecoms.com 
Sep 11 01:30:00 Mizerv sshd[4292]: Failed password for invalid user james from 62.173.39.252 port 48214 ssh2
Sep 11 01:30:01 Mizerv sshd[4294]: Invalid user snort from 62.173.39.252
Sep 11 01:30:01 Mizerv sshd[4294]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 01:30:01 Mizerv sshd[4294]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=39-252.rv.ipnxtelecoms.com 
Sep 11 01:30:03 Mizerv sshd[4294]: Failed password for invalid user snort from 62.173.39.252 port 48628 ssh2
Sep 11 01:30:05 Mizerv sshd[4296]: Invalid user radiomail from 62.173.39.252
Sep 11 01:30:05 Mizerv sshd[4296]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 01:30:05 Mizerv sshd[4296]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=39-252.rv.ipnxtelecoms.com 
Sep 11 01:30:06 Mizerv sshd[4296]: Failed password for invalid user radiomail from 62.173.39.252 port 49118 ssh2
Sep 11 01:30:08 Mizerv sshd[4298]: Invalid user harrypotter from 62.173.39.252
Sep 11 01:30:08 Mizerv sshd[4298]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 01:30:08 Mizerv sshd[4298]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=39-252.rv.ipnxtelecoms.com 
Sep 11 01:30:10 Mizerv sshd[4298]: Failed password for invalid user harrypotter from 62.173.39.252 port 49507 ssh2
Sep 11 01:30:12 Mizerv sshd[4300]: Invalid user divine from 62.173.39.252
Sep 11 01:30:12 Mizerv sshd[4300]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 01:30:12 Mizerv sshd[4300]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=39-252.rv.ipnxtelecoms.com 
Sep 11 01:30:13 Mizerv sshd[4300]: Failed password for invalid user divine from 62.173.39.252 port 50019 ssh2
Sep 11 01:30:15 Mizerv sshd[4302]: Invalid user popa3d from 62.173.39.252
Sep 11 01:30:15 Mizerv sshd[4302]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 01:30:15 Mizerv sshd[4302]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=39-252.rv.ipnxtelecoms.com 
Sep 11 01:30:17 Mizerv sshd[4302]: Failed password for invalid user popa3d from 62.173.39.252 port 50526 ssh2
Sep 11 01:30:19 Mizerv sshd[4304]: Invalid user aptproxy from 62.173.39.252
Sep 11 01:30:19 Mizerv sshd[4304]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 01:30:19 Mizerv sshd[4304]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=39-252.rv.ipnxtelecoms.com 
Sep 11 01:30:21 Mizerv sshd[4304]: Failed password for invalid user aptproxy from 62.173.39.252 port 51018 ssh2
Sep 11 01:30:22 Mizerv sshd[4306]: Invalid user desktop from 62.173.39.252
Sep 11 01:30:22 Mizerv sshd[4306]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 01:30:22 Mizerv sshd[4306]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=39-252.rv.ipnxtelecoms.com 
Sep 11 01:30:25 Mizerv sshd[4306]: Failed password for invalid user desktop from 62.173.39.252 port 51582 ssh2
Sep 11 01:30:26 Mizerv sshd[4308]: Invalid user workshop from 62.173.39.252
Sep 11 01:30:26 Mizerv sshd[4308]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 01:30:26 Mizerv sshd[4308]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=39-252.rv.ipnxtelecoms.com 
Sep 11 01:30:29 Mizerv sshd[4308]: Failed password for invalid user workshop from 62.173.39.252 port 52107 ssh2
Sep 11 01:30:30 Mizerv sshd[4310]: Invalid user mailnull from 62.173.39.252
Sep 11 01:30:30 Mizerv sshd[4310]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 01:30:30 Mizerv sshd[4310]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=39-252.rv.ipnxtelecoms.com 
Sep 11 01:30:32 Mizerv sshd[4310]: Failed password for invalid user mailnull from 62.173.39.252 port 52707 ssh2
Sep 11 01:30:33 Mizerv sshd[4312]: Invalid user nfsnobody from 62.173.39.252
Sep 11 01:30:33 Mizerv sshd[4312]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 01:30:33 Mizerv sshd[4312]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=39-252.rv.ipnxtelecoms.com 
Sep 11 01:30:35 Mizerv sshd[4312]: Failed password for invalid user nfsnobody from 62.173.39.252 port 53068 ssh2
Sep 11 01:30:38 Mizerv sshd[4314]: Invalid user rpcuser from 62.173.39.252
Sep 11 01:30:38 Mizerv sshd[4314]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 01:30:38 Mizerv sshd[4314]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=39-252.rv.ipnxtelecoms.com 
Sep 11 01:30:40 Mizerv sshd[4314]: Failed password for invalid user rpcuser from 62.173.39.252 port 53530 ssh2
Sep 11 01:30:41 Mizerv sshd[4316]: Invalid user rpc from 62.173.39.252
Sep 11 01:30:41 Mizerv sshd[4316]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 01:30:41 Mizerv sshd[4316]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=39-252.rv.ipnxtelecoms.com 
Sep 11 01:30:43 Mizerv sshd[4316]: Failed password for invalid user rpc from 62.173.39.252 port 54213 ssh2
Sep 11 01:30:44 Mizerv sshd[4318]: Invalid user gopher from 62.173.39.252
Sep 11 01:30:44 Mizerv sshd[4318]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 01:30:44 Mizerv sshd[4318]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=39-252.rv.ipnxtelecoms.com 
Sep 11 01:30:46 Mizerv sshd[4318]: Failed password for invalid user gopher from 62.173.39.252 port 54690 ssh2

 

Το root log in είναι απενεργοποιημένο από το ssh.

1)Ποσο εύκολο είναι να βρει κάποιος τα user και το pass κάνοντας αλλεπάλληλες προσπάθειες;

2)Πως μπορώ προστατευτώ;

(πχ να γίνετε κάπως αυτόματο ban ip μετά από κάποιες προσπάθειες)

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Το root log in είναι απενεργοποιημένο από το ssh.

1)Ποσο εύκολο είναι να βρει κάποιος τα user και το pass κάνοντας αλλεπάλληλες προσπάθειες;

2)Πως μπορώ προστατευτώ;

(πχ να γίνετε κάπως αυτόματο ban ip μετά από κάποιες προσπάθειες)

 

Συνήθως αυτά τα scans είναι ακίνδυνα εφόσον έχεις ένα ευλόγως «δυνατό» password. Τα bots που κάνουν αυτά τα scans ψάχνουν κάποιους στάνταρ συνδυασμός username/password.

 

Προσωπικά, αυτό που κάνω για να προστατέψω τα διάφορα pc είναι:

 

  1. Χρήση του allow_groups directive στο sshd_config για να δώσω πρόσβαση σε ένα συγκεκριμένο group (π.χ. ssh_users), στο οποίο προσθέτω ο ίδιος τους χρήστες που θέλω να μπορούν να κάνουν login. Αυτό με σώζει από το να φτιάξω ένα χρήστη "test/test" για να κάνω δοκιμές και να τον ξεχάσω εκτεθειμένο στο internet (και αυτός ο χρήστης είναι συνήθως η πρώτη απόπειρα που κάνουν τα bots ;-)).
     
  2. Απενεργοποίηση των passwords όπου μπορώ και χρήση μόνο ssh public key authentication. Αυτό είναι το καλύτερο μέτρο που μπορείς να λάβεις και σε σώζει από πολλά δεινά:
    • Δεν είναι πρακτικά δυνατό να κάνει κανείς brute force σε κλειδί 2048 bits.
    • Ένα από τα πρώτα πράγματα που κάνει ένα χακεμένο μηχάνημα, είναι να μαζεύει τα passwords των χρηστών που κάνουν login και μετά να τα χρησιμοποιεί για να «πάρει» άλλα μηχανήματα. Με το public key authentication δεν υπάρχει password και ο server δε «βλέπει» ποτέ το private key, ώστε να μπορεί να το χρησιμοποιήσει για να κάνει login σε άλλα μηχανήματα.
    • Με τα κλειδιά μπορείς να χρησιμοποιήσεις ειδικά directives ώστε να περιορίσεις τις εντολές που μπορεί να δώσει ένας χρήστης. Έτσι μπορείς να δίνεις root access στον backup server σου για να τραβάει τα αρχεία σου, χωρίς να μπορεί να κάνει κάτι παραπάνω.

 

[*] Αυτό που δεν κάνω ποτέ είναι να αλλάζω πόρτα στον sshd και να χρησιμοποιώ scripts. Τα scripts αυτά (fail2ban, denyhosts) αφενός βασίζονται στο parsing των logfiles, των οποίων το format δεν είναι κατ' ανάγκη σταθερό (αν ο sshd είχε κάποιο policy delegation feature, το συζητούσαμε), αφετέρου μπορούν κάλλιστα να κλειδώσουν και εσένα απ' έξω. Η δε πόρτα, απλά θα κόψει το τυχαίο bot, από το οποίο είμαι ασφαλής χάρη στα παραπάνω μέτρα. Αν κάποιος αποφασίσει να ασχοληθεί μαζί μου, τότε θα βρει εύκολα τον sshd, όπου και αν τον έχω βάλει.

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Αν βαλεις την ip του στο /etc/hosts.deny δεν θα σου τον αποκλεισει μονιμα?

 

Και αν εχει δυναμική IP -που δυναμική θα έχει; Δεν προστατεύει και πολύ αυτό το μέτρο.

 

Είτε μέσω του hosts.deny είτε μέσω iptables και DENY την MAC address του. Μπορείς να την βρείς κάνοντας ένα ping στην IP του και αμέσως μετά arp -n

 

Αυτό μάλιστα.

 

Απενεργοποίηση των passwords όπου μπορώ και χρήση μόνο ssh public key authentication. Αυτό είναι το καλύτερο μέτρο που μπορείς να λάβεις και σε σώζει από πολλά δεινά:

 

Δεν είναι πρακτικά δυνατό να κάνει κανείς brute force σε κλειδί 2048 bits.

Ένα από τα πρώτα πράγματα που κάνει ένα χακεμένο μηχάνημα, είναι να μαζεύει τα passwords των χρηστών που κάνουν login και μετά να τα χρησιμοποιεί για να «πάρει» άλλα μηχανήματα. Με το public key authentication δεν υπάρχει password και ο server δε «βλέπει» ποτέ το private key, ώστε να μπορεί να το χρησιμοποιήσει για να κάνει login σε άλλα μηχανήματα.

Με τα κλειδιά μπορείς να χρησιμοποιήσεις ειδικά directives ώστε να περιορίσεις τις εντολές που μπορεί να δώσει ένας χρήστης. Έτσι μπορείς να δίνεις root access στον backup server σου για να τραβάει τα αρχεία σου, χωρίς να μπορεί να κάνει κάτι παραπάνω.

 

Καλή λύση τα κλειδιά, αλλά μόνο αν θες να μπαίνεις αποκλειστικά εσύ.

Δηλαδή αν θέλει ο φίλος μας, ας πούμε, να μπει ένα άλλο παιδί στον server που τρέχει το ssh για να διορθώσει κάτι θα πρέπει να έχει το public key, και δεν είναι καθόλου βολικό να κάθεσε να στέλνεις κλειδιά.

 

 

Αυτό που δεν κάνω ποτέ είναι να αλλάζω πόρτα στον sshd και να χρησιμοποιώ scripts. Τα scripts αυτά (fail2ban, denyhosts) αφενός βασίζονται στο parsing των logfiles, των οποίων το format δεν είναι κατ' ανάγκη σταθερό (αν ο sshd είχε κάποιο policy delegation feature, το συζητούσαμε), αφετέρου μπορούν κάλλιστα να κλειδώσουν και εσένα απ' έξω. Η δε πόρτα, απλά θα κόψει το τυχαίο bot, από το οποίο είμαι ασφαλής χάρη στα παραπάνω μέτρα. Αν κάποιος αποφασίσει να ασχοληθεί μαζί μου, τότε θα βρει εύκολα τον sshd, όπου και αν τον έχω βάλει.

 

Εγώ άλλαζω τη πόρτα, καθώς τα περισσότερα σκριπτάκια χτυπάνε στη πόρτα 22.

Ξέρω ότι δεν είναι τίποτα το φοβαρό, αλλά το εφαρμόζω.

Πως μπορεί να βρει κανείς σε ποιά πόρτα έχεις βάλει τον sshd; Ας πούμε ότι τον έχει βάλει στο 1000, θα βρεί ότι είναι ανοιχτή μ'ένα nmap ή κάποιο άλλο, αλλά πως θα ξέρει ποιό service τρέχει εκεί;

 

Όσο για τα σκριπτάκια και τα log files, μπορείς να πεις στο σκριπτάκι που θα διαβάζει για να βλέπει τα logs.

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Καλή λύση τα κλειδιά, αλλά μόνο αν θες να μπαίνεις αποκλειστικά εσύ.

Δηλαδή αν θέλει ο φίλος μας, ας πούμε, να μπει ένα άλλο παιδί στον server που τρέχει το ssh για να διορθώσει κάτι θα πρέπει να έχει το public key, και δεν είναι καθόλου βολικό να κάθεσε να στέλνεις κλειδιά.

 

Δεν είναι τραγικό πράμα να σου κάνει paste ένα κλειδί σε κάποιον instant messenger.

 

 

Εγώ άλλαζω τη πόρτα, καθώς τα περισσότερα σκριπτάκια χτυπάνε στη πόρτα 22.

Ξέρω ότι δεν είναι τίποτα το φοβαρό, αλλά το εφαρμόζω.

Πως μπορεί να βρει κανείς σε ποιά πόρτα έχεις βάλει τον sshd; Ας πούμε ότι τον έχει βάλει στο 1000, θα βρεί ότι είναι ανοιχτή μ'ένα nmap ή κάποιο άλλο, αλλά πως θα ξέρει ποιό service τρέχει εκεί;

To nmap έχει και το -A flag, που κάνει περίπου αυτό:

>
apoikos@black:~ $ telnet localhost 22
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.1p1 Debian-5

Όπως βλέπεις δε χρειάζεται να γράψεις τίποτα για να σου πει το SSH ότι τρέχει εκεί. Ακόμα και αν αλλάξεις το banner, μπορείς με ένα σωστά σχεδιασμένο script να αρχίσεις να κάνεις SSH negotiation σύμφωνα με το πρωτόκολλο για να δεις τι θα πει το απέναντι άκρο. Κάνε ένα ssh -v some.host.name να δεις από πόσα στάδια περνάει η σύνδεση προτού πει κάτι για password ή κλειδιά. Τα targeted probes δεν είναι δύσκολα γενικά ;-)

 

Όσο για τα σκριπτάκια και τα log files, μπορείς να πεις στο σκριπτάκι που θα διαβάζει για να βλέπει τα logs.

Ναι, αλλά τι θα γίνει αν, ας πούμε, το OpenSSH 6 αποφασίσει να αλλάξει το log file format και αντί για "Invalid user" να λέει "Non-existent user"; Θα το ξέρεις για να αλλάξεις τα regular expressions; Το να μετατρέπεις τη δομημένη πληροφορία σε free text και μετά να το κάνεις parse με regular expressions είναι σα να πυροβολείς τον εαυτό σου στο πόδι. Αν υπήρχε κάποιο μονοσήμαντα ορισμένο interface ανάμεσα στον sshd και κάποιον εξωτερικό policy daemon, τότε ενδεχομένως θα το εμπιστευόμουν.

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Δεν είναι τραγικό πράμα να σου κάνει paste ένα κλειδί σε κάποιον instant messenger.

 

 

 

To nmap έχει και το -A flag, που κάνει περίπου αυτό:

>
apoikos@black:~ $ telnet localhost 22
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.1p1 Debian-5

Όπως βλέπεις δε χρειάζεται να γράψεις τίποτα για να σου πει το SSH ότι τρέχει εκεί. Ακόμα και αν αλλάξεις το banner, μπορείς με ένα σωστά σχεδιασμένο script να αρχίσεις να κάνεις SSH negotiation σύμφωνα με το πρωτόκολλο για να δεις τι θα πει το απέναντι άκρο. Κάνε ένα ssh -v some.host.name να δεις από πόσα στάδια περνάει η σύνδεση προτού πει κάτι για password ή κλειδιά. Τα targeted probes δεν είναι δύσκολα γενικά ;-)

 

 

Ναι, αλλά τι θα γίνει αν, ας πούμε, το OpenSSH 6 αποφασίσει να αλλάξει το log file format και αντί για "Invalid user" να λέει "Non-existent user"; Θα το ξέρεις για να αλλάξεις τα regular expressions; Το να μετατρέπεις τη δομημένη πληροφορία σε free text και μετά να το κάνεις parse με regular expressions είναι σα να πυροβολείς τον εαυτό σου στο πόδι. Αν υπήρχε κάποιο μονοσήμαντα ορισμένο interface ανάμεσα στον sshd και κάποιον εξωτερικό policy daemon, τότε ενδεχομένως θα το εμπιστευόμουν.

 

Οπότε θεωρείς ότι η χρήση public keys και η απαγόρευση χρήσης passwords είναι το μόνο μέτρο που μπορούμε να πάρουμε και να είμαστε σχετικά ήρεμοι;

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Οπότε θεωρείς ότι η χρήση public keys και η απαγόρευση χρήσης passwords είναι το μόνο μέτρο που μπορούμε να πάρουμε και να είμαστε σχετικά ήρεμοι;

 

Εξαρτάται από το πόσο παρανοϊκός είσαι.

 

Γενικά το public key είναι ο ασφαλέστερος τρόπος να κάνεις login per se, όμως δεν είναι και ο πιο εύχρηστος, διότι αν θες να έχεις πρόσβαση από παντού, πρέπει να κουβαλάς μαζί σου το κλειδί και να προσέχεις σε τι PC το βάζεις. Η όλη ασφάλεια του public key authentication βασίζεται στο ότι το private key το ελέγχεις εσύ και δεν το εκθέτεις ποτέ σε κίνδυνο.

 

Από 'κει και πέρα, αν έχεις ένα μηχάνημα σπίτι σου, τότε με ένα δυνατό password (>10-12 χαρακτήρων, με σύμβολα και αλφαριθμητικά) είσαι οκ, αν δε θες να χρησιμοποιήσεις public key. Αν είσαι λίγο πιο παρανοϊκός, μπορείς να χρησιμοποιήσεις public key καθημερινά, και one time passwords αν χρειαστεί να κάνεις login από κάποιο untrusted υπολογιστή. Αν έχεις περισσότερους από έναν υπολογιστές, τότε το password authentication παίζει οπουδήποτε μεταξύ του κουραστικού (1 «καλό» password για κάθε μηχάνημα) και του επικίνδυνου (το ίδιο password σε κάθε μηχάνημα), οπότε αναγκαστικά πας σε public key-only, με passphrase-protected κλειδί.

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Προσωπικά είμαι ΣΧΕΤΙΚΑ ήρεμος μόνο με χρήση key με password και ssh σε chrooted περιβάλον για συγκεκριμένες δουλειές όπου αυτό είναι εφικτό.

 

Λίγο παρανοίκο δεν είναι;

 

Εξαρτάται από το πόσο παρανοϊκός είσαι.

 

Γενικά το public key είναι ο ασφαλέστερος τρόπος να κάνεις login per se, όμως δεν είναι και ο πιο εύχρηστος, διότι αν θες να έχεις πρόσβαση από παντού, πρέπει να κουβαλάς μαζί σου το κλειδί και να προσέχεις σε τι PC το βάζεις. Η όλη ασφάλεια του public key authentication βασίζεται στο ότι το private key το ελέγχεις εσύ και δεν το εκθέτεις ποτέ σε κίνδυνο.

 

Από 'κει και πέρα, αν έχεις ένα μηχάνημα σπίτι σου, τότε με ένα δυνατό password (>10-12 χαρακτήρων, με σύμβολα και αλφαριθμητικά) είσαι οκ, αν δε θες να χρησιμοποιήσεις public key. Αν είσαι λίγο πιο παρανοϊκός, μπορείς να χρησιμοποιήσεις public key καθημερινά, και one time passwords αν χρειαστεί να κάνεις login από κάποιο untrusted υπολογιστή. Αν έχεις περισσότερους από έναν υπολογιστές, τότε το password authentication παίζει οπουδήποτε μεταξύ του κουραστικού (1 «καλό» password για κάθε μηχάνημα) και του επικίνδυνου (το ίδιο password σε κάθε μηχάνημα), οπότε αναγκαστικά πας σε public key-only, με passphrase-protected κλειδί.

 

Στους servers που χειρίζεσαι εσύ τι μέτρας παίρνεις;

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Και μία λεπτομέρεια που κατά περιπτώσεις μπορεί να έχει τη σημασία της: Η αλλαγή των default ports μπορεί να λειτουργήσει ως δίκοπο μαχαίρι. Αν πρόκειται για server που δέχεται γενικά πολλές επισκέψεις (π.χ. κάνεις host σε αυτόν και κάποιο site), μπορεί να σε ταράξουν στα port scans => not good. Οπότε, 22 για τον sshd και παίρνεις τα μέτρα που ανέφεραν ήδη τα παιδιά πιο πάνω.

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Θα το κάνω με public key, αν και έκανα ένα search google, και δεν πολύ κατάλαβα πως να το κάνω από αυτά που διάβασα.

Αν έχει διάθεση κάποιος να εξηγήσει, η να προσθέσει στο insomnia wiki, από ότι είδα υπάρχει ένα άρθρο για ssh, ίσος βοηθήσει κιάλλους μελλοντικά :o

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Αρχειοθετημένο

Αυτό το θέμα έχει αρχειοθετηθεί και είναι κλειστό για περαιτέρω απαντήσεις.

  • Δημιουργία νέου...