Strumenti Utente

Strumenti Sito


tecno:letsencrypt-irewall

LetsEncrypt e l’errore "Probabile errore dovuto al firewall."

Tutto è iniziato quando ho deciso di portare i miei vari siti in home: avendo un nuovo provider che mi forniva nel contratto un IP statico di default, e non mancandomi l’hardware necessario, non aveva più senso tenere in affitto un server in una Farm per i servizi che avevo installato.

Alla fin fin fine si trattava di una serie di siti, gestiti tutto sotto Apache2 e Wordpress. Altri servizi come il proxy Tor per le varie applicazioni ed altre casette comunque non richiedevano grandi quantità ne di disco ne di memoria, per cui ho deciso di trasferire il tutto su un server a casa.

Tra le altre cose: da una parte ero stufo di Wordpress, che ogni due per tre, all’aggiornamento rompeva il sistema, dall’altra i blog li avevo già trasformati tutti in newsletter, portandoli sotto SubStack, per cui Wordpress non l’ho più installato.

Per quello che mi restava da pubblicare, ossia il mio Wiki, ed altre poche cose DokuWiki, con il plugin MarkDown si è rivelato più che sufficiente. Quindi:


  • ho installato DokuWiki sul mio server;

  • creati i vari punti radice dei vari siti;

  • creato le configurazioni dei VirtualServer per Apache2;

  • sistemato i puntamenti nuovi per i vari record del server DNS.

  • creato la regola sul mio firewall per raggiungere via ssh il server da Internet;

  • creato le classiche regole sul mio firewall per reindirizzare le porte 80 e 443 verso il mio server

Restava un’ultima cosa da fare: rigenerare i certificati di LetsEncrypt: i vecchi li avevo cancellati perché ero più che certo, anche se non ho verificato in effetti, che spostandoli si altro server non avrebbero funzionato correttamente.

E qui sono cominciati i problemi: sembrava non ci fosse modo di creare i certificati stando un un server con IP locale, classe 192, raggiunto da un indirizzo pubblico via regole sul firewall.

Ho tentato usando i seguenti comandi:

letsencrypt -d jcsh.eu
letsencrypt 
letsencrypt certbot -d jcsh.eu
letsencrypt certbot -w /var/www/jcsh.eu -d dicolamiasu.jcsh.eu

Ma non c’era verso che la generazione del certificato andasse a buon fine: qualunque comando tentassi, il risultato era sempre lo stesso, ossia durante la fase di verifica veniva generato un errore generico tipo Probable firewall problem.

Nel dubbio dapprima ho spento il firewall sul mio server, poi l’ho proprio disinstallato: sempre lo stesso errore. A quel punto ho pensato fosse un errore dovuto al firewall necessario a generare le regole di instradamento dal router al mio server. Chiaramente quello non potevo spegnerlo, o non avrei più raggiunto il server dall’esterno.

La soluzione più immediata era quella di farmi assegnare un secondo IP pubblico in modo da porgere il mio server direttamente verso internet assegnandoli l’IP pubblico sulla configurazione della scheda di rete: l’ho fatto decine di volte per i clienti, ed ha sempre funzionato!

In quella fase mi sono ricordato che il mio nuovo ISP, oltre ad un indirizzo pubblico IPv4 mi ha assegnato un’intera classe 48 di indirizzi IPv6.

Ora la faccio breve, altrimenti diventa troppo complesso spiegare il perché, ma gli indirizzi IPv6 sono tutti pubblici, quindi una macchina con indirizzo IPv6 può essere raggiunta da internet senza bisogno di alcuna regola sul router/firewall.

Chiaramente questa cosa rende più insicura la struttura di rete su cui esiste il server in questione, per cui si deve porre particolare attenzione a dettare le giuste protezioni con il firewall residente sul server stesso.

Configurato il server per avere il suo IPv6 visibile sulla rete, quindi con le giuste regole configurate, ho testato il tatto usando dei certificati auto generati: tutto ok! Siti raggiungibili, certificati auto generati riconosciuti come tali e siti visualizzati!!!

Mi son detto: ok adesso ci siamo! Ho riprovato a generare quei benedetti certificati: stesso risultato con lo stesso errore!

