Raccogliere i syslog di BIND Named


Il server DNS Bind, noto anche come Named, è uno dei nameserver più vecchi e diffusi sul web e nelle organizzazioni che utilizzando sistemi Linux e Unix.
Spesso Bind viene configurato in modalità chroot, il che permette di ridurre la superficie di attacco isolando il servizio in una gabbia.
Tuttavia quando una risorsa viene “ingabbiata” si perdono le caratteristiche che permettono una semplice condivisione di messaggi o dati con altri servizi.
In questo caso vorremmo poter raccogliere tutte le query fatte al nostro DNS server e gli errori mediante un server syslog esterno.
La configurazione di default non è sufficiente per fare ciò e bisogna fare delle modifiche ai file di configurazione del syslog (rsyslog) e di Bind.

Qualora rsyslog non sia installato (questo succede in distribuzioni vecchie come Red Hat 5 e simili) è necessario installarlo e sostituire rsyslog al syslog di base, chiamato syslogkd/klogd.

Il server syslog esterno raccoglie i log di Bind con Log Analyzer

Se Named è chrootato, i file di configurazione sono posti (di default) in /var/named/chroot quindi il classico named.conf non si trova più /etc/named.conf ma in /var/named/chroot/etc/named.conf

La prima cosa da fare è modificare il file di configurazione di Bind /var/named/chroot/etc/named.conf aggiungendo nella sezione options la riga “querylog yes“, poi abilitando il logging verso il syslog. Tutto il codice va nel blocco logging.

options {
	  querylog yes;
};

channel log2syslog  { 
    print-time yes;
    print-category yes;
    print-severity yes;

    syslog daemon;
    severity info; 
};
category queries { queries_log; };

L’uso delle istruzioni che cominciano con print è facolatativo ma consente un migliore filtraggio sul server di destinazione.

L’abilitazione del logging via syslog crea un socket unix in /dev/log. Visto che il nostro Bind è in chroot, il socket sarà creato nella sua cartella chrootata, quindi il socket sarà /var/named/chroot/dev/log.

Ora abilitiamo l’ascolto sul socket da parte di rsyslog e modifichiamo la configurazione di /etc/rsyslog.conf aggiungendo le seguenti righe:

$ModLoad imuxsock
$AddUnixListenSocket /var/named/chroot/dev/log
input(type="imuxsock" Socket="/var/named/chroot/dev/log" CreatePath="on")

:programname, isequal, "named" @172.16.0.2
:programname, isequal, "named" ~

Dove 172.16.0.2 è l’indirizzo IP del server syslog esterno.
Così facendo avremmo inoltrato i messaggi di syslog alla porta 514 (UDP) del syslog esterno.

E’ importante verificare che se è attivo SELINUX, sia permessa la comunicazione dei 2 servizi e qualora il firewall fosse attivo, sia abilitata l’uscita dei datagrammi UDP verso il server syslog esterno.

Fatto questo possibile riavviare il servizio rsyslog e named.

service rsyslog restart
service named restart

Note: Questo articolo è stato scritto per essere il più generico possibile, ossia utilizzabile sia su sistemi recenti o vecchi come Red Hat 5 e derivate. Per questo motivo potrebbero esserci delle differenze su altre distribuzioni.

Requisiti di sistema per Microsoft Flight Simulator 2020

Aggiornato 3 ottobre 2020 – Ad agosto di quest’anno, la casa madre ha rilasciato una nuova release: Microsoft Flight Simulator 2020 (FS 2020) per sistemi Windows.

Sono passati veramente molti anni dall’ultima versione di Microsoft Flight Simulator, Microsoft Flight Simulator X detto anche FSX o FS10.

Flight Simulator 2020 è disponibile in più versioni: quella più economica, ossia la versione standard, mette a disposizione meno aerei e gli aeroporti sono meno dettagliati delle versioni superiori. Il mio suggerimento è quello di puntare alla versione più accessoriata.

Il videogame è acquistabile presso il Windows Store: https://www.microsoft.com/it-it/p/microsoft-flight-simulator-standard-preorder/9nxn8gf8n9ht

In alternativa per provare il videogame, senza dover spendere molto, è l’acquisto dell’Xbox Game Pass. Questo, per circa 10 euro al mese in abbonamento, offre l’accesso a centinaia di giochi tra cui FS2020.

