Report Final Report of SecureCo

Download 74.94 Kb.
NameReport Final Report of SecureCo
A typeReport


Final Report of SecureCo

This document contains technical information regarding SecureCo's capstone project

Brandon Forbister, Taylor Jones, Jordan Holfeld


Executive Summary

Our vision for this project is to setup an email server on which we can monitor activity. The project is divided into three parts, the first part is setting up the email server, the second part is hardening the server, and finally we will monitor the activity on the network. The purpose of our project is to log the activity that may be observed on an email server to compile the most common attacks. A problem companies have is loss of confidential information over email, as technology advances so must security. This project’s major stakeholders are SAIT, SecureCo, and our instructors as sponsors.

We consider our project to be more research based then objective based. Our project focuses on creating an IDS for an email server; we will set up a monitoring system to track the activity on our system, sending alerts of any unauthorised users attempting to access our system. We will focus mainly on hardening and monitoring the activity on our email server. The first two weeks will be setting up the email server, followed by 2-3 weeks of determining the traffic flow over our network. Then we will research methods of statistical analysis as the network will be live.

Our group consists of Jordan Holfeld, Taylor Jones and Brandon Forbister. We feel that we bring different strengths to computer security and that will help us to work well together. We have included a detailed Gantt chart to show our timeline. Our equipment will be supplied and workspace will be provided by SAIT. We have a budget of $32 360 for all equipment and labour. As we have no sponsor any financial risks that we encounter will be out of pocket. However, the chances that this will happen are very unlikely as most of the equipment is provided for us. We can't predict the chances of theft or tampering happening.

The final statistical analysis of our network traffic will stay confidential; it will stay limited to our team members, instructors, and potential clients. We consider the hardware to be SAIT's, however, the ideas we come up with and way we report our data to belong to our group. This project has the potential to be extended past what we have set out to do. With more time a bit more could be tied into this project. One idea might be to add a honey-pot to the project to make it more appealing to attacks.

In review our project we will be setting up an IDS and attach it to an email server, followed by statistical analysis. After reading our charter proposal we hope you will accept this proposal and would like to proceed immediately once the next semester begins.

Table of Contents

Outcome 3

Challenges 4

Solutions 4

What we learned 5

Budget 5

Conclusion 6

Recommendations (Appendix A) 6

Glossary (Appendix B) 7

References (Appendix C) 7

Manual (Appendix D) 8

Equipment 9

Included Equipment 9

Required Equipment 9

Physical Server Setup 10

System Setup 10

Setting Snort’s Home Network 11

Snort Configuration 11

Snort Options 11

Starting Snort Server 13

Testing Snort 13

Launching Snort 14

Basic Snort Scan 14

Background Snort Scan 14

Checking Snort Logs 14

Analysis (Appendix E) 15


Our project focuses on creating an ID for an email server. We will set up a monitoring system to watch activity going on over our live system, alerting us to any unauthorised users from attempting to access our system. With increased security this can save money in the long run, as a loss of confidential information could cost a lot of money and jobs. A secondary focus of our project is the statistical analysis of the types and severity of intrusions on our system once we set it up on a live network for a couple of days.


As any project takes place, problems will happen. There are a few big problems that could potentially happen and lots of minor issues. We have experienced a few minor issues with snort logs, some removable features and adding additional details to our journals. A few bigger problems we experienced came from user changes. However managed to get through it as a team.

The bigger problems we experienced were first of all was we put a BIOS password, however it didn't say a maximum password length. Our password started overwriting other letters of it, we were unsure what got over written. Ex if our password was "password" and the length could only be 7 characters long, the password could have been overwritten to be "passwod" or "passwor". Many possible password options as we had a more secure password than "password"

Our second issue was the permissions on the /var was changed to 770 instead of 775. When we rebooted an update was needed from the /var, it couldn't access it because the appropriate permissions were not on it.. Our third and final major setback was while removing the GUI, somehow the dbus-launch was removed.

We didn't realize how big snort was when we started. Getting all the requirements ready before we could even run snort took longer than expected. We had to write a few scripts, remove some applications and a few applications that snort required. It took a few attempts but we finally got snort working properly.


Luckily we were able to find solutions to all of our problems. The first problem about the password being the wrong length, we were able to fix it by simply removing the CMOSS battery, leaving it out for 15 minutes will cause the hard drive to restart (not our ubuntu). We then put the battery back in, default setting were set and no password was on the BIOS.

Secondly we were able to fix the permissions of the /var by inserting an ubuntu cd, then just "try ubuntu" we are then logged in on the cd, still able to access the hard drive. We then had to go into the terminal, switch into the location of the hard drive, navigate to the /var and change the permissions. It was able to boot at startup again.

