rsystem Maximiliano Marchesi

Transcript

1 Maximiliano Marchesi 28 Settembre 2005 Diario delle Revisioni Revisione Settembre 2005 Sommario Introduzione Effetti negativi Sicurezza Affidabilità Architettura di rsystem Comunicazione con i socket La struttura degli indirizzi Creazione e chiusura della connessione read() write() nel socket Altre funzioni utilizzate TO DO Introduzione Questo progetto ambisce alla realizzazione di una semplice shell remota rsystem. La shell remota rsystem è stata sviluppata a scopo didattico, una delle sue caratteristiche principali è la possibilità di tenere aperta la sessione di connessione tra il client e il server per permettere al client di eseguire piu comandi sul server, un altra sua caratteristica è la concorrenza, la parte server di rsystem permette di accettare diverse connessioni. Grazie a questa caratteristica diversi client possono connettersi simultaneamente aprendo simultaneamente sul server varie shell. Effetti negativi rsystem nasce a scopo didattico e solo in questo ambito dovrebbe rimanere,i motivi principali sono "sicurezza" e "affidabilità". Sicurezza rsystem è composto da client e server, rispettivamente "rsystem" e "rsystemd". "rsystemd" deve essere fatto girare nella macchina server, quella che eseguirà i comandi di un altra macchina remota(client) che a sua volta utilizzerà "rsystem" per richiedere ed eseguire i comandi shell sulla macchina server. E perciò vivamente sconsigliato eseguire come amministratore "rsystemd" su un sistema direttamente connesso ad internet, un telnet sulla porta in cui lavora il server "rsystemd" potrebbe dare privilegi di amministratore a chiunque. permettendo l esecuzione malevola di comandi sul sistema su cui gira il servizio "rsystemd", in pratica potrebbe diventare una pericolosa backdoor. Anche eseguire "rsystemd" come utente limitato potrebbe creare molti problemi di privacy all utente che ha lanciato il server "rsystemd" per i motivi già esposti. Bisogna inoltre considerare che tutti i dati scambiati tra i moduli "rsystemd" e "rsystem", risulatno essere in chiaro non crittografati, per questo motivo tramite appositi programmi di sniffing di pacchetti tcp è possibile conoscere i comandi eseguiti sul server dal cliente oltre al relativo output, eventuali password immesse risulterebbero in chiaro. 1

2 In conclusione "rsystem" è consigliabile per motivi di sicurezza utilizzarlo solo in sistemi di TEST, evitando di connetterli in reti potenzialmente pericolose come internet. Affidabilità Per la sua natura didattica "rsystem" permette di eseguire in modo concorrente sul server comandi lanciati da vari client e permette di utilizzare la stessa sessione, però non sono supportati comandi interattivi. Architettura di rsystem Come abbiamo già detto "rsystem" è suddiviso in due moduli rsystemd - Parte server rsystem - Parte Client "rsystem" utilizza il modello client-server che è l archittettura fondamentale su cui si basa gran parte della programmazione di rete in Unix, in questo modello di programmaizone vi sono due categorie di soggetti i programmi di servizio chiamati "server" che ricevono le richieste e le soddisfano, e i programmi che li utilizzano detti "client". Nel nostro caso "rsystem" fornisce un "server" concorrente in grado di rispondere simultaneamente a diversi client. Comunicazione con i socket In "rsystem" i Socket sono utilizzati come meccanismo di comunicazione tra i due processi remoti, esistono diversi tipi di socket: SOCK_STREAM SOCK_DGRAM SOCK_RAW "rsystem" utilizza i socket del tipo SOCK_STREAM, comunemente definito come socket TCP, le sue caratteristiche principali sono: Canale bidirezionale Sequenziale affidabile Stream i dati vengono trasmessi e ricevuti come un flusso 2

