Composable Tools For Network Discovery and Security Analysis

Transcription

1 Composable Tools For Network Discovery ad Security Aalysis Giovai Viga Fredrik Valeur Jigyu Zhou Richard A. Kemmerer Reliable Software Group Departmet of Computer Sciece Uiversity of Califoria Sata Barbara Abstract Security aalysis should take advatage of a reliable kowledge base that cotais sematically-rich iformatio about a protected etwork. This kowledge is provided by etwork mappig tools. These tools rely o models to represet the etities of iterest, ad they leverage off etwork discovery techiques to populate the model structure with the data that is pertiet to a specific target etwork. Ufortuately, existig tools rely o icomplete data models. Networks are complex systems ad most approaches oversimplify their target models i a effort to limit the problem space. I additio, the techiques used to populate the models are limited i scope ad are difficult to exted. This paper presets NetMap, a security tool for etwork modelig, discovery, ad aalysis. NetMap relies o a comprehesive etwork model that is ot limited to a specific etwork level; it itegrates etwork iformatio throughout the layers. The model cotais iformatio about topology, ifrastructure, ad deployed services. I additio, the relatioships amog differet etities i differet layers of the model are made explicit. The modeled iformatio is maaged by usig a suite of composable etwork tools that ca determie various aspects of etwork cofiguratios through scaig techiques ad heuristics. Tools i the suite are resposible for a sigle, well-defied task. Each tool has a abstract specificatio of the iput, the output, the type of processig, ad the requiremets for carryig out a task. Tool descriptios are expressed i a Network Tool Laguage. The tool descriptios are the stored i a database. By usig the etwork model ad the tool descriptios, NetMap is able to automatically determie which tools are eeded to perform a particular complex task ad how the tools should be scheduled to obtai the requested results. Keywords: Network Security, Network Modelig ad Aalysis, Network Discovery ad Validatio.. Itroductio Network security is achieved by composig the fuctioality of a umber of security applicatios, such as firewalls ad itrusio detectio systems. Deployig ad cofigurig security applicatios requires a i-depth kowledge of the etwork to be protected. I additio, cotiuous moitorig of both the etwork ad the cofiguratio of the security applicatios is the basis for determiig the curret etwork security posture. Ufortuately, kowledge about the etwork beig protected ofte exists oly i the mid of the etwork admiistrator, ad this kowledge is obtaied by usig a umber of tools, each of which ca oly provide a subset of the iformatio about the protected etwork. For example, the iformatio about the services active o a host could be determied by scaig the ports of the host. I additio, the results obtaied from the executio of oe tool are ofte used as the basis for additioal aalysis ad possibly as iput for the executio of other tools. I the previous example, oce the ope ports have bee determied, baer-grabbig tools ca help to determie the type ad versio of the server applicatios. The coordiatio of tool executios ad the compositio of their results is usually a huma-itesive task. This is the case eve whe ad hoc scripts ad procedures developed by etwork admiistrators through years of experiece i itegratig the results of etwork moitorig ad aalysis are available. This paper presets NetMap, a ovel approach that provides support for automated etwork discovery ad security aalysis. NetMap is cetered aroud a model of both the etwork to be aalyzed ad the tools to be used for aalysis. The etwork model has bee desiged by takig ito accout the models used by existig etwork maagemet ad vulerability scaig tools. The model is ot limited to a specific etwork level; it itegrates etwork iforma-

