Con il gran numero di Raspberry Pis allo stato brado e il fatto che grandi gruppi di essi siano configurati in modo identico (quando viene installata una scheda SD appena flash con una delle poche immagini disponibili), è probabile che siano un bersaglio allettante per malware, comprese le botnet.

Cosa si può fare per mitigare questo?

È ragionevolmente noto che si dovrebbe cambiare la password per l'utente "pi" (Debian) e "root" (Arch.) Ma che dire di altri account di sistema (ad esempio "tli", "pnd"?) Qualcuno di loro ha password universali che sono presumibilmente le stesse per tutte le unità?

E ci sono vulnerabilità note in altri pacchetti installati nelle immagini SD disponibili per il Pi (ad esempio a causa di limitazioni hardware o versioni ridotte di quei pacchetti?)

In particolare, sono preoccupato per sshmysql e tutti gli altri servizi che potrebbero essere in esecuzione su un'immagine appena installata.

Cose che ho notato finora sull'immagine di Debian Squeeze di serie:

• / etc / shadow contiene un mucchio di hash di password per account che non sono l'account pi (buildbot, ecc.). Cambia la password sull'account pi, naturalmente, se non l'hai già fatto (o crea un nuovo account utente per te stesso ed elimina l'account pi) ma modifica anche le altre voci e sostituisci gli hash con * s. Nota / etc / passwd contiene voci duplicate per l'account pi, che confonde l'inferno di adduser / deluser, basta cancellarne uno.

• la configurazione predefinita del demone ssh consente l'accesso root remoto. Questo dovrebbe essere disabilitato.

• vale la pena usare netstat per verificare l'insieme di cose che ascoltano le connessioni; una quantità sorprendente di roba è in esecuzione rispetto a un tipico netinst minimale Debian. In genere è una buona idea ridurre l'esposizione solo alle cose di cui hai bisogno , quindi prima disabilita o spegni il firewall su tutto , quindi esponi solo i servizi che vuoi deliberatamente visibili su Internet pubblico (in genere solo ssh o ssh + http).

• ti consigliamo di cambiare le chiavi dell'host ssh invece di usare quelle nell'immagine (AIUI l'ultima immagine effettivamente le rigenera al primo avvio)

Esistono molti modi per affrontare le vulnerabilità, tuttavia la prima cosa che dovresti sapere è che Linux non è suscettibile alle intrusioni come altri sistemi operativi. Ciò è dovuto principalmente alla mancanza di malware destinato a * NIX. Tuttavia, si desidera essere consapevoli dei modi in cui è possibile accedere al sistema.

Le password

Innanzitutto è necessario modificare le password predefinite per tutti gli utenti che sono in grado di accedere. Per Debian questo è solo l'utente predefinito Pi . Per Arch Linux questo è il superutente root . Le password vengono modificate quando si accede come utente digitando passwdsulla riga di comando.

È incoraggiata una politica di password sicura, poiché sarebbe abbastanza semplice eseguire attacchi con dizionario di forza bruta sul tuo utente predefinito. Scegli una password decente di media lunghezza.

Oscurità

L'accesso remoto è probabilmente la falla di sicurezza più importante. Quello che possiamo usare qui è chiamato sicurezza dall'oscurità . Un metodo di attacco comune è la scansione di un intervallo di indirizzi IP alla ricerca di porte aperte. Quindi una delle contromisure più semplici che possiamo prendere è quella di essere un utente che non utilizza le porte predefinite .

Tutto ciò che deve essere fatto qui è cambiare le porte predefinite per i protocolli comunemente usati. Ad esempio, la porta SSH predefinita è 22 e FTP è 21. Nel mio sistema SSH utilizza 222 e FTP 221, il che dovrebbe oscurare questi protocolli da qualsiasi attacco automatico.

Sicurezza della connessione

In primo luogo, il problema di sicurezza più importante è che l'account root non dovrebbe essere in grado di accedere tramite SSH. È possibile disabilitare l'accesso root nel /etc/ssh/sshd_configfile commentando o rimuovendo questa riga:

PermitRootLogin yes

Dovrebbe essere impostato su no per impostazione predefinita, ma è meglio assicurarsi.

Se usi molto SSH e sei preoccupato per gli attacchi man in the middle, attacca i dizionari contro la tua password, quindi puoi usarli SSH Keys.

L'autenticazione basata su chiave presenta numerosi vantaggi rispetto all'autenticazione con password, ad esempio i valori chiave sono significativamente più difficili da forzare rispetto alle semplici password.

Per impostare l'autenticazione con chiave SSH è necessario prima creare la coppia di chiavi. Questo è più facilmente eseguibile sul tuo computer client (il computer con cui vuoi accedere al Pi).

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/pi/.ssh/id_rsa):

Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/pi/.ssh/id_rsa.
Your public key has been saved in /home/pi/.ssh/id_rsa.pub.

Come puoi vedere, questo ha creato due file, la chiave privata id_rsae la chiave pubblica id_rsa.pub.

La chiave privata è nota solo a te e deve essere protetta in modo sicuro . Al contrario, la chiave pubblica può essere condivisa liberamente con qualsiasi server SSH a cui si desidera connettersi.

