Archivi categoria: Computer

Articoli che riguardano i computer: software, hardware e modi d’utilizzo.

Combattere lo SPAM con exim

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.

Aggiungere un timeout ad un servizio di systemd

Systemd pare forse troppo veloce ad avviare i server su cui lavoro, dei DELL PowerEdge T110-II con dischi SATA in mirror.
Me ne sono accorto perché, all’avvio del server, il database postgresql non veniva avviato ed il relativo servizio di systemd era in stato «failed». Nei log di postgresql non c’erano errori, ma il database era spento.
Avviare postgresql via systemd da linea di comando ha sempre funzionato correttamente, ma ovviamente questo avviene solo dopo aver avviato il sistema, quando la macchina è meno carica. Difatti all’avvio, systemd fa partire in parallelo tutti i servizi che non hanno dipendenze tra loro. Tutti questi, partendo, leggono dal disco, il file system risponde quindi più lentamente del normale, e postgresql va in timeout.

Continua a leggere

Creare un nuova directory in LDAP con la nuova configurazione in /etc/ldap/slapd.d

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

SQL Server e la gestione automatica della memoria

Ogni istanza di SQL Server ha due parametri che indicano la quantità minima e massima di memoria RAM da utilizzare. Se questi valori sono diversi, SQL Server allocherà il minimo all’attivazione dell’istanza, e allocherà altra memoria secondo le necessità, arrivando eventualmente a raggiungere la soglia massima, ma senza superarla. Inoltre, l’istanza di SQL Server comunica al sistema operativo che, all’occorrenza, può liberare spazio, cosicché quando il sistema non riesce a dare memoria ad altre applicazioni, chiede a SQL Server di liberarne un po’. In questo caso la quantità di memoria usata cala, rimanendo sempre sopra la soglia minima impostata.

Fin qui tutto bene. Continua a leggere

Operare manualmente sulla mappatura UID/SID di winbind nel formato tdb2

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.