Il delirio di MarcoGNU

Se anche tu, come me, ti trovi a gestire dei server Debian GNU/Linux, ti consiglio vivamente di passare da Etch a Lenny, in modo tale da lasciarti alle spalle il bug di OpenSSL 0.9.8.c, cioè quello per cui il generatore di numeri casuali non era poi così tanto casuale (DSA-1571-1).

Cosa è successo?

Nei giorni scorsi qualcuno ha cercato di forzare Apache per mettere al suo posto uno script che aprisse un socket sulla porta 80 verso il mondo esterno, per poi fare chissà cosa. Ovviamente questo script ha lasciato traccia nell’error_log di Apache, quindi è stato facile sgamarlo. In più il pirla ha usato un bell’IP pubblico, appartenente al pool di IP di un provider texano, per cui ho potuto agevolmente segnalare l’abuso allo stesso provider.

Il risultato di questo tentativo di hack del mio server è stato solo il down di Apache, dovuto al fatto che il web server riscontrava un conflitto sulla porta 80 e quindi non partiva.

Dopo questo episodio ho deciso quindi di fare una bella distro-upgrade in modo tale da levare per sempre i rischi di bug e altro, derivanti dai vecchi packages presenti nei repository di Etch. Putrtoppo infatti, nonostante gli aggiornamenti vari, l’OpenSSL era sempre alla versione 0.9.8c. Sì, sicuramente patchato, però il timore di vedersi il server bucato ti resta nel cervello…

Per procedere con l’upgrade della distro vi consiglio il seguente articolo, molto utile e preciso: cyberciti

Come leggerete in tale articolo, l’autore cita iptables. Altro mio consiglio spassionato: non fate come me, che pur conoscendo bene tale software – peraltro strafico perché semplicemente fa quello che deve fare – non lo avevo ancora configurato.

Iptables vi permette di filtrare tutto il traffico attorno al vostro server; se passate a Lenny, probabilmente lo troverete già installato e attivo, ma senza alcuna regola impostata. Non fatevi intimorire dalla sua sintassi, perché di fatto è molto intuitiva.

Dato che avevo a disposizione un file di regole che scrissi per Fedora, prima di fare cazzate ho chiesto al buon vecchio Google se sapeva darmi qualche indicazione specifica per Lenny (le distro qualche differenza tra di loro la devono pur implementare, se no a cosa serve averne n-mila a disposizione? ;-)

Sappiate che la cosa fondamentale da fare con iptables è non chiudersi mai fuori dal server stesso, se no per ripigliarlo o vi rivolgete al vostro houser, che interverrà con un reset della macchina, magari pigiando il tastino posto sullo chassîs del server stesso, o, peggio, staccandogli la corrente, oppure vi rivolgete a qualche divinità la quale però non vi darà retta perché fino ad un attimo prima l’avrete nominata più e più volte accostandola ad aggettivi che richiamano il mondo animale.

Questo è uno script shell che ho adattato alle mie esigenze:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117

#!/bin/sh
# ...
# Script per la configurazione di iptables
# Rev. 1.0.4 - 20090326
 
check ()
{
  if [[ ! -x "\$1" ]]
  then
    echo "\$1 not found or is not executable"
    exit 1
  fi
}
 
IPTABLES="/sbin/iptables"
check "$IPTABLES"
 
#IPTABLES=iptables_debug
rule_counter=1
iptables_debug ()
{
   echo "doing ( $((rule_counter++)) ): \"/sbin/iptables $*\""
   /sbin/iptables $*
}
 
INTERFACE=$1
if [[ "$INTERFACE" == "" ]]
then
   echo "Usage: $0 <network>"
   exit 1
fi
 
echo -n "Attempting to bring up firewall on $INTERFACE: "
 
# Cancella ogni regola precedente:
$IPTABLES -F
$IPTABLES -t nat -F
$IPTABLES -t mangle -F
$IPTABLES -X
 
# Regole di default:
$IPTABLES -P INPUT   DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT  DROP
 
# Catene di regole:
# ICMP:
iptables -N icmp-chain
$IPTABLES -A icmp-chain -i $INTERFACE -p icmp --icmp-type echo-reply -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A icmp-chain -i $INTERFACE -p icmp --icmp-type echo-request -m limit --limit 5/s -m state --state NEW -j ACCEPT
$IPTABLES -A icmp-chain -i $INTERFACE -p icmp --icmp-type destination-unreachable -m state --state NEW -j ACCEPT
$IPTABLES -A icmp-chain -i $INTERFACE -p icmp --icmp-type time-exceeded -m state --state NEW -j ACCEPT 
$IPTABLES -A icmp-chain -i $INTERFACE -p icmp --icmp-type timestamp-request -m state --state NEW -j ACCEPT 
$IPTABLES -A icmp-chain -i $INTERFACE -p icmp --icmp-type timestamp-reply -m state --state ESTABLISHED,RELATED -j ACCEPT 
# ogni altra cosa respinta:
iptables -A icmp-chain -j DROP
 
