I provider, da un po’ di tempo, offrono connessioni in fibra ottica. In questa pagina cerco di descrivere brevemente come funziona e come configurare il router (o un semplice PC).

La connessione in fibra è costituita da un fascio luminoso che viene trasmesso dentro un cavo. Alla centrale del provider c’è un apparato «server» chiamato OLT che comunica con parecchi apparati «client» chiamati ONT. Il fascio di luce parte dall’OLT e attraversa una serie di splitter per arrivare a tutti gli ONT ad esso collegati. Si tratta di una specie di «broadcasting» nel quale l’OLT non può comunicare con un solo client, ma manda tutto a tutti. Nella direzione contraria, i vari ONT si mettono d’accordo e usano il fascio di luce in «timesharing» vale a dire uno alla volta, secondo una divisione temporale statica. In pratica, se l’OLT è connesso a 100 ONT, allora ogni ONT ha 1/100 della banda.

La velocità di upload è quindi statica: 1/100 della banda riservato ad ogni ONT permette di avere una velocità costante. Invece la velocità in download è variabile: se ad esempio, due persone collegate a due diversi ONT richiedono due pagine web in contemporanea, poiché l’OLT trasmette tutto a tutti, le pagine verranno trasmesse dall’OLT una alla volta: la prima pagina avrà come destinatario l’ONT della prima persona, ma il fascio di luce arriverà anche alla seconda, che dovrà ignorarlo, mentre la seconda pagina avrà come destinatario il secondo ONT ma andrà anche al primo, che dovrà ignorarlo. In questo senso, se a scaricare dati da Internet sono in pochi, allora la velocità sarà maggiore, mentre se sono in tanti, la veclocità sarà minore.

Oltre al traffico Internet, nelle connessioni in fibra ci sono il traffico televisivo e quello voce della fonia. Il primo e il terzo sono bidirezionali, il secondo funziona solo nella direzione dall’OLT all’ONT.

In casa, quando viene tirato il cavo della fibra, vengono messi una borchia e poi l’ONT. Il primo è una scatoletta non alimentata dalla corrente, il secondo richiede invece l’alimentazione e ha anche una porta RJ45 per la connessione Ethernet.

Questi terminali ONT sono in genere dei piccoli apparati con Linux o altri semplice sistemi embedded. Spesso hanno un indirizzo IP fisso sulla porta RJ45 e rispondono al telnet oppure via HTTP. A volte, ci si può collegare a rilevare i dati sulla qualità del segnale ottico.

All’ONT, dicono i vari provider, va collegato un router, di quelli da comprare in negozio, specifico per le connessioni in fibra. Ma vediamo a cosa serve esattamente il router.

Il router va collegato all’ONT con un cavo ethernet e ha di norma anche una serie di porte RJ45 per potervi collegare i computer, oppure le antenne per la connessione Wi-Fi. Se + un computer per la fibra allora ha anche una o due porte per i telefoni PSTN, cioè quelli normali, non quelli VoIP. Non ci sono attacchi speciali per la televisione.

Il router va configurato in modo che si colleghi al provider attraverso l’ONT. Di norma la connessione avviene con il protocollo PPPoE, cioè la classica connessione PPP che anziché usare un segnale seriale (tipico dei tempi del modem PSTN o anche delle linee ADSL), utilizza una connessione a pacchetti ethernet. La connessione richiedere quindi di inserire delle credebziali (login e password) e di norma anche un codice VLAN. Il codice VLAN si usa per fare passare via ethernet varie informazioni, nel nostro caso voce, tv e Internet, semplificandone la separazione. Il router deve accedere ad Internet, quindi deve usare la VLAN di Internet, altrimenti l’ONT lo ignorerà. TIM usa la VLAN 835, altri provider usano altre VLAN per Internet.

Le credenziali permettono al provider di riconoscere chi si collega e applicare le varie configurazioni. Ad esempio, TIM mette sulla sua pagina web le informazioni per la configurazione standard, che offre la connessione con IP dinamico, ma si possono richiedere le credenziali corrette, ad esempio, per avere l’IP statico legato al proprio contratto.

Il router, se ha la porta RJ41 per il telefono, dovrà essere configurato per il VoIP. I parametri sono forniti dal provider e, sostanzialmente, permettono al router di collegarsi, tramite una diversa VLAN, al provider e ottenere la linea telefonica VoIP. Il VoIP, su linea in fibra, ha la priorità sul traffico Internet e quindi funziona bene. Personalmente ho collegato un FAX PSTN alla porta RJ41 del router e ha funzionato bene anche con trasmissioni alla massima velocità.

