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

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).

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.

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 )

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?