Hardening

Menu
MontelLUG frontpage
Feed RSS ultime modifiche
Aiuto: Come modificare le pagine

Avvisi iniziali

In questa microguida mi occuperò essenzialmente di hardening software, quindi assicuratevi che l'hardware della vostra macchina sia in un posto sicuro :-)

Altra nota: queste sono precauzioni abbastanza semplici ed elementari, ma che garantiscono una discreta sicurezza su un serverino di modeste dimensioni. Ci sono tante altre cose che sarebbe bene sistemare, tipo PAM, Kerberos e cosine del genere, ma non le ho mai trattate, quindi siate pazienti... anzi, se volete mandatemi suggerimeti ed aiuti :-)

Cocludendo le premesse, questa "guida" vuole essere un promemoria delle cose minime da fare per avere un server sicuro anche se si è dei principianti. Cominciamo, và...

Cosa ci installo? Che cosa è sicuro?

Innanzitutto, è bene sapere da dove il nostro server potrà essere attaccato: per una buona difesa bisogna conoscere i propri punti critici, per cui vediamo di lasciare installato solo il minimo indispensabile, specialmente se è un qualcosa che permette la comunicazione con l'esterno.

Esempio pratico: un server dati.

• Cose utili: Samba, ssh, uhm... basta direi ^_^
• Cose superflue: il resto :-D

Visto ciò, sarà bene "blindare" i due servizi, come si vedrà di seguito.

Altra cosa da tener presente è che il MALE esiste dappertutto, per cui tutto ciò che non è classificato come sicuro da noi (siamo gli amministratori, il bene e la sicurezza della macchina sono nelle nostre decisioni ed azioni >:-) ) è da classificare come MALE; da ciò si evince che qualsiasi persona all'infuori di noi stessi (e forse una o due altre personalità se siete mooolto fortunati) è da tenere alla larga dalla nostra preziosa macchia >:-DDD

Vedremo anche questo.

Ora si smanetta.

Impostazioni generali

Iniziamo con un'impostazione da sistemare appena dopo l'installazione: il CTRL-ALT-DEL. Mica vogliamo che lo spiritoso di turno ci faccia scherzetti, vero? Disabilitiamo l'impostazione di riavvio.

Disabilitare il riavvio alla pressione di CTRL-ALT-DEL:

• sul file /etc/inittab commentare la riga ca::ctrlaltdel:/sbin/shutdown -t3 -r now

Posizione fisica della macchina: naturalmente nel solito stanzino piccolo, buio, scomodo, polveroso e senza aria condizionata... o troppa, a seconda della vostra fortuna. Nonostante ciò, ci sarà sempre qualcuno che ha la pessima idea di voler mettere le sue zampacce sul server, per cui disabilitiamo un po' di shell, risparmiando anche un po' di RAM ^_^

Togliere le consoles che non servono:

• andare nel file /etc/inittab e commentare quelle che non servono (le righe con "tty" verso la fine)

Di solito se ne lasciano alcune disperse in posizioni strambe, tipo F5 o simili, tanto per fare i simpatici :-)

Visto che ci siamo, disabilitiamo anche il login diretto per l'utente root, così ci si deve prima autentificare con un utente normale e poi acquisire i diritti, immettendo quindi due password.

Blocco login utente root in locale:

• nel file /etc/securetty commentare tutte le consoles, o quelle da bloccare, se si vuole lasciare una possibilità.

Notare che ci sono anche quelle remote.

Bene. Bloccato il povero root e falciato un po' di consoles, passiamo a tagliare le gambe agli utenti >:-D

Ci sono due metodi: uno più elegante e uno decisamente brutale.

Blocco login in degli utenti.

• Metodo elegante:

in /etc/passwd, guardare in fondo alle righe delle opzioni degli utenti e cambiare la shell da /bin/bash in /bin/false

• Metodo brutale:

in /etc/shadow aggiungere un carattere (* o simili) nel campo della password

Ecco che succede: col primo si impedisce solo l'accesso ad un terminale, mentre col secondo si invalidano le password, con ovvie conseguenze per loro, mentre grande soddisfazione per noi.