3 La struttura degli indirizzi Esistono diverse famiglie di socket ( Protocol Family PF), in "rsystem" abbiamo utilizzato La famiglia AF_INET, i socket di questa famiglia vengono utilizzati per la comunicazione attraverso internet, ecco un estratto da "rsystem": struct sockaddr_in server; In questo caso abbiamo utilizzato la struttura "sockaddr_in" perchè è la struttura per gli indirizzi per un socket internet. Adesso mostreremo come viene utilizzata in "rsystem": server.sin_family = AF_INET; // Famiglia di indirizzi impostata a dominio internet. server.sin_port= htons(atoi(port)); // Converte il formato dell intero del pc nel formato di rete,converte H to N SHORT da una precedente conversione stringa->numero memcpy( (char *)&server.sin_addr, (char *)hp->h_addr,hp->h_length); // copia l indirizzo nella stringa della struttura indirizzi. In "rsystem" nella struct sockaddr_in vi sono tre parametri il primo è il tipo di famiglia utilizzato in questo caso AF_INET, vi è poi il numero di porta utilizzato, il terzo contiene il valore dell indirizzo internet al quale dobbiamo collegarci tramite il socket. Creazione e chiusura della connessione Ora analizziamo in "rsystemd" e "rsystem" i passaggi che sono effettuati per iniziare la connessione tra client e server. Partiamo da "rsystemd" il modulo server di "rsystem" che implementa il servizio. (1) listen_fd = socket(af_inet,sock_stream,0)) (2) bind(listen_fd,(struct sockaddr *)&server, sizeof(server) ) (2) listen(listen_fd,10) Nella riga(1) troviamo la funzione socket() accetta tre parametri, il primo argomento è il dominio "AF_INET",nel secondo argomento impostiamo il protocollo TCP "affidabile", nel terzo argomento viene messo zero in modo che socket() scelga autonomamente il corretto protocollo da utilizzare. La funzione socket restituisce un intero che rappresenta un file descriptor che utilizzeremo nelle system calls successive, questa funzione si limita a creare le opportune strutture nella file table del kernel creando appunto un file descriptor. Nella riga(2) la funzione bind() associa un indirizzo fisico di una interfaccia di rete con la relativa porta al file descriptor che gli abbiamo fornito, perciò il primo argomento listen_fd è il file descriptor socket che abbiamo ricevuto dalla funzione socket(),il secondo argomento è l indirizzo ip dell interfaccia di rete e il numero di porta su cui vogliamo che il servizio sia funzionante questi due dati devono essere immessi anticipatamente nella struct "sockaddr_in" prima della funzione bind(). Nella riga(3) con la funzione listen() poniamo il socket in attesa di una connessione da un client remoto, le connessioni sono in attesa della funzione accept(), ovviamente il primo parametro sarà il socket e il secondo un intero che rappresenta il limite di connessioni in attesa. Invece nella parte client di "rsystem" troviamo: (1) struct sockaddr_in server; (2) struct hostent *hp; (3) fdsocket = socket(af_inet,sock_stream,0) (4) hp = gethostbyname(servername); 3

