Newsgroup: it.comp.os.linux.sys
Titolo: SSH attacato

Salve a tutti,
ho la necessità di tenere aperta su internet la porta ssh per amministrare una
rete, ma ultimamente sto notando che i tentativi di accesso al server sono
triplicati da ogni parte del mondo ogni giorno c'è un nuovo IP che ci prova.
Naturalmente tengo aggiornato il server regolarmente e cambio le password
quasi ogni settimana, ma non mi sento sicuro.
La mia domanda è: esiste un programma su linux che abilita la regola del
firewall della porta ssh all'accorenza tramite un client. Stavo pensando di
svilupparlo io ma prima di procedere volevo accertarmi che qualcuno non aveva
già realizzato qualcosa del genere.
La mia idea è questa: 
un modulo kernel 2.4 che tramite gli hook di netfilter intercetta certi tipi
di pacchetti 
                   |
                  \ /
e invia la notifica ad un demone che gira in user space che una volta
stabilita una sequenza di autenticazione esegue un comando che potrebbe
essere l'abilitazione della apertura della porta ssh solo all'ip autenticato.
Inoltre ci sarebbe il client che invia i pacchetti alla macchina interessata.
Grazie a tutti per l'aiuto
Andrea

 firewall della porta ssh all'accorenza tramite un client.
? hu ? cioe'... tu vuoi un client che si collega al tuo server
(come?) e _altera il firewall_ ??? e questo ti sembra meno 'pericoloso'
che lasciare ssh aperto?
Davide
-- 
The trouble with superheros is what to do between phone booths.
		-- Ken Kesey

 Grazie a tutti per l'aiuto
http://www.linuxjournal.com/article.php?sid=6811
-- 
Vincenzo

 essere l'abilitazione della apertura della porta ssh solo all'ip autenticato.
Inutile, difficile e pericoloso. Sposteresti solo il problema da un'altra
parte (ovvero nel modulo e nelle sue eventuali problematiche).
Fai loggare iptables e fai uno qualcosa che analizzi i logs.
Quando individui un pattern fidato (tipo l'arrivo di un SYN con una
daterminata combinazione di porta sorgente/porta destinazione/valore di
syn, whatever...) apri la 22 a quell'ip per tot secondi...
Hola...
-- 
cat: .signature: No such file or directory

 firewall della porta ssh all'accorenza tramite un client. <>
Potenzialmente si, ma non ne vale la pena.
Utilizza l'autenticazione mediante chiavi ssh, se puoi riduci il pool di
ip che possono accedere alla tua macchina, assicurati che solo gli
utenti che ritieni tu opportuno possano accedere via ssh, e questi tutti
con chiave. Disabilita l'accesso ssh via password e vai tranquillo.
I recenti "tentavi" sono cmq di tipo guess (tentano admin e guest o
altro).
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Company slogan: The Mandatory Beatings Will Continue Until Morale Improves.

 rete, ma ultimamente sto notando che i tentativi di accesso al server sono
Anche io ho la stessa problematica e ho fatto una cosa stupidissima ho 
attivato ssh su una porta non standard cosi se vogliono trovarla devono 
farmi almeno un port-scanning.
Sul  firewall ho snort attivato con un script in perl (
guardian.pl
) che 
analizza i log e nel caso di un port-scanning mi blocca l'ip incriminato 
  x 48 ore.
Da quando ho fatto questo (circa 1 mese ) i tentativi da una decina al 
giorno sono passati a 0.
Ciao

 
Quello che vorrei è che la porta ssh non sia aperta a tutti gli ip sempre, ma
solo ad uno determinato (che non conosco a priori) in un preciso istante.
Sicuramente aggiungere un nuovo componente al server aumenta le probabilità
della presenza di un bug. Secondo me vale la pena di provare.
Andrea

   x 48 ore.
Pessima idea.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
There are three kinds of people: Those who can count & those who can't.

 Pessima idea.
