Inetd e i servizi di rete: differenze tra le versioni

Vai alla navigazione Vai alla ricerca

Inetd e i servizi di rete (visualizza wikitesto)

Versione delle 17:20, 9 gen 2008

3 byte aggiunti ,  9 gen 2008
→‎Comandi utili
Riga 1: Riga 1:
La soluzione pi� diffusa e stabile, per la messa on-line di un applicativo scritto in ruby on rails, � data dall'accoppiata Mongrel e Apache2!
==Il superdemone inetd==


= Introduzione =
===Introduzione===
La struttura del nostro ambiente di produzione � descritta nella seguente figura:
Inetd ('''Internet Super-Server''') è un [[demone]] che ascolta sulle porte specificate nel suo file di configurazione e fa avviare il relativo servizio nel momento in cui viene fatta una richiesta. Esso controlla tramite dei [[wrapper]] i file '''/etc/hosts.allow''' e '''/etc/hosts.deny''' per verificare che la connessione sia consentita.


TODO!!!
Viene chiamato superdemone proprio per questa sua funzione di controllo di altri demoni.


Il vantaggio di usarlo è di ottimizzare le risorse del sistema, avviando il demone che gestisce un determinato servizio solo quando ci sono effettive richieste.


Tutte le richieste arriveranno al server web apache, che si occuper� di dirottare le richieste dinamiche a uno dei server mongrel, mentre servir� i contenuti di tipo statico direttamente, senza cos� appesantire le istanze di mongrel con richieste che possono essere processate direttamente da apache.
Sebbene possa essere usato per gestire quasi tutti i servizi è consigliabile farlo solo per quelli a basso e occasionale traffico.


Questa struttura, inoltre, permette espansioni future per garantire una buona scalabilit� in caso di un forte aumento delle richieste: potremo, in futuro, spostare le verie istanze di mongrel su server differenti, distribuire il filesystem in modo da avere "pi� apache" pronti ad accettare le richieste, ...
===Installazione===
Se per qualche motivo il demone inetd non dovesse essere installato è sufficiente installarlo tramite APT. Inoltre consiglio l'installazione dei TCP wrappers:
<pre>$: apt-get install openbsd-inetd tcpd</pre>


===Configurazine===
Per prima cosa è necessario modificare i permessi al file '''/etc/inetd.conf''' in modo che solo root abbia accesso:
<pre>$: chmod 600 /etc/inetd.conf</pre>


= Installazione =
Ogni riga di '''/etc/inetd.conf''' corrisponde ad un servizio che viene gestito da inetd. Se è commentata con un # il servizio non viene avviato e inetd non mette la relativa porta in listening. Esempio:
== Apache2 ==
Per installare Apache � sufficiente un  
<pre>
# apt-get install apache2-mpm-prefork libapache2-mod-proxy-html
</pre>


Consiglio la versione "prefork" in quanto � supportata pienamente anche da php5, e di conseguenza non ci saranno problemi ad installare anche applicazioni come phpmyadmin, molto comoda per la gestione di database mysql. L'installazione base di apache, per�, non � sufficiente per i nostri fini, infatti dobbiamo abilitare alcuni moduli:
<pre># These are standard services. 
* deflate
#
* proxy_balancer
#ftp    stream  tcp  nowait  root  /usr/sbin/tcpd  in.ftpd -l -a 
* proxy_connect
#telnet stream  tcp  nowait  root  /usr/sbin/tcpd  in.telnetd
* proxy_html
#
* proxy_http
# Shell, login, exec, comsat and talk are BSD protocols. 
* proxy
# 
* rewrite
#shell  stream  tcp    nowait  root    /usr/sbin/tcpd  in.rshd 
#login  stream  tcp    nowait  root    /usr/sbin/tcpd  in.rlogind 
#exec  stream  tcp    nowait  root    /usr/sbin/tcpd  in.rexecd 
#comsat dgram  udp    wait    root    /usr/sbin/tcpd  in.comsat 
#talk  dgram  udp    wait    root    /usr/sbin/tcpd  in.talkd 
#ntalk  dgram  udp    wait    root    /usr/sbin/tcpd  in.ntalkd 
#dtalk  stream  tcp    waut    nobody  /usr/sbin/tcpd  in.dtalkd</pre>


