Andrea Beggi

To a man with a hammer, everything looks like a nail.

SSH, porte e sicurezza

A T T E N Z I O N E ! Questo post ha piu' di sei mesi. Le informazioni contenute potrebbero non essere aggiornate.

…sono dietro ad un router su sitema windows ed ho optato per l’aprire la porta 80 con un demone Apache in ascolto… Inoltre ho un demone SSH sulla 22 e ovviamente ho dovuto aprire verso il mio PC anche questa porta: mi connetto dall’esterno tramite un tunnel VNC e rimane pronta per tunnellare l’imminente ftp.
…a quali ipotetici e generici rischi di intrusione/infezione potrei andare incontro avendo queste due porte aperte e i due demoni attivi (soprattutto per l’ssh visto che potrebbero farci quasi tutto)?
Un saluto
Yuri

Gli aspetti di cui tenere conto sono molteplici. Intanto come dici altrove nella mail, è meglio cambiare la porta 22 sulla quale ascolta SSH. Questo per evitare di essere sottoposto tutto il giorno a tentativi di intrusione da parte dei soliti ragazzini. Non è una questione di sicurezza, ma piuttosto di risparmio di banda: io avevo decine di accessi al secondo al mio router, a causa dei tentativi di accesso. Ho cambiato la porta e sono cessati.
Distinguiamo tra la sicurezza di Apache e quella di SSH, che sono indipendenti tra di loro; il consiglio è di tenere il più possibile aggiornati i relativi programmi.
Non ho particolare esperienza nella configurazione di Apache per Windows, ma forse potrebbe essere sensato creare un utente dedicato e far girare il servizio con i suoi privilegi. Quindi, tramite la protezione a livello di di file system, bloccarne l’accesso alle aree del disco non di competenza.
Per quanto riguarda SSH, io ho fatto così: ho creato un utente con privilegi bassissimi e password complessa, ed ho bloccato l’accesso via SSH a tutti gli altri utenti. In questo modo per avere accesso amministrativo alla macchina è necessario autenticarsi due volte. Inoltre, nei casi di massima paranoia, è possibile usare l’autenticazione tramite il meccanismo della chiave pubblica/chiave privata. In questo caso solo chi è in possesso della chiave privata e conosce la relativa passfrase è in grado di connettersi.
Usate Google per trovare indicazioni sull’uso di SSH tramite le coppie di chiavi pubbliche/private. Ci sono tonnellate di documenti, sia per Linux che per Windows (in questo caso PuTTY e i programmi correlati sono la soluzione ideale).

Update: leggete qui sotto il commento di uno che ne sa…

15 Commenti

Giorgio Zarrelli | #

Aggiungerei, per ssh, la creazione di una chroot: non che faccia tantissimo, ma è qualcosa in più. Inoltre, inibire la possibilità di loggarsi da remoto come utente root e magari si potrebbe implementare un sistema di autenticazione OPIE (One Time Password), attraverso PAM (Pluggable Authentication Module), ma sotto Windows.

Stessa cosa, per Apache, una chroot può servire, come è ideale utilizzare un utente non privilegiato, con password bloccata e shell nulla, cui si potrebbe aggiungere mod_security, per la prevenzione della maggior parte degli attacchi. Disabilitare la possibilità di utilizzare l’indicizzazione del contenuto delle directory e mettere un AllowOverride none, tanto per stare tranquilli, mentre disabilitare le cgi inutili non sarebbe brutta cosa, cos’ come bloccare i symlink.

Se il sistema fosse Unix, si potrebbero aggiungere swatch, acid e grsecurity, insieme a tiger

Giorgio Zarrelli | #

Ops, troppo onore. Comunque, dimenticavo che Acid va in accoppiata con Snort.

silentman | #

Solo per dire la mia sulla “security thru obscurity”:

Occhi aperti, perche’ questo falso senso di sicurezza e’ pericoloso. Un attaccante preparato e motivato in genere se ne infischia di trovarsi la 22 chiusa (e il risparmio di banda che tu citi e’ molto relativo, perche’ ogni tentativo di connessione implica, come minimo, l’invio di un pacchetto RST (Reset) all’IP sorgente, a comunicare il rifiuto della connessione).

