ee 590 – linux routers spring 2002bdu/ee590t1.pdf · internet’s speed and technology. network...

EE 590 – Linux Routers Spring 2002

Final Project Final Project Final Project Final Project ---- Network Security tools

nTOP, Saint, and Sara

To: Juris ReinfeldsJuris ReinfeldsJuris ReinfeldsJuris Reinfelds

From: TEAM #1TEAM #1TEAM #1TEAM #1

Bo DuBo DuBo DuBo Du Juan RubioJuan RubioJuan RubioJuan Rubio

Victor RubioVictor RubioVictor RubioVictor Rubio Daniel CarbajalDaniel CarbajalDaniel CarbajalDaniel Carbajal

Date Due: May 9, 2002 Date Submitted: May 9, 2002

EE 590 – Linux Routers Final Project – Team #1

Table of Contents TABLE OF CONTENTS.............................................................................................................. 2

ABSTRACT ................................................................................................................................... 4

INTRODUCTION......................................................................................................................... 4

RESEARCH................................................................................................................................... 4 Security Administrator’s Integrated Network Tool aka SAINT .............................................. 4 Download, Installation, and Running of SAINT ..................................................................... 5 Setting Up a Scan with SAINT ................................................................................................ 5 Analyzing the Results with SAINT........................................................................................... 5 Problems with SAINT.............................................................................................................. 6 Security Auditor’s Research Assistant (SARA) ....................................................................... 6 SARA Installation .................................................................................................................... 6 Ntop ......................................................................................................................................... 7 Running nTop .......................................................................................................................... 7

EXPERIMENTAL PROCEDURE.............................................................................................. 8 SAINT and SARA..................................................................................................................... 8 nTOP ....................................................................................................................................... 9

EXPERIMENTAL RESULTS................................................................................................... 10 SAINT .................................................................................................................................... 10 SARA...................................................................................................................................... 11 Ntop ....................................................................................................................................... 11

NETWORK TOOLS ASSESSMENT ....................................................................................... 12 SAINT .................................................................................................................................... 12 SARA...................................................................................................................................... 12 nTOP ..................................................................................................................................... 12

CONCLUSION............................................................................................................................ 12

REFERENCES............................................................................................................................ 13 Appendix 1: SAINT - saint.html ................................................................................................... 14 Appendix 2: SAINT - Data Management ..................................................................................... 15 Appendix 3: SAINT - Target Selection......................................................................................... 16 Appendix 4: SAINT - Data Collection.......................................................................................... 17 Appendix 5: SAINT - Data Collection (continued) ...................................................................... 18 Appendix 6: SAINT - Data Analysis ............................................................................................ 19 Appendix 7: SAINT - Data Analysis – Vulnerabilities – Danger Levels ..................................... 20 Appendix 7: SAINT - Data Analysis – Vulnerabilities – Danger Levels (cont’d) ....................... 21 Appendix 7: SAINT - Data Analysis – Vulnerabilities – Danger Levels (cont’d) ....................... 22 Appendix 8: SAINT - Data Analysis – Vulnerabilities – By Type............................................... 23 Appendix 9: SAINT - Data Analysis – Vulnerabilities – By Counts ........................................... 24 Appendix 10: SAINT - Data Analysis – Host Information – by Class of Service........................ 25 Appendix 11: SAINT - Data Analysis – Host Information – by System Type............................. 26 Appendix 12: SAINT - Data Analysis – Host Information – by Internet Domain ....................... 27


Appendix 13: SAINT - Data Analysis – Host Information – by Subnet....................................... 28 Appendix 14: SAINT - Data Analysis – Host Information – by Host Name................................ 29 Appendix 15: SAINT - SAINTwriter – Configuration Management ........................................... 30 Appendix 16: SAINT - SAINTwriter – Report............................................................................. 31 Appendix 16: SAINT - SAINTwriter – Report (cont’d)............................................................... 32 Appendix 16: SAINT - SAINTwriter – Report (cont’d)............................................................... 33 Appendix 16: SAINT - SAINTwriter – Report (cont’d)............................................................... 35 Appendix 16: SAINT - SAINTwriter – Report (con’d)................................................................ 36 Appendix 16: SAINT - SAINTwriter – Report (cont’d)............................................................... 37 Appendix 16: SAINT - SAINTwriter – Report (cont’d)............................................................... 38 Appendix 16: SAINT - SAINTwriter – Report (cont’d)............................................................... 39 Appendix 16: SAINT - SAINTwriter – Report (cont’d)............................................................... 40 Appendix 16: SAINT - SAINTwriter – Report (cont’d)............................................................... 41 Appendix 17: SARA - Scanning result form host 128.123.9.210 (SuSE 7.2) .............................. 42 Appendix 17: SARA - Scanning result form host 128.123.9.210 (SuSE 7.2) cont’d ................... 42 Appendix 18: SARA - Scanning result from host puppy.cs.nmsu.edu (Windows 2000) ............. 44 Appendix 19: SARA - Scanning result from host puppy.cs.nmsu.edu (Windows 2000) ............. 45 Appendix 20: SARA - Reports on host 128.123.9.210................................................................. 46 Appendix 21: SARA - Scanning Result of host pedro.nmsu.edu ................................................. 47 Appendix 22: SARA - Reports on host pedro.nmsu.edu .............................................................. 48 Appendix 23: SARA – Different Report on host pedro.nmsu.edu................................................ 49 Appendix 24: nTOP – setup .......................................................................................................... 50 Appendix 25: nTOP – Web Interface............................................................................................ 51 Appendix 26: nTOP – Host Information....................................................................................... 52


