[EvolutionCrazy]

Poi un altro piccolo dubbio, dopo aver configurato CSF poco fa (con il livello di sicurezza alto) sono andato a spulciare i log per vedere che ci sta di interessante, e a parte qualche indirizzo IP estraneo che pare cercare di collegarsi ho notato questo che si ripete in continuazione:

Mar 27 01:49:01 ks352335 kernel: Firewall: *UDP_OUT Blocked* IN= OUT=eth0 SRC=91.121.81.100 DST=91.121.81.251 LEN=218 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=43079 DPT=6171 LEN=198

Il primo IP è il mio server, il secondo non sono sicuro cosa sia. Non è che sto bloccando qualcosa in uscita? Magari la configurazione "alta" di CSF non è indicata ed è meglio farne una "a mano" più semplice?

il secondo ip è il monitor RTM ovh (http://help.ovh.co.uk/RealTimeMonitoring)... se lo blocchi non manda gli updates...

non bloccare quel traffico!!!

[activ]

ho per caso trovato il post, davvero ottimi suggerimenti

mi permetto di rispondere a mondopallone:
se cambi porta devi necessariamente modificare anche la regola su iptables, quindi

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN

diventa

iptables -A INPUT -p tcp --dport TUA_PORTA-m state --state NEW -j SSHSCAN

[mondopallone]

Ciao Raffo,

Ho cambiato la porta SSH da 22 ad un'altra, e mi chiedevo se aveva senso avere poi questa regola IP table che hai postato:

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 8 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN Bloccati: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 8 --name SSH -j REJECT

Conviene lasciarla e aggiungere anche la porta su cui ho impostato SSH? Qual è la sintassi corretta per avere la regola valida su più porte? ho cercato un attimo su internet ma non ho trovato quello che vorrei fare io.

Grazie,
Fabio

[mondopallone]

L'accesso tramite chiave RSA non crea alcun problema anzi, i tecnici ovh effettuano il login tramite chiave pubblica (devi installare la loro)
Non essere paranoico con CSF, non so che il sia quello forse broadcast o gateway, limita solo il flood dei pacchetti e connessioni senza limitare troppo e senza bloccare gli ip permanentemente, poi esegui qualche test simulando del traffico sul tuo sito per vedere se ti blocca.

Con "non essere paranoico con CSF" intendi di non preoccuparmi troppo di quei LOG oppure che posso anche evitare di usare CSF e impostare giusto qualche regola semplice direttamente tramite IPTables?

[raffo]

L'accesso tramite chiave RSA non crea alcun problema anzi, i tecnici ovh effettuano il login tramite chiave pubblica (devi installare la loro)
Non essere paranoico con CSF, non so che il sia quello forse broadcast o gateway, limita solo il flood dei pacchetti e connessioni senza limitare troppo e senza bloccare gli ip permanentemente, poi esegui qualche test simulando del traffico sul tuo sito per vedere se ti blocca.

[mondopallone]

Ciao raffo!

Grazie, anche per i consigli preziosi che avevi scritto in precedenza e che mi sono serviti.

Questi altri consigli me li devo studiare, come per gli altri faccio qualche ricerca su internet per capirne di più perchè come detto non sono un vero e proprio sistemista, ma mi piace comunque sperimentare e imparare cose nuove.

Avrei un dubbio per quanto riguarda l'accesso SSH tramite chiave privata: questo crea qualche problema ai tecnici di OVH avendo disabilitato l'accesso tramite password? come devo fare per garantire a loro l'accesso in caso di problema?

Poi un altro piccolo dubbio, dopo aver configurato CSF poco fa (con il livello di sicurezza alto) sono andato a spulciare i log per vedere che ci sta di interessante, e a parte qualche indirizzo IP estraneo che pare cercare di collegarsi ho notato questo che si ripete in continuazione:

Mar 27 01:49:01 ks352335 kernel: Firewall: *UDP_OUT Blocked* IN= OUT=eth0 SRC=91.121.81.100 DST=91.121.81.251 LEN=218 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=43079 DPT=6171 LEN=198

Il primo IP è il mio server, il secondo non sono sicuro cosa sia. Non è che sto bloccando qualcosa in uscita? Magari la configurazione "alta" di CSF non è indicata ed è meglio farne una "a mano" più semplice?

Grazie di nuovo.
Fabio

[raffo]

Ciao!

Ti consiglio di usare mod_security e suhosin per filtrare richieste malevoli o potenzialmente pericolose per quanto riguarda apache e php.

Disabilita le versioni di apache e php negli headers, disabilita il metodo trace su apache.
Disabilita alcune funzioni pericolose su php, dai un chmod 750 su alcuni comandi potenzialmente utili alle phpshell come tar, cp, mv, cat, tail, head ecc ecc in modo che qual'ora dovessero inseriti una phpshell tramite RFI su wordpress non possono agire come vogliono pur avendo la funzione exec() abilitata, utile per gli aggiornamenti automatici di wordpress.
Dividi backend con frontend, il traffico del pubblico tramite regole su .htaccess non puo accedere ai files .php oltre a quelli necessari per login e commenti, disabilita il metodo POST a directory a cui non è necessario caricare dati tramite post o upload, ad esempio nella directory del template e dei plugins, è li che caricano files sfruttando falle dei medesimi.
Inoltre dai permessi bassi, chmod 400 e 440 se usi suPHP e suEXEC.

Saluti!

[mondopallone]

Salve a tutti!

Innanzitutto grazie, ho trovato questo thread (seppur datato) molto molto utile e mi ha chiarito le cose più importanti da fare per rendere il server dedicato sicuro.

Parto dal presupposto che non sono un sistemista, sono un developer. Ho però abbastanza esperienza su server Windows dato che mi occupo spesso di configurazioni, deployment ecc...ma non ho particolare esperienza su Linux.

Ho comprato un server dedicato kimsufi con sistema Debian, su questo server ci girerà fondamentalmente un sito in WordPress.

Per il momento ho eseguito alcuni dei consigli indicati qui:

1) disabilitato accesso SSH tramite password e abilitato la chiave RSA. Funziona tutto correttamente.
2) Cambiare porta da 22 ad un'altra non l'ho fatto, serve lo stesso nonostante il punto 1)?
3) Avevo inizialmente configurato IP Tables con queste due regolette indicate qui http://www.digitalsanctuary.com/tech...e-attacks.html ma poi ho letto di questo SCF e quindi ho installato prima Webmin (ho fatto bene?) e poi SCF a cui ho impostato come livello di sicurezza "Alto" e che mi ha inserito una fiondata di regole IPTables. Spero bastino

