L’editor di default di Debian Lenny è Nano. Io non ho niente contro Nano ma preferisco Vi, quindi, quando il mio server utilizza un editor, ad esempio quando viene richiamato un crontab -e, voglio il mio editor prferito.

Ci sono due strade percorribili, una è la Debian Way l’altra è quella maccheronica. Descriverò quella alla Debian Way e lascio ai commenti l’opportunità di descrivere quella maccheronica!:)

Con il comando update-alternatives –config editor vien fuori:

Ci sono 5 alternative che forniscono `editor'.
Selezione Alternativa
-----------------------------------------------
1 /bin/ed
+ 2 /bin/nano
3 /usr/bin/vim.tiny
4 /usr/bin/vim.basic
* 5 /usr/bin/vim.nox
Premi invio per mantenere il default[*], o inserisci il numero da selezionare:

Facile no? Ovviamente bisogna aver installato l’editor che si vuole impostare come default altrimenti la lista mostrata sarà molto misera.

Adesso chiedo a voi: qual’è il modo maccheronico per cambiare editor?

Di solito viene usato il target LOG per impostare la scrittura dei log su file quando facciamo delle regole con iptables. Ma è comodo avere un file (a volte mastodontico) da anzalizzare? Meglio avere i dati in un database MySQL e lavorarci sopra attraverso tool appositi.

Ci viene in aiuto ULOG, un tool che lavora in userspace e permette   quindi,   tramite un   programma   in   continuo   ascolto,   di   gestire   tali   informazioni nella maniera più disparata.

Procediamo con l’installazione dei pacchetti necessari:

apt-get install ulogd ulogd-mysql

Adesso va creato il database con gli opportuni privilegi. Tralascio questa fase perché è banale, specie con phpMyAdmin.
Le struttura della tabella è scritta nel file /usr/share/doc/ulogd-mysql/mysql.table, quindi lo carichiamo nel database appena creato con:

mysql -u <utente> -p <nome_db> < /usr/share/doc/ulogd-mysql/mysql.table

Procediamo con la configurazione di ULOG editando il file /etc/ulogd.conf.

Nella sezione plugins va decommentato:

plugin="/usr/lib/ulogd/ulogd_MYSQL.so"

visto che i dati andranno sul un db MySQL.

Impostiamo l’account per l’accesso al database:

[MYSQL]
table="ulog"
pass="<password>"
user="<user>"
db="<database>"
host="localhost"

Bene, riavviamo ULOG:

/etc/init.d/ulogd restart

Proviamo il tutto impostando una regola di iptables con il target ULOG:

iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -o eth0 -j ULOG

In breve: tutto quello che proviene dalla classe lan 192.168.1.0/24 ed esce dall’interfaccia eth0 (verso Internet) e quindi viene nattato, lo registriamo su MySQL. Ovviamente possiamo impostare qualsiasi regola di firewall con target ULOG per testarne il funzionamento.

MySQL ha qualche record in più? Bene, abbiamo finito.

NFS è un servizio di rete che, avvalendosi delle RPC, permette la condivisione di porzioni di filesystem da e verso altre macchine connesse. La configurazione è velocissima, si installano alcuni pacchetti e si procede alla configurazione del file /etc/exports/.

Vediamo come. (continua…)

C’era una volta BIND, purtroppo (lo dico per i suoi innumerevoli bug) c’è ancora ma, configurare il server DNS tramite file di testo, può risultare scomodo e lento, quindi fortunatamente hanno messo al mondo PowerDNS.

Lo uso da tantissimo tempo ma, quando tutta Internet tremava per il bug dei server DNS, sapere che PowerDNS era completamente immune a tale vulnerabilità, ha rafforzato la mia stima verso questo software.

I principali punti di forza di PowerDNS sono:

• Backend per svariati database quali ad esempio MySQL e PostgreSQL
• Facilità di configurazione
• Sicurezza
• Versatilità

Prima di procedere con l’installazione è doveroso illustrare le parti che compongono questo software:

1. pdns-server: il server DNS vero e proprio
2. pdns-backend-*: il backend dove sono memorizzati i dati ad esempio pdns-backend-mysql utilizzerà MySQL per memorizzare i record DNS
3. pdns-recursor: un server necessario se si devono risolvere altri domini Internet oltre a quelli gestiti dal server

Installiamo! (continua…)

Da Wikipedia:

Un rootkit, (in ambiente Unix per “root” access si intende accesso di livello amministrativo, quindi letteralmente si potrebbe intendere equipaggiamento da amministratore) è un programma software creato per avere il controllo completo sul sistema senza bisogno di autorizzazione da parte di utente o amministratore. Recentemente alcuni virus informatici si sono avvantaggiati della possibilità di agire come rootkit (processo, file, chiave di registro, porta di rete) all’interno del sistema operativo.

Per capire se sul nostro server ci sono rootkit è necessario:

• controllare i log di sistema alla ricerca di cose anomale
• monitorare attentamente i processi server quali Apache, SSH etc
• controllare le directory su cui tutti possono scrivere come ad esempio /tmp
• vedere il file history alla ricerca di comandi non nostri
• attraverso tool come ntop vedere se ci sono in esecuzione processi non autorizzati
• con netstat o nmap verificare che non ci siano porte aperte non consentite dalla nostra configurazione
• controllare lo spazio su disco utilizzato

Tutto questi controlli portano via tempo e di certo non è un lavoro facile da fare.

In ambiente Linux esistono due tool particolarmente efficienti che fanno al caso nostro: ChkRootkit e rkhunter.

(continua…)

Un ottimo network traffic monitor per Linux è vnStat che consente di avere le statistiche del traffico delle interfacce presenti sulla nostra linux box.

Su Debian l’installazione è banale:

apt-get install vnstat

Adesso dobbiamo inizializzare il database di vnStat con le interfacce in nostro possesso:

vnstat -u -i <interfaccia>

Il più delle volte le nostre interfacce ethernet sono eth0, eth1 etc etc.

Adesso è il momento del caffè visto che i dati devono confluire in vnStat per visualizzare le prime statistiche. Trascorso un pò (bel pò) di tempo torniamo su Linux e vediamo che dati fornisce il tool appenna installato. (continua…)

Come la pubblicità di Maxbon ci ha insegnato, sappiamo che “two is meglio che one” quindi perché avere una sola scheda ethernet all’interno del nostro server se con due possiamo avere un ottima ridondanza di rete e/o un ottimo bilanciamento del carico? Vediamo di mettere sù un ethernet bonding, un sistema che la ho lo scopo di unire due flussi ethernet al fine di formare un unico canale.

Prima di procedere all’installazione del software necessario, vediamo le modalità operative del channel bonding:

• mode=0 (balance-rr): avviene il round-robin tra le due interfacce. I pacchetti vengono trasmessi attraverso la scheda di rete scarica e se una delle due va ko viene usata solo la scheda di rete funzionanete. Questa  modalità fornisce sia il load balance e sia il fault tolerance e non prevede switch di rete con particolari funzionalità.
• mode=1 (active-backup): una sola schede di rete viene usata se questa si rompe il MAC address viene associato all’altra funzionante (di backup) e quindi il flusso di rete viene garantito. Questa modalità fornisce un sistema di fault tolerance e non è necessario uno switch che abbia funzionalità avanzate.
• mode=2 (balance-xor): il traffico di rete viene inoltrato sulla scheda in base a questa regola di XOR: ((source MAC) XOR (dest MAC)).  Questa modalità garantisce load balance e  fault tolerance e non necessità di particolati switch.
• mode=3 (broadcast): vengono usate entrambe le interfacce per trasmettere e ricevere. Il fault tolerance è garantito senza switch preposti.
• mode=4 (802.3ad): è una modalità si supporto allo standard IEEE 802.3ad Dynamic link aggregation, per questa modalità è necessario uno switch che supporti lo standard 802.3ad.
• mode=5 (balance-tlb): Adaptive Transmit Load Balancing. Il traffico in entrata è ricevuto solo sullo slave attivo, il traffico in uscita viene distribuito a seconda del carico su ogni slave. Non necessità di particolai switch.
• mode=5 (balance-alb): Adaptive Load Balancing. Fornisce bilanciamento del carico sia in ricezione che in trasmissione. Non necessità di switch particolari ma richiede la capacità di cambiare l’indirizzo MAC del dispisitivo di rete senza che questo interrompa il traffico. (continua…)