sicurezza server

[khael]

salve a tutti,
fra qualche giorno il mio server sarà connesso ad una webfarm con 100mbit di connessione.

Premetto che non è un server mission critical (non mi sarei mai avventurato per "gioco" in un'operazione del genere).

Come distribuzione pensavo ad ubuntu server 10.04 (senza gui ovviamente).

Le porte aperte che mi servono sono:
1) ssh (ovvio)
2) ftp
3) altra porta random per 1 applicativo.

Ho pensato di adoperare subito queste strategie:
1) cambio porte standard per ssh e ftp
2) fail2ban
3) limitare le connessioni ip/porta a 2
4) limitare richieste icmp (oppure lasciarle ma solo sotto pochi byte?)
5) altre piccole regole iptables contro port scan (ho trovato qualche piccola guida)

Che ne dite per iniziare?
grazie!

[fcorbelli]

Personalmente (potendo) userei (ed uso) BSD.
Un elemento fondamentale è una password ssh veramente buona (il che significa lunga, molto lunga) e verificare periodicamente i log (magari facendoteli spedire per email).

Altrettanto importante è disabilitare qualsiasi servizio non necessario (meglio ancora disinstallarlo); ftp può essere fonte di problemi, e infatti valuta bene per quale motivo lo vuoi tenere, a favore eventualmente di un servizio sicuro (sftp)

[vampirodolce1]

Per l'ssh ricordati di disabilitare l'accesso come root e inoltre usa l'accesso con chiave pubblica/chiave privata, disabilitando quello con username e password, anche perche' gli attacchi sono tutti a dizionario, quindi li stronchi sul nascere
Eventualmente abilita un port knocking per maggiore sicurezza.

Concordo anch'io sull'uso di sftp al posto di ftp, che fra l'altro usa una sola porta e la configurazione e' la stessa di ssh. Ne risentiranno un po' le prestazioni, dato che l'ftp e' fatto per massimizzare le prestazioni, mentre l'sftp e' fatto per massimizzare la sicurezza.

ICMP puoi droppare tutto in ingresso.

Buona poi l'idea di spostare i servizi su porte non standard, difficilmente qualcuno provera' a cercare un sshd in ascolto su porta 45297, mentre se lo lasci sulla 22 e non ben configurato sei fregato in mezz'ora.

Infine, assicurati come gia' detto di disabilitare tutti i servizi in ascolto, il comando 'netstat -atupn' deve dirti che in ascolto hai solo le 3 righe di sshd, ftpd e la tua applicazione.

Alla fine del lavoro di tuning, applica policy restrittive sul firewall, come ulteriore livello di sicurezza.

[khael]

Grazie a tutti per gli aiuti.
Allora ftp l'ho abbandonato, all'occorrenza mi basta wget e wput!

Ho cambiato le porte per ssh e webmin (con webmin sto cercando di risolvere, vorrei settarlo in modo che soltanto il mio ip possa accedere e tramite ssl).

Con netstat queste porte sono aperte, ma non penso siano un problema giusto?

tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 3051/named
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 3051/named
tcp 0 0 0.0.0.0:10022 0.0.0.0:* LISTEN 2967/sshd
tcp 0 0 0.0.0.0:10023 0.0.0.0:* LISTEN 3117/perl
tcp6 0 0 ::1:53 :::* LISTEN 3051/named
tcp6 0 0 ::1:953 :::* LISTEN 3051/named
tcp6 0 0 :::10022 :::* LISTEN 2967/sshd
udp 0 0 127.0.0.1:53 0.0.0.0:* 3051/named
udp 0 0 0.0.0.0:10000 0.0.0.0:* 3117/perl
udp6 0 0 ::1:53 :::* 3051/named

ICMP non posso far droppare tutto, devo configurarlo per bene (non l'ho ancora guardato).

Per ssh:
1) disabilitato root
2) l'accesso con i certificati (chiave pubblica/privata) non so come funziona
3) il port knocking non so cosa sia...dopo cerco!

Ora cerco su

[vampirodolce1]

Hai il servizio named in esecuzione (DNS server), direi che puoi eliminarlo dal boot a meno che non ti serva esplicitamente. Nel tuo runlevel /etc/rcX.d (ad es. /etc/rc2.d) dovresti avere un file Sxxnamed, Sxxbind o simili, sostituisci la S con una K.

Poi c'e' quel perl, e' webmin?

Per l'ssh io in debian entro come utente, poi divento root col comando su.
Per ubuntu (che non conosco benissimo) prova 'sudo su -" o magari col comando login se riesci a fare un login successivo come root.