Per quanto mi riguarda io preferirei cercare di indirizzarmi verso il bloccaggio di eventuali tentativi di scan (magari utilizzando strumenti come tarpit) o stratificando la sicurezza (es. ssh pubblico su porta 22, accessibile solo via VPN, con autenticazione a chiave pubblica).

garbaland | #

Se posso aggiungere, forzare l’utilizzo del protocollo SSH 2.0 e inibire i precedenti, e poi utilizzare le chiavi. L’accoppiata protocollo minore di 2.0 + password è vulnerabile ad attacchi MITM. Magari esagero, però già che ci siamo…

Andrea | #

Silentman: io lo so e per me non è un senso di falsa sicurezza.
Da quando ho spostato la porta, i tentativi sono cessati, lo vedo dal log sshd.
Prima il router era un lampeggio continuo, il processore del serverino aveva un po’ di carico, e i log mi si riempivano.
Adesso il server non lavora più e il TCP RST lo manda il router, poichè il PAT non è configurato per la porta 22.
Se io avessi avessi un router con un firewall in modalità stealth, non ci sarebbe neppure il TCP RST.

Noantri | #

Colossale OT: io davvero non capisco perché ci si debba mettere sempre il livore nelle cose. Giuro, non ci riesco ad arrivare.
[Ste]

Giorgio Zarrelli | #

Il protocollo 2 di ssh ormai è abilitato di default in tutte le nuover versioni delle varie distribuzioni in circolazione.

Il tarpit delle connessioni va benissimo, ma si può giochicciare divertendosi con le istruzioni DROP di un firewall.

Per rallentare in maniera esasperante uno scanning selvaggio su tutte le porte, è di aiuto mettere in DROP qualsiasi connessione in entrata che non sia relazionata a una connessione in uscita, ovvero non sia una connessione “di ritorno” e qualsiasi connessione non indirizzata a una porta esplicitamente aperta.

In questo modo, i pacchetti passeranno attraverso il 3 way handshacking solo sulle porte aperte.

Ma, ed è qui il giochino, al posto di rifiutare le connessioni con una regola di REJECT, che manderebbe indietro un pacchetto di RST di la chiusura (cosa che, tra l’altro, espone al ben noto overflow del backlog dello stack), si mette al suo posto una regola di DROP.

Con una regola di DROP, il firewall non manda mai indietro un RST, ma lascia cadere la connessione, lasciando l’attaccante ad attendere un RST che non arriverà mai e quindi rallentandone notevolmente la procedura di scan, che rimane in attesa per ogni connessione, fino al timeout.

Questo in linea generale.

Andrea | #

Non c’è alcun livore per nessuno. Solo, mi cadono le braccia a sentire certi discorsi.

silentman.it | #

ma nemmeno da parte mia c’era del livore, ho solo detto la mia sulla base delle mie esperienze a questo riguardo… voglio credere che Andrea abbia capito il senso del mio intervento (nè era mia intenzione fare il saccente, insomma :))

Yuri | #

“nascendo” da sistema Windows su piccole reti casalinghe ho sempre sottovalutato la gestione dei privilegi utente, (non sono l’unico visto che dove finora ho lavorato non esiste il concetto di amministratore… tutti possono fare tutto sul pc di tutti) mi sa che devo cominciare a pensare un po’ più da… linux…

Grazie mille per la risposta

Yuri

Andrea | #

Silentman, ti devo delle scuse. Sei capitato in mezzo ad una discussione che nulla c’entra con l’argomento del post.
E’ un off- topic, e il mio commento non si riferiva al tuo, che peraltro è utile e appprezzato.

anonimo italiano | #

Per evitare di vedere nei log le tonnellate di ragazzini che fanno bruteforcing su ssh, che ogni volta mi viene il mal di mare, oltre ad inibire l’accesso a root, invece di cambiare la porta di ssh, uso il port knocking.

Andrea | #

Grazie, Anonimo!
Non lo conoscevo….

robs | #

ma ilfile di log dove si trova su centos? è per caso lastlog ?a cui si accede in lettura non con editor ma solo con appunto ilcomando lastlog?
se è tale file perà fa vedere solo eventuali accessi da utenti del server o anche chiunque?