Per giocare a Flight Simulator è necessario usare Windows 10 (64 bit) versione 1903, ma è meglio installare tutti gli aggiornamenti disponibili. Sfortunatamente è necessario avere una connessione ad Internet per giocare.

Ecco la lista dei requisiti per giocare a Microsoft Flight Simulator 2020 che sono indicati da Microsoft:

Requisiti minimi Flight Simulator 2020:

  • CPU: AMD Ryzen 3 1200 oppure Intel Core i5 4460
  • GPU: Radeon RX 570 oppure Nvidia GTX 700
  • RAM della scheda video: 2 GB
  • RAM: 8 GB
  • Spazio su hard disc: 150 GB
  • Velocità Internet: 5 Mbps (0,6 MB/s)

Requisiti consigliati:

  • CPU: AMD Ryzen 5 1500X oppure Intel Core i5 8400
  • GPU: Radeon RX 590 oppure Nvidia GTX 970
  • RAM della scheda video: 4 GB
  • RAM: 16 GB
  • Spazio su hard disc: 150 GB
  • Velocità Internet: 20 Mbps (2,5 MB/s)

Requisiti ideali per FS 2020:

  • CPU: AMD Ryzen 7 2700X o Intel Core i7 9800X
  • GPU: Radeon VII oppure Nvidia RTX 2080
  • RAM della scheda video: 8 GB
  • RAM: 32 GB
  • Spazio su hard disc: SSD da 150 GB
  • Velocità Internet: 50 Mbps (6,3 MB/s)

Come possiamo osservare requisiti necessari per far girare bene Flight Simulator 2020 non sono esagerati, ma se vogliamo dettagli ultra è opportuno predisporre di un computer di fascia alta. Per chi intende comperare un nuovo PC consiglio caldamente di scegliere una configurazione come quella indicata, se il budget non consente una spesa maggiore di 1000 euro. Con questa configurazione sarà possibile giocare con un dettaglio High e con una risoluzione 1920×1080 (Full HD) ad un frame rate superiore ai 60 fps:

CPU: Intel Core i5-10400F (circa 175 euro)
GPU: MSI GeForce GTX 1660 SUPER VENTUS XS OC 6GB (circa 225 euro)
RAM: 32 GB (2 X 16 GB) Corsair Vengeance DDR4-3200 CMK32GX4M2B3200C160 (circa 130 euro)
SSD: M.2 da 500 GB (circa 65 euro)
Scheda madre: ASUS TUF GAMING B460-PLUS (circa 130 euro)
Alimentatore: be quiet! System Power 9 da 600W (circa 65 euro)
Case: Corsair 110Q ATX (60 euro)

Totale: 850 euro.

Consigli per massimizzare le prestazioni di FS2020

Se volete migliorare le performance di Flight Simulator 2020 vi suggerisco di installare il driver 452.06 WHQL, per chi possiede una scheda video Nvidia. Mentre per chi possiede una scheda AMD aggiornare il driver almeno alla versione 20.8.2. Entrambi i driver contengono delle fix per massimizzare le performance delle rispettive schede grafiche. Penalizzano le performance driver più vecchi.

Prima di installre i driver, si consiglia di rimuovere il driver precedente installato (con Display Driver Uninstaller) e poi di installare quello per la propria GPU.

Per aumentare le prestazioni di FS2020, è opportuno attivare in Windows 10 anche la modalità gioco, in maniera da priorizzare l’allocazione delle risorse al videogame anzichè alle routine del sistema.

Per attivarela basta andare in Impostazioni quindi cliccare sull’icona Giochi.

Cliccando su Modalità gioco nella colonna di sinistra si dovrà quindi attivare l'”interruttore” Usa modalità gioco.

Miniedit, l’interfaccia grafica per Mininet

Mininet è uno strumento utile a costruire, su un computer oppure su una virtual machine, una rete virtuale realistica composta da host, switch e programmi vari. Uno degli ambiti in cui Mininet è molto usato è la sperimentare di sistemi OpenFlow e Software-Defined Networking (SDN).
MiniEdit, invece, è un’interfaccia grafica basata su Python e TK che consente di disegnare delle reti da usare con Mininet usando un tool con interfaccia grafica.

