Newsgroup: it.comp.os.linux.sys
Titolo: iptables, ssh e recent

salve a tutti,
per evitare i continui tentativi di connessione al mio ssh dell'ufficio che,
anche se destinati a fallire per l'utilizzo esclusivo della key, mi
riempiono il log file per tutta la notte con "invalid user <nomeassurdo>"
ho cercato con google e ho trovato questo pezzo di codice che sembra
funzionare alla perfezione:
	$IPT -N SSH
	$IPT -N SSH_BLACK
	for x in `cat /root/.blacklist`; do
[0]		$IPT -A SSH -i eth0 -s $x -d $MYIP -j DROP
	done
[1]	$IPT -A SSH_BLACK -m recent --name SSH_BLACK --set -j LOG \
		--log-level warn --log-prefix "ABL: +SSH: "
[2]	$IPT -A SSH_BLACK -j REJECT
[3]	$IPT -A SSH -m recent --name SSH_BLACK --update --seconds 3600 -j REJECT
[4]	$IPT -A SSH -m recent --name SSH --rcheck --seconds 60 \
		--hitcount 5 -j SSH_BLACK
[5]	$IPT -A SSH -m recent --name SSH --rcheck --seconds 2 -j LOG \
		--log-level warn --log-prefix "RATE: "
[6]	$IPT -A SSH -m recent --name SSH --update --seconds 2 -j REJECT
[7]	$IPT -A SSH -m recent --name SSH_BLACK --remove -j LOG \
		--log-level warn --log-prefix "ABL: -SSH: "
[8]	$IPT -A SSH -m recent --name SSH --set -j ACCEPT
[9]	$IPT -A INPUT -m state --state NEW -p tcp -m tcp --dport 22 -j SSH
vorrei una conferma di aver capito bene:
1) l'ultima riga [9] invia tutti i nuovi tentativi di connessione alla chain SSH
2) all'inizio droppa tutti quelli caricati dalla mia blacklist [0]
3) la regola [3] vede se l'IP e' gia' in /proc/net/ipt_recent/SSH_BLACK e, in
   questo caso, aggiorna il timestamp e REJECT per una ulteriore ora.
4) il check della [4] vede se entro il minuto si sono tentate 5 connessioni, nel
   qual caso reinvia alla chain SSH_BLACK, che aggiunge, logga e REJECT.
5) la [5] e la [6] sono "indipendenti" dal resto, nel senso che se i tentativi
   si ripetono entro i 2 secondi (brute force) a prescindere da SSH_BLACK fa
   il REJECT. Non aggiunge niente alle chain in /proc/net/ipt_recent ??
6) se si arriva alla [7], elimina dalla BLACK_LIST e logga e accept [8].
grazie anticipate ...
Antonio67
-- 
Never try to teach a pig to sing.
It wastes your time and annoys the pig.

 funzionare alla perfezione:
Io per evitare questi tentativi continui di accesso uso fail2ban, 
semplice e veloce.
http://www.fail2ban.org/wiki/index.php/Main_Page
La pacchettizzazione Debian (aehm, non è il giorno giusto per parlare di 
sicurezza & debian, è vero) prevede già la regola per ssh attiva: dopo 
il 3 o 6 tentativo di accesso SSH banna l'IP per un tempo a piacere, di 
default 30 min.
Usa IPtables ma fa una sua regola a parte.
Angelo

 anche se destinati a fallire per l'utilizzo esclusivo della key, mi
Io ho banalmente risolto spostando la porta dell'SSH su una porta
diversa dalla 22. Salvo casi particolari, la connessione SSH è una cosa
diciamo "privata", non vedo perché usare per forza la porta standard.
Alternativamente, puoi impostare il firewall per accettare connessioni
SSH solo dalle fasce di IP appartenenti ai provider che usi per la
connessione (insomma taglia fuori tutta la fuffa di Cina, Taiwan e
compagnia bella da dove arriva il 99% dei tentativi).
Il metodo dello scripting per bloccare le connessioni entranti in
automatico l'avevo provato anni fa per l'smtp, ma è destinato a fallire
per due motivi:
a) se lo fai IP per IP, a parte avere un file di blacklist ingestibile,
non serve praticamente a niente visto che gli IP da cui provengono gli
attacchi sono sempre diversi. Bloccarli *dopo* che hanno tentato, non
serve più a granché;
b) se filtri per subnet, prima o poi capita lo stronzo sulla subnet del
*tuo* provider che si becca un worm e tenta l'accesso... e dopo resti
chiuso fuori anche tu da remoto (mi è successo...).
Poi magari hai esigenze diverse e per te va benone eh (non pretendo di
essere depositario di verità assolute, sia chiaro!).
-- 
Massimo Bacilieri AKA Crononauta 
ICQ:4005815

 1) l'ultima riga [9] invia tutti i nuovi tentativi di connessione alla chain SSH
Piu' precisamente, tutti i pacchetti NEW che arrivano sulla 22/tcp.
Compresi quelli con ip sorgente spoofato uguale a quello da dove ti
connetti normalmente tu ;-) 
Farei un paio di riflessioni:
1) che male fanno un po' di righe di log in piu'?
2) se lo usi solo tu e pochi altri, perche' non fare ascoltare sshd
   su porte non standard ed evitare d'installare altro software che
   aumenta inutilmente la complessita' del sistema?
3) le chiavi le hai create sulla tua slack o su una debian >:-> Che
   di questi periodi e meglio usare le password, 'n si sa mai :-)
Fabio

 chiuso fuori anche tu da remoto (mi è successo...).
infatti controllo sempre la blacklist prima di "listarli" definitivamente ...
adesso vedo un po' come va ... e magari faccio la prova con il cambio
di porta ...
grazie per la risposta ...


    di questi periodi e meglio usare le password, 'n si sa mai :-)
?? questa non l'ho capita ... mi sfugge qualcosa ?
ciao ...


 
http://www.fail2ban.org/wiki/index.php/Main_Page
molto interessante ... ho letto il tutorial e la doc ...
grazie ...


> ?? questa non l'ho capita ... mi sfugge qualcosa ?
Dove hai vissuto negli ultimi due giorni? :-) Leggi il post di 
Arne Sknussem "Sempre a proposito di...".

    di questi periodi e meglio usare le password, 'n si sa mai :-)
'Stard...:)
(però, al primo upgrade si autoinstalla openssh-blacklist, si reinstalla
openssh e si rigenerano le chiavi)

 dal quale mi connetto ...
geoip lookup, ad esempio, tipo maxmind.

 Arne Sknussem "Sempre a proposito di...".
mamma mia !! altro che "buco" ;-))
per fortuna tutto creato sulla slack !!
P.S.
sto appresso a mia figlia con la tonsillite ;-((
