Server Density: controllate i vostri server

Ci sono molti tools per controllare lo stato dei nostri server: Nagios, Collectd, Octopussy per citarne alcuni. Ma per chi ha poche esigenze come me e/o non ha voglia di sbattersi nel configurare questi programmi ho trovato una soluzione KISS: Server Density.

Quest’ultimo è un servizio gratuito che si appoggia ad un server esterno. Diamo in outsourcing il controllo delle nostre macchine. Abbiamo due opzioni: tenerci il profilo free oppure quello a pagamento che (oltre la ram, cpu e alert relativi) controlla lo stato di MySQL e Apache con altre sfiziose feature. Ma possiamo provare quest’ultima scelta per 30 giorni, ovviamente, in demo.

Tutto il lavoro che dobbiamo fare, in qualsiasi cosa, si risolve in 5 minuti.

Installazione

Ieri mi sono messo a creare un pacchetto per sd-agent (che va installato su ogni server che intendiamo controllare), patchandolo e modificandolo, e stamattina l’ho messo su AUR. Se avete idee da proporre per la modifica sono ben accette.

Configurazione

Do per scontato che siate già registrati e che quindi vi sia arrivata la mail con l’username da voi scelto e la password. Ora ci logghiamo al sito e aggiungiamo un server (ma anche di più) da controllare e prendiamo nota del relativo agent che è la chiave che identifica univocamente il nostro server (infatti il nome del server lo scegliamo come vogliamo).

Sul server ora possiamo modificare

/etc/sd-agent/config.cfg

e cambiare sd_url con il vostro account di Server Density mentre come agent_key mettiamo la chiave che abbiamo trovato prima.

Avvio

Ora possiamo far partire il nostro agent sul server

# /etc/rc.d/sd-agent start

stando attenti che se:

  • sd_url gli facciamo usare il protocollo http dobbiamo ovviamente tenere la porta 80 con protocollo TCP aperta verso l’esterno;
  • sd_url gli facciamo usare il protocollo https dobbiamo ovviamente tenere la porta 443 con protocollo TCP aperta verso l’esterno.

L’ultima scelta è la migliore perché facciamo viaggiare tutto il traffico sotto SSL.

Conclusioni

Ora non vi resta che modificare gli alert (che vi avvisano via mail per esempio se qualcosa non funziona), godervi i grafici creati da Server Density (sul carico del vostro server) e guardare i grafici a riguardo.

Più terminali e più log in ssh

Caso d’uso

Ci logghiamo da remoto al nostro server OpenSSH poi, a un certo punto, mentre stiamo lavorando cade la connessione. Ci dobbiamo riloggare ma un’istanza della connessione rimane comunque aperta (controllate con ps ax). Oltretutto qualsiasi programma che avevamo lanciato dalla vecchia istanza continua a girare senza nessun controllo da parte nostra: lo killiamo o non lo killiamo e aspettiamo? Tipo se stavamo aggiornando con pacman…bella rogna vero?

Altro esempio. Siamo sul nostro terminale remoto e dobbiamo controllare più log in contemporanea ovvero osservarne due sulla stessa istanza di terminale aperta…come si fa?

Soluzione

Per il primo caso ci può affidare a screen. Anche se ci cade la connessione possiamo comunque agganciarci all’istanza di screen che abbiamo perso e ritrovarci il programma che avevamo lanciato continuare nel suo lavoro.

Per il secondo caso ci si può affidare a multitail. Apre più finestre nella stessa finestra di terminale e in ognuna un log scelto da noi. Consiglio: meglio usare multitail nelle tty cioé dando CTRL+ALT+F1, se non si fa così le combinazioni di tasti potrebbero venire intercettate da gnome-terminal, terminal ecc…

ssh: denyhosts

Configuare OpenSSH a prova di bomba

Siamo talmente paranoici che abbiamo fatto, quasi, tutto quanto consigliato qua per rendere il nostro server con OpenSSH a prova di bomba. Per un uso casalingo io non ho impostato però nessun firewall (mi fido delle impostazioni che ho messo sul mio router netgear dg834g) cioè nessuna regola di iptables sul sistema dove è veramente installato OpenSSH server.

Fregare gli attacchi brute-force

L’unica cosa che mi scoccia sono questi essere infimi, e poco pericolosi, chiamati script-kiddies che tentano degli attacchi brute-force sulla porta 22. Non che sia una gran scocciatura ma i file di log, più precisamente i /var/log/auth.log, tendono a riempirsi paurosamente. Ho trovato una soluzione KISS usando un programma, scritto in Python, chiamato denyhosts. Il concetto è semplice: si guarda i file di log e se un determinato IP fallisce la connessione ssh lo blocca ficcandolo in /etc/hosts.deny.