Ora avrei un dubbio, dovrei prima di tutto rendere sicuro anche l'accesso a Webmin perchè altrimenti con l'utente root e la password uno può entrare e comunque sfondare il server, consigliate qualcosa in particolare?

Dopodichè, dovrei passare alla configurazione vera e propria del web server. Per installare LAMP non dovrei avere problemi, l'ho fatto già sul mio portatile con ubuntu e alla fine i comandi sono quelli lì, c'è poco da inventarsi.

Per ottimizzare invece i servizi, in particolare Apache e PHP avete dei consigli o guide?

Grazie mille a tutti!
Fabio

[Acidflame]

Hai pienamente ragione, infatti avevo spiegato un attimo sopra con parole più povere cosa volevi intendere e poi con i link che ci sono altrettante spiegazioni. La prima cosa è la teoria ma come ben sai non tutti hanno voglia di leggere XD, comunque spiegazione ottima credo sarà d'aiuto a parecchi utenti.

[raffo]

@raffo: Bravissimo Raffaele
Bella spiegazione che illustra in linea generale quali sono le linee
guida da seguire per mettere in sicurezza almeno il demone SSH
(basilare per la gestione di un server linux based).

Grazie grazie avrei scritto molto piu ma poi mi sono chiesto "qualcuno leggera?" :P

[/LIST]
Potresti essere un pò più chiaro per questi punti?
Cmq davvero utile il tuo post