Abstract Internet security has become increasingly essential with today’s rapid evolvement of the Internet’s speed and technology. Network administrators’ have to be constantly staying ahead of hackers and the computer attacks that come with them. This paper covers three of todays most popular security tools. Today there are hundreds, even thousands of network security tools that an administrator can use to monitor a network. On the other hand, these tools are also available for attackers, and since the speed of the Internet is still a primary concern, it is essential that these network security tools won’t ‘slow’ down a network. While, there are many security tools, most of these tools fall under two categories: ‘scanning’ tools and ‘sniffing’ tools. Scanning tools essentially scan or ‘attack’ a network to help a network administrator detect vulnerabilities within a network before an attacker exposes it. Sniffing tools are primarily used to monitor the network and detect attacks on the network. Two of the network tools covered in this paper (SAINT, SARA) are scanning tools, while nTop is researched as an intrusion detection (‘sniffing’) tool Introduction Today’s world offers high tech computers and products that make browsing the Internet fast and easy to accomplish. However, in the changing world of technology and due to the fast growth of the Internet, security is becoming a very big issue. Today a person can access data of their bank accounts, credit cards, and send large program files by using the Internet. Large companies and corporations have large storage databases and accounts that can be used in transactions from anywhere around the world. So the question is who is authorized to view all of this information? New technologies are being developed to prevent unauthorized people entry into networks or accounts. This report focuses on three of the network security tools that have evolved from the growing demand for security. Research Security Administrator’s Integrated Network Tool aka SAINT By: Victor Rubio One of the network security tools we choose to evaluate was the program Security Administrator’s Integrated Network Tool aka SAINT. SAINT is a program that aids the system or security network administrator in auditing their network. It should also be noted that SAINT is being developed by SAINT Corporation and was a derived work of SATAN, which now includes many enhancements to the original. “In its simplest mode, it gathers as much information about remote hosts and networks as possible by examining such network services as finger, NFS, NIS, ftp and tftp, rexd, statd, and other services.”[2] To check all the vulnerabilities SAINT checks for go to http://www.saintcorporation.com/cgi-bin/vulns.pl for a list and explanation of each. SAINT has also been certified to detect the SANS Top 20 Internet Security Threats (http://www.sans.org/top20.htm). The information gathered shows the services being used by each system and any possible security flaws. The information can then analyzed through an HTML browser such as Netscape. There is even an add-on called SAINTwriter (http://www.saintcorporation.com/saintwriter/index.html) that writes reports from the data gathered. The goal for our project was to run SAINT against the Network Teaching Lab Network, a host system on Team #1 sub-subnet work 128.123.9.208/26, and attack a system outside of network but on the NMSU domain.


Download, Installation, and Running of SAINT We went to the SAINT Homepage http://www.saintcorporation.com/saint/index.html and found out that there was a full version of SAINT for $1800 and a free version. We opted for the free version of which we obtained SAINT version 3.4.8 from the http://www.saintcorporation.com/saint/downloads/ website. Using “root” we download the .tar file to the /usr/local directory and untared the file. Next we changed directory’s to /usr/local/saint-3.4.8/ and were ready to install SAINT by running the following commands from the UNIX command prompt: #/usr/local/saint-3.4.8>./configure #/usr/local/saint-3.4.8>make #/usr/local/saint-3.4.8>make install Once SAINT is installed if you change directories to “/usr/local/saint-3.4.8>” and run “./saint” form the command prompt, SAINT will come up. Note is recommended from the SAINT website to run SAINT as “root!” Once Netscape comes up you should see a window as seen in Appendix A: SAINT – saint.html. Setting Up a Scan with SAINT After running SAINT, we want to setup a file to save our data. To do that click on the “Data Mgmt.” button to the left of the screen. See Appendix B: SAINT – Data Management. This screen allows us to open an existing database, create a new database or merge a database. It is high suggested that if you create a new database file for you scan to name the database appropriately with the network you scanned and maybe the date. For now we’ll stick with the default database “saint-data.” Next you want to click on the “Target Selection” button to the left of the screen. See Appendix C: SAINT – Target Selection. Here we select what host(s) or network we would scan, select the scanning level, select if SAINT should perform dangerous test and select if SAINT needs Firewall support. Under the scanning level you can choose how hard to scan the host: light, normal, heavy, heavy +, top 20 or custom. If you know that your host is behind a firewall, check for firewall support. This is to insure that the results will be as accurate as possible. For now we’ll keep the default setting, except for putting 128.123.9.199 or ee590group1.nmsu.edu as the host to scan. To start scanning, click the “Start the Scan” button towards the bottom of the screen. If the scan successfully started you should see a screen like Appendix D: SAINT – Data Collection. Analyzing the Results with SAINT Once the scan has completed, you can click on the “Data Analysis” button to the left of the screen. See Appendix E: SAINT – Data Analysis. Here we can analyze the data by vulnerabilities, by host information, or by trust. Each of which is shown categorized by different options. For example you can view the vulnerabilities categorized by approximate danger level, by vulnerability type, or by vulnerability count. One you click on one, you’ll see what vulnerabilities SAINT found. The results show find a description of each vulnerability, a Common Vulnerability Exposure (CVE) number and CERT advisories, and a suggestion for possible solutions. For ease you can even download a SAINT add-on report writer called SAINTwriter. For screen shots see:

