|
Ciao, fail2ban su SSH lo lascerei solo per bloccare chi fa tentativi e quindi, una volta bannato, rifiutare le connessioni da quell’IP senza
neanche fare attivare la risposta del daemon SSH. Capisco che implementare fail2ban sul collegamento https potrebbe essere difficoltoso. Però se il log dell’applicativo web che gestisce
l’autenticazione è facile da interpretare, una regular _expression_ che becchi il fallimento si può inventare. Pare che Motion abbia implementato i log sul failed logon un po’ di tempo fa: https://github.com/Motion-Project/motion/issues/348 https://github.com/Motion-Project/motion/pull/434 Chiedo scusa se queste cose sono state già dette, mi sono sicuramente perso dei pezzi. Ciao da Lorenzo Da: Giuliano Curti <giulianc51@gmail.com>
Il lun 4 ott 2021, 22:04 Mauro <mauro@teppisti.it> ha scritto:
Ciao Davide e Mauro, grazie delle risposte; Mauro ha chiarito i limiti e le difficoltà di fail2ban. Aggiungo per Davide che l'oggetto è la sicurezza di un sistema di videosorveglianza (abbastanza naif e basato sul solo motion); ho previsto l'apertura della porta 22 per l'amministrazione del sistema via SSH, occorre poi aprire le porte per l'uso di motion, una per il webcontrol (un controllo limitato dei parametri di motion) ed una per ogni telecamera. Ovviamente i dati (visualizzazione di un paio di prati) non hanno alcuna importanza e segretezza, sono più che altro un pretesto per farmi approfondire i temi della rete e della sicurezza; l'unica cosa fastidiosa sarebbe l'uso della mia
macchina per attività criminose. Riassumo, senza ripetere, le domande che avevo posto: 1) la disabilitazione dell'accesso per password rende SSH ragionevolmente sicuro? 2) l'uso di SSL/TLS rende ragionevolmente sicura la connessione alle porte di pmotion e telecamerep? con "ragionevolmente sicuro" intendo che possa fare a meno di fail2ban. Grazie, ciao, Giuliano PS: ho qualche problema su openssl; mi sa che tornerò all'attacco :-) |