Archivio

Archivio per 1 Maggio 2009

Connettersi da Windows a Ubuntu via Remote desktop NX

1 Maggio 2009

Per poter gestire un pc remoto gestito da una distribuzione linux Ubuntu da un pc comune con sistema operativo Windows possiamo agire in tanti modi, io ne elencherò solo alcuni tanto per fare una breve panoramica.

Il primo modo consiste nell’usare una semplice console testuale, come ad esempio Putty e per a gestione dei file magari WinSCP, questo è il metodo più diffuso dato che su un server solitamente non abbiamo necessità di un ambiente graffico, che al contrario appesantirebbe le sue funzioni.

Ma se invece volessimo accedervi graficamente dato che magari vi abbiamo installato un ambiente grafico a finistre come può essere KDE o Gnome, beh allora possimo procedere in due modi a seconda delle nostre esigenze:

  • Con un Vnc client se vi abbiamo installato e avviato un  Vnc server
  • Con un l’esportazione grafica del Xserver in uso (XMCP)

Vediamo di chiarire un po le cose. Usando vnc si ha il vantaggio che client vnc per windows ce ne sono tanti e facilmente configurabili, come ad esempio Realvnc. Per abilitarlo su Ubuntu 8.01 basta abilitare quello che viene chiamato “remote desktop”.

Come preferenze potremo impostare una password d’accesso o una approvazione per il client che si sta connettendo. Nel mio caso non ho impostato nessuna password e neessuna approvazione, ma solo una notifica.

Questa faccenda dell’approvazione ci permette di capire un grosso vincolo che si ha nell’usare vnc come desktop remoto, infatti quando ci si connette con vnc il sistema deve essere gia in uso da un utente! Quest’utente è quello che nel caso dovrà darci la “approvazione” all’esportazione del desktop.

Di fatto vnc non è altro che un modo per condividere un ambiente grafico duplicandone l’output e gli input. Questo ha come conseguenza che se nessuno sta usando il pc server o meglio non ci si è ancora loggato allora non potremo connetterci!
Oltre a questa cosa che mi sembra abbastanza vincolante, quando ci saremo connessi al server remoto non potremo di certo lavorare contemporaneamente con l’utente che ci si era loggato in precedenza…perchè, per esempio, il mouse o lo usiamo noi o lo usa lui, idem per il monitor etc.

Quindi questa soluzione molto semplice è però molto limitativa.

Un metodo migliore sarebbe quello di poter accedere al mio server eseguendo il login allo stesso modo di un utente che volesse usarlo in locale. In questo modo molti utenti potrebbero usare il server contemporaneamente e senza nessun vincolo. Ma come si fa?
Beh la soluzione sarebbe esportare il Xserver verso un pc remoto. Per fare questo sul mio server Ubuntu devo abilitarlo dalla finestra per le preferenze di login:

Una opzione che potete abilitare o meno, dipende dalle vostre esigenze, è la possibilità accedere al server usando più volte lo stesso account o meno. Forse per fare qualche esperimento iniziale potete anche permettere questa possibilità 😉

Dopo di che potete passare direttamente alla scheda “remoto” e impostare il tipo di schermata d’accesso. Nell’esempio mostrato ho impostato il login da remoto come quello che si ha in locale. Nel nostro caso è l’ambiente grafico gnome.

Potreste vole impostare altre opzioni, ma per i nostri fini questo è pù che sufficiente! Esatto non dobbiamo fare altro.

Per verificarlo dato che stiamo lavorando sul server remoto possiamo installare Xnest usare il comando

sudo apt-get install xnest

dopo di che col comando

gdmflexiserver --xnest

visualizzerete una finestra dalla quale potrete loggarvi allo stesso server remoto. In questo modo potete simulare cosa accadrebbe da remoto.

Ci sarebbe da approfondire un po su questo argomento soprattutto sul come gdm ovvero l’ambiente grafico gnome non digerisca bene Xnest che invece da KDE risulta molto piu semplice infatti basta lanciare il comando:

Xnest -query localhost 1:

senza dover ricorrere ad altro… cqm questo è un altro discorso.

A questo punto se come client  avessi un pc con linux tutto sarebbe molto facile dato che basterebbe al momento del login sul pc oppure usando Xnest indicando l’indirizzo del pc remoto nell’opzione query, potrei accedere al server remoto come se fossi li davanti.

Tutto molto bello, ma io ho windows…. 🙁