Io la ritengo buona a certe condizioni.
Personalmente la applico così (con metodologie differenti ma con queste
funzionalità):
- Se qualcuno portscanna sticazzi.
- Se qualcuno "tocca" certe porte sensibili Metto in deny quell'IP per
qualche minuto (non qualche ora) in modo da far risultare comunque tutto
chiuso. L'utilizzo di queste porte sensori è un ottimo deterrente per
bloccare gli script kiddies che analizzano porte standard alla ricerca di
vuln (soprattutto microsoft-oriented)
- Ovviamente ho alcuni IP che sono TRUSTED e che non inserirò mai nella
blacklist.
Un altro medodo che ritengo utile è l'utilizzo di VPN.
Un bell'OpenVPN sul server è cosa buona e giusta per avere accesso alla
macchina, previa chiusura totale di ssh dall'esterno a meno di qualche
trusted-client con ip fisso.
Max

 
Perche ???
Forse perche cosi mi espongo a un DDOS??
L'unico problema del genere potrebbe venire se usano gli ip del dns.

 trusted-client con ip fisso.
e quale sarebbe la differenza tra tenere aperto ssh e tenere aperto
openvpn?!?


 L'unico problema del genere potrebbe venire se usano gli ip del dns.
O quello di un router, o quello del tuo router, o quello della dorsale
verso gli usa, o verso ita... Devo continuare?
Per altro, spoofare un ip per fare portscan/porttouching e`, se non
banale, estremamente semplice.
Se _proprio_ vuoi fare una cosa del genere, rivedi il commento di
Citrix che pone _ampie_ condizioni sull'uso di una pratica del genere.
Che in ogni caso mi sento fortemente di sconsigliare.


 preciso istante.
Cosi' che, se ti cade la connessione da quell'ip e te ne assegnano un altro,
hai un bel DoS finche' non resetti il blocco o non ti scade il timeout.
Ti dico la verita', non mi pare la pensata piu' brillante dell'anno.
Ciaotutti,
*
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 openvpn?!?
beh.
Prima di tutto se hai un server remoto e devi accedere via ssh, i casi
sono:
1) lasci ssh aperto al mondo (ne stiamo parlando ora, talvolta č una buona
cosa, talvolta meno)
2) se hai IP fisso dalla sede dive amministri il server, abiliti della ACL
ergo dalla sede puoi accedere, dal resto del mondo no.
3) estendendo il punto 2) con un openvon, freeswan,opensvan o quello che
vuoi, puoi guadagnare accesso alla macchina nel tunnel, pur avendo ip
dinamico. Possiamo disquisire all'infinito sulla utilitą di questa
soluzione, ma IMHO č un ottimo compromesso tra la 1) e la 2). SSH
risulterebbe chiuso al mondo ma l'accesso sarebbe aperto tramite VPN. Tutto
qui il vantaggio che ci vedo.
Max

 qui il vantaggio che ci vedo.
sisi, questo l'ho capito. Quello che non ho capito è la vpn: tra chi e
chi?
Se un capo della vpn è il server, l'altro chi è? Il client roadwarrior
che se ne va a zonzo?
Perchè, in tal caso, che differenza c'è tra una compromissione ai danni
di openvpn e una ai danni di ssh?
Una volta compromesso il servizio sempre dentro la stessa macchina sono...


 
Scusa ma.... mi sembrava ovvio che queste considerazioni nelle 
configurazione dello snort e del guardian andassero tenute in 
considerazione.
Posso essere d'accordo sulle 48 ore di deny che forse sono un po' troppe.
Ciao

 Una volta compromesso il servizio sempre dentro la stessa macchina sono...
Su questo non ci piove.
Però unisci il vantaggio del roadwarrior con la porta ssh chiusa
pubblicamente.
Aggiungo però che se con openvpn si utilizzano non le preshared ma dei
certificati ssl con delle belle password, anche in caso di furto si è
ragionevolmente sicuri di non subire danni nel breve tempo. E si possono
aggiornare le chiavi con una certa calma con la garanzia che la VPN non
sarebbe "negoziata".
Max

 Posso essere d'accordo sulle 48 ore di deny che forse sono un po' troppe.
Eh.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
If work, don't fix it.

 sarebbe "negoziata".
beh.. questo di per se vale (o può valere) anche per ssh...
Se la metti in questi termini, tantovarrebbe telnet in stunnel -v 3...


 
Il firewall reattivo lo uso almeno da 3 anni e dei problemi potenziali 
che tanto stai decantando non mi sono mai successi.
Dirai che sono fortunato .....ebbene si son fortunato.
Cmq son tutti problemi che con un flush delle regole di iptables 
relativi agli ip incriminati posso risolvere in 5 secondi.
Ma la cosa fondamentale è che deve essere un buon compresso tra 
sicurezza e usabilità.
Tu hai proposto le chiavi, ma prova a farle usare ad un amministratore 
delegato che ha 60 anni che di portatili non ne vuole sentire nemmeno 
parlare e che cmq vuole collegarsi per farsi una situazione economico 
patrimoniale in tempo reale da un pc presso un internet point in un 
albergo di Tokio.
Cmq. sono d'accordo con Citryx dove è possibile Vpn altrimenti tengo ssh 
  aperto su intenert su porta non standard e firewall reattivo.
By

 altro).
Questa e` una cosa che non ho mai capito.
Perche' dovrebbe essere piu` sicura l'autenticazione mediante chiavi?
Ovvero, se ti bucano la macchina su cui c'e` la chiave (o la rubano -
metti un portatile), automaticamente e` bucata anche quella a cui accedi
tramite autenticazione basata sulle chiavi.
O e` possibile proteggere la chiave tramite password?
Se mi sono perso qualcosa dimmelo.
Andrea

 O e` possibile proteggere la chiave tramite password?
passphrase per chiudere la chiave privata....


 albergo di Tokio.
E perche` mai costui deve collegarsi in ssh alla macchina?
Mi pare che tu stia un po` deviando... Se mi sbaglio me ne scuso, ma ho
come l'impressione che questa frase sia un po` buttata li`.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
"I just drank WHAT?" (Socrates)

 Se la metti in questi termini, tantovarrebbe telnet in stunnel -v 3...
Si per carità.
Tanto vale spegnere ssh e andare di accesso locale !
Cioè...
Di modi se ne possono usare tonnellate.
Tutto sta a trovare il giusto compromesso tra sicurezza ed usabilità che
vogliamo utilizzare.
Personalmente stunnel non lo uso ma non dubito che sia una buona soluzione.
Ad ogni modo ci tengo a sottolineare (non per te, Skull, ma per altri) che
uno può utilizzare le policy di sicurezza più paranoiche del mondo ma se
non aggiorna i demoni quando esce qualche vulnerabilità direi che tutte le
policy sono inutili.
Vedo in giro ancora degli apache 1.3.18 e roba ancora più vecchia... che
tristezza.
MAx

 
Beh esistono gestionali che girano in emulazione di terminale quindi 
anche su ssh.
Naturamente non è la macchina di produzione ma una appositamente 
replicata e con solo i dati e progammi minimi necessari.
Evidentemente abbiamo problemi diversi tu quello di dover amministrare 
la macchina da remoto, e io invece di dover fare usare un Gestionale da 
remoto a diversi utenti.

 replicata e con solo i dati e progammi minimi necessari.
A me pare in generale, un po` pericoloso. E` cmq una valutazione "a
sensazione".
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
!!! THIS SIGNATURE HAS BEEN CENSORED !!!

 - Se qualcuno "tocca" certe porte sensibili ...
[cut]
Quali porte "sensibili" usi?
Grazie
Ivo

 
A me sta cosa fa proprio schifo....ma valla a spiegare al famoso AD e ai 
commerciali.
Non puoi immaginare le schifezze che ho dovuto inserire in quella 
versione del Gestionale per limitarlo alle funzioni e ai dati necessari.
Ciao.


Quindi, portando a conclusione il ragionamento altrui, non e`
piu` comodo che usare la password direttamente, ma perche' e`
piu` sicuro?
Andrea

 Andrea
Perche ci sono 2 livelli di sicurezza.
1 La chiave
2 la Password.
Se ti fregano la password e non hanno la chiave mica riescono a collegarsi.
Idem per l'inverso.
by by


Grazie, direi che la risposta ha senso :-), la domanda forse meno, ma se 
non ci fosse stata non avrei potuto leggere la risposta ;-)
Andrea

 piu` sicuro?