Right after we fixed the last solution we tried to remove the GUI. Dbus-launch got removed in this process, which is required at boot. Again, we tried the live cd option, instead of changing permissions though we had to transfer a file located on the cd (dbus-launch) onto the hard drive. After it was copied over everything was working perfectly.

What we learned

During our project there are many things that we were able to improve on. Before this project we didn't even talk to one another. We figured it would be easier to get work done working with other people. By getting to know each other we were able to solve issues and work together throughout the project. There were times where it was hard to work with one another but in a workplace you are not going to get along with everyone all the time. It was a good chance to feel what it's like to work with others.

We have been introduced to the basic IDS setup and explained what it is. However, we have never worked with Snort before. In snort there are a ton of files, some which are needed some that need to be removed. We added extra scripts for snort which were needed to log what we saw through our snort. Checking on our analysis we learned that even here in Calgary you can be attacked so it is always best to be up to date with security. The last thing you want is to be hacked and confidential information is lost.

One thing we all learned is that no matter what you plan, things will change and not go accordingly. In the beginning we were thinking we would have a lot of time to do a statistical analysis of the traffic we received. However the server needed to be completely safe before we were able to put it online. A group from a previous year put their server online and it wasn't fully secure, it was breached and used for phishing. Needless to say, we did not want that to happen to us so we put the extra time into hardening our server.

Lastly, before putting the server live you should do a quick run through to make sure everything is working how you want it to. Making sure that the snort is detecting properly would be the first thing to check. Including all scripts that you wrote for snort and making sure the logs are writing properly is an important part to showing your work for this type of project.



Specific Product




HP ProLiant ML370

$3 500.00

Client Machines

Intel Duo core 2.33 GHz Processor, 2 GB RAM, 160 GB HDD

Intel Website



20” LG Flatron

Best Buy Website


Mice and Keyboard Sets


Logitech Website





Uncompiled Snort Source Code





Since we started the project it was about working in a team to complete it. When the deadline approached we worked harder to ensure that everything was finished, everybody pulling a part. It was about teamwork that we were able to finish and complete our project effectively. We experienced a few problems as does anyone, we were able to pull through and find solutions to our problems. Our project allows you to see how much activity is going on here in Calgary. People think nothing bad happens close to home, this allows you to see that even here we have negative activity.

Recommendations (Appendix A)

Our project required us to go on a live network, meaning it was crucial to have it hardened to the best our ability and then some. In a previous year, a group did the same type of project, they failed to check on it and harden it; turns out that a phishing botnet was able to intrude into the system, doing phishing attacks from their server.

The second thing you should keep in mind is time management, with a project you should save lots of time in case something goes wrong. With this project I would leave plenty of time to harden your server as things can go wrong while hardening it or you can think of other things you need to look at while you are working. Always back up what you are working on, if something does go wrong while you are working on your server it will save you a lot of time in the end. We locked ourselves out at one point without backing up, if we weren't able to fix it we would have had to start from the beginning. Luckily we knew a few tricks to fix it.

While picking a group I suggest picking a group you can rely on. Everyone needs to pull their part including showing up to class (even other classes). If you can't rely on your group mates, you will get stuck doing a lot of work on your own. If your group has a problem bring it up, don't let it pass otherwise it will be a long semester. It is nice to work with friends, if you think you won't get distracted; However it is more important to pick a group that can work together than your group of friends.

Glossary (Appendix B)

IDS: Intrusion Detection System: A computer security system designed to monitor a given system and alert the administrator to an unauthorized intrusions or activities within the network.

IPS: Intrusion Prevention System: A computer security system designed to prevent unwanted intrusions from accessing a system altogether.

Statistical Analysis: The analysis of numerical data to determine patterns and commonalities.

References (Appendix C)

No outside references were used.

Manual (Appendix D)

SecureCo Snort IDS Server User Manual

Warning: Instructions available in English only.

Familiarity with Linux based operating system and commands required.

Some understanding of networking principles is required.

Prior experience with physical server setup recommended.


Included Equipment

SecureCo HP DL360 G3 Server

    • Hardened Ubuntu 10.04 Installed

    • Snort Installed and Configured

2 Power Cords

Required Equipment

Ethernet (RJ45) Cable

Computer Peripherals preferably USB

    • Mouse

    • Keyboard


    • Power Cord

    • VGA Cable

Physical Server Setup

  1. Set the server in a location you plan on leaving it

    1. Note if you are setting it up in a server rack you may want to do this step last as most of the cable connectors are on the rear of the machine.

  2. Plug in both power cables into the appropriate spots on the rear of the machine. Then plug the opposite end of the cable into a wall socket

  1. Plug in the Ethernet (RJ45) cable into the port labeled Nic 1. To verify that Nic 1 is working, check the front of the machine and confirm that the Nic 1 light is green.

  2. Attach the mouse and keyboard to the server via the 2 USB ports on the rear of the machine.

  3. Hook the monitor up through the VGA port on the rear of the server, and then plug the monitor into a power outlet.

  4. Press the power button on the front of the machine and assuming everything is properly connected you have now completed the physical setup.

