1195 lines
44 KiB
Markdown
1195 lines
44 KiB
Markdown
---
|
|
title: Cybersecurity con sistemi GNU/Linux
|
|
subtitle: Dispensa del corso
|
|
author: Andrea Fazzi
|
|
data: 13.03.2024
|
|
urlcolor: blue
|
|
---
|
|
|
|
# Utilizzo avanzato del terminale
|
|
|
|
In questa sezione verranno discussi gli utilizzi più avanzati del
|
|
terminale. In particolare, ci si soffermerà sui cosidetti *terminal
|
|
multiplexer*.
|
|
|
|
## I *terminal multiplexer*
|
|
|
|
I terminal multiplexer in Linux sono strumenti potenti che consentono
|
|
agli utenti di creare più sessioni di terminale all'interno di una
|
|
singola finestra del terminale. Questi strumenti sono particolarmente
|
|
utili per gestire più processi contemporaneamente, mantenendo aperte
|
|
le sessioni anche dopo la disconnessione, e per organizzare le
|
|
finestre del terminale in modo efficiente.
|
|
|
|
Uno dei terminal multiplexer più popolari e ampiamente utilizzati è
|
|
`tmux`. `tmux` permette agli utenti di creare, gestire e navigare tra
|
|
più sessioni di terminale, facilitando l'organizzazione dei processi e
|
|
la gestione delle finestre. Con `tmux`, è possibile dividere la
|
|
finestra del terminale in più riquadri, ciascuno dei quali può
|
|
eseguire un processo separato, e passare facilmente da una sessione
|
|
all'altra.
|
|
|
|
Un altro esempio di terminal multiplexer è `screen`, che offre
|
|
funzionalità simili a `tmux` ma con una sintassi leggermente
|
|
diversa. Entrambi gli strumenti sono disponibili per la maggior parte
|
|
delle distribuzioni Linux e possono essere installati tramite il
|
|
gestore di pacchetti della distribuzione.
|
|
|
|
Utilizzare un terminal multiplexer può migliorare notevolmente
|
|
l'efficienza e la produttività degli sviluppatori e degli
|
|
amministratori di sistema, consentendo di lavorare con più processi
|
|
contemporaneamente senza dover aprire molteplici finestre del
|
|
terminale.
|
|
|
|
### Riferimenti
|
|
|
|
1. [https://opensource.com/article/21/5/linux-terminal-multiplexer](https://opensource.com/article/21/5/linux-terminal-multiplexer)
|
|
|
|
## Introduzione a `tmux`
|
|
|
|
`tmux` è un potente strumento di gestione delle sessioni di terminale
|
|
in Linux. Permette agli utenti di creare, gestire e navigare tra più
|
|
sessioni di terminale all'interno di una singola finestra del
|
|
terminale. Questa funzionalità è particolarmente utile per
|
|
l'esecuzione di più programmi con una singola connessione, come quando
|
|
si effettua una connessione remota a una macchina utilizzando Secure
|
|
Shell (SSH) [1].
|
|
|
|
Per iniziare ad utilizzare `tmux`, basta digitare `tmux` nel
|
|
terminale. Questo comando avvia un server `tmux`, crea una sessione
|
|
predefinita (numero 0) con una singola finestra e si collega ad
|
|
essa. Una volta connessi a `tmux`, è possibile eseguire qualsiasi
|
|
comando o programma come si farebbe normalmente.
|
|
|
|
## Installazione di `tmux`
|
|
|
|
`tmux` è un'applicazione disponibile nel repository di `Arch
|
|
Linux`. Per installarla basterà utilizzare il comando `pacman`.
|
|
|
|
```bash
|
|
sudo pacman -S tmux
|
|
```
|
|
|
|
Per verificare che l'installazione sia andata a buon fine:
|
|
|
|
```bash
|
|
tmux -V
|
|
```
|
|
|
|
Il comando restituirà la versione installata.
|
|
|
|
### Riferimenti
|
|
|
|
1. https://www.redhat.com/sysadmin/introduction-tmux-linux
|
|
2. https://linuxhandbook.com/tmux/
|
|
3. https://hamvocke.com/blog/a-quick-and-easy-guide-to-tmux/
|
|
4. https://linuxize.com/post/getting-started-with-tmux/
|
|
5. https://linuxconfig.org/introduction-to-terminal-multiplexer-tmux
|
|
6. https://github.com/tmux/tmux/wiki/Getting-Started
|
|
7. https://www.howtogeek.com/671422/how-to-use-tmux-on-linux-and-why-its-better-than-screen/
|
|
8. https://opensource.com/article/17/2/quick-introduction-tmux
|
|
9. https://wiki.archlinux.org/title/Tmux
|
|
10. https://github.com/tmux/tmux/wiki
|
|
|
|
## Primi passi con `tmux`
|
|
|
|
Per eseguire `tmux` si dovrà semplicemente invocare il comando
|
|
all'interno di una sessione di terminale.
|
|
|
|
```bash
|
|
tmux
|
|
```
|
|
|
|
È possibile staccare la sessione `tmux` premendo `Ctrl+B` seguito da
|
|
`D`. `tmux` opera utilizzando una serie di scorciatoie da tastiera
|
|
(keybindings) attivate premendo la combinazione "prefisso". Di
|
|
default, il prefisso è `Ctrl+B`. Dopo di che, premere `D` per staccare
|
|
dalla sessione corrente. La sessione continua ad eseguire in
|
|
background anche dopo la disconnessione, permettendo di riprendere
|
|
dove si è lasciati quando si è pronti a riconnettersi al server e
|
|
riattaccarsi alla sessione esistente.
|
|
|
|
`tmux` fornisce una serie di scorciatoie da tastiera per eseguire
|
|
comandi rapidamente all'interno di una sessione `tmux`. Alcune delle
|
|
più utili includono:
|
|
|
|
- `Ctrl+B D` — Stacca dalla sessione corrente.
|
|
- `Ctrl+B %` — Suddividi la finestra in due pannelli orizzontalmente.
|
|
- `Ctrl+B "` — Suddividi la finestra in due pannelli verticalmente.
|
|
- `Ctrl+B` seguito da una freccia (sinistra, destra, su, giù) — Sposta tra i pannelli.
|
|
- `Ctrl+B X` — Chiudi il pannello.
|
|
- `Ctrl+B C` — Crea una nuova finestra.
|
|
- `Ctrl+B N` o `P` — Sposta alla finestra successiva o precedente.
|
|
- `Ctrl+B 0` (1,2...) — Sposta a una finestra specifica per numero.
|
|
- `Ctrl+B :` — Entra nella riga di comando per digitare
|
|
comandi. L'auto-completamento tramite tab è disponibile.
|
|
- `Ctrl+B ?` — Visualizza tutte le scorciatoie da tastiera. Premere `Q` per uscire.
|
|
- `Ctrl+B W` — Apre un pannello per navigare tra le finestre in più sessioni.
|
|
|
|
### Esercizio
|
|
|
|
Utilizza `tmux` per suddividere il terminale in due pannelli
|
|
verticali. Nel pannello di sinistra apri uno script in Python
|
|
utilizzando l'editor `nano`. Nel pannello di destra esegui il comando
|
|
`htop`. Se `htop` non è presente nel sistema, procedi con la sua
|
|
installazione attraverso il package manager `pacman`.
|
|
|
|
## Configurazione di `tmux`
|
|
|
|
Il file di configurazione di `tmux`, noto come `tmux.conf`, è un file
|
|
di testo che permette agli utenti di personalizzare l'ambiente di
|
|
lavoro di `tmux` secondo le proprie preferenze. Questo file può essere
|
|
posizionato in due luoghi principali:
|
|
|
|
- `~/.tmux.conf` per una configurazione specifica dell'utente corrente.
|
|
- `/etc/tmux.conf` per una configurazione globale, applicabile a tutti gli utenti del sistema.
|
|
|
|
Se il file `~/.tmux.conf` non esiste, può essere creato semplicemente
|
|
eseguendo il comando `touch ~/.tmux.conf` nel terminale. Questo creerà
|
|
un file di configurazione vuoto che può essere modificato per
|
|
aggiungere le impostazioni desiderate.
|
|
|
|
La configurazione di `tmux` può includere una vasta gamma di opzioni, tra cui:
|
|
|
|
- Cambio del prefisso di comando predefinito.
|
|
- Abilitazione della modalità mouse.
|
|
- Impostazione di due prefissi.
|
|
- Cambio del comportamento predefinito del server.
|
|
- Inizio del conteggio dei numeri delle finestre e dei pannelli (Base-Index) a 1.
|
|
- Modifica dello sfondo del pannello corrente.
|
|
- ...
|
|
|
|
Per esempio, per cambiare il prefisso di comando predefinito da
|
|
`Ctrl+B` a `Ctrl+A`, si potrebbe aggiungere la seguente riga al file
|
|
`tmux.conf`:
|
|
|
|
```
|
|
set-option -g prefix C-a
|
|
```
|
|
|
|
Dopo aver apportato modifiche al file di configurazione, è necessario
|
|
ricaricarlo per applicare le nuove impostazioni. Questo può essere
|
|
fatto eseguendo il comando `tmux source-file ~/.tmux.conf` dal
|
|
terminale o utilizzando il comando `source-file ~/.tmux.conf` dalla
|
|
modalità di comando di `tmux`. Per facilitare il processo, è possibile
|
|
aggiungere un collegamento rapido nel file `tmux.conf` per ricaricare
|
|
facilmente la configurazione:
|
|
|
|
```
|
|
bind r source-file ~/.tmux.conf \; display "Reloaded!"
|
|
```
|
|
|
|
Questo permette di ricaricare la configurazione premendo il prefisso
|
|
seguito da `r`, visualizzando un messaggio di conferma.
|
|
|
|
### Riferimenti
|
|
|
|
1. https://hamvocke.com/blog/a-guide-to-customizing-your-tmux-conf/
|
|
2. https://www.hostinger.com/tutorials/tmux-config
|
|
3. https://dev.to/iggredible/useful-tmux-configuration-examples-k3g
|
|
4. https://github.com/gpakosz/.tmux
|
|
5. https://arcolinux.com/everthing-you-need-to-know-about-tmux-configuration/
|
|
6. https://thevaluable.dev/tmux-config-mouseless/
|
|
7. https://github.com/samoshkin/tmux-config
|
|
8. https://wiki.archlinux.org/title/tmux
|
|
9. https://medium.com/@bhavik.n/customize-tmux-to-use-it-effectively-28b262c8b692
|
|
|
|
## Creazione di layout personalizzati
|
|
|
|
Si supponga di voler creare un file di configurazione specifico per un
|
|
progetto in cui il terminale viene diviso in tre parti: due colonne
|
|
verticali di cui una a sua volta suddivisa orizzontalmente. In questo
|
|
caso è possibile utilizzare uno script di configurazione
|
|
personalizzato per `tmux`. Questo script può essere salvato in un file
|
|
separato, ad esempio in `~/.config/tmux/split.conf`.
|
|
|
|
```
|
|
new -s splitted_session # crea una nuova sessione
|
|
|
|
selectp -t 0 # seleziona il primo pannello
|
|
splitw -h # divide il pannello corrente orizzontalmente in due parti
|
|
|
|
selectp -t 1 # seleziona il nuovo secondo pannello
|
|
splitw -v # divide il pannello corrente verticalmente in due parti
|
|
selectp -t 0 # torna al primo pannello
|
|
```
|
|
|
|
Una volta creato il file di configurazione, occorrerà "eseguirlo" con
|
|
|
|
```bash
|
|
tmux source-file ~/.config/tmux/split.conf
|
|
```
|
|
|
|
### Esercizio
|
|
|
|
Crea un file di configurazione `tmux` per produrre un layout con due
|
|
righe di cui la prima suddivisa in due colonne secondo uno schema
|
|
simile a quello riportato sotto.
|
|
|
|
|
|
```
|
|
-----------
|
|
| | |
|
|
| | |
|
|
-----------
|
|
| |
|
|
| |
|
|
-----------
|
|
```
|
|
# Secure Shell
|
|
|
|
Il protocollo SSH (Secure Shell) è un protocollo di rete che fornisce
|
|
una connessione sicura e crittografata tra due sistemi informatici su
|
|
una rete non sicura. OpenSSH è una delle implementazioni più comuni di
|
|
SSH, che offre una serie di strumenti per la gestione delle chiavi
|
|
SSH, l'autenticazione e la sicurezza delle connessioni.
|
|
|
|
## Comando `ssh`
|
|
|
|
Il comando `ssh` è utilizzato per stabilire una connessione sicura con
|
|
un server remoto. Ad esempio, per connettersi a un server remoto con
|
|
l'indirizzo IP `192.168.1.100` come utente `utente`, il comando è:
|
|
|
|
```bash
|
|
ssh utente@192.168.1.100
|
|
```
|
|
|
|
Questo comando avvia una sessione SSH con il server specificato,
|
|
richiedendo l'autenticazione dell'utente.
|
|
|
|
## Comando `ssh-keygen`
|
|
|
|
`ssh-keygen` è uno strumento per generare una coppia di chiavi
|
|
pubbliche/private per l'autenticazione SSH. Per generare una nuova
|
|
chiave SSH, si può eseguire il comando `ssh-keygen` come nell'esempio sotto
|
|
|
|
```bash
|
|
ssh-keygen -t rsa
|
|
```
|
|
|
|
Agendo sulle opzioni del comando, si può specificare un percorso per
|
|
salvare la chiave impostare una passphrase per la chiave privata per
|
|
una maggioreq sicurezza.
|
|
|
|
```bash
|
|
ssh-keygen -t rsa -b 2048 -f ~/.ssh/mykey
|
|
```
|
|
|
|
Questo comando genera una chiave RSA di 2048 bit e la salva nel file
|
|
`~/.ssh/mykey`. La chiave pubblica corrispondente sarà salvata in
|
|
`~/.ssh/mykey.pub`.
|
|
|
|
## Comando `ssh-copy-id`
|
|
|
|
`ssh-copy-id` è uno strumento che copia la chiave pubblica SSH di un
|
|
utente in un server remoto, consentendo l'accesso senza password. Per
|
|
copiare la chiave pubblica `mykey.pub` dell'utente corrente al server
|
|
`192.168.1.100`, il comando è:
|
|
|
|
```bash
|
|
ssh-copy-id -i ~/.ssh/mykey.pub utente@192.168.1.100
|
|
```
|
|
|
|
Questo comando copia la chiave pubblica nel file
|
|
`~/.ssh/authorized_keys` dell'utente remoto, consentendo l'accesso
|
|
senza password. Dopo aver copiato la chiave, è possibile testare
|
|
l'accesso senza password con:
|
|
|
|
```bash
|
|
ssh -i ~/.ssh/mykey utente@192.168.1.100
|
|
```
|
|
|
|
I nomi di default per le chiavi pubbliche e private sono
|
|
rispettivamente `id_rsa.pub` e `id_rsa`. Utilizzando queste chiavi,
|
|
l'accesso al server senza password si semplifica. Basterà infatti
|
|
eseguire
|
|
|
|
```bash
|
|
ssh utente@192.168.1.100
|
|
```
|
|
|
|
## Mobile Shell (mosh)
|
|
|
|
Mosh, acronimo di Mobile Shell, è un'applicazione di terminale remoto
|
|
che risolve i problemi di connettività tipici di SSH, specialmente su
|
|
reti mobili o instabili. A differenza di SSH, che utilizza TCP e
|
|
richiede una connessione stabile, Mosh utilizza UDP, che è un
|
|
protocollo senza connessione, permettendo una connessione più stabile
|
|
e reattiva anche in presenza di interruzioni temporanee della
|
|
connessione. Mosh mantiene una connessione attiva attraverso
|
|
cambiamenti di indirizzo IP e sospensioni del dispositivo, rendendolo
|
|
ideale per l'uso su dispositivi mobili.
|
|
|
|
### Come funziona Mosh
|
|
|
|
Mosh inizia stabilendo una connessione SSH per l'autenticazione,
|
|
utilizzando le stesse credenziali di SSH (ad esempio, password o
|
|
chiavi pubbliche). Successivamente, avvia un server Mosh sul
|
|
dispositivo remoto e stabilisce una connessione UDP per la
|
|
comunicazione. Questo approccio consente a Mosh di gestire meglio la
|
|
perdita di pacchetti e di mantenere una connessione attiva anche in
|
|
presenza di interruzioni temporanee della rete.
|
|
|
|
### Vantaggi di Mosh rispetto a SSH
|
|
|
|
- **Robustezza e Responsività**: Mosh è più robusto e reattivo
|
|
rispetto a SSH, soprattutto su connessioni Wi-Fi, cellulari e lunghe
|
|
distanze. Questo è dovuto al suo protocollo basato su UDP che
|
|
gestisce meglio la perdita di pacchetti e imposta il tasso di
|
|
fotogrammi in base alle condizioni della rete.
|
|
- **Eco Locale Intelligente**: Mosh fornisce un eco locale speculativo
|
|
delle pressioni dei tasti, permettendo all'utente di vedere le
|
|
proprie pressioni dei tasti quasi istantaneamente, senza attendere
|
|
il round trip di rete. Questo migliora l'esperienza utente,
|
|
specialmente su connessioni ad alta latenza.
|
|
- **Supporto per Roaming**: Mosh supporta il roaming, permettendo
|
|
all'utente di cambiare la propria posizione fisica senza
|
|
interrompere la sessione. Questo è particolarmente utile per gli
|
|
utenti mobili che si spostano tra diversi luoghi.
|
|
|
|
### Esempi
|
|
|
|
Per connettersi a un server remoto utilizzando Mosh, il comando è
|
|
simile a quello di SSH, ma utilizzando `mosh` al posto di `ssh`. Ad
|
|
esempio:
|
|
|
|
```bash
|
|
mosh utente@host
|
|
```
|
|
|
|
E' possibile utilizzare `mosh` e `tmux` insieme. Ad esempio, con la
|
|
seguente linea di comando è possibile connettersi al server remoto ed
|
|
eseguire tmux.
|
|
|
|
```bash
|
|
mosh utente@host -- tmux
|
|
```
|
|
|
|
## Riferimenti
|
|
|
|
- [1] https://www.ssh.com/academy/ssh/copy-id
|
|
- [2] https://www.techtarget.com/searchsecurity/tutorial/Use-ssh-keygen-to-create-SSH-key-pairs-and-more
|
|
- [3] https://alexhost.com/faq/using-ssh-copy-id-ssh-keygen-commands-in-linux/
|
|
- [4] https://www.ssh.com/academy/ssh/keygen
|
|
- [5] https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys
|
|
- [6] https://docs.oracle.com/en/operating-systems/oracle-linux/openssh/openssh-WorkingwithSSHKeyPairs.html
|
|
- [7] https://www.redhat.com/sysadmin/configure-ssh-keygen
|
|
- [8] https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server
|
|
- [9] https://www.thegeekstuff.com/2008/11/3-steps-to-perform-ssh-login-without-password-using-ssh-keygen-ssh-copy-id/
|
|
- [10] https://mosh.org/
|
|
|
|
### Esercizio
|
|
|
|
### Prerequisiti
|
|
|
|
Installa un server OpenSSH e assicurati di poter effettuare
|
|
l'accesso. Crea un file layout.conf che funga da configurazione per
|
|
una sessione tmux. La configurazione deve prevedere una qualche
|
|
suddivisione della finestra. L'accesso via ssh dev'essere senza password.
|
|
|
|
### Obiettivo
|
|
|
|
Effettuando un ssh da locale verso locale, una volta effettuato
|
|
l'acccesso, la sessione tmux dev'essere automaticamente avviata.
|
|
|
|
# Introduzione a `systemd`
|
|
|
|
Systemd è un sistema di inizializzazione e gestione dei servizi per
|
|
Linux, che sostituisce il tradizionale SysVinit. È progettato per
|
|
essere il punto di partenza per il sistema operativo, gestendo l'avvio
|
|
dei servizi, la gestione delle sessioni utente, la configurazione di
|
|
rete e molto altro. In Arch Linux, systemd è l'impostazione
|
|
predefinita e viene utilizzato per gestire l'avvio del sistema e i
|
|
servizi.
|
|
|
|
Systemd utilizza i "target" per raggruppare le unità insieme tramite
|
|
dipendenze e come punti di sincronizzazione standardizzati. Questi
|
|
servono uno scopo simile ai runlevel di SysVinit ma agiscono
|
|
leggermente diversamente. Ogni target è nominato invece di essere
|
|
numerato e serve uno scopo specifico con la possibilità di avere più
|
|
attivi allo stesso tempo.
|
|
|
|
## Riferimenti
|
|
|
|
- [1] https://wiki.archlinux.org/title/systemd
|
|
- [2] https://bbs.archlinux.org/viewtopic.php?id=214188
|
|
- [3] https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/
|
|
- [4] https://stackoverflow.com/questions/10297969/systemd-on-arch-linux
|
|
- [5] https://wiki.archlinux.org/title/Systemd/User
|
|
- [6] https://superuser.com/questions/1025091/start-a-systemd-user-service-at-boot
|
|
- [7] https://halestrom.net/darksleep/blog/005_distrohop_p1/
|
|
- [8] https://www.youtube.com/watch?v=M51mbTRyL6U
|
|
|
|
## Gestione di `systemd`
|
|
|
|
`systemctl` è il comando principale utilizzato per esaminare e
|
|
controllare lo stato di `systemd` in un sistema Arch Linux. Questo
|
|
strumento è fondamentale per la gestione dei servizi e delle unità del
|
|
sistema. Ecco alcuni esempi di utilizzo di `systemctl`:
|
|
|
|
### Avvio e Arresto di Servizi
|
|
|
|
Per avviare un servizio, ad esempio `sshd`, si utilizza:
|
|
|
|
```bash
|
|
sudo systemctl start sshd
|
|
```
|
|
|
|
Per fermare lo stesso servizio:
|
|
|
|
```bash
|
|
sudo systemctl stop sshd
|
|
```
|
|
|
|
### Abilitazione e Disabilitazione di Servizi all'Avvio
|
|
|
|
Per abilitare un servizio all'avvio del sistema:
|
|
|
|
```bash
|
|
sudo systemctl enable sshd
|
|
```
|
|
|
|
Per disabilitare l'avvio automatico del servizio:
|
|
|
|
```bash
|
|
sudo systemctl disable sshd
|
|
```
|
|
|
|
### Controllo dello Stato dei Servizi
|
|
|
|
Per controllare lo stato corrente di un servizio:
|
|
|
|
```bash
|
|
systemctl status sshd
|
|
```
|
|
|
|
### Gestione dei Target
|
|
|
|
I target in systemd rappresentano stati di sistema o configurazioni
|
|
specifiche. Per vedere il target corrente:
|
|
|
|
```bash
|
|
systemctl get-default
|
|
```
|
|
|
|
Per cambiare il target di default al prossimo avvio:
|
|
|
|
```bash
|
|
sudo systemctl set-default multi-user.target
|
|
```
|
|
|
|
### Utilizzo di systemctl su una macchina remota
|
|
|
|
È possibile utilizzare `systemctl` per controllare un'istanza di
|
|
`systemd` su una macchina remota tramite SSH:
|
|
|
|
```bash
|
|
systemctl -H user@host status sshd
|
|
```
|
|
|
|
### Diagnostica dei servizi
|
|
|
|
Per visualizzare i servizi che hanno manifestato problemi alla partenza:
|
|
|
|
```bash
|
|
systemctl --state=failed
|
|
```
|
|
|
|
### Riferimenti
|
|
|
|
- [1] https://wiki.archlinux.org/title/systemd
|
|
- [2] https://man.archlinux.org/man/systemctl.1.en
|
|
- [3] https://wiki.archlinux.org/title/Systemd/User
|
|
- [4] https://bbs.archlinux.org/viewtopic.php?id=260255
|
|
- [5] https://gist.github.com/bugyt/c149de4ba5b1ea79a077
|
|
- [6] https://superuser.com/questions/1025091/start-a-systemd-user-service-at-boot
|
|
- [7] https://wiki.archlinux.org/title/systemd/Timers
|
|
- [8] https://www.reddit.com/r/linux4noobs/comments/18fklyi/using_systemd_to_automatically_run_commands_on/
|
|
- [9] https://stackoverflow.com/questions/10297969/systemd-on-arch-linux
|
|
- [10] https://man.archlinux.org/man/systemd.unit.5.en
|
|
|
|
## Utilizzo di `journalctl`
|
|
|
|
`journalctl` è uno strumento potente per la gestione dei log in
|
|
sistemi che utilizzano `systemd`, come Arch Linux. Questo strumento
|
|
consente di visualizzare, filtrare e analizzare i messaggi di log
|
|
generati dal sistema e dai servizi. Ecco alcuni esempi notevoli di
|
|
utilizzo di `journalctl`:
|
|
|
|
### Visualizzazione dei Log
|
|
|
|
Per visualizzare tutti i messaggi di log:
|
|
|
|
```bash
|
|
journalctl
|
|
```
|
|
|
|
### Filtraggio dei Messaggi di Log
|
|
|
|
- Per visualizzare tutti i messaggi che corrispondono a un pattern specifico:
|
|
|
|
```bash
|
|
journalctl --grep=PATTERN
|
|
```
|
|
|
|
- Per visualizzare tutti i messaggi dal boot corrente:
|
|
|
|
```bash
|
|
journalctl -b
|
|
```
|
|
|
|
- Per visualizzare i messaggi dal boot precedente:
|
|
|
|
```bash
|
|
journalctl -b -1
|
|
```
|
|
|
|
- Per visualizzare i messaggi da una data specifica:
|
|
|
|
```bash
|
|
journalctl --since="2022-01-01"
|
|
```
|
|
|
|
- Per visualizzare i messaggi degli ultimi 20 minuti:
|
|
|
|
```bash
|
|
journalctl --since "20 min ago"
|
|
```
|
|
|
|
### Seguire i nuovi messaggi
|
|
|
|
Per seguire i nuovi messaggi di log in tempo reale:
|
|
|
|
```bash
|
|
journalctl -f
|
|
```
|
|
|
|
### Visualizzazione per Unità di Servizio
|
|
|
|
- Per visualizzare tutti i messaggi per un servizio specifico, ad esempio `httpd`:
|
|
|
|
```bash
|
|
journalctl -u httpd.service
|
|
```
|
|
|
|
- Per visualizzare i messaggi di log per un'unità utente specifica, ad esempio `dbus`:
|
|
|
|
```bash
|
|
journalctl --user -u dbus
|
|
```
|
|
|
|
### Visualizzazione dei Messaggi di Errore
|
|
|
|
Per visualizzare solo i messaggi di errore, critico e allarme:
|
|
|
|
```bash
|
|
journalctl -p err..alert
|
|
```
|
|
|
|
### Visualizzazione del Buffer del Kernel
|
|
|
|
Per visualizzare i messaggi del buffer del kernel:
|
|
|
|
```bash
|
|
journalctl -k
|
|
```
|
|
|
|
### Visualizzazione dei Log in un File Specifico
|
|
|
|
Se il directory dei log contiene una grande quantità di dati di log,
|
|
`journalctl` può richiedere diversi minuti per filtrare l'output. Può
|
|
essere significativamente velocizzato utilizzando l'opzione `--file`
|
|
per forzare `journalctl` a cercare solo nel journal più recente:
|
|
|
|
```bash
|
|
journalctl --file /var/log/journal/*/system.journal -f
|
|
```
|
|
|
|
### Esercizio
|
|
|
|
Utilizzando il terminal multiplexer `tmux` suddividi il terminale in
|
|
due pannelli. Nel pannello di sinistra esegui `journalctl` in modo da
|
|
visualizzare i log del servizio `sshd`. Nel pannello di destra
|
|
connettiti al server ssh in esecuzione sulla tua macchina. Qualora il
|
|
servizio non fosse in esecuzione, fallo partire utilizzando
|
|
`systemctl`. Salva una porzione dei log in un file di testo come prova
|
|
di aver svolto l'esercizio.
|
|
|
|
### Riferimenti
|
|
|
|
- [1] https://wiki.archlinux.org/title/Systemd/Journal
|
|
- [2] https://man.archlinux.org/man/journalctl.1.en
|
|
- [3] https://www.debugpoint.com/systemd-journalctl/
|
|
- [4] https://serverfault.com/questions/721963/how-do-you-use-systemds-journalctl-patterns
|
|
- [5] https://www.loggly.com/ultimate-guide/using-journalctl/
|
|
- [6] https://bbs.archlinux.org/viewtopic.php?id=208480
|
|
- [7] https://unix.stackexchange.com/questions/199988/how-to-inspect-systemd-journal-files-directly
|
|
- [8] https://kb.adamsdesk.com/operating_system/arch_linux_quick_reference_commands/
|
|
- [9] https://www.reddit.com/r/archlinux/comments/lskkdt/always_check_your_journalctl_when_weird_problems/
|
|
- [10] https://wiki.archlinux.org/title/systemd
|
|
|
|
## Timer di `systemd`
|
|
|
|
`systemd/Timers` in Arch Linux sono unità di sistema che permettono di
|
|
pianificare l'esecuzione di servizi o eventi in base a specifici
|
|
intervalli di tempo o eventi di sistema. Questi timer possono essere
|
|
utilizzati come alternativa a `cron` per la pianificazione di
|
|
attività. I timer di `systemd` supportano eventi di tempo calendario e
|
|
monotonici, e possono essere eseguiti in modo asincrono.
|
|
|
|
### Tipi di Timer
|
|
|
|
- **Timer Realtime (o Wallclock Timers)**: Attivano un evento in base
|
|
a un calendario, similmente a come funzionano i cronjobs. Utilizzano
|
|
l'opzione `OnCalendar=` per definire l'evento.
|
|
- **Timer Monotonici**: Attivano dopo un intervallo di tempo relativo
|
|
a un punto di partenza variabile. Si fermano se il computer viene
|
|
sospeso temporaneamente o spento. Esempi comuni includono
|
|
`OnBootSec` e `OnUnitActiveSec` [1].
|
|
|
|
### Creazione di un Timer
|
|
|
|
Per creare un timer, è necessario creare un file di unità con
|
|
estensione `.timer` che descriva quando e come il timer deve attivare
|
|
un'unità di servizio corrispondente. Ad esempio, per creare un timer
|
|
che esegue un servizio ogni giorno alle 12:00, il file del timer
|
|
potrebbe essere simile a questo:
|
|
|
|
```ini
|
|
[Unit]
|
|
Description=Esegui il mio servizio giornaliero
|
|
|
|
[Timer]
|
|
OnCalendar=daily
|
|
Persistent=true
|
|
|
|
[Install]
|
|
WantedBy=timers.target
|
|
```
|
|
|
|
E il file del servizio corrispondente potrebbe essere:
|
|
|
|
```ini
|
|
[Unit]
|
|
Description=Il mio servizio giornaliero
|
|
|
|
[Service]
|
|
ExecStart=/path/to/my-service
|
|
```
|
|
|
|
La sintassi `OnCalendar` in `systemd` è utilizzata per specificare
|
|
quando un timer deve essere attivato, offrendo una maggiore
|
|
flessibilità rispetto al formato cron tradizionale. La sintassi
|
|
`OnCalendar` segue il formato `DOW YYYY-MM-DD HH:MM:SS`, dove `DOW` è
|
|
il giorno della settimana (opzionale), e gli altri campi possono
|
|
utilizzare un asterisco (`*`) per corrispondere a qualsiasi valore per
|
|
quella posizione. Se l'ora non è specificata, viene assunta come
|
|
`00:00:00`. Se la data non è specificata ma l'ora è, il prossimo match
|
|
potrebbe essere oggi o domani, a seconda dell'ora corrente [5].
|
|
|
|
Ecco alcuni esempi di come utilizzare `OnCalendar`:
|
|
|
|
- Per eseguire un evento ogni giorno alle 10:00, puoi usare:
|
|
```ini
|
|
OnCalendar=*-*-* 10:00:00
|
|
```
|
|
- Per eseguire un evento ogni anno il 15 ottobre alle 17:48:00, puoi usare:
|
|
```ini
|
|
OnCalendar=*-10-15 17:48:00
|
|
```
|
|
- Per eseguire un evento ogni anno il 1 gennaio alle 00:00:00, puoi usare:
|
|
```ini
|
|
OnCalendar=*-01-01 00:00:00
|
|
```
|
|
- Puoi anche combinare questi campi per specificare eventi più
|
|
precisi. Ad esempio, per eseguire un evento ogni mercoledì alle
|
|
17:48:00, puoi usare:
|
|
|
|
```ini
|
|
OnCalendar=Wed *-*-* 17:48:00
|
|
```
|
|
Questo può anche essere scritto come:
|
|
```ini
|
|
OnCalendar=3Wed, 17:48
|
|
```
|
|
|
|
Sì, `OnCalendar` in `systemd` ammette alias come "daily" per
|
|
specificare intervalli di tempo più comuni. Questo alias può essere
|
|
utilizzato per semplificare la pianificazione di eventi ricorrenti. Ad
|
|
esempio, per eseguire un evento ogni giorno, puoi semplicemente
|
|
utilizzare:
|
|
|
|
```ini
|
|
OnCalendar=daily
|
|
```
|
|
|
|
Questo è equivalente a specificare l'evento per ogni giorno alle
|
|
00:00:00. Altri alias comuni includono "weekly", "monthly", "yearly",
|
|
e specifici giorni della settimana come "Mon", "Tue", "Wed", ecc.
|
|
|
|
Per esempio, per eseguire un evento ogni lunedì alle 10:00, potresti
|
|
usare:
|
|
|
|
```ini
|
|
OnCalendar=Mon 10:00:00
|
|
```
|
|
|
|
O per eseguire un evento ogni settimana, potresti usare:
|
|
|
|
```ini
|
|
OnCalendar=weekly
|
|
```
|
|
|
|
Questi alias rendono più semplice e leggibile la configurazione dei
|
|
timer in `systemd`, specialmente per intervalli di tempo ricorrenti
|
|
comuni [4].
|
|
|
|
`systemd` offre strumenti come `systemd-analyze calendar` per validare
|
|
e esaminare gli eventi del calendario utilizzati in
|
|
un'espressione. Questo strumento analizza un'espressione di evento del
|
|
calendario e fornisce la forma normalizzata e altre informazioni, come
|
|
la data e l'ora del prossimo "elapso" (cioè, corrispondenza) e la
|
|
quantità approssimativa di tempo prima che raggiunga il tempo di
|
|
attivazione [5].
|
|
|
|
### Gestione dei Timer
|
|
|
|
Per abilitare e avviare un timer, utilizza i comandi `systemctl
|
|
enable` e `systemctl start`, ricordando di aggiungere il suffisso
|
|
`.timer` al nome dell'unità. Per visualizzare tutti i timer attivi,
|
|
esegui:
|
|
|
|
```bash
|
|
systemctl list-timers
|
|
```
|
|
|
|
Per elencare tutti i timer (inclusi quelli inattivi), usa:
|
|
|
|
```bash
|
|
systemctl list-timers --all
|
|
```
|
|
|
|
Se un timer si sincronizza, potrebbe essere utile eliminare il suo
|
|
file `stamp-*` in `/var/lib/systemd/timers` (o
|
|
`~/.local/share/systemd/` nel caso dei timer utente). Questi file di
|
|
lunghezza zero contrassegnano l'ultima volta in cui ogni timer è stato
|
|
eseguito. Se vengono eliminati, verranno ricostruiti al prossimo avvio
|
|
del loro timer [1].
|
|
|
|
### Esempi di Utilizzo
|
|
|
|
Per impostare un timer che effettui il backup della cartella home ogni
|
|
mattina alle 10:00, e che si assicuri che il backup venga effettuato
|
|
anche se il PC è spento, segui questi passaggi. Questo esempio
|
|
utilizza un timer e un servizio di `systemd` per eseguire il backup.
|
|
|
|
#### Creazione del Servizio
|
|
|
|
Prima di tutto, crea un file di servizio che eseguirà il backup. Puoi
|
|
chiamarlo `home-backup.service` e metterlo in `/etc/systemd/system/`
|
|
per un backup a livello di sistema, o in `~/.config/systemd/user/` per
|
|
un backup a livello utente.
|
|
|
|
```ini
|
|
[Unit]
|
|
Description=Backup della cartella home
|
|
|
|
[Service]
|
|
Type=oneshot
|
|
ExecStart=/path/to/your/backup-script.sh
|
|
```
|
|
|
|
Assicurati che lo script di backup (`/path/to/your/backup-script.sh`)
|
|
sia eseguibile e che contenga i comandi necessari per il backup.
|
|
|
|
#### Creazione del Timer
|
|
|
|
Successivamente, crea un file di timer che attiverà il servizio sopra
|
|
ogni mattina alle 10:00. Anche questo file va in
|
|
`/etc/systemd/system/` per un backup a livello di sistema, o in
|
|
`~/.config/systemd/user/` per un backup a livello utente. Chiamalo
|
|
`home-backup.timer`.
|
|
|
|
```ini
|
|
[Unit]
|
|
Description=Timer per il backup della cartella home
|
|
|
|
[Timer]
|
|
OnCalendar=*-*-* 10:00:00
|
|
Persistent=true
|
|
|
|
[Install]
|
|
WantedBy=timers.target
|
|
```
|
|
|
|
L'opzione `Persistent=true` assicura che il timer si attivi non appena
|
|
il sistema è avviato, anche se il tempo previsto per l'esecuzione è
|
|
passato.
|
|
|
|
#### Abilitazione e Avvio del Timer
|
|
|
|
Per abilitare il timer, esegui:
|
|
|
|
```bash
|
|
sudo systemctl enable home-backup.timer
|
|
```
|
|
|
|
E per avviare il timer immediatamente, senza doverlo abilitare:
|
|
|
|
```bash
|
|
sudo systemctl start home-backup.timer
|
|
```
|
|
|
|
Se stai creando un timer a livello utente, sostituisci `sudo` con
|
|
`--user` nei comandi sopra.
|
|
|
|
#### Verifica
|
|
|
|
Per verificare che il timer sia attivo e pianificato correttamente,
|
|
puoi usare:
|
|
|
|
```bash
|
|
systemctl list-timers
|
|
```
|
|
|
|
Questo mostrerà tutti i timer attivi, inclusi quelli pianificati per
|
|
il futuro.
|
|
|
|
#### Considerazioni
|
|
|
|
- Assicurati che lo script di backup sia configurato correttamente e
|
|
che abbia i permessi necessari per eseguire il backup.
|
|
- Se il tuo sistema è spento quando il timer dovrebbe attivarsi, il
|
|
timer si attiverà al prossimo avvio del sistema, grazie all'opzione
|
|
`Persistent=true`.
|
|
- Ricorda che i timer a livello utente richiedono che l'utente sia
|
|
loggato per funzionare, a meno che non sia configurato per "linger"
|
|
con `loginctl enable-linger $USER`.
|
|
|
|
Questo metodo ti permette di pianificare il backup della cartella home
|
|
ogni mattina alle 10:00, garantendo che il backup venga effettuato
|
|
anche se il PC è spento al momento previsto per il backup [1].
|
|
|
|
### Riferimenti
|
|
|
|
- [1] https://wiki.archlinux.org/title/Systemd/Timers
|
|
- [2] https://linuxconfig.org/how-to-schedule-tasks-with-systemd-timers-in-linux
|
|
- [3] https://www.airplane.dev/blog/systemd-timer-how-to-schedule-tasks-with-systemd
|
|
- [4] https://man.archlinux.org/man/systemd.timer.5
|
|
- [5] https://opensource.com/article/20/7/systemd-timers
|
|
- [6] https://wiki.archlinux.org/title/Systemd
|
|
- [7] https://lloydrochester.com/post/unix/systemd-timer-example/
|
|
- [8] https://unix.stackexchange.com/questions/704109/configure-systemd-timer-to-run-every-hour-after-first-run
|
|
- [9] https://linuxman.co/linux-desktop/easily-automate-maintenance-in-arch-linux-with-the-power-of-systemd-timers/
|
|
- [10] https://www.fosslinux.com/48317/scheduling-tasks-systemd-timers-linux.htm
|
|
- [11] https://www.binaryte.com/blog/systemd-timers-tutorial-for-scheduling-tasks
|
|
- [12] https://www.learnlinux.tv/automate-your-tasks-with-systemd-timers-a-step-by-step-guide/
|
|
- [13] https://blog.devgenius.io/devops-in-linux-systemd-timer-4e95f57b6d71
|
|
- [14] https://dashdash.io/5/systemd.timer
|
|
- [15] https://techviewleo.com/configuring-cron-jobs-in-linux-using-systemd-timers/
|
|
|
|
# Linux hardening
|
|
|
|
Il "Linux Hardening" è un processo fondamentale per migliorare la
|
|
sicurezza dei sistemi Linux, riducendo la superficie di attacco e
|
|
limitando i danni che possono essere causati da attacchi
|
|
informatici. Questo processo coinvolge l'ottimizzazione della
|
|
configurazione del sistema per operazioni sicure e la protezione dei
|
|
dati, seguendo tre regole principali: rimuovere funzionalità non
|
|
necessarie, applicare patch e aggiornamenti tempestivamente e
|
|
mantenere impostazioni di configurazione sicure [2].
|
|
|
|
Linux Hardening è essenziale perché i sistemi Linux, specialmente
|
|
quelli preinstallati, spesso vengono forniti con configurazioni
|
|
predefinite che potrebbero non essere ottimizzate per la
|
|
sicurezza. Questo include credenziali predefinite, configurazioni non
|
|
ottimizzate e software non aggiornato, che rappresentano potenziali
|
|
punti di ingresso per gli attaccanti [3].
|
|
|
|
Il processo di hardening richiede un'attenta considerazione delle
|
|
componenti del sistema, comprese le impostazioni di sicurezza
|
|
specifiche per ciascuna, e l'implementazione di misure proattive per
|
|
prevenire attività malevole. Questo può includere l'uso di benchmark
|
|
dell'industria, come quelli forniti dal Center for Internet Security
|
|
(CIS) e dal Security Technical Implementation Guide (STIG), per
|
|
guidare le configurazioni sicure [1][2].
|
|
|
|
## Riferimenti
|
|
|
|
- [1] https://github.com/trimstray/the-practical-linux-hardening-guide#:~:text=Simply%20speaking%2C%20hardening%20is%20the,suspicious%20activity%20in%20the%20future.
|
|
- [2] https://www.netwrix.com/linux_hardening_security_best_practices.html
|
|
- [3] https://cleverism.com/linux-hardening-how-its-done/
|
|
- [4] https://ubuntu.com/blog/what-is-system-hardening-definition-and-best-practices
|
|
- [5] https://mattiazignale.medium.com/introduction-to-linux-security-hardening-635af8e6e885
|
|
- [6] https://intezer.com/blog/cloud-security/top-10-linux-server-hardening-and-security-best-practices/
|
|
- [7] https://dev.to/terceranexus6/introduction-to-linux-hardening-5aj1
|
|
- [8] https://tuxcare.com/blog/linux-system-hardening-top-10-security-tips/
|
|
- [9] https://www.pluralsight.com/blog/it-ops/linux-hardening-secure-server-checklist
|
|
- [10] https://documentation.sas.com/doc/en/bimtag/9.4/p0xodkl4216thhn1g935xtu06bl2.htm
|
|
|
|
## Crittografia dei dischi
|
|
|
|
Il comando `cryptsetup` è uno strumento utilizzato per gestire la
|
|
crittografia dei dischi in Linux. Si utilizza principalmente per la
|
|
creazione, la gestione e l'accesso a volumi crittografati, come quelli
|
|
creati con LUKS (Linux Unified Key Setup). Questo strumento è
|
|
fondamentale per l'implementazione della crittografia a livello di
|
|
disco, consentendo agli utenti di proteggere i dati sensibili
|
|
memorizzati sui loro dispositivi di archiviazione.
|
|
|
|
Ecco alcuni esempi di utilizzo del comando `cryptsetup`:
|
|
|
|
1. **Creazione di un volume crittografato LUKS**: ```bash sudo
|
|
cryptsetup luksFormat /dev/sdX ``` Questo comando inizializza un
|
|
volume crittografato LUKS sul dispositivo specificato
|
|
(`/dev/sdX`). Dopo l'esecuzione, verrà richiesta una passphrase che
|
|
sarà necessaria per accedere al volume crittografato.
|
|
|
|
2. **Apertura di un volume crittografato LUKS**: ```bash sudo
|
|
cryptsetup luksOpen /dev/sdX my_encrypted_volume ``` Questo comando
|
|
apre il volume crittografato LUKS e lo rende accessibile tramite un
|
|
nome di dispositivo mappato, in questo caso
|
|
`my_encrypted_volume`. Dopo l'apertura, verrà richiesta la
|
|
passphrase precedentemente impostata.
|
|
|
|
3. **Chiusura di un volume crittografato LUKS**: ```bash sudo
|
|
cryptsetup luksClose my_encrypted_volume ``` Questo comando chiude
|
|
il volume crittografato LUKS, rendendolo non più accessibile.
|
|
|
|
4. **Decrittografia di un disco crittografato LUKS**:
|
|
```bash
|
|
sudo cryptsetup luksOpen /dev/sdX tmpData
|
|
sudo mount /dev/mapper/tmpData /mnt
|
|
```
|
|
Questo esempio mostra come decrittografare un disco crittografato LUKS e montarlo in un punto di montaggio specificato (`/mnt`). Dopo aver terminato l'uso del disco, è possibile smontarlo e chiudere il volume crittografato con i seguenti comandi:
|
|
```bash
|
|
sudo umount /mnt
|
|
sudo cryptsetup luksClose tmpData
|
|
```
|
|
|
|
Il comando `cryptsetup` è uno strumento potente e versatile che offre
|
|
una vasta gamma di opzioni per la gestione della crittografia dei
|
|
dischi in Linux. È particolarmente utile per chi desidera proteggere i
|
|
dati sensibili memorizzati sui propri dispositivi di archiviazione,
|
|
garantendo che siano accessibili solo a chi conosce la passphrase
|
|
corretta.
|
|
|
|
### Riferimenti
|
|
|
|
- [1] https://stackoverflow.com/questions/22617725/cryptsetup-offline-attack-with-list-of-known-keys-possible
|
|
- [2] https://askubuntu.com/questions/316486/problems-with-cryptsetup-during-update
|
|
- [3] https://www.reddit.com/r/pop_os/comments/n7qsqb/how_to_fix_cryptsetup_waiting_for_encrypted/
|
|
- [4] https://unix.stackexchange.com/questions/399620/how-to-decrypt-a-hard-drive-with-luks-encryption
|
|
- [5] https://oldforum.puppylinux.com/viewtopic.php?t=117274
|
|
- [6] https://forum.openwrt.org/t/cryptsetup-block-info-problem/70161
|
|
- [7] https://superuser.com/questions/431820/how-to-change-pass-phrase-of-full-disk-encryption
|
|
- [8] https://xo.tc/full-disk-encryption-on-linux.html
|
|
- [9] https://wiki.archlinux.org/title/Dm-crypt/Device_encryption
|
|
|
|
## Uncomplicated firewall (`ufw`)
|
|
|
|
UFW (Uncomplicated Firewall) è uno strumento di configurazione del
|
|
firewall che funziona sopra `iptables`. Fornisce un'interfaccia
|
|
semplificata per configurare casi d'uso comuni del firewall tramite la
|
|
riga di comando. UFW è progettato per rendere la configurazione del
|
|
firewall più semplice e intuitiva, rendendolo adatto anche per utenti
|
|
meno esperti.
|
|
|
|
### Come configurare un firewall con UFW
|
|
|
|
1. **Installazione di UFW**:
|
|
- Su Arch Linux, UFW può essere installato con il comando:
|
|
```bash
|
|
sudo pacman -S ufw
|
|
```
|
|
- Dopo l'installazione, è necessario avviare e abilitare il
|
|
servizio UFW: ```bash sudo systemctl start ufw sudo systemctl
|
|
enable ufw ``` Questo passaggio è particolarmente importante su
|
|
Arch Linux, dove UFW non viene avviato automaticamente [2].
|
|
|
|
2. **Abilitazione di UFW**:
|
|
- Per abilitare UFW e applicare le regole del firewall, esegui:
|
|
```bash
|
|
sudo ufw enable
|
|
```
|
|
- Se stai connettendoti tramite SSH, assicurati di consentire
|
|
l'accesso alla porta SSH (di solito la porta 22) per evitare di
|
|
bloccarti fuori dal server [4].
|
|
|
|
3. **Configurazione delle regole di default**:
|
|
- UFW blocca tutte le connessioni in entrata e consente tutte le connessioni in uscita di default. Puoi modificare queste regole di default con:
|
|
```bash
|
|
sudo ufw default deny incoming
|
|
sudo ufw default allow outgoing
|
|
```
|
|
- Questo significa che chiunque tenti di raggiungere il tuo server
|
|
non sarà in grado di connettersi, mentre qualsiasi applicazione
|
|
all'interno del server sarà in grado di connettersi esternamente
|
|
[4].
|
|
|
|
4. **Aggiunta di regole specifiche**:
|
|
- Puoi consentire o bloccare servizi specifici per porta, interfaccia di rete e indirizzo IP sorgente. Ad esempio, per consentire l'accesso SSH (porta 22) da qualsiasi luogo, usa:
|
|
```bash
|
|
sudo ufw allow 22
|
|
```
|
|
- Per bloccare l'accesso a una porta specifica, ad esempio la porta 80, usa:
|
|
```bash
|
|
sudo ufw deny 80
|
|
```
|
|
|
|
5. **Verifica dello stato di UFW**:
|
|
- Per vedere quali regole sono attualmente bloccate o consentite, puoi usare il parametro `verbose` con `ufw status`:
|
|
```bash
|
|
sudo ufw status verbose
|
|
```
|
|
|
|
6. **Disabilitazione di UFW**:
|
|
- Se per qualche motivo devi disabilitare UFW, puoi farlo con il comando:
|
|
```bash
|
|
sudo ufw disable
|
|
```
|
|
- Questo comando disabiliterà completamente il servizio del firewall sul tuo sistema [1].
|
|
|
|
UFW è uno strumento potente che può migliorare notevolmente la
|
|
sicurezza dei tuoi server quando configurato correttamente. La maggior
|
|
parte dei comandi in questa guida può essere adattata per adattarsi a
|
|
diversi casi d'uso e scenari, modificando parametri come l'indirizzo
|
|
IP sorgente e/o la porta di destinazione [1].
|
|
|
|
### Riferimenti
|
|
|
|
- [1] https://www.digitalocean.com/community/tutorials/ufw-essentials-common-firewall-rules-and-commands
|
|
- [2] https://www.linode.com/docs/guides/configure-firewall-with-ufw/
|
|
- [3] https://www.youtube.com/watch?v=XtRXm4FFK7Q
|
|
- [4] https://www.digitalocean.com/community/tutorials/how-to-setup-a-firewall-with-ufw-on-an-ubuntu-and-debian-cloud-server
|
|
- [5] https://www.cloud.it/tutorial/come-installare-e-configurare-ufw-firewall-su-ubuntu-18-04.aspx
|
|
- [6] https://www.cherryservers.com/blog/how-to-configure-ubuntu-firewall-with-ufw
|
|
- [7] https://www.zenarmor.com/docs/network-security-tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu
|
|
- [8] https://gmadv.it/it/sistemi-operativi/come-installare-e-configurare-ufw-su-ubuntu-20-04/
|
|
- [9] https://ioflood.com/blog/ufw-linux-command/
|
|
- [10] https://phoenixnap.com/kb/configure-firewall-with-ufw-on-ubuntu
|
|
- [11] https://wiki.archlinux.org/title/Uncomplicated_Firewall
|
|
|
|
# Linux backdoors
|
|
|
|
Le backdoor Linux sono codici nascosti, script o programmi che
|
|
consentono agli aggressori di accedere rapidamente e in modo
|
|
istantaneo al sistema senza doverlo compromettere nuovamente. Queste
|
|
possono essere nascoste in vari punti di un sistema Linux.
|
|
|
|
## Riferimenti
|
|
|
|
- [1] https://www.reddit.com/r/tryhackme/comments/mwx70e/official_walkthrough_linux_backdoors/
|
|
- [2] https://fahmifj.github.io/blog/linux-backdoors-and-where-to-find-them/
|
|
- [3] https://arstechnica.com/civis/threads/never-before-seen-linux-backdoor-is-a-windows-malware-knockoff.1495897/
|
|
- [4] https://security.stackexchange.com/questions/126399/finding-a-backdoor-on-a-server
|
|
- [5] https://www.infoq.com/news/2013/10/Linux-Backdoor/
|
|
|
|
# Linux privilege escalation
|
|
|
|
La privilege escalation in Linux si riferisce al processo di
|
|
acquisizione di privilegi di amministratore o di utente superuser su
|
|
un sistema operativo Linux. Questo può avvenire quando un utente con
|
|
privilegi limitati riesce a eseguire azioni che normalmente sarebbero
|
|
riservate a utenti con privilegi elevati, come l'amministratore del
|
|
sistema. La privilege escalation può essere il risultato di
|
|
vulnerabilità nel software, configurazioni errate, o l'uso improprio
|
|
di permessi.
|
|
|
|
Esistono vari metodi per eseguire una privilege escalation, tra cui:
|
|
|
|
- **Sfruttamento di vulnerabilità nel kernel**: Questo metodo sfrutta
|
|
le vulnerabilità nel kernel Linux per eseguire codice arbitrario con
|
|
privilegi elevati.
|
|
- **Sfruttamento di servizi e applicazioni**: Alcuni servizi o
|
|
applicazioni eseguono con privilegi elevati e possono essere
|
|
sfruttati per eseguire comandi come root.
|
|
- **Configurazioni errate**: Configurazioni errate nel sistema, come
|
|
permessi troppo permissivi su file o directory critiche, possono
|
|
permettere a un utente di eseguire azioni non autorizzate.
|
|
- **Uso improprio di permessi**: L'uso improprio di permessi, come
|
|
l'abilitazione di esecuzione di script o programmi non sicuri, può
|
|
portare a privilege escalation.
|
|
|
|
Per prevenire la privilege escalation, è importante mantenere il
|
|
sistema operativo e le applicazioni aggiornate, utilizzare
|
|
configurazioni sicure, e limitare i privilegi degli utenti al minimo
|
|
necessario per svolgere le loro funzioni. Inoltre, l'uso di strumenti
|
|
di sicurezza come firewalls, IDS/IPS, e sistemi di gestione delle
|
|
vulnerabilità può aiutare a identificare e mitigare le potenziali
|
|
vulnerabilità.
|
|
|
|
# Shell `zsh`
|
|
|
|
La shell `zsh` (Z shell) e `bash` (Bourne Again SHell) sono due shell
|
|
popolari utilizzate in ambienti Unix-like, come Linux e
|
|
macOS. Entrambe offrono una serie di funzionalità avanzate e sono
|
|
ampiamente utilizzate per la programmazione, l'automazione e la
|
|
gestione di sistemi. Ecco alcune delle differenze e analogie
|
|
principali tra `zsh` e `bash`:
|
|
|
|
## Caratteristiche Comuni
|
|
|
|
- **Funzionalità di Programmazione**: Entrambe le shell supportano
|
|
cicli, costrutti condizionali, espansioni di tilde e parentesi
|
|
graffe, e l'uso di alias. Queste funzionalità rendono entrambe le
|
|
shell potenti strumenti per la programmazione e l'automazione [2].
|
|
- **Interazione Generale**: I comandi e l'interazione generale tra
|
|
`bash` e `zsh` sono essenzialmente identici. La familiarità con una
|
|
shell può essere facilmente tradotta nell'altra senza affrontare una
|
|
ripida curva di apprendimento.
|
|
|
|
## Differenze Principali
|
|
|
|
- **Personalizzazione e Estensione**: `zsh`, grazie alla sua comunità
|
|
attiva, offre una vasta gamma di plugin e temi attraverso Oh My Zsh,
|
|
permettendo agli utenti di personalizzare ulteriormente la loro
|
|
shell. Questo include funzionalità come il completamento automatico
|
|
delle schede e l'espansione del percorso ricorsivo, che non sono
|
|
disponibili in `bash`.
|
|
- **Opzioni di Configurazione**: `zsh` utilizza `.zshrc` per le
|
|
impostazioni di configurazione dell'utente, simile a `.bashrc` per
|
|
`bash`. Tuttavia, `zsh` offre un livello di personalizzazione
|
|
integrato più avanzato, con molte più opzioni di shell esposte
|
|
rispetto a `bash`.
|
|
- **Shell Predefinita su macOS**: A partire da macOS Catalina, `zsh` è
|
|
stata adottata come shell predefinita, segnando un riconoscimento
|
|
ufficiale della comunità di sviluppatori di `zsh`.
|
|
|
|
## Analogie
|
|
|
|
- **Familiarità e Uso**: La familiarità con `bash` può facilitare
|
|
l'apprendimento di `zsh`, poiché molte delle funzionalità e dei
|
|
comandi sono simili. Questo rende il passaggio tra le due shell
|
|
relativamente semplice.
|
|
- **Supporto e Risorse**: Entrambe le shell godono di un ampio
|
|
supporto online e di una vasta gamma di risorse, inclusi tutorial,
|
|
forum e documentazione. Questo rende facile trovare assistenza e
|
|
risorse per entrambe le shell.
|
|
|
|
## Installazione di `oh-my-zsh`
|
|
|
|
Si tratta di un framework utile a personalizzare una shell `zsh` con
|
|
temi e plugin. Per l'installazione si faccia riferimento alla
|
|
[documentazione](https://ohmyz.sh/#install) ufficiale.
|
|
|
|
## Installazione di `Powerlevel10k`
|
|
|
|
Si tratta di un tema per `zsh`. Per l'installazione si faccia
|
|
riferimento alla
|
|
[documentazione](https://github.com/romkatv/powerlevel10k?tab=readme-ov-file#oh-my-zsh) ufficiale.
|
|
|
|
# OverTheWire (wargames)
|
|
|
|
OverTheWire è un [sito web](https://overthewire.org/wargames/) che
|
|
offre una serie di esercizi di programmazione e sicurezza informatica,
|
|
chiamati "wargames" (giochi di guerra), progettati per aiutare gli
|
|
utenti a migliorare le loro competenze tecniche. Questi wargames sono
|
|
strutturati come una serie di sfide, ognuna delle quali richiede di
|
|
risolvere un problema specifico utilizzando le competenze di
|
|
programmazione e di sicurezza informatica.
|
|
|
|
Ogni wargame è progettato per essere accessibile a diversi livelli di
|
|
esperienza, dalla principiante all'avanzato, permettendo agli utenti
|
|
di imparare e migliorare le loro competenze in sicurezza informatica e
|
|
programmazione attraverso la pratica.
|