Marco's Informatik Blog

Sono qui a segnalarvi la lodevole attività svolta da Guru@Work, un’associazione culturale no profit di Grosseto che promuove l’uso di software libero e Open Source, sia nella PA che per uso domestico.
Hanno siglato una convenzione con Unicoop Tirreno per collaborare nell’organizzazione di eventi su tema del software libero.
Il primo evento di questa serie è un corso introduttivo, ovviamente gratuito, per apprendere le basi di GNU/Linux, OpenOffice.org e la sicurezza informatica.
Io abito a Siena ed ho appreso la notizia su di un quotidiano locale, quindi finalmente queste cose hanno una eco anche al di fuori dei soliti canali per geek.
Guardando i componenti, o gurus, come si presentano nel sito ho visto che c’è pure un mio ex compagno di università, con cui sviluppammo assieme ad un altro ragazzo, un simpaticissimo campo minato in Java, che ci valse un bel 30 ad Informatica II

Piccolo post autocelebrativo, dato che non li faccio mai!
Dopo circa un anno e mezzo dall’apertura di questo mio blog, le visite hanno passato di molto le 250.000 unità, ma apparte questo a darmi soddisfazione sono le email, di consulenze ma anche di semplice chiaccherate che mi mandate (si sa, i complimenti fanno sempre piacere!!).
Ho cominciato a scrivere soprattutto per mio uso e consumo, come block notes per memoria futura su tutti gli argomenti che affronto al lavoro, e poi questo è stato condiviso ad un vasto pubblico.
Principalmente mi trovo sempre a parlare di Asterisk, Trixbox, VoIP in genere, ma anche Linux, sicurezza, firewall…
Tra l’altro ho di recente scoperto (entrando per la prima volta nel mondo BSD) pfSense, a mio parere un appliance che se la combatte bene anche con prodotti commerciali più blasonati.
Poi per diletto ho aperto un sito, Il Mio VoIP, dove vorrei dare dei servizi, tutti a scopo non commerciale e puramente divulgativo, come Click to Dial dal web, server STUN di test e così via, anche se ahimè non ho molto tempo per svilupparlo attivamente (magari datemi una mano!!)
Bhe che dire, grazie a chi mi conosce e chi mi conoscerà su queste pagine!
Ah, e grazie al mio Amore Anna, che delle sere mi vede sempre chino sul notebook (e sul divano!) intento a scrivere di strane cose dai nomi esotici

Forse molti di voi già lo conoscono, mentre chi no deve sapere che delle volte la Microsoft propone utility veramente utili!
Ed è il caso di questo Robocopy, un’evoluzione del classico XCOPY che presenta una miriade di opzioni, per copiare (ma non solo) files da un server all’altro (o tra dischi).
Diciamo l’uso più comune è mantenere copia di un archivio su un altro server (perchè no un NAS, magari volendo conservare gli attributi di sicurezza), oppure creando una copia specchio (mirroring), tutto questo magari in maniera automatica utilizzando le “operazioni pianificate”.
Vediamo due esempi, la semplice copia e il mirroring (occhio che questa seconda maniera può essere pericolosa, nel senso che se un file viene cancellato accidentalmente nel sorgente, sarà cancellato anche nell’archivio di backup alla successiva esecuzione dello script, proprio perchè trattasi di mirroring!!)

Copia semplice di tutti attributi, creazione di file di log e mantenimento informazioni dei file

robocopy “\\srv1\SOURCE” “F:\DEST” /COPYALL /SEC /V /NP /E /W:5 /R:1 /LOG:”c:\robocopy.log”

Mirroring delle cartelle con mantenimento informazioni di sicurezza

robocopy “\\srv1\SOURCE” “F:\DEST” /MIR /SEC /V /NP /W:5 /R:1 /LOG:”c:\robocopy.log”

Io sconsiglio di mettere cadenzato il /MIR, per evitare perdite accidentali di dati nell’archivio di “sicurezza”, causato da errori umani, magari lo potete lanciare di tanto in tanto per ripulire l’archivio e manterlo coerente con quello sorgente, con una sorta di purge.
Per una descrizione su tutti i comandi potete fare riferimento a questo link.

