Newsgroup: it.comp.os.linux.sys
Titolo: Re: Digicom Firegate

 nigeriani mi esauriscono la partizione di log in pochi giorni)
Hai valutato l'ipotesi di risolvere questo problema cambiando la porta
su cui ascolta sshd?
Fabio

 Fabio
-- 
Imagine if every Thursday your shoes exploded if you tied them the usual
way.
This happens to us all the time with computers, and nobody thinks of
complaining.

 basta fare uno scan delle porte e sei contento
Lui ha posto come moticazione del blocco la lunghezza dei files di log
dovuti a programmi di bruteforce che tentano l'accesso.
Sebbene ti possa salvaguardare dal bruteforce con le chiavi, non ti
salvaguardi dalla rumenta nei log.
Proprio perchč sono scripts che "ce provano" in automatico, cambiare la
porta, dove possibile, č la soluzione migliore (pure se a me non piace) per
evitare rumenta nei log.
Non credo che questi script facciano scansioni di porte per fare
bruteforce, a meno che il payoad della macchina non sia cosě importante, ma
in quel caso si ricade in un'altra tipologia di approccio per cercare di
ottenere l'accesso.
Quindi, come soluzione per il problema esposto nel thread, la soluzione,
ebbene si, č furba.
Max

 basta fare uno scan delle porte e sei contento
Cambiando porta, non stai facendo security through obscurity, ma stai,
semplicemente, eliminando il rumore di fondo nei log del 99% degli
strumenti di scansione automatica o semiautomatica, molto più banalmente.

 
Hai pensato all'utilizzo di un sistema di port-knocking ?
Se il tuo firewall (non lo conosco) non fa NAT, puoi farlo con facilita'.
Sul firegate autorizzi tutto il traffico della porta 22 + almeno paio di
altre a tua scelta verso il tuo server; su quest'ultimo metti un bel
DROP tramite iptables su tutte le porte. 
Dopoiche' attivi un bel knockd, che si mette ad ascoltare tutte le porte, a 
prescindere da iptables, in modo promisquo. Se riceve una sequenza giusta, 
tlac, come per magia apre la porta 22 SOLO all'IP che ha generato il 
traffico.
Io l'ho usato con molta efficacia su un web server pubblico: una volta ho 
provato a lasciare aperta la 22 e ho ricevuto qualcosa tipo 480 tentativi 
di combinazione username/password in meno di un ora. Tuttavia avevo 
necessita' di poterlo amministrare da remoto.
Se invece il fw fa NAT, la cosa e' piu' complicata; piu' che altro non hai 
modo di far capire al tuo server l'ip originario.
-- 
Non c'e' onore nel morire massacramente.

 
beato te...
Non è che mi diano fastidio (auth solo con chiave), però è tutta fuffa 
da controllare.
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
La gente diventa cio' che e'.  Persino Beethoven e' diventato Beethoven.
		-- Randy Newman

 
Beh, dipende da come il pacchetto viene riscritto dal nat del firewall: 
potrebbe anche riscrivere SIA mittente CHE destinatario, in modo che il 
server riponda a lui e sia poi lui a ritraslare entrambi gli indirizzi 
all'inverso. Comunque, se le cose stanno cosi' sei a cavallo: puoi aprire 
la porta SSH solo all'ip che ha bussato nella maniera corretta.
E' un semplice strato di protezione in piu' che tuttavia ti toglie il 
99.95% della fuffa dai file di log.
Io ti consiglio a questo punto knockd; supportato da debian (se usi una 
debian-based) o facilmente reperibile su 
http://www.zeroflux.org/cgi-bin/cvstrac/knock/wiki
E comunque ti consiglio 
http://www.portknocking.org/
 per le info generali 
sul sistema in se.
