Recommendations of network architecture with filters to improve safety in particular to better protect themselves from attacks from the

Internet Jean-Luc Archimbaud CNRS UREC (http://www.urec.fr) January 25, 2000 This document is intended for network administrators and systems, who must estab lish or to change the architecture of information systems (computers and network s) of a campus, a group of laboratories or laboratory (in what follows the term site, select these three environments). Another document more didactic, less det ailed and less technical is available online: http://www.urec.cnrs.fr/securite/a rticles/archi.reseau.court.pdf. This article does not attempt to solve all secur ity problems, far from it. It focuses on vulnerabilities related to network, par ticularly to attacks from the Internet and tries to propose a model of architect ure associated with access controls to mitigate these vulnerabilities. This mode l should be acceptable to the community teaching and research. Specifically it d oes not require heavy investment and can be easily adopted by users, even transp arent to them. Like any model it is to adapt to each environment. The recommenda tions below are not new, many years we have expressed in various ways. Now, it i s generalized to all sites because the risks and attacks are increasing day by d ay. But the features that are recommended to use are now available on all produc ts installed on sites and administrators have become proficient enough to unders tand network and configure these mechanisms. 1. Situation 1.1 The success of the Internet was not planned ... Our sites are connected to the Internet long. When choosing the architecture of access points to Internet sites, specifically to RENATER, security was not a pri ority criterion. The main purpose was so that all machines sites, without except ion, can access and be accessed from the Internet with the best rate possible. T he total connectivity (full connectivity) was the objective. We thought there mi ght be security problems in the future but this was not a priority in technical decisions. The Internet was a set of research networks in which "everybody knew" . There was no attack of spam, scan, smurf, flood, spoofing, sniffer, ... (refer to articles of the mainstream computing press). Now the Internet has become a g lobal communication tool, used by good and bad citizens and all current deviatio ns are present. Even the term global village, which designated the Internet with its note of friendliness and quiet, seems to have disappeared. The Internet is not as black as the world but it is not as white either. We saw immediately that this was a total connectivity boon to ill-intentioned people who could very eas ily and try to test all the machines on a site and quickly find a weak link. Whe n the first attacks came as we know now every day, an extreme reaction was to re commend installing a firewall at the entrance to each site. Magic word, full ins urance! This equipment, which originally meant a set of application relays would solve all problems. But the gatekeepers of the time were very restrictive. They did not support (let go) that some applications, demanded (and still require) a heavy administration, were bottlenecks in terms of throughput (which is always true for relay applications) ... We have not recommended to generalize this solu tion for all sites. Another reason very Recommendations of network architecture with filtering to improve safety - JLA CNRS / UREC 1 pragmatics is that we do not have the financial and human resources to install a nd administer this type of equipment in each laboratory. Soon these gatekeepers relay applications have evolved to become more "bearable". Today, it would be ha rd to define what a firewall because it may combine one or more very different f unctions such as packet filtering, filtering (static or dynamic) of sessions, tr anslation of addresses, the relay applications, user authentication, intrusion d etection,€... These firewalls can be found in black boxes or dedicated software on a PC or router or ... And it takes skill to choose a firewall suitable for th eir needs and configure. The security has not simplified. The firewall in the se nse box or special software is not a solution to systematically reject, in some environments it is justified, but it does not generalize to any laboratory. Clos

ing parenthesis. The choice of "wide open", when it was done, was not a mistake but now stay in the same logic is one. It is essential to limit the possibilitie s of communication between the exterior and interior, not by restricting users b ut allowing only what is useful, this on all sites. The method is explained in t his document. In the same way that they can be locked his apartment or his car, which can control access to its building, it should not be left completely open their Internet access. The commercial operators who are connected to the Interne t much later did not have the same approach as us. They viewed the Internet as a departure from the external world, hostile. They built a private internal netwo rk to connect their sites, an intranet, where all communication flows (often con fidential) intra-company. They are connected with the Internet in one or two poi nts through which mainly public information. These gates are controlled by equip ment type firewall. We, we use as an Intranet Renater while RENATER is the Inter net. We have hundreds of access points to the Internet where a totally different situation, much more dangerous. Internally on the sites where the local or camp us networks have been established, the goal was the same as for Internet access. It should connect the maximum number of posts, all posts to be able to communic ate with all others, install a universal service, the same for everyone. On smal l sites, one Ethernet network enough, on several major sites connected Ethernet networks were constructed by routers, with a geographical division to reduce loa d and overcome the distance limitations of Ethernet. No security test has been t aken into account in the design of the first campus networks. The use of network generalization is realized on the same site, some groups such as students had g reat opportunities to count among them a cracker, some laboratories (with many i ndustrial contracts for example) needed more security than others, some machines contained sensitive information management, ... and was an Ethernet network whi ch broadcast with a simple software installed listening on a PC user could retri eve all the passwords that circulate on the network (this is just one example of an architecture of vulnerability unsegmented). In the second wave of setting up networks of large sites, segmentation (cutting the network) has been implemente d, physically first (a "fiber" for teaching, for research, for Administration), then logically with VLANs (Virtual LAN, Local Area Network) when this feature wa s available on the equipment. We must now try to generalize the segmentation at all medium and large sites. 1.2 imperfect systems What is the risk of total connectivity, ie the total freedom of communication be tween internal machines and the Internet? Recommendations of network architecture with filtering to improve safety - JLA CNRS / UREC 2 1.2.1 Systems with bugs If all systems were perfect and all the machines were administered with daily mo nitoring, there would be no additional risk. But it is very far from this image of Epinal. Almost daily advice of a CERT (Computer Emergency Response Team) repo rts a bug in a program with the appropriate patch. Usually this decision follows the broadcast on the Internet a tool of attack that uses this bug to gain admin istrator rights of the vulnerable machine. To handle this weapon free software a nd available to all, no need to be a genius, you just run a program. Fortunately for us the vast majority of Internet users has other goals than trying to hack the search engines. Otherwise€What carnage in laboratories! But in the tens of m illions of Internet users, there is a small handful of psychopaths or criminals, and there always will be, to show that their capacity for fun, revenge, delight in penetrating the system, break .. . The laboratories also have some scientifi c or commercial competitors who do not hesitate to use these tools to take owner ship of their work. Several attacks were targeted at units to retrieve search re sults or interesting developments. Thus the CNRS, on average 2 a week of violent

attacks are dawn (excluding scans). 1.2.2 Open systems default The other Achilles heel of a distributed information system network as it has to day is the heavy administrative work of the many Unix and NT servers are based. Now who said servers, said network server software (Unix daemons, servic es NT), all of which are windows that can afford to break into a computer. The work wou ld be greatly simplified if the computers were delivered all the windows closed and the administrator only has to open one to one they needed. It is not! The tr end of Unix and NT is the opposite of the start up of services by default, witho ut informing the administrator. It must close these unnecessary openings. A firs t step is to discover all the openings, the second to keep only those useful net work services actually used. A simple command just you tell me. Nay! On Unix, we begin to have the necessary experience and with inetd.conf, startup files and c ommands ps and netstat we come to take stock and to the household. On NT, you ca n achieve a similar result with the Services menu in Control Panel and the Task Manager but the experience is sorely lacking and we do not even know with certai nty the number of ports used by all NT services. So on most computers in a site is launched unnecessary network servers, misconfigured, or not all of which igno red windows wide open. 1.2.3 Too Many Systems When there were few machines (especially few servers) at the sites, a strong rec ommendation was to retain all the machinery of sites in a safe condition, well c onfigured with the latest patches. But this goal is unrealistic now. A director who has tried to apply all patches rating of CERTs in all its diverse park and t ried to control the network services on any Unix or NT users quickly realized th at this was a race unwinnable. With such buggy software to regularly change and open servers delivered it must reconfigure tasks are added to their daily work, the directors did not physically have time to maintain all systems of a site in a state acceptable security. 1.2.4 So? We must find another solution. It is the purpose of these recommendations that p rovide a network architecture with the necessary access restrictions and allow r estrictions to a handful the number of systems to be configured carefully, regul arly update and monitor daily, leaving the vast majority other stations in a mor e relaxed without undue risk to the safety of all. Recommendations of network architecture with filtering to improve safety - JLA CNRS / UREC 3 2. Architecture 2.1 Principles We can make the observation that all systems of a site do not need the same acce ss opening towards the Internet. In the sense out of the site to the Internet, a ll positions must be able to access Web servers, exchange messages, will limit . .. Mostly little communication in this regard. Nevertheless, we may consider tha t certain groups such as students can behave as a pirate for the outside and lim it their actions in this direction outgoing. But in the sense incoming from the Internet to the site, meaning that provides access to network services on local stations, the need for connection is generally very low, of course, the Web serv er must be accessible by any Internet but local servers (eg computing) and user workstations have rarely needed. If this is the case, however, the need is often temporary (access to files on missions, from home) and identified (since some s ites).€Yet it is this meaning that this coming danger. We will therefore try to limit as much as it can flow in that direction. On this basis the principle of t he architecture is simple. At first we need to separate machines that need to be

accessed from the Internet (network servers) other (client machines and users o n local servers) and have the first in a zone between the Internet and semiouver te purely local network. In a second time on the local network, it must identify the different communities (units, laboratories, schools, UFRs, services, intern al corporate servers, ...). The machines of these groups will be divided into di fferent sub-s physical or logical networks. We thus have a segmented architectur e. The criteria to be considered for this sort may be the administrative transfe r but also the network needs (full connectivity with the Internet or not), the s ecurity requirements (confidentiality of certain contracts, data, ...), types of users (permanent or transient), the mode of administration of the machines (by the department, an ITA or without administration recognized). Lab A WEB MAIL DNS Internet R1 Public database ... R2 Lab N Administration Hall TP Semi-open Fig 1: principle of architecture In a third step we will install filters in the connection devices (routers R1 an d R2) to isolate certain sensitive machines or groups at risk and allow only nec essary services and controlled circulation. The sorting machines are made, these filters are simple to write. Recommendations of network architecture with filtering to improve safety - JLA CNRS / 4 UREC 2.2 Services in the semi-open In the semi-open, site entry, you must install all the machines that provide net work services with external DNS, mail, Web, anonymous FTP, News Server, dial-up, Web caching, database public data, and any other service that requires intensiv e communication with the Internet. This area is typically an Ethernet 10 or 100 million, according to the flow of making access to the Internet. You do not need gigabit if we have an access to 2 million with the Internet. This network will be connected to the Internet through a router (R1 in the diagram) in which it ha s installed a set of filters described below. Network services pouront be split across multiple machines or concentrated on one or both, depending on site size, budget, method of administration ... The breakup advised on several machines to better monitor and restrict access. These machines are the handful of machines that must be perfectly managed. Each machine will be dedicated to his or her dut ies, she will not be used as a workstation "classic" and does not host other app lications. The system will be Unix or NT. The selection criterion should be the competence of directors. NT services can seem easier to install but NT is a comp lete system that must be mastered and known as Unix if it wants to ensure its se curity and its overall functioning. On these machines, system versions and appli cations are regularly upgrades and security patches are installed as they are re leased. All unnecessary network services will be inhibited (household in inetd.c onf on UNIX or in Control Panel - Services on NT). A minimum of users with inter active access will be declared, only administrators who need it. On each will be installed a monitoring tool and trace the connections as tcp_wrapper Unix. In t hese servers, all logging messages (logs) will be returned on an internal server , called "Server logs" on the diagram below. Lets look at some services that req uire certain adaptations: • On the mail server will be reported all users with a n email account POP or IMAP to access their mailbox without the possibility of i nteractive work (no shell, hence the name "Mail without sh). If for some read th

eir mail using Unix commands (which require a shell), their messages will be ret urned to any internal mail server, called "Mail sh" in the diagram, where these users will have interactive accounts. For each user, the password used to access the mail server of the semi-open will be different from all other passwords use d to access other systems, particularly that of their working machine.€• The Web server will contain only public pages. If the site wishes to have private pages they are on an internal server, called "Internal Web Server" on the diagram. Si milar to other servers, it must account minimum interactive on this machine. Thu s the construction of pages of public Web server that requires this type of acce ss will be made on the internal Web server. The updating of the public server wi ll transfer files between two servers every day, for NFS mount if administrators fully mastered the mechanisms of this protective system, or any other similar s ystem and well controlled. • If the site has a database server or public data ac cessed from the Internet, these machines will be installed in this area, and we apply the same recommendations for operational and updated for the Web server. • If the site has a dial-up service (PSTN), it will also consider in this area. I n this server, it will authenticate all users, and keep track of calls, sent to the "server logs". We apply access restrictions per user, in particular we will not default connection to the Internet via such access. • To prevent direct acce ss through telnet or FTP from the Internet on the internal network machines, mac hine relays can be installed. Thus a user who wants access from outside interact ively with telnet on the machine laboratory must first connect to the relay and then do another telnet. On this relay will be declared only for users who need t his service with a particular password. A record of all accesses this relay will Recommendations of network architecture with filtering to improve safety - JLA CNRS / UREC 5 preserved. A fine-grained control of user accounts (life accounts, strong passwo rds, ...) will be made. This passage allows obliged to concentrate all the right security measures on the management of user accounts on a single station, which is much easier to do than several tens or hundreds of machines in-house. The ne w network services become widespread, one might think, as the LDAP (Light Direct ory Access Protocol) can be integrated in the same way: an LDAP server informati on "public" (as the phone number or electronic address) in the semi-open, anothe r in the "internal Shared Services" for information "private" (as the password). At one point in this area we can look to all exchanges with the Internet. This is the place to install a tool that measures the activity and identifies some ab normal traffic, traffic analyzer as IPtrafic or intrusion detection. Such equipm ent can be very useful to detect attacks and to know the use of the Internet mad e by the site. The only problem is the time required to install and use the resu lts of this kind of product. Network Administration IPtrafic or intrusion detector Research Team / A Team research lab / lab B Internet Router R1 Mail without sh DNS Relay WEB anonymous FTP telnet and ftp Backbone R2 BTI S Research team / lab X Web Caching

Rooms Laptops TP sh ... Mail Services internal common News WEB Server Server Server Server load backups or internal logs Application Area s emi-open Fig 2: detailed architecture 2.3 The internal architecture On the internal network, typically an Ethernet 10-100-1000 Mbps, a division of t he network will be made. The device called Backbone R2 is a set of elements that make routing (routers, switches -4-5-6-7 level 3, ...) with filtering functions . Each subnet connected to R2 can be physical, by a dedicated cable network, or logical if the equipment has the functions of virtual networks (VLANs). One of t he advantages of VLANs is the ability to evolve this architecture, at the option of restructuring moves and very common among us, without intervention on the wi ring. However, this imposes certain constraints such as the centralization of ad ministration and uniformity of equipment almost mandatory. Although the definiti on of groups and segmentation depend entirely on the site, the scheme gives an e xample on which to draw. There are sub-networks: Recommendations of network architecture with filtering to improve safety - JLA CNRS / UREC 6 Administration: includes management stations, with data often confidential (form al correspondence€personal files, contracts, accounting information, evaluations of staff and students, ...). Users of this group needs "servants" of the Intern et, Mail and Web only, not really telnet or FTP. There may be several sub-networ ks "administration" on the site, when many administrative services are present f or example. • Teams or laboratories: a sub-network research team or laboratory o r administrative entity with a specific decision-making authority. These network s often have special needs connectivity: access to computational servers or data bases or large national or international scientific equipment, cooperation with foreign teams, ... • Movie TP (Lab): networks that are controlled computers but poorly users, considered dangerous because potential attackers, both for the loc al site for the remote sites. We want to limit their Internet use and access to other local groups. • Laptops and more generally concerning not administered, if such equipment is common, perhaps he should consider a subnet (or several) to c onnect the stations of people passing the site or who have "their" personal comp uter that does not administer the IT team. These machines may be incorrectly con figured, they certainly are, and are therefore dangerous. It will certainly isol ate and treat them as external machines. • Common Services Internal: can be grou ped on one or more subnets machines that provide services to the entire site or multiple site groups. Users of these services are only local stations do not nee d access from outside (as opposed to servers in the semi-open). This can be comp utational servers, backups, web internal servers ... if need internal messaging with interactive users (see before). A security apparatus which collates and ret rieves the relevant server logs of the semi-open and routers is required. This m achine can be installed in this subnet. • 2.4 Filters The architecture development becomes truly useful for security, if you install m echanisms that limit the traffic with the Internet and between different subnets . On routers or equivalent equipment that can be done in different ways: • By ro uting control: in fact it's easy not to announce (make known) sub-network RENATE R for example, and all machines subnet will not be reachable from the Internet b ecause the IP number of subnet will be unknown in the routing tables national an d international. • For static filtering on IP addresses: one prohibits all traff

ic to and from some machines, certain sub-networks. • By filtering static port n umbers associated with IP addresses: one and allows the use of only certain appl ications to or from certain stations or subnets. • For dynamic filtering for app lications that use dynamic port numbers as H.323 for IP telephony. The first thr ee ways are covered by the functionality of almost all routers in the market (fo r switches, routers or equipment "hybrid" of this type must be checked). The dyn amic filtering often requires a relatively new equipment or software specific ro uter, classified as a gatekeeper. 2.4.1 The filters on the router input R1 The policy will ban everything R1 in the direction of incoming services except t hat we know and to control some machines. All other access will be rejected. Ini tially, we will install filters to prevent the usual problems of IP masquerading and IP broadcast. Then the purpose of these filters can be: • Deny access from the Internet to machinery of government (too sensitive) and laptops (not adminis tered). One can proceed in several ways with four types of filtering above. The simplest method, which we do not often think, is to "hide" sousRecommandations n etwork architecture with filtering to improve safety - JLA - CNRS / UREC 7 Network Administration "and" Mobile "on the Internet. In fact these groups have claims only messaging and web access (no need telnet for example). In this case, if the site has a Web cache, the machines of these subnets do not use a direct IP access to the Internet,€access to the semi-open enough (where we find the mai l server and web cache). This will not announce (make known) these subnets Renat er or simply numbering machines with private addresses (RFC1918). • You can appl y the same remedy for subnet "TP Room" with a different purpose: to limit the po ssibilities of attacks to external sites from this subnet. By not allowing full connectivity with the Internet, the internal potential hackers can not access or telnet or ftp to external sites. This will limit significantly their ability to harm. • Prohibit all traffic with some sensitive machines and who do not need a n Internet connection, as IPtrafic station, the station with the intrusion detec tion software, server logs, some machines used for sensitive research contracts, and Why not service machines such as internal server computing ... This may be achieved by filtering on IP addresses. It prohibits the entry packet with destin ation address as the IP address of sensitive machines • Do not 'let' current ser vices which are known (email, web, ...) as to the machines of the semi-open, it authorize to say that the incoming email traffic to the mail server without sh o f the semi-open Web to the Web server of the semi-open ... and ban all these ser vices and others to all other machines . Remember the policy is to ban everythin g that is not allowed. This can be achieved by filtering the static port numbers and IP addresses. Network Administration Room Phones TP research team / lab X I N T E R N E T IPtrafic or intrusion detector Unrecognized Service Mail Mail without sh WEB Backbone R2 WEB FTP

Anonymous FTP Relay telnet and ftp Telnet Router R1 Semi-open Fig 3: Principle (simplified) filters These filters offer great protection but not 100% as you might think at first an alysis. Two vulnerabilities are present: Recommendations of network architecture with filtering to improve safety - JLA CNRS / UREC 8 . Rebound: when R1 is prohibited on "incoming telnet" to an internal station S1 but that it be allowed to another internal station S2, an attacker can first con nect S2 to S1 then log on. In this case the filter on R1 will be no effect. . Th e demons start with nonstandard ports. If a hacker is already in place, a statio n manager, he may issue a telnetd daemon on a port other than 23. In this case t elnet access to the station may not be detected by the filters (it depends on th e writing of filters), a router telnet service is synonymous with port 23. Cauti on, make no mistake about the purpose of such access restrictions. The purpose o f these filters is not to harass users but not to miss what is really useful. Th e special needs for example, can and should be taken into account. If a research team at a station of its internal network provider must resort to other externa l (interactive X, remote computing, distributed applications, ...) will open a f ilter to allow dialogue. But we will do the most restrictive way possible, ie we only allow the software application (identified by its port number) between two stations (identified by their IP number). 2.4.2 The filters on the backbone R2 These filters are primarily intended to protect various internal entities betwee n them. Why? Because a group can host too lax pirates in it or have so few machi nes that hackers outside protected introduce it easily without being detected fr om the base and may attack other machines on the site (problem reported Rebound before). Technically, the equipment 'backbone R2 "may have security features tha t most primary R1. Its role is primarily to transport (switch or router) traffic as quickly as possible between different subnets. As a filter we can deny all o r part of the communications between entities that do not trust: "Administration " versus "Network TP, research teams between them ... You can also defer part of filtering described for R1 R2 if it is too difficult for technical reasons or o rganization to focus all controls on R1.€The effectiveness of these filters can be verified with simulation software such as Internet Scanner intrusions launche d from outside the network, the Internet, to the internal machines. This is a ve ry good test to perform regularly. 2.5 and NAT? NAT as Network Address Translation is a mechanism generally placed in a router t hat changes the IP addresses in datagrams. Specifically, the output site, it dyn amically assign addresses to client machines over the site when they access the Internet. It allows to have a virtually unlimited private address on the site an d use a handful of official numbers for communications with the outside. This is the only solution when you can not get IP address for all official s of its mac hines. It is a wart does not comply with the principles of TCP / IP but is now a must for some sites to address shortage. To implement this feature, you must ta ke inventory of the site's servers, which they must always have the same static address not private address ranges assigned to client machines, ... so all work of identification and classification stations and services. With NAT, a machine

of his client a different address each time it connects to the Internet ite. It can thus be very difficult to attack from the Internet. It is for these reasons that some rank NAT in security mechanisms. In an indirect way is correct because it forces one to do the job of identifying services used ... But if you make th is work, which we built the architecture described before with the recommended f ilters, NAT does not really add additional protection. So if you have a lack of official IP addresses for your site using NAT but do not install it only for sec urity features, first follow these recommendations. Recommendations of network architecture with filtering to improve safety - JLA CNRS / UREC 9 3. Results 3.1 What is the usefulness of such an architecture? Currently, the most common technique to attack a website is to discover all mach ines on the site ("scan"), to detect all network services installed on those mac hines to test the known security holes in these server software and then use the se holes to gain administrative privileges on the machines. Need to be an expert to carry out these attacks, many tools are available on servers that are known and used by any user. If you do not filter input from your site without effort, these tools will detect vulnerable machines at home and cons ... For if you have the recommended filters, attacks reach only a handful of machines in the semi open, machines that are properly administered low vulnerability. All other attac ks to internal machines will be adopted by the filters. To take one example, in early 2000, the CERT RENATER has published statistics showing that the ports app lications Sendmail, RPC, DNS, NFS and HTTP, and ports used by Trojans Back Orifi ce and NetBus had been scanned more earlier this year. With filters installed in Chapter 2 attacks Sendmail, DNS and HTTP reach only mail servers, web names and the semi-open servers properly managed and monitored very, rpc attacks, NFS, Ba ck Orifice Netbus and not reach any machine as filtered through R1. So if the in ternal network stations are not monitored with the poor management of user accou nts (old dormant accounts, weak passwords ...) or software security patch ... wi thout the risk of successful attack from outside is very low. Indeed, with filte rs in place, it will be impossible from the outside directly reach these station s. The hacker can possibly go through the telnet-ftp, but it will take it crosse s the barrier well supervised and managed carefully, so very little vulnerable. The problem with passwords is also less critical. So if a user discloses, volunt arily or not, the password for his third personal station, it can not access the station from the outside. In the same vein, if a hacker installs a sniffer (sof tware listens on a network) on the semi-open he will not discover the passwords of users on their workstations or on internal servers.€If a student does the sam e thing the subnet "Hall TP" he discovers that the passwords of other stations i n this room. Many other protection arising from the architecture of these filter s, but it would be too tedious to enumerate here. Another advantage is the estab lishment of such an architecture requires knowledge of the network and systems f rom its site and use that is made. And this is a good point and even a pre-requi site to ensure security: it does not protect well as what we know. Finally, this architecture will over time easy integration of additional protections for cert ain communities as dynamic filters, application firewalls, intrusion detection s oftware, strong authentication ... without questioning the existing. One might t hink that the widespread use of encryption products will soon need this type of architecture and filters. It will not happen. First, it will take several years before that each user has a certificate and that all applications are secure. We may even think that much of the application remain insecure. For the worldwide deployment of key management infrastructure may be slow and costly. Those who ha ve begun to study and test PKI (Public Key Infrastructure, aka PKI - Public Key Infrastructure, Alias TGI - Public Key Infrastructure) can attest. Second, even if some of these applications are secure, the stations will still have demons or

network services in the queue that have bugs ... and respond to attacks like Recommendations of network architecture with filtering to improve safety - JLA CNRS / UREC 10 today. The use of encryption is not going to remove the vulnerabilities describe d in this document. 3.2 Where to apply this model? The proposed model is to adapt to each environment. We chose the vague term "Sit e" in this document voluntarily. He may designate a campus, a group of laborator ies, laboratory, ... On one site we can have several semi-open. If we take the e xample of a campus, we could set up one semi-open to the entire campus, or more semi-open areas, one for each major laboratory or laboratory group (institute, u niversity, ...). It may also be the meeting of two solutions, a semi-open campus entrance (servers for small units in poverty) and as many semi-open areas as gr oups of laboratories that have their own network servers. For services must make the same adaptation. The goal of this architecture is not to force the sites to centralize all network services on machines site. While this centralization is beneficial for the security (limiting the number of stations to monitor, ...) mu st also take account of existing skills in each entity and the willingness of so me groups to have their own autonomy when they have the computer to administer t he services. As a campus, taking as an example messaging, a laboratory may wish to administer their own mail server different from the general server. This is n ot inconsistent with our recommendations if this server is administered accordin g to the recommendations that were made, if the server is placed in a semi-open and if the filters are adapted. In the case of email, another option for the lab oratory can be to its mail server in the subnet of the laboratory and to channel messages from the mail server of the semi-open site. So, do not hesitate to ada pt. By cons, there is in all cases clearly segregate for each machine type (user station, network server, internal server), her service, placing "the right plac e" and the type of operation to be done. These choices are thus dependent on the presence or non-network services common to all laboratories on the site but als o directors or assigned to those common services, the two go hand in hand. 3.3 How to apply? Some say that users will not accept these changes. If properly implemented it sh ould be transparent to them. To do this requires a first phase about the environ ment, entities, servers, services used ... A conductor must have the global visi on of the entire site and security to implement.€But it must involve all adminis trators. Thus from the outset to perform the inventory, it must consolidate the directors of all laboratories, very official with the approval of management of each entity. This will also ensure the support of all directors, but also direct ions and therefore the users. This group can then define the architecture to imp lement. We need a goal to reach but it will certainly be preferable to proceed s tep by step to achieve this where possible, for example by network service netwo rk service ending with telnet, ftp implies a change of habit for the users. The creation and installation of filters can be made by the conductor who will commi t to react very quickly to open or close a service request from a laboratory. Th is work could eventually be divided among several people if jurisdiction exists, but with a very good coordination. The filters are powerful tools but any error s or inconsistencies can block certain network services. I recommend two article s by Sophie Nicoud (GLM Marseille) and Marie-Laure Minuissi (CNRS Sophia) cited in the references that are very concrete examples of implementation of filters o n campus. Recommendations of network architecture with filtering to improve safety - JLA CNRS / UREC 11 3.4 What followed? In conclusion, this architecture does not put you to protect from all attacks, b ut will protect you say 98% of ongoing attacks, which is not negligible. By cons

, we must remain vigilant. Regular reading of the opinion CERTs and installing p atches will maintain systems and application servers from the semi-opened in a s ecure state. It will be good to ensure regular monitoring of these servers in th e manner indicated above, but also newspapers fueled by waste packages filtered and tools such as IPtrafic. 4. References Architecture • • • • • • The campus network security GLM (Sophie Nicoud CNRS Marseille) http://www.dr12.c nrs.fr/d12/si/sr/pub/securite/secu-info-court.htm Establishment of filter input laboratory (Marie-Laure Miniussi CNRS Sophia): Controlling access to http://www. dr20.cnrs.fr/reseau_de_campus/filtres.pdf LMCP Policy and Implementation (Franci s Mauris Yves Epelboin, Laboratory of Mineralogy-Crystallography ) http://www.cs iesr.jussieu.fr/pole2/lmcp/index.htm Establishment of a firewall (Sylvaine Roy a nd Jean-Paul Eynard IBS) Proceedings JRES99 (http://www . univ-montp2.fr / ~ jre s99 /) From the firewall to network partitioning (Herve Schauer HSC): http://www .hsc.fr/ressources/presentations/jres99/jres99001.html VLAN (John- Paul Gautier CNRS UREC): http://www.urec.cnrs.fr/cours/Liaison/vlan/sld001.htm Software • • • • Tcp_wrapper: http://www.urec.cnrs.fr/securite/outils/index.html IPtrafic: http:/ /www.urec.cnrs.fr/iptrafic/ Simulation and detection, a further step in computer security ( Nicole Dausque CNRS UREC): http://www.urec.cnrs.fr/securite/articles /confRaid98.html Using simulation products intrusions (Nicole Dausque CNRS UREC) : http://www.urec. cnrs.fr/securite/articles/actes_ND_JRES99.pdf Filters • • Static filters (JL Archimbaud CNRS UREC): http://www.urec.cnrs.fr/cours/securite /commencer/3.0.0.filtres.html Dynamic Filters (Gabrielle Feltin LORIA): http://w ww.loria .com / services / info-resources / security / CBAC-JRES.html Private address • RFC1918 - Address Allocation for Private Internets: http://www.pasteur.fr/cgi-bi n/mfs/01/19xx/1918 NAT • • RFC2663 - IP Network Address Translator (NAT) Terminology and Considerations: ht tp://www.pasteur.fr/cgi-bin/mfs/01/26xx/2663 NAT scale of a university (Univ Did ier Benza Toulon): http://www.univ-tln.fr/ benza/jres99 ~ / Not to mention the servers security baseline for the academic French CRU (http:/ /www.cru.fr/Securite) and UREC (http://www.urec.cnrs.fr/securite) Recommendations of network architecture with filtering to improve safety - JLA CNRS / UREC 12