Cerchiamo di rendere piu' sicuro il nostro server Sono pessimista? No, pero' sappiamo tutti che l'unico computer sicuro e' quello spento e con la spina staccata, quindi.... Il sistema sicuro non esiste, pero' esiste spesso un falso senso di sicurezza che e' piu' dannoso di un sistema vulnerabile :) Dopo queste perle di saggezza possiamo introdurre qualche buona tecnica per aumentare il grado di sicurezza del nostro caro server :)))) La prima scelta e' sicuramente il sistema operativo, scarterei sicuramente windows in favore di un piu' stabile *BSD o di un piu' versatile e comodo Linux, ma tutto e' dettato dalla priorita': se avete bisogno di un server che sia stabile come il granito e che non si puo' permettere di crashare dopo 2 mesi di uptime, beh, a quel punto OpenBSD e FreeBSD (opportunamente patchati per evitare di essere rootati da remoto tramite telnet :) faranno egregiamente il loro bel lavoro, se invece potete permettervi un eventuale crash ogni due mesi, a quel punto possiamo mirare su una comoda linux box. Per quella poca esperienza che posso vantare, sceglierei una Slackware o una Debian, se il vostro pc deve essere un server allora probabilmente non avra' un grande workload e quindi tutti i dieci cd bonus della redhat sarebbero solo superflui, inoltre ricordate che piu' e' il software installato sul pc, meno e' la sicurezza. La prima cosa da fare e' installare una qualche distribuzione con il minor numero di programmi possibile, quindi evitate tutte quelle cose che possono sembrare carine ma che di fatto non usereste mai :), evitate di installare sendmail e mettete su un bel postfix, per il resto possiamo lasciare tutto cosi', poi upgraderemo in seguito. Una volta messa su la nostra bella distribuzione dobbiamo fare due cose fondamentali: aggiornare il kernel ad una versione stabile (ora siamo alla 2.5.1 si presume quindi che il 2.4.x sia in fase di stabilizzazione ma anche il 2.2.x e' davvero ottimo) e patcharlo con qualcosa per aumentarne la sicurezza...Ma cosa? Ho trovato davvero strabilianti la patch della grsecurity (grsecurity.net). Questo gruppo ha riunito in un comodo file il lavoro svolto dai ragazzi della PaX e quello svolto dai programmatori della OpenWall, l'autore ha anche inserito ulteriori migliorie e dopo aver patchato il nostro kernel avremo queste features in piu': - Lo stack non sara' piu' eseguibile rendendo pertanto estremamente difficili da portare a termine tutti i tentativi di Buffer Overflow (o cmq andrebbero modificati gli exploit cosa che la maggior parte delle persone non sa fare, oltretutto in condizioni _delicate_ non e' proprio possibile modificare l'exploit senza minarne il corretto funzionamento) - Non sara' possibile inserire codice esterno nella memoria in cui sta girando un processo (il free exploit ad esempio) pertanto i propri privilegi non potranno esser elevati tramite questa tecnica :) - Insieme allo stack non eseguibile avremo anche il supporto per il trampoline code e questo ci dara' un'ulteriore difesa - La base degli indirizzi che alloca mmap sara' completamente random quindi il sistema sara' ulteriormente difficile da exploitare anche tramite address-guessing - Si ha una comoda protezione verso le temp race conditions (youhuu :P) - I PID sono randomizzati :) - Tante restrizioni sull'accesso alle directory - La macchina non risponde agli ICMP e gli OS Guessing sono letteralmente impossibili... ....Tanto altro, ma vi rimando al readme di questa splendida patch perche' l'autore armato di buona voglia ha fatto anche tanti piccoli esempi sicuramente utilissimi. Una volta patchato il kernel siamo discretamente piu' sicuri...Ci resta da prendere ancora qualche piccolo accorgimento. Tanto per cominciare eliminiamo fisicamente telnet e telnetd dal sistema, leviamo sendmail se l'avete messo :) togliamo tutti i bit suid se non utilizziamo determinati programmi (ad esempio, lpd suid e' inutile se non si usa lpd). Mettiamo su la release piu recente di OpenSSH/OpenSSL (mai utilizzare versioni vecchie visto che sono quasi tutte vulnerabili anche se gli exploit non sono released), installiamo un buon demone ftp (sempre se ci serve), io opterei per un ProFTPd anche se le obiezioni potrebbero essere tante. Tuteliamoci levando l'accesso anonymous a meno che non vogliate metter su un server warez :) o un qualche mirror. Disabilitiamo l'accesso remoto da root su tutte le console ad eccezione della stty (se invece non avete bisogno di loggarvi come root da remoto allora blindatele tutte) aprite /etc/login.defs (per le slackware): # If defined, either full pathname of a file containing device names or # a ":" delimited list of device names. Root logins will be allowed only # upon these devices. # # Inserite questa linea per consentire l'accesso root sulla stty o commentatelo # per disabilitarla CONSOLE /etc/securetty #CONSOLE console:tty01:tty02:tty03:tty04 Sempre smanettando su questo file, fate in modo che non venga mostrata la versione del kernel al login, non e' molto, ma e' qualcosa :) Fatto questo passiamo alla configurazione del firewall, per kernel 2.4 e superiori avremo iptables, una configurazione di base potrebbe essere questa: iptables -A INPUT -i eth0 -p tcp -m state --state INVALID -j DROP iptables -A INPUT -i eth0 -p udp -m state --state INVALID -j DROP iptables -A INPUT -i eth0 -p tcp --syn -m limit 1/second -j ACCEPT Le prime due rules sono chiare, la terza invece serve per evitare i synflood, ovvio che se dovete gestire 100.000 connessioni al giorno su un grosso server allora non potete inserire l'ultima rule. Se il vostro server non deve accettare connessioni dall'esterno potete chiudere tutte le porte, se invece i vostri utenti sono limitati potete configurare iptables per accettare solo determinate mask, al contrario, se i vostri utenti sono molti, non potete far altro che limitare le mask che NON vi piacciono :P, usare i programmi reputati _sicuri_, utilizzare meno servizi possibili e limitare pesantemente i permessi di accesso (la patch di grsecurity permette tra le tante cose, anche di settare una ACL che e' comodissima dal momento che potete decidere anche quanta memoria puo' utilizzare per i propri processi un singolo utente, cosi da evitare fork bomb). Blindate ovviamente la porta delle RPC (111 per chi non lo sapesse) e commentate tutto cio' che non vi serve in /etc/inetd.conf (ftp ed altre cose e' meglio che le fate partire come standalone) Un'ottima idea e' quella di metter su snort (www.snort.org) e configurarlo in modo da sniffare tutte le stringhe _caratteristiche_ degli exploit (lo shellcode ad esempio). Mentre verso l'interno della LAN io metterei uno sniffer tipo ettercap (ciao ALoR :)) che ci consente rapidamente di vedere tutto cio' che puo' essere anomalo. Se avete fatto tutto come descritto, ora dovreste avere uno sistema cosi configurato: Kernel Patchato, servizi opportunamente filtrati, sniffer verso la rete internet e verso l'interno, possibilita' limitata di login root su console....Vi pare abbastanza? Io dico di no, possiamo fare di meglio, innanzitutto dobbiamo loggare tutto quello che avviene sul nostro sistema, opterei per un clone del syslog come ad esempio syslog-ng che mi e' sembrato davvero buono, se proprio siete paranoici fate come me, mi sono fatto uno scriptino che ogni due tre ore mi critta i log cosi' li leggo e li modifico solo io :) Loggate pesantemente l'attivita' su tutti i servizi piu' usati (come ftp) magari utilizzando anche semplicemente iptables in questo modo: iptables -A INPUT -p tcp -s ! 10.0.0.0/24 --dport 21 -j LOG --log-prefix "FTP TCP Access Attempt!" Dove 10.0.0.0/24 e' la nostra lan, questa rule logga tutti gli accessi su ftp, guardate un esempio sulla mia macchina: Dec 26 11:48:21 xxxxx kernel: FTP TCP Access Attempt! IN=ppp0 OUT= MAC= SRC=203.78.94.131 DST=xx.xxx.xx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=51 ID=9927 PROTO=TCP SPT=49853 DPT=21 WINDOW=4096 RES=0x00 SYN URGP=0 Nel caso invece si logghi una macchina della LAN, si ottiene qualcosa come: Dec 26 21:34:09 xxxxx kernel: FTP Connection AttemptIN=eth0 OUT= MAC=00:e0:3c:56:32:27:00:e0:3c:89:14:6b:05:00 SRC=10.0.0.9 DST=10.0.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=31415 DF PROTO=TCP SPT=1401 DPT=21 WINDOW=16484 RES=0x00 SYN URGP=0 Questo ci da una panoramica globale su quello che avviene dentro e fuori la rete, ora possiamo gia stare poco piu' tranquilli :). Se proprio vi va, potete fare una cosa utilissima, i BSD ogni tot ore mandano al root una mail con il report di tutti i file suid del sistema, l'ideale sarebbe farsi un semplicissimo scriptino che ogni 12-24 ore vi manda un report di tutti questi spostamenti su una casella esterna (tipo yahoo o hotmail). Un esempio potrebbe essere questo, fatto sul momento: ------------------8<---CUT HERE-----8<--------------------------- #!/bin/sh find / -type f \( -perm -04000 -o -perm -02000 \) -ls > /tmp/suid md5sum /tmp/suid >> /tmp/suid cat /tmp/suid | mail root ------------------8<---CUT HERE-----8<--------------------------- Mettetelo nel cron ogni 12 ore e via.... :) E' stato fatto tutto il possibile per rendere sicuro il nostro bel server? Naaaa non credo proprio, in realta' si potrebbe fare qualcosa di seriamente bello, ovvero rendere il nostro server un MAC (Mandatory Access Control), e' un tipo di organizzazione utilizzato sui sistemi militari, e' una soluzione un po' laboriosa ma e' davvero strastupenda, credo che ne scrivero' presto un tutorial, quindi, antenne dritte ragazzi :PPP Saludosssss -=Quequero=- SpP/Member http://www.spippolatori.org UIC Founder http://quequero.cjb.net