Ho voluto rischiare spegnendo totalmente il firewall del server nella fase di generazione dei certificati (ricordate? Stavo usando indirizzo IPv6 quindi non passavo dal firewall del router), di nuovo nulla da fare: sempre lo stesso errore.

Ormai ero lì per arrendermi: mi sono detto che:


  1. probabilmente LetsEncrypt non era studiato per un caso come il mio in cui eseguivo un server da dietro un firewall domestico;

  2. Probabilmente LetsEncrypt non supportava IPv6.

Se così fosse stato mi restavano due alternative:

  1. Affittare un nuovo server in una Farm e tornare al punto di partenza;

  2. tenere il tutto sul mio server in home e far vivere i siti con i certificati auto generati, nonostante questo significasse un calo immediato del ranking nei motori di ricerca, ed un immediato azzeramento delle visite ai siti: chi si fiderebbe, al giorno d’oggi, di un sito con certificati auto generati, specialmente da quando esiste LetsEncrypt che i certificati li da gratis a chiunque?

Mi sono messo a leggere tutta la documentazione che ho trovato su LetsEncrypt: sia dal sito ufficiale, sia da documentazione alternativa trovata in rete. Alla fine dello studio ero certo di due cose:

  1. LetsEncrypt non poneva divieti di avere certificati stando dietro un router che instradava verso una macchina con indirizzo locale;

  2. LetsEncrypt dichiara di supportare gli indirizzi IPv6.

Ho chiesto a diverse IA consigli sul tipo di configurazione, ma da quello che consigliavano anche loro davano per scontati i due punti sopra elencati.

Inoltre, nei tentativi di far funzionare LetsEncrypt ho scoperto un’altro problema inerente gli indirizzi IP e la risoluzione degli HostName.

Da quanto letto in rete, da una certa data in poi, i server DNS sono istruiti, al momento della richiesta di una traduzione, di cercare prima un indirizzo IPv6, se non lo trova cercare un indirizzo IPv4.

Conseguentemente avevo configurato in questo modo il mio server DNS:


31 subdomains
jcsh.eu	[ add ]
	jcsh.eu (G)	A	xxx.xx.xx
	jcsh.eu (G)	AAAA	xaxx:xdxx:xxxf:x::cxxe

Quindi secondo quanto appreso alla richiesta http://jcsh.eu il server DNS avrebbe dovuto ritornare:

  • xaxx:xdxx:xxxf:x::cxxe se la mia rete supportava IPv6

  • xxx.xx.xx se la mia rete non supportava IPv6

E finché lavoravo dalla mia rete, era tutto corretto. Facendo delle prove con

  1. Scheda di rete configurata in IPv6 ed IPv4

  2. Scheda di rete configurata solo in IPv6

  3. Scheda di rete configurata solo in IPv4

Riuscivo sempre a collegarmi al mio dominio.

MA Se tentavo le stesse operazioni da una rete che non supportasse IPv6 —non semplicemente spegnendo il protocollo IPv6 dalla mia macchina— ho provato usando la rete del mio cellulare, non funzionava più nulla, mentre teoricamente essendo la rete cellulare una rete IPv4 il server DNS avrebbe dovuto cercare il record A e risolvere correttamente il nome dominio trasferendo il browser alla giusta destinazione.

Questo più il problema di LetsEncrypt mi ha fatto sorgere un dubbio: sono andato a scartabellare il sito del mio nuovo provider e… sorpresa!!!

Imboscato all’ultima riga di una sezione Q&A trovo: «Come è configurato il firewall perimetrale?»

Perimetrale? Come perimetrale? Nessuno mi ha detto che la rete del mio provider ha un firewall perimetrale

Per chi non sapesse cosa fosse un firewall perimetrale, la spiego molto facile facile, poi vi passo un indirizzo con informazioni più approfondite.

Nel modo più semplice possibile: avete presente cosa fa il firewall al vostro computer? Ecco adesso pensate ad un firewall poso A MONTE del vostro internet provider. Questo è un firewall perimetrale, dove il perimetro in questo caso è l’intera rete del vostro provider: tutte le limitazioni imposte sul firewall perimetrale saranno forzate su tutti quelli che vivono all’interno di quel perimetro, quindi per estensione a tutti i clienti di quell’ISP.