Una precisazione su come funzionano /etc/hosts.allow e /etc/hosts.deny. Questi sono dei file che configurano il TCP Wrapper: una spiegazione esaustiva si trova negli Appunti di Informatica Libera di Daniele Giacomini. Riassumendo: se un IP è regolamentato da una regola in /etc/hosts.allow tutto fila liscio, se invece questo IP non è previsto in /etc/hosts.allow il sistema guarda /etc/hosts.deny. Quindi in /etc/hosts.allow, se vogliamo fare in modo che gli IP della nostra sottorete non vengano bloccati, mettiamo questa riga:

sshd: 192.168.0.0/255.255.255.248

Ovviamente questo è solo un esempio preso dalla mia configurazione. Se non sapete niente di reti e sottoreti non capirete una tega, forse potrebbe venirvi in aiuto il programma ipcalc:

Esempio ipcalc

ma anche Wikipedia…se non basta fatevi un corso universitario di Reti di Calcolatori o leggetevi un libro a riguardo o rompete i coglioni a un SysAdmin (non io: non lo sono!).
In /etc/hosts.deny non mettiamo nulla: se ne occuperà automaticamente denyhosts. Per esempio una riga che aggiunge denyhosts è la seguente (ovviamente l’IP bloccato è di fantasia):

# DenyHosts: Sat Nov 21 13:05:13 2009 | ALL: 123.123.123.123
ALL: 123.123.123.123

Figo no? Ora non ci resta che editare il file di configurazione di denyhosts che si trova, su Arch Linux, in /etc/denyhosts/denyhosts.cfg.

Configurazione di denyhosts.cfg

Prendo paro paro il mio file di configurazione con una spiegazione tutta mia. Le FAQ sul sito e i commenti su denyhosts.cfg sono molto esaustivi ma degli esempi in più non fanno mai male e non vi faranno sicuramente schifo (vero?). Comunque sia sto usando la versione 2.6 di denyhosts.

SECURE_LOG = /var/log/auth.log Ovviamente questo è il file che denyhosts parsa per andare a pescarsi gli IP da bannare.

HOSTS_DENY = /etc/hosts.deny In un sistema Linux è qui che ci sono le regole per il TCP Wrapper degli IP a cui è vietato l’ingresso nel sistema.

PURGE_DENY = 2d Ricordo che stiamo parlando di uso domestico, quindi abbiamo un indirizzo dinamico raggiungibile magari, con l’ausilio di dyndns come ho fatto io, con un URL www. Ma abbiamo sempre un indirizzo dinamico e ad ogni caduta di connessione (grazie Telecom) cambiamo spesso IP. Quindi gli script-kiddies non punteranno sempre a noi pensando che siamo sempre noi cambiando, magari, gli username e password. Insomma non siamo un bersaglio fisso! Quindi è inutile riempire /etc/hosts.deny di IP. Anche perché magari pure gli script-kiddies hanno IP dinamici come tutti i comuni mortali (a parte i compuer zombie ma si spera di no). Quindi è meglio ripulire /etc/hosts.deny abbastanza spesso. 2d infatti sta per 2 day: due giorni.

BLOCK_SERVICE = ALL Ok, abbiamo solo sshd attivo come servizio. Sarebbe più logico mettere BLOCK_SERVICE = sshd. De gustibus. Questo cambia ovviamente le occorrenze di /etc/hosts.deny che dal mio esempio precedente diventerebbero

# DenyHosts: Sat Nov 21 13:05:13 2009 | sshd: 123.123.123.123
sshd: 123.123.123.123

Denyhosts è molto configurabile, può controllare o tutti i servizi o solo quello che vogliamo noi.

DENY_THRESHOLD_INVALID = 2 Ogni due tentativi da parte di un username invalido (che non esiste sul sistema o che non è specificato in AllowUsers o AllowGroups in /etc/ssh/sshd_config) l’IP viene bannato. Metti che uno al posto di scrivere cicciobanza scrive cicciobnza…lo banniamo subito? Diamogli una seconda possibilità.

DENY_THRESHOLD_VALID = 3 Diamo invece tre tentativi a un user valido nel sistema, magari ha la giornata storta e sbaglia la password (che comunque, siamo stati bravi, è un’autenticazione chiave pubblica/privata).

DENY_THRESHOLD_ROOT = 1 Diciamo che se uno tenta subito root lo banniamo immediatamente..vero?