Appendix 6: SAINT - Data Analysis Appendix 7: SAINT - Data Analysis – Vulnerabilities – Danger Levels


Apendix 7: SAINT - Data Analysis – Vulnerabilities – Danger Levels (cont’d) Appendix 7: SAINT - Data Analysis – Vulnerabilities – Danger Levels (cont’d) Appendix 8: SAINT - Data Analysis – Vulnerabilities – By Type Appendix 9: SAINT - Data Analysis – Vulnerabilities – By Counts Appendix 10: SAINT - Data Analysis – Host Information – by Class of Service Appendix 11: SAINT - Data Analysis – Host Information – by System Type Appendix 12: SAINT - Data Analysis – Host Information – by Internet Domain Appendix 13: SAINT - Data Analysis – Host Information – by Subnet Appendix 14: SAINT - Data Analysis – Host Information – by Host Name Appendix 15: SAINT - SAINTwriter – Configuration Management Appendix 16: SAINT - SAINTwriter – Report

Problems with SAINT Once we first installed and compiled SAINT, initially the program would not bring up Netscape, which is a crucial part of SAINT. After some investigation of what the configuration scripts were doing, Bo wrote the “/bin/netscape” script so that it would properly load Netscape version 6.0. After we got SAINT to come up, we found out that Netscape would just come up to “default” page instead of opening up to the SAINT interface. To fix this we made the “/usr/local/saint-3.4.8/html/saint.html” file the default page on our Netscape browser. Another annoying problem we discovered was that we had to be in the “/usr/local/saint-3.4.8>” director in order to run SAINT, we couldn’t just run “./saint” from any location. The last bug we found with SAINT was when we started analyzing our data, each system showed its vulnerabilities as a hyperlink. Well all the links were broken and in order to get the web page we had to search for it through the Netscape Search engine. On a side note we’d like to mention that SAINTwriter demo version reports on up to three hosts. After reading up some more on SAINT, it was determined that while SAINT runs on most flavors of UNIX, it hadn’t been tested and approved for SuSE Linux. Security Auditor’s Research Assistant (SARA) By: Bo Du SARA was developed by the original author of SAINT, Bob Todd. When he joined Advanced Research in early 1999 and has been working to evolve SATAN and original SAINT concept to community-oriented product, the new Security Auditor’s Research Assistant (SARA)[1]. One goal of our project is to run SARA against the hosts in the Network Lab and some other machines in the NMSU domain to find all possible vulnerabilities. SARA Installation The source code of SARA was downloaded from the official website [1] and was installed on our machine 128.123.9.199. The installation follows the standard software installation procedure on UNIX. No more extra configurations are needed. By default, the SARA will be set into the directory /usr/local/sara-3.5.5/. After installation, login as root and go to the SARA directory, type “./sara” to run it. A good feature of SARA is that it will automatically call the default web browser on the machine thus provides the user a graphic environment to operate SARA. User can use a Netscape to specify


the target host for scanning, view the result in a HTML format and print a paper report by just clicking a button. Ntop By: Daniel Carbajal NTop was originally designed as a traffic managing application. It is based of the Unix command ‘top’, which shows network usage. Since nTop was originally designed around traffic management, it was used to recognized specific traffic patterns, which included recognizing specific attacks. In order to better address this issue, the authors, Luca Deri and Stefano Suin, decided to add a Network Intrusion Detection System (NDIS) to nTop (Deri, 1999). Unlike SAINT and SARA, which are considered to be sniffer tools, nTop is considered to be a packet sniffer (i.e., ethereal). It gives more of a mapping of the network and gives the ability to sort packets by various protocols. Since nTop has the knowledge of the network traffic and usage from two of the other tasks it performs, it makes if possible to provide a security system that is simple to implement in comparison to other Intrusion Detection Systems (IDSs). For example, if an unknown user wants to capture packets from a host on the network, he will send an ICMP redirect message to that host. The ICMP redirect message is only allowed to be sent to a host by the default router. NTop can detect this by implementing one simple rule. NTop can then sound an alarm either by setting a flag, emailing the administrator, or other specified methods that the administrator implements, whenever this happens. However, nTop security rules can also be implemented so that no DOS (Denial of Service) flood occurs. A DOS flood can occur when an attacker sends multiple messages packets , and this cause nTop or another IDS to detect it. An alarm will be transmitted for every packet. If an attacker sends many (even millions) of these packets then the IDS system itself will flood the host which will cause a network failure itself. NTop rules can be easily written to detect these attacks but only report an attack once , and then after a specified period of time if the attack continues. A time of 60 or 90 seconds can usually be used or even more if the administrator desires. In our experiment, we created rules to try and detect intrusions on the network including those conducted by SAINT and SARA. Running nTop Ntop is a common network tool (i.e., ping, tcpdump, etc.) available with most current Unix systems. However, the satellite machine from which nTop was run did not have this tool available. Since nTop is an open-source application, we downloaded a free copy from http://www-serra.unipi.it/~ntop/ntop.html. The software package came in an rpm (binary ) file named: ntop.rpm. From the command prompt at the ‘xterm’ window in our machine, the command : rpm ntop.rpm was typed and nTop was ready to run. From this we found that RPM is the RPM Package Manager, which is a software package tool that allows ‘users to take source code for new software and package it into source and binary form such that binaries can be easily installed and tracked and source can be rebuilt easily. ‘ (Barnes,1999) This was much easier than having to use the gunzip and tar commands that were required to install SAINT and SARA. Ntop can be used in the script mode, in which all data is logged into a file called ntop.log, or by using a web-browser. We found that using the web browser, allows the user to see a clearer picture of the network analysis that nTop performs. To run nTop in script mode the command: ntop is all that is required. This will cause nTop to run as a daemon collecting all network