Il software può essere installato e configurato sullo stesso sistema in cui c’è Mininet. Nel nostro caso, Mininet è installato su Ubuntu 20.04 e oltre alle dipendenze di quest’ultimo è necessario installare alcuni pacchetti aggiuntivi come python-tk:

sudo apt install python-tk

Qualora non lo avessimo già fatto precedentemente in fase di installazione di Mininet, è opportuno installare anche openvswitch-testcontroller e creare un link per poter testare la nostra topologia personalizzata.

sudo apt-get install openvswitch-testcontroller
sudo ln /usr/bin/ovs-testcontroller /usr/bin/controller

Poi per lanciare MiniEdit, si può usare il comando python2 (attualmente python3 non funziona):

sudo python2 ~/mininet/examples/miniedit.py

Per disegnare una semplice rete, basta selezionare dal menù laterale gli oggetti: host, switch, controller e altro, da collegare con un link. Per esempio questo è il risultato della progettazione di una semplice rete.

Per modificare lo script del disegno che si potrà esportare, basta andare nel menù Edit, Preferences e cambiare qua le varie impostazioni:

E’ possibile optare per una configurazione che supporti versioni più recenti di OpenFlow, oppure uno switch diverso dal classico Open vSwitch, nonchè aggiungere il supporto per un controller di rete esterno a Mininet. E’ utile attivare la casella Start CLI.

Per esportare la configurazione in uno script python, andare nel menù, File e selezionare Export level 2 script.

Ora per lanciare il tool mininet con la topologia personalizzata è sufficiente lanciare il comando:

sudo python2 miatopologia.py

Lettori Blu-ray Samsung in riavvio continuo

Aggiornamento 26/06/2020 – In fondo al post. Quello che è successo negli ultimi giorni è alquanto bizzarro, ma non di certo infrequente: all’improvviso una serie di lettori Blu-ray Samsung ha praticamente smesso di di funzionare.
In un post della community sul sito di supporto di Samsung ci sono ormai centinaia di interventi di utenti che confermano il problema su vari modelli: Samsung J5900, BD-J5100, BD-JM56C, BD-JM57C, BD-J5700, HT-J5500W.
Quando il lettore Blu-ray Samsung si accende dopo poco inizia a riavviarsi all’infinito ogni pochi secondi, classico esempio di boot loop.
I comandi di accensione e di espulsione del disco vengono ignorati e tutti i tentativi di ripristinare i lettori blu-ray non hanno avuto buon seguito.

L’assistenza Samsung ha riferito che i dispositivi che presentano il problema vanno inviati alla riparazione hardware, e a questo punto Samsung sembra aver ammesso che il continuo riavvio dei lettori Blu-ray è un problema comune, non un singolo caso.
Per chi ha un lettore Blu-ray Samsung fuori garanzia che manifesta il problema del continuo riavvio del lettore Blu-ray ha precluso il normale processo di aggiornamento del software; purtroppo in questo caso si ha ben poco da fare se non attendere e sperare che un’eventuale riparazione sia poco costosa. Per il momento conviene lasciare spento il proprio lettore Blu-ray Samsung onde evitare che possa verificarsi il problema del riavvio continuo.

Aggiornamento 23/06/2020: ieri il supporto tecnico di Samsung scrive nel thread aperto sulla community: “Siamo a conoscenza dei clienti che hanno segnalato un problema con i loop di avvio su alcuni lettori Blu-Ray e stiamo esaminando ulteriormente questo aspetto. Pubblicheremo un aggiornamento qui su questo thread quando avremo ulteriori informazioni.”

Aggiornamento 26/06/2020: sembra che sia sufficiente conttare il centro di assistenza di Samsung (o telefonare al numero verde 800 726 7864) anche se il proprio lettore Blu-Ray è fuori garanzia per ricevere supporto, il lettore va inviato ai centri di riparazione di Samsung che poi provvederanno a ripararlo e a rispedirlo all’utente.

Come aumentare lo spazio di una partizione ext4 montata

A volte capita di dover estendere lo spazio disco associato ad una partizione di tipo EXT4 che è attiva (online) su un server. Nel nostro caso abbiamo un server con Ubuntu 14.04 sul quale è necessario più spazio per cui bisogna estendere la partizione / del sistema operativo.

Il server non ha logical volume (LVM) ma le partizioni sono le solite standard.