Ciao, eccomi quà dopo qualche giorno di assenza!
Anche nel nostro “amato” Trixbox può essere necessario ricompilare Asterisk, anche per rendere più stabile il demone stesso, inoltre perchè no, per renderlo più performante.
Sicuramente di più che nella classica compilazione del pacchetto rpm, per i386.
Per farlo però sono necessari alcuni piccoli e semplici accorgimenti.
Innanzittutto scaricate e scompattate il sorgente in /usr/src e dovrete avere gli headers del kernel, utili anche nel caso doveste compilare anche mISDN.
Per scaricare gli headers basterà

yum -y install kernel-devel
o yum -y install kernel-smp-devel
se avete un processore SMP o più di un processore

A questo punto dovete editare il file Makefile e trovare la riga

ASTVARRUNDIR=$(INSTALL_PREFIX)/var/run
che va modificata in
ASTVARRUNDIR=$(INSTALL_PREFIX)/var/run/asterisk

Fatto ciò fate make, poi vi consiglio di spostare in una directory a parte il contenuto della dir /usr/lib/asterisk/modules che contiene il moduli precompilati orginali.
Infatti dando make install senza togliere i moduli presenti, riceverete uno warning che vi avviserà di qualche, eventuale e non sicuro, malfunzionamento.
Per sicurezza cancellate tutti i moduli standard, lasciando all’installer script di ricopiarci i nuovi.
Se Asterisk (che avrete fermato con amportal stop prima del make install) una volta riavviato non dovesse appunto “partire”, controllate nel file /var/log/asterisk/full l’eventuale modulo mancante o non funzionante.
Alla fine però avrete un sistema più sicuro e performante sul vostro Trixbox.

Una delle funzioni più utili in un centralino è sicuramente quella del call pickup, ovvero “prendere” una chiamata diretta verso altre estenzioni.
Ma non voglio parlare delle funzione in se, per la quale vi rimando qui, ma su come implementare questa funzione con i tasti BLF dei telefoni Thomson ST2030 e Snom 3X0.
Innanzittutto aggiornate entrambi i telefoni alle ultime versioni del firmware, la 1.52.1 per lo ST2030 e la 6.5.2 per i vari Snom 300, 320 e 360.
Per monitorare le linee tramite i BLF dovrete configurare come Supervised Line i tasti nel Thomson e come Extension sugli Snom.
In questo modo vedrete i led lampeggiare quando le linee ricevono una telefonata e fissi se sono occupati.
Ma mentre lampeggiano, se cliccate sul tasto non succederà niente, anzi magari partirà un altra chiamata verso quella estenzione.
A questo punto in features.conf dovrete scrivere pickupexten => *8 nel contesto general e poi in extensions_custom.conf create questo contesto

[app-pickup-custom]
exten => _*8.,1,Noop(Attempt to Pickup ${EXTEN:2} by ${CALLERID(num)})
exten => _*8.,n,Pickup(${EXTEN:2})

A patto di avere

[app-pickup]
include => app-pickup-custom
exten => _**.,1,Noop(Attempt to Pickup ${EXTEN:2} by ${CALLERID(num)})
exten => _**.,n,Pickup(${EXTEN:2})

in extensions_additional.conf (lo è di default, quindi nessun problema! Le ultime due righe sono utili per il GXP 2000 della Grandstream).
Per sicurezza dalla console eseguite show features e dovrete avere una riga così

Builtin Feature Default Current
————— ——- ——-
Pickup *8 *8

Adesso effettuate il reload di features e di estensions.
A questo punto provate a fare una chiamata verso un estensione, e quando squillerà da un altro telefono chiamate il *8xxx dove xxx è il numero dell’estensione.
Se tutto è ok, dovreste essere in grado di prendere la chiamata.
Bene, siamo a metà strada!
Adesso sarà necessaria una modifica ad asterisk, ma niente paura, sostituiremo per comodità solo un file.
Prima di tutto aggiornare Trixbox, ed al momento in cui scrivo avrete Asterisk alla versione 1.2.14.
Una volta fatto ciò scaricate il sorgente di Asterisk e limitatevi alla scompattazione, poi nella stessa directory del sorgente, scompattate questo file.
Fatto ciò, eseguite questo comando patch -p0 < patch_chan_sip_pickup che andrà a modificare il file chan_sip.c e poi compilate Asterisk normalmente. (potreste anche compilare solo tale file, ma non complichiamoci la vita!)
NON LANCIATE make install ma copiamo il file chan_sip.so dalla directory channels in /usr/lib/asterisk/modules, ovviamente prima stoppate Asterisk.
Riavviate tutto con amportal start ed adesso proviamolo!
Facendo come prima, adesso quando vediamo lampeggiare l’estensione chiamata, premendo il tasto BLF dovremmo “prendere” la telefonata.
Testato con entrambi i modelli, funziona perfettamente!
Ringrazio vocesuip.com per le dritte