information and the user will be unable to read the data until nTop is stopped. To run nTop on as a web-based application you can type the following command: ntop -w 80 –W443 which tells ntop to run and collect data using port 80 (http port) or port 443 (secure http). The ‘xterm’ window will display the data stating the processes that Ntop is running such as those seen in Appendix A. The parameters –l 10 and –r 10 are used to tell the nTop application how long to wait before updating data. In this case the time was set to 10( which is measured in seconds). The parameter –R filter.rules is used to tell the nTop Network Intrusion Detection System to apply the network security rules listed in the file filter.rules. This file will be discussed in more detail in the next section. Ntop may also be viewed on a web-browser by opening it on an unused port (port 3000 is used by default). However, this is for remote browsing, which allows any user who knows the address of the machine and the port nTop is running on, to view all information that is gathered by nTop. This can be a vulnerability, as it allows a user to view more information that he maybe able to see if he were just scanning the machine. The final command used to run nTop was: ntop –w 3000 – W443 –l 10 –r 10 –R filter.rules. Once nTop is running, the user can then open a web-browser, such as Netscape and type the address of the machine on which nTop is running ( in our case 128.123.9.210) and the graphic interface for nTop will appear. You can view various traffic management tools that nTop has to offer. In Appendix B, nTop is showing the traffic that is being seen on the network by the machine 128.123.9.210. Due to using –w 3000 the address that must be typed in the URL window on the web-browser is 128.123.9.210:3000 to indicate that we want to view what is running on port 3000 of the machine 128.123.9.210. Experimental Procedure This experiment divides into three parts. The first part consists of researching the three security network tools (SAINT,SARA,nTop), and downloading and implementing each of the software tools. The second part will be to research and explore the functions that each network tool has to offer. From this we will develop an experiment to test the security of the Network Lab subnet and then that of our own sub-subnet that is inside this lab. Finally we will devise an experiment that will try to find vulnerabilities of a network form an outside source. In our case, we will use our machine (128.123.9.199/26) as the outside source, and we will try to find vulnerabilities in our subnet and an outside host in the Computer Science department called puppy.cs.nmsu.edu. We will be running nTop from each of these hosts and try to detect when they are being attacked (‘scanned’) by one to the scanner programs (SAINT and SARA). SAINT and SARA In our experiment with SAINT and SARA, we selected 4 target machines. 2 from the network lab running SuSE 7.2, 2 computers from CS Department, one is running Solaris and the other is running in a dual mode (Windows2000/RedHat Linux 7.1). Since these machines are all in the NMSU domain, we assume they are in a same LAN thus we selected to use the “no firewall support” option to save the experiment time. We did heavy scans on all these machines which SAINT and SARA will try all standard scanning techniques. It will scan all known TCP ports of the host. For the port 21 (FTP), port 22(SSH), port 23(TELNET), it will try some simple guessing of the user’s (e.g. root) password. It will also try to get some information from port 80 which is the port for HTTP server to figure out the setting of CGI and other un-secure characters.


Here is a part of our scanning result of the host 128.123.9.210, using SARA.

When SAINT and SARA finish collecting all information from the hosts, it will put all these into its own database and compare each item and give a report. The report will be a HTML format which will be quite readable. In the report, all the secure features of the host will be give a green icon. Some potential security holes will be listed out with a brown icon. For the unsafe service, a red mark will be given to warn the administrator to fix it. nTOP The first part of this project was to find out what nTop does, and then we can use this information to determine how well it can be used as a network security tool. As mentioned earlier in this section, nTop is similar to the Unix top tool that reports processes that are running on a computer. NTop has been designed to perform four specific tasks that can further broken down into various processes. These four tasks are measuring traffic, monitoring traffic, network planning, and network security detection. This makes nTop a very broad and useful tool for network managers. For the purpose of this project we are interested in the usefulness of the network security detection that nTop provides. Several rules were written to detect common network intrusion attacks. After running ethereal while SAINT and SARA were attacking a machine, the following attacks were seen. Each application scans a multitude of ports by sending a SYN flag to each port less than 1024. A rule can be implemented to see if a single host is sending many packets with the SYN flag at one time to each port. This will be possible even if an attacker sends each packet very slowly, in order to avoid detection, because part of nTop is continually updating and monitoring network usage. It was also noted on ethereal that each scanning application used a SYN-RST packet or a SYN-FIN packet to detect ports that are not open. By default this gives them an list of the ports that are open. We found that both SAINT and SARA attempted to login as ftp ‘root’ on various

