Ciao a tutti alcune norme chiedono modalità per la protezione dei logs
degli amministratori di sistema dalla manomissione anche degli
amministratori stessi; ci vorrebbe un algoritmo basato sulla principio
di indeterminazione di Heisenberg, un algoritmo quantistico ;) Voi come affrontate nel mondo comune la cosa?

Piviul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il 12 dicembre 2024 08:04:56 CET, Piviul <piviul@riminilug.it> ha scritto: >Ciao a tutti alcune norme chiedono modalità per la protezione dei logs degli amministratori di sistema dalla manomissione anche degli amministratori stessi; ci vorrebbe un algoritmo basato sulla principio di indeterminazione di Heisenberg, un algoritmo
quantistico ;) Voi come affrontate nel mondo comune la cosa?

I log di journald sono firmati e non possono venire modificati (se cambi anche solo 1 byte journald se ne accorge e emette un warning).

federico

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/12/24 09:21, Federico Di Gregorio wrote:

Il 12 dicembre 2024 08:04:56 CET, Piviul <piviul@riminilug.it> ha scritto:

Ciao a tutti alcune norme chiedono modalità per la protezione dei logs degli amministratori di sistema dalla manomissione anche degli amministratori stessi; ci vorrebbe un algoritmo basato sulla principio di indeterminazione di Heisenberg, un

algoritmo quantistico ;) Voi come affrontate nel mondo comune la cosa?

I log di journald sono firmati e non possono venire modificati (se cambi anche solo 1 byte journald se ne accorge e emette un warning).

questo è già un buon inizio però l'amministratore li può eliminare...
anche journald può inviare i logs ad un journald di un altro server? In
ogni caso avete qualche consiglio, best practice su come ottenere l'immodificabilità dei logs almeno degli amministratori di sistema?

Paolo

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ciao Piviul,

Il giorno gio, 12/12/2024 alle 09.40 +0100, Piviul ha scritto:

On 12/12/24 09:21, Federico Di Gregorio wrote:

Il 12 dicembre 2024 08:04:56 CET, Piviul <piviul@riminilug.it> ha scritto:

Ciao a tutti alcune norme chiedono modalità per la protezione dei logs degli amministratori di sistema dalla manomissione anche degli amministratori stessi; ci vorrebbe un algoritmo basato sulla principio di indeterminazione di Heisenberg, un

algoritmo quantistico ;) Voi come affrontate nel mondo comune la cosa?

I log di journald sono firmati e non possono venire modificati (se cambi anche solo 1 byte journald se ne accorge e emette un warning).

questo è già un buon inizio però l'amministratore li può eliminare... anche journald può inviare i logs ad un journald di un altro server? In ogni caso avete qualche consiglio, best practice su come ottenere l'immodificabilità dei logs almeno degli amministratori di sistema?

Journald può essere configurato per inviare i log ad un secondo server. Vedi
i file del pacchetto systemd-journal-remote.

Riguardo la protezione dall'amministratore, potresti fare la replica gestita
da un amministratore diverso, attivare la firma del journal da parte di systemd, e copiare periodicamente i file su un supporto rimovibile. Per farlo devi tenere presente che journald ha delle regolazioni riguardo quanti file e quando spazio usare, sicché automaticamente cancella i log più vecchi. Devi fare in modo da copiare tutto su supporto esterno prima che i log vengano cancellati automaticamente.

Ma non è una configurazione a prova di bomba: ad esempio l'amministratore del primo server può riconfigurare e interrompere la replica verso il secondo.

In genere la replica ha senso quando hai tante macchine de gestire e centralizzi journald. Per fare la sola archiviazione, puoi operare sul server principale, se ne hai solo uno.

In ogni caso, se parli di norme legali, non devi fare qualcosa che funzioni assolutamente perfettamente (inappuntabile dal punto di vista tecnico). Devi solo ridurre al minimo la possibilità che ci siano alterazioni non volute. Se poi ci fossero, vai alla polizia postale e denunci la cosa. Legalmente non serve altro. Ad esempio, se ti va a fuoco il server di replica mentre facevi
la copia su DVD sul server stesso, perdendo di fatto gli ultimi log, devi
solo denunciare il fatto e sei sollevato dalla responsabilità legale.

Ciao,
Giuseppe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/12/24 09:40, Piviul wrote:

On 12/12/24 09:21, Federico Di Gregorio wrote:

Il 12 dicembre 2024 08:04:56 CET, Piviul <piviul@riminilug.it> ha
scritto:

Ciao a tutti alcune norme chiedono modalità per la protezione dei
logs degli amministratori di sistema dalla manomissione anche degli
amministratori stessi; ci vorrebbe un algoritmo basato sulla
principio di indeterminazione di Heisenberg, un algoritmo
quantistico ;) Voi come affrontate nel mondo comune la cosa?

I log di journald sono firmati e non possono venire modificati (se
cambi anche solo 1 byte journald se ne accorge e emette un warning).