Quindi ciò che vorremmo fare è copiare la chiave pubblica sul Raspberry Pi. Possiamo farlo molto facilmente:

ssh-copy-id pi@address

Dove si pitrova il nome utente di Raspberry Pi ed addressè l'indirizzo IP del Pi.

Lo ripeterò, distribuiamo la chiave pubblica . La chiave privata è tua. Tienilo stretto, per rilasciare quella chiave si rompe la sicurezza del sistema.

La wiki di Arch ha una descrizione eccellente su come funziona:

Quando un server SSH ha la tua chiave pubblica in archivio e ti vede richiedere una connessione, usa la tua chiave pubblica per costruire e inviarti una sfida. Questa sfida è come un messaggio in codice e deve essere soddisfatta con la risposta appropriata prima che il server ti garantisca l'accesso. Ciò che rende questo messaggio in codice particolarmente sicuro è che può essere compreso solo da qualcuno con la chiave privata. Mentre la chiave pubblica può essere utilizzata per crittografare il messaggio, non può essere utilizzata per decrittografare lo stesso messaggio. Solo tu, il proprietario della chiave privata, sarai in grado di comprendere correttamente la sfida e produrre la risposta corretta.

Per ulteriori informazioni sulla sicurezza dell'autenticazione con chiave pubblica, Wikipedia ha una spiegazione approfondita .

Con la sicurezza SSH in atto è possibile eseguire una quantità enorme di trasferimenti di dati crittografati e sicuri. Praticamente ogni altra porta può essere instradata tramite SSH, se necessario. Puoi persino inoltrare la sessione X tramite SSH in modo che appaia su un altro computer.

Come esempio interessante, ieri stavo eseguendo Eclipse sul mio desktop, visualizzandolo sul mio Raspberry Pi e controllando il mouse e la tastiera dal mio netbook. Tale è il potere di SSH.

permessi

Le autorizzazioni per i file sono il punto cruciale del sistema di sicurezza Linux. Hanno effetto su chi può vedere i tuoi file e cartelle e può essere molto importante per proteggere i tuoi dati. Ad esempio, accedere a Raspberry Pi come un normale utente ed eseguire:

cat /etc/shadow

Il shadowfile contiene password crittografate per gli utenti del sistema, quindi non vorremmo che nessuno lo guardasse! Quindi dovresti vedere questa risposta:

cat: /etc/shadow: Permission denied

Possiamo vedere perché questo è dando un'occhiata alle autorizzazioni del file:

ls -l /etc/shadow
-rw------- 1 root root 821 Jun 11 22:13 /etc/shadow

Questo ci dice che il file è di proprietà di root e solo il proprietario ha le autorizzazioni di lettura / scrittura. Analizziamo quell'output.

-rw-------

Questo è lo stato delle autorizzazioni. Il primo bit ci dice il tipo di file ( -significa file normale). I successivi tre bit rappresentano le azioni disponibili per il proprietario del file. I secondi tre bit rappresentano il gruppo e i tre finali sono per gli altri o per tutti gli altri. Quindi una directory con autorizzazioni complete sarebbe simile a questa:

drwxrwxrwx  10 root root   280 Jun 20 11:40 tmp/

Sono le autorizzazioni di lettura, scrittura ed esecuzione per il proprietario, il gruppo e tutti gli altri.

La prossima parte importante sono i due nomi. Nel nostro caso root root. Il primo utente è il proprietario del file. Il secondo è il gruppo di utenti . Ad esempio sarebbe comune vedere:

drwxr-xr-x  10 pi users   280 Jun 20 11:40 home/pi

Ciò consentirebbe l'accesso in lettura / scrittura per l'utente pinella sua home directory e l'accesso in lettura per tutti gli altri utenti.

Autorizzazioni più spesso riferite e controllate utilizzando valori ottali. Ad esempio, se vogliamo impostare rw solo per il proprietario, digitare:

chmod 600 /path/to/file

Questa è una panoramica di base, per maggiori dettagli sulle autorizzazioni dei file Linux, ecco un buon articolo.

Questa comprensione è importante quando si proteggono file e cartelle. Ad esempio, supponiamo che abbiamo appena impostato le chiavi SSH. Non vogliamo assolutamente che altri utenti vedano all'interno della nostra ~/.sshdirectory, altrimenti potrebbero prendere la nostra chiave privata. Quindi rimuoviamo i loro privilegi di lettura:

chmod 700 ~/.ssh
ls -la ~/.ssh 
drwx------   2 james users  4096 Jun 18 03:05 .

Spero che questo chiarisca alcune delle tue preoccupazioni con la protezione di Linux. Da questo dovresti essere in grado di vedere che è un sistema abbastanza sicuro e se stai attento non dovresti avere problemi di sicurezza.

Per prevenire attacchi bruteforce, è possibile installare e configurare fail2ban. Analizzerà i file di registro (come /var/log/auth.log) e tenterà di rilevare se diversi tentativi di accesso non sono riusciti. Quindi, bandirà automaticamente gli indirizzi IP di origine con iptables.

Ci sono un sacco di howtos su Internet.