VPS Aruba - Tentavi Intrusione Ssh

[stuk]

Salve a tutti, ho un VPS su aruba, dove ogni giorno qualche bot cerca di accedervi su ssh, con utenti inventati. C'è qualcosa che posso fare per prevenire questi attacchi? Ok che non portano a niente...però magari un giorno riusciranno ad indovinare la password.
Grazie.

[WizOfOz]

Punto 1. Cambia (con attenzione!!!) la porta di default del servizio..

Punto 2. Puoi impedire l'accesso root e consentire sono accessi non-privilegiati.. in questo modo anche se qualcuno accedesse al server avrebbe poteri limitati sulla macchina.

Punto 3. La cosa più sicura è impedire l'accesso con password e abilitare solo quello con certificati... in questo modo non esiste un accesso con password e nessuno può entrare se non ha il certificato installato (che ovviamente tu non darai a nessuno )

Ciao

[Rebel]

Salve a tutti, ho un VPS su aruba, dove ogni giorno qualche bot cerca di accedervi su ssh, con utenti inventati. C'è qualcosa che posso fare per prevenire questi attacchi? Ok che non portano a niente...però magari un giorno riusciranno ad indovinare la password.
Grazie.

Installa questo:

Main Page - Fail2ban

Ci sono svariate guide su internet.

Poi come ti hanno detto giustamente sopra, cambia porta e disabilita l'utente root.
Per farlo apri il file:

/etc/ssh/sshd_config

e cambia la riga:

PermitRootLogin yes

in

PermitRootLogin no

Ti consiglio infine di abilitare un solo utente al login ssh e scegliete una password molto lunga, con spazi e punteggiatura, ad esempio un'intera frase come: "(nel mezzo del cammin di nostra vita)".
In questo modo userai quell'utente per accedere ad ssh e poi passerai root con su.
Per farlo edita sempre lo stesso file e aggiungi:

AllowUsers nomeutente

Stai sicuro che con pass come queste e' mooolto difficile che riescano a farti un brute force.

[stuk]

Grazie a tutti, cmq già la password è moooolto lunga, però cmq tranne con il certificato, credo di aver capito che non si può evitare questo genere di attacchi. Pensavo ad una qualche regola iptables, del tipo se sbagli accesso 5 volte, blocco ip per 1 ora...ma a quanto ho letto non si può fare con aruba.

[WizOfOz]

@stuk Prima di fare qualsiasi cosa documentati su cosa stai facendo e possibilmente prova prima in locale con un una vps installata sul tuo PC.
Se fai qualche errore rischi di bloccarti fuori dal VPS e non riuscire più ad accedere...
Una volta fatte le modifiche devi riavviare il servizio perchè siano effettive.

i comandi che ti ha dato rebel servono solo per il mio punto 2... per gli altri leggiti questo
HowTos/Network/SecuringSSH - CentOS Wiki
E' scritto per CentOS ma più o meno va bene per tutte le distro

[WizOfOz]

Grazie a tutti, cmq già la password è moooolto lunga, però cmq tranne con il certificato, credo di aver capito che non si può evitare questo genere di attacchi. Pensavo ad una qualche regola iptables, del tipo se sbagli accesso 5 volte, blocco ip per 1 ora...ma a quanto ho letto non si può fare con aruba.

anche se non puoi bloccare gli attacchi li puoi rendere inutili.. se non si entra con password potranno provarci per 100 anni ma non entreranno...

questi attacchi sparano nel mucchio sperando di trovare un "fesso" (e ce ne sono ) che lasci un accesso root ssh con password facili da indovinare

[stuk]

anche se non puoi bloccare gli attacchi li puoi rendere inutili.. se non si entra con password potranno provarci per 100 anni ma non entreranno...

questi attacchi sparano nel mucchio sperando di trovare un "fesso" (e ce ne sono ) che lasci un accesso root ssh con password facili da indovinare

Si lo so, ho visto nei log quanto ci provano, solo che anche se la banda che mi occupano è praticamente nulla (visto che poi di solito avvengono di notte) pensavo di ottimizzare il più possibile

[mewberry28]

già cambiando la porta di ascolto di ssh risolvi il problema. solitamente sono scan automatici che agiscono solo sulla porta di default.

per quanto riguarda il PermitRootLogin già aruba lo imposta di default su no per loggarti alla macchina infatti ti dovrebbe aver fornito un user di del tipo admin+numero d'ordine.

[Rebel]

non e' che risolvi molto il problema, non ci vuole molto a capire su che porta e' in ascolto ssh.

cmq, tralasciando la soluzione tramite certificato, che e' la migliore ma secondo me un po' scomoda se ti colleghi da luoghi diversi e ti devi portare quindi sempre dietro il certificato, limitando gli account che possono utilizzare ssh e usando password complesse, il problema e' quasi risolto.

[stuk]

Ripeto, il mio obbiettivo era quello di non aver nessun tentativo di login, cambiando porta credo che il 90% dei bot ci rinunci...credo...

[Valeriano Manassero]

Ripeto, il mio obbiettivo era quello di non aver nessun tentativo di login, cambiando porta credo che il 90% dei bot ci rinunci...credo...