Uno dei principali usi del nostro amato GNU/Linux è sicuramente quello del firewall.
Potente, economico, versatile e facile da configurare…bhe non sempre!!!
Rispetto ad ipchains, il vecchio firewall che stava nei kenrnel 2.0, Iptables/Netfilter ha reso la sintassi meno contorta, ma per creare regole elaborate può essere sempre una pratica ostica.
Inoltre le appliances firewall commerciali più conosciute, permettono di considerare il traffico entrante ed uscente non in schede di rete, ma in visione più ampia, in zone.
Ogni zona può “gestire” anche più schede di rete, e le interazioni tra zone saranno governate da policy di default che potranno essere “superate” da regole specifiche, ma andiamo con calma!!
Il files fondamentali che troverete in /etc/shorewall sono i seguenti

• zones
• interfaces
• policy
• rules

Ovviamente i nomi sono esplicativi, definizione delle zone, delle interfacce per ogni zona, delle policy di default tra zone e le specifiche regole.
Adesso vi riporterò una configurazione tipica con due schede di rete, con regole che bloccano il traffico di ingresso se non verso determinati ip, blocco totale del traffico in uscita (nattato) escluso determinate porte ed inoltre dei redirect per l’interazione con Dansguardian/Squid e p3scan, ovviamente il nome delle zone sono indicativi

/etc/shorewall/zones

#ZONE   TYPE            OPTIONS         IN                      OUT
#                                       OPTIONS                 OPTIONS
fw      firewall
verde   ipv4
rossa   ipv4
#LAST LINE – ADD YOUR ENTRIES ABOVE THIS ONE – DO NOT REMOVE

/etc/shorewall/interfaces

#ZONE   INTERFACE       BROADCAST       OPTIONS
verde   eth0
rossa   eth1    -       routeback
#LAST LINE — ADD YOUR ENTRIES BEFORE THIS ONE — DO NOT REMOVE

/etc/shorewall/policy

#SOURCE         DEST            POLICY          LOG             LIMIT:BURST
#                                               LEVEL
rossa   fw      DROP
rossa   verde   DROP
verde   fw      ACCEPT
verde   rossa   DROP
fw      verde   ACCEPT
fw      rossa   ACCEPT
#LAST LINE — DO NOT REMOVE

/etc/shorewall/rules

#ACTION SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE            USER/
#                                               PORT(S) PORT(S)         DEST            LIMIT           GROUP
#SECTION ESTABLISHED
#SECTION RELATED
SECTION NEW
LOG:info        verde   fw      tcp     22
LOG:info        verde   fw      tcp     10000
ACCEPT  rossa:XX.XX.XX.XX   $FW     tcp     22
ACCEPT  rossa:XX.XX.XX.XX   $FW     tcp     10000
DNAT    rossa:XX.XX.XX.XX     verde:192.168.0.113     tcp     3389
REDIRECT        verde   8110    tcp     110
REDIRECT        verde   8080    tcp     80
ACCEPT  verde   rossa   tcp     13,17,21,22,23,25,43,53,80,81,110,113,119,143,443
ACCEPT  verde   rossa   tcp     465,993,995,1352,1755,1863,2003,2345,3389,4711
ACCEPT  verde   rossa   tcp     2082,2401,4800,4899,5190,5900,7070,8080,8081,8443,8827,8775,10000
ACCEPT  verde   rossa   tcp     50022,50080
ACCEPT  verde   rossa   tcp     6665:6669
ACCEPT  verde   rossa   tcp     1001:1010
ACCEPT  verde   rossa   tcp     65120:65122
ACCEPT  verde   rossa   tcp     60000:60010
ACCEPT  verde   rossa   tcp     31443
ACCEPT  verde   rossa   udp     37,53,123,3052,4569