per abilitarli:
Il formato tipico di ogni riga è il seguente:
<pre>
# a2enmod deflate
# a2enmod proxy_balancer
# a2enmod proxy_connect
# a2enmod proxy_html
# a2enmod proxy_http
# a2enmod proxy
# a2enmod rewrite
</pre>


La configurazione di default del modulo proxy permette connessioni solo dall'indirizzo ip 127.0.0.1. Questa situazione rende impossibile, per�, l'accesso al VirtualHost che andremo a configurare dall'esterno. A tal proposito dobbiamo modificare il file di configurazione del modulo (''nome del file di configurazione'') modificando la seguente riga:
<pre>service type protocol wait user server cmdline</pre>


TODO


Una volta abilitati i moduli e fatte le modifiche necessarie, riavviamo apache:
Un esempio pratico di una riga presente in '''/etc/inetd.conf''':
<pre>
<pre>ftp stream tcp nowait root /usr/sbin/in.ftpd –l
# /etc/init.d/apache2 restart
</pre>


L'installazione e la configurazione base di apache sono terminate.
ftp: nome del servizio
stream: indica il tipo
tcp: indica il protocollo
nowait: indica se deve attendere
user: indica l’utente che ha il privilegio di accesso
server: indica dove si trova il programma
cmdline:indica il nome dell’eseguibile e eventuali flag</pre>


== Ruby ==
Inoltre inetd si appoggia su un altro file di configurazione dei servizi:
Se non � gi� presente sulla macchina, provvediamo ad installare ruby ed i componenti pi� importanti, necessari alla compilazione di mongrel:


<pre>
<pre>/etc/services
# apt-get install ruby irb ri rdoc ruby1.8-dev build-essential
File che assegna un nome di servizio alla relativa porta.
</pre>
Viene usato anche da altri programmi come file di riferimento.</pre>


Se si vogliono utilizzare i tcpwrapper per limitare l'accesso al servizio la riga sopra diventa:
<pre>ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd –l</pre>


== Rails ==
Nelle distribuzioni Linux, solitamente inetd è già configurato per supportare i tcp wrappers.
Prima di tutto scarichiamo rubygems dal sito ufficiale: http://www.rubygems.org/


In questo momento l'ultima versione � la [http://rubyforge.org/frs/download.php/28174/rubygems-0.9.5.tgz 0.9.5]:
===TCP wrappers===
<pre>
I tcp wrapper '''TCPD''', sviluppati dall'olandese Wietse Venema, sono un layer software che permette il controllo e il filtro degli accessi a servizi del sistema, tipicamente gestiti con inetd.
# wget http://rubyforge.org/frs/download.php/28174/rubygems-0.9.5.tgz
# tar xzvf rubygems-0.9.5.tgz
# cd rubygems-0.9.5
# ruby setup.rb
</pre>


Ora possiamo installare rails, facendo attenzione alla versione richiesta dal nostro applicativo:
In pratica da una configurazione:
* Ultima versione
<pre>
# gem install rails
</pre>
* Una versione specifica
<pre>
# gem install rails -v 1.2.5
</pre>


<pre>client -----> inetd -----> servizio</pre>


== Mongrel ==
Si passa ad una configurazione:
Mongrel si installa allo stesso modo di rails, inoltre installeremo anche mongrel-cluster, che ci semplificher� moltissimo la vita:
<pre>
# gem install mongrel
# gem install mongrel_cluster
</pre>


= Configurazione =
<pre>client -----> inetd -----> TCPD -----> servizio</pre>
== Mongrel ==
La configurazione del cluster di server mongrel � semplice, e si riduce a creare un semplice file di configurazione. Questo � quello base, da cui partire:
<pre>
---  
cwd: /opt/applicativo/
log_file: log/mongrel.log
port: "3000"
environment: production
address: 127.0.0.1
pid_file: tmp/pids/mongrel.pid
servers: 3
</pre>


