Michele PinassiPer i dettagli sul progetto guardate la pagina su www.gnu.unisi.it. Io vi voglio raccontare quello che è stata la mia attività.
Sala di lettura “Chiesa della Rosa”: 5 PC con Windows XP con accesso alla rete, completamente infestati di virus e malware vario, lenti e spesso neanche funzionanti. Arriviamo con un PC “server” in spalla, che funzionerà da proxy per una sottorete creata ad-hoc (per beghe istituzionali di autenticazione). In tasca il CD della Debian 5.0.3 Lenny ed una patch di rete.
Attacco il server alla rete, monitor, tastiera e parto con l’installazione della Debian. Da buon sistemista, al contrario di molti, NON installo X nè qualsiasi altra cosa abbia a che fare con X: attraverso SSH si riesce egregiamente a fare di tutto. Chi ha bisogno del mouse per gestire un server, meglio che mediti di cambiare lavoro.
Debian si installa senza problemi e tutto l’hardware della workstation HP xw4200 viene visto perfettamente.
Prima scelta strategia: partizionare il disco. Ho a disposizione 160GByte di hard disk…un’enormità rispetto al necessario. Decido di creare una / da 40GByte, 1 Gbyte per /boot ed il restante per /var, dove andranno tutti i log ed i DB di MySQL. Riservo 512MByte per lo swap.
Seconda scelta strategica: il software. Sono alla scelta dei pacchetti. Non rinuncio alla suite gcc, make etc etc per la compilazione di nuovi programmi. Installo Squid, Apache, MySQL, PHP, Postfix per la messaggistica, Monit per il monitoring dei processi, iptraf per controllare cosa succede nella rete. La partizione di root è stata occupata per circa 1GByte.
Terza scelta strategica: la rete. Finalmente si inizia a parlare di cose serie: come organizziamo la rete ? Decidiamo di creare una intranet 192.168.10.x per i PC al pubblico (dotandoli di IP fisso così da saper intervenire, via SSH, in caso di bisogno) e dotiamo il server proxy di due schede di rete (inizialmente creo una interfaccia virtuale sulla eth0: eth0:1): IF pubblica ed IF privata (192.168.10.1). Modifico il file /etc/network/interfaces:
allow-hotplug eth0 iface eth0 inet static address 172.x.x.x netmask 255.255.248.0 gateway 172.x.x.xauto eth1 iface eth1 inet static address 192.168.10.1 netmask 255.255.255.0 network 192.168.10.0 broadcast 192.168.10.255
Verifico la connettività e passo a configurare lo Squid, il proxy. Scelgo non implementare una soluzione di transparent-proxy perchè prevediamo di utilizzare dei redirector (tipo SquidGuard) per la gestione e blocco del traffico. Implemento l’autenticazione sul server LDAP di Ateneo così da permettere la navigazione solamente agli utenti dotati di account:
auth_param basic program /usr/lib/squid/ldap_auth -v 3 -b "dc=xxx,dc=it" -D "cn=xxx,ou=admin,dc=xxx,dc=it" -w xxx -f "(&(uid=%s)(objectclass=Person))" ldap.xxx.it
auth_param basic children 5
auth_param basic realm PASS
auth_param basic credentialsttl 1 minute
authenticate_ttl 2 hours
e mi riservo la possibilità di aggiungere dei domini visitabili anche da persone non autenticate (ad es. la pagina istituzionale o il catalogo):
acl noauthurl url_regex "/etc/squid/noauth.lst"
http_access allow noauthurl
decido anche di facilitare il compito ad un eventuale log analyzer (come webalizer) impostando il formato “combined” per i log di Squid:
logformat combined %>a %ui %un [%tl] "%rm %ru HTTP/%rv" %Hs %<st "%{Referer}>h" "%{User-Agent}>h" %Ss:%Sh
access_log /var/log/squid/access.log combined
Ok, per il momento può bastare. Per il fine-tuning ci sarà, e ci vorrà, tempo. Passo adesso a lavorare ad una delle parti più delicate di un server: il firewall.
Impostare delle buone regole di firewalling penso sia una delle attività più difficili che un sistemista si trovi a dover compiere: una scelta sbagliata può compromettere tutta la funzionalità dei servizi e la scelta di cosa permettere e cosa bloccare richiede una buona conoscenza dei protocolli TCP, UDP ed ICMP e relativi servizi assegnati alle porte.
Insomma, il firewall deve proteggere: una corazza deve essere indossata bene perchè se cade al primo fendente….che corazza è ? 🙂
Ovviamente non starò a spiegarvi per filo e per segno cosa ho fatto in merito alle regole di firewalling. Dirrò che ho usato le splendide IPTABLES per gestire il tutto nel migliore dei modi e con risultati più che soddisfacenti !
Se per voi una riga così è arabo, non siete decisamente pronti a configurare un firewall:
[193883.833623] IN=eth1 OUT=eth0 SRC=192.168.10.xxx DST=130.59.10.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=7438 DF PROTO=TCP SPT=44968 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Non disperate: su netfilter.org trovate, comunque, tutto quello che vi serve !
Bene, adesso, mentre i miei colleghi sono alle prese con le 5 postazioni utente, mi dedico all’HP ProCurve (uno Switch) per far configurare una bella VLAN dedicata per la intranet della sala.
A questo punto passiamo alle raffinatezze che un sistema GNU/Linux offre. Innanzitutto implemento un bel sistema di monitoring continuo su tutti i servizi presenti nella macchina usando MonIT (apt-get install monit) e configurando adeguatamente /etc/monit/monitrc. MonIT controlla i servizi e, in caso di problemi, tenta il riavvio notificando agli indirizzi e-mail impostati l’evento. Per evitare problemi nella notifica ho scelto di installare un MTA (Mail Transport Agent) direttamente sulla macchina. La scelta è, ovviamente, ricaduta su Postfix (apt-get install postfix). Installo anche webalizer per fare l’analisi dei log di Squid così da avere anche una reportistica di uso delle postazioni. In più decido anche di implementare un server dns caching-only con bind9.
A questo punto riavvio (notare: riavvio !) per verificare le configurazioni di startup.
Alla fine, in una giornata di lavoro, abbiamo migrato 5 postazioni a Ubuntu Linux e configurato un server proxy Debian per il tutto, spendendo ZERO per il software e recuperando tutte le macchine esistenti.
La Chiesa della Rosa è stata liberata dalla malefica M$ !!!
Hai trovato utile questo articolo?