Chi si sta chedendo: "ma se castrono le password, poi come fanno ad usare Samba?", sappia che esiste la possibilità di usare password diverse: siamo mica scemi da lasciare le stesse, vero? (<-- ramanzina da uno che ha cominciato i primi esperimenti su Samba con password in chiaro ed altri settaggi da paura '^_^)

E con questo i malefici lusers sono tagliati fuori dal grosso del sistema (sarebbe utile bandirli anche dalle directory condivise e dallehomes, ma poi si lamentano perché non riescono a salvare i loro importantissssssssimi files...)

Se però per qualche oscuro motivo non potete tagliarli fuori, o qualcuno deve smanettare (improbabile, ma per questo non impossibile), ecco di seguito una bella carrellata su alcuni accorgimenti per tenerli più controllati.

Avete presente quella simpatica utility per cui in shell se si premono le frecce su e gi scorre la lista dei comandi dati? Ebbene, si trovano tutti nel file .bash_history nella home del relativo utente. Naturalmente, più dati tiene e più informazioni avremo su quello che l'infido luser avrà combinato.

Allungare la cronologia dei comandi:

• nel file /etc/profile inserire:

HISTSIZE=4000
HISTFILESIZE=4000

Ora terrà 4000 righe.

Di seguito, invece, tre righe che permettono di "immagazzinare" il file .bash_history quando eccede dalle dimensioni predefinite, evitando cosìdi mandare in /dev/null tutto il nstro lavoro di tracciamento.

Salvare la cronologia degli utenti:

• nel file ~/.bashrc o ~/.profile aggiungere:

if [ 'wc -l .bash_history | awk '{print $1}' -gt 3500 ] ; then
cp -f .bash_history .bash_history-'date -I'
fi

Logs

Visto che siamo in tema di tracciamento mascalzoni, diamo un'aggiustatina ad un po' di log :-) Si lavora sul file login.defs

abilitare log di chi fallisce il login:

LOG_UNKFAIL_ENAB yes

loggare i login a buon fine:

LOG_OK_LOGINS yes

tentativi di su root:

SULOG_FILE /var/log/sulog

Poi, sempre qui c'è un'interessante opzione da controllare: se un utente riesce a loggarsi sul server ma non può accedere alla sua home, viene dirottato su / . Penso che ogni commento sia superfluo... direte "Sì, ma non ha i diritti..." beh, comunque non è simpatico lo stesso :-)

evitare scherzi da utenti senza home

DEFAULT_HOME no

Ponendo a no, nel caso non si abbia la home, non si accede al sistema.

SSH

Ora passiamo a sistemare ssh; andiamo a castron... ehm... sistemare il file /etc/ssh/sshd_config

Ci sarebbe molto da dire, ma presupponendo i lettori agli inizi, facciamo le cose di base (anche perché questo so '^_^)

Come al solito, iniziamo accanendoci sugli utenti, ed in particolare sul povero root, visto che è priviegiato con un comando tutto suo.

Blocco login utente root in remoto:

PermitRootLogin no

root non potrà più loggarsi direttamente: ci si dovrà prima autentificare con un utente valido e poi fare su

Vogliamo discriminare il resto della gente? No, vero? Bene, blocchiamo anche loro, quindi ^_^

Permettere solo ad alcuni utenti l'accesso:

AllowUser utente1 utente2 utente3

Tutti quelli non in lista non passano >:-)

Altre due cosette per blindare ssh: dove porre in ascolto il demone. La porta di default di ssh è la 22, ma visto che per un sysadmin "default" e "MALE, CATASTROFE, BRUTTE_COSE_IN_GENERE" sono sinonimi, lo si mette in ascolto su un'altra a vostra scelta. Ce ne sono circa 65301 (se ho controllato bene in internet '^_^), per cui scegliete voi quale più vi piace :-)

Cambiare la porta di ssh:

Port 22 <--- meglio spostarla

Visto che ci siamo, vediamo anche questa: se avete un firewall (o anche il server, o quello che volete) con due o più schede di rete, perché non fare in modo che ssh stia in ascolto solo su quella verso la LAN, o comunque più sicura? Voilà:

mettere in ascolto ssh solo su una scheda:

ListenAddress 192.168.3.110

Così accetterà collegamenti ssh solo dalla scheda con IP 192.168.3.110 . Bello, no?

Samba

E' ora di passare a Samba; file da analizzare: /etc/smb.conf

Come al solito, occupiamoci di root, impedendogli l'accesso al servizio:

esclusione di root (e/o di altri utenti) da Samba

invalid users = root

Naturalmente, se c'è un qualche utente che fa il "birichino", ci si può occupare anche di lui, aggiungendolo alla lista >:-)

Fatto questo, vediamo l'autenticazione degli utenti. Samba offre vari livelli di sicurezza, quindi vediamo di settare il più restrittivo e usiamo le password criptate; è di default, ma è sempre bene controllare :-)

