Con l’uscita di questo articolo dell’ottimo ossblog, che si merita il premio di blog del giorno, ho trovato finalmente una utility per testare i DNS: namebench presente anche su aur.

Ho constatato, con amara sorpresa, che i fooldns (tralasciando le altre feature) non sono poi così veloci ma almeno ho la soddisfazione di scrivere che gli opends sono quasi allo stesso livello.

Sono rimasto invece basito dalle soluzioni che proposte dopo i benchmark:

Recommended configuration (fastest + nearest):
———————————————-
nameserver 151.99.125.2 # Interbusiness IT
nameserver 212.31.224.3 # COLT IT-2
nameserver 62.196.2.70 # Infracom Network Application IT

********************************************************************************
In this test, Interbusiness IT is 96.5% faster than your current primary DNS server
********************************************************************************

Forse ora è meglio che consideri seriamente di reinstallare privoxy + adblock plus per firefox, cambiare dns abbandonando i fooldns…

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…

Avendo intenzione di fare dei benchmark dopo ogni cambiamento, sulla mia macchina con Arch Linux, ho deciso di installare Phoronix-test-suite. Usando anche la GUI.

Per ottenere questo bisogna installare php-gtk (il binding php per le librerie gtk) ma questo, al momento attuale, funziona solo con php<5.3.

Installazione del necessario

Ho trovato la soluzione su AUR. Da qui ho prelevato sia php 5.2 che php-gtk. Scompattati e installati con

$ makepkg -scir

Non uso yaourt e non ho intenzione di farlo! Fatto questo non resta che installare phoronix-test-suite

# pacman -S phoronix-test-suite

Configurazione

Qui ho trovato un dilemma. Facendo partire l’applicazione con le configurazioni php per php-gtk bisogna eseguire una roba del genere

$ php -c /etc/php/php-gtk.ini /usr/share/phoronix-test-suite/pts-core/phoronix-test-suite.php gui

Come se non bastasse i vari risultati dei test tentavano di essere salvati su tale directory (ovviamente impossibile: perché il tutto è di proprietà di root). Quindi ho adottato una soluzione drastica

# cd /etc/php
# mv php.ini php.ini_back
# mv php-gtk.ini php.ini

Finalmente così possiamo dare

$ phoronix-test-suite gui

senza colpo ferire.

Conclusioni

I nostri file di configurazioni, i test, risultati dei test verranno salvati in ~./phoronix. La GUI funziona un po’ male; apre molte finestre inutili durante i test che possono essere tranquillamente chiuse alla fine e alcuni test non riesco a installarli (ma provando dalla CLI il risultato è medesimo). Ora mi resta solo da capire come fare i confronti con test fatti su altre macchine…ma per questo c’è tempo!

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:

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.

La mia ragazza ha un pc con dei sensori pazzeschi

k8temp-pci-00c3
Adapter: PCI adapter
Core0 Temp:  +19.0°C
Core0 Temp:  +25.0°C
Core1 Temp:  +24.0°C
Core1 Temp:  +22.0°C

Già: ho disabilitato quelli che fanno arrabbiare ACPI (togliendo del tutto sensors dai DAEMONS in rc.conf). Ma come faccio a mostrare ora la temperatura della CPU su conky? Ma sono giusti quei valori?

Prima risposta: facciamo una media con awk dei Core0 e Core1

sensors|awk ‘/Core0/ {totale+=$3 n++}END {print totale/n}’

e

sensors|awk ‘/Core1/ {totale+=$3 n++}END {print totale/n}’

Seconda risposta: più o meno sì facendo la media. Basta convincersene con i valori di  it87 (prima di togliere sensors dai DAEMONS) e anche grazie ad una visitina al BIOS.

Non chiedetemi perché, quando, come.

Non so infatti il motivo, nemmeno da quando c’è il problema, ma le applicazioni GNOME non rilevavano i CD audio (sound-juicer, rhythmbox, brasero) mentre nessun problema con vlc, k3b, exaile. Gira e remena ho trovato (ma che fatica!).

Avendo XFCE ho dovuto sostituire, in .xinitrc, la seguente riga

exec ck-launch-session xfce4-session

con questa

exec ck-launch-session startxfce4

E ora funziona.

Ultimamente ho più roba sulla lista nera che blue jeans (ah io non porto i blue jeans ne ho solo di neri). Intendo dire che in modprobe.d ho dovuto creare un file blacklist.conf per riuscire a capirmi in futuro. Non usando quindi il punto esclamativo su rc.conf o altri sistemi per evitare il caricamento dei moduli

Ecco il mio /etc/modprobe.d/blacklist.conf

# ipv6 non lo usa ancora nessuno
blacklist ipv6

# questo modulo ho scoperto, grazie a lspci -v, che controlla smbus ma con il kernel 2.6.31 leggo questo messaggio da dmesg:
# ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f]
blacklist i2c-i801