Data collection in progress... Adding a primary target Add-primary: gump.nmsu.edu Add-target: gump.nmsu.edu prox 0 policy: gump.nmsu.edu prox 0 level 3 Check-pulse: gump.nmsu.edu ==> running bin/timeout 180 bin/fping gump.nmsu.edu process_targets: probe gump.nmsu.edu... Prox: 0 AL : 3 Add-todo: gump.nmsu.edu|dns.sara| Add-todo: gump.nmsu.edu|rpc.sara| Add-todo: gump.nmsu.edu|finger.sara| Add-todo: gump.nmsu.edu|backdoor.sara| Add-todo: gump.nmsu.edu|hosttype.sara| Add-todo: gump.nmsu.edu|tcpscan.sara 1-9999,12345,16600,20034,27665,31337-33568,60008,65000| Add-todo: gump.nmsu.edu|udpscan.sara 1-2050,6500,27444,31335,31337,32767-33500| ==> running bin/timeout 20 bin/finger.sara gump.nmsu.edu ==> running bin/timeout 180 bin/hosttype.sara gump.nmsu.edu ……


occasions as well as login in as guest and root into a machine using simple password checks (i.e. guest as the password for guest login). From the results found in ethereal and from the network managing tools available from nTop, we devised several rules to try and detect SARA and SAINT when attacking. Writing rules is simple and easy to implement. To write a rule for nTop the following format is used. ‘protocol rule-label rule-options’ The first part of the rule states the protocol that nTop will look for such as tcp, udp, or http. The second part of the rule is the name that you wish to call the rule. This will be helpful in determining the type of security violation that occurred. For example, you may name a rule ‘ftp-root’ to indicate that someone attempted to login in an ftp server as root. The last part of the rule is used to indicate what is to be detected and the type of action that will be taken. For example, the following rule was written to indicate if anyone tried to login as a root on an ftp server:

tcp root-ftp any/ftp any/any contains ‘root login:’ action alarm This rule will look for a tcp packet that is going to the ftp port with the characters ‘root login’ as part of the data. If this is detected nTop will record a network transaction showing the ALARM flag. An administrator may also have nTop send email or an advertisement depending on the severity of the security violation. We wrote several rules to try and detect several security violations. More on nTop rules can be found in the man8 directory of the ‘man’ pages for ntop_rules. Once the rules were created, they were written in a file called filter.rules and placed into action in nTop by using the –R parameter when starting nTop. Then we tried to login as root and guest users by using various random passwords. We also ran SAINT and SARA to see what security violations were detected by nTop. Experimental Results SAINT Using the SAINT networking scanning program we scanned the whole Network Teaching Laboratory subnet 128.123.9.192/26, Team #1 sub-subnet 128.123.9.208/29, and a machine from the Computer Science Department running in two modes Windows 2000 and RedHat Linux 7.1. Various scanning levels were all tested on the different host and networks using the procedure from “Setting Up a Scan with SAINT,” from above. By default we analyzed the vulnerabilities by Danger Level. Some of the critical problems that were found were user shell – http_cgi_access, unprivileged shell – guessed_account_password, user file write – open_SMB_shares and unrestricted_NFS_export, and evidence of penetration – worm_detected. Some areas for concern were information gathering – excessive_finger_information. And some potential problems were limiting Internet access – remote_login_on_the_internet, remote_shell_on_the_internet, guessable_read_community. The “_” names are further descriptions and html pages with more details. After analyzing all our results the only crucial security hole was found was on the Windows NT system being used for samba (golden.nmsu.edu). This system showed evidence of penetration where the guest account showed signs of the worm Nimba and it was detected that the windows account for guest had no password. Unfortunately, before letting anyone know about the problem it seems that the system got attacked with BIOS password, email being sent and we’re no sure who did what. After investigating a little more on the Nimba worm, it was determined


that it usually created an account with root authority and also changed the BIOS password. For data from SAINT see Appendix 16 pages 38-41. To some extent Team #1 feels responsible by not making the owner of golden.nmsu.edu aware of the security holes we found. The other potential problems or areas of concern could be attributed to old software in which know security bugs have been fixed with newer software our lab doesn’t not have. In general though our Network Teaching Laboratory Network it well secured. SARA So far we have not got any information of crucial security holes of all the hosts that we scanned. All hosts seemed running in a secure state. There are explanations for this:

1. The operating systems on these machines are quite new and all the known security bugs have already been fixed before the OS is released. For example, the machines we scanned are running the latest Windows and Linux version.

2. The administrators of the machines intentionally shut the un-secure services unless they have to use them for a while.

3. Some techniques that SARA uses are out-of-date. SARA collects some traditional tricks that hackers used 3-5 years ago. For example, the way of guessing user’s password. It becomes such a standard that from SATAN, the first generation of such kind of security tools, system administrators began to use them as test criteria.

We did find a security problem on one machine in the network lab that is running Windows2000. It was detected that a guest account without any password verification was enabled. We succeeded logged in the machine using the guest ID. All results and screen shots will be attached in the appendix:

Appendix 17: SARA - Scanning result form host 128.123.9.210 (SuSE 7.2) Appendix 17: SARA - Scanning result form host 128.123.9.210 (SuSE 7.2) cont’d Appendix 18: SARA - Scanning result from host puppy.cs.nmsu.edu (Windows 2000) Appendix 19: SARA - Scanning result from host puppy.cs.nmsu.edu (Windows 2000) Appendix 20: SARA - Reports on host 128.123.9.210 Appendix 21: SARA - Scanning Result of host pedro.nmsu.edu Appendix 22: SARA - Reports on host pedro.nmsu.edu Appendix 23: SARA – Different Report on host pedro.nmsu.edu

Ntop After running SAINT and SARA and trying several ‘illegal’ root and guest logins, nTop was reviewed. We found that it had listed the name of the host that launched the attacks. Just by looking at the network traffic management tools that nTop has available, one was able to see that something was wrong. First a large amount of traffic was shown coming from a single host. When looking into the host, which is a traffic option available in nTop, we found that the host had accessed every single port from 0 to 35675. We don’t know if there was not enough room to fit the other ports, or perhaps SAINT and SARA don’t attack all ports. Every time the test was run, we found that we had similar but not exact results. Looking at the ethereal output, it seems as though SAINT and SARA try to access all the ports up to 1024 and then chose random ports thereafter. Then we noticed a ! mark next to the address of the attacking host. In the results we


found a bracket showing the security violations that had been detected by nTop. You can see some of them by looking at appendix C. Network Tools Assessment SAINT After seeing what SARA could do (practically the same as SAINT), I still saw SARA as being a bit more powerful. However, I can not fully conclude this due to the fact that the full version of SAINT cost $1800, for that amount of money it better be a powerful tool. The freeware version did prove to help detect a problem with the system golden.nmsu.edu, however I truly feel that if we’d had the funding to buy the full version of SAINT, we could of uncovered more critical security holes. We also want to note that didn’t want to alarm any network security administrators by making them think that were attacking their system so we stuck to scanning our Network Teaching Laboratory Network. However we do recommend using either SAINT or SARA to scan their network for any possible network security holes. SARA SARA is useful tool for the network security monitoring. It combines a lot of scanning and peeking techniques to find out the security holes of the system. SARA can reveal the setting of the network system. In most cases, it will discover more than 90% of the security problems of a stand-alone machine. For machines working in a more severe environment which 100% security are required (banks, financial facilities, etc.), more detecting/protecting tools are needed to use together to maximize the security of the whole system. nTOP NTop does not claim to be heavy IDS system, however; it provides very good security detection capabilities. It can detect most common attacks, including worms and Trojan horses which usually come through a ‘commonly known’ port. Its rules are similar to using iptables, however not as much time is lost going through each rule because it uses its traffic monitoring capabilities to help it detect abnormal behavior within a network. It is especially useful in a large network, since a majority of network attacks are usually generated inside the same network. NTop does offer more easy and various options in viewing traffic data as opposed to other packet sniffers such as tcpdump and ethereal. It provides reliable intrusion detection system, and it has been designed with optimizing the speed at which it operates. After all, it is a network optimizing and planning tool as well. So it can detect security violations faster than most other IDS systems and it does not take up much memory (designed to take up a maximum of 16 MB or it will create a new swap space or file to store old data). This gives us both good security and optimum speed. Overall nTop offers a very effective security tool. Conclusion Network security will continue to increase in demand, especially with the increased growth of the Internet, and the introduction of wireless networks. It is essential to stay up to date in the current security tools that are available to a network administrator. SARA, SAINT, and nTop offer various options in detecting security vulnerabilities and violations. It will be difficult to achieve 100% secure networks (the Network Teaching Lab is fairly safe with some


vulnerabilities detected), but by using the right tools, and implementing good security policies, it is possible to achieve a fairly secure network. Security tools usually come in three forms: scanning devices, packet sniffers, and packet managing devices (such as firewalls). This report covers two of the most popular scanning tools in SAINT and SARA. These tools cover the most common types of attacks and are usually kept up-to-date in the current attacks that are being developed everyday (SAINT provides a scan for the SANS Top 20 network attacks which is updated on a weekly basis). NTop is a unique tool that gives an administrator a security (packet sniffing) tool as well as a powerful traffic managing and network-planning tool. While a good security policy and the proper awareness of Internet dangers is necessary to keep a network safe, SAINT,SARA, and nTop are three tools that will help any network administrator manage a secure network effectively. References

1.) http://www-arc.com/sara 2.) http://www.saintcorporation.com/saint

3.) http://www.ntop.org

4.) Mancill, Tony. Linux Routers: A Primer for Network Administrators (New Jersey:

Prentice Hall, 2001).


Appendix 1: SAINT - saint.html


Appendix 2: SAINT - Data Management


Appendix 3: SAINT - Target Selection


Appendix 4: SAINT - Data Collection


Appendix 5: SAINT - Data Collection (continued)


Appendix 6: SAINT - Data Analysis


Appendix 7: SAINT - Data Analysis – Vulnerabilities – Danger Levels


Appendix 7: SAINT - Data Analysis – Vulnerabilities – Danger Levels (cont’d)


Appendix 8: SAINT - Data Analysis – Vulnerabilities – By Type


Appendix 9: SAINT - Data Analysis – Vulnerabilities – By Counts


Appendix 10: SAINT - Data Analysis – Host Information – by Class of Service


Appendix 11: SAINT - Data Analysis – Host Information – by System Type


Appendix 12: SAINT - Data Analysis – Host Information – by Internet Domain