Il router, per permette alla televisione di ricevere le trasmissioni, fa da proxy IGMP. Quando si accende la TV, collegata alla rete LAN del router, questa cerca un proxy IGMP e si registra tra quelli interessati a ricevere le trasmissioni. Le tramissioni sono inviate dall’OLT a tutti gli ONT secondo la modalità «multicast», il router le riceve e le inotra a quei dispositivi che ne hanno fatto richiesta.

Se si prende un computer qualsiasi e vi si installa GNU/Linux, è facile poi configurarlo come router. Si dovrebbe avere un computer con due schede di rete moderne, che vadano alla velocità della connessione in fibra, quindi in genere gigabit. Ad un interfaccia di rete si attacca il cavo che lo collega all’ONT, all’altra interfaccia si collega lo switch.

Sul computer vanno installati i pacchetti per la connessione pppoe e per il proxy igmp. La parte delle VLAN si configura con il pacchetto iproute2, che normalmente è già installato.

La configurazione può essere fatta a mano, oppure si possono utilizzare progetti come il debian-v9-router che si trova qui.

Affrontare lo SPAM è una guerra continua, con regole e situazioni che cambiano di frequente. Riporto qui di seguito alcune considerazioni legate alla configurazione di exim4, in particolare su Debian.

Non elencherò qui le soluzioni più diffuse, come utilizzare spamassassin per la verifica della posta in ingresso, oppure utilizzare le varie blacklist per negare l’accesso a server poco accreditati. Invece, scriverò solo metodi aggiuntivi, per rafforzare ulteriormente il server.

Nome account diverso dal nome della casella di posta elettronica

Molto spesso, chi raccoglie indirizzi di posta elettronica tramite ricerceh su web o tramite la lettura delle rubriche private, tenta poi l’accesso al server di posta utilizzando come nome utente l’indirizzo di posta, con o senza il dominio.

Per esempio, se sulla macchina «macchina.tld» esiste un utente Francesco Rossi con una utenza «francesco», molto probabilmente esistena la casella di posta «francesco@macchina.tld». Se si fa un server di posta, dedicato alla parte SMTP e/o IMAP, vanno definite le utenze e le caselle di posta. Il suggerimento è di usare utenze diverse dalle caselle di posta. Ad esempio, si può dare a Francesco l’utenza «kl2482gg@macchina.tld» che corrisponda alla casella di posta «francesco@macchina.tld».

In questo modo, chi conoscerà la casella di posta «francesco@macchina.tld» tenterà di accedere usando l’utenza «francesco» oppure «francesco@macchina.tld», che non esistono.

Geolocalizzazione

Altra cosa importante è che le credenziali vengono comunque rubate, in un modo o nell’altro, magari tramite virus. Una volta che queste sono in mano agli spammer, verranno effettuate migliaia di connessioni correttamente autenticate verso il server SMTP, che accetterà i messaggi SPAM e cercherà di inviarli.

Una via per limitare questo attacco, è quella di bloccare email inviate da IP stranieri. Per farlo conviene mettere un log per tracciare le nazioni dalle quali si riceve la posta autenticata e capire quali siano le nazioni valide. Su Debian c’è un pacchetto chiamato «geoip-database» che contiene l’elenco degli IP con l’indicazione della nazione di appartenenza. Per exim esiste una libreria dinamica (disponibile qui) che permette di interrogare quel database. Una volta compilata e installata seguendo le istruzioni sul sito della libreria, si devono aggiungere alcuni file di configurazione a exim. Il primo crea una variabile con la nazione dell’IP, chiamiamolo «/etc/exim4/conf.d/acl/exim4-config_check_geoip_parte1»:

#imposta la variabile acl_c_geoip_country_code
warn set acl_c_geoip_country_code = \
${dlfunc{/usr/local/lib/exim4/exim-geoipv6-dlfunc.so}\
{geoip_country_code}{$sender_host_address}}

Il secondo usa la variabile per bloccare l’accesso, chiamiamolo «/etc/exim4/conf.d/acl/exim4-config_check_geoip_parte2»:

#
# Controllo dell'IP origine della connessione.
# Utilizza una libreria e il database degli IP
# la libreria è https://github.com/snabb/exim-geoipv6-dlfunc
# il database e' nel pacchetto geoip-database
#

# nella fase di test, aggiungo una intestazione per controllare la
# variabile
#warn
# condition = ${if def:acl_c_geoip_country_code}
# authenticated = *
# log_message = Accesso autenticato dalla nazione $acl_c_geoip_country_code