Chiave pubblica/privata: il client genera la coppia di chiavi e mette la pubblica su server, la privata va cifrata con una passphrase aggiuntiva per maggior sicurezza. Documentati su ssh-keygen, known_hosts, authorized_keys. Trovi molta documentazione in rete e nelle pagine man di ssh, sshd, ssh-keygen, known_hosts, authorized_keys, ecc.

Port knocking: la porta ssh e' sempre chiusa, a meno che non mandi una serie di pacchetti su delle porte scelte da te (anch'esse chiuse) e se la combinazione e' esatta viene eseguito un comando a piacere... con quel comando puoi inserire una regola di iptables che sblocca per tot secondi la porta di sshd sul firewall, al fine di permetterti di fare il login e poi la richiude con un close_command.
In debian c'e' il pacchetto knockd (il client c'e' anche per windows se ti interessa ed e' un banalissimo .exe di pochi KB), vedi se in ubuntu il pacchetto ha lo stesso nome.
http://packages.debian.org/squeeze/knockd

Buon lavoro.

[fcorbelli]

Personalmente l'autenticazione con chiave non la vedo come particolarmente più "robusta" di una buona password, che tra l'altro consente facilmente di connettersi da più macchine.
L'elemento-chiave è avere un server ssh aggiornato (storicamente ci sono state falle di sicurezza, ma ormai qualsiasi distro da questo punto di vista non dovrebbe dare problemi).

Analogamente per il port knocking: attenzione a non "chiudersi fuori", nel senso che esiste il rischio di non potersi più connettere del tutto a causa di un blocco-terminazione inaspettata. Personalmente non lo consiglio se non è possibile avere certezza, nel caso, di poter avere un KVM IP per collegarsi (sia pure virtualmente) alla console.
Addirittura, in certi casi, se si adottano politiche molto (o troppo) restrittive sugli IP di collegamento c'è il rischio di perdere la possibilità di connessione, ad esempio perchè arrivano attacchi vari etc.

Riguardo all'elenco... c'è BIND, il che è potenzialmente male.

[khael]

K85bind9
c'è già la K davanti...
Cosa posso fare?

Ho rimosso i seguenti pacchetti:

Removing bind9 ...
Removing bind9-doc ...
Removing dnsutils ...
Removing bind9-host ...
Removing bind9utils ...

Va bene così?
grazie!

[khael]

ps: attualmente ho la vKVM, più avanti probabilmente prendo il secondo ip con la KVM hardware!
grazie

[vampirodolce1]

Allora non sei in quel runlevel ma avendolo disinstallato dovresti essere a posto.
Magari riprova col netstat.

P.S. Per vedere in che runlevel sei: 'who -r'

[Tasslehoff]

Concordo anch'io con quanto segnalato dagli altri, anch'io ritengo utile disabilitare l'accesso in ssh tramite password, chiaramente a patto di avere la console fisica sempre accessibile via KVM o interfaccia di lights-out (molto meglio in questo caso in modo da poter gestire anche l'alimentazione da remoto).

A me onestamente non piacciono molto i meccanismi di anti-hammering, dalla mia esperienza in genere provocano più disagi di quelli che risolvono.
Piuttosto io suggerisco un sistema che invii notifiche in caso di anomalie, insomma un log analyzer (o un IDS se lo vogliamo intendere in senso più ampio) tipo OSSEC.

[khael]

grazie a tutti per i consigli; penso stia venendo un risultato "accettabile".

Una domanda, è possibile lasciare una finestra in esecuzione?

cioè, quando io mi connetto con putty apri una sessione, alla sua chiusura la sessione si chiude; se io volessi lasciare i programmi in esecuzione e connettermi alla sessione è possibile?

Spero di essermi spiegato

grazie ancora

[wizard1993]

Originariamente inviato da khael

grazie a tutti per i consigli; penso stia venendo un risultato "accettabile".

Una domanda, è possibile lasciare una finestra in esecuzione?

cioè, quando io mi connetto con putty apri una sessione, alla sua chiusura la sessione si chiude; se io volessi lasciare i programmi in esecuzione e connettermi alla sessione è possibile?

Spero di essermi spiegato

grazie ancora

GNU screen is the way
piccola guida in italiano
http://guide.debianizzati.org/index.php/GNU/Screen

[vampirodolce1]

Confermo, si fa con screen. Puoi fare il detach e il reattach della sessione e funziona veramente bene!!

[khael]

grazie mille

mi metto a leggere