Il Pro? Imporre maggiore sicurezza ai clienti, quindi a voi che usate il vostro ISP per andare in internet.

Il Contro? Il cliente non ha modo di aggirare le restrizioni imposte dal firewall perimetrale. In più, molto spesso accade che l’ISP nemmeno avvisi il cliente dell’esistenza del firewall perimetrale stesso.

Quando ho finalmente realizzato a quale firewall si riferisse LetsEncrypt quando generava errore, ossia quello perimetrale, ho contattato subito il mio provider. Ho chiesto di farmi aggirare totalmente il firewall perimetrale, addossandomi la protezione dei miei sistemi. Come previsto dalle normative, hanno subito provveduto a ripristinarmi una connessione DIRETTA verso internet e… voilà: LetsEncrypt ha ripreso a funzionare correttamente generando tutti i miei certificati senza dare più errori.

Inoltre, visto che avevano una regola anche sulla porta del server DNS, evidentemente era quella che impediva lo switch dal record AAAA ossia IPv6 verso il record A ossia IPv4.

Adesso anche chi non ha una rete che supporti l’IPv6 può vedere regolarmente i miei siti anche se essi hanno sia un record A che un record AAAA, come vi avevo mostrato prima:


31 subdomains
jcsh.eu	[ add ]
	jcsh.eu (G)	A	xxx.xx.xx
	jcsh.eu (G)	AAAA	xaxx:xdxx:xxxf:x::cxxe




Precisazione

Il firewall perimetrale non fa solo quanto detto sinora: nelle grandi aziende, come anche gli ISP, il perimetrale assomma tutta una serie di azioni oltre al controllo delle porte, per esempio:

  • anti-virus

  • anti-maleware

  • anti ransomware (nei limiti del possibile)

  • anti-spyware

Ed altro ancora. Insomma: il firewall perimetrale si occupa di tutta una serie di cose che riguardano la sicurezza informatica.


Conclusioni

Ha senso che un provider attivi un firewall perimetrale? Certo che si: per il 90% degli utenti non aziendali ha senso. L’utente domestico non è tenuto a sapere né cosa sia un firewall, né come attivarlo e/o configurarlo.

Certo dovrebbe al giorno d’oggi studiarsi un minimo di sicurezza informatica, ma diciamocelo chiaramente: l’utente medio vuole solo


  • attaccare la spina;

  • accendere il computer

  • collegarsi al proprio wifi/cavo di rete

  • collegarsi ad internet

Punto: non vuole sapere altro.

Quindi si: ha un senso che il provider attivi un firewall perimetrale per proteggere i propri clienti ignari.

Avrebbe anche senso, però che segnalasse questa cosa, al cliente, al momento dell’apertura di un contratto: se lo avessi saputo subito, non avrei perso ore, per non dire un paio di giorni, per capire cosa impediva a LetsEncrypt di generare i miei certificati, o perché gli utenti con rete solo IPv4, che sono la stragrande maggioranza, non riuscissero a vedere i miei siti.



Riferimenti

Wikipedia: firewall: cosa è e come funziona.

Forcepiont: che cos’è un firewall.

Onorato: che cos’è un firewall perimetrale.

Centro di competenza CyberSecurity: I firewall.


Esempio di Firewall Perimetrale di un ISP

Porte filtrate automaticamente, ma disattivabili su richiesta:

PROTOCOLLO SERVIZIO CAUSA DEL BLOCCO Porte Direzione
TCP ssh SSH Server 22 IN
TCP telnet Telnet Server 23 IN
TCP http Riservato per gestione remota 80 IN
TCP/UDP sun-rpc Vulnerabilità nota sunRPC su Unix 111 IN
UDP snmp Riservato per gestione remota 161,162 IN
TCP https Riservato per gestione remota 443 IN
TCP pptp Server PPTP VPN 1723 IN
TCP mikrotik Mikrotik RouterOS SpeedTest server 2000 IN

Joseph Curto 30/11/2023 10:50 - Ultima modifica il : 30/11/2023 10:50

tecno/letsencrypt-irewall.txt · Ultima modifica: 24/03/2024 09:40 da 127.0.0.1