**Once you have powered up the server, login using the credentials provided with the system**

System Setup

**We have configured the majority of the system for snort, although the end use must configure it to fit their own network, snort.conf is located in the /etc/snort directory. **

Setting Snort’s Home Network

  1. Type in “ifconfig” (ipconfig if it’s a Windows Machine) at the command prompt of the system(s) you are protecting to determine the IP address(es) you will need to set in snort.conf.

  2. Edit the snort .conf file using “sudo vi snort.conf” from the directory it is located in, once you have started editing snort.conf scroll down to the HOME_NET variable location.

  3. Set “var HOME_NET” to protect the IP address(es) you want to protect, it can cover a single address, several different IP addresses and even an entire subnet using the following syntaxes.

    1. Single address: var HOME_NET

    2. Multiple addresses: var HOME_NET [,,]

    3. Subnet: var HOME_NET

    4. Subnet and Multiple Addresses:

var HOME_NET [,,,]

Snort Configuration

If you wish to configure your own Snort server from scratch, ensure you research plenty beforehand. A poorly configured snort Intrusion Detection System server can in some cases virtually give access to your network away, rather than simply monitoring your network for intruders.

Snort Options

Before you start running snort you may want get familiar with the options available to you when you go to run snort.

Note some commands are more advanced than others so be careful when using a new command.

-A: Generates an alert using one of the specified alert-modes: fast, full, none, and unsock. Rather than specifying the alert mode within a configuration file, you can include it here at the command line.

-b: Logs packets in tcpdump format (i.e., libpcap), files in tcpdump format are smaller, so this is the best method of recording large amounts of logged data and packets. It is very fast and may be a good option on high-traffic networks.

-B: Scrambles the networks specified in the -h (or HOME_NET) setting. This hides the real internal network addresses inside binary logs.

-c: Allows you to specify which configuration file you want to use. If you have different configurations with various rules enabled, you can specify which configuration to use at the command line. This option is required when Snort is run in NIDS mode.

-C: Prints the character data found in the packet payload, rather than displaying it in a hexadecimal format.

-d: Displays the application layer data while in verbose mode.

-D: Runs Snort in daemon mode. Alerts are dumped to the alert file in the logging directory (/var/log/snort by default). Daemon mode is useful if you wish to automate the startup of Snort in the event of a reboot. Passing this option to Snort in a command script starts Snort in the background. Do not use this mode unless you are already familiar with Snort and have a working, viable configuration.

-g: Changes the default group ID under which Snort runs after initialization.

-h: Sets the "home network" to a specific address in a subnet. With this variable set, all decoded packet logging is done relative to the home network address space. This option is equivalent to setting the HOME_NET variable in the configuration file.

-i: Specifies which interface Snort should listen on. This option is used on machines that have more than one functional network interface card or that have different kinds of interfaces, besides Ethernet.

-I: In alerts, displays the interface on which each packet arrived.

-l: Specifies the logging directory. All alerts and packet logs are placed in this directory. The default logging directory is /var/log/snort, but that default is only used when Snort is in alert (-A) mode.

-N: Turns off packet logging. Alerts are still generated but are printed to the console only.

-O: When in ASCII packet dump mode, replaces the IP addresses printed to the screen or logfile with "". If the home-net address switch is set -h, only addresses on home-net are hidden, while non-home net IPs are left visible.

-p: Turns off promiscuous mode sniffing. When not in promiscuous mode, an adapter will only accept packets addressed to itself.

-q: Tells Snort to run quietly. Does not display banner and initialization information. If you aren't interested in the initialization messages, you can suppress them with this.

-r tcpdump-filename: Use this option to process a tcpdump-formatted file. The output appears much like it would when capturing data in real-time. This option is used to analyze a packet trace that was collected at an earlier time.

-s: Sends alert messages to a syslog server. This can be either a local or remote server. Use this option when capturing logs and alerts within syslog.

-t chroot: Changes Snort's root directory to chroot after initialization. Paths for logfiles and alert files are relative to the new root directory.

-T: Starts Snort in self-test mode. Useful for debugging Snort before it is run in daemon mode or before it is launched on a production box. Can also be used to test configuration files.

-u: Changes the default user ID or UID under which Snort runs after initialization. Like the -g option, an added security feature for running Snort as a nondescript user.

-U: Forces the timestamp in all logs to be in UTC (a.k.a. GMT) format. A recommended option when capturing logs from multiple sources on a single syslog server and if sensors are scattered across a large WAN; you won't have to deal with time zone differences.

-v: The verbose option prints all packets to the console. Be careful when using this option, as it may slow Snort and result in dropped packets.

-V: Displays the Snort version number and then exits.