Il problema di questa configurazione è la swap. Infatti la partizione di swap è posta alla fine del disco SDA, quindi è necessario toglierla perchè una classica partizione EXT4 deve essere contigua.

Come si può vedere abbiamo una partizione SDA5 di swap a fine disco.

La prima cosa da fare è estendere il disco, se è un disco virtuale spesso è opportuno spegnere la virtual machine ed estendere il disco. Poi riaccendere la virtual machine. Se il disco è fisico, rimuovere la swap e usare quello spazio per estendere la partizione principale. La swap può essere ricreata su un altro disco oppure fatta su file.

Nel nostro caso vogliamo espandere la partizione / e mantenere la partizione di swap di 3 GB sullo stesso disco.

Attenzione questa procedura è rischiosa e potrebbe portarvi alla perdita di tutti i dati, per cui in primis è necessario fare un backup di tutto.

Ok. Ora il disco SDA è stato espanso di ulteriori 4 GB passando dai precedenti 8 GB ai 12 GB. Dobbiamo rimuovere la swap, cancellare le partizioni, ricreare la partizione / e quella di swap.

La partizione di swap va disattivata.

swapoff /dev/sda5

Poi va lanciato fdisk sul disco che contiente il tutto.

fdisk /dev/sda

Premendo il carattere p, si ottiene la situazione attuale delle partizioni.

Cancelliamo la partizione 5 e la 2 che sono rispettivamente la swap e una partizione estesa. Per cancellare una partizione premere il tasto d, seguito dal numero della partizione es. 5.

Ora c’è la parte più delicata: quella di cancellare anche la partizione 1. Premendo d, si cancella l’ultima partizione esistente.

La partizione / va ricreata come una nuova partizione primaria la cui dimensione deve essere pari allo spazio del disco meno lo spazio della swap, quindi se il nostro disco è di 12 GB e la nostra swap di 3 GB, la partizione / sarà di 9 GB.

Per creare una partizione nuova premere n, poi p (per primaria), +9G per assegnare 9 gigabyte di spazio.

Ora è possibile creare la partizione di swap. Premere n per una nuova partizione, p per una primaria, come partition number premere INVIO per confermare l’opzione di default. Siccome è l’ultima partizione del disco anche la dimensione è quell di default, quindi basta premere INVIO.

E’ opportuno, a differenza della partizione di root, modificare l’etichetta (tag) del codice, premendo t, indicando la seconda partizione premendo 2 e inserendo l’hex code 82.

questo è lo stato dopo tutte le operazioni:

Per confermare tutte le operazioni bisogna premere il tasto w.

Può essere che compaia un messaggio di avvertimento. In questo caso, la tabella delle partizioni modificata non è stata ricaricata dal kernel, quindi per poter estendere il disco, occorre ricaricare la tabella.

Per ricaricare la tabella usare il comando partprobe.

partprobe

Creiamo la nuova swap, usando il classico comando:

mkswap /dev/sda2

Annotiamoci l’UUID (quello che nell esempio inizia con 1c8…) che è apparso sopra. Apriamo il file fstab e modifichiamo l’UUID associato alla swap vecchia con quello nuovo.

vi /etc/fstab

Il nuovo file fstab avrà queste informazioni:

La swap va nuovamente attiva con il comando swapon, per verificare poi lo stato si può ricorrere allo stesso comando con il parametro -s.

swapon /dev/sda2
swapon -s

Finalmente possiamo estendere la partizione / con il semplice ma efficace resize2fs.

resize2fs /dev/sda1

Il ridimensionamento è online, ossia senza la necessità di smontare il filesystem / per estendere la partizione. Ora la partizione è molto più grande.

Assegnare un IP statico in Ubuntu 20.04

Impostare un IP statico, ossia un indirizzo IP che non cambia, in Ubuntu 20.04 non è molto difficile. La modifica può essere fatta via interfaccia grafica nella versione desktop, mentre nella versione server di Ubuntu 20.04 è necessario usare la riga di comando.

Per prima cosa occorre individuare il nome dell’interfaccia di rete alla quale sarà assegnato l’indirizzo IP statico. Per scoprirlo basta usare il comando:

ip a

Nell’output generato dal comando si può vedere che la scheda di rete che ha l’IP 192.168.217.9 (assegnato tramite DHCP ossia dinamicamente) si chiama ens192.