2 tio throughout the layers. The model cotais iformatio about topology, ifrastructure, ad deployed services. I additio, the security-relevat relatioships betwee differet etities i differet layers of the model are made explicit. For example, the model icludes trust relatioships betwee cliets ad servers for specific services, as well as relatioships betwee services ad cofiguratio objects (e.g., files) used to defie the applicatio behavior. The etwork model is implemeted as a database maagemet system, called NetDB. A tool model supports the abstract descriptio of a suite of etwork discovery ad scaig tools usig a Network Tool Laguage (NTL). Each tool i the suite is resposible for a sigle, well-defied task ad has a specificatio of the iput, the output, the type of processig, ad the requiremets for carryig out a task. The tool descriptios are stored i a tool repository, called the Network Tool Database (NTDB). NetMap allows a etwork admiistrator to specify highlevel discovery/aalysis tasks i a query laguage, called NetScript. Tasks rage from pure etwork discovery, to the validatio of existig iformatio, to vulerability scaig. Give a task descriptio, a Query Processor compoet uses the tool descriptios to determie which tools are eeded to perform a particular complex task, what their schedule should be, ad how the results should be iserted ito a istace of the etwork model that represets the protected etwork. The remaider of this paper is structured as follows. Sectio 2 discusses related work o etwork models ad etwork aalysis tools ad presets a overview of the NetMap approach. Sectio 3 describes the etwork model. Sectio 4 presets the cocept of composable etwork tools. Sectio 5 discusses issues related to etwork discovery ad security aalysis. Sectio 6 presets a evaluatio of NetMap s performace. Fially, Sectio 7 describes the curret status of the NetMap system, draws some coclusios, ad outlies future work. 2. Related Work Curretly, etworks are moitored, maitaied, ad diagosed usig tools that rely o etwork protocols like the Iteret Cotrol Message Protocol (ICMP) [0] ad the Simple Network Maagemet Protocol (SNMP) [2]. Examples of these tools are HP OpeView [6], Scotty [], Brother [], ad Fremot [2]. These tools support etwork discovery tasks ad provide a meas to remotely query ad cotrol etwork devices, such as routers ad hosts. Network maagemet tools have proved to be effective i determiig etwork cofiguratio problems ad i helpig security aalysts. However, their data model ad the type of iformatio they gather is ot sufficiet to determie ad verify the security posture of a protected etwork. Thus, etwork security aalysts use vulerability scaig tools i additio to etwork maagemet tools. Vulerability scaig tools automatically perform checks o the hosts of a subetwork lookig for vulerable applicatios, miscofigured services, ad flawed operatig system versios. Examples of these tools are Nessus [8], Nmap [4], ad ISS s Iteret Scaer [7]. These tools provide differet types of fuctioality, use differet meas to retrieve iformatio about a etwork, ad store iformatio i differet formats. Table summarizes the characteristics of several popular etwork ad security aalysis tools. The table shows, for each tool, the type of fuctioality provided (ode discovery, topology discovery, service mappig, operatig system figerpritig, ad ode maagemet), ad the type of storage used for the iformatio gathered (data structures i memory, text files, or databases). The tools described above provide may useful fuctioalities but suffer from four mai limitatios:. They are limited i scope. Most of the tools address oe sigle problem (e.g., Nmap provides oly scaig capabilities). Differet aalysis domais, such as routig ad applicatio-level service cofiguratio, are ot aalyzed i a itegrated way. 2. They do ot rely o a well-defied, shared etwork model. Some tools do ot model ad store persistet data at all, others use text files that are mostly ustructured. A few rely o database maagemet systems, but the correspodig database schemas are desiged for the specific tool oly; they do ot cover features ot cosidered by the tool. I additio, these tools do ot agree o a shared model. This makes it hard to combie the results from oe tool with aother. Eve though there are ogoig efforts to stadardize a etwork maagemet model [3], the proposed stadard does ot take ito accout the applicatio-level characteristics of a etwork, which are paramout i determiig the security cofiguratio of services. 3. They are ot flexible. I most cases, it is impossible or very hard to add ew fuctioality ad aalysis techiques to a existig tool. The recet vulerabilities discovered i a umber of SNMP implemetatios [5] have brought this problem to the forefrot. I order to cope with the icreasig umber of attacks targetig SNMP agets, the agets have ofte bee disabled, which effectively prevets SNMP-based etwork tools from workig properly. Eve though the desired iformatio is accessible by other meas (e.g., by remote executio of shell scripts), the existig tools caot be easily modified to take advatage of these alterative sources of iformatio. I additio, composig ad 2

3 Product Descriptio Fuctioality Storage Node Discovery Topology Service OS Fi- Node Discovery Mappig gerprit Maage- met Nmap Port scaig Memory tool Nessus Vulerability Memory scaig tool Fremot Topology discovery tool Memory, text files Big Network Text files Brother moitor Scotty Network Maagemet Memory, text files Tool OpeView Network Maagemet Tool Database Table. Characteristics of existig etwork aalysis tools. itegratig differet tools requires the developmet of ad hoc procedures. 4. There is o automated support for tool compositio. Give a etwork aalysis or moitorig task, there is o automated support to determie what tools could be used to carry out the task or how differet tools should be composed. NetMap is a ew approach that overcomes the limits listed above. NetMap s goal is to provide a etwork aalysis tool that supports etwork discovery ad aalysis over a wide rage of etwork characteristics. NetMap relies o a well-defied etwork referece model to represet both the etities of a protected etwork ad a suite of etwork aalysis tools. Network discovery tools are used to populate the model structure with the data that is pertiet to a specific target etwork, ad the security aalysis is performed o the collected data. Ulike ay other etwork security or etwork maagemet tool, the approach preseted i this paper does ot rely o a moolithic tool suite or a fixed set of techiques. The NetMap approach relies o composable etwork tools. NetMap maitais a tool database cotaiig a toolset composed of specially built tools, COTS compoets, or specific tool features (e.g., the TCP portscaig fuctioality of Nmap). Each of the tools i the toolset is resposible for a sigle well-defied task (e.g., determiig if a host i a etwork is up or dow) ad is associated with a specificatio of the iput, the output, the type of processig, ad the requiremets for carryig out a task. The tool descriptio is expressed i a Network Tool Laguage. The tool descriptios are the stored i the Network Tool Database. Wheever data has to be retrieved to populate the etwork model or to verify its cotets, a Query Processor compoet automatically determies: what iformatio is eeded; which tools ca be used to obtai or verify the iformatio; ad how to compose the iputs ad outputs of differet tools to obtai the result. The resultig system is flexible, customizable, extesible, ad ca easily itegrate off-the-shelf tools. I additio, it provides automated support for the executio of complex tasks that require the results obtaied from several differet tools. Figure shows the high-level architecture of the system. Existig etwork tools are described usig NTL specificatios. Tool specificatios are stored i the NTDB. The Network Security Admiistrator browses the etwork iformatio cotaied i the NetDB ad may request the executio of a etwork discovery operatio by issuig a NetScript query. The query is set to the Query Processor compoet, which determies a suitable set of tools to perform the requested task o the basis of the iformatio stored i both the NetDB ad the NTDB. The tools are scheduled for executio, the actual tools are ivoked, ad evetually the results are stored i the NetDB for further aalysis. The followig sectios detail the mai compoets of the NetMap architecture. 3