DENY_THRESHOLD_RESTRICTED = 1 Questa è una sboronata. Possiamo specificare degli username (in /var/lib/denyhosts/restricted-usernames) a cui possiamo dare tot tentativi. Io ho messo 1 perché ci metto i classici: mysql, test, user…i soliti username che non andrebbero mai usati…

WORK_DIR = /var/lib/denyhosts Si commenta da sola, io la lascio così di default e consiglio di fare altrettanto!

SUSPICIOUS_LOGIN_REPORT_ALLOWED_HOSTS=YES A dire la verità non ho ben capito. Sembra che denyhosts si faccia dei sospetti di attacco anche sugli hosts della nostra sottorete e ci avverta di questo. Ho lasciato YES ma approfondirò in seguito…

HOSTNAME_LOOKUP=NO A dire la verità non ho capito molto questo. Non ho capito cosa se ne faccia denyhosts del nome host dell’IP associato che blocca. Approfondirò anche questo…

LOCK_FILE = /var/run/denyhosts.pid Si commenta da solo, lasciamolo così com’è.

ADMIN_EMAIL = Lo lascio vuoto, non ho nessun Postfix o simili installato sul sistema che invii mail di avvertimento quindi…

AGE_RESET_VALID=1m Resetta i tentativi, dopo un minuto di inattività, di un utente valido. Del tipo, scannate password, aspettate un minuto: avete ancora 3 tentativi (riguardate DENY_THRESHOLD_VALID).

AGE_RESET_ROOT= Se uno tenta root non gli diamo altre possibilità.

AGE_RESET_RESTRICTED= Se uno tenta mysql non gli diamo altre possibilità.

AGE_RESET_INVALID= Se uno tenta un utente invalido non gli diamo altre possibilità.

DAEMON_LOG = /var/log/denyhosts Si commenta da solo. Comunque è meglio aggiungere /var/log/denyhosts in /etc/logrotate.d/syslog-ng in modo che logrotate faccia la rotazione anche dei log di denyhosts.

DAEMON_SLEEP = 1m Ogni minuto denhyhosts controlla i file di log. Ci saranno comunque dei tentativi, in un minuto, gli script kiddies provano circa 5-10 username al colpo.

DAEMON_PURGE = 1h Il periodo, quando denyhosts è daemonizzato, con il quale controlla le occorrenze di /etc/hosts.deny e le toglie (in base ovviamente a PURGE_DENY)

Queste sono configurazioni base e utili per un sistema casalingo. Più fico sarebbe sincronizzare /etc/hosts.deny anche con IP bannati da altri che usando denyhosts e che condividono le informazioni (tutto sempre configurando denyhosts.cfg) ma è troppo per noi. Io ho provato ma, come ho già detto, non siamo bersagli fissi.

FoolDNS beta tester

Eh sì, anche io sono un beta tester dei DNS forniti da FoolDNS.

Devo dire che, a livello pratico, ho disattivato l’add-on di firefox adblock plus e che rispetto agli OpenDNS si ha una velocità di query del 40% in più (non ho fatto statistiche evolute, ogni tanto provo manualmente con dig sul terminale).

Dato che FoolDNS blocca le pubblicità (e ci riesce nel 99% dei siti che visito) viene duramente criticato. Ma se io, consapevolmente, non voglio continuamente vedere dei cazzuttissimi banner pubblicitari, che non ho mai clickato in vita mia, cosa tange all’economia globale? Cosa cambia rispetto a prima? Cosa cambia rispetto a quando usavo l’estensione adblock plus?

Allora immagino che a questi personaggi, a cui piace tanto vedersi dei cazzi di banner che ti invitano su qualche sito dato che è il 99999999 accesso effettuato, non gli scazzino nemmeno quelle merdose telefonate di pubblicità che arrivano, dai call-center, sul telefono di casa alle 7 di sera proponendo una vantaggiosa offerta riguardo “qualcosa”. Oppure quelle cazzo di pubblicità in televisione delle cartomanti sulle reti private o quelle dei pannolini pieni di pupù trasmesse durante il pranzo.

PS riguardo alle telefonate rompi-cazzo-della-sera, se voglio cambiare gestore telefonico lo decido quando voglio io. Se il gestore dell’enel vuole cambiarmi un tariffario e farmi quello più conveniente per me la cosa puzza, cosa gli viene in tasca all’enel che la mia bolletta sia più leggera se sono già cliente della loro azienda?

certificati (SSL) mancanti

Non so come mai ma la cartella

/etc/ssl/certs/

