The Istituto Zooprofilattico Sperimentale dell'Abruzzo e del
Molise "G. Caporale" is a public health istitution operating in the field of
animal and veterinary public health. Since 1994 it used opensource software. In this article
we reassumes the advantages offers by
this choice and the currently more important system managed by the
I.Z.S.A.M: the Italian bovine registry office.

End from the end of 1994 the I.Z.S. it has given
to
credit to the opensource software thanks to the introduction of the serveur
web Apache which main public serveur web of the institute and thanks
to the introduction, in the Intranet of the institute, of software
which Squid like proxy server and Inn which serveur of feed of the
news.

Immediately successive to the introduction of such
services on products opensource and to the natural requirement of
having to supply dynamic contents it bases to you on the given bases
that the institute managed and manages is been born the requirement to
create of the scripts of interfacciamento to these DB.

Also in this case the choice has fallen on a product
opensource: the Perl.

In 1998 the net of the I.Z.S. begins to being a point of
reference for the information veterinaries to national level.
Beyond to this, of the danger and being left over culture
cracking of intrusioni wished do not make to be born a more and more
pressing requirement of emergency in computer science within. E'
of this year the introduction, in border-linens of the connettività
of the IZS, of a Linux firewall based on ipchains. [ Inserire
the speech of the transparent-bridging ]

In the 2000 () modernization of the Linux firewall
to suite netfilter + iproute2 of the kernel of the version 2.4.x of
Linux and I use it of the functionalities of "statefull inspection",
"tracking connection"[
1 ]
they
allow the I.Z.S. I use it of a second line of connettività without
the necessity of purchase of an ulterior one router and avoiding the
practical one in order to become Autonomus () System for the
management of the protocol of routing of Internet: the BGP.

The new functionalities of source-NAT together to the
marking of the packages in the PREROUTING process allow navigation of
determine to you calculating through the new connettività, while the
functionality of destination-NAT allows to some of the serveur publics
of the institute of being visible also through the second line.

The bovine registry office enters in the I.Z.S.

To the beginning of 2002 the requirement is born to export
on Internet leaves of the present data in the bovine registry office
Italian and this door to the necessity to resolve problems which the
emergency, the cryptography of the data, the high reliability and
efficiency of the service beyond to the necessity of having to
guarantee one scalabilità of the architecture in terms of number of
at the same time soddisfabili demands.

The demand is therefore that the architecture of the
system hills its the following foundations on bench marks:

emergency, with the adoption of a firewall and the
cryptography of the data;

scalabilità in terms of efficiency and number of
soddisfabili demands;

reliability trying to limit lessened the points of
"single
point of failure" and the time of firm machine in case of crash [
finding the name exact ]

Emergency of the net of the bovine registry
office

A natural consequence of the matured experience
has been the adoption of suite netfilter + iproute2 for the protection
of the net [ to put a little roba in more... where it has been put the
fw, the rules, the routing ].

For the cryptography of the data it has been decided to
use prodocollo the sure HTTPS through I use it of the module
opensource OpenSSL for apache.

Scalabilità of the service

For the performance of this capisaldo it has been
decided to construct an infrastructure to four levels therefore
structured:

[ design ]

a layer of bilauncher

a layer of serveur HTTPS

a layer of serveur HTTP

a layer for the base given

The choice of an architecture to four levels has
been made based on the exposed considerations of continuation.

The separation in two levels between the layer of logon
TCP/IP and that one of applicativo HTTPS has been dictated from the
dualità of having to appear, on one side, to the outside, like an
only serveur web (www address univoco) and from the other side, the
necessity of having to scale the infrastructure to growing of the
demands distributing these on more serveur.

To such aim, the bilauncher, based on a serveur Linux
RedHat with a written applicativo opensource in C, receives logons
TCP/IP on door HTTPS (443) and anticipatamente
distributes to the demands to one list of serveur through one
scheduler round-robin verifying the raggiungibilità of the serveur
excluding those not active.

Serveur HTTPS elaborates the demand as it will be looked
at later on and it gives back the answer to the bilauncher who sends
back it to the client.