Ora possiamo creare un file di configurazione della scheda di rete.

sudo vi /etc/netplan/50-my-init.yaml

In questo file incolliamo questo testo, opportunamente modificato con i nostri parametri.

network:
    ethernets:
        ens192:
            dhcp4: false
            addresses: [192.168.217.32/24]
            gateway4: 192.168.217.1
            nameservers:
              addresses: [192.168.217.1,8.8.8.8]
    version: 2

ens160 corrisponde al nome dell’interfaccia di rete recuperato col comando ip a. 192.168.217.32 è l’IP statico che abbiamo scelto per la nostra rete, mentre /24 corrisponde alla netmask. Il gateway della rete è specificato dalla voce gateway4.

Si possono aggiungere anche diversi indirizzi IP dei DNS, questi vanno separati con una virgola; per esempio nel caso sopra gli indirizzi dei server DNS sono 192.168.217.1 e 8.8.8.8.

La vecchia configurazione della scheda di rete era in DHCP, quindi spostiamo il vecchio file in modo che esso possa essere recuperato ma non sia attivo:

sudo mv /etc/netplan/00-installer-config.yaml /etc/netplan/00-installer-config.yaml_old

A questo punto è possibile applicare la nuova configurazione usando il comando:

sudo netplan apply

Ora eseguendo il comando ip a potremmo scoprire come la scheda di rete ha un indirizzo IP statico.

Disinstallare le app integrate di Windows 10

Windows 10 putroppo ha diverse app installate che possono dare fastidio, sia in termini di privacy (e telemetria) sia a livello di occupazione delle risorse come cpu, ram e spazio disco. A volte anche fastidio di ritrovarsi con queste app che compaiono nel menù Start.

Il modo più semplice per sbarazzarsi di queste app è quello di cliccarci su con il tasto destro del mouse e selezionare la voce Disinstalla.

Disinstallazione di Bubble Witch 3 Saga

C’è la possibilità di rimuovere le app integrate di Windows 10 anche via riga di comando (powershell), così da velocizzare la disinstallazione delle app. Per aprire poweshell, cercare la parola power nella barra vicino al pulstante start. Selezionare Windows PowerShell.

Per esempio ecco un elenco di app che possono essere disinstallate senza creare lacune nel sistema, incolliamo queste righe nella Poweshell:

Get-AppxPackage *3dbuilder* | Remove-AppxPackage
Get-AppxPackage *windowscommunicationsapps* | Remove-AppxPackage
Get-AppxPackage *skypeapp* | Remove-AppxPackage
Get-AppxPackage *zunemusic* | Remove-AppxPackage
Get-AppxPackage *windowsmaps* | Remove-AppxPackage
Get-AppxPackage *bingfinance* | Remove-AppxPackage
Get-AppxPackage *zunevideo* | Remove-AppxPackage
Get-AppxPackage *bingnews* | Remove-AppxPackage
Get-AppxPackage *onenote* | Remove-AppxPackage
Get-AppxPackage *people* | Remove-AppxPackage
Get-AppxPackage *windowsphone* | Remove-AppxPackage
Get-AppxPackage *windowsstore* | Remove-AppxPackage
Get-AppxPackage *bingsports* | Remove-AppxPackage
Get-AppxPackage *bingweather* | Remove-AppxPackage
Get-AppxPackage *xboxapp* | Remove-AppxPackage
Get-AppxPackage *CandyCrush* | Remove-AppxPackage

Rinnovare un certificato TLS in Tomcat

La procedura per rinnovare il certificato SSL/TLS nel keystore di Tomcat dipende tipicamente dal tipo di certificato o meglio dall’ente certificatore.

Nelle ultime versioni di Tomcat l’uso del keystore, come abbiamo visto negli articoli precedenti, non è più necessario rendendo il rinnovo del certificato più semplice in quanto basta sostituire i file della chiave, della full-chain e riavviare Tomcat.

Tuttavia l’uso del keystore è ancora molto popolare quindi se vi ritrovate a dover rinnovare il certificato è probabile che dobbiate usare il keystore e lo strumento per la gestione: il keytool.

Nel caso di Letsencrypt i passaggi sono piuttosto semplici e automatizzabili: consistono nella cancellazione del certificato dal keystore e dall’importazione del nuovo, più riavvio di Tomcat.

