Guide@Debianizzati.Org

Python e Vim: differenze tra le versioni

Pagina Discussione

Python e Vim (visualizza wikitesto)

Versione delle 14:52, 27 dic 2006

143 byte aggiunti ,  27 dic 2006
completato
(completato)
Riga 1: Riga 1:
==Il superdemone inetd==
=Introduzione=
Ci avr� provato ad installare apache (o apache2) con supporto ssl si sar� trovato davanti al problema del certificato: come generarlo? che valore ha? dove posso ottenere un certificato valido? esistono soluzioni gratuite?


===Introduzione===
Queste sono le domande normali che si pone un utente, soprattutto guardando i prezzi esorbitanti proposti per l'acquisto di certificati [http://it.wikipedia.org/wiki/SSL SSL].
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.


Viene chiamato superdemone proprio per questa sua funzione di controllo di altri demoni.
=Generazione del certificato=
La generazione di un certificato � un po' macchinosa, ma tutto questo � a favore della sicurezza della procedura.


Il vantaggio di usarlo � di ottimizzare le risorse del sistema, avviando il demone che gestisce un determinato servizio solo quando ci sono effettive richieste.
Per prima cosa � necessario [https://www.cacert.org/index.php?id=1&lang=it_IT registrarsi] su [http://www.cacert.org/index.php?id=0&lang=it_IT Cacert.Org]. Terminata la registrazione (confermando via email la validit� del proprio indirizzo email) siamo pronti per iniziare.


Sebbene possa essere usato per gestire quasi tutti i servizi � consigliabile farlo solo per quelli a basso e occasionale traffico.
==Registrazione di un Dominio==
Per poter generare un certificato � necessario disporre di un dominio.
* Dopo essersi ''loggati'' nel portale si verr� indirizzati nella propria pagina;
* Selezioniamo, a destra, il men� '''Domini''' e la voce '''Aggiungi''';
* Inseriamo il dominio (senza ''www.'' o altro davanti) e proseguiamo;
* Per poter generare un certificato � necessario verificare che il richiedente sia effettivamente legato al dominio. Per questo motivo sono presenti degli indirizzi email predefiniti a cui inviare l'email di verifica: ''root@dominio.it'', ''hostmaster@dominio.it'', ''postmaster@dominio.it'', ''admin@lerasole.it'', ''webmaster@lerasole.it''.
* All'arrivo dell'email, confermiamo l'aggiunta del dominio.


===Installazione===
==Generazione csr==
Se per qualche motivo il demone inetd non dovesse essere installato � sufficiente installarlo tramite APT. Inoltre consiglio l'installazione dei TCP wrappers:
Per poter ottenere un certificato � necessario avere una Richiesta di Sottoscrizione del Certificato (Certificate Signing Request, CSR). Per crearla usiamo il seguente comando:
<pre>$: apt-get install netkit-inetd tcpd</pre>
<pre>
# openssl req -nodes -new -keyout dominio.it.key -out dominio.it.csr
</pre>
Dove, ovviamente, ''dominio.it'' rappresenta il nome del nostro dominio.


===Configurazine===
Verranno poste le seguenti domande:
Per prima cosa � necessario modificare i permessi al file '''/etc/inetd.conf''' in modo che solo root abbia accesso:
<pre>
<pre>$: chmod 600 /etc/inetd.conf</pre>
Generating a 1024 bit RSA private key
..............++++++
..................++++++
writing new private key to 'mail.knio.it.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:IT
State or Province Name (full name) [Some-State]:Verona
Locality Name (eg, city) []:Garda
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MaXeR
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:dominio.it
Email Address []:admin@dominio.it


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:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
</pre>


<pre># These are standard services. 
{{Box|Nota:|i dati inseriti sono futtizzi, � d'obbligo sostituirli con quelli reali}}
#
#ftp    stream  tcp  nowait  root  /usr/sbin/tcpd  in.ftpd -l -a 
#telnet stream  tcp  nowait  root  /usr/sbin/tcpd  in.telnetd
#
# Shell, login, exec, comsat and talk are BSD protocols. 
# 
#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>


Il formato tipico di ogni riga � il seguente:
Per dare una durata di tempo al certificato aggiungere al comando openssl , -days xxx
dove xxx sono il numero di giorni di validit� dello stesso


<pre>service type protocol wait user server cmdline</pre>
Verranno generati due file: ''dominio.it.key'', che rappresenta la chiave privata; ''dominio.it.csr'' che rappresenta la Richiesta di Sottoscrizione del Certificato.


==Richiesta del Certificato==
Visualizziamo il contenuto del file '''dominio.it.csr''' e copiamolo nel form contenuto in ''Certificati per i Server (Server Certificates)'', ''Nuovo''.


Un esempio pratico di una riga presente in '''/etc/inetd.conf''':
Inviamo il contenuto del form e confermiamo. Al termine dell'elaborazione verr� mostrato il codice del certificato (una copia ci verr� inviata anche via email), salviamolo nel file '''dominio.it.crt'''.
<pre>ftp stream tcp nowait root /usr/sbin/in.ftpd �l


ftp: nome del servizio
==Spostiamo i file sul server==
stream: indica il tipo
Spostiamo i tre file sul server, nella directory '''/etc/apache/ssl/''' nel caso di apache, '''/etc/apache2/ssl''' nel caso di apache2.
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>


Inoltre inetd si appoggia su un altro file di configurazione dei servizi:
==Verifica del Certificato==
Prima di configurare il server � d'obbligo un controllo sulla correttezza del certificato. Per fare questo dobbiamo:
* Scaricare il ''root certificate'' dall'indirizzo http://www.cacert.org/certs/root.crt
* Copiarlo nella directory '''/etc/apache/ssl/''' (o '''/etc/apache2/ssl''' nel caso di apache2)
* Eseguire il comando: <pre>openssl verify -CAfile root.crt -purpose sslserver dominio.it.crt</pre>


<pre>/etc/services
Se tutto � stato eseguito correttamente, il controllo avr� esito positivo.
File che assegna un nome di servizio alla relativa porta.
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:
=Apache=
<pre>ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd �l</pre>
==Installazione==
''Apache-ssl'' rappresenta il [[demone]] Apache con il supporto per ssl abilitato. L'installazione � semplice, rappresentando un pacchetto ''separato'' da apache ''normale'':
<pre>
# apt-get install apache-ssl
</pre>


Nelle distribuzioni Linux, solitamente inetd � gi� configurato per supportare i tcp wrappers.
==Configurazione==
Prima di installare i certificati � consigliabile mettere mano alla configurazione generica del server, in modo da sistemare quei parametri relativi al dominio, all'amministratore e alla directory radice utilizzata da apache.


===TCP wrappers===
===Modifica impostazioni base===
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.
Il file in questione � '''/etc/apache-ssl/httpd.conf'''. Le voci da adattare alla propria configurazione sono le seguenti:
; ServerName : indica il dominio al quale dovr� rispondere il server. Nel nostro caso sar� ''esempio.it''.
; ServerAdmin : l'email dell'amministratore del server. Nel nostro caso ''sysadmin@esempio.it''.
; DocumentRoot : indica la directory radice in cui si trovano le pagine che verranno mostrate da apache. Nel nostro esempio verr� mantenuto il valore di default.


In pratica da una configurazione:
===Aggiunta del Certificato===
Il file da modificare �, anche in questo caso, quello principale: '''/etc/apache-ssl/httpd.conf'''. All'interno di questo � presente una sottosezione, preceduta dalla riga
<pre>
# ----------------------------SSL----------------------------------
</pre>
All'interno di questa sezione si trovano tutte le voci di configurazione del modulo SSL; quelli che ci interessano, per una configurazione ''base'' sono ''SSLCertificateFile'' e ''SSLCertificateKeyFile''.


<pre>client -----> inetd -----> servizio</pre>
Commentiamo (o modifichiamo) quindi quelle gi� presenti ed aggiungiamo quelle relative al nostro certificato:
<pre>
SSLCertificateFile /etc/apache-ssl/ssl/esempio.it.crt
SSLCertificateKeyFile /etc/apache-ssl/ssl/esempio.it.key
</pre>


Si passa ad una configurazione:
Salviamo il file e riavviamo apache-ssl.
<pre>
# /etc/init.d/apache-ssl restart (o reload)
</pre>


<pre>client -----> inetd -----> TCPD -----> servizio</pre>
=Apache2=
==Installazione==
L'installazione di apache2 � semplicissima:
<pre>
# apt-get install apache2
</pre>


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.
==Attivazione del supporto SSL==
Per poter usare SSL in apache2 � necessario attivarlo (visto che non � presente un pacchetto apposito come ''apache-ssl''):
<pre>
# a2enmod ssl
</pre>
provvede ad attivare il supporto per SSL.


Questo file permette di specificare quali servizi abilitare e da quali indirizzi IP:
==Creazione VirtualHost==
<pre>/etc/hosts.allow</pre>
Dobbiamo, ora, creare un VirtualHost che sia in ascolto sulla porta 443.


Questo file permette di specificare come limitare l'accesso a specifici servizi:
Prima di procedere, per�, dobbiamo modificare il comportamento di Apache relativamente ai ''NameVirtualHost''.  
<pre>/etc/hosts.deny</pre>


===Comandi utili===
Modifichiamo il file '''/etc/apache2/apache.conf''' e aggiungiamo, prima di
Per avviare, riavviare, fermare il servizio inetd:
<pre>
<pre>$: /etc/rc.d/init.d/inetd start/stop/restart</pre>
Include /etc/apache2/sites-enabled/[^.#]*
</pre>
le seguenti righe:
<pre>
NameVirtualHost *:80
NameVirtualHost *:443
</pre>
e assicuriamoci che l'opzione ''NameVirtualHost *'' sia commentata o rimossa dal file '''/etc/apache2/sites-available/default'''.


===Configurazioni utili===
Modifichiamo tutti i VirtualHost aggiungendo l'indicazione delle porte (ad esempio: ''<VirtualHost *>'' diventa ''<VirtualHost *:80>'').
Nega l'accesso a tutti i client e controlla che ip - nome.host corrispondano:
<pre>File da applicare: /etc/hosts.deny
ALL:ALL@ALL,PARANOID</pre>


Consente l'accesso a tutti i client e controlla che ip - nome.host corrispondano:
Ora creiamo un nuovo file, in ''/etc/apache2/sites-available''' che chiameremo '''dominio.it-ssl''', ed utilizziamo il seguente schema:
<pre>File da applicare: /etc/hosts.allow
<pre>
ALL: LOCAL 192.168.1.0/255.255.255.0</pre>
<VirtualHost *:443>
        SSLEngine On
        ServerName dominio.it
        ServerAdmin admin@dominio.it
        DocumentRoot /var/www


Permette l'accesso SSH all'host prova.it corrispondente all'IP 10.0.0.1
        ErrorLog /var/log/apache2/dominio.it-ssl_error.log
<pre>File da applicare: /etc/hosts.allow
        CustomLog /var/log/apache2/dominio.it-ssl_access.log combined
sshd: 10.0.0.1 prova.it</pre>
</VirtualHost>
</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.
ovviamente adattando le varie opzioni alla situazione reale...
<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==
Ora provvediamo ad attivarlo:
===Differenze===
<pre>
A differenza del precedessore, xinetd (e'''x'''tended inetd):
# a2ensite dominio.it-ssl
</pre>


:*Limita o regola l'accesso a determinati servizi senza ricorrere al Tcp Wrapper;
==Aggiunta Certificati==
:*Offre un sistema di logging indipendente da syslog;
I certificati, in questo caso, verranno aggiunti in un file a parte: '''/etc/apache2/conf.d/ssl.conf''' con il seguente contenuto:
:*Permette di limitare l'accesso ai servizi in determinate ore della giornata;
<pre>
:*Supporta il protocollo Ipv6;
SSLCertificateFile ssl/dominio.it.crt
:*Utilizza vari meccanismi che mitigano l'impatto di un attacco DOS.
SSLCertificateKeyFile ssl/dominio.it.key
SSLCertificateChainFile ssl/root.crt
</pre>


===File di configurazione===
Per applicare le modifiche � sufficiente riavviare apache:
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>
<pre>/etc/xinetd.conf
# /etc/init.d/apache2 restart
File di configurazione del demone
</pre>


/etc/xinetd.d/*
=Test di funzionamento=
Directory che contiene i singoli file dei servizi offerti da xinetd</pre>
Il miglior test � forse il pi� semplice: aprire un browser e collegarsi all'indirizzo https://esempio.it ;-)


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:
=Considerazioni=
<pre>service service_name
==Limitazioni nell'utilizzo di VirtualHost==
{
La limitazione pi� ''pesante'' che si pu� notare � l'impossibilit� di utilizzare pi� di un certificato per la stessa accoppiata ''ip:porta''. Il motivo � semplice: i dati inviati sono cifrati, quindi � impossibile, per apache, riuscire ad estrapolare il ''ServerName''... Quindi viene usata l'accoppiata ''ip:porta'' per definirlo.
    attribute assign_op [value] [value] [...]
    [...]
}</pre>


Dove i seguenti attributi indicano:
==Diffusione di CaCert==
:* '''service_name'''  � l�indicazione di un servizio gestito da xinetd;
CaCert inizia ad essere inserito, come certificato root, anche nei vari browser, evidenziando che l'attenzione verso questo progetto sta salendo... Non resta che adottarlo ed, eventualmente, fare richiesta agli sviluppatori del nostro browser preferito affinche CaCert venga inclusa.
:* '''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===
=Bookmark=
Di seguito sono riportati alcuni esempi pratici e semplici di un file di configurazione '''/etc/xinetd.conf''':
[http://www.cacert.org '''CaCert.Org''']
<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]]
TheNoise
1 760

contributi

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