Beh, e` piu` comodo a prescindere, sopratutto se usi ssh-agent.
E` piu` sicuro perche` hai e due livelli di protezione, e perche` sposti
la debolezza, sulla fisicita` di una macchina.
L'autenticazione avviene sempre tra chiavi: queste non sono
(praticamente[1]) indovinabili.
Anche se, qualcuno si impossessasse del computer con la chiave
(privata), dovrebbe _ancora_ avere a che fare con la passphrase (non
obbligatoria, ma ampiamente consigliabile, poi YMMV).
Il problema con le password e` il solito: quelle serie e difficili, lo
sono talmente che le scrivi. Quelle che ricordi a memoria, tipicamente
sono _tecnicamente_ indovinabili.
Se le scrivi, hai il problema di sicurare il posto in cui le scrivi. No,
il post-it non e` una buona scelta. :) [2].
Poi, non so come funziona da voi, ma "prendere possesso fisico della
macchina che ha le chiavi", mediamente, significa bypassare 3
autenticazioni (bios, lilo, utente).
A meno di non smontare il disco ovviamente.
[1]
In teoria no, ma la potenza di calcolo e/o il tempo richiesto sono
sufficientemente scoraggianti per tentare altri tipi di approcci.
Ovviamente, in assenza di bug.
[2]
Per questo, e per evitare di avere 3 password su decine di macchine,
chiavi e diavolerie similari, uso un app del palm (keyring). Eppero` il
punto debole diventa il palm... ecc. :)
Del resto cercare sicurezze assolute significa non aver capito come
funziona la sicurezza. Si deve ricercare un livello di sicurezza tale da
far desistere un attacker (e _non_ il /compromesso/ con l'usabilita`. Io
non so chi vi ha detto sta cosa, ma non la ripeterei in giro).
Se il compromesso e` l'usabilita`, di solito, bisogna riprogettare la
situazione (o dormire sempre con l'ansia).
My 0.2 cent.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Security-wise, NT is a server with a "Kick me" sign taped to it.

 My 0.2 cent.
My 0.1 cent.
Andrea

 non so chi vi ha detto sta cosa, ma non la ripeterei in giro).