4 (5) connect(fdsocket,(struct sockaddr *)&server,sizeof server) Nella riga(1) troviamo la struttura per memorizzare gli indirizzi di un socket tipo internet questa dichiarazione è presente anche in "rsystemd", nella riga(2) dichiariamo la struttura che ci servirà per effettuare la risoluzione dei nomi a dominio, nella riga(3) come per "rsystemd" c è la creazione del file descriptor socket anche per il client "rsystem", è interessante la riga(4) qui infatti troviamo la funzione gethostbyname() che ritorna un indirizzo corrispondente al nome del server che gli abbiamo dato come parametro, infine nella riga(5) troviamo la funzione connect() che è usata dal client "rsystem" per connetersi al server "rsystemd", i parametri in ingresso sono il socket file descriptor del client e l indirizzo con numero di porta del server a cui vogliamo connetterci, è importante dire che utilizzando questa funzione inizia il 3 way handshake tra il client e il server, una volta cloncluso l handshake(stretta di mano) tra client e server il client puo iniziare a lanciare richieste al server. Una volta concluso l handshake, nella parte server di "rsystemd" troviamo: (1) accept_fd = accept(listen_fd,(struct sockaddr *)&client,(socklen_t *) &length)) Nella riga(1) la funzione accept() restituisce un nuovo socket file descriptor che sarà utilizzato per effettuare le comunicazioni tra server e client, i parametri in ingresso sono il socket di ascolto delle connessioni e gli indirizzi fisici delle interfaccie di rete del client. Conclusa questa funzione possiamo chiudere il socket "liste_fd" detto socket di attesa close(listen_fd); Grazie alla funzione close() possiamo chiudere e liberare spazio per i file descriptor, inoltre evitiamo qualsiasi tipo di lettura e scrittura nel canale del socket. read() write() nel socket Ora che abbiamo creato un canale tra il client e il server, ci servono delle funzioni per poter scrivere e leggere, "in" e "da" questo canale. La funzione write() (1) size_t write(int fd,void * buf,size_t count) Questa system call ci permette di scrivere nel socket file descriptor "fd" "count" byte del buffer "buf", e restituisce il numero byte effetivamente scritti. La funzione read() (1) size_t read(int fd,void * buf,size_t count) Questa system call ci permette di leggere dal socket file descriptor "fd" "count" byte del buffer "buf", e restituisce il numero byte effetivamente letti. Sia read() che write() ritornano un valore negativo nel caso ci siano stati problemi di lettura o scrittura. Altre funzioni utilizzate Ecco altre funzioni utilizzate nel protocollo di rsystem. 4

5 La funzione fork() (1) pid_t fork(void) Questa funzione crea un nuovo processo figlio, è importante perchè è il meccanismo che ci consente di rendere "rsystemd" concorrente e soddisfare diversi client contemporaneamente. In caso di successo restituisce il pid del figlio al padre e zero al figlio; ritorna -1 al padre (senza creare il figlio) in caso di errore La funzione dup2() (1) int dup2(int oldfd, int newfd) Rende newfd una copia del file descriptor oldfd. La funzione ritorna il nuovo file descriptor in caso di successo e -1 in caso di errore. Questa funzione è utilizzata nel protocollo di "rsystemd" per incanalare lo STD_OUT e lo STD_ERR del server nel socket in modo che possa essere trasmesso al client "rsystem". Ecco un piccolo esempio di utilizzo: (1) dup2(accept_fd,1); //redirect stdout to socket (2) dup2(accept_fd,2); //redirect stderr to socket Come abbiamo detto redirezionamo STD_OUT e STD_ERR nel socket accept_fd. La funzione system() (1) int system(const char * cmdstring) In "rsystem" il client lancia un comando che vuole eseguire nella shell remota, tramite il socket arriva al Server che prende la stringa e la esegue con la system call system(), ovviamente lo STD_OUT e lo STD_ERR viene reimmesso nel socket per essere visualizzato nell STD_OUT del client. La funzione ioctl() (1) int ioctl(int fd, int request,...) Manipola il dispositivo sottostante, usando il parametro request per specificare loperazione richiesta ed il terzo parametro (usualmente di tipo char * argp o int argp) per il trasferimento dellinformazione necessaria. In rsystem abbiamo utilizzato questa funzione per controllare se nel socket file descriptor vi erano byte da leggere, se dopo un certo tempo non vi erano piu byte nel socket, si evitava di andare ad eseguire una read() bloccante sul socket. TO DO... Nello script "rsystem.sh" si deve aggiungere la possibilità di selezionare numeri di porta diversi. C è uno spreco di risorse nel ciclo in cui si controlla con la funzione ioctl il socket per vedere se vi sono byte da leggere. Per rendere piu sicuro l utilizzo di rsystemd si ha la necessità di utilizzare un sistema di autentificazione e autorizzazione ad esempio con ldap, eventualmente verificare se sia possibile criptare i dati in modo da evitare che possano essere intercettati nella rete durante il lancio dei comandi. 5