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