Autenticazione a livello utente (si deve inserire nome utente e password per accedere dai client):

security = user

Utilizzo delle password criptate:

encrypt passwords = true

Precedentemente si erano fatte saltare le password degli utenti considerati "persone non gradite", quindi bisogna dire a Samba che si arrangi a gestirsi le sue :-)

Gestione indipendente delle password:

unix password sync = false

Da notare che gli utenti di Samba devono essere anche utenti del server, ma solo quelli presenti in /etc/samba/smbpasswd possono accedere alle risorse condivise.

Di fronte ad uno spazio di stoccaggio per lui infinito, il caro luser non ci penserà due volte a riversarci dentro tutti i suoi "importantissssimi, preziosissssimi, utilissssimi, e vitali" files inutili, specialmente se finiscono in .mp3, .avi e simili. Se si considera che la presenza di ciò è illegale (a meno che non ve li facciate voi), occupa spazio e che oltre a chi li ha prelevati ci rimette giuridicamente anche l'azienda, è buona norma tenere quest'ingombrante spazzatura molto distante dalle nostre macchine.

Impedire il salvataggio di certi files:

veto files = /*.mp3/ /*.wav/ /*.mpeg/ /*.avi/

Ricordatevi di stare attenti a quello che scrivete, per non impedire salvataggi leciti, o rischiare strane sparizioni: infatti se attivate questa opzione ad un server già operante e pieno di tutto è possibile fare un po' di pulizia in automatico dicendogli di bruciare i files vietati; ecco il comando:

bruciare i files vietati in automatico:

delete veto files = yes

Non so se di default sia attivo "yes" o "no", ma io ci andrei con i piedi di piombo (si sa mai :-) ) Se invece preferite fare le cose a manina, impostate a "no" l'opzione e date un'occhiata allo script in questa pagina: Shell_Tricks

L'ho usato personalmente ed è efficacissimo :-)

Gestione degli accessi a livello host

Per concludere, diamo una bella regolata anche ai vari pc che si possono connettere.

Per fare ciò, si usano i files in /etc (tanto per cambiare) hosts.allow ed hosts.deny

Prima di cominciare, però, ricordate che funzionano così: il sistema legge prima allow, se trova una corrispondenza permette l'accesso saltando il deny; se non si ottengono corrispondenze, passa al deny e se qui la trova, nega, altrimenti permette.

Per cui viene bloccato solo quello che è esplicitamente scritto su deny.

Sintassi: abbastanza elementare, ma molto flessibile: si tratta di due termini separati da ":", di cui il primo identifica il servizio preso in esame, mentre il secondo a chi si fa riferimento, più eventuale sintassi per raffinare. Gli esempi sono di seguito.

File hosts.deny

Si scrive ALL : ALL , così gli si dice di bloccare tutto, a meno che non sia specificato in host.allow

File hosts.allow

Si inserisce chi può fare l'accesso al sistema.
Con ALL : 192.168.3. si permette alla sottorete 192.168.3.0/255 di poter accedere alla maccina
Altro esempio: ALL : 192.168.3. EXCEPT 192.168.3.200 : tutti si possono connettere, tranne 192.168.3.200

Conclusioni, ringraziamenti, bibliografia, saluti finali, ecc.

Con questo per ora ho finito. Per maggiori informazioni si rimanda ai vari man, a internet, a google e ad un bel po' di persone più esperte di me :-)

Spero di aver scritto qualcosa di interessante ed utile; ringrazio la redazione di Linux & c. (dalla quale ho tratto più di uno spunto dai loro articoli riguardanti l'hardening), un bel po' di siti internet (e loro curatori) che ora non ricordo ma dai quali ho estratto altro materiale, i poveri disgraziati che si sono subiti i miei stati di estasi dopo aver limitato ancora di più gli utenti... mi pare basti... Ah, anche voi che state leggendo: fa sempre piacere essere utili a qualcuno ^_^

Daneel Olivaw

Appendice

Visto che ho trovato una paginetta interessante dopo aver concluso il tutto, qui sotto riporterò links o altro visto in giro o segnalato :-)

• Da Programmazione.it un'interessante panoramica su dove mettere le mani per aumentare la sicurezza
• Da sistemistiindipendenti.org una guida in pdf per proteggere un webserver
• Sempre da sistemistiindipendenti.org una soluzione per non chiudere porte utili ma bersagliate da tentativi di forzatura a raffica: il Port Knocking (in pdf)