Appendix 13: SAINT - Data Analysis – Host Information – by Subnet


Appendix 14: SAINT - Data Analysis – Host Information – by Host Name


Appendix 15: SAINT - SAINTwriter – Configuration Management


Appendix 16: SAINT - SAINTwriter – Report


Appendix 16: SAINT - SAINTwriter – Report (cont’d)


Appendix 17: SARA - Scanning result form host 128.123.9.210 (SuSE 7.2) Data collection in progress... Adding a primary target Add-primary: gump.nmsu.edu Add-target: gump.nmsu.edu prox 0 policy: gump.nmsu.edu prox 0 level 3 Check-pulse: gump.nmsu.edu ==> running bin/timeout 180 bin/fping gump.nmsu.edu process_targets: probe gump.nmsu.edu... Prox: 0 AL : 3 Add-todo: gump.nmsu.edu|dns.sara| Add-todo: gump.nmsu.edu|rpc.sara| Add-todo: gump.nmsu.edu|finger.sara| Add-todo: gump.nmsu.edu|backdoor.sara| Add-todo: gump.nmsu.edu|hosttype.sara| Add-todo: gump.nmsu.edu|tcpscan.sara 1-9999,12345,16600,20034,27665,31337-33568,60008,65000| Add-todo: gump.nmsu.edu|udpscan.sara 1-2050,6500,27444,31335,31337,32767-33500| ==> running bin/timeout 20 bin/finger.sara gump.nmsu.edu ==> running bin/timeout 180 bin/hosttype.sara gump.nmsu.edu ==> running bin/timeout 180 bin/tcpscan.sara 1-9999,12345,16600,20034,27665,31337-33568,60008,65000 gump.nmsu.edu Add-fact: gump.nmsu.edu|sunrpc|a|||||offers sunrpc Add-fact: gump.nmsu.edu|ssh|a||||SSH-1.99-OpenSSH_2.9p2\n|offers ssh Add-fact: gump.nmsu.edu|printer|a|||||offers printer Add-fact: gump.nmsu.edu|elcsd|a|||||offers elcsd Add-fact: gump.nmsu.edu|982:TCP|a|||||offers 982:TCP Add-fact: gump.nmsu.edu|X-0|a|||||offers X-0 ==> running bin/timeout 20 bin/backdoor.sara gump.nmsu.edu ==> running bin/timeout 20 bin/rpc.sara gump.nmsu.edu Add-fact: gump.nmsu.edu|ypbind|a|x||||is a NIS client Add-fact: gump.nmsu.edu|statd|a|x||||runs statd ==> running bin/timeout 180 bin/udpscan.sara 1-2050,6500,27444,31335,31337,32767-33500 gump.nmsu.edu Add-fact: gump.nmsu.edu|rje|a|x||||offers rje Add-fact: gump.nmsu.edu|tcpmux|a|x||||offers tcpmux Add-fact: gump.nmsu.edu|#|a|x||||offers # Add-fact: gump.nmsu.edu|echo|a|x||||offers echo Add-fact: gump.nmsu.edu|sunrpc|a|x||||offers sunrpc ==> running bin/timeout 20 bin/dns.sara gump.nmsu.edu Add-fact: gump.nmsu.edu|dns|a|||nmsu-relay.nmsu.edu|nmsu-relay.nmsu.edu|Mail exchanger Add-fact: gump.nmsu.edu|dns|a|host|gump.nmsu.edu|dns1.nmsu.edu||authoritative DNS host Add-fact: gump.nmsu.edu|dns|a|host|gump.nmsu.edu|dns2.nmsu.edu||authoritative DNS host Add-fact: gump.nmsu.edu|dns.sara|u|||||program timed out Waiting for all processes to complete Add-todo: gump.nmsu.edu|depends.sara|statd Add-todo: gump.nmsu.edu|xhost.sara|-d gump.nmsu.edu:0 Add-todo: gump.nmsu.edu|ssh.sara| Add-todo: gump.nmsu.edu|depends.sara|printer

Appendix 17: SARA - Scanning result form host 128.123.9.210 (SuSE 7.2) cont’d


==> running bin/timeout 20 bin/ssh.sara gump.nmsu.edu Add-fact: gump.nmsu.edu|ssh|a|bo|[email protected]|[email protected]|SSH vulnerabilities|OpenSSH may be vulnerable to version 1 fallback ==> running bin/timeout 20 bin/depends.sara printer gump.nmsu.edu Add-fact: gump.nmsu.edu||a|ycio|[email protected]|[email protected]|printer version|LPRng print spooler may be vulnerable ==> running bin/timeout 20 bin/xhost.sara -d gump.nmsu.edu:0 gump.nmsu.edu ==> running bin/timeout 20 bin/depends.sara statd gump.nmsu.edu Add-fact: gump.nmsu.edu|statd|a|zcio|ANY@ANY|ANY@ANY|rpc statd access|rpc.statd is enabled and may be vulnerable Waiting for all processes to complete Data collection completed (1 host(s) visited).