4 Exteral Tools Executio Modelig Results Network Security Admiistrator Schedule NetDB NTL Specificatios Query Processor Browse NetMap Viewer NTDB NetScript Queries Figure. NetMap high-level architecture. 3. The Network Model The etwork model is a etity-relatioship descriptio of a etwork. It describes both the topology ad the service structure of the etwork. Figure 2 presets a simplified schema for the model. The etwork topology is a descriptio of the costituet compoets of the etwork ad how they are coected. The etwork model defies etities, such as iterfaces, odes, ad liks, to describe elemets of the etwork, ad uses relatioships to determie how the elemets are coected to each other. Each topology elemet has a rich set of attributes that defies the characteristics of the elemet. For example, the ode elemet is characterized by its type (e.g., a router or a workstatio), the processor architecture, type, ad speed, the maufacturer, the amout of memory ad disk storage available, its geographical locatio (e.g., buildig ad room umber), ad so o. This part of the model represets the blueprit of a etwork. The etwork model is ot limited to etwork topology; it also cotais a descriptio of the service structure provided by the hosts of a etwork. This icludes what operatig systems are istalled o the differet hosts, ad what services are available. Examples of these services are the Network File System (NFS), the Network Iformatio System (NIS), Secure Shell, FTP, ad r services. The model cotais a characterizatio of each service i terms of the etwork/trasport protocol(s) used, the access model (e.g., request/reply), the type of autheticatio (e.g., address-based, password-based, toke-based, or certificatebased), ad the level of traffic protectio (e.g., ecrypted or ot). I additio, the model explicitly represets the relatioships betwee the differet etities. For example, the model icludes trust relatioships betwee service cliets ad servers, as well as relatioships betwee services ad cofiguratio objects (e.g., files) used to defie program behavior. This structure allows oe to determie the implicit impact of a attack with respect to the whole etwork. For example, suppose that a host-based attack that allows a uauthorized user to write to a root-owed file (e.g., /etc/exports) is detected. The model cotais the iformatio that relates the target file to a specific service (i this case, the Network File System). Aalysis based o the model ca determie the overall impact of the attack. For example, suppose that cliet hosts use NFS to mout users home directories. The NFS service could be used to mout modified versios of the users eviromets extedig the compromise to may user accouts. I this case, by makig the relatioship betwee the cliet ad the server explicit it is possible to uderstad that a simple attack is actually affectig the security of all of the users of the etwork. The model is implemeted usig a relatioal database. The model explicitly addresses three differet levels: structure, view, ad status. At the structure level the model represets those objects that have a relatively log lifetime, such as topology ad services. At the status level the model represets iformatio related to the curret status of the etwork, such as etwork statistics. At the view level the model provides differet metaphors to preset the iformatio cotaied i the model to the users (or to applicatios). Curretly, two prototype views have bee implemeted; oe is based o the tkied system [9], ad a secod is accessible through a Web iterface. Both views allow the Network Security Admiistrator to browse the NetDB, update the cotaied iformatio, ad issue NetScript queries to the Query Processor compoet. 4. Composable Network Tools Network discovery ad aalysis is doe by buildig ew tools or usig tools that already exist ad combiig them to achieve the desired results. The advatage of usig existig tools is that it requires less work to implemet the mappig ad aalysis procedures. 4