Nei dettagli tutte le voci:
Nella nuova configurazione i tcpwrappers possono limitare l'accesso al servizio secondo criteri configurabili ed hanno funzionalità anti-spoofing e anti tcp seguence guessing. La configurazione dei tcp wrappers si fa essenzialmente in due file.
; cwd : ''current work directory'', cio� la directory in cui � presente l'applicativo. � consigliato usare SEMPRE un percorso assoluto.
; log_file : dove conservare i log di mongrel. Il valore di default va pi� che bene
; port : la porta iniziale per l'array di server mongrel
; environment : l'envirorment di rails da utilizzare... normalmente si usa production (essendo un server di produzione), ma in casi particolari si pu� inserire un nuovo ambiente.
; address : l'indirizzo IP su cui mettersi in ascolto. Le scelte pi� comuni sono:
:; 127.0.0.1 : il cluster sar� raggiungibile solo da applicazioni residenti sul server su cui � in esecuzione mongrel, impostazione consigliata a meno di configurazioni pi� complesse
:; 0.0.0.0 : il cluster sar� raggiungibile da qualsiasi indirizzo esterno, scelta sconsigliata a meno che non ci si trovi in un ambiente protetto
; pid_file : dove inserire i [[pid]] dei vari processi mongrel
; servers : il numero di server mongrel da lanciare.  


Questo file permette di specificare quali servizi abilitare e da quali indirizzi IP:
<pre>/etc/hosts.allow</pre>


== Apache ==
Questo file permette di specificare come limitare l'accesso a specifici servizi:
Questo � un classico file di configurazione di apache per un VirtualHost, che sfrutta 3 server mongrel.
<pre>/etc/hosts.deny</pre>


<pre>
===Comandi utili===
da inserire
Per avviare, riavviare, fermare il servizio inetd:
</pre>
<pre>$: /etc/init.d/openbsd-inetd start/stop/restart</pre>
le spiegazioni sono nei commenti del file di configuarzione. Consiglio di non cancellarli quando si utilizza questo template, in quanto possono sempre tornare utili nel futuro ;)


= Avvio, Arresto e Riavvio di un cluster Mongrel =
===Configurazioni utili===
In questa parte del tutorial vedremo come lanciare, fermare e riavviare una batteria di server mongrel:
Nega l'accesso a tutti i client e controlla che ip - nome.host corrispondano:
== Avvio ==
<pre>File da applicare: /etc/hosts.deny
== Arresto ==
ALL:ALL@ALL,PARANOID</pre>
== Riavvio ==


Consente l'accesso a tutti i client e controlla che ip - nome.host corrispondano:
<pre>File da applicare: /etc/hosts.allow
ALL: LOCAL 192.168.1.0/255.255.255.0</pre>


= Conclusione =
Permette l'accesso SSH all'host prova.it corrispondente all'IP 10.0.0.1
Giunti a questo punto abbiamo configurato alla perfezione sia apache che mongrel... se tutto funziona a dovere il nostro applicativo dovrebbe essere visibile dall'esterno ;)
<pre>File da applicare: /etc/hosts.allow
sshd: 10.0.0.1 prova.it</pre>
 
Manda una mail all'indirizzo specificato admin_mail ogni qualvolta qualcuno si connette attraverso il servizio telnet, indicando l'indirizzo del client (%a) e l'utente (%u), la lista di questi parametri è contenuta nella man page hosts_access.
<pre>File da applicare: /etc/hosts.allow
in.telnetd : ALL@ALL : spawn ( /bin/mail -s "Connessione telnet da: %a %u" admin_mail ) & </pre>
 
==Da inetd a Xinetd==
===Differenze===
A differenza del precedessore, xinetd (e'''x'''tended inetd):
 
:*Limita o regola l'accesso a determinati servizi senza ricorrere al Tcp Wrapper;
:*Offre un sistema di logging indipendente da syslog;
:*Permette di limitare l'accesso ai servizi in determinate ore della giornata;
:*Supporta il protocollo Ipv6;
:*Utilizza vari meccanismi che mitigano l'impatto di un attacco DOS.
 
===File di configurazione===
La configurazione del demone e dei servizi può essere suddivisa in più file non compatibili con i vecchi file di configurazione del demone inetd. Le directory contenenti i file di configurazione sono leggermente cambiate:
<pre>/etc/xinetd.conf
File di configurazione del demone
 