Appendix 18: SARA - Scanning result from host puppy.cs.nmsu.edu (Windows 2000) Data collection in progress... Adding a primary target Add-primary: puppy.cs.nmsu.edu Add-target: puppy.cs.nmsu.edu prox 0 policy: puppy.cs.nmsu.edu prox 0 level 3 Check-pulse: puppy.cs.nmsu.edu ==> running bin/timeout 180 bin/fping puppy.cs.nmsu.edu process_targets: probe puppy.cs.nmsu.edu... Prox: 0 AL : 3 Add-todo: puppy.cs.nmsu.edu|dns.sara| Add-todo: puppy.cs.nmsu.edu|rpc.sara| Add-todo: puppy.cs.nmsu.edu|finger.sara| Add-todo: puppy.cs.nmsu.edu|backdoor.sara| Add-todo: puppy.cs.nmsu.edu|hosttype.sara| Add-todo: puppy.cs.nmsu.edu|tcpscan.sara 1-9999,12345,16600,20034,27665,31337-33568,60008,65000| Add-todo: puppy.cs.nmsu.edu|udpscan.sara 1-2050,6500,27444,31335,31337,32767-33500| ==> running bin/timeout 180 bin/tcpscan.sara 1-9999,12345,16600,20034,27665,31337-33568,60008,65000 puppy.cs.nmsu.edu Add-fact: puppy.cs.nmsu.edu|netbios-ssn|a||||\131\000\000\001\143|offers netbios-ssn Add-fact: puppy.cs.nmsu.edu|swift-rvf|a||||220 Serv-U FTP Server v3.0 for WinSock ready...\r\n331 User name okay, need password.\r\n530 Not logged in.\r\n221 Goodbye!\r\n|offers swift-rvf Add-fact: puppy.cs.nmsu.edu|epmap|a|||||offers epmap Add-fact: puppy.cs.nmsu.edu|microsoft-ds|a|||||offers microsoft-ds Add-fact: puppy.cs.nmsu.edu|blackjack|a|||||offers blackjack Add-fact: puppy.cs.nmsu.edu|7230:TCP|a|||||offers 7230:TCP ==> running bin/timeout 180 bin/udpscan.sara 1-2050,6500,27444,31335,31337,32767-33500 puppy.cs.nmsu.edu Add-fact: puppy.cs.nmsu.edu|finger|a|x||||offers finger Add-fact: puppy.cs.nmsu.edu|sunrpc|a|x||||offers sunrpc Add-fact: puppy.cs.nmsu.edu|epmap|a|x||||offers epmap Add-fact: puppy.cs.nmsu.edu|netbios-ns|a|x||||offers netbios-ns Add-fact: puppy.cs.nmsu.edu|netbios-dgm|a|x||||offers netbios-dgm Add-fact: puppy.cs.nmsu.edu|microsoft-ds|a|x||||offers microsoft-ds Add-fact: puppy.cs.nmsu.edu|isakmp|a|x||||offers isakmp Add-fact: puppy.cs.nmsu.edu|printer|a|x||||offers printer Add-fact: puppy.cs.nmsu.edu|1026:UDP|a|x||||offers 1026:UDP Add-fact: puppy.cs.nmsu.edu|1027:UDP|a|x||||offers 1027:UDP Add-fact: puppy.cs.nmsu.edu|1174:UDP|a|x||||offers 1174:UDP Add-fact: puppy.cs.nmsu.edu|1175:UDP|a|x||||offers 1175:UDP ==> running bin/timeout 20 bin/rpc.sara puppy.cs.nmsu.edu ==> running bin/timeout 20 bin/finger.sara puppy.cs.nmsu.edu Add-fact: puppy.cs.nmsu.edu|finger.sara|u|||||program timed out ==> running bin/timeout 180 bin/hosttype.sara puppy.cs.nmsu.edu Add-fact: puppy.cs.nmsu.edu|host|a||||HOST Windows 2000| Add-fact: puppy.cs.nmsu.edu|hosttype.sara|u|||||program timed out ==> running bin/timeout 20 bin/dns.sara puppy.cs.nmsu.edu


Appendix 19: SARA - Scanning result from host puppy.cs.nmsu.edu (Windows 2000) Add-fact: puppy.cs.nmsu.edu|dns|a|host|puppy.cs.nmsu.edu|cs.cs.nmsu.edu||authoritative DNS host ==> running bin/timeout 20 bin/backdoor.sara puppy.cs.nmsu.edu Waiting for all processes to complete Add-fact: puppy.cs.nmsu.edu|swift-rvf|a|g||||FTP (non-standard port) Add-todo: puppy.cs.nmsu.edu|smb.sara| Add-todo: puppy.cs.nmsu.edu|depends.sara|printer ==> running bin/timeout 20 bin/depends.sara printer puppy.cs.nmsu.edu ==> running bin/timeout 700 bin/smb.sara puppy.cs.nmsu.edu Add-fact: puppy.cs.nmsu.edu|netbios-ssn|a||||Netbios Name|PUPPY Waiting for all processes to complete Data collection completed (1 host(s) visited).


Appendix 20: SARA - Reports on host 128.123.9.210


Appendix 21: SARA - Scanning Result of host pedro.nmsu.edu


Appendix 22: SARA - Reports on host pedro.nmsu.edu


Appendix 23: SARA – Different Report on host pedro.nmsu.edu


Appendix 24: nTOP – setup


Appendix 25: nTOP – Web Interface


Appendix 26: nTOP – Host Information

ee 590 – linux routers spring 2002bdu/ee590t1.pdf · internet’s speed and technology. network...

Documents