-X: Displays raw packet data starting at the link layer. With this option you can see the entire packet, including Ethernet headers and trailers.

-y: Includes the year in all alerts and log files. Useful when you want to create an archive of logged Snort packets that can be referred to later.

-z: Enables the stream4 preprocessor, which tells Snort to generate alerts only when a packet is part of an established session, foiling some IDS evasion mechanisms.

-?: Lists all switches and options and then exits.

Starting Snort Server

Testing Snort

After familiarizing yourself with the basic options provided by snort, run a test scan to check for errors in the setup.

    • To run a test scan as a normal user # “sudo snort –T” to run a scan as root simply remove the sudo and proceed.

If the test run comes back with no errors then you are finally ready to launch snort.

Launching Snort

Basic Snort Scan

You have read through the options on what snort can do, but lets start off with just the standard scan using the configuration files that are set up for snort. Remember unless you are running as root user snort requires root authority via sudo login to run.

We will use only the configuration file option and therefore just require the name of the file (and path if you running snort from a different directory than /etc/snort).

Standard Scan: # sudo snort –c snort.conf

Since this is a foreground scan you will not be able use the terminal while snort is running using this method.

Background Snort Scan

Once you’ve got the hang of how snort works, and are sure that it works, unless snort is the only thing being used on the server, you may want to run snort in the background through daemon mode so that you can still use the command line while you are running snort.

Daemon mode also forces snort to start after an accidental reboot which is quite handy if you are away from the server for extended periods of time. The example below incorporates the use of the configuration file with daemon mode.

Daemon Mode Scan: # sudo snort –c snort.conf –D

Checking Snort Logs

Snort records everything that it scans into two separate types of files located by default in the /var/logs/snort folder, if you wish to set a different folder you need to edit the appropriate header in the snort.cnf directory.

Tcpdump.log: These files are used to store the packet data for everything trying to access the network. By default these are in binary, but can be read using the tcpdump –r [filename] command.

Alert file: This file stores information about every attack or intrusion that trips one of the rules held by snort. By default this is written in ASCII, and can be read by any of the many available interpreters.

Analysis of Logs

When analyzing your snort logs they will by default be in the /var/logs/snort/alertlog. This is where all the information regarding your alerts is recorded. In order to view your logs, in the command prompt type the command:

Sudo less /var/logs/snort/alertlog

You will need the provided root password in order to run this command.

Inside the logs you will see all the information pertaining to alerts. This includes the alert type (top), alert IP address (middle) and the alert reference (bottom). In order to determine how many alerts were logged you will need to count the alerts. From this you will count which types of alerts are which and then use the formula:

Alert type / number of hours server was online = Alert ratio

The alert ratio will tell you approximately how often an alert was logged.

Analysis (Appendix E)

The purpose of our project was to find out just how many times any device on the internet would be attacked or probed. To accomplish this we set up a SNORT IDS on an ubuntu server.  We left our server online for 46 hours (from 4pm Thursday April 6th 2012 until 2pm Saturday April 8th 2012).  We were unsure of how much traffic we would receive because we did not even browse the web. Our results astonished us.

We received 11 alerts and 7851packets analyzed. Of our alerts 4 were NMAP scans and 7 were faulty IP header lengths (bogus packets).  This means that any device connected to the internet is vulnerable to manipulation or intrusion from just being connected. NMAP scans are used to determine open ports (ways into the device) and faulty IP header lengths can mean a number of things from attempted intrusion to malicious code dispersal to a faulty packet.
Based on these statistics we can say that a regular device on the internet will receive an attempted intrusion once every 11.5 hours (#nmapscans/46 hours) and a suspicious packet once every 6.5 hours (#ipheaderfaults/46). If we take alerts/hours we find that we received an alert approximately once every 4 .18 hours.

To anyone and everyone connected in today’s modern society this should be alarming. Considering our device wasn’t even browsing the internet or having any participation with other machines (aside from being connected to the internet) an alert once every 4 hours is astounding.

Share in:


Report Final Report of SecureCo iconFinal Report

Report Final Report of SecureCo iconFinal Report Form

Report Final Report of SecureCo iconReport-Final Project

Report Final Report of SecureCo iconFinal Report on Best Practices For the Employment of People with...

Report Final Report of SecureCo iconAbstract in this report, we describe the application that we have...

Report Final Report of SecureCo iconReport in response to Ireland’s Third Report under the International...

Report Final Report of SecureCo iconReport from the Audit Committee recommending the draft scheme taking...

Report Final Report of SecureCo iconReport. The City Bar 2010 Report explains

Report Final Report of SecureCo iconReport(s) and investigative consumer report(s) by Company Name Here

Report Final Report of SecureCo iconA more complete report about Willowridge High School, the Texas Academic...

forms and shapes

When copying material provide a link © 2017