Abstract.

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.

The income of the Opensource in the I.Z.S.

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:

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

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

3. 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:

1. verification of the certificate and decifratura of the demand,

2. satisfaction of the demand,

3. 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.