Su Linux per capire quali sono i file e le cartelle con dimensione più grandi ci sono diverse possibilità specialmente usando tools a riga di comando.
Per esempio per scoprire quali directory consumano molto spazio su disco si può usare il seguente comando
cd /; du -x | sort -nr
Volendo vedere soltanto le prime dieci cartelle possiamo integrare il comando precedente con un filtro.
cd /; du -x | sort -nr | head -10
Nello specifico questo comando impartisce l’istruzione di mostrare le dieci cartelle più grandi ordinate per dimensione (in byte) che si trovano sulla partizione / e ignora i mount point grazie al parametro “x”.
Il comando du tende ad essere molto veloce, per lo meno rispetto al classico find. Tuttavia find è indispensabile se oltre alla dimensione delle directory vogliamo scoprire anche quali sono i file più grandi:
find / -type f -exec wc -c {} \; | sort -nr | head -10
Col precedente comando abbiamo ottenuto la lista dei 10 file più grandi che si trovano sul sistema.
Fail2ban è uno strumento per creare delle regole dinamiche di firewalling al fine di bloccare ripetuti tentativi di hacking o bruteforce. Ecco un utile post rapido per fermare i tentativi di hacking al tuo server web WordPress come brute force alla wp-login.php e attacchi exploit a xmlrpc. Installa fail2ban.
sudo apt-get install fail2ban
Dopo aver installato fail2ban, configuralo per rilevare e bloccaree i tuoi host dannosi, aggiungendo queste due regole al tuo file jail su /etc/fail2ban/jail.conf
Modifica il percorso dove si trovano i file log di Apache o del tuo webserver (anche Nginx). Ora aggiungi due file in /etc/fail2ban/filter.d chiamati worpdress-xmlrpc.conf e worpdress-wplogin.conf con il seguente contenuto:
Ad agosto, Microsoft ha rilasciato un patch per diverse versioni di Windows (gratuite per Windows 10 o Windows 2012 in su) per correggere una vulnerabilità che consentirebbe ad un utente malintenzionato di diventare essenzialmente amministratore di dominio facilmente. L’unica cosa che gli serve è un collegamento diretto ad un domain controller, ossia il server che nelle reti di server Windows svolgere il ruolo di gestire gli accessi centralizzati.
La vulnerabilità è possibile grazie ad un errore in uno schema di autenticazione crittografica utilizzato dal Netlogon Remote Protocol, che tra le altre cose può essere utilizzato per aggiornare le password dei computer. Questo problema consente agli aggressori di impersonare qualsiasi computer, incluso il domain controller (DC) stesso, ed eseguire chiamate di procedura remota (RPC) per conto di un altro computer.
Già l’anno scorso si era scoperta una vulnerabilità al componente Netlogon meno grave ma ora questa seconda vulnerabilità è molto più grave (punteggio CVSS: 10.0). Creando un token di autenticazione per una specifica funzionalità di Netlogon, è stato in grado di utilizzare una funzione per modificare la password di un computer sul domain controller su un valore noto. Dopodiché, l’aggressore può utilizzare questa nuova password per assumere il controllo del domain controller e rubare le credenziali di un amministratore di dominio.
La patch rilasciata ad agosto predispone l’insieme di server all’arrivo di una nuova patch che sarà rilasciata a febbrario 2021. Questo è stato necessario perchè una volta installata la patch di febbraio i vecchi domain controller Windows 2003 e 2008 per i quali non verrà rilasciata nessuna patch non potranno più comunicare con domain controller patchati.
Linux è affetto?
Ora veniamo a Linux, i tool di configurazione di Samba supportano canali sicuri tra i membri del dominio e i domain controller. Tuttavia, il comportamento predefinito per il server schannel (secure channel) prima di Samba 4.8 era di negoziare automaticamente il canale sicuro solo se un client lo supportava. Dalla versione 4.8, il comportamento predefinito di Samba è stato quello di preferire un canale sicuro per tutti i client (come se ci fosse “server schannel = yes” nel file smb.conf), il che è una soluzione sufficiente contro gli exploit noti che sfruttano la vulnerabilità CVE-2020-1472.
La richiesta di un canale sicuro potrebbe rendere inutilizzabili alcune vecchie applicazioni scrite per vecchie versioni di Active Directory (domini NT4). Per questo motivo, la mitigazione di Microsoft per CVE-2020-1472 non disabilita immediatamente l’accesso non autenticato al servizio di netlogon.
Red Hat non è a conoscenza di applicazioni specifiche che richiedono l’uso di un canale non autenticato per il servizio di netlogon. Tutti i componenti Samba in tutte le versioni di Red Hat Enterprise Linux (RHEL) supportano il funzionamento con schannel e continueranno a funzionare quando i futuri aggiornamenti di Microsoft disabiliteranno del tutto il supporto del canale non autenticato.
In Red Hat Enterprise Linux 6 le configurazioni predefinite dei pacchetti samba e samba4 forniti con il sistema sono vulnerabili in quanto non impongono la creazione di canali sicuri per tutte le connessioni client al servizio netlogon. La vulnerabilità può essere mitigata mettendo “server schannel = yes” nella sezione [global] del file smb.conf e riavvia Samba su tutti i DC.
Tuttavia , si può usare testparm per verificare che la configurazione di Samba sia in esecuzione in modalità domain controller oppure standalone (ossia membro di dominio) e quale impostazione “server schannel” viene utilizzata.
testparm -v -s | grep schannel
Se nell’output del comando compare “Server role: ROLE_DOMAIN_PDC” oppure “Server role: ROLE_DOMAIN_BDC” il server agisce come domain controller. Nelle righe successive dell’output è riportato se è attivato o meno il secure channel (schannel).
Qui è installato Samba 4.7, questo server è vulnerabile.
Anche SuSE Linux è affetta dalla problematica per le versioni di Samba precedenti alla 4.8, anche qui il suggerimento per mitigare la falla è quello di inserire lo stesso parametro visto per RHEL: “server schannel = yes” nel file smb.conf e riavviare il servizio con un “sudo service smb restart”. Il supporto di SUSE riporta sono state correzioni e aggiornamenti a tutte le versioni supportate e interessate al problema.
NVIDIA ieri sera ha annunciato che acquisterà la società di progettazione di semiconduttori ARM Limited per 40 miliardi di dollari fra contanti e azioni. L’accordo consentirà a SoftBank, la società che possiede ora ARM, di ricevere 12 miliardi in contanti e 21,5 miliardi in azioni NVIDIA. Tuttavia la strada per la conclusione impeighera parecchi mesi in quanto l’acquisto deve essere approvato dai vari paesi. SoftBank, che in precedenza aveva acquisito alla cifra di 32 miliardi l’allora indipendente ARM nel 2016, fece questa mossa per fare un investimento prevedendo che il valore della società continuasse a crescere.
In questo articolo vediamo come come eliminare la coda di posta in Postfix. Per cancellare la coda di posta in Postfix, si può usare il comando chiamato postsuper che viene utilizzato per fare manutenzione alla coda di posta postfix. Il comando postsuper può essere eseguito solo da un super utente del sistema oppure da root. Per sapere cosa c’è nella coda della posta si può usare il comando mailq. Se ci sono messaggi non consegnati, è possibile vedere un lungo elenco di messaggi usando mailq.
In questo tutorial useremo il comando postsuper per svuotare la coda di posta di Postfix.
Per prima cosa esegui il comando mailq comando per verificare quante mail sono in coda.
mailq
Invece per svuotare la coda delle email, puoi scegliere una di queste alternative:
rimuovere un particolare messaggio con un ID della coda di posta (eseguendo il comando mailq, otterrai l’ID della coda di posta, ossia “Queue ID”)
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.
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:
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.
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.
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:
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.
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.
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:
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:
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:
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ì:
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
Questo sito utilizza i cookie per migliorare la tua esperienza. Supponiamo che tu sia d'accordo con ciò, comunque puoi rinunciare all'uso dei cookie, se lo desideri.AcceptRejectRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