5 etname IPAddr etmask Network likaddr type Iterface Part of odename ickame type subtype architecture maufacturer model locatio Node Is i Coected to Coected to Coected to Is istalled likname liktype Lik IPAddr etmask gateway ameserver Status type vedor type ame vedor versio patchlevel IPsetup Device OS m m Cliet Server Coected to Coected to ame trasport_prot sessio_prot port autheticatio traffic Service Cofiguratio type fuctio uri Resource Figure 2. Etity-relatioship schema for the etwork model. The NetMap philosophy is to perform each part of the overall etwork discovery/aalysis task with the tool best suited for the job. This works best if a tool performs oe specific task istead of implemetig may differet fuctioalities as a moolithic applicatio. A tool that is able to perform may tasks should at least have parameters that ca limit the operatio of the tool to exactly what is eeded. A example of a tool like this is Nmap [4]. Nmap performs pig scas, port scas, OS figerpritig, ad RPC scas. Nmap ca be fiely tued to suit the specific eeds of each query. NetMap provides a way to describe the characteristics of etwork tools by writig specificatios i the Network Tool Laguage. These specificatios serve as the basis for determiig which tools to ru ad how to compose their iput ad output. Each tool ca have differet costs associated with it. For istace, a cost could represet efficiecy, cofidece, or etwork badwidth usage. The purpose of the cost metrics is to provide support for selectig the most appropriate tools to aswer a particular query. Whe NetMap is give a query i the NetScript laguage, the Query Processor determies all the possible tool schedules that satisfy the query. These schedules are costructed so that they satisfy all the depedecies i the tool descriptios. If more tha oe schedule ca aswer the query, the schedule that optimizes the desired cost metrics is selected. The selected schedule is the ru. Note that the schedule that optimizes efficiecy is ot likely to be the same as the oe that optimizes cofidece. Therefore, the user queries must also specify what cost metrics are most importat. 4.. Represetig Model Etities NetScript ad NTL must agree o a commo way to refer to etities i the etwork model. A NetScript query uses these refereces to represet a desired value. NTL uses refereces to etities ad their attributes to specify the iput required by a tool ad/or the tool s output. The set of attributes of iterest is specified by usig a path ad the orgaizig the paths ito trees. A path is a list of idetifiers separated by dots, where the first idetifier is called the root, itermediate idetifiers are relatio ames, ad the last idetifier is a attribute ame. If several paths start with a commo subsequece of idetifiers they ca be combied ito a tree. The tree is formed by cocateatig the commo subsequece with a comma separated list of the remaiders eclosed i paretheses, where a remaider is the path with the commo subsequece removed. For istace, the paths iface.mac ad iface.type ca be 5

