# ssh e un po di sicurezza..

## HexDEF6

NOTA: questo post l'ho fatto anche sul forum di HWUG (spero non sia un problema)

ATTENZIONE

Questo mini-howto non ha nessuna pretesa di essere la soluzione a tutti i problemi di sicurezza di una macchina gestita in remoto, ma sono solo "pensieri" che mi sono saltati in mente dopo aver visto bucare alcune macchine dove lavoro.. quindi se avete suggerimenti sono benvenuti!

ATTENZIONE2

Io tengo conto che sulla macchina remota giri solamente il server ssh, non anche un server di telnet o un apache o altro, quindi e' inutile prendere precauzioni paranoiche per il server ssh e poi lasciate l'accesso da root remoto con telnet! inoltre si presume che ci sia un firewall che permetta l'accesso alla sola porta 22 e che tutto il software sia aggiornato (se usate ssh del 1912 di sicuro questo mini howto non vi sara' di aiuto!) quindi non prendero in considerazione altro.

PARTE SERVER

Configurazione1

Normalmente ssh permette l'accesso diretto da root

infatti se guardiamo in /etc/ssh/sshd_config troviamo:

```

PermitRootLogin yes

```

e se e' commentato (o non presente) verra' usato il parametro di default (che e' yes).

Questo e' molto comodo, ma nasconde alcune insidie:

alzino la mani quanti di voi controllano giornalmente i log!

diciamo che lo fanno solo quelli che lo fanno per lavoro e ben pochi altri.. magari provate a dare un'occhiata, molte volte si trovane dei tentativi di accesso remoto non autorizzati, questi dovuti ad alcuni tool automatici che tentano di trovare password deboli... regalare il proprio account da root solo perche' non si ha voglia di inserire 2 password non e' bello!

quindi se volete un minimo di sicurezza in piu' dovete:

- usare una password decente (niente cose che si trovano su vocabolari o hanno a che fare con il vostro lavoro, o con voi, e usate almeno 8 caratteri per la password, magari comprendendo qualche numero e simbolo)

- disabilitare il login diretto da root:

```
 

PermitRootLogin no

```

questa configurazione vi da un minimo di sicurezza in piu'

Configurazione2

Se quello che gestite da remoto non e' il vostro desktop personale, ma qualcosa di piu' sostanzioso (da leggersi: se vi craccano siete nella mer*a) il passo successivo e':

- restringere l'accesso a ssh da predeterminati ip riconfigurando iptables (non sempre possibile, se magari volete accedere remotamente ala vostra macchina e vi attaccate ad internet da posti diversi)

- restringere l'uso di ssh solo agli utenti che hanno veramente bisogno di accedere da remoto:

questo viene fatto con la direttiva:

```

AllowUsers utente1 utente2

```

in questo modo anche se sulla macchina ci sono 87 account solo utente1 e utente2 potranno loggarsi via ssh (se impostate AllowUsers, anche se lasciate PermitRootLogin su yes, questo non potra' loggarsi),

inoltre con questa direttiva si puo' specificare da dove puo' essere fatto il login:

```

AllowUsers utente1@* utente2@192.168.0.*

```

cosi utente1 puo' loggarsi da tutte le parti del mondo, invece utente2 solo dalla sottorete privata 192.168.0.* 

Configurazione3A

Andando nel paranoico, possiamo usare la direttiva AllowUsers per mettere un ulteriore passaggio per avere accesso da root... infatti se usiamo:

```

AllowUsers utente1@* utente2@127.0.0.1 utente2@localhost

```

e facciamo in modo che utente1 non faccia parte del gruppo wheel (e quindi non possa lanciare il comando su per poter aumentare i propri privilegi)

per poter avere accesso da root dobbiamo fare:

- ssh utente1@server

una volta loggati dovremo fare:

- ssh utente2@127.0.0.1

ed infine

- su

quindi se abbiamo fatto tutto per bene ci sono 3 password prima di poter accedere da root!

Configurazione3B

Siccome il 99% dei casi ci troviamo degli attacchi alla porta 22 portati con tool automatici che fanno un lavoro del tipo:

la porta 22 e' aperta?==> proviamo un po di combinazioni di utenti e password.

una cosa comoda per evitare questi tentativi e' cambiare la porta di default di ssh usando la direttiva:

```

Port

```

io consiglio di usare una porta > 2000 visto che alcuni tool fanno automaticamente lo scan delle prime 1024 porte (quelle privilegiate)

```

Port 2865

```

ovviamente quando ci si deve collegare bisogna anche specificare la porta:

```

ssh -p 2865 user@server

```

Port Knocking

Se il livello di paranoia della configurazione3 non e' sufficente il passo successivo e' quello di usare http://www.zeroflux.org/knock/

cos'e'?

e' un piccolo demone che gira sul vostro server (nel pacchetto e' compreso pure il client knock)

a cosa server?

serve per aprire la porta 22 (quella dell'ssh) all'indirizzo ip da cui riceve la "bussata"

come funziona?

il demone ascolta sull'interfaccia di rete aspettando di ricevere una particolare "bussata" (la bussata si traduce in pacchetti tcp o udp su alcune porte da voi decise), quando questo succede apre la porta 22 (in verita' lancia uno script che puo' fare qualunque cosa, ma di default lancia iptables in modo che apra la porta 22) al solo indirizzo che ha bussato

cosa comporta?

ad uno scan del vostro server la porta 22 risulta chiusa, e quindi il 99% dei programmini automatici per tentare di trovare le password passera' a rompere le p@lle ad un altro ip lasciandovi in pace!, inoltre aggiunge un altro livello di sicurezza:

anche se qualcuno sapesse che bisogna bussare per aprire la porta 22 dovrebbe conoscere su quante e quali porte bussare, questo si traduce in:

porte usabili per la bussata circa 64000 (in realta' le porte che si possono usare sono 65536, ma togliamo le prime 1024 che sono riservate, e per fare il conto tondo usiamo 64000), quindi se impostiamo 3 porte per la bussata, il "malvivente" che tentera' di trovare queste 3 porte bussando a caso avra' da testare (in media) 64000*64000*64000 / 2 combinazioni, praticamente come avere una password in piu' prima di arrivare al sistema!

controindicazioni?

Le controindicazioni sono nella configurazione del firewall.. dovete stare attenti che inserire una regola in fondo al vostro script non dia problemi... diciamo che non sono di sicuro problemi insormontabili e a volte non ci sono proprio!

L'installazione e' semplicissima (con gentoo basta un emerge knock) e la configurazione altrettanto semplice, basta modificare il file /etc/knockd.conf (non lasciate le 3 porte di default!) e lanciare /etc/init.d/knock start (ovviamente dovete riconfigurare il firewall in modo che di default droppi la porta 22!)

Semplificazioni ok... finalmente qualcosa di utile!

Ok... cosi' vi ho complicato la vita in modo esagerato, quindi eccovi alcune "semplificazioni"

siccome nel 90% dei casi (almeno per me) gestisco le macchine remote dal mio pc personale e' comodo poter usare (in combinazione con una delle configurazioni precedenti) la possibilita' delle chiavi condivise (e quindi niente digitazione di password!):

sul nostro pc (che sara' il client) generiamo le chiavi:

```

ssh-keygen -t rsa

```

vi chiedera' dove salvare la chiave privata e pubblica (di solito in ~/.ssh/id_rsa) 

vi chiedera' una passphrase, di questa potreste farne anche a meno (ma lo sconsiglio!) e' praticamente una password per poter accedere alla propria chiave privata.

una volta generate le chiavi, copiate la chiave pubblica (che finisce con .pub !!!!) sul server remoto:

```

scp ~/.ssh/id_rsa.pub utente_ser@server: 

```

una volta copiata, accedete al server remoto:

```

ssh utente_ser@server: 

```

e copiate la chiave pubblica nel file ~/.ssh/authorized_keys2 (in qualche versione di ssh il file potrebbe essere ~/.ssh/authorized_keys)

```

cat id_rsa.pub >> .ssh/authorized_keys2

```

una volta fatto questo potrete loggarvi al server remoto senza digitare alcuna password remota, ma solo la passphrase (se l'avete messa, altrimenti senza digitare niente)..

se avete usato la passphrase puo' venire comodo lanciare ssh-agent e quindi "aggiungere" la vostra passphrase con ssh-add in modo tale che questa vi venga chiesta solamente la prima volta, e non ad ogni tentativo di connessione!

```

ssh-agent

ssh-add 

```

dovete solamente digitare la vostra passphrase (come detto prima, se avete generato la vostra chiave senza passphrase, questa procedura non serve!)

Infine si puo' fare una semplificazione finale, cioe' poter entrare direttamente da root sulla macchina remota senza usare password:

sul server modificate in questa maniera /etc/ssh/sshd_config:

```
 

PermitRootLogin  without-password

AllowUsers utente1@* utente2@127.0.0.1 utente2@localhost root@ip_del_vostro_pc

```

io consiglio di fare un collegamento root ==> root e non utente ==> root, quindi sul vostro pc alzate i vostri privilegi e loggatevi da root, quindi generate le chiavi (come sopra descritto... e per favore usate una passphrase!) e poi copiate la chiave pubblica sul server remoto (come descritto sopra)...

In questa maniera potrete loggarvi direttamente da root sulla macchina remota senza usare password!

Il sistema non e' insicuro come si potrebbe pensare perche':

- root puo' loggarsi direttamente con le chiavi, ma NON con la password

- lo puo' fare solamente dal vostro pc (quindi cercate di non farvi craccare il vostro pc, altrimenti avra' il controllo di tutte le macchine!)

ricordatevi che:

-potete "dare in giro" la parte pubblica della vostra chiave senza nessun problema di sicurezza (l'importante e' che la privata rimanga tale!)  

-dopo ogni modifica al file sshd_config dovete riavviare il server ssh

-se state riavviando un server ssh remoto pensateci ben 15 volte perche' non sarebbe bello essere esclusi dal proprio sistema (controllate 86 volte sshd_config e poi fatelo controllare anche a qualcun'altro!) comunque vada la connessione attuale non verra' chiusa, quindi prima di uscire provate se tutto funziona perfettamente

-potrei aver scritto qualche cazzata, quindi prima di fare tutto leggetevi le man pages

-non prendetevela con me se dopo tutte le modifiche non funziona niente!!

PARTE CLIENT

tunnel con ssh

oltre al normale uso per amministrare una macchina remota, ssh puo' essere comodo per fare tunnelling.

ESEMPIO: voglio collegarmi al server vnc sulla macchina 1 (che si trova sulla porta 5903 visto che lo abbiamo lanciato con vncserver -geometry 800x600 :3 ) ma l'unica porta aperta del server e' la 22... abbiamo 2 o 3 opzioni:

- apriamo la porta 5903 del firewall (dobbiamo avere accesso da root alla macchina, e aprire una porta in piu' all'esterno non e' mai un bene!)

- usiamo una vpn (ma anche n questo caso dobbiamo aprire una porta in piu' oltre a dover configurare la vpn e altri problemi)

- facciamo un tunnel ssh

per poter fare un tunnel basta lanciare:

```

ssh -L 5903:127.0.0.1:5903 user@server

```

poi da un altro xterm (sempre sul client) lanciamo:

```

vncviewer 127.0.0.1:3

```

intanto ricordo che per determinare su che porta sia in ascolto il vnc basta fare 5900 + numero di display usato, analizziamo la riga di comando del client ssh:

-L e' il parametro fondamentale (andate a leggere le man pages!)

nel nostro caso: -L 5903:127.0.0.1:5903 che sta' ad indicare:

ridirigi sulla porta locale 5903 (del client) quello che vedi remotamente (quindi dal punto di vista del server) su 127.0.0.1 alla porta 5903

quindi con ssh possiamo andare ad usare un vnc su una macchina interna ad una LAN, basta avere accesso (via ssh) ad una macchina perimetrale (che abbia un'interfaccia su internet e un'altra sulla LAN)

esempio:

client (IP pubblico 193.205.x.x)===>server ssh(ip pubblico 212.122.x.x)===>macchina con vncserver(ip privato 192.168.0.1)

questo con:

```

ssh -L 5903:192.168.0.1:5903 user@212.122.x.x

```

ATTENZIONE: normalmente i tunnel ssh vengono usati al posto del collegamento diretto anche perche' in questa maniera il tutto viene passato attraverso ssh e quindi criptato, ma in casi come questo appena visto, il traffico e' criptato fra 193.205.x.x e 212.122.x.x, ma NON tra 212.122.x.x e 192.168.0.1... nel 99% dei casi questo e' poco importante (ci fidiamo di chi sta nella nostra LAN... ma bisogna tenerne conto nell'altro 1% dei casi!)

esempio2:

Se abbiamo un pc (una gentoo!) e dobbiamo fare un emerge sync da un pc che puo' uscire solamente via proxy, ma possiamo appoggiarci ad una macchina periferica (che esce direttamente su internet) possiamo fare:

```

ssh -L 873:ip_server_rsync:873 user@macchina_periferica

```

ricordatevi che questo funziona solo da root visto che state ridirigendo una porta privilegiata

poi basta modificare make.conf e dire di usare come server rsync 127.0.0.1

```

SYNC="rsync://127.0.0.1/gentoo-portage"

```

ssh come socks server

sempre nel caso in cui la vostra macchina sia dietro proxy e disponete di un account su una macchina perimetrale che ha pieno accesso ad internet, potete usare ssh come socks server.

Per poter utilizzare questa funzionalita' oltre a ssh dovete avere installato sul vostro computer anche un socks client (gli esempi che faccio tengono conto che venga usato tsocks)

```

ssh -D 5000 user@macchina_perimetrale

```

poi configurate tsocks.conf in questa maniera:

```

#inserite tutte le reti locali

local = 192.168.0.0/255.255.0.0

local = 10.1.0.0/255.255.0.0

#inserite l'ip del server

server = 127.0.0.1

#e la porta

server_port = 5000

```

poi basta lanciare una qualsiasi applicazione con tsocks esempio:

```

tsocks mozilla

```

e navighera senza configurare nessun proxy.

o potete fare un ssh all'esterno:

```

tsocks ssh user@server_esterno

```

Ciao

edit: corrette alcuni errori di scrittura

edit2: inserita la configurazione 3B (la 3A comporta un utente in piu' e in molti casi si considera piu' sicura una macchina con MENO utenti)

todo:

aggiungere l'uso di: ssh -R

bugfix vari

P.S. come detto all'inizio queste sono mie considerazioni, quindi se avete idee, suggerimeti, notate errori ecc. fatemelo sapere!

----------

## drizztbsd

openssh 2 non aveva "PermitRootLogin no" di default?

----------

## HexDEF6

 *Drizzt Do` Urden wrote:*   

> openssh 2 non aveva "PermitRootLogin no" di default?

 

dal man:

```

PermitRootLogin

             Specifies whether root can login using ssh(1).  The argument must

             be ``yes'', ``without-password'', ``forced-commands-only'' or

             ``no''.  The default is ``yes''.

```

poi non so!

----------

## JacoMozzi

Grazie mille dell'ottimissimo How-to HexDEF6  :Very Happy: 

(imho sarà aggiunto ai post utilissimi  :Laughing:  )

CIao

Jaco

----------

## drizztbsd

Sì scusa avevo preso il man di freebsd che ha no di default.

Mea Culpa  :Crying or Very sad: 

P.S. hai messo id_dsa nel ssh_keygen e id_rsa nell'scp

----------

## FonderiaDigitale

considerazioni:

- usa per favore i tag del forum in maniera piu consistente!

- quello che scrivi vale solo per openssh (non per ssh, la sintassi e' diversa)

- per far coesistere le due implementazioni si deve usare USE=openssh

- la prima buona regola per evitare noie e' bindare ssh a una porta diversa, preferibilmente, alta: in primis eviti una marea di scan e di TCP CONNECT, che se sei su una rete come alice che e' una groviera, e se hai una macchina scrausa come firewall, assicuro che vogliono dir tanto; in seconda istanza e' la prima maniera, la piu banale, per evitare gli exploit, anche xche appena esce un bug subito i vari script kiddies si mettono a scannare le classi B e C per una porta 22 vulnerabile

- quando si modifica un file di configurazione di ssh, e non si e' sicuri che riparta, e' bene provarlo in debug su una porta diversa avviandolo in console e usando il parametro -p

- contrariamente alla credenza popolare, /etc/init.d/sshd restart non uccide i processi figli attivi, e di conseguenza le sessioni attualmente aperte

- per mantenere le chiavi pubbliche aperte attraverso le sessioni e' buona norma usare keychain (vedi i doc ufficiali di gentoo su come implementarlo)

- le sessioni non vanno tenute aperte e lasciate a pascolare in idle, per questo ti rimando a  questo mio howto che ho scritto parecchio tempo fa

- fare nesting di login sulla stessa macchina non aumenta la sicurezza, che semmai va ricercata nell'accoppiata porta_alta+restrizioni di accesso da host specifici+chiave pubblica e privata tenuta su un media portatile (tipo penna usb)

ciao

----------

## .:chrome:.

 *FonderiaDigitale wrote:*   

> 
> 
> - fare nesting di login sulla stessa macchina non aumenta la sicurezza, che semmai va ricercata nell'accoppiata porta_alta+restrizioni di accesso da host specifici+chiave pubblica e privata tenuta su un media portatile (tipo penna usb)
> 
> 

 

io direi più che altro che è una paranoia assolutamente inutile. anzi... mi costringe ad aggiungere un utente che non serve assolutamente a nulla  :Sad: 

----------

## HexDEF6

 *FonderiaDigitale wrote:*   

> considerazioni:
> 
> - usa per favore i tag del forum in maniera piu consistente!
> 
> 

 

in che senso?

 *FonderiaDigitale wrote:*   

> 
> 
> - quello che scrivi vale solo per openssh (non per ssh, la sintassi e' diversa)
> 
> - per far coesistere le due implementazioni si deve usare USE=openssh
> ...

 

hai ragione! in effetti io considero solo openssh

 *FonderiaDigitale wrote:*   

> 
> 
> - la prima buona regola per evitare noie e' bindare ssh a una porta diversa, preferibilmente, alta: in primis eviti una marea di scan e di TCP CONNECT, che se sei su una rete come alice che e' una groviera, e se hai una macchina scrausa come firewall, assicuro che vogliono dir tanto; in seconda istanza e' la prima maniera, la piu banale, per evitare gli exploit, anche xche appena esce un bug subito i vari script kiddies si mettono a scannare le classi B e C per una porta 22 vulnerabile
> 
> 

 

hai ragione anche in questo caso, aggiungero pure questo!

 *FonderiaDigitale wrote:*   

> 
> 
> - quando si modifica un file di configurazione di ssh, e non si e' sicuri che riparta, e' bene provarlo in debug su una porta diversa avviandolo in console e usando il parametro -p
> 
> 

 

ok ho imparato una cosa nuova!

 *FonderiaDigitale wrote:*   

> 
> 
> - contrariamente alla credenza popolare, /etc/init.d/sshd restart non uccide i processi figli attivi, e di conseguenza le sessioni attualmente aperte
> 
> 

 

questo lo sapevo!

 *FonderiaDigitale wrote:*   

> 
> 
> - per mantenere le chiavi pubbliche aperte attraverso le sessioni e' buona norma usare keychain (vedi i doc ufficiali di gentoo su come implementarlo)
> 
> 

 

me lo devo andare a vedere...

 *FonderiaDigitale wrote:*   

> 
> 
> - le sessioni non vanno tenute aperte e lasciate a pascolare in idle, per questo ti rimando a  questo mio howto che ho scritto parecchio tempo fa
> 
> 

 

questo dove lavoro non posso implementarlo (se scade la sessione si inc@zz@no pure)

 *FonderiaDigitale wrote:*   

> 
> 
> - fare nesting di login sulla stessa macchina non aumenta la sicurezza, che semmai va ricercata nell'accoppiata porta_alta+restrizioni di accesso da host specifici+chiave pubblica e privata tenuta su un media portatile (tipo penna usb)
> 
> 

 

Perche' no?, non metto in dubbio che cambiare porta sia importante, ma secondo me, aggiungere "uno strato" in piu' per arrivare alla vetta rende il tutto piu' sicuro.

 *FonderiaDigitale wrote:*   

> 
> 
> ciao

 

Ciao e grazie delle indicazioni!

----------

## .:chrome:.

 *HexDEF6 wrote:*   

>  *FonderiaDigitale wrote:*   
> 
> - fare nesting di login sulla stessa macchina non aumenta la sicurezza, che semmai va ricercata nell'accoppiata porta_alta+restrizioni di accesso da host specifici+chiave pubblica e privata tenuta su un media portatile (tipo penna usb)
> 
>  
> ...

 

no, perché se il tuo server è vulnerabile, rimane tale anche con lo strato in più... che nel particolare viene sfondato con la facilità con cui un coltello caldo entra nel burro... inoltre ti costringe a creare un utente dedicato, il che è una cosa estremamente discutibile, dal momento che una delle prime cose che si fanno, quando si vuole fare l'hardening di un sistema è appunto eliminare gli utenti inutili (compresi quelli di sistema con UID inferiore a 10).

pensa poi agli utenti che devono usare questo sistema: devono ricordarsi non una, ma due password, e vista l'idiozia media dell'utente, questo aumenta la possibilità che le due password siano identiche, o banali, o che se le scrivano da qualche parte.

secondo me è molto più sensato aumentare il livello di protezione usando i mezzi che il sistema stesso ti mette a disposizione.

tanto per intenderci: mi parli di sicurezza, ma non hai nominato PAM, wheel, acl e limiti (le primissime cose che mi vengono in mente)

----------

## HexDEF6

 *k.gothmog wrote:*   

> 
> 
> no, perché se il tuo server è vulnerabile, rimane tale anche con lo strato in più... che nel particolare viene sfondato con la facilità con cui un coltello caldo entra nel burro...
> 
> 

 

e su questo non c'e' dubbio, infatti io mi riferisco ad un sistema "virtualmente" senza bachi dove l'unica maniera per entrare e' conoscere le password..

 *k.gothmog wrote:*   

> 
> 
>  inoltre ti costringe a creare un utente dedicato, il che è una cosa estremamente discutibile, dal momento che una delle prime cose che si fanno, quando si vuole fare l'hardening di un sistema è appunto eliminare gli utenti inutili (compresi quelli di sistema con UID inferiore a 10).
> 
> 

 

come ho detto prima io sono tutto tranne un esperto di sicurezza, quindi i consigli sono ben accetti (howto, guide, pareri personali) quello su cui mi baso io e' la mia (poca) esperienza personale!

sono qui per imparare (anche dai miei errori!)

 *k.gothmog wrote:*   

> 
> 
> pensa poi agli utenti che devono usare questo sistema: devono ricordarsi non una, ma due password, e vista l'idiozia media dell'utente, questo aumenta la possibilità che le due password siano identiche, o banali, o che se le scrivano da qualche parte.
> 
> secondo me è molto più sensato aumentare il livello di protezione usando i mezzi che il sistema stesso ti mette a disposizione.
> ...

 

contro l'utente totalmente imbec**** non ci si puo' fare niente, se ha bisogno di accesso alla macchina in remoto, io l'unica cosa che posso imporgli e' come si deve fare (figurati che c'e' gente che vuole amministrarsi il proprio computer e ha ancora una redhat 6.2... ed e' fiero del fatto che non l'ha mai aggiornata)

 *k.gothmog wrote:*   

> 
> 
> tanto per intenderci: mi parli di sicurezza, ma non hai nominato PAM, wheel, acl e limiti (le primissime cose che mi vengono in mente)

 

come ho scritto io volevo parlare solo di ssh, non sono di sicuro un gran esperto di sicurezza e saper mettere assieme tutto per bene va al di la di quel che volevo postare (con tutto quello che c'e' da tirare in ballo si potrebbe scrivere un'enciclopedia) oltre che andar al di la delle mie conoscenze!

Pero' preferisco dare il mio apporto (e magari capire se quello che sto facendo e' sbagliato o meno) che tenermi tutto per me e credere che quello che faccio sia il top senza avere nessuno con cui confrontarmi.

Ciao

----------

## .:chrome:.

 *HexDEF6 wrote:*   

>  *k.gothmog wrote:*   
> 
> tanto per intenderci: mi parli di sicurezza, ma non hai nominato PAM, wheel, acl e limiti (le primissime cose che mi vengono in mente) 
> 
> come ho scritto io volevo parlare solo di ssh, non sono di sicuro un gran esperto di sicurezza e saper mettere assieme tutto per bene va al di la di quel che volevo postare (con tutto quello che c'e' da tirare in ballo si potrebbe scrivere un'enciclopedia) oltre che andar al di la delle mie conoscenze!
> ...

 

ma infatti ho citato funzioni del sistema strettamente legate a SSH  :Smile: 

puoi dire al server SSH di demandare l'autenticazione a PAM, in questo modo puoi imporre dei criteri minimi per l'accettazione delle password, e delle scadenze, nonché la chiusura di /bin/su agli utenti non autorizzati, che credo sia più vantaggioso rispetto a quel contorto passaggio per due utenti di cui parli tu  :Confused:  ... o almeno, questo è quello che penso io  :Wink: 

se la tua preoccupazione, comunque, è la sicurezza, ci sono molti possibili parametri in sshd_config che meritano di essere presi in considerazione. prova a dare un'occhiata a man sshd_config

----------

## HexDEF6

 *k.gothmog wrote:*   

> 
> 
> ma infatti ho citato funzioni del sistema strettamente legate a SSH 
> 
> puoi dire al server SSH di demandare l'autenticazione a PAM, in questo modo puoi imporre dei criteri minimi per l'accettazione delle password, e delle scadenze,
> ...

 

A dire la verita' ho tutti gli ssh che usano PAM (credo sia di default in quasi tutte le distribuzioni o mi sbaglio?), e hai ragione, potrei integrare l'howto con un minimo di configurazione di PAM e cracklib...

 *k.gothmog wrote:*   

> 
> 
> nonché la chiusura di /bin/su agli utenti non autorizzati, che credo sia più vantaggioso rispetto a quel contorto passaggio per due utenti di cui parli tu  ... o almeno, questo è quello che penso io 
> 
> 

 

si forse hai ragione... piu' ci penso su e piu' gli utenti multipli hanno "qualcosa che non va"... se hai altri suggerimenti sono contento!

 *k.gothmog wrote:*   

> 
> 
> se la tua preoccupazione, comunque, è la sicurezza, ci sono molti possibili parametri in sshd_config che meritano di essere presi in considerazione. prova a dare un'occhiata a man sshd_config

 

il problema e' che devo bilanciare sicurezza e usabilita (con gente che ODIA i cambiamenti...  :Sad:   )

tipo come cosa minima sto cercando di passare piu' pc (ne ho circa una sessantina da gestire) da ip pubblico a ip privato (per raggiungere la propria macchina dall'esterno si appoggiano su un pc con server ssh che puo' fare solo ssh) e sto incontrando grosse opposizioni anche da gente che non sa che differenza ci sia tra ip pubblico e privato.. solo adesso che hanno bucato 2 macchine (una red hat 7.3  :Shocked:   e una debian testing, che a dire la verita' e' stata bucata perche' sulla red hat hanno installato un keylogger) qualcuno smolla il proprio ip pubblico...

Molti non mi permettono nemmeno di mettere mano al loro pc (e quindi nessuno controlla i log o fa aggiornamenti) e mi vengono a chiedere aiuto solamente quando la macchina o va a pezzi o vanno in conflitto i 2 o 3 rootkit installati (ti assicuro che non sto scherzando)

Ok adesso vado a nanna... ma se avete altri suggerimenti vi ringrazio!

----------

## .:chrome:.

 *HexDEF6 wrote:*   

>  *k.gothmog wrote:*   
> 
> ma infatti ho citato funzioni del sistema strettamente legate a SSH 
> 
> puoi dire al server SSH di demandare l'autenticazione a PAM, in questo modo puoi imporre dei criteri minimi per l'accettazione delle password, e delle scadenze,
> ...

 

io ci andrei piano con PAM, cracklib, & soci... non è facile metterci le mani  :Sad: 

 *HexDEF6 wrote:*   

>  *k.gothmog wrote:*   
> 
> nonché la chiusura di /bin/su agli utenti non autorizzati, che credo sia più vantaggioso rispetto a quel contorto passaggio per due utenti di cui parli tu  ... o almeno, questo è quello che penso io 
> 
>  si forse hai ragione... piu' ci penso su e piu' gli utenti multipli hanno "qualcosa che non va"... se hai altri suggerimenti sono contento!
> ...

 beh... quello che c'era da dire è già stato detto. meno utenti ci sono e meglio è

 *HexDEF6 wrote:*   

> 
> 
>  *k.gothmog wrote:*   
> 
> se la tua preoccupazione, comunque, è la sicurezza, ci sono molti possibili parametri in sshd_config che meritano di essere presi in considerazione. prova a dare un'occhiata a man sshd_config 
> ...

 

quando mi trovo davanti a questo tipo di problemi la risposta è una sola: "l'amministratore di rete sono io, e quello che risponde delle cazzate che combinano gli utenti alla polizia postale sono io. siccome non voglio rischiare il posto e la testa si fa come dico io, altrimenti qualcuno mi solleva dalla responsabilità penale di quello che succede qui dentro". ci sono poche persone così stupide da controbattere a questo.

per il problema del login, io farei una cosa diversa: abiliterei il forward di alcune porte sul firewall. mi spiego:

login sulla porta 22 -> login sul firewall

login sulla 10122 -> login su 192.168.1.1

login sulla 10222 -> login su 192.178.1.2

e così via... in questo modo non devi creare utenze sulla macchina di frontiera, ma ognuno usa la sua (e ognuno ha la responsabilità della sua macchina)

da me, in università, è successo un piccolo pasticcio. sai come si è risolto? 802.1X e radius sulla rete interna. banditi i pc portatili, e se uno studente stacca un pc fisso dalla rete, non solo viene tracciato, loggato e disattivata la porta, ma il tipo viene pure preso e sospeso.

se tu sei l'amministratore non ci devi rimettere le chiappe per i tuoi utenti. le regole le devi dettare tu!

----------

## HexDEF6

 *k.gothmog wrote:*   

> 
> 
> io ci andrei piano con PAM, cracklib, & soci... non è facile metterci le mani 
> 
> 

 

per ora ho smanettato solamente con le limit di pan (visto che molti computer sono adibiti a calcoli devo far si che chi lo usa da remoto abbia un nice piu' alto) e un po con le cracklib... ovviamente prima approfondisco e poi se ne cavo qualcosa di utile aggiungo nell'howto (e se ci sono cavolate sono sicuro che qui non passeranno innosservate!)

 *k.gothmog wrote:*   

> 
> 
> quando mi trovo davanti a questo tipo di problemi la risposta è una sola: "l'amministratore di rete sono io, e quello che risponde delle cazzate che combinano gli utenti alla polizia postale sono io. siccome non voglio rischiare il posto e la testa si fa come dico io, altrimenti qualcuno mi solleva dalla responsabilità penale di quello che succede qui dentro". ci sono poche persone così stupide da controbattere a questo.
> 
> 

 

Il problema e' che io non sono il responsabile di queste cose, e non posso obbligare nessuno a darmi l'accesso da root della macchina, in teoria io dovrei solo dare una mano a installare programmi e fare delle aggiustatine ai computer, ma ovviamente quando succedono i casini me li devo ciucciare io (non legalmente parlando!).. la questione della sicurezza e' qualcosa che ha iniziato il tipo che lavorava prima di me (prima avevano tutti ip pubblico senza firewall ecc. praticamente allo sbando totale... figurati che avere un paio di macchine craccate al mese era considerato normalissimo) e io voglio portare avanti per avere meno rogne possibili in futuro... 

 *k.gothmog wrote:*   

> 
> 
> per il problema del login, io farei una cosa diversa: abiliterei il forward di alcune porte sul firewall. mi spiego:
> 
> login sulla porta 22 -> login sul firewall
> ...

 

la macchina perimetrale non e' sotto la mia "giurisdizione" quindi si usa cosi'!

Ciao!

----------

## .:chrome:.

beh... quello che posso dirti, è di parlare con i kapi e i responsabili della macchina di frontiera e di far aprire loro gli occhi... in una rete non può mancare una policy di sicurezza!

di solito la guardia di finanza e la polizia postale sono delle ottime argomentazioni per convincere le persone.

----------

## HexDEF6

 *k.gothmog wrote:*   

> beh... quello che posso dirti, è di parlare con i kapi e i responsabili della macchina di frontiera e di far aprire loro gli occhi... in una rete non può mancare una policy di sicurezza!
> 
> di solito la guardia di finanza e la polizia postale sono delle ottime argomentazioni per convincere le persone.

 

si ma tu non hai mai avuto a che fare con la burocrazia!!

Ti faccio un paio di esempi:

- le macchine con ip pubblico non sono minimamente firewallate... perche'? per via di un ricercatore che fa esperimenti sul p2p (e quindi ha bisogno di avere tutte le porte aperte) tutti hanno tutte le porte aperte (decisione del preside di facolta')

- hanno provato a staccare il server telnet da una delle macchine "principali", per una settimana ci sono state circa 100 telefonate al giorno di lamentele, e quindi i grandi capi (occhio non i tecnici) hanno fatto rimettere in piedi il telnet

- pur avendoli gia configurati, il server di posta non supporta pop3s e imaps ma solo le versioni non crittate... tutto questo perche' c'e' gente che non ha ancora capito minimamente cosa sia la sicurezza informatica

praticamente ci ritroviamo un gruppo di tecnici qualificati che per motivi burocratici o politici non possono "mettere le cose a posto"

Io nel mio piccolo (praticamente lavoro solo nel dipartimento di fisica teorica) tento di fare il possibile (dove mi lasciano) ma per il resto la rete universitaria e' un mezzo colabrodo!

Ciao!

----------

## .:chrome:.

 *Quote:*   

> si ma tu non hai mai avuto a che fare con la burocrazia!!

 

ah no? io sono la prima persona che vanno a prendere se succede qualcosa alle macchine che ho in gestione, in università. mi rimetto alle disposizioni generali del centro reti, ma alla fine che detta legge sono io, e che ci rimette le chiappe se qualcosa va male sono sempre io

 *Quote:*   

> Ti faccio un paio di esempi:
> 
> - le macchine con ip pubblico non sono minimamente firewallate... perche'? per via di un ricercatore che fa esperimenti sul p2p (e quindi ha bisogno di avere tutte le porte aperte) tutti hanno tutte le porte aperte (decisione del preside di facolta')
> 
> - hanno provato a staccare il server telnet da una delle macchine "principali", per una settimana ci sono state circa 100 telefonate al giorno di lamentele, e quindi i grandi capi (occhio non i tecnici) hanno fatto rimettere in piedi il telnet
> ...

 scusa eh... ma questa non è burocrazia. quella è ben altra cosa. questa è pura idiozia

 *Quote:*   

> praticamente ci ritroviamo un gruppo di tecnici qualificati che per motivi burocratici o politici non possono "mettere le cose a posto"
> 
> Io nel mio piccolo (praticamente lavoro solo nel dipartimento di fisica teorica) tento di fare il possibile (dove mi lasciano) ma per il resto la rete universitaria e' un mezzo colabrodo!
> 
> 

 non era il massimo neanche da noi prima che arrivasse l'attuale responsabile di rete.

poi arriva questo qui, che si è permesso di collaborare solo con i Bell Labs e di scrivere qualche RFC... credo di avere imparato più da lui che da chiunque altro

----------

## FonderiaDigitale

attenzione a pam: le password passano in chiaro tra i vari moduli.

questo e' uno dei motivi per cui e' stato rimosso il supporto cracklib nativo in samba, tra l'altro.

pensateci prima di aggiungere un'autenticazione che in alcuni casi e' superflua

----------

## .:chrome:.

 *FonderiaDigitale wrote:*   

> attenzione a pam: le password passano in chiaro tra i vari moduli.

 

scusa...? questa mi manca... puoi dare qualche notizia in più, perché non ho nemmeno capito bene cosa intendi

----------

## kaosone

le cose che mi sono venute in mente sono che 

8 caratteri sono pochi, io consiglio > 10 caratteri 

la public key e' MALE se non associata a una keyword...

----------

## hellraiser

Scusate forse l [OT]...ma perche non facciamo un post in cui raccogliamo un po di materiale sulla Sicurezza??

Magari TIP - HOWTO - Esperienze personali

Secondo me sarebbe molto interessante e utile...anche per gli utenti poco informati.

Che ne dite???

----------

## FonderiaDigitale

 *k.gothmog wrote:*   

>  *FonderiaDigitale wrote:*   attenzione a pam: le password passano in chiaro tra i vari moduli. 
> 
> scusa...? questa mi manca... puoi dare qualche notizia in più, perché non ho nemmeno capito bene cosa intendi

 

intendo che tra i vari socket interni alla macchina le password girano non criptate.

vedi ad esempio questo.

----------

## .:chrome:.

 *FonderiaDigitale wrote:*   

> intendo che tra i vari socket interni alla macchina le password girano non criptate.
> 
> vedi ad esempio questo.

 

beh... ma finché si tratta di socket interni, il problema non dovrebbe essere grave, no?

voglio dire... chi se ne frega se girano le password in chiaro? tanto sono appunto comunicazioni interne, su localhost

----------

## xchris

qualche considerazione.

Parlare di sicurezza in assoluto senza menzionare l'ambito non ha alcun senso a mio avviso.

-Eccedere nel hardening di un sistema spesso e' + dannoso che salutare su sistema gia' intrinsecamente sicuri.

(perche' magari gia' sotto altri tipi di firewall)

-E' necessario sapere se ci sono utenti locali o meno.

ecc ecc!

Esistono sempre alcuni parametri correlati su cui giocare.

- sicurezza in senso assoluto

- tempo necessario per l'hardening

- esposizione ai rischi

- abliita' amministratore (spesso una macchina e' consegnata ad un cliente che poco sa di linux)

- altri che dimentico

E' importante trovare un buon compromesso.

(a meno che la vostra missione e' quella di renderlo sicuro a costo di passare notti su questa macchina e prendere magari 2 soldi per realizzarla e magari lasciarla libera ad attacchi HARDWARE (la donna delle pulizie che stacca la spina....e' sempre un DDOS))

Quindi ai due amici cari che hanno risposto per primi.... non siate sempre cosi' paranoici!  :Very Happy: 

Tutto dipende dall'ambito...

Sul fatto che il nesting di login sia inutile non sono proprio d'accordo.

(spesso la macchina va in gestione a clienti che mettono la password del figlio.... mettere un utente extra anche con la stessa password aiuta di sicuro)

(gli attacchi + pericolosi sono quelli che passano per via non informatica a mio avviso.

Interessante lo spunto sul /etc/init.d/ssh restart

E infine un plauso a HexDEF6 perche' iniziare un thread cosi' non e' semplice e ha permesso cmq a persone meno esperte di avventurarsi in questo mondo complicatissimo della sicurezza.

....e un plauso e un incoraggiamento perche' come un kamikaze si e' esposto ai rompiballe del forum  :Very Happy:   :Laughing: 

ciao

EDIT: quando dico rompiballe... prendetela con filosofia... (ormai Fonderia e' un po' abituato con me...vero?  :Wink: )

----------

## randomaze

 *HexDEF6 wrote:*   

>  *FonderiaDigitale wrote:*   considerazioni:
> 
> - usa per favore i tag del forum in maniera piu consistente!
> 
>  
> ...

 

Suppongo qualcosa di simile:

[ATTENZIONE]

Questo mini-howto non ha nessuna pretesa di essere la soluzione a tutti i problemi di sicurezza di una macchina gestita in remoto, ma sono solo "pensieri" che mi sono saltati in mente dopo aver visto bucare alcune macchine dove lavoro.. quindi se avete suggerimenti sono benvenuti!

PARTE SERVER

Configurazione

Normalmente ssh permette l'accesso diretto da root

infatti se guardiamo in /etc/ssh/sshd_config troviamo:

```

PermitRootLogin yes

```

e se e' commentato (o non presente) verra' usato il parametro di default (che e' yes).

....

Per gli utenti firefox c'é una comoda estensione: BBCode  :Wink: 

----------

## kaosone

imho bastano il bold e il code... anzi colorato e con diverse dimensioni, diventa anche piu faticoso da leggere..

----------

## stefanonafets

Se si tratta di macchine veramente critiche si potrebbe anche considerare (ma dipende dal budget) anche (ANCHE, nn solo) l'utilizzo di smart-card, piuttosto che le chiavette della RSA secure-id, imho.

Aspetto smentite  :Very Happy: 

----------

## FonderiaDigitale

 *xchris wrote:*   

> 
> 
> Quindi ai due amici cari che hanno risposto per primi.... non siate sempre cosi' paranoici! 

 

fiu..menomale non sono tra i primi 2. forse l'ho scampata stavolta

 *Quote:*   

> 
> 
> Sul fatto che il nesting di login sia inutile non sono proprio d'accordo.
> 
> (spesso la macchina va in gestione a clienti che mettono la password del figlio.... mettere un utente extra anche con la stessa password aiuta di sicuro)
> ...

 

io partivo dal presupposto che la macchina venga data in gestione o manutenuta da una persona dotata di coscienza e buon senso; se questi mancano non c'e' sicurezza che tenga (ad esempio basta che il figlio scopra che esistono i boot in single mode, tanto per dirne 1)

 *Quote:*   

> 
> 
> (gli attacchi + pericolosi sono quelli che passano per via non informatica a mio avviso.
> 
> Interessante lo spunto sul /etc/init.d/ssh restart
> ...

 

non lo avevo sottolineato pensando che hexdef6 ne fosse ignorante, quanto per farlo presente a tanti CHE PENSANO DI SI.

 *Quote:*   

> 
> 
> ....e un plauso e un incoraggiamento perche' come un kamikaze si e' esposto ai rompiballe del forum  
> 
> EDIT: quando dico rompiballe... prendetela con filosofia... (ormai Fonderia e' un po' abituato con me...vero? )

 

ecco. gnapotevofa. lo sapevo.  :Very Happy: 

----------

## FonderiaDigitale

 *k.gothmog wrote:*   

>  *FonderiaDigitale wrote:*   intendo che tra i vari socket interni alla macchina le password girano non criptate.
> 
> vedi ad esempio questo. 
> 
> beh... ma finché si tratta di socket interni, il problema non dovrebbe essere grave, no?
> ...

 

non ne sarei tanto sicuro.. il fatto che sia interno alla macchina non lo rende meno vulnerabile (quanti exploit per apache davano accesso a /dev/kmem?)

se poi ci sono utenti locali non ne parliamo proprio.  :Mad: 

in ogni caso una cosa che mi insegnarono in croce rossa ma che val bene anche in questo ambito è: meglio sopravvalutare che sottovalutare. si lo so. sono paranoico. ma con moderazione.. vedi il "rompiballe" di xchris di cui sopra.  :Smile: 

----------

## kaosone

si ma per avere accesso a kmem devi comunque essere root (anche se kmem e' 777)

----------

## .:chrome:.

 *FonderiaDigitale wrote:*   

> non ne sarei tanto sicuro.. il fatto che sia interno alla macchina non lo rende meno vulnerabile (quanti exploit per apache davano accesso a /dev/kmem?)

 

ma se devo essere paranoico, piuttosto che rinunciare a PAM e cracklib, blindo il sistema con apposite patch (PaX ad esempio). questo non altera il funzionamento del sistema (o comunque lo fa meno rispetto alla rimozione di pam e/o cracklib) e mi garantisce immunità pressoché assoluta verso quel tipo di aggressione

----------

## FonderiaDigitale

senza entrare in polemiche ma sopratutto senza finire OT, che PAX alteri meno un sistema che eliminare pam ho dei grossi dubbi, in sincerita': usare pax significa patchare un kernel, DOVER RIAVVIARE una macchina, e non e' sempre possibile. specie in azienda.

poi fare tanto ma tanto tuning, far fare learning alle ACL dei demoni, sistemarle dopo averlo fatto (che quasi mai funzionano subito), dover installare le user-space utilities ecc.

Per sostituire pam con un altro metodo di autenticazione non inchiodo un servizio o una macchina, posso farlo online mantenendo l'autenticazione esistente e provando su istanze separate nella stessa macchina, non devo per forza compromettere la stabilita' del core.

non e' proprio la stessa cosa.

Inoltre ti garantisco che anche pax si buca: ci sono degli 0day molto carini a cui nessun grsec regge. non posso entrare in dettagli xche e' un lavoro non mio, cmq e' uno dei motivi x cui dove posso sto migrando a selinux.

Ah un'altra cosa: grsecurity di default protegge solo dai BoF. gli altri attacchi passano: vogliamo contare quanti di quelli che mettono pax poi si mettono a configurare le acl?

----------

## .:chrome:.

 *FonderiaDigitale wrote:*   

> senza entrare in polemiche ma sopratutto senza finire OT, che PAX alteri meno un sistema che eliminare pam ho dei grossi dubbi, in sincerita': usare pax significa patchare un kernel, DOVER RIAVVIARE una macchina, e non e' sempre possibile. specie in azienda.
> 
> poi fare tanto ma tanto tuning, far fare learning alle ACL dei demoni, sistemarle dopo averlo fatto (che quasi mai funzionano subito), dover installare le user-space utilities ecc.
> 
> Per sostituire pam con un altro metodo di autenticazione non inchiodo un servizio o una macchina, posso farlo online mantenendo l'autenticazione esistente e provando su istanze separate nella stessa macchina, non devo per forza compromettere la stabilita' del core.
> ...

 

vabbè... ormai finiamo OT, il discorso lo merita  :Smile: 

per quello che dici te, un mio amico ha fatto un lavoro di ricerca molto interessante riguardo all'abbinamento di PaX e GRSecurity. non è che io abbia una grande esperienza in fatto di pen-test, ma visto così, mi sembra una cosa parecchio solida.

per quella storia degli 0day sarei molto interessato... proprio non riesci a darmi qualche dritta?

----------

## HexDEF6

ho aggiunto qualcosa, ho messo un po di bbcode (spero che il tutto sia piu' leggibile)...

adesso potete riprendere a massacrarmi  :Laughing: 

a parte gli scherzi, altri suggerimenti sono benvenuti!

Ciao!

----------