Io ho qualche dubbio e questa frase, detta da te, che sei solitamente
pacato nei commenti mi lascia alquanto perplesso.
L'usabilità è quella che si deve garantire agli utonti che usano la
macchina e all'amministratore quando la amministra.
Ho avuto delle macchine talmente blindate con grsec che per installare dei
semplici script per analizzare dei log o per fare delle procedure di
backup, ci volevano ore a configurare il sistema. Desiste l'"haqquer" di
turno ma desiste ache l'admin che si ammala di orchite.
Come in ogni cosa ci vuole un pò di sale in zucca. La macchina deve
funzionare e non deve dare problemi ne all'admin ne agli utonti.
L'usabilità va intesa in questo senso.
Lo dici tu stesso che la sicurezza assoluta non esiste. Fare in modo che
una macchina sia usabile non vuol dire necessariamente rendere la vita
facile ad un attacker.
Max 

 autenticato.
senti, e' solo un'idea (magari stupida :-) ed io non li ho mai provati ma
non potrebbe andare bene uno di quei tool tipo sebek? in pratica sono dei
rootkit "benevoli" che stanno nascosti e rispondono a determinati
pacchetti/password e poi potresti attivare ssh con quello
ciao
Ti

 uno script in batch su un'altra macchina, come fai?
Tipicamente, con un utente dedicato, magari non accessibile da rete, che
ha una chiave senza passphrase. Poi, YMMV.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------


 facile ad un attacker.
