[zorzside]

Uso la release3 ovh, ma non trovo il file di log di fail2ban. Di default non è attivo il log oppure non sta in var/log ?

[user7415]

grazie a tutti per i preziosi suggerimenti,
anche se semplicemente cambiando la porta ssh sono spariti i tentativi di accesso... finirò ugualmente di configurare perbene fail2ban per essere tranquillo.

hmm per quanto riguarda la lista completa dei range ip di ovh, sapete dove posso trovarla?

alla fine si potrebbe anche blacklistare tutti i range sul firewall esclusi quelli dei propri server

Zen, puoi anche blacklistare range di ip interi di countries dove sai che non hai e non avrai mai nulla a che fare..

[Zenzip]

grazie a tutti per i preziosi suggerimenti,
anche se semplicemente cambiando la porta ssh sono spariti i tentativi di accesso... finirò ugualmente di configurare perbene fail2ban per essere tranquillo.

[albert]

... ottima info Mac, quella della lista

@zenzip: controlla il file fail2ban.conf (in centos e' in /etc/fail2ban ... e verifica dove scrive il log

[mac]

In debian il log è di default in

/var/log/fail2ban.log

Per tagliare degli IP specifici (o reti intere) si può usare una blacklist.
Si può realizzare in molti modi, ad esempio editando il file

/etc/fail2ban/action.d/iptables-multiport.conf

e aggiungendo ad actionstart:

cat /etc/fail2ban/ip.blacklist | while read IP; do iptables -I fail2ban- 1 -s $IP -j DROP; done

nel file

/etc/fail2ban/ip.blacklist

si possono quindi aggiungere gli IP da bloccare in modo permanente.

saluti

[albert]

ola

settalo sul conf di fail2ban, sostituiscilo a sysconfig (mettendo il path completo) e restarta

[Zenzip]

piccolo appunto, per impostare il [recidive] nel file fail2ban.local mi conviene leggere nel log di fail2ban giusto? ma non trovo il log di fail2ban sotto /var/log/ ...

Esempio, alla fine del file aggiungo

[recidive]
enabled  = true
filter   = recidive
logpath  = /var/log/fail2ban.log
action   = iptables-allports[name=recidive]
           sendmail-whois-lines[name=recidive, logpath=/var/log/fail2ban.log]
bantime  = 604800 
findtime = 86400
maxretry = 5

ma giustamente non trova il file fail2ban.log sotto /var/log/

help

[Zenzip]

ola,

si, puoi intanto allungare il ban del filtro SSH. Poi attiva il filtro recidive (dopo tot ban rilevati, blocca il recidivo per un tempo molto piu lungo ... decidi tu quanto anche qui).

ps.. i range di ovh sono diversi, per cui prendi spunto dalle mail inviateti da fail2ban e sega il range

io ho una chain ovh ed una per la cina (a buon intenditor)

Grazie, esattamente quello che farò intanto ho allungato a 3600secondi il ban di default, ed ora provvederò ad attivare il recidive di Fail2Ban.
Fatto ciò capirò (non lo so ancora fare) come impostare il il firewall iptables con una chain ovh prendendo come riferimento gli IP segnalati nelle mail, ed una per gli occhi a mandorla che a quanto pare si danno spesso da fare

Ed in ultimo, vedrò di controllare con Fail2Ban anche i log dell FTP, anche se ho già configurato proftpd per accettare connessioni soltanto da 2 IP (casa e ufficio), quindi per esclusione tutti gli altri dovrebbero restare fuori.

grazie ancora albert.

[albert]

ola,

si, puoi intanto allungare il ban del filtro SSH. Poi attiva il filtro recidive (dopo tot ban rilevati, blocca il recidivo per un tempo molto piu lungo ... decidi tu quanto anche qui).

ps.. i range di ovh sono diversi, per cui prendi spunto dalle mail inviateti da fail2ban e sega il range

io ho una chain ovh ed una per la cina (a buon intenditor)

[Zenzip]

Ciao,

fai una chain e sega i range ovh.

Ma poi, attiva il recidive su fail2ban e setta il ban ad 1-n mesi.

Alberto

Ok grazie Alberto, proverò a settare iptables in modo da chiudere in faccia la porta a catena a tutti gli IP nel range di OVH.

Per fail2ban se ho capito bene mi consigli di creare un nuovo filtro con il quale dopo tot-ban ignora il tempo di ban di default (che al momento ho stettato a 900secondi) ed attua un ban permanente o più lungo, ho capito bene?

[albert]

Ciao,

fai una chain e sega i range ovh.

Ma poi, attiva il recidive su fail2ban e setta il ban ad 1-n mesi.

Alberto

[Zenzip]

E' la normalità, visto che normalmente tentano di loggare come root, basta disattivare il login come root tramite ssh e passare per un altro utente, e scalare dopo i privileggi a root. In questo modo i bruteforce non costituiscono un problema.

grazie già fatto questo, tramite SSH l'accesso come root è disabilitato, quindi non devo preoccuparmi? basta disattivare le notifiche di fail2ban per non avere seccature? siamo ad 80 mail in meno di 24ore!

Qualche altro consiglio?

[TheDarkITA]

E' la normalità, visto che normalmente tentano di loggare come root, basta disattivare il login come root tramite ssh e passare per un altro utente, e scalare dopo i privileggi a root. In questo modo i bruteforce non costituiscono un problema.

[Zenzip]

Salve, ho da circa 15 giorni dei problemi di sicurezza con il mio server dedicato.

una settimana fa ho riscontrato e segnalato questo strano problema:
http://forum.ovh.it/showthread.php?6...1100#post31100

ho scritto anche al supporto che ne ignora le cause e rimanda a me la responsabilità nonostante, con log FTP ed SSH, e history della shell alla mano, non ci sia alcuna traccia di comandi che vanno a rimuovere, modificare, aggiornare quei file.
Ho ripristinato manualmente la situazione, ma sono iniziate le preoccupazioni.

Detto ciò da quel momento ho deciso di aumentare drasticamente la sicurezza del mio server, cambiando tutte le password, limitando l’accesso FTP a soli due IP (mi tocca cambiarli una volta al giorno visto che in ufficio non ho ip statico), e l’accesso in SSH a soli due utenti con password molto sicure. Ho inoltre ieri aggiornato all’ultima release OVH passando dalla 3.20 alla 3.22. Ed ho scoperto un’utile funzionalità, ovvero tramite mail mi mi vengono inviati gli altert di Fail2Ban.
Bene da ieri ho ricevuto circa 60 email di ban di vari IP per accesso non autorizzato in SSH al mio server, moltissimi dei quali provengono da Server hostati su OVH! Sono sicuro che le mie password non siano in mano a nessun altro, e che quindi si tratti di attacchi ripetuti e in maniera massiccia.

Come è possibile limitare questa problematica? se molti di questi “attacchi” provengono da server hostati sulla stessa rete OVH il supporto non può intervenire?

E’ normale che il mio server sia così esposto? Cosa posso fare per proteggermi meglio?

Grazie per l’aiuto