# SERVIZI:
$IPTABLES -N services
# regole specifiche:
# ssh:
$IPTABLES -A services -p tcp -i $INTERFACE --dport 22 --sport 1024:65535 -m state --state NEW -j ACCEPT
# www:
$IPTABLES -A services -p tcp -i $INTERFACE --dport 80 --sport 1024:65535 -m state --state NEW -j ACCEPT
$IPTABLES -A services -p tcp -i $INTERFACE --dport 443 --sport 1024:65535 -m state --state NEW -j ACCEPT
# ftp:
$IPTABLES -A services -p tcp -i $INTERFACE --dport 21 --sport 1024:65535 -m state --state NEW -j ACCEPT
$IPTABLES -A services -p tcp -i $INTERFACE --dport 35000:36000 -m state --state NEW -j ACCEPT
# named:
$IPTABLES -A services -p tcp -i $INTERFACE --dport 53 --sport 1024:65535 -m state --state NEW -j ACCEPT
$IPTABLES -A services -p udp -i $INTERFACE --dport 53 --sport 1024:65535 -m state --state NEW -j ACCEPT
$IPTABLES -A services -p tcp -i $INTERFACE --dport 953 --sport 1024:65535 -m state --state NEW -j ACCEPT
# ntpd:
$IPTABLES -A services -p tcp -i $INTERFACE --dport 123 --sport 1024:65535 -m state --state NEW -j ACCEPT
# ogni altra cosa respinta:
$IPTABLES -A services -j DROP
 
# Blocca frammenti e "Xmas tree", SYN,FIN e SYN,RST:
$IPTABLES -A INPUT -i $INTERFACE -p ip -f -j DROP 
$IPTABLES -A INPUT -i $INTERFACE -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP 
$IPTABLES -A INPUT -i $INTERFACE -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP 
$IPTABLES -A INPUT -i $INTERFACE -p tcp --tcp-flags SYN,RST SYN,RST -j DROP 
 
# Tutto attivo su loopback:
$IPTABLES -A INPUT -i lo -s 127.0.0.1 -j ACCEPT 
$IPTABLES -A OUTPUT -o lo -d 127.0.0.1 -j ACCEPT 
 
# BLACK LIST:
$IPTABLES -A INPUT -i $INTERFACE -s 69.13.93.44 -j DROP
$IPTABLES -A OUTPUT -d 69.13.93.44 -j DROP
$IPTABLES -A INPUT -i $INTERFACE -s 205.134.160.58 -j DROP
$IPTABLES -A OUTPUT -d 205.134.160.58 -j DROP
$IPTABLES -A INPUT -i $INTERFACE -s 205.134.160.74 -j DROP
$IPTABLES -A OUTPUT -d 205.134.160.74 -j DROP
 
# connessioni gia' stabilite permesse:
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# Anti-spoofing:
$IPTABLES -A INPUT -i $INTERFACE -s 200.200.200.200 -j DROP 
$IPTABLES -A INPUT -i $INTERFACE -s 192.168.0.0/24 -j DROP 
$IPTABLES -A INPUT -i $INTERFACE -s 127.0.0.0/8 -j DROP 
 
# Blocca pacchetti NEW senza SYN:
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP 
 
# Connessioni in uscita:
$IPTABLES -A OUTPUT -m state --state NEW -j ACCEPT 
 
# Attiva la catena ICMP:
$IPTABLES -A INPUT -p icmp -j icmp-chain
# Attiva la catena servizi:
$IPTABLES -A INPUT -i $INTERFACE -m state --state NEW -j services
 
echo "done."
exit 0

Lo script svuota le regole di iptables già presenti in runtime e carica quelle in esso contenute. In questo modo, eseguendolo sarete al riparo dal rischio di fare un flush delle regole senza avere poi la possibilità di riaprirvi l’accesso in ssh: lo script infatti, tra le prime azioni che compie, imposta il firewall in modo tale che di default rifiuti TUTTE le connessioni in entrata, quindi se avete già eseguito almeno una volta questo codice e poi fate un flush da linea di comando, vi ritroverete chiusi fuori e senza chiavi! Occhio quindi a non fare MAI un “iptables -F” senza avere aperto un varco verso il server stesso, se no ritorniamo al punto houser o divinità. Sarò ridondante ma tenete sempre in mente che se iniziate a manipolare le regole con questo script, è meglio che continuiate a farlo con questo script!