Premessa: da prendere tutto IMHO, anche se, non solo mio.
Il punto di quanto scrivo sopra e` lievemente trasversale: sicurezza e
usabilita` non sono nello stesso dominio di problemi, lo _sembrano_ .
L'usabilita` dei sistemi dipende dalla loro architettura, non dalla loro
sicurezza.
Cosi` la sicurezza dei sistemi, non puo` dipendere dalla loro
usabilita`.
Ecco perche` dico che se ti poni il problema di compromesso,
verosimilmente, il problema e` di revisione di architettura. Che poi,
per motivi terzi (magari di budget) non si possa fare certe scelte, e`
altro paio di maniche.
E` chiaro che poi, declini le tue scelte "teoriche" sulle attivita`
pratiche. Ma questo non ne sancisce la regola, sono una deroga.
Per fare un esempio pratico (e magari sbagliato, ma deve solo rendere
l'idea):
io ho un auto a benzina. Mi capita una sera che sono rincitrullito, e
anziche` mettere benzina verde, al self-service, metto benzina rossa.
La macchina non esplode, ma va lo stesso, forse piu` avanti dovro` far
ripulire qualcosa.
Questo fa scaturire alcune affermazioni, ma non valide altre:
e` vero che la macchina va a benzina verde.
e` vero che la macchina ha continuato a funzionare nonostante avessi
messo un po` di benzina sbagliata
NON e` vero che la macchina va a benzina verde e rossa,
indifferentemente.
NON e` vero che dipende da quanti soldi ho, il tipo di benzina che posso
mettere.
Quando sei costretto a declinare sulla sicurezza, per questioni di
"usabilita`" significa che verosimilmente dovresti spostare a livello
fisico/logico/livello la tale applicazione/servizio/feature.
Che poi tu possa decidere di derogare e accettare un ragionevole (per
te, pero`, non come regola) compromesso, e` evidente che si puo` fare,
come e` evidente che potresti non avere mai problemi, ma non puo` essere
una regola.
Il resto, e` budget, disponibilita`, capacita`, e altro ancora. Ma non
e` compromesso. O in alternativa, miri ad un target di sicurezza piu`
basso che e` inutile avere la porta blindata e le finestre di carta.
Spero di aver esploso un po` meglio il concetto.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------


 Pero` in questo caso, devi biasimare te stesso...
Chiaramente nessun altro.
Quindi se anche sei loggato e "agentato" e dalla rete ti bucano 
l'account devono comunque digitare ancora la passphrase?
Ho capito bene?
Andrea

 Ho capito bene?
Si. ssh-agent un wrap-around di una sessione, tipo una shell.
Cmq, questo e` un non problema.
Se io possiedo il tuo account, possiedo la tua chiave privata. Che mi
pare molto piu` problematico dell'intercettare la sessione dell'agent.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Debian - even Hell freezes faster.

 pare molto piu` problematico dell'intercettare la sessione dell'agent.
Quindi, chiudendo il cerchio (partendo dalla mia obiezione iniziale), 
parrebbe piu` sicura l'autenticazione basata su password, piuttosto di 
quella su chiavi ;-)
Andrea

 quella su chiavi ;-)
Esattamente il contrario.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Christ died for our sins, so let's not disappoint him.

 Esattamente il contrario.
Unanderstendo. Se tu devi digitare una password per ogni macchina 
(possibilmente diversa per ognuna) a cui ti colleghi in ssh e quella 
password e` solo dentro alla tua mente, non corri il richio che qualcuno
che ti abbia bucato l'account e trafugato la chiave privata e/o la 
passphrase possa collegarsi col tuo account a tutte quelle macchine e 
dunque la cosa, anche se piu` scomoda, mi sembra piu` sicura.
Andrea

tempo fa ero incappato in un progetto il nome non me lo ricordo, ma mi 
pare ci fosse knock dentro, proprio per permettere l'accesso ad una 
determinata porta solo se avviene prima una sequenza di pacchetti 
precedentemente comcordata... prova a cercare con google.

 
scerto bello che esiste quello che cerchi si chiama portknocking...
www.portknocking.org
ciao
peppe

 Max