|
|
|
|
Strumenti |
13-04-2005, 10:51 | #1 |
Senior Member
Iscritto dal: Dec 2000
Città: Trento
Messaggi: 5917
|
ssh e un po di sicurezza..
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: Codice:
PermitRootLogin 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: Codice:
PermitRootLogin no 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: Codice:
AllowUsers utente1 utente2 inoltre con questa direttiva si puo' specificare da dove puo' essere fatto il login: Codice:
AllowUsers utente1@* utente2@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 Codice:
DenyUsers localuser Configurazione3A Andando nel paranoico, possiamo usare la direttiva AllowUsers per mettere un ulteriore passaggio per avere accesso da root... infatti se usiamo: Codice:
AllowUsers utente1@* utente2@127.0.0.1 utente2@localhost 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: Codice:
Port Codice:
Port 2865 Codice:
ssh -p 2865 user@server 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: Codice:
ssh-keygen -t 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: Codice:
scp ~/.ssh/id_rsa.pub utente_ser@server: Codice:
ssh utente_ser@server: Codice:
cat id_rsa.pub >> .ssh/authorized_keys2 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! Codice:
ssh-agent ssh-add 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: Codice:
PermitRootLogin without-password AllowUsers utente1@* utente2@127.0.0.1 utente2@localhost root@ip_del_vostro_pc 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: Codice:
ssh -L 5903:127.0.0.1:5903 user@server Codice:
vncviewer 127.0.0.1:3 -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: Codice:
ssh -L 5903:192.168.0.1:5903 user@212.122.x.x 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: Codice:
ssh -L 873:ip_server_rsync:873 user@macchina_periferica poi basta modificare make.conf e dire di usare come server rsync 127.0.0.1 Codice:
SYNC="rsync://127.0.0.1/gentoo-portage" 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: Codice:
ssh -g -L 5903:192.168.0.1:5903 user@212.122.x.x Codice:
vncviewer 193.205.x.x:3 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: Codice:
ssh -R 3000:127.0.0.1:22 user@server 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: Codice:
ssh -R 4000:127.0.0.1:22 user@193.200.X.X Codice:
while [ 1 ]; do echo "Ciao"; sleep 15; done una volta arrivati al vostro server, potete raggiungere il vostro pc con: Codice:
ssh -p 4000 user@127.0.0.1 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) Codice:
ssh -D 5000 user@macchina_perimetrale Codice:
#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 Codice:
tsocks mozilla o potete fare un ssh all'esterno: Codice:
tsocks ssh user@server_esterno 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: Codice:
PermitTunnel yes Codice:
ssh -w 0:0 host-remoto adesso bisogna dare un ip alle 2 nuove interfacce di rete: sul server: Codice:
ifconfig tun0 192.168.99.1 netmask 255.255.255.252 Codice:
ifconfig tun0 192.168.99.2 netmask 255.255.255.252 ma per raggiungere la sottorete interna (lato server) bisogna fare (sul client): Codice:
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
__________________
Linux User #272700 >+++++++++[<+++++++++>-]<+.++.>++++[<---->-]<++.+++++++. HOWTO: SSH Firewall e DMZ ɐɹdosoʇʇos oʇuǝs ıɯ Ultima modifica di HexDEF6 : 03-02-2009 alle 10:55. |
13-04-2005, 10:59 | #2 |
Senior Member
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
|
Bello, mi piace. Se puoi integrare con la creazione di un tunnel ssh è perfetto.
Sposto nella sez. di documentazione.
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12 |
13-04-2005, 11:20 | #3 | |
Senior Member
Iscritto dal: Dec 2000
Città: Trento
Messaggi: 5917
|
Quote:
Ciao! edit: ho aggiunto una piccola parte dei tunnel, domani dovrei aver tempo di spiegare l'uso di -R
__________________
Linux User #272700 >+++++++++[<+++++++++>-]<+.++.>++++[<---->-]<++.+++++++. HOWTO: SSH Firewall e DMZ ɐɹdosoʇʇos oʇuǝs ıɯ Ultima modifica di HexDEF6 : 13-04-2005 alle 16:56. |
|
15-04-2005, 08:39 | #4 |
Senior Member
Iscritto dal: Dec 2000
Città: Trento
Messaggi: 5917
|
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!
__________________
Linux User #272700 >+++++++++[<+++++++++>-]<+.++.>++++[<---->-]<++.+++++++. HOWTO: SSH Firewall e DMZ ɐɹdosoʇʇos oʇuǝs ıɯ |
15-04-2005, 09:09 | #5 |
Senior Member
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
|
Fai con comodo. Quando hai finito metto un link nei thread con gli howto, ed elimino i post "spazzatura" (tipo questo )
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12 |
15-04-2005, 09:22 | #6 | |
Senior Member
Iscritto dal: Dec 2000
Città: Trento
Messaggi: 5917
|
Quote:
Ciao!
__________________
Linux User #272700 >+++++++++[<+++++++++>-]<+.++.>++++[<---->-]<++.+++++++. HOWTO: SSH Firewall e DMZ ɐɹdosoʇʇos oʇuǝs ıɯ |
|
21-04-2005, 07:52 | #7 |
Senior Member
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
|
Riporto temporaneamente nella sezione principale. Chi è interessato può fare commenti/richieste/suggerimenti.
Quando la guida sarà finita la inserirò tra gli howto.
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12 |
21-04-2005, 08:19 | #9 |
Senior Member
Iscritto dal: Jan 2001
Città: Milano
Messaggi: 5689
|
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. |
21-04-2005, 09:06 | #10 |
Senior Member
Iscritto dal: Oct 2003
Città: La Spezia
Messaggi: 962
|
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
__________________
Gigabyte ga-p55-ud6 | Intel i7 860 | 2x2gb Corsair xms3 | Adaptec 2410sa | raid1 barracuda 500gb 7200.12 | Intel x25-m 80gb G2 | ATI radeon 4890 | tutto in downclock (non ho parenti all'enel) Ultima modifica di _YTS_ : 21-04-2005 alle 09:20. |
01-05-2005, 09:17 | #11 | ||
Senior Member
Iscritto dal: Dec 2000
Città: Trento
Messaggi: 5917
|
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!
Quote:
Quote:
Ovviamente se qualcuno vuole ampliare o darmi una mano ad aggiungere altro, ne sarei piu' che felice! Ciao!
__________________
Linux User #272700 >+++++++++[<+++++++++>-]<+.++.>++++[<---->-]<++.+++++++. HOWTO: SSH Firewall e DMZ ɐɹdosoʇʇos oʇuǝs ıɯ Ultima modifica di HexDEF6 : 01-05-2005 alle 09:20. |
||
26-07-2005, 18:17 | #12 |
Senior Member
Iscritto dal: Dec 2000
Città: Trento
Messaggi: 5917
|
Direi che il tutto puo' considerarsi finito.. ameno che qualcuno non abbia altre modifiche/suggerimenti...
__________________
Linux User #272700 >+++++++++[<+++++++++>-]<+.++.>++++[<---->-]<++.+++++++. HOWTO: SSH Firewall e DMZ ɐɹdosoʇʇos oʇuǝs ıɯ |
26-07-2005, 22:25 | #13 |
Senior Member
Iscritto dal: Apr 2003
Città: Genova
Messaggi: 673
|
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 ... Ultima modifica di LimiT-MaTz : 26-07-2005 alle 22:30. |
26-07-2005, 22:52 | #14 | |||
Senior Member
Iscritto dal: Dec 2000
Città: Trento
Messaggi: 5917
|
Quote:
Quote:
Quote:
__________________
Linux User #272700 >+++++++++[<+++++++++>-]<+.++.>++++[<---->-]<++.+++++++. HOWTO: SSH Firewall e DMZ ɐɹdosoʇʇos oʇuǝs ıɯ |
|||
27-07-2005, 07:31 | #15 | |
Senior Member
Iscritto dal: Apr 2003
Città: Genova
Messaggi: 673
|
Quote:
Dato che dovrei fare un server di posta per una aziendina e ssh mi serve di sicuro per la gestione. Ti ringrazio ciao! |
|
28-07-2005, 15:07 | #16 |
Senior Member
Iscritto dal: Sep 2004
Messaggi: 3963
|
potresti aggiungere qualcosa anche sull'X forwarding?
(considerando magari un client per windows come putty o una shell tipo cygwin) Thx.
__________________
Dai wafer di silicio nasce: LoHacker... il primo biscotto Geek Ultima modifica di RaouL_BennetH : 28-07-2005 alle 16:06. |
28-07-2005, 16:16 | #17 | |
Senior Member
Iscritto dal: Mar 2003
Città: Paris
Messaggi: 912
|
Quote:
Comunque complimenti per l'how-to.
__________________
"Grandi menti discutono di idee, menti mediocri discutono di eventi, piccole menti discutono di persone." |
|
29-07-2005, 01:38 | #18 |
Bannato
Iscritto dal: Feb 2001
Città: Pescara
Messaggi: 10542
|
complimenti vivissimi
Davvero eccellente. |
03-08-2005, 14:07 | #19 | |||
Senior Member
Iscritto dal: Dec 2000
Città: Trento
Messaggi: 5917
|
Quote:
Quote:
Quote:
__________________
Linux User #272700 >+++++++++[<+++++++++>-]<+.++.>++++[<---->-]<++.+++++++. HOWTO: SSH Firewall e DMZ ɐɹdosoʇʇos oʇuǝs ıɯ |
|||
01-10-2005, 23:07 | #20 |
Senior Member
Iscritto dal: Jun 2001
Città: Alessandria (provincia)
Messaggi: 4772
|
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 ! |
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 01:50.