risultava vuota. Ergo qualsiasi sito con una catena di certificati valida non risultava valido! Ohibò…ho reinstallato ca-certificates (il pacchetto che si occupa di validare i certificati) e ha ricreato i link simbolici su tale cartella e facendo un suo update…ora è tutto risolto! Finalmente posso navigare senza che konqueror rompa sui certificati, risolsi l’arcano mistero (ma non da dove venissie)

sudo pacman -S ca-certificates

[…omissis…]
Clearing symlinks in /etc/ssl/certs…done.
Updating certificates in /etc/ssl/certs….done.
Running hooks in /etc/ca-certificates/update.d….done.

PS so che sul planet si legge ugaciaka:ugaciaka invece del nome del post ma non so come risolvere…se qualcuno ha qualche idea…

Cerco un’unità NAS domestica

Sto cercando disperatamente un’unità NAS, qualcuno sa consigliarmi?

Vi dirò alcune caratteristiche:

- che sia di una marca notoriamente specializzata in questo ramo (tipo l’asus per me MoBo), pensavo alla Western Digital

- io ho un router wifi e vorrei che il NAS si attaccasse all’ethernet del router mentre accedo al NAS tramite il router dal pc di casa (mi sembra ovvio che debba funzionare ma non ne sono sicuro),

- che possa contenere due dischi (non ci sono limiti per dimensioni in GiB vero? perché vorrei ficcarne due da 750GB…un tera e mezzo per ora forse mi basta)

- che sia silenzioso

- consumi poco

- che magari abbia una distro linux interna da hackerare (che ne so…per installarci bittorrent)

- il nas mi serve per backappare tutti i miei film e ne ho tanti (in DVD dual layer…quindi sui 8GiB ciascuno) , tutta la mia musica (ho intere discofrafie originali)…E non sto scherzando forse quei 1tera e mezzo forse non mi basteranno …

- ultimo ma non meno importante: sono disposto a spendere intorno a 200euro, anche senza HD incorporati (ne ho uno da 250 e uno da 500 della western digital)

Grazie ;-)

EDIT:

o questa unità NAS oppure un pc assemblato. Quest’ultimo del tipo un bel procio che consumi poco, poca ram a pochi ghz, tower piccolo, scheda madre asus; il tutto da controllare tramite SSH e NFS.
Entrambi le soluzioni si aggirano sui 300euro.

RIEDIT: infatti guardate cosa ho trovato per 300 euri

RIRIEDIT: grazie al forum di www.unipd.net mi hanno consigliato questa derivata di freeBSD fatta apposta per installare un SO per un NAS!

Ralink per WL-167G e custom kernel

Come promesso scrivo la guida per installare i driver con *buntu 8.04, compilandoli da sorgenti, per la WL-167G dell’Asus quando si ha un kernel customizzato e vogliamo i driver più aggiornati.

Scarichiamo i sorgenti
Usiamo ovviamente i compat-wireless (contiene anche molti altri driver oltre ai nostri)

wget http://linuxwireless.org/download/compat-wireless-2.6/compat-wireless-2.6.tar.bz2

Il firmware
Per far funzionare i driver serve il firmware, purtroppo no opensource, scarichiamolo con

wget http://www.ralinktech.com.tw/data/RT71W_Firmware_V1.8.zip

Sì, casomai ci facciate caso anche per la intel 3945 serve il firmware…

Scompattiamo la cartella

gunzip RT71W_Firmware_V1.8.zip

entriamo nella cartella scompattata

cd RT71W_Firmware_V1.8/

e spostiamo il firmware nella cartella /lib/firmware

sudo mv rt73.bin /lib/firmware/

Rimuoviamo i componenti non necessari
Per essere sicuri che finisca tutto liscio prima di compilare ed installare i driver da sorgenti scarichiamo dal kernel quelli di ubuntu

sudo rmmod rt73

Compiliamo ed installiamo
Scompattiamo ed entriamo nella cartella

tar xjvf compat-wireless-2.6.tar.bz2
cd compat-wireless-2.6

compiliamo

make
sudo make install

ed installiamo

sudo make unload
sudo make load

Ora il gioco è fatto

ugaciaka@eclipse:~$ modinfo rt73usb | grep version
version: 2.1.7
srcversion: DA51F4772B0889CE02618DC

Conclusioni
Ovviamente questa guida è stata adattata per un kernel customizzato che non vede il firmware già presente nella cartella del kernel patchato di ubuntu. Infatti la stessa guida può essere seguita per un kernel generic che non ha bisogno di “vedere” il firmware essendo già messo in

/lib/firmware/”kernel generico”

Il tutto è spiegato

qua

per i compat wireless in generale