• Re: VPN

    From mauro morichi@21:1/5 to All on Wed Dec 27 17:10:01 2023
    Il 26/12/23 18:57, Giuliano Curti ha scritto:
    Fra le varie opzioni possibili mi è sembrato di individuare WIREGUARD
    come lo strumento adatto.
    Prima di tuffarmi nella lettura e nella configurazione mi piaceva
    avere il conforto della vostra opinione (che tornerò a sollecitare per
    i dettagli pratici).


    Personalmente uso openvpn.

    in primo luogo puoi configurare la connessione sia per computer che per
    altri device (android,osx, iphone) di client ce ne sono a iosa,

    inoltre, oltre a poter configurare il tutto fornendo un file di
    configurazione con dentro tutto (quindi basta attivare la connessione
    dal pc e la connessione va da se), puoi anche optare per la richiesta
    username e password.

    inoltre, cosa comoda, aggiungendo un dns come dnsmasq (molto semplice da configurare) puoi offrire al client la possibilita' di digitare un nome anziche' un indirizzo ip per collegarsi al tuo server http.

    Rispetto a wireguard sicuramente lo studio e' un po' piu' complesso, ma
    i risultati sono decisamente validi.

    my 5 cents

    Mauro.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From mauro@teppisti.it@21:1/5 to All on Wed Dec 27 20:40:01 2023
    27 dicembre 2023 alle ore 18:05, "Giuliano Curti" <giulianc51@gmail.com> scrive:




    Ti ringrazio infinitamente per il tuo consiglio che valuterò; aggiungo però, rettificando forse il tiro, che per i miei usi (criptare una trasmissione HTTP per renderla fruibile solo ad utente/i predefinito/i) potrebbe bastare un SSH Port forwarding.

    Settando qualcosa tipo "SSH -L porta_locale remote.host:porta_remota" dovrei, aprendo il browser su http:://localhost:porta_locale, vedere quello che il web server del remote.host trasmette sulla porta_remota, o sbaglio?

    Non sbagli pero' mi domando: chi deve usare l'http e' uno in grado di aprire una shell, digitare un ssh -L etc etc o preferisce qualcosa di piu' automatico: avvio connessione cliccando su una qualche icona, aprire il browser e accedere?





    Mauro




    <!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body><p>27 dicembre 2023 alle ore 18:05, "Giuliano Curti" &lt;<a href="mailto:giulianc51@gmail.com?to=%22Giuliano%20Curti%22%20%3Cgiulianc51%40gmail.com%
    3E" target="_blank" tabindex="-1">giulianc51@gmail.com</a>&gt; scrive:<br></p><blockquote><div dir="auto"><div><div class="msg-gmail_quote"><div dir="ltr" class="msg-gmail_attr"><br></div></div>Ti ringrazio infinitamente per il tuo consiglio che valuterò
    ; aggiungo però, rettificando forse il tiro, che per i miei usi (criptare una trasmissione HTTP per renderla fruibile solo ad utente/i predefinito/i) potrebbe bastare un SSH Port forwarding.<div><br></div></div><div dir="auto"><br></div><div dir="auto">
    Settando qualcosa tipo "SSH -L porta_locale remote.host:porta_remota" dovrei, aprendo il browser su http:://localhost:porta_locale, vedere quello che il web server del remote.host trasmette sulla porta_remota, o sbaglio?<br></div><div dir="auto"><br></
    </div></blockquote><div>Non sbagli pero' mi domando: chi deve usare l'http e' uno in grado di aprire una shell, digitare un ssh -L etc etc o preferisce qualcosa di piu' automatico: avvio connessione cliccando su una qualche icona, aprire il browser e
    accedere?</div><blockquote><div dir="auto"></div></blockquote><div><br></div><div>Mauro</div><blockquote><div dir="auto"><div dir="auto"><br></div></div></blockquote><div><br></div></body></html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Leonardo Boselli@21:1/5 to Giuliano Curti on Thu Dec 28 18:20:01 2023
    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.

    Una domanda importantissima: gli utenti predefiniti si collegano sempre
    dallo stesso indirizzo, e lo usano solo loro ? perché se così fosse basterebbe un allow e a quel punto non ti chiede neppure la utenticazione.

    On Wed, 27 Dec 2023, Giuliano Curti wrote:
    Azzeccato, hai ragione :-)) uno degli "utenti predefiniti" sono io e posso presumere che, risolto la
    prima volta, posso reiterare correttamente la stringa di connessione, ma dovessi autenticare moglie o
    figlia per una cosa che riguarda anche loro il problema si porrebbe, a meno di risolvere con uno
    script..... Valuterò, grazie dell'avvertimento.

    --
    Leonardo Boselli
    Firenze, Toscana, Europa

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From mauro@teppisti.it@21:1/5 to All on Thu Dec 28 22:30:01 2023
    28 dicembre 2023 alle ore 22:18, "Giuliano Curti" <giulianc51@gmail.com> scrive:





    2: la porta 22 e' bersagliata continuamente da scriptkiddies che tentanto tutte le possibili combinazioni pur di indovinare gli accessi. Suggerisco di cambiare la porta di default del servizio ssh, adeguare ovviamente le impostazioni di eventuali
    firewall, file2ban e soci in modo da togliere di mezzo gli script automatici. Non si tratta di un vero e' proprio metodo di sicurezza, ma evita l'affollamento di tentativi di accesso automatici che riempono i log.


    Si, ho visto l'avvertenza in molti post e interverrò, però, come info generale, l'accesso con chiave e la protezione fail2ban non sono una solida protezione?


    fail2ban analizza il log e blocca gli accessi agli ip che esagerano.... sulla porta 22 in breve tempo ti ritrovi delle liste lunghe una quaresima.
    l'accesso con chiave o certificato danno sicuramente la garanzia che cerchi. Il discorso di cambiare la porta e' quella di bloccare sul nascere il tentativo. Il risultato e' avere un log pulito, risparmio di cicli macchina nel controllare chi si collega
    da parte di fail2ban, meno utilizzo di banda (non e' che rubano chissa' quanto, ma onestamente vedere un log pulito ti risparmia la perdita di tempo - e lo risparmia pure a fail2ban - alla ricerca di eventuali attaccanti). Cambiare la porta non è
    assolutamente un presidio di sicurezza come lo sono chiavi, password e fail2ban, ma aiuta a tenere meglio sotto controllo la situazione proprio perche' c'e' meno monnezza da controllare.


    M.
    <!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body><p>28 dicembre 2023 alle ore 22:18, "Giuliano Curti" &lt;<a href="mailto:giulianc51@gmail.com?to=%22Giuliano%20Curti%22%20%3Cgiulianc51%40gmail.com%
    3E" target="_blank" tabindex="-1">giulianc51@gmail.com</a>&gt; scrive:<br></p><blockquote><div dir="auto"><div><div><br></div></div><div dir="auto"><br></div><div dir="auto"><div class="msg-gmail_quote"><blockquote class="msg-gmail_quote" style="margin:
    0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div><br></div><div>2: la porta 22 e' bersagliata continuamente da scriptkiddies che tentanto tutte le possibili combinazioni pur di indovinare gli accessi. Suggerisco
    di cambiare la porta di default del servizio ssh, adeguare ovviamente le impostazioni di eventuali firewall, file2ban e soci in modo da togliere di mezzo gli script automatici. Non si tratta di un vero e' proprio metodo di sicurezza, ma evita l'
    affollamento di tentativi di accesso automatici che riempono i log.<br></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Si, ho visto l'avvertenza in molti post e interverrò, però, come info generale, l'accesso con chiave e
    la protezione fail2ban non sono una solida protezione?<br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div></blockquote><div><br></div><div>fail2ban analizza il log e blocca gli accessi agli ip che esagerano....
    sulla porta 22 in breve tempo ti ritrovi delle liste lunghe una quaresima.<br></div><div>l'accesso con chiave o certificato danno sicuramente la garanzia che cerchi. Il discorso di cambiare la porta e' quella di bloccare sul nascere il tentativo. Il
    risultato e' avere un log pulito, risparmio di cicli macchina nel controllare chi si collega da parte di fail2ban, meno utilizzo di banda (non e' che rubano chissa' quanto, ma onestamente vedere un log pulito ti risparmia la perdita di tempo - e lo
    risparmia pure a fail2ban - alla ricerca di eventuali attaccanti). Cambiare la porta non è assolutamente un presidio di sicurezza come lo sono chiavi, password e fail2ban, ma aiuta a tenere meglio sotto controllo la situazione proprio perche' c'e' meno
    monnezza da controllare.<br></div><div><br></div><div><br></div><div>M.</div></body></html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From mauro@teppisti.it@21:1/5 to All on Thu Dec 28 22:20:01 2023
    28 dicembre 2023 alle ore 19:13, "Giuliano Curti" <giulianc51@gmail.com> scrive:




    Aggiungo ancora un (....o dei tanti) dubbio.
    In questo momento ho aperto sul router la porta 22 per l'amministrazione SSH e le porte 8080+ per la trasmissione web delle telecamere (1 per ogni telecamera + 1 per l'applicativo).

    Se instauro il tunnel SSH le porte 8080+ devono cmq rimanere aperte? In tal caso il discorso risulterebbe vanificato perché il sistema continuerebbe a trasmettere in chiaro su quelle porte; sono protette da user: password e da fail2ban, ma il
    tunneling non mi porterebbe vantaggi, mentre ne avrebbe parecchi se potessi chiuderle (come ho detto i dati non sono per nulla sensibili, per me è semplicemente un'occasione per capire di più di reti e sicurezza).


    --



    ci sono due punti:
    1: puoi chiudere tutte le porte ad accezione della ssh. tutti gli accessi passerebbero via ssh e non ci sarebbe piu' necessita' di avere le ulteriori porte aperte.
    2: la porta 22 e' bersagliata continuamente da scriptkiddies che tentanto tutte le possibili combinazioni pur di indovinare gli accessi. Suggerisco di cambiare la porta di default del servizio ssh, adeguare ovviamente le impostazioni di eventuali
    firewall, file2ban e soci in modo da togliere di mezzo gli script automatici. Non si tratta di un vero e' proprio metodo di sicurezza, ma evita l'affollamento di tentativi di accesso automatici che riempono i log.




    <!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body><p>28 dicembre 2023 alle ore 19:13, "Giuliano Curti" &lt;<a href="mailto:giulianc51@gmail.com?to=%22Giuliano%20Curti%22%20%3Cgiulianc51%40gmail.com%
    3E" target="_blank" tabindex="-1">giulianc51@gmail.com</a>&gt; scrive:<br></p><blockquote><div dir="auto"><div class="msg-gmail_quote" dir="auto"><div dir="ltr" class="msg-gmail_attr"><br></div></div><div dir="auto"><br></div><div dir="auto">Aggiungo
    ancora un (....o dei tanti) dubbio.<br></div><div dir="auto">In questo momento ho aperto sul router la porta 22 per l'amministrazione SSH e le porte 8080+ per la trasmissione web delle telecamere (1 per ogni telecamera + 1 per l'applicativo).<br></div><
    div dir="auto"><br></div><div dir="auto">Se instauro il tunnel SSH le porte 8080+ devono cmq rimanere aperte? In tal caso il discorso risulterebbe vanificato perché il sistema continuerebbe a trasmettere in chiaro su quelle porte; sono protette da user:
    password e da fail2ban, ma il tunneling non mi porterebbe vantaggi, mentre ne avrebbe parecchi se potessi chiuderle (come ho detto i dati non sono per nulla sensibili, per me è semplicemente un'occasione per capire di più di reti e sicurezza).<br></div>
    <div dir="auto"><br></div><div class="msg-gmail_quote" dir="auto"><blockquote class="msg-gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">--</blockquote></div></div></blockquote><div><br></div><
    ci sono due punti:<br></div><div>1: puoi chiudere tutte le porte ad accezione della ssh. tutti gli accessi passerebbero via ssh e non ci sarebbe piu' necessita' di avere le ulteriori porte aperte.<br></div><div>2: la porta 22 e' bersagliata
    continuamente da scriptkiddies che tentanto tutte le possibili combinazioni pur di indovinare gli accessi. Suggerisco di cambiare la porta di default del servizio ssh, adeguare ovviamente le impostazioni di eventuali firewall, file2ban e soci in modo da
    togliere di mezzo gli script automatici. Non si tratta di un vero e' proprio metodo di sicurezza, ma evita l'affollamento di tentativi di accesso automatici che riempono i log.</div><blockquote><div dir="auto"><div class="msg-gmail_quote" dir="auto"><br><
    /div></div></blockquote><div><br></div></body></html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Davide Prina@21:1/5 to All on Sun Dec 31 11:30:02 2023
    Giuliano Curti ha scritto:

    Purtroppo il port forwarding fatto sul router interno alla rete, pur consentendo l'accesso alla home dello stesso, perde tutta l'impostazione grafica rendendo praticamente illeggibile il contenuto.

    Anche l'opzione -X non da miglioramenti (non ho provato la -Y): sapete se c'è qualche opzione ovvero qualche altro browser graficamente meno avido di Chromium, che renda possibile l'operazione?

    ma che desktop environment usi?
    Con wayland il l'X forwarding non dovrebbe più funzionare.

    Per poter avere qualcosa di simile ho visto che c'è
    waypipe

    Mi sono un po' perso nel thread e non me ne intendo su
    questo argomento... ma se si devono trasmettere le immagini
    di telecamere non si potrebbe usare uno screencast e accedere
    allo stream con un semplice programma come mpv?
    Ad esempio ho visto che c'è questo:
    ustreamer

    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)