Due breve righe su casi particolari (messi per esempio)
ACCEPT  rossa:XX.XX.XX.XX   $FW     tcp     22 (accetta collegamenti ssh da un determinato ip)
ACCEPT  rossa:XX.XX.XX.XX   $FW     tcp     10000 (accetta collegamenti sulla porta webmin)
DNAT    rossa:XX.XX.XX.XX     verde:192.168.0.113     tcp     3389 (port forwarding su un server windows 2003 interno. sempre solo da un determinato ip esterno)
REDIRECT        verde   8110    tcp     110 (per il check del traffico da parte di p3scan)
REDIRECT        verde   8080    tcp     80 (per il controllo dei contenuti da parte di Dansguardian)
Questa serie di regole dovrebbero permettervi una navigazione tranquilla degli utenti, ma anche una certa sicurezza (ad esempio impedire il peer to peer)
Maggiori info sulla sintassi le trovate nella documentazione ufficiale.
Inoltre le distro più adatte per questo uso, IMHO sono Debian e Trustix.
A presto con nuovi articoli sul tema!
Ah dimenticavo, un ottimo frontend per Shorewall è l’onnipresente Webmin!

Problema tipi di tutte le installazioni Asterisk è quello dell’eco che sentiamo nelle telefonate che entrano (o escono) dal nostro pbx passando da linee analogiche o digitali (PRI/BRI).
Questò perchè? Per tantissimi motivi, latenza, impendenza, qualità della linea, delle periferiche, distanza dalle centrali etc..etc..
Però è possibile alleviare questi problemi tramite semplici settaggi, molto empirici, che dopo un pò di prove e smanettamento, dovrebbero dare alcuni risultati positivi.
Prima di tutto in zapata.conf ci devono essere questi settaggi

echocancel=128
echocancelwhenbridged=yes
echotraining=800

Per il significato particolare di queste voci vi basti cercare su Google il termine zapata.conf
Ma questo può non bastare, infatti altri due parametri fondamentali sono txgain e rxgain.
Per controllare come aggiustare il guadagno, dovrete utilizzare lo strumento ztmonitor fornito con i sorgenti di Zaptel.
Aprite due console (o terminali ssh), fate una telefonata ed eseguite in una delle due console questo comando 

./ztmonitor NUMERO CANALE -v

Ed avrete una cosa simile 

Visual Audio Levels.
——————–
Use zapata.conf file to adjust the gains if needed.( # = Audio Level * = Max Audio Hit )
<-------------(RX)-------------> <-------------(TX)------------->
######*                                   ############## *

Questo indica i livelli di volume di RX e TX, mentre il primo è regolare, il secondo è troppo alto, quindi txgain và necessariamente abbassato.
Di solito questi valori devono essere compresi tra -11 e +11 (il valore minimo e massimo sono -100 e 100).
Dall’altra console eseguirete reload chan_zap.so in modo da regolare i volumi “on-the-fly”.
Quando avrete raggiunto un livello ottimale, per sicurezza, potete riavviare il vostro centralino.
Con un pò di fortuna, dopo varie prove, non dovreste più sentire quel fastidioso eco.

Ciao a tutti, oggi sono in ferie ma dato che volevo controllare una cosa su un server di un nostro cliente, stavo pensando a come poter fare a collegarmici, dato che l’accesso via Terminal Server è possibile solo uscendo dalla nostra adsl con ip fisso, per ovvie ragioni di sicurezza.
Quindi mi è venuto in mente di fare una bounce connection con netcat!
Non starò qui a tediarvi sulle caratteristiche di nc, vi rimando al sito http://netcat.sourceforge.net/…
La logica è questa

CASA MIA—>1234 tcp port—>MIO FIREWALL LAVORO—>3389/tcp—>SERVER CLIENTE

In questo modo il server del cliente vede come ip sorgente quello del nostro firewall permettendo la connessione, mentre io sono comodamente seduto in casa
Per fare in modo che netcat rimanga in ascolto su una porta tcp/ip basta usare inetd o xinted, io userò quest’ultimo.
Per prima cosa create una nuova riga su /etc/services, una cosa del tipo

bounce          9833/tcp

poi andate su /etc/xinetd.d/ e create un file di nome bounce con dentro questo testo

service bounce
{
        flags           = REUSE
        disable         = yes
        socket_type     = stream
        protocol        = tcp
        user            = nobody
        wait            = no
        server          = /usr/bin/nc
        server_args     = -w 2 x.x.x.x 3389
}

poi un bel /etc/init.d/xinetd start (o restart se lo avete già in esecuzione!)
In questo modo tutte le connessioni sono ridirezionate e posso lavorare!!
PS.
Come in una ricetta potete aggiungere a piacere elementi di sicurezza, dall’uso di regole sul firewall che limitano l’accesso alla porta, o all’uso del netcat in combinazione con una vpn, ad esempio OpenVPN!