Credi male, del resto non è colpa tua se moltissimi consigliano questa pratica che è poco più di un palliativo.
Intanto, per maggior sicurezza, lavori esclusivamente a certificati. In effetti è meno comodo, ma estremamente più sicuro.
A quel punto, dovresti anche filtrare il traffico che non arriva dal tuo host, un pelino più complesso se non hai un ip fisso da cui connetterti.
A quel punto puoi anche pensare di cambiare porta, tanto per giocare a nascondino, anche se è solo un trucchetto (ed i bot attuali sono svegli).
Un ulteriore forma di sicurezza è lavorare di fino con iptables in modo che, dopo un tot di tentativi falliti, blacklisti l'ip per un po'.

Questo è un livello accettabile di sicurezza, solo il cambio porta è una pratica assolutamente inutile.

[2busy]

che poi, a costo di essere pesante e rompipalle, vorrei conoscere chi è quel sistemista che amministra i server dalla prima macchina che gli capita tanto da non poter utilizzare i certificati...

[WizOfOz]

Credi male, del resto non è colpa tua se moltissimi consigliano questa pratica che è poco più di un palliativo.
Intanto, per maggior sicurezza, lavori esclusivamente a certificati. In effetti è meno comodo, ma estremamente più sicuro.
A quel punto, dovresti anche filtrare il traffico che non arriva dal tuo host, un pelino più complesso se non hai un ip fisso da cui connetterti.
A quel punto puoi anche pensare di cambiare porta, tanto per giocare a nascondino, anche se è solo un trucchetto (ed i bot attuali sono svegli).
Un ulteriore forma di sicurezza è lavorare di fino con iptables in modo che, dopo un tot di tentativi falliti, blacklisti l'ip per un po'.

Questo è un livello accettabile di sicurezza, solo il cambio porta è una pratica assolutamente inutile.

@valeriano
Infatti sono tutte cose che sia io (certificati) che rebel (fail2ban) gli abbiamo consigliato di fare...
@stuk
Comunque se vuoi proteggere il tuo server cerca le "falle" ben più gravi sul lato "applicativi web", tipo sql injection e cose simili... in genere sono le più facili da sfruttare

[444523]

Comunque se vuoi proteggere il tuo server cerca le "falle" ben più gravi sul lato "applicativi web", tipo sql injection e cose simili... in genere sono le più facili da sfruttare

Non posso che quotare... al 90% passano sempre da lì...

[FlameNetworks]

Salve a tutti, ho un VPS su aruba, dove ogni giorno qualche bot cerca di accedervi su ssh, con utenti inventati. C'è qualcosa che posso fare per prevenire questi attacchi? Ok che non portano a niente...però magari un giorno riusciranno ad indovinare la password.
Grazie.

Il consiglio che posso darti, oltre a quelli già forniti dagli amici nei loro precedenti interventi, è di utilizzare uno script del genere (che si trova online) che blocca il traffico da determinate nazioni, in base al relativo Country Code:

#!/bin/bash
### Block all traffic from AFGHANISTAN (af) and CHINA (CN). Use ISO code ###
ISO="af al dz as ad ao ai ag ar am aw au az bs bh bd bb by bz bj bm bt bo ba bw br io bn bg bf bi kh cm ca ky cf cl cn co cd ck cr ci hr cu cy dj do ec eg sv er ee et fo fj gf pf ga gm ge g
h gi gr gl gd gu gt gw gy ht va hn hk hu is in id ir iq ie il jm jp jo kz ke ki kr kw kg la lv lb ls lr ly li lt lu mo mk mg mw my mv ml mt mr mu mx fm md mn ma mz mm na nr np an nc nz ni n
e ng nu nf mp om pk pw ps pa pg py pe ph pl pt pr qa ro ru rw kn lc ws sa sn sc sl sg sk si sb za lk sd sr sz sy tw tj tz th tg to tt tn tr tm tv ug ua ae uy uz vu ve vn vg vi ye zm zw"

### Set PATH ###
IPT=/sbin/iptables
WGET=/usr/bin/wget
EGREP=/bin/egrep

### No editing below ###
SPAMLIST="countrydrop"
ZONEROOT="/home/xxx/iptables"
DLROOT="http://www.ipdeny.com/ipblocks/data/countries"

cleanOldRules(){
$IPT -F
$IPT -X
$IPT -t nat -F
$IPT -t nat -X
$IPT -t mangle -F
$IPT -t mangle -X
$IPT -P INPUT ACCEPT
$IPT -P OUTPUT ACCEPT
$IPT -P FORWARD ACCEPT
}

# create a dir
[ ! -d $ZONEROOT ] && /bin/mkdir -p $ZONEROOT

# clean old rules
cleanOldRules

# create a new iptables list
$IPT -N $SPAMLIST

for c  in $ISO
do
        # local zone file
        tDB=$ZONEROOT/$c.zone

        # get fresh zone file
        $WGET -O $tDB $DLROOT/$c.zone

        # country specific log message
        SPAMDROPMSG="$c Country Drop"

        # get
        BADIPS=$(egrep -v "^#|^$" $tDB)
        for ipblock in $BADIPS
        do
           $IPT -A $SPAMLIST -s $ipblock -j LOG --log-prefix "$SPAMDROPMSG"
           $IPT -A $SPAMLIST -s $ipblock -j DROP
        done
done

# Drop everything
$IPT -I INPUT -j $SPAMLIST
$IPT -I OUTPUT -j $SPAMLIST
$IPT -I FORWARD -j $SPAMLIST

# call your other iptable script
# /path/to/other/iptables.sh

exit 0

Attento a non inserire "it" nella variabile ISO altrimenti ti chiudi fuori.

Ciao,

F.