Nota importante: nel mio caso sul server dove questa configurazione è attiva non gestisco i servizi di posta per terzi, quindi come potete vedere dal codice, il firewall permetterebbe la connessione al servizio smtp solo dall’interfaccia di loopback, quindi solo locali (ad esempio da applicazioni che devono inviare e-mail). Se avete bisogno di filtrare il traffico per questo servizio, aggiungete le dovute regole alla catena “services” in modo tale che i vostri utenti possano collegarsi correttamente ad esso. Questo vale per ogni servizio che dovete fornire all’esterno del vostro server.

Altre due cose utili da fare:

la prima è salvare il set di regole in runtime in modo tale da creare un file di configurazione per le regole di iptables, in questo modo:

# iptables-save > /etc/firewall.conf

la seconda è creare uno script di avvio in modo tale che il set di regole venga caricato da iptables ad ogni riavvio del server:

create ad esempio il file “/etc/network/if-up.d/iptables”, rendetelo eseguibile con un “chmod +x /etc/network/if-up.d/iptables” e scrivetegli questo contenuto:

#!/bin/sh
iptables-restore < /etc/firewall.conf

Ovviamente i set di regole possono essere personalizzati a seconda delle proprie esigenze e dei servizi che si vogliono o devono offrire, inserendo, come si evince dal codice, regole per bloccare ogni comunicazione con determinati IP remoti, creando quindi una sorta di black list.

Buon divertimento!

Tutti noi abbiamo in casa una workstation basata su processore DEC Alpha ;)
Nel mio caso si tratta di una Personal Workstation Alpha 600a¹ con impresso il glorioso marchio “Digital”, perfettamente funzionante, sulla quale nel tempo ho usato WinNT 4.0 Workstation, FreeBSD 4.7 e, da qualche tempo, Debian 4.0 Etch.

Sebbene lo meriterebbe, con questo post non intendo raccontare tutta la storia dell’hardware che caratterizza le PWS – quando questa classe di workstation apparve sul mercato, i processori x86 più potenti erano i PentiumII a 300MHz -, né tanto meno le peculiarità del software che su tale hardware poteva girare. Basti sapere che i s.o. sviluppati per tale hardware sono appunto NT4.0, OpenVMS, True64 (e prima Digital Unix), FreeBSD e qualche distro Linux.

Vabbè, tanto per renderle giustizia, la 600a monta un DEC Alpha 21164 a 600MHz (quello col dissipatore di calore bullonato sopra). Il processore Alpha con la sua architettura RISC e le sue varie evoluzioni del bus EV, grazie alla compravendita di brevetti Digital² avvenuta tra la fine degli anni ‘90 e la prima metà di questo decennio, è alla base dell’evoluzione, dell’incremento di prestazioni e di frequenze di clock che i processori AMD ed Intel hanno avuto in questi 10 anni.

Un altro pezzo forte delle PWS è la scheda grafica. La mia 600a monta di serie una PowerStorm 4D60T marchiata Digital e prodotta da Intergraph³, sulla base del chipset grafico delle schede RealiZM. Purtroppo solo con WinNT ho potuto godere della tremenda accelerazione hardware OpenGL che questa scheda fornisce, giocando a Quake2, per giunta con codice x86 tradotto per Alpha dal layer FX!32⁴ in real-time… massimo rispetto per quegli sviluppatori visionari! Col driver TGA di XFree86 e di X.org infatti funziona solo la sezione che monta un Cirrus Logic GD5440 con, se non ricordo male, 1MB di ram video, mentre il resto dell’elettronica è del tutto ignorato. Risultato: scheda smontata, gelosamente conservata e sostituita con una più comune ATI PCI.

Ok, tralasciando questi ricordi da anziano, sulla 600a ho messo Debian 4.0 Etch. Siccome sono fresco fresco di re-installazione, ho pensato di riportare qui i passi da seguire per una corretta installazione, si sa mai che possa servire a qualcuno.

Quanto sto per scivere vale sia per i modelli “a” che per gli “au”. La differenza sta nel fatto che gli “a” venivano forniti con Windows mentre gli “au” con Unix.

Tutte le PWS di Digital e, in seguito, di Compaq hanno di serie un doppio firmware:
- SRM console;
- ARC, meglio consociuto come AlphaBIOS.
Il primo è necessario per il boot dei sitemi Unix-like mentre il secondo emula il bios di un comune pc e serve per l’avvio di WinNT4.0. Inoltre il primo supporta il disklabel degli Unix BSD, mentre il secondo la partition table di MS-DOS.
Il primo passo da fare è dunque abilitare il boot via SRM console, ammesso che non sia già così. Per farlo è sufficiente avviare la workstation, premere F2 per accedere al setup del bios, andare sulla voce “Advanced CMOS Setup/Console Selection” e scegliere “Unix (SRM)”, salvare la modifica e spegnere la workstation. Attenzione: se non viene spenta, al reboot viene  eseguito ancora l’AlphaBIOS.