Dovremo quindi cercare un X-client che giri sotto windows e che mi permetta di accedere al mio server remoto.
Ora tra incompatibilità varie, installazioni su windows improbabili devo dire che non è la cosa più facile de mondo.

La soluzione che invece vi voglio proporre si chiama NXclient ed NXserver, che sono rispettivamente il software da usare nel pc locale e quello da installare nel server remoto. Questi li potrete scaricare dal sito  e la potrete trovare nel sito http://www.nomachine.com.

Quindi scaricare ed installare l’ NXclient.exe sul pc locale con windows.

Al momento dell’avvio del client dovremo dare un nome alla connessione e poi configurarlo:

Come host bisogna mettere l’ip del server remoto e selezionare che tipo di desktop, nel mio caso GNOME.

Ora pensiamo al pc remoto

Se non lo avete gia fatto in precedenza, installare il server ssh nel pc remoto

sudo apt-get install openssh-server

dopo scaricare ed installare la suit NX sul server remoto (client, node, server), nel mio esempio ho messo i nomi della versione 3.3, ma vi consiglio sempre di scaricare la versione piu aggiornata, e poi ho scelto la versione x64 perche nel mio server mi serviva quella versione, voi potrete scarica quella di cui necessitate.

wget http://64.34.161.181/download/3.3.0/Linux/nxclient_3.3.0-3_x86_64.deb
wget http://64.34.161.181/download/3.3.0/Linux/nxnode_3.3.0-3_x86_64.deb
wget http://64.34.161.181/download/3.3.0/Linux/FE/nxserver_3.3.0-8_x86_64.deb

se mai vi servisse scaricare questa versione potete trovarli anche qui:

linux_server_x64_3.3.deb linux_server_x32_3.3.deb
linux_node_x64_3.3.deb linux_node_x32_3.3.deb
linux_client_x64_3.3.deb linux_client_x32_3.3.deb

dopo di che procedere con l’installazione, naturalmente usando il file della versione scaricata:

sudo dpkg -i nxclient_3.3.0-3_x86_64.deb
sudo dpkg -i nxnode_3.3.0-3_x86_64.deb
sudo dpkg -i nxserver_3.3.0-8_x86_64.deb

a questo punto il server è pronto, infatti non sono necessarie particolari configurazioni per farlo funzionare, ma se ne aveste bisogno leggete la Guida per amministrazione server NX o direttamente dal sito.

Provate a collegarvi dal client inserendo il nome utente e password che usereste per connettervi in locale al server remoto e il gioco è fatto! 🙂

Vediamo alcune comandi per il server NX che potrebbero tornarci utili.
Per disabilitare le nuove connessioni lasciando attive quelle gia in atto usare il comando:

sudo /usr/NX/bin/nxserver --stop

in questo modo non si impedisce il login al sistema (telnet,ssh..etc) ma solo il login tramite NX.
Per mandare un messaggio a tutti gli utenti connessi al server

sudo /usr/NX/bin/nxserver --broadcast "Il testo del messaggio qui"

Per troncare tutte le connessioni esistenti e spegnere il server NX:

sudo /usr/NX/bin/nxserver --shutdown

Se voleste ripulire il server dai software appena installati usate il comando

sudo dpkg -r nxserver
sudo dpkg -r nxclient
sudo dpkg -r nxnode
Share

Tips Linux e Microsoft

Guida alla configurazione sicura di un router Cisco

1 Maggio 2009

Configurazione di base

Il primo passo per la prevenzione è abilitare il sistema di log per tenere traccia di tutti gli eventi “interessanti”. (È inutile dire che il server sul quale viene registrato il file di log deve essere adeguatamente protetto; è consigliabile inoltre adottare meccanismi automatici di allarme, ad es. swatch).