I link che ti h dato Acidflame sono altrettanto validi ma se non c'e' molta teoria e quando ci sono troppi comandi e' facile fare copia&incolla senza realmente sapere che cosa succede..

Dunque cio che ho consigliato di fare e' disabilitare l'accesso a SSH tramite password e di entrare solo con chiave RSA e di configurare il firewall di linux mediante iptables in modo che limita e blocca l'accesso all'ip del client se effettua troppe connessioni simultanee.

Che sia ubuntu, gentoo o centos poco importa, la configurazione di openssh e' sempre su /etc/ssh/sshd_config apri questo file con un editor e assicurati che questi parametri non sono commentati (il commento e' un prefisso sulla riga fi un foglio di config o di programmazione che fa ignorare l'interprete di prende in considerazione quella riga, in questo caso il commento e' il #)

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
PermitEmptyPasswords no
PasswordAuthentication no
MaxAuthTries 10

Quest'ultimo parametro blocca l'accesso all'IP che ha sbagliato l'accesso dopo 10 volte mostrando un messaggio del tipo "too many entry for root user".
Fatto cio salva il file ma prima di riavviare ssh crea una chiave RSA altrimenti ti butti fuori dal server e non puoi entrare se non in console o in rescue..

ssh-keygen e' il comando per generare la chiave RSA o DSA, questo ha degli attributi che servono a indicare che tipo di chiave creare. Siamo paranoici e vogliamo una chiave rsa a 8128 bit invece di quella di default che e' di 2084 bit:

ssh-keygen -b 8128 -t rsa

La genera e ci chiede 2 cose, dove vogliamo salvarla e se vogliamo usare una passprhase per proteggere la chiave altrimenti la salva su /root/.ssh/id_rsa senza passprhase e quindi quando la dovremo usare non ci chiedera' una pass per decifrare la chiave prima di poterla usare.

Dopo averla creata dobbiamo fare solo altre due cose: impostare la chiave pubblica nel file authorized_keys che accetta la chiave generata e scaricare la chiave in locale o dove bisogna usarla.

cat /root/.ssh/id_rsa.pub >> /root/ssh/authorized_keys
Questo comando aggiunge al file authorized_keys il contenuto di id_rsa.pub

Ora devi solo copiare id_rsa
cat /root/.ssh/id_rsa

Se ti colleghi con putty hai bisogno di convertire la chiave RSA con il generatore fornito da putty.
Se invece ti colleghi da Unix puoi usare questa sintassi:
ssh -i id_rsa root@server.ovh.net
Puoi rinominare id_rsa come ti pare ma deve avere i permessi di sola lettura da parte del proprietario quindi 400.

Dopo aver provato il corretto funzionamento puoi riavviare ssh con il comando
service ssh restart
(se hai service installato, altrimenti per ubuntu /etc/init.d/ssh restart)

Fin qui e' il primo punto che ho scritto.
Adesso hai un buon livello di sicurezza anche se c'e' un modo per fare lo sniffing della chiave RSA tramite ssldump ma bisogna essere tra il server e l'utente root..

In breve, per bloccare il bruteforce tramite iptables su linux ci sono due semplici comandi che puoi salvare in un file ed eseguirlo al boot oppure aggiungerlo alle regole che gia hai di iptables.

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 8 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN Bloccati: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 8 --name SSH -j REJECT

In pratica abbiamo imposto a linux che a chi fa piu di 8 nuove connessioni in 300 secondi nel protocollo ssh su porta tcp 22, viene messo in una blacklist SSHSCAN e viene notificato nei log di sistema con il prefisso SSH SCAN Bloccati. L'IP bloccato quando si prova a connettere il server gli invia un pacchetto icmp di errore (reset).

Il punto tre che avevo consigliato contraddice il punto uno. Se sei paranoico disabilita l'accesso root tramite ssh (impostando "PermitRootLogin no" nella config di ssh) e creando un utente con uid 0 ovvero un secondo root.
useradd -o -u 0 root2

Buona giornata,
RAFFAELE

[Acidflame]

Allora per ubuntu puoi seguire queste guide che ti spiegano come generare la chiave privata e disabilitare l'autenticazione tramite password all'account root