/etc/xinetd.d/*
Directory che contiene i singoli file dei servizi offerti da xinetd</pre>
 
Il file di configurazione di xinetd è un file di testo che indica i servizi gestiti da xinetd. Contiene delle sezioni, ognuna delle quali identifica un servizio, con la seguente sintassi:
<pre>service service_name
{
    attribute assign_op [value] [value] [...]
    [...]
}</pre>
 
Dove i seguenti attributi indicano:
:* '''service_name'''  è l’indicazione di un servizio gestito da xinetd;
:* '''attribute'''  indica un attributo relativo al servizio service_name;
:* '''assign_op'''  è un operatore di assegnamento, e può essere = (specifica l’unico valore dell’attributo), += (aggiunge un valore all’attributo) o -= (rimuove un valore dall’attributo).
 
===Esempi di configurazione di Xinetd===
Di seguito sono riportati alcuni esempi pratici e semplici di un file di configurazione '''/etc/xinetd.conf''':
<pre>service shell
          {
                socket_type        = stream
                wait                = no
                user                = root
                instances          = UNLIMITED
                server              = /usr/etc/in.rshd
                log_on_success      += HOST RECORD
          }
 
service ftp                                                             
          {
                socket_type        = stream
                wait                = no
                nice                = 10
                user                = root
                server              = /usr/etc/in.ftpd
                server_args        = -l
                instances          = 4
                log_on_success      += DURATION HOST USERID
                access_times        = 2:00-9:00 12:00-24:00
          }</pre>
 
Per una guida dettagliata di ogni singolo parametro è possibile consultare il '''man''' una volta installato xinetd. Xinetd è un demone molto flessibile e tramite il suo file di configurazione è possibile specificare decine e decine di opzioni.
 
===Opzioni di Xinetd===
Le opzioni che possono essere utilizzate per la modalità di funzionamento di xinetd sono le seguenti:
:* '''-d''' abilita la modalità di debug;
:* '''-syslog syslog_facility''' imposta la facility relativa al system log44 secondo quanto specificato da syslog_facility;
:* '''-filelog logfile'''' indica di redirigere il log degli eventi di xinetd nel file logfile;
:* '''-f config_file''' indica il file di configurazione da considerare secondo quanto specificato da config_file (default /etc/xinetd.conf);
:* '''-pidfile pid_file''' indica di scrivere nel file pid_file il PID del processo lanciato;
:* '''-stayalive''' indica di rimanere in esecuzione anche se nel file di configurazione non è stato specificato nessun servizio;
:* '''-limit proc_limit''' imposta il numero massimo di processi che xinetd può lanciare secondo quanto specificato da proc_limit;
:* '''-logprocs limit''' imposta il numero massimo di daemon che possono essere lanciati in esecuzione per ogni utente, secondo quanto specificato da limit;
:* '''-version''' visualizza la versione di xinetd;
:* '''-inetd_compat''' indica di considerare anche il file di configurazione '''/etc/inetd.conf''' subito dopo '''/etc/xinetd.conf''';
:* '''-cc interval''' indica di controllare un controllo periodico del proprio stato ogni interval secondi;
 
Il processo xinetd effettua le operazioni elencate in corrispondenza dei seguenti segnali:
 
:*'''SIGHUP''' rilegge il file di configurazione e termina l’esecuzione dei daemon relativi a servizi non più attivi (secondo quanto specificato nel file di configurazione);
:* '''SIGQUIT''' termina la sua esecuzione;
:* '''SIGTERM''' termina l’esecuzione di tutti i daemon prima di terminare anche la sua esecuzione;
:* '''SIGUSR1''' scrive il suo stato interno (dump) nel file '''/var/run/xinetd.dump''';
:* '''SIGIOT''' controlla la consistenza delle sue strutture dati, visualizzando quindi un messaggio relativo.
 
Autore: [[Utente:Net deity|Net deity]]
[[Categoria:Server]][[Categoria:Networking]]
GipPasso
117

contributi

Estratto da "https://guide.debianizzati.org/index.php/Speciale:DiffMobile/15045"

Menu di navigazione