service timestamps log datetime
logging trap debugging
logging facility
logging
Per eliminare la possibilita` che un router utente sia utilizzato come “ponte” per connessioni illecite,  è consigliabile disabilitare la possibilita` di fare telnet dal router,  pur lasciando un account non privilegiato per diagnostica: la connessione inoltre dovra` essere possibile solo da alcuni host prestabiliti (ad es.: dalla rete interna e dal router del PoP).


! account di servizio (non puo’ fare telnet)
!
username access-class 1 nopassword
access-list 1 deny any log
….
access-list 2 permit 0.0.0.0
access-list 2 permit 0.0.0.255
!
line vty 0 4
….
access-class 2 in
login local

I file di configurazione dei router vengono tipicamente salvati su un tftp server e sono quindi accessibili, in linea di principio, a tutti: è consigliabile permettere l’accesso al tftp server ai soli nodi interessati (ad es. mediante un sistema di tcp-wrapper sul server).

La criptazione della password di accesso al router non è sufficiente: è infatti diffuso un “tool” che permette di decriptare la password di enable dei router CISCO, a partire dal file di configurazione (si veda il punto precedente), in quanto l’algoritmo di criptazione è reversibile. E` fortemente consigliato quindi sostituire la password di enable con il “secret” che usa un algoritmo di criptazione non reversibile.

! abilita la criptazione delle password
!
service password-encryption
!
! inserimento password di tipo secret
!
enable secret SECRET1

Attacchi di tipo Denial of Service (DoS)

Gli attacchi di tipo DoS hanno come scopo di rendere inutilizzabile un servizio o una risorsa, eventualmente per sostituirsi ad essa e trarne un illecito vantaggio.

La tipologia di questi attacchi spazia dall’impedire la connessione ad un server (o a un router) al mandare in crash lo stesso.

Vediamo i casi più diffusi.

smurfing

Un grave disservizio verificatosi recentemente in alcuni siti GARR è stato causato dall’invio dall’esterno di pacchetti ICMP all’indirizzo di broadcast di una delle reti del sito (“broadcast storm”): lo “smurfing“.

Tale tipo di attacco coinvolge solitamente tre siti: il sito di origine dell’attacco (sito O) e altri due siti “vittime”, uno intermedio che “amplifica” l’attacco (sito I) ed uno terminale (sito T).

Solitamente dal sito O vengono effettuati ping sull’indirizzo di broadcast di una (o più reti) del sito I, con il campo source ip address dell’header falsificato e posto uguale a quello di un host del sito T (per maggiori dettagli: CERT CA-98.01, RFC 2267). In questo modo viene generato un flusso consistente di pacchetti ICMP dal sito I al sito T (per una stima del disservizio, si veda: “THE LATEST IN DENIAL OF SERVICE ATTACKS: “SMURFING” DESCRIPTION AND INFORMATION TO MINIMIZE EFFECTS“)

Purtroppo non c’è modo per il sito T di difendersi direttamente, se non tramite una politica preventiva estesa a quanti più siti possibile tesa ad eliminare le cause (cioè ad impedire comportamenti “scorretti” dei propri utenti).

