Abstract
Network Security is still in its infancy at the moment. While known attacks are typically preventable, it’s the unknown and new exploits that are hard to defend against. Most home networks and small business have firewalls and ACLs but the security typically stops there. When a host on one of these networks gets compromised, it usually goes undetected until the attack is completed and only detected if normal usage or operation is disrupted. If the attack is aimed to stay hidden and to monitor system usage or even log the user’s actions, then it may never even be known that an attack occurred. This is a clear unacceptable level of security for these types of networks where sensitive data resides and reliable service are critical and need to be treated as such. Large corporate networks can afford teams of security personnel to help monitor their networks and limit an attackers damage, but this is not needed to have a decent level of security on a private or smaller network. By implementing tried and tested open source security tools on a small network, you can easily monitor, log and be alerted to any kind of suspicious network activity without much effort. This paper will describe how to implement 3 different open source tools to achieve an acceptable level of security while remaining inexpensive and relatively easy to maintain and manage by one individual.
1. Introduction
Powerful network security software is readily available for free to all who choose to utilize it. There have been many recent advances in network security and this paper is intended to clarify the semantics of setting up a functional IDS or Intrusion Detection System. The 3 main open source tools this paper will describe how to implement are: Snort, Nessus and Honeyd. A few other applications will be referenced such as swatch and BASE for parsing and reading the IDS output.
Snort will act as the primary network sniffing & intrusion detection system. This will alert the network administrator when something potentially bad is happening. Snort has configuration files for pattern matching network data called rules. When these rules are triggered, snort will log the output to one or many sources.
Honeyd will act as a signature generator and attack sensor for when attacks are happening. This is a good tool to use when new viruses are released and there is no attack signature for them yet. Honeyd can generate the attack signature to be used to create more IDS rules.[7]
Lastly, Nessus will be used to audit the functionality of the IDS and test the security setup for obvious holes and triggering known attack sequences to test the alert facility.
This paper is written from the standpoint of a Unix user operating a Unix system for simplicity sake and ease of understanding concepts. These open source applications will also run on windows with a little more work for compiling them. If you have any questions regarding the setup of these open source tools, feel free to contact me.
2. Pre Installation
Before any installations take place, the network configuration should be examined. The first thing you will want to locate is the physical point on the network that you wish to monitor. For most networks, this would be the traffic coming and going from the uplink router. A second IDS sensor could be placed on an inside subnet to watch internal traffic for malicious network events from host to host as viruses will often do. Since snort has the ability to log alerts to a database, you can set up as many snort instances or “sensors” on as many different machine as you wish and send all the logging output to one database. Then high-level queries can be performed on the collected data to analyze and determine if something bad is happening network wide.
One common problem faced at this stage of deployment would be switched networks. Unless the switch can be configured to mirror all its traffic to a given port for Snort to monitor, then there is no way to capture the traffic by conventional means. One cheap and effective solution to this problem is to purchase an optical gigabit network tap. A network tap will duplicate the traffic going over any network line and replay it to an interface.[6] The IDS machine will simply just need to connect an Ethernet cable to the tap’s interface for logging.
A second cheaper solution would be to use a hub instead of a tap, but due to the half-duplex nature of hubs, under heavy network load, hubs can drop packets. It is favorable to use some kind of network tap and the prices are quite reasonable for a home or small business. For example, one might want to place a network tap on the downlink side of the uplink router to see all the traffic that makes its way inside the network. A line off the network tap would go into the IDS machine.
An alternative configuration for larger gigabit networks is to use a tap panel to distribute the output to multiple 100Mbit interfaces [5]. For most small networks, just being able to tap the 100Mbit router link will suffice. At this point, all your network traffic that you wish to monitor should be transmitting to the network interface on the machine that you can install the IDS on. For around $200, you could purchase a complete used system that is considered “out-dated” by today’s standards and run the IDS on a decent free Unix[17] operating system just fine.
Once the network input is determined, that input should be sent to the interface or interfaces on a machine that will run the IDS. Also, it is assumed that the network already has a firewall implemented. Most all operating systems come with a built-in firewall application. If you’re not already familiar with one, now is the time to look it up and use it. Also, server applications come with an ACL or access control list. It is assumed that these applications are configured to block unwanted host addresses and grant access to known host addresses.
3. Setting up the IDS
When it comes to open source IDS, there are really only two choices: Snort [3] and Bro [4] . At the time of this paper being written, Bro does not support logging to databases while Snort does. So this section will focus on setting up Snort. Bro has advanced features for reacting to alerts and automating responses, but the realm of IPS is still fairly new. There exists support to sync your Snort rules to Bro rules if you wish to use both which will be discussed later.
This paper will mainly focus on IDS implementation with a brief overview of IPS implementation. On a standard Unix system, it should be trivial to build and install the snort from source. It usually takes one or two commands to download, configure, build and install it. If you plan on using database support, it may be necessary to build snort with flags to enable support for MySQL or PostgreSQL. Once snort is installed, type snort –v to test that snort is in fact working and reading traffic off the default network interface. As with every application, all the details lay in the configuration.
Snort has a few places for configuration. The main application configuration exists in one file: snort.conf. From there you can locate all the other imported configuration files and edit these as well. The heart and brains of the IDS mainly hinges on the proper configuration of the alert rules. Snort comes with a hefty set of patterns already categorized from simple policy violations to shell code attacks. You will start with these rules when you start up snort for the first time. Once you have had a chance to examine your alerts, then you will want to start editing you rules and possibly changing their priority or classification categorization. For example, AOL and MSN messenger traffic is marked as a policy violation by default, you may wish to keep this or remove this rule set all together depending on your own network policy. You also may wish to change the level of severity (1-10) for that policy rule. The most important settings in the snort.conf file are setting your network ip addresses and various application server addresses correctly. Also in snort.conf you should specify the output functionality. You should have all the alerts written to syslog, and if you have a MySQL or PostgreSQL database setup somewhere, you can log the alerts to the database. You will first have to create a database for the snort alerts and that can be setup by reading the README in the snort distribution and using the appropriate sql schema script to initialize the new tables.[8] This is all contained in the snort distribution and can be found from reading the README file. If you do not have a database, that is ok. Either way, simply logging to syslog will suffice. Another reason for logging to syslog other than keeping a history of alerts, is to be notified when certain alerts occur via email or sms pager.[1] Later on, you can install and use swatch[18] to notify you of any pattern matches that occur in syslog. For example, to be notified of all alerts that snort classifys as level 1 priority, you would a line like this to swatch’s configuration: watch for /Priority \:1/ Using swatch is essential if you want to be actively notified by email or sms pager of certain alert priority levels as Snort has no build-in notification mechanism.
Once you are done configuring snort for the first time, launch snort with the start up script that was installed during installation. The start up script gets installed on your system once you have installed snort. This start up script is typically installed in the system rc.d/ script folder. Once snort is running, and traffic is being transferred on your network interface, you will notice your output plugins receiving output. If you ran the database setup script and have the correct permissions on the database tables for the user you gave to snort, and if there is no firewall or connection issues with your database server, then snort should be logging all alerts to your database. At this point you can install a project called: BASE[9] which is a nice web interface to organize and view all the database output from snort. Its quite easy to sort and analyze all the alerts generated by snort in BASE. When you have found an alert that is a false positive, then you need to edit the rule files to either change the level of the alert ( 1-10 ) or change the type of alert. Someone accessing an irc server shows up as a policy violation alert by default, you may want to change this to a different classification.
Logging alerts and then re-categorizing the alert level or classification is where most of the time is spent in getting snort to operate functionally well. It is safe to say that updating your snort rules is an on-going process. When new attacks are detected, then new rules need to be added so snort can detect the new attack signatures. By subscribing to the snort.org mailing lists, you can stay updated on the latest security rule releases. You can also stay updated by staying in sync with the cvs updater. One easy way to detect new attacks and generate rules based on these attack signatures is by using a HoneyPot.
4. Setting up the Honey Pot Service
Setting up the honey pot is much simpler than setting up snort. For the honey pot, we will be using honeyd. Again, the building and installing of honeyd is trivial on most Unix systems with a decent package manager. Once honeyd is installed, you will have to specify what you want your dummy network to look like to a would-be attacker. In the honeyd configuration you can specify how many hosts are on this dummy network, what operating systems they each or all will have. And even the fake services each one of these hosts is running. Through using a well created honeyd configuration, you can look like a real big corporate network or even multiple big networks. The network appearance is only limited by your imagination and willingness to write configuration files. Using the output from the honey pot, you can create a rule for snort to be alerted by. And honeyd logs out to one log file.[19] You can specify where you want this log file to be with command line arguments and then in turn you can setup swatch to monitor the honey pot log file and notify you when any activity is encountered.
5. Setting up the Nessus Server and client
Finally we have the Nessus Server and client to take care of. As described above, a Nessus server will scan a host or hosts on a network and give a complete report of all known vulnerabilities. You might be asking yourself, “How do I test if I really am vulnerable or not to all the known exploits? That would take forever finding and locating all the exploits one by one.” Having a nessus Server to test your network is critical and often overlooked when putting together a secure network. Nessus uses a central database on the Internet to update its list of all the known exploits. This list of exploits is maintained by thousands of active users and developers. Each time someone finds a new exploit, the routine is written into what is called a plugin.[11] These plugins are submitted to the Nessus development team then they are tested for accuracy and added to the main database.
At the moment, Nessus is the only good, free and easy way to test you network for known security holes. It also happens to be one of the best. Nessus will update itself and then test a given network or host for all the known exploits without actually infecting or destroying the machine. You can audit the security effectively for obvious mistakes or just to make sure everything is 100% secure, and it also doubles as an IDS tester. Meaning you can test the alerts on the IDS by running Nessus. If this isnt desired, you can configure snort to temporarily ignore attacks coming from the Nessus host if you want to ignore the false positive alerts snort will generate during the nessus scan, or you may want to test your alert system for certain known attacks like worm or virus signatures and see if you are getting your emails or pager alerts. You could also test your honey pots out and make sure the logs are working by having nessus scan the honey pot networks.
So now your IDS and Honey Pot should be set up and working. The next choice is to decide where to run your Nessus server. Which machine you decide to run the Nessus server on will change the outcome of the Nessus reports. If you run Nessus inside a firewalled network you will find many more exploits than running Nessus outside a firewalled network. You may want to set up a Nessus server inside the firewalled network to see if a host gets compromised, what exploits would be available to the attacker or a malicious user.[12] Most importantly, if you’re only going to run one Nessus server, then run one outside your firewalled network so you can see what the rest of the world sees when they see your network on the Internet. You don’t need a dedicated machine for a nessus server. For testing a home network, a friend’s home network located on another network block can suffice to run a Nessus server. Nessus runs on one port so it can be forwarded by nat and allowed by a firewall easily. After Nessus is installed, you will have to add a user to the nessus server so you can login remotely with a nessus client. Also, once nessus is installed, and from time to time, you will have to run the nessus plugin update script. This will get all the latest security exploit tests.
Now start up the nessus server, and from any machine, even the nessus server, download and install the nessus client.[13] On Unix systems this usually comes with the main nessus distribution and will be there once its installed. Upon running the nessus client, locate the options and connection panel and enter in the host, user name and password for the nessus server and nessus user you created earlier on the server. Once you are logged in, you will have access to configure a huge array of tests for exploits and attacks. Nessus’s ability to scan and exploit is very extensive so you may spend an hour or 2 just learning and reading up on all the various options and methods to scan and exploit networks. If you’re not sure about a certain option, leave the default setting. The more tests you enable, the longer it takes to scan. The main configuration option here to notice is entering the host or network range of hosts you want to scan. For example you may want to scan your external gateway if you are scanning from outside your network to test what exploits the public world can see on your network access point. Or you can specify a network range if you are scanning internal network hosts all at once.
When you’re done creating the configuration and enabling tests, you can save the configuration settings as a scan session and use them again later or use the saved session to create other scan sessions for other networks. Now you are ready to scan; you will want to scan and let it run for about 10-20 minutes for each host you are scanning depending on how many tests you enabled and connectivity. When the scans are complete, a report is generated and can be read in html or pdf format. The report will have a comprehensive analysis of all your known vulnerabilities. They are categorized by severity. Go through the report and make sure you close up and are aware of all vulnerable services. Some services like a web or email server you may have no choice but to leave exposed. But sometimes there is an exploit in a web server itself and upgrading to the latest security branch release for that web server will solve the issue. Other times you might see an open port with an unknown service running that you were not aware of. Nessus is great for auditing a network and getting a complete picture on all your own services and vulnerabilities.
6. Operating and Testing the IDS
Now you should have an IDS, a honey pot and a Nessus server all up and running. You are optionally using BASE to view and analyze the alerts stored in database tables. You should be running swatch on the Snort server to analyze syslog if you want to be notified by email or sms pager when certain alerts occur. Also you are using nessus to test each one of your policy rules configured by snort. And using a honeypot to be able to see activity of any network viruses or malicious users or applications. By going thru and testing each alert with nessus, you can see if your IDS is logging alerts properly, logging them with the right priority and testing your notification service using swatch to see if emails and pages are sent through. This part of the setup will take the most time, because each network operator will have a unique different set of policies that they will have to configure for their network. For example, a stock brokerage firm’s computer network will not want to tolerate the same traffic as a nursing home’s computer network. At a nursing home, playing games online is allowed where at a stock brokerage firm, playing games might be prohibited. It all depends on what the policy guidelines are, usually stated by the network owner or administrator. Once the policy is clear, then it is rather easy to test each aspect of the policy. If certain websites are prohibited due to a policy, then you could create a rule that pattern matches the url and logs an alert whenever a host generates that packet when visiting the website.
After sometime and some testing of these rules, you can get the network policy down to almost a science. And only the new unforeseeable threats or new attacks will be the bottle neck in security. One option is to use the latest and greatest rule sets from a project that is devoted to 2 things: Writing high-quality attack signatures for snort IDS, and getting them out in a quick and timely manner.[14] The project is called Bleeding Snort and the group is composed of security minded rule writers. If there is a new virus or attack on the loose, this project will most likely have the alert rules for it for snort to use. For a small business or a home office network, there should rarely be a time when you actually will need to craft your own signatures. Most likely when an attack occurs, you will be encountering malicious virus programs or trojans that others have encountered before you. So probably the rules have been written for your new attack by the time you're ready to need it. If you happen to be on the frontier of a new malicious program attack, and no attack signatures have been created yet, at the very least, you could post the hex packet payload on bleedingsnort.com and if it is indeed a virus attack, someone else will create the alert rule and add it to the list of alert updates. Security is everyone's concern. If there exists a new virus with no attack signature, it is to everyone’s benefit to create a signature and share it with everyone. As long as there are still volunteers willing to do contribute time and effort into creating new alert signatures, then the security community can at least stay one closer step behind the creative attackers.
7. Converting to an IPS
After some time of testing and modifying policy and alert levels, you will find that the IDS performs very close to what is expected. When policy rules are violated, the proper channels are notified, but this does nothing for preventing an attack when it is happening. This is where an IPS or Intrusion Prevention Device can be created. Bro is an excellent and easy choice for implementing reaction measures like blocking ports or hosts from a firewall application. And Bro has a nice rules translation tool to convert all your snort rules to bro rules. Then you can choose to assign actions to any rule in the form of a script to be launched when the rule is triggered. A typical reactionary script would be when a known worm virus is pattern matched, then block the ip that the worm is coming from on all network gateways and firewalls by inserting a new rule into the firewall application or applications. While a worm is a safe bet to block for firewall traffic, allowing other patterns may trigger more false positives and start blocking hosts that shouldn’t be blocked causing an unwanted denial of service. And if an attacker knows this, they might be able to trigger false positives with normal traffic to cause denial of service attacks. Bro is a very decent IPS because it does more than just do strict pattern matching like Snort. Bro also pattern matches on higher levels that just static pattern matching, Bro uses regular expressions and can understand traffic better based on its context thus reducing false positive alerts. It can be noted here that Bro can be used to replace Snort, but as of now, Bro has no database support.
8. Conclusion
Many networks are vulnerable simply because there is no standard way to implement and test a network for security. This paper attempts to clarify and standardize the methods needed to be taken to properly secure a small home or office network. While firewalls and access control lists have become necessary, so should an IDS. Using an IDS with active alert notification is the only real way to keep a network safe from attack or intrusion. Being able to be notified of network policy breeches the instant they happen is not only necessary for any business or home user but it is critical as more and more sensitive data gets moved into the digital realm.
9. References:
2. Pre Installation
Before any installations take place, the network configuration should be examined. The first thing you will want to locate is the physical point on the network that you wish to monitor. For most networks, this would be the traffic coming and going from the uplink router. A second IDS sensor could be placed on an inside subnet to watch internal traffic for malicious network events from host to host as viruses will often do. Since snort has the ability to log alerts to a database, you can set up as many snort instances or “sensors” on as many different machine as you wish and send all the logging output to one database. Then high-level queries can be performed on the collected data to analyze and determine if something bad is happening network wide.
One common problem faced at this stage of deployment would be switched networks. Unless the switch can be configured to mirror all its traffic to a given port for Snort to monitor, then there is no way to capture the traffic by conventional means. One cheap and effective solution to this problem is to purchase an optical gigabit network tap. A network tap will duplicate the traffic going over any network line and replay it to an interface.[6] The IDS machine will simply just need to connect an Ethernet cable to the tap’s interface for logging.
A second cheaper solution would be to use a hub instead of a tap, but due to the half-duplex nature of hubs, under heavy network load, hubs can drop packets. It is favorable to use some kind of network tap and the prices are quite reasonable for a home or small business. For example, one might want to place a network tap on the downlink side of the uplink router to see all the traffic that makes its way inside the network. A line off the network tap would go into the IDS machine.
An alternative configuration for larger gigabit networks is to use a tap panel to distribute the output to multiple 100Mbit interfaces [5]. For most small networks, just being able to tap the 100Mbit router link will suffice. At this point, all your network traffic that you wish to monitor should be transmitting to the network interface on the machine that you can install the IDS on. For around $200, you could purchase a complete used system that is considered “out-dated” by today’s standards and run the IDS on a decent free Unix[17] operating system just fine.
Once the network input is determined, that input should be sent to the interface or interfaces on a machine that will run the IDS. Also, it is assumed that the network already has a firewall implemented. Most all operating systems come with a built-in firewall application. If you’re not already familiar with one, now is the time to look it up and use it. Also, server applications come with an ACL or access control list. It is assumed that these applications are configured to block unwanted host addresses and grant access to known host addresses.
3. Setting up the IDS
When it comes to open source IDS, there are really only two choices: Snort [3] and Bro [4] . At the time of this paper being written, Bro does not support logging to databases while Snort does. So this section will focus on setting up Snort. Bro has advanced features for reacting to alerts and automating responses, but the realm of IPS is still fairly new. There exists support to sync your Snort rules to Bro rules if you wish to use both which will be discussed later.
This paper will mainly focus on IDS implementation with a brief overview of IPS implementation. On a standard Unix system, it should be trivial to build and install the snort from source. It usually takes one or two commands to download, configure, build and install it. If you plan on using database support, it may be necessary to build snort with flags to enable support for MySQL or PostgreSQL. Once snort is installed, type snort –v to test that snort is in fact working and reading traffic off the default network interface. As with every application, all the details lay in the configuration.
Snort has a few places for configuration. The main application configuration exists in one file: snort.conf. From there you can locate all the other imported configuration files and edit these as well. The heart and brains of the IDS mainly hinges on the proper configuration of the alert rules. Snort comes with a hefty set of patterns already categorized from simple policy violations to shell code attacks. You will start with these rules when you start up snort for the first time. Once you have had a chance to examine your alerts, then you will want to start editing you rules and possibly changing their priority or classification categorization. For example, AOL and MSN messenger traffic is marked as a policy violation by default, you may wish to keep this or remove this rule set all together depending on your own network policy. You also may wish to change the level of severity (1-10) for that policy rule. The most important settings in the snort.conf file are setting your network ip addresses and various application server addresses correctly. Also in snort.conf you should specify the output functionality. You should have all the alerts written to syslog, and if you have a MySQL or PostgreSQL database setup somewhere, you can log the alerts to the database. You will first have to create a database for the snort alerts and that can be setup by reading the README in the snort distribution and using the appropriate sql schema script to initialize the new tables.[8] This is all contained in the snort distribution and can be found from reading the README file. If you do not have a database, that is ok. Either way, simply logging to syslog will suffice. Another reason for logging to syslog other than keeping a history of alerts, is to be notified when certain alerts occur via email or sms pager.[1] Later on, you can install and use swatch[18] to notify you of any pattern matches that occur in syslog. For example, to be notified of all alerts that snort classifys as level 1 priority, you would a line like this to swatch’s configuration: watch for /Priority \:1/ Using swatch is essential if you want to be actively notified by email or sms pager of certain alert priority levels as Snort has no build-in notification mechanism.
Once you are done configuring snort for the first time, launch snort with the start up script that was installed during installation. The start up script gets installed on your system once you have installed snort. This start up script is typically installed in the system rc.d/ script folder. Once snort is running, and traffic is being transferred on your network interface, you will notice your output plugins receiving output. If you ran the database setup script and have the correct permissions on the database tables for the user you gave to snort, and if there is no firewall or connection issues with your database server, then snort should be logging all alerts to your database. At this point you can install a project called: BASE[9] which is a nice web interface to organize and view all the database output from snort. Its quite easy to sort and analyze all the alerts generated by snort in BASE. When you have found an alert that is a false positive, then you need to edit the rule files to either change the level of the alert ( 1-10 ) or change the type of alert. Someone accessing an irc server shows up as a policy violation alert by default, you may want to change this to a different classification.
Logging alerts and then re-categorizing the alert level or classification is where most of the time is spent in getting snort to operate functionally well. It is safe to say that updating your snort rules is an on-going process. When new attacks are detected, then new rules need to be added so snort can detect the new attack signatures. By subscribing to the snort.org mailing lists, you can stay updated on the latest security rule releases. You can also stay updated by staying in sync with the cvs updater. One easy way to detect new attacks and generate rules based on these attack signatures is by using a HoneyPot.
4. Setting up the Honey Pot Service
Setting up the honey pot is much simpler than setting up snort. For the honey pot, we will be using honeyd. Again, the building and installing of honeyd is trivial on most Unix systems with a decent package manager. Once honeyd is installed, you will have to specify what you want your dummy network to look like to a would-be attacker. In the honeyd configuration you can specify how many hosts are on this dummy network, what operating systems they each or all will have. And even the fake services each one of these hosts is running. Through using a well created honeyd configuration, you can look like a real big corporate network or even multiple big networks. The network appearance is only limited by your imagination and willingness to write configuration files. Using the output from the honey pot, you can create a rule for snort to be alerted by. And honeyd logs out to one log file.[19] You can specify where you want this log file to be with command line arguments and then in turn you can setup swatch to monitor the honey pot log file and notify you when any activity is encountered.
5. Setting up the Nessus Server and client
Finally we have the Nessus Server and client to take care of. As described above, a Nessus server will scan a host or hosts on a network and give a complete report of all known vulnerabilities. You might be asking yourself, “How do I test if I really am vulnerable or not to all the known exploits? That would take forever finding and locating all the exploits one by one.” Having a nessus Server to test your network is critical and often overlooked when putting together a secure network. Nessus uses a central database on the Internet to update its list of all the known exploits. This list of exploits is maintained by thousands of active users and developers. Each time someone finds a new exploit, the routine is written into what is called a plugin.[11] These plugins are submitted to the Nessus development team then they are tested for accuracy and added to the main database.
At the moment, Nessus is the only good, free and easy way to test you network for known security holes. It also happens to be one of the best. Nessus will update itself and then test a given network or host for all the known exploits without actually infecting or destroying the machine. You can audit the security effectively for obvious mistakes or just to make sure everything is 100% secure, and it also doubles as an IDS tester. Meaning you can test the alerts on the IDS by running Nessus. If this isnt desired, you can configure snort to temporarily ignore attacks coming from the Nessus host if you want to ignore the false positive alerts snort will generate during the nessus scan, or you may want to test your alert system for certain known attacks like worm or virus signatures and see if you are getting your emails or pager alerts. You could also test your honey pots out and make sure the logs are working by having nessus scan the honey pot networks.
So now your IDS and Honey Pot should be set up and working. The next choice is to decide where to run your Nessus server. Which machine you decide to run the Nessus server on will change the outcome of the Nessus reports. If you run Nessus inside a firewalled network you will find many more exploits than running Nessus outside a firewalled network. You may want to set up a Nessus server inside the firewalled network to see if a host gets compromised, what exploits would be available to the attacker or a malicious user.[12] Most importantly, if you’re only going to run one Nessus server, then run one outside your firewalled network so you can see what the rest of the world sees when they see your network on the Internet. You don’t need a dedicated machine for a nessus server. For testing a home network, a friend’s home network located on another network block can suffice to run a Nessus server. Nessus runs on one port so it can be forwarded by nat and allowed by a firewall easily. After Nessus is installed, you will have to add a user to the nessus server so you can login remotely with a nessus client. Also, once nessus is installed, and from time to time, you will have to run the nessus plugin update script. This will get all the latest security exploit tests.
Now start up the nessus server, and from any machine, even the nessus server, download and install the nessus client.[13] On Unix systems this usually comes with the main nessus distribution and will be there once its installed. Upon running the nessus client, locate the options and connection panel and enter in the host, user name and password for the nessus server and nessus user you created earlier on the server. Once you are logged in, you will have access to configure a huge array of tests for exploits and attacks. Nessus’s ability to scan and exploit is very extensive so you may spend an hour or 2 just learning and reading up on all the various options and methods to scan and exploit networks. If you’re not sure about a certain option, leave the default setting. The more tests you enable, the longer it takes to scan. The main configuration option here to notice is entering the host or network range of hosts you want to scan. For example you may want to scan your external gateway if you are scanning from outside your network to test what exploits the public world can see on your network access point. Or you can specify a network range if you are scanning internal network hosts all at once.
When you’re done creating the configuration and enabling tests, you can save the configuration settings as a scan session and use them again later or use the saved session to create other scan sessions for other networks. Now you are ready to scan; you will want to scan and let it run for about 10-20 minutes for each host you are scanning depending on how many tests you enabled and connectivity. When the scans are complete, a report is generated and can be read in html or pdf format. The report will have a comprehensive analysis of all your known vulnerabilities. They are categorized by severity. Go through the report and make sure you close up and are aware of all vulnerable services. Some services like a web or email server you may have no choice but to leave exposed. But sometimes there is an exploit in a web server itself and upgrading to the latest security branch release for that web server will solve the issue. Other times you might see an open port with an unknown service running that you were not aware of. Nessus is great for auditing a network and getting a complete picture on all your own services and vulnerabilities.
6. Operating and Testing the IDS
Now you should have an IDS, a honey pot and a Nessus server all up and running. You are optionally using BASE to view and analyze the alerts stored in database tables. You should be running swatch on the Snort server to analyze syslog if you want to be notified by email or sms pager when certain alerts occur. Also you are using nessus to test each one of your policy rules configured by snort. And using a honeypot to be able to see activity of any network viruses or malicious users or applications. By going thru and testing each alert with nessus, you can see if your IDS is logging alerts properly, logging them with the right priority and testing your notification service using swatch to see if emails and pages are sent through. This part of the setup will take the most time, because each network operator will have a unique different set of policies that they will have to configure for their network. For example, a stock brokerage firm’s computer network will not want to tolerate the same traffic as a nursing home’s computer network. At a nursing home, playing games online is allowed where at a stock brokerage firm, playing games might be prohibited. It all depends on what the policy guidelines are, usually stated by the network owner or administrator. Once the policy is clear, then it is rather easy to test each aspect of the policy. If certain websites are prohibited due to a policy, then you could create a rule that pattern matches the url and logs an alert whenever a host generates that packet when visiting the website.
After sometime and some testing of these rules, you can get the network policy down to almost a science. And only the new unforeseeable threats or new attacks will be the bottle neck in security. One option is to use the latest and greatest rule sets from a project that is devoted to 2 things: Writing high-quality attack signatures for snort IDS, and getting them out in a quick and timely manner.[14] The project is called Bleeding Snort and the group is composed of security minded rule writers. If there is a new virus or attack on the loose, this project will most likely have the alert rules for it for snort to use. For a small business or a home office network, there should rarely be a time when you actually will need to craft your own signatures. Most likely when an attack occurs, you will be encountering malicious virus programs or trojans that others have encountered before you. So probably the rules have been written for your new attack by the time you're ready to need it. If you happen to be on the frontier of a new malicious program attack, and no attack signatures have been created yet, at the very least, you could post the hex packet payload on bleedingsnort.com and if it is indeed a virus attack, someone else will create the alert rule and add it to the list of alert updates. Security is everyone's concern. If there exists a new virus with no attack signature, it is to everyone’s benefit to create a signature and share it with everyone. As long as there are still volunteers willing to do contribute time and effort into creating new alert signatures, then the security community can at least stay one closer step behind the creative attackers.
7. Converting to an IPS
After some time of testing and modifying policy and alert levels, you will find that the IDS performs very close to what is expected. When policy rules are violated, the proper channels are notified, but this does nothing for preventing an attack when it is happening. This is where an IPS or Intrusion Prevention Device can be created. Bro is an excellent and easy choice for implementing reaction measures like blocking ports or hosts from a firewall application. And Bro has a nice rules translation tool to convert all your snort rules to bro rules. Then you can choose to assign actions to any rule in the form of a script to be launched when the rule is triggered. A typical reactionary script would be when a known worm virus is pattern matched, then block the ip that the worm is coming from on all network gateways and firewalls by inserting a new rule into the firewall application or applications. While a worm is a safe bet to block for firewall traffic, allowing other patterns may trigger more false positives and start blocking hosts that shouldn’t be blocked causing an unwanted denial of service. And if an attacker knows this, they might be able to trigger false positives with normal traffic to cause denial of service attacks. Bro is a very decent IPS because it does more than just do strict pattern matching like Snort. Bro also pattern matches on higher levels that just static pattern matching, Bro uses regular expressions and can understand traffic better based on its context thus reducing false positive alerts. It can be noted here that Bro can be used to replace Snort, but as of now, Bro has no database support.
8. Conclusion
Many networks are vulnerable simply because there is no standard way to implement and test a network for security. This paper attempts to clarify and standardize the methods needed to be taken to properly secure a small home or office network. While firewalls and access control lists have become necessary, so should an IDS. Using an IDS with active alert notification is the only real way to keep a network safe from attack or intrusion. Being able to be notified of network policy breeches the instant they happen is not only necessary for any business or home user but it is critical as more and more sensitive data gets moved into the digital realm.
9. References:
[1] Real-Time Alerting with Snort http://www.linuxsecurity.com/content/view/117377/49/ June 2003
[2] http://www.cl.cam.ac.uk/~cpk25/publications/honeycomb-hotnetsII.pdf
[3] Snort - An Open Source IDS http://www.snort.org/
[4] Bro – An Open Source IDS/IPS http://www.bro-ids.org/
[5] Using network taps - http://www.snort.org/docs/Gb_tapping.pdf
[6] Implementing Networks Taps with Network Intrusion Detection Systems http://www.securityfocus.com/infocus/1594 June 2002
[7] Disabling Worms With Honeypots http://www.honeyd.org/worms.php August 2004
[8] How to log to multiple databases or output plugins - http://www.snort.org/docs/faq/1Q05/node88.html
[9] BASE – PHP Web Based snort alert analyzer http://secureideas.sourceforge.net/
[10] Nessus – Security and Exploit auditor http://www.nessus.org/
[11] Exploit plugins for nessus - http://www.nessus.org/plugins/
[12] Introduction to Nessus - http://www.securityfocus.com/infocus/1741 October 2003
[13] Nessus client - http://nessuswx.nessus.org/
[14] Snort Rules for the latest security threats - http://www.bleedingsnort.com/
[15] Simulating Networks with Hone Pots - http://www.paladion.net/papers/simulating_networks_with_honeyd.pdf
[16] Honey Pot – Sample configuration files http://www.honeyd.org/configuration.php
[17] FreeBSD – A very stable open-source server and desktop unix operating system http://www.freebsd.org/
[18] Swatch - http://swatch.sourceforge.net/
[19] HoneyD man page - http://www.citi.umich.edu/u/provos/honeyd/honeyd-man.pdf