6 tool pig { ipsetup s; iput s.ipaddress; output s.status; efficiecy = 2; cofidece = 9; code{ args - -i "map -sp { if grep appears to be up. >/dev/ull ; the echo ; else echo 0; fi" tool map_portsca { ipsetup s; iput s.ipaddress; output s.services*-.(port,trasport_prot); efficiecy = 5; cofidece = 6; // The followig iput assertio is used // to limit the space of a portsca to local etworks iput_assertio ipsetup.ipaddress:iiprage(28..*.*); // The tool is oly able to sca TCP ports output_assertio service.trasport_prot:equals(tcp); code{ ssh root@host "../miit;m_portsca" Figure 3. Example of the tool defiitio sytax. combied ito the tree iface.(mac,type). Itermediate idetifiers i the tree ca be marked with set qualifiers. The valid set qualifiers are * for complete set, *- for subset, ad *+ for superset. The qualifier should occur directly after a idetifier i the path. The set qualifiers are used to map etities ad attributes of iterest ito sets of etities i the Network Model. For example, cosider ode.odeame ad ode*.odeame. The first case refers to oe ode s odeame, while the secod case refers to the set of odeames for all odes The Network Tool Laguage NetMap tools are described usig the Network Tool Laguage. A tool descriptio starts with the keyword tool. This is followed by the ame of the tool ad a tool descriptio body eclosed i curly brackets. See Figure 3 for two examples. The tool descriptio body cosists of optioal variable declaratios, a optioal iput defiitio, a output defiitio, optioal cost specificatios, optioal assertios, ad a code block. The elemets are separated with a ;. The iput ad output defiitios are the tool descriptio s most importat parts. The Query Processor eeds to kow about a tool s iput ad output to resolve tool depedecies. Before a tool ca be ru, all the iput data it eeds must be preset. If some iput data is missig a differet tool must be ru first to provide the required data. Iput ad output defiitios have similar sytax. They start with the keyword iput or output followed by a tree that cotais all the attributes that are to be defied. The root elemet is either the ame of a etity or a declared variable. I order to specify a relatio betwee the iput parameters ad the output parameters, NTL supports the declaratio of variables that ca be used as root elemets i both the iput ad output defiitio. The declaratio starts with the type of the etity to be declared followed by a variable ame. For example, i both example descriptios i Figure 3, a variable of type ipsetup is declared ad the used i both the iput ad output defiitio. The sytax for cost specificatios is costame = value, where value is relative to a specified rage. Differet cost metrics may be associated with differet rages. The sytax for a code block starts with the keyword code followed by the code to be executed eclosed i curly brackets. The code represets the set of actios to be executed to carry out the tool s task. There are tool assertios for both iput data ad for output data. A assertio is oly i effect whe the tool i questio is ru. The iput assertio, itroduced by the iput assertio keyword, is used to require that the tool is ru oly usig iput etities that have some special attributes. For example, a tool that checks a particular web server feature eeds a web server to be preset o the target host. Some tools ca also be depedet o the target computer ruig a specific operatig system. The output assertio, itroduced by the keyword output assertio, is used to filter uwated excess data from the output of a tool. Output assertios are also used by the Query Processor i the schedulig process. If some tools are oly capable of scaig a limited value set, the the scheduler ca combie the tools i order to cover the whole value domai. The Query Processor does ot support this feature i the curret implemetatio. For both types of assertios, the iitial keyword is followed by a attribute referece, a :, ad the assertio. The attribute referece is of the form etity ame.attribute ame. The format of the costrait specificatio is depedet o the type of assertio. I order for a tool s code to gai access to the assertios ad their costrait specificatios, assertio hooks are provided. A assertio hook ca appear aywhere withi a code block. It starts with the character sequece #ASRT ad eds at the first followig #. The body of the hook is composed of tokes separated by :. The tokes specify 6

7 query odesca(iprage) { result ipsetup*.ipaddress; assertio ipsetup.ipaddress:iiprage(iprage); cofidece 2; efficecy ; code { <.. Code to process the result..> query portsca(iprage, portrage) { result ipsetup*.(ipaddress, services*.(port, trasport_prot, ame)); assertio ipsetup.ipaddress:iiprage(iprage); assertio service.port:irage(portrage); code { <.. Code to process the result..> Figure 4. Example of the query sytax. the assertio of iterest, the attribute of iterest, ad other parameters that allow a tool to use the costrait iformatio at executio time. The pig tool i Figure 3 declares a variable of type ipsetup, which is used as the root i the iput ad output defiitios. The tool takes a IP address as iput ad outputs a status flag. A o-ull value for this flag meas that the host is aswerig ICMP echo messages. A cofidece cost of 2 ad efficiecy cost of 9 is specified. The code rus Nmap i pig sca mode. The map portsca tool i Figure 3 takes a IP address as iput ad returs a list of port,trasport prot tuples represetig the services related to the IP address. The code block specifies that a commad should be executed o a remote host to do the scaig The NetScript Query Laguage Queries are a way of issuig commads to NetMap to start the discovery of the parts of the etwork that oe is iterested i. A NetScript query specifies the etwork attributes of iterest, the rage of values they ca have, ad what to do with the result. See Figure 4 for two examples of the NetScript sytax. A query defiitio starts with the keyword query followed by the ame of the query ad a comma separated list of parameter ames i parethesis. This is followed by the body of the query i curly brackets. The query body cosists of a result specificatio, assertios, cost weights, ad a code block. The result specificatio ad the code block have the same format as i the NTL tool descriptios. The result specificatio is the oly madatory part. Assertios start with the keyword assertio. The rest of the sytax is the same as for NTL tool assertios. The sytax of cost weights are the costame, a whitespace, ad a weight. The statemet is termiated by a ;. The result specificatio idetifies which attributes are of iterest. The assertios set a limit o the value the attributes ca have. Assertios ca, for istace, costrai a query to a subet. The cost weights state how importat each cost is whe decidig which tools to use. NetMap curretly supports two differet classes of costs depedig o how the total cost is calculated. Oe class uses the sum of all costs as the total, while the other uses the miimum value. The sum type is appropriate for a efficiecy cost, while the miimum type would be used for a cofidece cost. The code block is ru after the query is fiished. The purpose of the code block is to process the result. The odesca query i Figure 4 takes oe parameter as iput. The iput defiitio asks for a rage of IP addresses. The assertio limits the rage of IP addresses that is scaed to the parameter passed to the query. The cost statemets specify that cofidece is twice as importat as efficiecy. The secod example query asks for a rage of IP addresses ad the related services port umbers, trasport protocols, ad service ames. The two assertios limit the IP addresses ad the ports that are scaed to the parameters passed to the query. 5. Maagig Network Iformatio After havig successfully ru the tools, the Query Processor stores the query result i the NetDB database. Oe of the problems that might occur is that the data received from the tools is icosistet ad/or icomplete. The Query Processor uses a ormalizatio procedure to geerate a cosistet view of the etwork from the curret cotet of the database. 5.. Resolvig Icosistecies The most commo icosistecy problem is the hadlig of so-called ghost etries. A ghost etry is preset whe more tha oe of the stored istaces represet the same etwork object. This ofte happes whe tools retur istaces with few or o attributes. I this case, the Query Processor caot immediately tell if these istaces were previously stored or ot; therefore, ambiguities must be resolved by post processig the data. Costraits offer a way to determie if two etity istaces represet the same etwork object or ot. A uique costrait o a attribute meas that the attribute uiquely idetifies the etity istace, similar to keys i a database 7

8 Ipsetup Iterface CS Ipaddr: Netmask: Ipsetup Ipaddr: Iterface Ipsetup Ipaddr: Netmask: Iterface Ipsetup Normalize CS Ipsetup Ipaddr: Netmask: Netmask: Figure 5. Example of the complete set costrait. table. Note that the Query Processor allows the NetDB to be i a semi-icosistet state, where more tha oe etity istace may have the same uique attribute value. This icosistecy is resolved durig the ormalizatio of the database, whe all istaces that have the same uique attribute value are merged. The cardiality costraits o the relatios i the etwork model ca also be used whe resolvig ghost etries. Cosider a relatio that has a :N costrait. If the data stored i the NetDB actually implemets a M:N relatio, the the Query Processor ca ifer that all the etity istaces o the left side of the relatio are ghost etries. This icosistecy ca the be resolved by mergig all istaces o the left side of the relatio. Aother useful costrait is the complete set costrait. A relatio istace is marked as a complete set if it is kow that o more etity istaces ca take part i that relatio. If other related etities exist, the they are ghost etities ad should be merged with the complete set. As a example of the use of a complete set costrait, cosider the iterface ad ipsetup etities from the NetDB schema of Figure 2. Figure 5 shows a graphical represetatio of a example iput to the ormalizatio algorithm ad the result. The dashed lie betwee the two iterface elemets symbolizes that the two iterface istaces show are the same. The CS ext to two of the relatios deotes that the relatio is a complete set. The ormalizatio algorithm detects that there exists oe ipsetup istace that is ot part of the complete set. Because of the complete set costrait, the ipsetup etity must be a ghost etry of oe of the ipsetups i the complete set. The etmask attribute of the ghost etry ad the first ipsetup i the complete set differ. This meas they caot represet the same object. The oly possible solutio is that the ghost etry ad the secod ipsetup are the same ad should be merged. The result of the algorithm is show i the right side of Figure Network Security Aalysis After the NetDB database is populated with up-to-date etwork iformatio, a comprehesive security aalysis ca be performed. The output of the aalysis may either be a report of the curret state of the etwork or cofiguratio data to be used with some security compoet, such as a firewall or a itrusio detectio system. Curretly, two prototype aalyzers have bee developed. The first, a firewall cofigurator, uses the cliet-server relatioship expressed i the etwork model to create a list of valid cliets for each service. The list ca be used by the firewall to block uauthorized cliets from accessig sesitive services. Eve if a malicious user were able to chage the access cotrol list of the service itself, he would ot be able to gai ay access, sice the firewall would block ay coectio attempt. The secod aalyzer lists all the hosts i the etwork with a give operatig system that have a specific service istalled. This iformatio is used whe a etwork admiistrator eeds to decide which hosts are affected by a ew security vulerability ad eed patchig. Without a database of all istalled services i the etwork, this iformatio would have to be collected by some ad hoc scaig tool. The costructio of this tool would be time cosumig, ad the results would likely be error-proe due to the ad hoc ature of the tool. 6. Evaluatio NetMap s fuctioality ad performace have bee tested o both simulated ad real etworks. The real etworks that have bee scaed are subets i the Computer Sciece Departmet at UCSB. The tests o these real etworks were performed to check whether NetMap is able to map ad aalyze a etwork correctly. The tests also gave iformatio about how log the discovery process takes. The tests performed o the simulated etwork made it possible to use more complicated etwork topologies. 8

9 query local() { result ipsetup*.(ipaddress,services*.(port,trasport_prot)); assertio ipsetup.ipaddress:iiprage( *); query local2() { result ode*.(hostame,iterfaces*.(mac,ipsetups*.(ipaddress,services*.(port,trasport_prot)))); assertio ipsetup.ipaddress:iiprage( *); query departmet() { result ode*.(hostame,iterfaces*.(mac,ipsetups*.(ipaddress,services*.(port,trasport_prot)))); assertio ipsetup.ipaddress:iiprage( *); query departmet2() { result ode*.(iterfaces*.(ipsetups*.(etmask,ipaddress),lik.etwork.etumber)); assertio ipsetup.ipaddress:iiprage( *); Figure 6. Test queries used i the real etwork tests, expressed i NTL. Whe usig NetMap o the UCSB etworks, the four test queries show i Figure 6 were used. Two queries were ru o the local class C etwork i the Reliable Software Lab (RSL), ad two queries were ru o four subets i the Computer Sciece Departmet. The RSL etwork is coected by a switch, ad the other subets used i the tests have a similar topology. A router coects the differet subets. For the performace test 26 hosts i the RSL were used, ad 22 hosts were used for the fuctioality tests. 6.. Performace Test The performace test focuses o how much time NetMap requires for a give task ad how much overhead NetMap itroduces. The test case is the local query i Figure 6, which is a query of all the ope ports i the RSL. I Figure 7, we compare the time required for these differet methods. The first ru is performed by usig a shell script to perform a pig sca followed by a sequetial port sca. The other two rus are performed by NetMap. I the NetMap sequetial ru, the port sca is also performed sequetially for all the iput values. While i the parallel ru, the umber of executio threads for port sca was set to 0. The NetMap sequetial ru ad the shell script ru take approximately the same time, which idicates that NetMap imposes very little overhead o the processig. The timig break dow is discussed further i Sectio 6.2. The parallel ru reduces the total time from about four hours to about half a hour, which is a factor of eight. All three rus fid all the hosts i the etwork. The umbers of ope ports, however, are slightly differet. This is because a port may be opeed or closed durig the differet test rus. The reaso that the sca took such a log time is that most hosts i the RSL are ruig local firewalls, which usually takes about 20 miutes per host to sca, while computers without a firewall usually ca be scaed withi 0 secods. The fact that most of the port sca time is waitig for I/O is crucial for the parallel ru. The data shows that the CPU usage is uder five percet, eve i the case of te parallel port scas. For this reaso, 5 threads were used for port ad OS scas i the fuctioality tests Fuctioality Test The fuctioality test cases are show i Figure 6. The first test is a query for all the ope ports i the RSL. The secod query is for OS ame, hostame, mac address, ad all ope ports o the hosts i the RSL. The third query asks for the same data from four subets. The last query is for IP address, etmask, ad etwork from the same subets. The tools used i the test were: Pig Fids hosts that are up by issuig a ICMP echo message ad listeig for a ICMP echo-reply. Implemeted usig Nmap i pig sca mode. NetARP Returs the ARP cache of a host give its IP address. Nslookup Does a reverse DNS lookup o a IP address. Osdetect Performs OS figerpritig by sedig various packets to the host ad matchig the result agaist a database of OS s TCP/IP profiles. Implemeted as Nmap i OS detect mode. Portsca Tries to coect to a rage of ports o a give IP address. Implemeted as Nmap i port sca mode. ICMP etmask Fids the etmask of a ipsetup by sedig a ICMP etmask request to the IP address. Netfid Takes the IP address ad etmask of a ipsetup as iput ad returs a etwork IP address. The etwork IP address is the IP address ANDed with the et- 9

10 Testame # of Host # of ope ports Time Shell Script :29 NetMap Sequetial :59 NetMap Parallel :33 Figure 7. Performace testig of local etwork. Times are expressed i miutes ad secods. mask. This tool does ot do ay active discovery. Implemeted as a shell script. Figure 8 cotais the tool schedule chose for each query, ad the ruig time for each tool. The total colum i the table shows the time it took to ru the whole query. The processig time is the total time mius the sum of the tool times. This is the time NetMap uses to ormalize the data ad isert it ito the NetDB. I both of the local tests all the collected data was correct. NetMap was also able to discover most of the attributes queried. There were some problems detectig the OSs of some of the hosts (i.e., 7 out of 22 hosts did ot get a OS mappig). The reaso for this problem is that all the Liux boxes i the RSL ru local firewalls. This prevets the OS discovery tool from figerpritig the hosts. I the first departmet sca, a higher percetage of the OSs were figerprited successfully compared to the local sca (7 out of 78 did ot get a mappig). These were the same hosts as i the local test. The secod departmet sca was performed to determie if NetMap is able to group the scaed hosts ito subets. 46 out of 77 hosts got their etmask attribute detected ad were successfully assiged to the correct etwork. The hosts that failed the etmask detectio were ot assiged to ay etwork. However, these 3 hosts ca be correctly assiged to the etwork by usig the logest prefix match with kow etwork addresses. The secod departmet sca was ot performed the same day as the first oe, which explais the differece i the umber of IP addresses. By comparig the ru times for the local ad the first departmet sca oe fids that the pig, NetARP, ad slookup ru times icrease approximately liearly with the umber of hosts. The OS detect ad port sca times do ot icrease much at all, while NetMap processig time icreases cosiderably. 7. Coclusios ad Future Work This paper described the NetMap approach ad the characteristics of the implemetatio of the first prototype. A iitial etwork model has bee desiged by aalyzig existig models used by etwork maagemet, discovery, ad aalysis tools. A database-cetered applicatio, called NetDB, has bee implemeted to store a ivetory of etwork objects coformig to the model, ad two GUIs for browsig the database have bee developed. The database is populated by usig composable etwork tools. The Network Tool Laguage has bee defied to describe the tools i a abstract way. A laguage to describe etwork discovery tasks, called NetScript has also bee defied. A prototype Query Processor compoet has bee implemeted. The Query Processor takes a NetScript task specificatio as iput ad produces a schedule of tool executios that will produce the desired results. It the executes each of the tools i the schedule ad stores the result ito the NetDB. I additio, a prelimiary set of algorithms to deal with the reductio of icosistet ad/or redudat iformatio has bee desiged ad implemeted. Tests have bee performed to show that the implemetatio is capable of mappig etwork topology iformatio, discover service cofiguratios, ad perform security aalysis. The tests also showed that icosistecies ca be resolved. I order to perform the tests, a umber of tools were itegrated ito NetMap. The amout of work eeded to do this was miimal, which supports the claim that NetMap ca be easily exteded. Give more tools, it should be possible to map every feature of the etwork that is iterestig from a security poit of view. Future work will focus o extedig the curret set of tool descriptios, improvig the reductio algorithms, ad usig NetMap as the basis for itrusio detectio. To be more specific, we pla to validate the flexibility of the Network Tool Laguage by describig a wide rage of tools. By doig this the expressive power of the laguage as well as the overall itegratio power of the approach will be thoroughly tested. We also pla to perform additioal aalysis o the reductio algorithms that have bee developed to deal with icosistet ad duplicated iformatio. Fially, NetMap will be used to support a ew approach to detectig attacks, called the status-based approach. The status-based approach idetifies attacks by aalyzig the differeces betwee the iteded etwork status as specified by the model ad the actual etwork status as detected by the moitorig tools. This approach is similar to aomaly detectio approaches. A status-based IDS does ot rely o statistical models to represet the correct behavior of the system; therefore, it does ot eed to be traied over a log period of time. Furthermore, it ca be used i highly 0

11 Testame Pig NetArp Nslookup Osdetect Portsca Total Processig # IPs local : :2 25:32 :04 22 local2 :06 :7 :07 26:42 25:20 52:40 :08 22 departmet :22 :47 :49 30:5 25:48 60:42 2:25 82 Testame Pig icmp etmask etfid Total Processig # IPs departmet2 :9 :34 :38 :36 :05 77 Figure 8. Results of the real world tests. Times are expressed i miutes ad secods. dyamic iformatio systems where a well-defied patter of usage caot be determied. Ackowledgmets This research was supported by the Army Research Office, uder agreemet DAAD ad by the Defese Advaced Research Projects Agecy (DARPA) ad Rome Laboratory, Air Force Materiel Commad, USAF, uder agreemet umber F The U.S. Govermet is authorized to reproduce ad distribute reprits for Govermetal purposes otwithstadig ay copyright aotatio thereo. The views ad coclusios cotaied herei are those of the authors ad should ot be iterpreted as ecessarily represetig the official policies or edorsemets, either expressed or implied, of the Army Research Office, the Defese Advaced Research Projects Agecy (DARPA), Rome Laboratory, or the U.S. Govermet. [0] J. Postel. Iteret Cotrol Message Protocol. RFC 792, 98. [] J. Schowalder ad H. Lagedorfer. Tcl Extesios for Network Maagemet Applicatios. I Proc. 3rd Tcl/Tk Workshop, Toroto (Caada), July 995. [2] D. Wood, S. Colema, ad M. Schwartz. Fremot, A System for Discoverig Network Characteristics ad Problems. I Proceddigs of the USENIX Coferece, pages , Jauary 993. Refereces [] Big brother system ad etwork moitor homepage. http: //bb4.com/, [2] J. Case, K. McCloghrie, M. Rose, ad S. Waldbusser. Protocol operatios for versio 2 of the simple etwork maagemet protocol (SNMPv2). Iteret Egieerig Task Force (IETF), RFC 905, Jauary 996. [3] D. M. T. Force. Commo Iformatio Model (CIM) Core Model. White Paper, August org. [4] Fyodor. Nmap the etwork mapper. isecure.org/map/, [5] O. Group. PROTOS Test-Suite: c06-smpv. February [6] Hewlett Packard. Maagig Your Network with HP Ope- View Network Node Maager, Jauary Maufacturig Part Number: J [7] Iteret Security Systems. Iteret Scaer, http: // [8] Nessus homepage [9] M. Newham. Gettig Started with Tkied, Jauary schoew/scotty/docs/getstart.html.