ssh e un po di sicurezza..

[HexDEF6]

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.*
A volte puo' essere comodo usare la direttiva DenyUsers, in questo modo tutti gli utenti della macchina possono loggarsi tranne quelli esplicitamente proibiti da DenyUsers

DenyUsers localuser

in questo modo l'utente localuser puo' loggarsi solamente in locale, la direttiva e' molto comoda per creare degli account di "guest" con password note a tutti, ma impedirne l'utilizzo remoto.


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 serve?

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"

alcune note sui tunnel

normalmente se fate un tunnel con ssh, questo sara' disponibile solo per la macchina locale (verificate con un netstat -pl) se invece volete rendere il tunnel disponibile anche ad altre macchine dovete usare l'opzione -g. Quindi se lanciate:

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

chiunque (ovviamente se il vostro firewall lo permette!) puo' collegarsi al vncserver remoto usando:

vncviewer 193.205.x.x:3

questa opzione puo' venire comoda, cosi' non serve che tutti aprano un tunnel con ssh, ma si possono appoggiare a quello creato dalla vostra macchina.

Altra utile opzione del client ssh e' -R, per mette di ridirigere una porta di una macchina vista dal client su una porta sul server:

ssh -R 3000:127.0.0.1:22 user@server

in questo modo quando mi collego al server ridirigo la porta ssh del client sulla 3000 del server. Questo puo' venire molto utile per chi ha un ip privato e vuole essere raggiunto dall'esterno (tipo chi ha una connessione con fastweb), ovviamente si ha bisogno di un computer esterno su cui appoggiarsi (tipo un computer di facolta'!)
esempio:
pc1: 192.168.10.20 (rete fastweb o rete aziendale o comunque per qualche motivo avete un ip privato)
pc2: 193.200.X.X
dal pc1 lanciate:

ssh -R 4000:127.0.0.1:22 user@193.200.X.X

dopo esservi loggati bisogna ricordarsi che ssh fa cadere la connessione se non passano pacchetti per un po di tempo.. quindi magari potreste lanciare qualcosa del genere:

 while [ 1 ]; do echo "Ciao"; sleep 15; done

adesso avete un tunnel stabile (finche' non vi si sconnette internet!)
una volta arrivati al vostro server, potete raggiungere il vostro pc con:

ssh -p 4000 user@127.0.0.1

e vi collegate al pc di casa direttamente anche se si trova dietro firewall e con ip privato!


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

ssh come vpn

dalla versione 4.3 ssh comprende il supporto per TUN/TAP, in questa maniera si possono andare a creare delle vpn usando il solo ssh! (occhio che e' differente dal port forwarding!)

per poter creare un tunnel bisogna avere la possibilita' di accedere al device /dev/tun0 (da entrambi i capi della vpn)... normalmente questo succede solo per l'utente root, quindi occhio ai permessi! (lanciate ssh con i parametri -vvv per avere un po di info su quello che succede)

per prima cosa bisogna abilitare una voce nell'sshd_config:

PermitTunnel yes

una volta fatto questo (ricordatevi di far ripartire il server ssh) basta lanciare dal client:

ssh -w 0:0 host-remoto

in questa maniera si crea un tunnel tra i due tun0 (sul client e sul server)

adesso bisogna dare un ip alle 2 nuove interfacce di rete:

sul server:

ifconfig tun0 192.168.99.1 netmask 255.255.255.252

sul client

ifconfig tun0 192.168.99.2 netmask 255.255.255.252

in questa maniera si dovrebbero pingare tra di loro...
ma per raggiungere la sottorete interna (lato server) bisogna fare (sul client):

route add -net SOTTORETE_PARTE_SERVER/NETMASK_RELATIVA dev tun0

Ciao

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

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)
edit3: aggiunta l'opzione -g per i tunnel ssh
edit4: aggiunta la possibilita' di creare vpn

todo:
bugfix vari

[ilsensine]

Bello, mi piace. Se puoi integrare con la creazione di un tunnel ssh è perfetto.

Sposto nella sez. di documentazione.

[HexDEF6]

Originariamente inviato da ilsensine

Bello, mi piace. Se puoi integrare con la creazione di un tunnel ssh è perfetto.

Sposto nella sez. di documentazione.

volevo farlo... ma per oggi il tempo e' tiranno... comunque domani mattina integro la parte di tunnel ssh per far andare vnc e rsync

Ciao!

edit: ho aggiunto una piccola parte dei tunnel, domani dovrei aver tempo di spiegare l'uso di -R

[HexDEF6]

discutendone con altri, ho notato che nel mini howto ci sono alcune cose da correggere e da aggiungere:
cambiare porta a ssh
togliere la configurazione 3 che a detta di molti e' un passaggio inutile (e aumentare il numero di utenti sulla macchina e' male)
e altre cose, quindi adesso sto rielaborando il tutto, quando arrivo ad una conclusione decente modifico il primo post.

Ciao!

[ilsensine]

Fai con comodo. Quando hai finito metto un link nei thread con gli howto, ed elimino i post "spazzatura" (tipo questo )

[HexDEF6]

Originariamente inviato da ilsensine

Fai con comodo. Quando hai finito metto un link nei thread con gli howto, ed elimino i post "spazzatura" (tipo questo )

ok... ma siccome a casa sto cambiando adsl, non so quando posso farlo (spero di mettere a posto il tutto per domenica)..

Ciao!

[ilsensine]

Riporto temporaneamente nella sezione principale. Chi è interessato può fare commenti/richieste/suggerimenti.

Quando la guida sarà finita la inserirò tra gli howto.

[Duncan]

Bellissima guida complimenti

[kingv]

molto utile, soprattutto non sapevo del demone port knocking (fig@t@ ).


un appunto per la configurazione per il login tramite chiavi rsa.
è vero che anche un password si puo' dimenticare ma se potete lavorare solo da remoto sulle macchine su cui avete configurato sshd FATEVI 10 BACKUP della chiave privata, altrimenti non c'e' modo per cui riusciate a rientrare nelle macchine che hanno la vostra chiave pubblica.

[_YTS_]

direi che è un ottimo e semplice mini-howto!!
puoi inserire qualcosa sul privilege separation?

http://www.citi.umich.edu/u/provos/ssh/privsep.html

e magari come creare una jail per ssh? ho trovato questo...

http://www.tokkee.de/howtos/chrooted_ssh_howto.pdf

ciao

[HexDEF6]

Finalmente ho trovato un po di tempo e ho aggiunto l'opzione -R, direi che il mini howto puo' considerarsi completo, servirebbe un bel bugfix per quanto riguarda l'itagliano... se ci sono da fare correzzioni o altro fatemi sapere!

Originariamente inviato da _YTS_

direi che è un ottimo e semplice mini-howto!!
puoi inserire qualcosa sul privilege separation?

http://www.citi.umich.edu/u/provos/ssh/privsep.html

privilege separation e' di default attivo in ssh quindi credo non serva aggiungere questo gran che..

Originariamente inviato da _YTS_

e magari come creare una jail per ssh? ho trovato questo...

http://www.tokkee.de/howtos/chrooted_ssh_howto.pdf

ciao

direi che chroot e' fuori dalla portata di questo howto, che dovrebbe essere usato come base per avere un minimo di sicurezza anche per un utente con poca o nulla dimestichezza con i file di configurazione!
Ovviamente se qualcuno vuole ampliare o darmi una mano ad aggiungere altro, ne sarei piu' che felice!

Ciao!

[HexDEF6]

Direi che il tutto puo' considerarsi finito.. ameno che qualcuno non abbia altre modifiche/suggerimenti...

[LimiT-MaTz]

mi viene in mente questa cosa:
tu dici di lasciare un user "A" allowed(per ssh) che non appartenga al gruppo wheel che accetti connessioni dalla "rete esterna" e una volta connessi aprire ssh verso l'utente "B" (che ha accesso solo da localhost) su cui effettuale un bel "su".

A questo punto mi viene in mente poiche' l'utente A e' quello + accessibile dall'esterno perche non eliminari tutti quegli applicativi che non servono(naturalmente nel momento in cui pensiamo di avere un utente che svolga solo questo lavoro)e lasciare solo ssh (per connettersi a "B") ad esempio mi verrebbe in mente di fare degli appicativi "dummy" che lancino /bin/false.

ad esempio nel momento in cui l'utente a scrive ls (in realtà esegue /bin/false).
Cosi' facendo non si incrementerebbe maggiormente la sicurezza? o sarebbe solo una perdita di tempo?


spero di essermi spiegato
l'ho riletto 3 volte e ogni volta che lo modifico il mio itaGliano peggiora...
meglio andare a letto ...

[HexDEF6]

Originariamente inviato da LimiT-MaTz

mi viene in mente questa cosa:
tu dici di lasciare un user "A" allowed(per ssh) che non appartenga al gruppo wheel che accetti connessioni dalla "rete esterna" e una volta connessi aprire ssh verso l'utente "B" (che ha accesso solo da localhost) su cui effettuale un bel "su".

si... ma questa soluzione puo' funzionare solo per alcuni casi particolari.. il piu' delle volte aggiungere un utente al sistema vuol dire aumentare i rischi...

Originariamente inviato da LimiT-MaTz

A questo punto mi viene in mente poiche' l'utente A e' quello + accessibile dall'esterno perche non eliminari tutti quegli applicativi che non servono(naturalmente nel momento in cui pensiamo di avere un utente che svolga solo questo lavoro)e lasciare solo ssh (per connettersi a "B") ad esempio mi verrebbe in mente di fare degli appicativi "dummy" che lancino /bin/false.

ad esempio nel momento in cui l'utente a scrive ls (in realtà esegue /bin/false).
Cosi' facendo non si incrementerebbe maggiormente la sicurezza? o sarebbe solo una perdita di tempo?

diciamo che qualcosa del genere si ottiene facendo girare l'ssh in un gabbia (il cosidetto chroot) quindi l'utente A si connette al server e da questo punto puo' lanciare solo il comando ssh (l'unico comando che si va a mettere nel chroot.. insieme ad una bash e poco altro) anche se per qualche motivo riesce a ottenere i privilegi da root, in teoria, rimane confinato nella gabbia (dove, sempre in teoria, puo' fare danni limitati)...

Originariamente inviato da LimiT-MaTz

spero di essermi spiegato
l'ho riletto 3 volte e ogni volta che lo modifico il mio itaGliano peggiora...
meglio andare a letto ...

spero di aver risposto! e non ti preoccupare... per l'itaGliano sei in compagnia (sicuramente la mia!)!

[LimiT-MaTz]

Originariamente inviato da HexDEF6

diciamo che qualcosa del genere si ottiene facendo girare l'ssh in un gabbia (il cosidetto chroot) quindi l'utente A si connette al server e da questo punto puo' lanciare solo il comando ssh (l'unico comando che si va a mettere nel chroot.. insieme ad una bash e poco altro) anche se per qualche motivo riesce a ottenere i privilegi da root, in teoria, rimane confinato nella gabbia (dove, sempre in teoria, puo' fare danni limitati)...

ora mi informo un po su questo sistema che mi sembra molto valido (ma forse eccessivo?!?).
Dato che dovrei fare un server di posta per una aziendina e ssh mi serve di sicuro per la gestione. Ti ringrazio ciao!

[RaouL_BennetH]

potresti aggiungere qualcosa anche sull'X forwarding?
(considerando magari un client per windows come putty o una shell tipo cygwin)
Thx.

[figulus]

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?

Bello il gioco di parole!

Comunque complimenti per l'how-to.

[sblantipodi]

complimenti vivissimi
Davvero eccellente.

[HexDEF6]

Originariamente inviato da RaouL_BennetH

potresti aggiungere qualcosa anche sull'X forwarding?
(considerando magari un client per windows come putty o una shell tipo cygwin)
Thx.

beh, sotto windows bisognerebbe anche aggiungere l'installazione di un server X (tipo xorg con cygwin), e diventerebbe un po troppo dispersiva la faccenda... pero' un accenno all'Xfowarding lo posso mettere (anche se preferisco un tunnel e usare vnc)...

Originariamente inviato da figulus

Bello il gioco di parole!

doh! commetto questo errore ogni volta che parlo di server!

Originariamente inviato da figulus

Comunque complimenti per l'how-to.

Grazie!

[pinok]

Con che diritti gira knockd?
In questo post http://lists.debian.org/debian-itali.../msg00275.html di sostiene che alla fine introduca più debolezze che sicurezze.
Senza offesa, chi ha ragione? O forse dal 2004 ad oggi qualcosa è cambiato in knockd?

Grazie !