Skip to content

Commit

Permalink
New Crowdin updates (#2520)
Browse files Browse the repository at this point in the history 
* New translations 00-toc.md (Italian)

* New translations 02-web-servers-intro.md (Italian)

* New translations 00-toc.md (Italian)

* New translations disa_stig_part3.md (Italian)

* Update 00-toc.it.md

---------

Co-authored-by: sspencerwire <[email protected]>
  • Loading branch information
@rockylinux-auto @sspencerwire
rockylinux-auto and sspencerwire authored Nov 30, 2024
1 parent 7fcfca1 commit 58e3917
Show file tree
Hide file tree
Showing 4 changed files with 134 additions and 39 deletions.
44 changes: 22 additions & 22 deletions docs/books/disa_stig/disa_stig_part3.it.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -12,14 +12,14 @@ tags:

# Introduzione

Nella prima parte di questa serie abbiamo spiegato come costruire il nostro server web con la STIG RHEL8 DISA di base applicata e nella seconda parte abbiamo imparato a testare la conformità STIG con lo strumento OpenSCAP. Ora faremo qualcosa con il sistema, costruendo una semplice applicazione web e applicando la STIG del server web DISA: <https://www.stigviewer.com/stig/web_server/>
Nella prima parte di questa serie, abbiamo spiegato come costruire il nostro server web con la STIG RHEL8 DISA di base applicata e, nella seconda parte, abbiamo imparato a testare la conformità STIG con lo strumento OpenSCAP. Ora faremo qualcosa con il sistema, costruendo una semplice applicazione web e applicando la STIG del server web DISA: <a href=“https://www.stigviewer.com/stig/web_server/” x-nc=“1”>https://www.stigviewer.com/stig/web_server/</a>

Per prima cosa confrontiamo ciò che stiamo affrontando: la STIG DISA di RHEL 8 è indirizzata a una piattaforma molto specifica, quindi i controlli sono abbastanza facili da capire in quel contesto, da testare e da applicare. Le STIG delle applicazioni devono essere portabili su più piattaforme, quindi il contenuto è generico per funzionare su diverse distribuzioni Linux (RHEL, Ubuntu, SuSE, ecc.) **. Ciò significa che strumenti come OpenSCAP non ci aiuteranno a verificare/rimediare la configurazione, dovremo farlo manualmente. Questi STIG sono:
Per prima cosa confrontiamo ciò che stiamo affrontando: la STIG DISA di RHEL 8 è indirizzata a una piattaforma molto specifica, quindi i controlli sono abbastanza facili da capire in quel contesto, da testare e da applicare. Le STIG delle applicazioni devono essere portabili su più piattaforme, quindi il contenuto qui presente è generico per funzionare su diverse distribuzioni Linux (RHEL, Ubuntu, SuSE, ecc.)**. Strumenti come OpenSCAP non ci aiutano a verificare/recuperare la configurazione. Andremo a farlo manualmente. Questi STIG sono:

* Apache 2.4 V2R5 - Server; che si applica al server web stesso
* Apache 2.4 V2R5 - Sito; Che si applica all'applicazione web/sito web

Per la nostra guida, creeremo un semplice server web che non fa altro che servire contenuti statici. Possiamo usare le modifiche apportate qui per creare un'immagine di base e poi usare questa immagine di base quando costruiamo server web più complessi in seguito.
Per la nostra guida, creeremo un semplice server web che non fa altro che servire contenuti statici. Possiamo usare le modifiche apportate qui per creare un'immagine di base, che potremo poi usare quando costruiremo server web più complessi.

## Avvio rapido del server Apache 2.4 V2R5

Expand All @@ -38,16 +38,16 @@ sed -i 's/^\([^#].*\)**/# \1/g' /etc/httpd/conf.d/welcome.conf
dnf -y remove httpd-manual
dnf -y install mod_session

echo “MaxKeepAliveRequests 100” > /etc/httpd/conf.d/disa-apache-stig.conf
echo “SessionCookieName session path=/; HttpOnly; Secure;” >> /etc/httpd/conf.d/disa-apache-stig.conf
echo “Session On” >> /etc/httpd/conf.d/disa-apache-stig.conf
echo “SessionMaxAge 600” >> /etc/httpd/conf.d/disa-apache-stig.conf
echo “SessionCryptoCipher aes256” >> /etc/httpd/conf.d/disa-apache-stig.conf
echo “Timeout 10” >> /etc/httpd/conf.d/disa-apache-stig.conf
echo “TraceEnable Off” >> /etc/httpd/conf.d/disa-apache-stig.conf
echo “RequestReadTimeout 120” >> /etc/httpd/conf.d/disa-apache-stig.conf
echo "MaxKeepAliveRequests 100" > /etc/httpd/conf.d/disa-apache-stig.conf
echo "SessionCookieName session path=/; HttpOnly; Secure;" >> /etc/httpd/conf.d/disa-apache-stig.conf
echo "Session On" >> /etc/httpd/conf.d/disa-apache-stig.conf
echo "SessionMaxAge 600" >> /etc/httpd/conf.d/disa-apache-stig.conf
echo "SessionCryptoCipher aes256" >> /etc/httpd/conf.d/disa-apache-stig.conf
echo "Timeout 10" >> /etc/httpd/conf.d/disa-apache-stig.conf
echo "TraceEnable Off" >> /etc/httpd/conf.d/disa-apache-stig.conf
echo "RequestReadTimeout 120" >> /etc/httpd/conf.d/disa-apache-stig.conf

sed -i “s/^#LoadModule usertrack_module/LoadModule usertrack_module/g” /etc/httpd/conf.modules.d/00-optional.conf
sed -i "s/^#LoadModule usertrack_module/LoadModule usertrack_module/g" /etc/httpd/conf.modules.d/00-optional.conf
sed -i "s/proxy_module/#proxy_module/g" /etc/httpd/conf.modules.d/00-proxy.conf
sed -i "s/proxy_ajp_module/#proxy_ajp_module/g" /etc/httpd/conf.modules.d/00-proxy.conf
sed -i "s/proxy_balancer_module/#proxy_balancer_module/g" /etc/httpd/conf.modules.d/00-proxy.conf
Expand All @@ -68,7 +68,7 @@ systemctl start httpd

## Panoramica dei Controlli Dettagliati

Se siete arrivati fin qui, probabilmente siete interessati a saperne di più su ciò che la STIG vuole che facciamo. È utile capire l'importanza del controllo e quindi come si applica all'applicazione. A volte il controllo è tecnico (cambiare l'impostazione X in Y) e altre volte è operativo (come lo si usa). In generale, un controllo tecnico è qualcosa che si può modificare con il codice, mentre un controllo operativo probabilmente no.
Se siete arrivati fin qui, probabilmente siete interessati a saperne di più su ciò che la STIG vuole che facciamo. Aiuta a capire l'importanza del controllo e come si applica all'applicazione. A volte il controllo è tecnico (cambiare l'impostazione X in Y); altre volte è operativo (come lo si usa). In generale, un controllo tecnico è qualcosa che si può modificare con il codice, mentre un controllo operativo probabilmente no.

### Livelli

Expand All @@ -81,7 +81,7 @@ Se siete arrivati fin qui, probabilmente siete interessati a saperne di più su
* Tecnico - 24 controlli
* Operativo - 23 controlli

In questo articolo non tratteremo il "perché" di queste modifiche, ma solo ciò che deve accadere se si tratta di un controllo tecnico. Se non c'è nulla da modificare, come nel caso di un controllo Operational, il campo **Fix:** sarà vuoto. La buona notizia è che in molti di questi casi si tratta già dell'impostazione predefinita di Rocky Linux 8, quindi non è necessario cambiare nulla.
In questo articolo non tratteremo il “perché” di queste modifiche; discuteremo di ciò che deve accadere se si tratta di un controllo tecnico. Se non c'è nulla da modificare, come nel caso di un controllo Operational, il campo <strong x-id=“1”>Fix:</strong> sarà vuoto. La buona notizia in molti di questi casi è che questa è già l'impostazione predefinita in Rocky Linux 8, quindi non è necessario cambiare nulla.

## Apache 2.4 V2R5 - Dettagli del Server

Expand Down Expand Up @@ -165,7 +165,7 @@ dnf remove httpd-manual

```bash
dnf install mod_session
echo “SessionCookieName session path=/; HttpOnly; Secure;” >> /etc/httpd/conf.d/disa-apache-stig.conf
echo "SessionCookieName session path=/; HttpOnly; Secure;" >> /etc/httpd/conf.d/disa-apache-stig.conf
```

**(V-214269)** Il server web Apache deve rimuovere tutti i cifrari di esportazione per proteggere la riservatezza e l'integrità delle informazioni trasmesse.
Expand Down Expand Up @@ -217,7 +217,7 @@ echo “SessionCookieName session path=/; HttpOnly; Secure;” >> /etc/httpd/co
**Fix:**

```bash
echo “MaxKeepAliveRequests 100” > /etc/httpd/conf.d/disa-apache-stig.conf
echo "MaxKeepAliveRequests 100" > /etc/httpd/conf.d/disa-apache-stig.conf
```

**(V-214229)** Il server web Apache deve eseguire la gestione della sessione lato server.
Expand All @@ -227,7 +227,7 @@ echo “MaxKeepAliveRequests 100” > /etc/httpd/conf.d/disa-apache-stig.conf
**Fix:**

```bash
sed -i “s/^#LoadModule usertrack_module/LoadModule usertrack_module/g” /etc/httpd/conf.modules.d/00-optional.conf
sed -i "s/^#LoadModule usertrack_module/LoadModule usertrack_module/g" /etc/httpd/conf.modules.d/00-optional.conf
```

**(V-214266)** Il server web Apache deve vietare o limitare l'uso di porte, protocolli, moduli e/o servizi non sicuri o non necessari.
Expand Down Expand Up @@ -320,7 +320,7 @@ Fare riferimento a <https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html> per
**Fix:**

```bash
echo “Session On” >> /etc/httpd/conf.d/disa-apache-stig.conf
echo "Session On" >> /etc/httpd/conf.d/disa-apache-stig.conf
```

**(V-214250)** Il server web Apache deve invalidare gli identificatori di sessione al momento del logout dell'utente dell'applicazione ospitata o al termine di un'altra sessione.
Expand All @@ -330,7 +330,7 @@ echo “Session On” >> /etc/httpd/conf.d/disa-apache-stig.conf
**Fix:**

```bash
echo “SessionMaxAge 600” >> /etc/httpd/conf.d/disa-apache-stig.conf
echo "SessionMaxAge 600" >> /etc/httpd/conf.d/disa-apache-stig.conf
```

**(V-214252)** Il server Web Apache deve generare un ID di sessione sufficientemente lungo da non poter essere indovinato con la forza bruta.
Expand All @@ -340,7 +340,7 @@ echo “SessionMaxAge 600” >> /etc/httpd/conf.d/disa-apache-stig.conf
**Fix:**

```bash
echo “SessionCryptoCipher aes256” >> /etc/httpd/conf.d/disa-apache-stig.conf
echo "SessionCryptoCipher aes256" >> /etc/httpd/conf.d/disa-apache-stig.conf
```

**(V-214255)** Il server web Apache deve essere regolato per gestire i requisiti operativi dell'applicazione ospitata.
Expand All @@ -350,7 +350,7 @@ echo “SessionCryptoCipher aes256” >> /etc/httpd/conf.d/disa-apache-stig.con
**Fix:**

```bash
echo “Timeout 10” >> /etc/httpd/conf.d/disa-apache-stig.conf
echo "Timeout 10" >> /etc/httpd/conf.d/disa-apache-stig.conf
```

**(V-214254)** Il server web Apache deve essere costruito in modo da fallire in uno stato sicuro noto se l'inizializzazione del sistema fallisce, lo spegnimento fallisce o le interruzioni falliscono.
Expand All @@ -366,7 +366,7 @@ echo “Timeout 10” >> /etc/httpd/conf.d/disa-apache-stig.conf
**Fix:**

```bash
echo “TraceEnable Off” >> /etc/httpd/conf.d/disa-apache-stig.conf
echo "TraceEnable Off" >> /etc/httpd/conf.d/disa-apache-stig.conf
```

**(V-214230)** Il server Web Apache deve utilizzare la crittografia per proteggere l'integrità delle sessioni remote.
Expand Down
28 changes: 15 additions & 13 deletions docs/books/lxd_server/00-toc.it.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -10,19 +10,21 @@ tags:

# Creare un server LXD completo

??? warning "Stato attuale di LXD su Rocky Linux!"
!!! info "Informazione"

Quasi un anno fa, sulla mailing list lxc-users è stato pubblicato il seguente annuncio:

> Canonical, il creatore e principale collaboratore del progetto LXD, ha deciso che dopo oltre 8 anni di appartenenza alla comunità di Linux Containers, il progetto sarebbe stato gestito meglio direttamente da Canonical.
Questa procedura dovrebbe funzionare per Rocky Linux 8.x o 9.x. Se cercate un'implementazione moderna di questo progetto degli ex sviluppatori di LXD, ma disponibile solo per Rocky Linux 9.x, date un'occhiata a [il libro di Incus Server] (../incus_server/00-toc.md).

!!! info "Cosa è successo al progetto LXD"

Più di un anno fa, nella mailing list lxc-users è stato pubblicato il seguente annuncio:

Uno dei fattori decisivi sono state le dimissioni di alcuni sviluppatori principali di LXD, i quali hanno poi effettuato il fork di LXD in Incus, annunciando il fork nell'agosto 2023. Una versione di rilascio (0.1) è stata rilasciata nell'ottobre 2023, e da allora gli sviluppatori hanno rapidamente sviluppato questa versione con rilasci successivi fino alla 0.7 (marzo 2024). Dopo la 0.7 è arrivata la versione di supporto a lungo termine, la 6.0 LTS, il 4 aprile 2024.
> Canonical, the creator and main contributor of the LXD project has decided that after over eight years as part of the Linux Containers community, the project would now be better served directly under Canonical’s own set of projects.

Durante tutto il processo, si pensava che Cannonical avrebbe continuato a mantenere i collegamenti alle immagini dei container fornite da Linux Containers, ma a causa di un [cambio di licenza](https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-under-a-cla/) è diventato impossibile per Linux Containers continuare a offrire le immagini dei container all'interno di LXD. Ciò significa che LXD avrà delle immagini container, ma non saranno le immagini container che ci si aspetta attualmente. Linux Containers continua a ospitare e supportare le proprie immagini se si utilizza Incus.
Uno dei fattori decisivi sono state le dimissioni di alcuni sviluppatori principali di LXD, i quali hanno poi effettuato il fork di LXD in Incus, annunciando il fork nell'agosto 2023. Una versione di rilascio (0.1) è stata rilasciata nell'ottobre 2023, e da allora gli sviluppatori hanno rapidamente sviluppato questa versione con rilasci successivi fino alla 0.7 (marzo 2024). Dopo la 0.7 è arrivata la versione di supporto a lungo termine, la 6.0 LTS, il 4 aprile 2024, e ora la 6.4 LTS (da settembre 2024).

Questo documento utilizza LXD, piuttosto che Incus, MA è nostra intenzione riscrivere la procedura per Incus. Speravamo che una versione RPM di Incus venisse rilasciata nell'EPEL e, sebbene sia in lavorazione, non è ancora pronta. Ciò significa che per riscrivere questa procedura per Incus, dobbiamo concentrare i nostri interessi sulla routine di installazione e conversione del pacchetto sorgente. Il motivo di questo lungo avvertimento è che non vogliamo che si prenda il tempo di installare con questa procedura e poi si scopra che le immagini del contenitore (Rocky Linux, per esempio) non sono disponibili in LXD.
Durante tutto il processo, si pensava che Cannonical avrebbe continuato a mantenere i collegamenti alle immagini dei container fornite da Linux Containers, ma a causa di un [cambio di licenza](https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-under-a-cla/) è diventato impossibile per Linux Containers continuare a offrire le immagini dei container all'interno di LXD. Tuttavia, a causa di un [cambio di licenza](https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-under-a-cla/), è diventato impossibile per Linux Containers continuare a offrire le immagini dei container all'interno di LXD. Mentre Linux Containers non può più fornire immagini di container a LXD, il progetto LXD è riuscito a costruire alcuni container, compresi quelli per Rocky Linux.

Tenete d'occhio i cambiamenti qui!
Questo documento utilizza LXD anziché Incus.

## Introduzione

Expand All @@ -39,10 +41,10 @@ Per coloro che desiderano utilizzare LXD come ambiente di laboratorio sui propri
## Prerequisiti e presupposti

* Un server Linux Rocky, ben configurato. Considerare un disco rigido separato per lo spazio disco ZFS (è necessario se si usa ZFS) in un ambiente di produzione. E sì, il presupposto è un server bare metal, non un VPS (Virtual Private Server).
* Si tratta di un argomento avanzato, ma non è troppo difficile da capire e se si seguono queste istruzioni fin dall'inizio si dovrebbe avere successo. Detto questo, conoscere alcune nozioni di base sulla gestione dei container vi porterà lontano.
* Comfort alla riga di comando sulla/e macchina/e e dimestichezza con l'editor della riga di comando. (In questi esempi si utilizza _vi_, ma è possibile sostituirlo con il proprio editor preferito.)
* Si tratta di un argomento avanzato, ma non troppo difficile da comprendere. Se si seguono queste istruzioni fin dall'inizio, si dovrebbe avere successo. Detto questo, la conoscenza di alcune nozioni di base sulla gestione dei container è molto utile.
* Comfort dalla riga di comando sulla/e macchina/e e dimestichezza con l'editor della riga di comando. (In questi esempi si utilizza _vi_, ma è possibile sostituirlo con il proprio editor preferito.)
* Per la maggior parte di questi processi è necessario essere un utente non privilegiato. Per le prime fasi di configurazione, è necessario essere l'utente root o essere in grado di usare `sudo` per diventarlo. In tutti questi capitoli si assume che l'utente non privilegiato sia "lxdadmin". L'account utente dovrà essere creato più avanti nel processo.
* Per ZFS, assicurarsi che l'avvio sicuro UEFI NON sia abilitato. Altrimenti, si finirà per dover firmare il modulo ZFS per farlo caricare.
* Per ZFS, assicurarsi che il UEFI secure boot NON sia abilitato. Altrimenti, si finirà per dover firmare il modulo ZFS per farlo caricare.
* Utilizzo di container basati su Rocky Linux per la maggior parte del tempo

## Sinossi
Expand All @@ -52,7 +54,7 @@ Per coloro che desiderano utilizzare LXD come ambiente di laboratorio sui propri
* Il **Capitolo 3: Inizializzazione di LXD e configurazione dell'utente** si occupa dell'inizializzazione di base e delle opzioni, nonché della configurazione dell'utente non privilegiato che verrà utilizzato per la maggior parte del resto del processo
* **Capitolo 4: Impostazione del firewall** Ha le opzioni di configurazione di `firewalld`
* Il **capitolo 5: Impostazione e gestione delle immagini** descrive il processo di installazione delle immagini del sistema operativo in un contenitore e la loro configurazione
* Il **Capitolo 6: Profili** si occupa dell'aggiunta di profili e della loro applicazione ai contenitori, in particolare di macvlan e della sua importanza per l'indirizzamento IP sulla LAN o sulla WAN
* Il **Capitolo 6: Profili** si occupa dell'aggiunta di profili e della loro applicazione ai container, in particolare di macvlan e della sua importanza per l'indirizzamento IP sulla LAN o sulla WAN
* Il **capitolo 7: Opzioni di configurazione dei contenitori** copre brevemente alcune delle opzioni di configurazione di base per i contenitori e offre alcuni vantaggi ed effetti collaterali per la modifica delle opzioni di configurazione
* Il **capitolo 8: Istantanee dei contenitori** illustra in dettaglio il processo di istantanea dei contenitori sul server primario
* Il **capitolo 9: Il server snapshot** tratta l'impostazione e la configurazione del server snapshot e come creare una relazione simbiotica tra il server primario e il server snapshot
Expand All @@ -63,4 +65,4 @@ Per coloro che desiderano utilizzare LXD come ambiente di laboratorio sui propri

Questi capitoli consentono di configurare efficacemente un server LXD primario e uno snapshot di livello aziendale. Nel corso di questo processo, imparerete molto su LXD. Siate consapevoli che c'è ancora molto da imparare e considerate questi documenti come un punto di partenza.

Il vantaggio principale di LXD è che è economico da usare su un server, consente di avviare rapidamente le installazioni del sistema operativo e permette di eseguire molti server applicativi stand-alone su un singolo pezzo di hardware, sfruttando l'hardware per il massimo utilizzo.
Il vantaggio principale di LXD è che è economico da usare su un server, consente di avviare rapidamente le installazioni del sistema operativo e permette di eseguire molti server applicativi stand-alone su un singolo componente hardware, sfruttando l'hardware per il massimo utilizzo.
Loading

0 comments on commit 58e3917

Please sign in to comment.