questo è già un buon inizio però l'amministratore li può eliminare... anche journald può inviare i logs ad un journald di un altro server?
In ogni caso avete qualche consiglio, best practice su come ottenere l'immodificabilità dei logs almeno degli amministratori di sistema?

Il fatto che un amministratore possa rimuovere fisicamente il file non significa che possa modificare i log: da questo punto di vista i log di journald non sono modificabili ed è facile capire se qualcuno ha rimosso
dei file. Se oltre all'integrità vuoi anche rendere impossibile
"perdere" i log è sufficiente inviarli ad un altra macchina con systemd-journal-remote.

federico

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
On 12/12/24 14:22, Giuseppe Sacco wrote:

[...]
In genere la replica ha senso quando hai tante macchine de gestire e centralizzi journald. Per fare la sola archiviazione, puoi operare sul server principale, se ne hai solo uno.

Grazie mille Giuseppe e grazie anche a Diego, non conoscevo l'esistenza
di systemd-journal-remote; per caso sapete anche se esiste un client
windows per inviare i log ad un server systemd un po' come per rsyslog
in modo da centralizzare anche i logs di windows?

Piviul

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 12/12/24 14:22, Giuseppe Sacco
wrote:<br>
</div>
<blockquote type="cite" cite="mid:f25b317aa687d0650a5a3dece1c5fb0b54c15619.camel@sguazz.it">[...]<span
style="white-space: pre-wrap">
</span>
<pre class="moz-quote-pre" wrap="">In genere la replica ha senso quando hai tante macchine de gestire e
centralizzi journald. Per fare la sola archiviazione, puoi operare sul server principale, se ne hai solo uno.</pre>
</blockquote>
<p>Grazie mille Giuseppe e grazie anche a Diego, non conoscevo <span
style="white-space: pre-wrap">l'esistenza di systemd-journal-remote; per caso sapete anche se esiste un client windows per inviare i log ad un server systemd un po' come per rsyslog in modo da centralizzare anche i logs di windows?</span></p>
<p><span style="white-space: pre-wrap">Piviul
</span></p>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Piviul ha scritto:

alcune norme chiedono modalità per la protezione dei logs
degli amministratori di sistema dalla manomissione anche degli amministratori stessi;

ma nell'altro thread avevi chiesto di wazuh e sulla sua home page leggo
Unified XDR and SIEM protection for endpoints and cloud workloads.

Se non erro, dato che non sono un esperto in questo settore, il SIEM è
detto anche cassaforte dei log. Quindi se usi un SIEM e invii li i
log dovresti aver rispettato le norme.

Poi di log ne esistono di diversi tipi e ognuno può/deve avere un
trattamento particolare.
Quelli di base lato sicurezza sono quelli di audit. Sono quelli che
andrebbero mandati al SIEM

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
On 12/13/24 13:52, Piviul wrote:

Grazie mille Giuseppe e grazie anche a Diego, non conoscevo
l'esistenza di systemd-journal-remote; per caso sapete anche se esiste
un client windows per inviare i log ad un server systemd un po' come
per rsyslog in modo da centralizzare anche i logs di windows?

Provo a rispondermi da solo. Mi sembra di aver capito che l'agent su
windows rimane rsyslog ma poi rsyslog  con il modulo omjournal può fare
il forward dei logs ricevuti a journald...

Grazie a tutti

Piviul

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 12/13/24 13:52, Piviul wrote:<br>
</div>
<blockquote type="cite"
cite="mid:71330936-01a4-4a36-ad69-7cd1ab7dfa54@riminilug.it">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Grazie mille Giuseppe e grazie anche a Diego, non conoscevo <span
style="white-space: pre-wrap">l'esistenza di systemd-journal-remote; per caso sapete anche se esiste un client windows per inviare i log ad un server systemd un po' come per rsyslog in modo da centralizzare anche i logs di windows?</span></
blockquote>
<p>Provo a rispondermi da solo. Mi sembra di aver capito che l'agent
su windows rimane rsyslog ma poi rsyslog  con il modulo omjournal
può fare il forward dei logs ricevuti a journald... <br>
</p>
<p>Grazie a tutti</p>
<p>Piviul<br>
</p>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/15/24 11:14, Davide Prina wrote:

Piviul ha scritto:

alcune norme chiedono modalità per la protezione dei logs
degli amministratori di sistema dalla manomissione anche degli
amministratori stessi;

ma nell'altro thread avevi chiesto di wazuh e sulla sua home page leggo Unified XDR and SIEM protection for endpoints and cloud workloads.

Se non erro, dato che non sono un esperto in questo settore, il SIEM è
detto anche cassaforte dei log. Quindi se usi un SIEM e invii li i
log dovresti aver rispettato le norme.

Poi di log ne esistono di diversi tipi e ognuno può/deve avere un trattamento particolare.
Quelli di base lato sicurezza sono quelli di audit. Sono quelli che andrebbero mandati al SIEM

Si, infatti se adotteremo Wazuh quel problema lo avremo risolto

Piviul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)