Se invece il vostro certificato viene rilasciato da un rivenditore di certificati, la procedura solitamente prevede:

  • la creazione di un CSR (Certificate Signing Request) a partire dal certificato+chiave memorizzato nel keystore,
  • l’invio del CSR al rivenditore,
  • la verifica dell’identità del richiedente tramite DNS, mail o inserimento di una pagina web ad hoc,
  • la ricezione del certificato,
  • il caricamento del certificato nonchè del certificato root CA e dell’intermedio nel keystore
  • il riavvio di Tomcat.

Per verificare quali certificati sono presenti nel proprio keystore si può usare il comando (dove miokeystore.jks è il nome del proprio keystore):

keytool -list -keystore miokeystore.jks

Nella schermata precedente, ci sono 3 certificati: intermediate e root sono quelli della CA, mentre mydomain è il nostro certificato con chiave (PrivateKeyEntry) di Tomcat.

Facciamo una copia di backup del keystore

cp miokeystore.jks miokeystore.jks_backup

Per procedere alla generazione del CSR abbiamo bisogno della password del keystore e di sapere quale è l’alias che Tomcat usa per il certificato. Nel nostro caso è mydomain, quindi possiamo lanciare questo comando:

keytool -certreq -alias mydomain -file tomcat.csr -keystore miokeystore.jks

Verrà generato un file chiamato tomcat.csr partendo dal certificato con chiave contenuto nel keystore miokeystore.jks; il file tomcat.csr (non contiene la chiave) va passato al rivenditore di certificati.

A questo punto il rivenditore permette di scegliere un metodo di identificazione e autenticazione del proprietario del dominio. Scelto il metodo e verificato il proprietario, allora ci viene fornito il certificato del dominio in formato testuale.

Questo certificato spesso non è sufficiente da solo ma è necessario aggiungere nel keystore tutta la catena dei certificati, iniziando con il certificato della root CA, poi quello intermedio e poi il certificato del dominio.

Supponendo di dover sostituire il root CA e l’intermedio già presente nel keystore, bisogna eliminarli entrambi (solo se non ci sono altri certificati nel keystore che li usando, ovviamente).

I vecchi certificati intermediate e root possono essere eliminati:

keytool -delete -alias intermediate -keystore miokeystore.jks
keytool -delete -alias root -keystore miokeystore.jks

Non va cancellato il certificato con chiave mydomain.

I nuovi certificato root e intermediate che sono stati scaricati dal sito del rivenditore o della certification authority possono essere importati così:

keytool -import -trustcacerts -alias root -file DigiCert_Global_G2.pem -keystore miokeystore.jks

Dove DigiCert_Global_G2.pem è il certificato della Root CA.

keytool -import -trustcacerts -alias intermediate -file DigiCertGlobalCAG2.pem -keystore miokeystore.jks

Dove DigiCertGlobalCAG2.pem è il certificato della Intermediate CA.

Importiamo ora il certificato ricevuto dal rivenditore, supponiamo che il certificato sia contenuto nel file mydomain.txt

keytool -import -alias mydomain -file mydomain.txt -keystore miokeystore.jks

Così facendo il nuovo certificato verrà unito alla chiave già presente nel keystore.

Per far ripartire Tomcat su Debian o CentOS

systemctl restart tomcat9

Se l’importazione è stata effettuata in maniera corretta, il riavvio di Tomcat sarà completato con successo, altrimenti è possible che Tomcat non riesca a ripartire.

In tal caso, è possibile ripristinare il keystore originale (antecedente alle modifiche) e analizzare cosa è andato storto.

Una delle verifiche da fare è la corretta importazione del certificato con chiave. Infatti il certificato senza chiave non permette la partenza di Tomcat. Per verificare se c’è il certificato con chiave, basta cercare nell’output della lista se c’è PrivateKeyEntry.

keytool -list -keystore miokeystore.jks

NXNSAttack: Scoperta nuova vulnerabilità che sfrutta il meccanismo di delega DNS

La falla consente a un utente malintenzionato di forzare qualsiasi DNS resolver ricorsivo a inviare un numero elevato di query (Distributed denial-of-service) al server DNS autorevole della vittima.