SRM presenta pochi comandi, simili a quelli di Unix; qui è sufficiente sapere che scrivendo al prompt “help” si ottiene la lista dei comandi disponibili, mentre scrivendo “help <comando>” si ottiene l’help del comando indicato.

Un comando fondamentale è “show device”, che in output mostra la lista dei device disponibili.
Nel mio caso ad esempio ho:

>>> show device

dove la prima colonna è il nome effettivo del device, la seconda è un alias più adatto a noi umani, la terza è la stringa di descrizione fornita dal device e la quarta è la versione del firmware del device stesso, se disponibile (il comando mostra anche le schede PCI installate e riconosciute).
Dischi e unità ottiche sono le varie DKC, mentre la scheda di rete è EWA0.

Per fare il boot da un qualunque device, si usa il comando “boot”.
Nel caso dell’avvio dell’installazione da cd/dvd si scrive qualcosa di simile a questo:

>>> boot DKC300

Al comando boot si possono fornire due parametri:
-file per indicare quale immagine del kernel usare;
-flags per passare delle opzioni all’immagine del kernel.

Se non si fornisce alcun parametro, viene eseguito il boot da cd e si arriva al prompt di “aboot”.
Aboot è un boot manager per Linux su sistemi Alpha con SRM console… appunto. Si trova qualcosa di simile – yaboot – anche quando si vuole installare Debian su Mac-PowerPC.

Aboot ha dei comandi semplici. Quello che serve sapere in questa sede è che digitando “l” si ottiene la lista delle immagini bootabili del kernel, identificate da un numero compreso fra 0 e 9; è sufficiente indicare “0″ per eseguire l’immagine di default, che avvia l’installazione semi-grafica.

aboot>0

L’alternativa ad aboot è scrivere al prompt di SRM il seguente comando:

>>> boot DKC300 -flags 0

in questo modo aboot non presenta il suo prompt perché sa già quale immagine del kernel usare per l’avvio e il boot da cd porta subito nella procedura semi-grafica di installazione… sì, quella in stile Slackware, senza punta&clicca, che si usa con tastiera e tasto TAB a manetta.

A mio parere è meglio passare per aboot, perché alla fine dell’installazione e dopo il riavvio ci si ritroverà ancora lui a gestire l’avvio di Linux e questo torna utile nel caso ci fossero problemi subito dopo la prima installazione.
Premendo “q” infatti si torna al prompt di SRM e da qui poi sarà possibile testare l’avvio della workstation con l’apposito comando – che descriverò tra poco – per poi automatizzare l’avvio di Linux.

La procedura fa le solite cose, viste e riviste un sacco di volte (del resto chi si ferma a leggere questo post, Linux l’avrà già installato anche sulla centralina della caldaia!).

Arrivati al partizionamento dei dischi, ci si deve ricordare che per Alpha bisonga avere una partizione per aboot (basta 1MB) e una partizione di avvio per “/boot”, formattata tassativamente in ext2. Il resto a discrezione e in base al disco o ai dischi a disposizione. L’installazione procede come di consueto. In particolare io ho scelto la netinstall, per la comodità di avere un cd leggero e l’ADSL pagata per qualcosa di utile, hehehe!
Una volta finita l’installazione, si riavvia la workstation.

A questo punto, prima di automatizzare la procedura di avvio, val la pena verificare che aboot legga correttamente l’immagine del kernel.
Come prima, digitando “l” si ha la lista dei kernel disponibili e digitando “0″ si avvia Debian col predefinito per la nostra installazione fresca fresca… e dopo poco si vedrà Etch in tutto il suo splendore.

Nel caso ci fossero problemi, premendo “q” in aboot oppure premendo come dei forsennati la combinazione CTRL-C, è possibile interrompere la sequenza di avvio e ritornare al prompt di SRM.
Da qui è sufficiente scrivere:

>>> boot <device> -flags <n>

nel mio caso:

>>> boot DKC0 -flags 0

per verificare che la workstation esegua correttamente il boot di Debian.

Se tutto va a buon fine – e si torna ad avere Debian in tutto il suo splendore -, usando i seguenti parametri digitabili sempre dal prompt di SRM, si imposta il boot automatico, in modo tale da saltare l’interazione con SRM e con aboot:

>>> set boot_osflags 0
>>> set bootdef_dev DKC0
>>> set auto_action BOOT

Qui poi o si riavvia la workstation oppure si scrive per l’ultima volta il comando di avvio dall’hard disk.

Bene! Spero che questo post possa essere di aiuto a qualcuno. Se ci fosse qualche integrazione utile da fare, basta postare i commenti.
Nel caso poi qualcuno avesse trovato un driver per la PowerStorm, mi farebbe un grandissimo favore passandomi il link :)

note: