



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 Micro$oft propone utility veramente utili! ![]()
E’ 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
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!


More Options ...
Categorie
Tag Cloud
Blog RSS
Comments RSS

Void « Default
Life
Earth
Wind
Water
Fire
Light 