# il kernel cerca un generatore di numeri casuali HW che non trova, non crea problemi ma visualizza solo un messaggio su dmesg fastidioso
# intel_rng: FWH not detected
blacklist intel_rng

# per cups 1.4 bisogna disabilitare questo modulo sennò le stampanti USB non vengono rilevate
# dmesg restituisce un messaggio tipo: usbfs: interface 0 claimed by usblp while ‘usb’ sets config #1
blacklist usblp

Sto sinceramente pensando di ricompilare un kernel per togliere questi moduli e compilare quelli basilari staticamente (così evito anche il ramdisk).

Io non ho avuto problemi perché sensors prende i valori da acpi (atk0110-acpi-0) e quindi non necessito di far partire il demone sensors.

Ma al pc della mia ragazza non comparivano più i valori dando il comando sensors dato che le serve il modulo it87. Per fortuna, prima di andare da lei, avevo visto questo post che è capitato a fagiolo. Così dopo l’aggiornamento, visto che conky non mostrava nulla riguardo temperature e velocità delle ventole, ho aggiunto questo parametro al boot su grub

acpi_enforce_resources=lax

Mi pare di aver capito che sia acpi che alcuni moduli entrino in conflitto se cercano di usare gli stessi sensori contemporaneamente e questa opzione al boot lascia fregarcene di eventuali problemi derivanti. Se un certo modulo ha sempre funzionato non vedo perché farsi pippe mentali.
Occhio perché potrebbe essere potenzialmente dannoso (grazie Bardo).

Un’altra soluzione sarebbe sbattersene a priori di acpi e inserire sulla riga del kernel questa opzione

acpi=off

ovviamente se non avete un portatile o comunque un pc dove ci tenete al risparmio energetico.

Stamattina appena alzato o quasi, sono sveglio dalle 6.30 del mattino, ho realizzato 3 video per sfatare la leggenda metropolitana che afferma la non esistenza di programmi per le distribuzioni GNU/Linux. Questo è il primo video e in risposta c’è il secondo e poi ovviamente il terzo.

Sono tutti visibili in HD, registrati con gtk-recordmydesktop abbassando a 10 i fps (per non fare video troppo pesanti ma non so se ho fatto bene).

Siate impietosi nei commenti.

Quanto scritto in questo post è preso quasi nella sua totalità da questo. Quindi non ringraziate me ma DnaX (fra l’altro ho scoperto essere è un mio collega Ingegnere Informatico) anche perché quanto andrò a scrivere è solo la mia soluzione per il mio hardware e software (Arch Linux, Xfce 4.6, Linux 2.6.30.5) quindi non fatemi domande troppo difficili: non saprò rispondere!

Installazione del necessario
pacman -S irda-utils openobex obexftp
Ma questo è utile solamente se volete fare dei test come scritto nel post di Dnax.

Moduli del kernel
Aggiungere su /etc/rc.conf, nell’array MODULES, ircomm-tty

Usare Ircp-Tray
Ircp-Tray è un’applicazione che starà nel tray pronta a spedire al cellulare i nostri file. Questa applicazione è sviluppata e portata avanti sempre da DnaX ed è presente in AUR grazie al nostro archer psykopear. Per usare Ircp-Tray è necessario legare la porta utilizzata per l’IrDA allo stack del kernel e attivare l’auto-discovering. Quindi in /etc/rc.local inserire irattach /dev/ttyS1 -s & (l’& finale è solo per far eseguire questo comando in background, non fatevi seghe mentali non c’entra direttamente con l’IrDA). Una volta riavviato il portatile potete inviare i file al cellulare. Ircp-Tray dirà

Sembra che non ci sia un dispositivo qui vicino. Continuare?

ma continuate (date Ok): funzionerà lo stesso!

Usare Wammu
Wammu mi permette di scaricare i messaggi, la rubrica e inviare messaggi tramite il cellulare con una bellissima interfaccia grafica (Wammu è l’interfaccia grafica per Gammu). Forse fa anche di più ma devo ancora provare tutte le varie opzioni. L’unica pecca è che, purtroppo, non sono ancora riuscito a impostare Wammu per inviare file al cellulare quindi, finché non mi metto d’impegno e ci capisco qualcosa dell’IrDA su Linux, continuo ad usare Ircp-Tray per questa funzione. Per installare Wammu basta dare

pacman -S wammu

Fatto questo dobbiamo aggiungere il nostro utente al gruppo uucp, questo per me si traduce in

gpasswd -a ugaciaka uucp

Per le impostazioni vi lascio uno screenshot

Conclusioni
Eccoci arrivati alla fine, spero vi sia d’aiuto questo post. Se scopro qualcos’altro modificherò l’articolo o se avete qualche suggerimento non esitate a scrivere un commento