# nella fase di test, aggiungo una intestazione per controllare
# l'indirizzo se non è nel database
warn
!condition = ${if def:acl_c_geoip_country_code}
authenticated = *
!hosts = 10.0.0.0/24
log_message = Accesso autenticato da un IP sconosciuto e non della LAN

# accetta email che arrivano da IP della LAN a condizione che
# sia stata fatta l'autenticazione
accept
authenticated = *
hosts = 10.0.0.0/24
log_message = Accesso autenticato da computer in LAN

# accetta email che arrivano da IP di nazioni conosciute, ma mancanti dal database,
# a condizione che sia stata fatta l'autenticazione
accept
authenticated = *
# 88.209.103.0 - 88.209.103.255, Monaco-Telecom, MC
hosts = 88.209.103.0/24
log_message = Accesso autenticato da computer in LAN
# accetta email che arrivano da IP in Francia e Monaco a condizione
# che sia stata fatta l'autenticazione
accept
authenticated = *
condition = ${if def:acl_c_geoip_country_code}
condition = ${if inlist{$acl_c_geoip_country_code}{FR:IT:MC}}
log_message = Accesso autenticato da IP della nazione $acl_c_geoip_country_code

# blocca i messaggi per i quali è stata fatta l'autenticazione SMTP,
# cioè si conosce la password, ma vengono da una naziona conosciuta
# e straniera
# nota: in alcuni casi, acl_c_geoip_country_code non viene inizializzata
# perché l'IP non è nel database. In quel caso, non si entra in questa
# regola
deny
authenticated = *
condition = ${if def:acl_c_geoip_country_code}
!condition = ${if inlist{$acl_c_geoip_country_code}{FR:IT:MC}}
message = Authenticated access from foreign country denied.
log_message = Accesso autenticato da nazione non autorizzata. Rifiutato.


Infine, per fare usare questi due file ad exim, è necessario modificare il file con le opzioni locali, come ad esempio, «/etc/exim4/conf.d/main/000_local_options» aggiungendovi quest righe:

# controllo accessi tramite verifica geografica
CHECK_RCPT_LOCAL_ACL_FILE = /etc/exim4/conf.d/acl/exim4-config_check_geoip_parte1
CHECK_DATA_LOCAL_ACL_FILE = /etc/exim4/conf.d/acl/exim4-config_check_geoip_parte2

Con la geolocalizzazione si bloccano le richieste dall’estero, ma questo potrebbe essere un problema se uno si spostasse all’estero, magari in vacanza. Va quindi usata con attenzione.

Una seconda possibilità, più onerosa dal punto di vista computazionale, è quella di fare il controllo antispam, con spamassassin o altro, anche ai messaggi che arrivano da connessioni autenticate.

Quando si installa il pacchetto slapd, si configura una directory, generalmente chiamata dc=nodomain. Da quel punto in poi, tutta la modifica alla configurazione può essere fatta con un client LDAP, oppure si può operare direttamente con i file. Vediamo questa seconda via.

La prima cosa da considerare è che una directory LDAP viene memorizzata in una directory del file system tramite vari file che contengono dati e indici. Il sistema più vecchio di memorizzazione è quello chiamato bdb (Oracle Berkeley DB), ma ne esistono anche altri quali hdb (hierarchical Berkeley DB), mdb (Memory-Mapped DB) e sql. Ce ne sono anche altri, ma non sono generici. Scartiamo l’ultimo della lista, sql, poiché si tratta di uno strumento che permette solo di leggere dati, senza poterli modificare. Scartiamo anche il primo e il secondo, bdb e hdb, che sono ormai vetusti e addirittura sconsigliati per l’uso. Ci rimane sostanzialmente mdb. Continua a leggere→

Per collegare una macchina unix o Linux ad una Windows per l’autenticazione, si può utilizzare il winbind, cioè quella parte di samba che permette di autenticare gli utenti tramite le loro credenziali di dominio. Una volta che l’utente è autenticato, viene creato una utenza corrispettiva a quella Windows anche su Unix. La nuova utenza avrà un proprio UID e un GID generati al volo da winbind, ma quando l’utente tornerà una seconda volta a fare l’accesso a Unix, sarà meglio che trovi gli stessi UID e GID, così da avere gli stessi diritti che aveva al primo accesso. Per far sì che UID e GID siano mantenuti, questi vengono memorizzati da qualche parte e associati al SID (cioè all’UID per Windows).

Nel caso che si debbano avere più macchine unix collegate allo stesso dominio Windows, è il caso di memorizzare queste informazioni in un luogo accessibile a tutte le macchine, come ad esempio il dominio Windows stesso (utilizzando l’estensione SFU), oppure in un LDAP, oppure in alcuni file che possono essere periodicamente copiati dalla macchina unix principale alle secondarie. Invece, se la macchina unix è una sola, allora si possono semplicemente utilizzare dei file sul server unix stesso.