Relatively to a single transaction HTTPS, the bilauncher
it is behaved substantially like proxy sock a TCP/IP.

This division in two levels of the process of logon HTTPS
between client and serveur has moreover the advantage of being able to
move layer the 2 (serveur HTTPS) on an accessible private net to the
single bilauncher who remains the only accessible machine directly
from Internet becoming simpler therefore the configuration of the
border-linen firewall why he will have protect the single bilauncher.

In order to understand as never the state of applicativo
has been ulteriorly subdivided in two levels it goes held account of
the operation standard of a serveur SSL whose activity can
macrocospically be subdivided in three step:

verification of the certificate and decifratura of the
demand,

satisfaction of the demand,

coding of the answer.

Since one demanded SSL is medium four times slower than
one demanded correspondent HTTP and the difference resides in the
processes of coding and decifratura in the first one and the last one
step, it has been decided to use two levels of elaboration:
dedicating to first and the third party stepp and the other
dedicated to the process centers them that usual demand HTTP is
equivalent to one.

This separation has allowed to ridondare services HTTPS
with blots some low-cost and to have an only serveur HTTP in cluster
with resources of system adapted to the execution of the interrogation
processes to the database.

An other advantage is given, in spite of the redundancy
and the scalabilità given from serveur HTTPS, the centralization of
the contents in only serveur HTTP, becoming simpler in such a way the
maintenance of the service.

In the prosieguo we will analyze in detail the
technological infrastructure of the three levels in which they have
been used solutions opensource in how much for reasons of
high-availability, reliability and efficiency of layer DB and not
offering to the market a solution opensource, has been opted for a
Oracle system in cluster.

Bilanciatore

[ to make ]

Serveur web HTTPS

Clearly, seen the experience, the serveur web
Apache with OpenSSL module is chosen[ 2 ]and mod_perl[ 3 ].
Apachhe offers the possibility to personalize and to alter the
inner operation of the process of elaboration of the demand through
the module mod_perl.

This was for we essential for being able to realize the
separation between the part closely tied to the SSL (decifratura,
verification of the certificate, coding) remitting the satisfaction of
the demand to a remote serveur.

To such aim, the operation standard of serveur HTTPS had
to be altered in the relative part to the recovery of demand (step 2).
The data traffic deciphered went rediretto to a remote serveur
on protocol HTTP for the effective recovery of the information
demanded from the client. In the case of presence of a digital
certificate them in flow HTTPS it has been decided to alter flow HTTP
in order to communicate to the remote serveur the credentials of the
customer.

The realization of this process has involved the
realization of a module of extension of Apache, saying in written
jargon "handler" [ 4]
in Perl that intercepts the epurata demand for part SSL, of it
analyzes to the content to the search of the presence of an eventual
digital certificate them, from there alters the content eventually
adding the credentials of the customer like parameter
cgi, sendes the demand to the remote serveur attending the answer that
comes then sended to the client (via bilauncher).

Relatively to a single demand HTTPS this layer acts
therefore like proxy a HTTP converting demands HTTPS in HTTP,
addressing them to a remote serveur and encapsulating then answers
HTTP in protocol HTTPS.

Serveur web HTTP

Also this is a server Apache with script in Perl. [ to say other ].

Conclusions

On this infrastructure they have been you execute
yourself from a specialistic company of the stress-tests before going
in production that of it have found the corrected operation, the
efficiency and the scalabilità.

With the guideline to the opensource software they have always
been uses the instruments you of monitoring of the system of the
Italian bovine registry office. E' be in fact used Webalizer[ 5 ]
for analysis of log of the
several serveur and MRTG[
6 ]
for the graphical visualization of I use of the band of the
connettività to Internet.

From the acquired experience in the development of this
plan and particularly from the module realized for serveur HTTPS it
has been elaborated and distributed with licence GPL[ 7 ]
on 8CPAN [ ]
the
Apache::Request::Redirect module[
9 ]
for the forward of remote demands HTTP to serveur.

[ 1 ] For a trattazione user-level of
the functionalities of the firewall iptables and the suite iproute2
you can make reference to the document "Linux Firewall: one
march in more in the net "to the address
http://www.ebruni.it/docs/lf/.