E` quindi importante impedire che la propria LAN sia origine dell’attacco o amplificatore ignaro (ed allo stesso tempo vittima) dello stesso.

Per evitare che la propria LAN agisca da sito intermedio, è necessario disabilitare la possibilità di inviare pacchetti dall’esterno sull’indirizzo di broadcast delle proprie reti nel seguente modo:

! impedisce di inviare pacchetti broadcast dall’esterno
!
interface ethernet 0
…..
no ip directed-broadcast

Questa operazione deve essere ripetuta su ogni router connesso alla propria LAN.

Inoltre, per evitare che la propria LAN sia origine dell’attacco o quanto meno per permettere di individuare l’origine dell’attacco, è necessario controllare che i pacchetti che escono dalla LAN abbiano nell’header come source address un indirizzo appartenente ad essa. In questo modo è almeno possibile evitare di coinvolgere siti “terzi” e risalire all’origine dell’attacco disponendo di un sistema di monitoraggio sulla LAN (si veda ad es: “Building a Network Monitoring and Analysis Capability Step by Step”)

L’access-list seguente effettua il controllo richiesto (si ricordi che le access-list estese sono identificate da un numero compreso nell’intervallo 100-199 e che l’IOS CISCO effettua il controllo sequenzialmente dalla prima istruzione, fermandosi al primo match di condizione esatto che trova).

! impedisce ai pacchetti con source address falsificato di uscire dalla LAN
!
interface serial 0
……
ip access-group 101 out
…..
!
! definizione access-list (nell’esempio RETE è una rete di “classe C”)
!
access-list 101 permit ip <RETE> 0.0.0.255 any any
access-list 101 deny ip any any log

L’uso di una access-list per filtrare i pacchetti in uscita dalla propria LAN (è sufficiente l’access-list applicata come misura preventiva per lo smurfing) permette di circoscrivere eventuali attacchi verso terzi provenienti dalla propria LAN.


Attacchi UDP-TCP sulle porte di diagnostica del router

Un altro possibile attacco, di tipo DoS, cui sono soggetti router CISCO è l’invio di un grande numero di pacchetti spuri UDP o TCP sulle porte echo, chargen, discard e daytime (quest’ultimo solo TCP). In questi casi il router, per rispondere a queste richieste, può arrivare a consumare una grande percentuale della propria CPU fino, in casi estremi, ad andare in crash (per maggiori dettagli: “White Paper: Strategies to Protect Against UDP Diagnostic Port Denial of Service Attacks“).

È consigliabile disabilitare tale accesso, con le seguenti istruzioni in configurazione:

no service udp-small-servers
no service tcp-small-servers

Attacco “land”

Come è noto, è diffuso un “tool” (noto come land)  che permette l’invio ad un determinato host di pacchetti TCP SYN (inizio di connessione), con “ip source address” e “port” falsificati e posti uguali all’indirizzo ed alla porta dell’host di destinazione, causando in alcuni casi anche lo stallo del router.

Il problema è stato risolto nelle più recenti versioni di IOS Cisco, ma negli altri casi è necessario applicare un filtro che blocchi per ogni interfaccia la ricezione di questi pacchetti (per maggiori dettagli: “TCP Loopback DoS Attack (land.c) and Cisco Devices“).

! impedisce l’invio alle interfacce di pacchetti
! con ip source address uguale a quello dell’interfaccia
!
interface ethernet 0
…..
ip address
ip access-group 102 in
…..
!
! il filtro è inutile se l’interfaccia è unnumbered o
! comunque se ha un indirizzo non annunciato
!
interface serial 0
……
ip address
ip access-group 102 in
…..
!
access-list 102 deny ip 0.0.0.0 0.0.0.0
access-list 102 deny ip 0.0.0.0 0.0.0.0
access-list 102 permit ip any any

Attacchi “TCP SYN”

Un altro possibile attacco di tipo DoS  è l’attacco “TCP SYN” caratterizzato dalla richiesta di un grande numero di connessioni, apparentemente da host diversi, ad un router il quale però non riceverà mai l’acknowledgment di chiusura del “TCP three-way handshake”  per queste connessioni, causando quindi il riempimento della sua coda di connessione e quindi realizzando una situazione di Denial of Service (per maggiori dettagli si veda: “White Paper: Defending Strategies to Protect Against TCP SYN Port Denial of Service Attacks“).

Non è possibile rintracciare l’origine dell’attacco in quanto il mittente viene falsificato, né esistono metodi semplici di difesa (non è fattibile ad esempio l’attivazione di una access-list che filtri le connessioni in ingresso, perchè tipicamente l’ip sorgente è falsificato in maniera casuale e quindi un attacco può coprire buona parte dello space-address di Internet).

Sono attuabili alcune contromisure come aumentare la dimensione della coda di connessione (SYN ACK queue) e diminuire il tempo di time-out per il “three-way handshake“.

Anche in questo caso la realizzazione dell’acces-list per filtrare i pacchetti in uscita diminuisce la probabilità che la LAN sia utilizzata come base per questo tipo di attacchi (è sufficiente l’access-list applicata come misura preventiva per lo smurfing).

Uso non autorizzato delle risorse

Protezione degli host sulla LAN

In situazioni normali è difficilmente attuabile il controllo centralizzato di tutti gli host sulla propria LAN. La misura alternativa è filtrare selettivamente sul router i servizi tendenzialmente pericolosi.

In linea di principio, la situazione ottimale è isolare su una LAN dedicata i server “esterni” ovvero quelli che devono essere visibili a tutti, permettendo l’accesso verso di essi però solo limitatamente ai servizi “ufficiali” offerti; per quanto riguarda invece le macchine utente, dovrebbe essere bloccato tutto il traffico diretto verso le porte “pericolose” (dalle quali comunque di norma non dovrebbero essere offerti servizi).

Nella seguente tabella sono riportati i servizi da filtrare o bloccare.

Servizio Porta Protocollo Azione Note
echo 7 TCP/UDP Bloccare DoS
systat 11 TCP/UDP Bloccare informativo
daytime 13 TCP/UDP Bloccare
netstat 15 TCP Bloccare informativo
quotd 17 TCP/UDP Bloccare
chargen 19 TCP/UDP Bloccare DoS
smtp 25 TCP Filtrare
time 37 TCP/UDP Bloccare inutile
tacacs 49 TCP/UDP Bloccare
domain 53 TCP Filtrare Usato principalmente per zone transfer
bootp 67-68 UDP Bloccare
tftp 69 UDP Bloccare
gopher 70 TCP Bloccare obsoleto
finger 79 TCP Bloccare informativo
http 80 TCP Filtrare
link 87 TCP Bloccare
supdup 95 TCP Bloccare
pop2 109 TCP Bloccare obsoleto
pop3 110 TCP Filtrare
sunrpc 111 TCP/UDP Filtrare
nntp 119 TCP Filtrare
nbios-ns 137 TCP/UDP Filtrare
nbios-dgm 138 TCP/UDP Filtrare
nbios-ssn 139 TCP/UDP Filtrare
imap 143 TCP Filtrare
NeWS 144 TCP Bloccare
snmp 161 UDP Filtrare
snmptrap 162 UDP Bloccare
xdmcp 177 UDP Filtrare
irc 194 TCP/UDP Bloccare
exec 512 TCP Bloccare
biff 512 UDP Bloccare
login 513 TCP Bloccare
who 513 UDP Bloccare informativo
shell 514 TCP Bloccare
syslog 514 UDP Bloccare
printer 515 TCP Bloccare
route 520 UDP Bloccare
uucp 540-541 TCP Bloccare
mountd 635 TCP/UDP Filtrare
openwin 2000 TCP Bloccare
NFS 2049 TCP/UDP Filtrare
X11 6000-6063 TCP Filtrare


Mail Spamming

Come esempio significativo di uso illecito delle risorse (soprattutto della rete) esaminiamo il “mail spamming”, ovvero l’uso di mailer SMTP da parte di utenti non autorizzati per ottenere l’invio di decine di migliaia di messaggi di e-mail, di solito contenenti messaggi pubblicitari non richiesti dai destinatari (detti UCE: Unsolicited Commercial E-mails).

Per prevenire questo fenomeno, in linea di principio, è sufficiente configurare correttamente gli host di una LAN eliminando (selettivamente) la possibilità di utilizzarli come mail relay dall’esterno (per maggiori dettagli: sendmail organization )

In realtà però, come abbiamo notato precedentemente, è necessario filtrare il servizio smtp dall’esterno verso tutti gli host ritenuti non “affidabili” (cioè non controllati direttamente dai reponsabili del sito), lasciando pieno accesso smtp solo verso i mail server “ufficiali”.

Viene riportato di seguito un esempio di access-list che realizza questo filtro.

! impedisce le connessioni smtp dall’esterno verso host non autorizzati
! (nell’esempio si suppone che la connessione verso l’esterno avvenga
! tramite l’interfaccia serial 0)
!
interface serial 0
……
ip access-group 103 in
…..
!
! definizione access-list (nell’esempio RETE è una rete di “classe C”)
!
access-list 103 permit tcp any host
access-list 103 permit tcp any host
access-list 103 deny   tcp any <RETE> 0.0.0.255 eq smtp log
access-list 103 permit ip any any

Si noti che una simile configurazione non impedisce alle macchine interne di parlare SMTP tra di loro nè di trasmettere direttamente posta elettronica a tutto il mondo esterno: impedisce solamente al mondo esterno di accedere direttamente alla porta SMTP delle macchine non autorizzate (per maggiori dettagli si veda, ad es.: “Installazione e configurazione di Berkeley sendmail su piattaforma Unix“).

Un problema che rimane comunque aperto è lo spamming con il metodo del “doppio non delivery”. In questo caso lo “spammer”, per aggirare le protezioni sul mail-relay, invia il mail ad un utente inesistente in un dato dominio con il campo From falsificato e posto uguale al “bersaglio”: il sistema di mail del dominio ricevente accetta l’e-mail (è diretto ad utente del proprio dominio) ma poi constata che l’utente è inesistente e quindi lo rispedisce al mittente (a quello che crede essere il mittente…).

Purtoppo non c’è modo di difendersi se non segnalando il fatto ai gestori dell’ISP dal quale avvengono queste connessioni ed eventualmente  filtrare la connessione smtp dalle reti in questione (eliminando quindi anche i mail “legittimi”); d’altra parte questo tipo di “mail-spamming” è assolutamente inefficiente dal punto di vista dello spammer (deve mandare un mail per ogni “vittima”).

Share

Cisco