Per dire a winbind quale percorso seguire, vanno impostati i «backend» della mappatura degli identificatori, detta idmap. Nel mio caso ho utilizzato il backend tdb2, cioè la nuova versione del tdb («Trivial DataBase», che in italiano significa «base dati elementare»). Nel file di configurazione di samba, ho scritto:

idmap config *:backend = tdb2
idmap config *:range = 4000-4100

Che vuol dire: per le utenze di qualsiasi dominio Windows, memorizza le associazioni SID/UID e SID/GID tramite il backend tdb2. Inoltre crea gli UID e GID nell’intervallo da 4000 a 4100,  in modo da essere sicuro che non si sovrappongano a UID e GID già presenti sul sistema unix locale. (Nota: l’intervallo per UID e GID locali è definito in /etc/login.defs.)

Per tutti quelli che usano Debian GNU/Linux (state già usando tutti Debian, vero?), tdb2 andrà a creare il suo database nella directory /var/lib/samba e lo chiamerà idmap2.tdb.

Questo database è — appunto — elementare: cioè è capace di inserire solo dati nella forma chiave/valore. Per vedere quali chiavi sono memorizzate, si può usare il comando tdbtool in questo modo:

root@miura:~# tdbtool /var/lib/samba/idmap2.tdb keys
key 9 bytes: GID 4037
key 43 bytes: S-1-5-21-1142429371-1648316-403635728-1131
key 9 bytes: GID 4024
key 9 bytes: UID 4043
key 43 bytes: S-1-5-21-1142429371-1648316-403635728-1136
[...]

come si vede, le chiavi sono a volte un UID a volte un GID, a volte un SID. Non è scritto nella documentazione online, ma l’informazione su quanto sia lunga la chiave è di grande aiuto: la chiave “UID 4043” è lunga 9 byte, ma sono solo 8 caratteri, quindi c’è qualcos’altro. Idem per le altre chiavi.

Per sapere a cosa è associata una certa chiave potremmo usare lo stesso comando, con argomenti diversi. Proviamo:

root@miura:~# tdbtool /var/lib/samba/idmap2.tdb show 'GID 4037'
fetch failed

L’errore è criptico, ma ricordando il messaggio precedente sulla lunghezza della chiave, e con un po’ di fantasia (o leggendo il codice sorgente), si può trovare il comando corretto, con l’aggiunta di un byte 0 alla fine della chiave:

root@miura:~# tdbtool /var/lib/samba/idmap2.tdb show 'GID 4037\0'

key 9 bytes
GID 4037
data 43 bytes
[000] 53 2D 31 2D 35 2D 32 31  2D 31 31 34 32 34 32 39  S-1-5-21 -1142429
[010] 33 37 31 2D 31 36 34 38  33 31 36 2D 34 30 33 36  371-1648 316-4036
[020] 33 35 37 32 38 2D 31 31  38 35 00                 35728-11 85

bene, adesso non ci sono errori: alla chiave GID 4043 è associato il SID S-1-5-21-1142429371-1648316-403635728-1185, e viceversa:

root@miura:~# tdbtool /var/lib/samba/idmap2.tdb show \
'S-1-5-21-1142429371-1648316-403635728-1185\0'

key 43 bytes
S-1-5-21-1142429371-1648316-403635728-1185
data 9 bytes
[000] 47 49 44 20 34 30 33 37  00                       GID 4037

Lo stesso comando permette anche di cancellare un’associazione, ma questa operazione — ora che abbiamo capito che winbind scrive due record per ogni associazione — va fatta per entrambe le chiavi. Il comando in questo caso non fornisce nessun messaggio riguardo l’esito, nel miglior stile unix:

root@miura:~# tdbtool /var/lib/samba/idmap2.tdb delete \
'S-1-5-21-1142429371-1648316-403635728-1185\0'
root@miura:~# tdbtool /var/lib/samba/idmap2.tdb delete 'GID 4037\0'

Chiudo così questo breve excursus sul trivial database, che nel mio caso è il frutto dello studio dovuto ad un problema, su un server, che presentava due utenti con lo stesso UID. Erano difatti due diverse associazioni memorizzate nel tdb di winbind: una era riferita ad una utenza effettivamente presente sul dominio, mentre l’altra era una associazione rimasta memorizzata nonostante l’utenza sul dominio fosse stata cancellata. Ah, già, dimenticavo: winbind non cancella mai le associazioni locali SID/UID.