http://lani78.wordpress.com/2008/08/...ubuntu-server/
http://secure-ubuntu-server.blogspot...for-login.html
http://www.ubuntu-howto.info/

E queste per bloccare i bruteforce all'ssh

http://askubuntu.com/questions/32246...ce-ssh-attacks
http://www.digitalsanctuary.com/tech...e-attacks.html

Dimmi se non ti è chiaro qualche passaggio.

[viking2010]

Io utilizzo Ubuntu Server 10.10

[Acidflame]

Praticamente raffo, che ha dato dei consigli super ottimi in questi punti sta consigliando di

Disabilita l'accesso con password per l'utente root e abilita una volta creata la chiave di accedere solo con quella

L'utente di root non può accedere all'ssh e per accedere utilizzi solo una chiave privata(tipo quella che utilizza OVH per accedere al tuo server) in modo da ridurre gli attacchi che vengono portati sull'ssh proprio con l'utente root. Creando una chiave privata e connettendoti solo con quella risulta impossibile per gli altri scoprirla quindi eviti parecchie cose

Configura iptables con delle regole in modo da bloccare chi fa il bruteforce alla porta ssh che hai configurato

COnfigurare IPtables per i bruteforce all'ssh, e cioè configurare il "firewall" di linux in modo che chi prova ad accedere più volte all'ssh viene bloccato(l'ip viene bloccato). Se vuoi poi avere le varie procedure per fare ciò dovresti indicare gentilmente che tipo di sistema operativo utilizzi.

[viking2010]

• Disabilita l'accesso con password per l'utente root e abilita una volta creata la chiave di accedere solo con quella
• Configura iptables con delle regole in modo da bloccare chi fa il bruteforce alla porta ssh che hai configurato
• se sei paranoico, cambia il nome di root disabilitando l'accesso ssh e collegati semptre tramite chiave RSA/DSA con un utente in cui poi da li entrerai in root tramite il comando "su"

Potresti essere un pò più chiaro per questi punti?
Cmq davvero utile il tuo post

[tmit]

Spero avro soddisfato le tue paranoie
RAFFAELE

@raffo: Bravissimo Raffaele
Bella spiegazione che illustra in linea generale quali sono le linee
guida da seguire per mettere in sicurezza almeno il demone SSH
(basilare per la gestione di un server linux based).

[gen_patton]

Ti ringrazio delle risposta.
Non sono un sistemista (aimè), quindi ho capito un 20% di quello che hai scritto

Ho meno paranoie, anche perchè analizzando i log di un altro server che ho da un paio di anni con OVH, ho notato che i tentantivi sono piu o meno gli stessi. Ed il server ha sempre funzionato regolarmente e non è in nessuna blacklist.

Presumo quindi che le impostazioni di default bastano, a meno che qualcuno non abbia intenzione di entrare a tutti i costi nel mio server, e non ne vedo il motivo.

Faccio cmq uno screen grafico di tutti i tuoi utilissimi consigli, al momento opportuno verranno utili.

Grazie ancora.

Ciao.

[raffo]

Nel logwatch del kimsufi di oggi ho trovato:

*****Questi sono entrati?********
Illegal users from:
14.128.12.11: 30 times
118.96.110.47 (47.static.118-96-110.astinet.telkom.net.id): 3 times

Illegal users significa gli utenti che non esistono nel tuo sistema e quindi quei IP hanno tentato di accedere 3 e 30 volte con degli utenti che nel tuo sistema non esistono, ad esempio root2, root303...
NO, non ti sono entrati! oppure si.. chi puo dirlo? prova a vedere gli ultimi login con il comando "last" ma se hanno cancellato il file /var/log/last non puoi vederlo.
Quindi devi assicurarti che:

• Non ci sono altri utenti root o che hanno accesso a su/sudo
• Non c'e' una chiave pubblica o privata per l'accesso in SSH su /root/.ssh/authorized_keys che non sia la tua o quella di ovh

Ti consiglio fortemente di:

• Cambiare la porta SSH, la 22 e' troppo comune, usa una non banale come 2222 ma del tipo 8973
• Configura openssh solo su un IP che non usi nel web, diverso dai failover/ripe in modo da non esporti troppo (la config sta su /etc/ssh/sshd_config)
• Disabilita l'accesso con password per l'utente root e abilita una volta creata la chiave di accedere solo con quella
• Configura iptables con delle regole in modo da bloccare chi fa il bruteforce alla porta ssh che hai configurato
• se sei paranoico, cambia il nome di root disabilitando l'accesso ssh e collegati semptre tramite chiave RSA/DSA con un utente in cui poi da li entrerai in root tramite il comando "su"

Installa CSF che trovi su configserver.com se non sei molto pratico in ambienti linux, e' un ottimo interprete iptables e ha degli script in perl che bloccano il bruteforce e anche il port scanning.
Ci sono migliaia di accorgimenti che bisogna fare, questi che ti ho elencati sono essenziali per garantire un minimo di sicurezza.
OVH genera password a 8 cifre alfanumeriche con maiuscole e minuscole, se non hai ancora cambiato la password dopo l'installazione del server basta un semplice software come hydra per eseguire un bruteforce, che ora mai e' obsoleto visto che ogni server con login blocca gli utenti che sbagliano la password dopo un certo tentativo di volte che puo variare a seconda dalle impostazioni. Quasi sicuramente chi ha provato ad effettuare il login per 800 volte nel tuo server anche se aveva azzeccato la password alla 500esima volta il server openssh non avra preso in considerazione la connessione.

Oppure puoi configurare tu stesso le regole iptables (e' un firewall linux kernel) e configurare anche il port knocking che in pratica rende difficile eseguire un portscan perche' apre tutte le porte rendendo possibile stabilire la connessione su di esse qual'ora ci si connette, quindi se imposti ssh su una porta alta come 39443 il software che fa il portscan (esempio nmap) rileva che sono aperte 65535 porte.. ovvero tutte, difficile scoprire che che proprio la 39443 usa il protocollo ssh.. a meno che non si analizzi anche il fingerprint..

Spero avro soddisfato le tue paranoie, fammi sapere se ti servono anche degli esempi pratici
RAFFAELE

[gen_patton]

Nel logwatch del kimsufi di oggi ho trovato:

--------------------- pam_unix Begin ------------------------

proftpd:
Unknown Entries:
session closed for user io: 15 Time(s)
session opened for user io by (uid=0): 15 Time(s)

sshd:
Authentication Failures:
root (14.128.12.11): 865 Time(s)
root (189.215.251.189.cable.dyn.cableonline.com.mx): 221 Time(s)
unknown (14.128.12.11): 30 Time(s)
unknown (118.96.110.47): 3 Time(s)
bin (14.128.12.11): 2 Time(s)
gopher (14.128.12.11): 1 Time(s)
root (118.96.110.47): 1 Time(s)
root (190.144.175.133): 1 Time(s)
root (r200-40-251-146.ae-static.anteldata.net.uy): 1 Time(s)
Invalid Users:
Unknown Account: 33 Time(s)


---------------------- pam_unix End -------------------------


--------------------- SSHD Begin ------------------------


Failed logins from:
14.128.12.11: 868 times
118.96.110.47 (47.static.118-96-110.astinet.telkom.net.id): 1 time
189.215.251.189 (189.215.251.189.cable.dyn.cableonline.com.mx): 221 times
190.144.175.133: 1 time
200.40.251.146 (r200-40-251-146.ae-static.anteldata.net.uy): 1 time

*****Questi sono entrati?********
Illegal users from:
14.128.12.11: 30 times
118.96.110.47 (47.static.118-96-110.astinet.telkom.net.id): 3 times

Received disconnect:
11: Bye Bye : 900 Time(s)
11: Goodbye : 221 Time(s)

**Unmatched Entries**
reverse mapping checking getaddrinfo for 47.static.118-96-110.astinet.telkom.net.id failed - POSSIBLE BREAK-IN ATTEMPT! : 4 time(s)

---------------------- SSHD End -------------------------


Ho le paranoie

Ciao