L’aspetto che viene sfruttato è la delega glueless, dove un glue record corrisponde agli indirizzi IP di un name server (ossia un DNS server).
Petr Špa?ek scrive ul blog di CZ.NIC che
“Questa è la cosiddetta delega glueless, ovvero una delega che contiene solo nomi di server DNS autorevoli (a.iana-servers.net. oppure b.iana-servers.net.), ma non contiene i loro indirizzi IP.
Ovviamente DNS risolutore non può inviare una query a “nome”, quindi il risolutore deve prima ottenere l’indirizzo IPv4 o IPv6 del server autorevole “a.iana-servers.net”. o “b.iana-servers.net.” e solo allora può continuare a risolvere la query originale “esempio.com. A”. Questa delega glueless è il principio base di NXNSAttack: il server compromesso semplicemente restituisce la delega con nomi di server falsi (casuali) che puntano al dominio DNS della vittima, costringendo così il risolutore per generare query verso i server DNS delle vittime (in un inutile tentativo di risolvere falsi nomi di server autorevoli).
Molteplici i server DNS affetti da questo problema tra cui Bind, PowerDNS, i DNS di Cloudflare, Google, Amazon, Microsoft.

Si consiglia di aggiornare al più presto i propri pacchetti sulle varie distribuzioni Linux. Rimanente in attesa per quelle che non è ancora disponibile l’aggiornamento.

Dettagli nel documento: http://www.nxnsattack.com/dns-ns-paper.pdf

Ridurre la dimensione dei file di log di Journal

Systemd, il gestore di tutto in Linux, è uno dei servizi fondamentali dei sistemi operativi del piguino usciti negli ultimi 6-7 anni.
Ha gradualmente soppiantato SysVinit, il tradizionale gestore di avvio/spegnimento dei deamon, e ha anche preso posto di altri tool integrandosi nel sistema in maniera alquanto invasiva.

Journal è un componente di systemd che si occupa principalmente del logging raccogliendo messaggi dal kernel, boot, syslog e altri servizi. Il deamon che governa journal è systemd-journald, il quale raccoglie i messaggi e li memorizza nei suoi “registri” (/run/log/journal, non persistente al riavvio) e in alcuni file di log.

Questi ultimi file di log si trovano nella cartella journal della classica /var/log. La cosa particolare è che questi file di log non dovrebbero essere riciclati dal classico logrotate ma dovrebbero essere mantenuti dal deamon systemd-journald che si dovrebbe occupare della cancellazione dei dati più vecchi.

La mancanza della cartella /var/log/journal implica che non vengono manutenuti file di log persistenti, a meno che nel file di configurazione venga indicato un percorso alternativo.

Il file di configurazione principale è /etc/systemd/journald.conf ed eventuali altri in /etc/systemd/journald.conf.d/, in questi file si possono modificare alcuni parametri tra cui compressione e tempo di conservazione.

La mancanza del file di configurazione implica l’uso delle opzioni di default, tra cui l’attivazione della compressione, un file per utente, l’occupazione del massimo del 10% dello spazio disponibile nel filesystem dove i dati sono mantenuti persistenti e il 15% dello spazio del filesystem dove i dati non persistenti.

Quest’ultimo aspetto è interessante, in quanto se abbiamo una partizione /var/log molto piccola es. 5 GB, journal manterrà al massimo 500MB. Tuttavia se sia /run sia /var/log sono sullo stesso filesystem è possibile che l’uso del disco da parte di journal arrivi a raggiungere il 25% (10% + 15%), prima di essere recuperato.

Per vedere quanto spazio su disco occupa il file di log si può usare il comando:

journalctl --disk-usage

Per ridurre rapidamente le dimensioni su disco ci sono due vie la prima quella di decidere di mantenere soltanto un dato numero di file di journal, per cui verranno cancellati i file più vecchi ad eccezione dei tot più recenti.
Lanciando per esempio il comando:

journalctl --vacuum-files=4

Conserveremo esclusivamente gli ultimi 4 file.

Se il comando sopra non fosse disponibile, per ridurre le dimensioni del file di log si può usare anche il comando:

journalctl --vacuum-size=100M

dove 100M sono le dimensioni in cui il file di log deve stare ossia verranno scartiti tutti i log più vecchi finchè non si raggiunge uno spazio di disco usato da Jorunal di 100M (o meno).