Requirements Analysis

(Kreugel C. et al, 2005) state that with the explosion in use of the internet, companies have
increasingly put critical resources on line. This makes these resources vulnerable because no
system connected to the internet is 100% secure.
System administrators therefore need to be aware of any malicious or unusual activity occurring
on the network. They must be aware of any threat to critical resources. The usual solution is an
Intrusion Detection System.
An Intrusion Detection System is a device or application used to monitor network traffic and to
report any violation of security policies or suspicious activity. They are passive systems, which
inspect network traffic for violations and report these with alerts or logs (Julish 2003, p444).
The seminal paper by Dorothy Denning (Denning, 1987) suggested a model for intrusion
detection systems which is followed by most of those currently available.
However any detection tool is only worthwhile if you have time to look at what it's telling you.
Therefore an alerting system that will scan logs and give timely alerts is necessary.

In this coursework, I am required to design and create an outline implementation of an Intrusion

Detection System which will illustrate the use of an agent based approach and provide useful
alerts.
Since this is an outline implementation I will restrict the detection to a few threats to the server
in each category, describing them, and illustrating how they will be detected in the
implementation.
Since we are not interested in all network traffic - only traffic to this host - I will base all
detection of threats on the hosts IP/ MAC address only and promiscuous mode will not be
required of the network interface card.

For the purpose of this exercise the system to be protected is running FTP, Telnet and Web
servers.
These are characterised below.

FTP Server

File Transfer Protocol (FTP) is a network protocol used to transfer files over a TCP/IP network
such as the Internet.
FTP is built on a client-server architecture and has separate control and data connections
between the client and server applications.
The FTP protocol was originally defined in (RFC 959, 1985).
(RFC 959, 1985) states that a client makes a connection to the server using TCP port 21 on the
server. This connection, called the control connection, remains open for the duration of the
session.
Commands are sent by the client over the control connection in ASCII. Server responses on the
control connection are three digit status codes in ASCII and an optional text message. For
example '200' or '200 OK.' shows that the last command completed successfully.

e-Security Page 1
In active mode, a second connection on port 20 on the client is opened by the server to transfer
data. However many firewalls are set to reject incoming TCP requests and so passive mode
(PASV command) can be used. In this mode the server supplies the IP address and port to
connect to for the transfer and the client opens the connection to the server. This connection
will be allowed by the firewall.
FTP is specifically designed for users to upload or download files to and from the server. If an
attacker could access the password file (/etc/passwd in Linux) and download it then they could
try a brute force decryption at their leisure. Similarly the windows SAM file (Security Account
Manager) in the registry could yield invaluable information to any attacker.

Alert: Our system must alert any access to „sensitive‟ folders or files.
Detection: The text „root‟, „cwd root‟, „passwd‟ or „cd c:\‟ in a packet contents would
indicate unusual activity. Any directory traversal to the System32 folder in Windows, or any
other sensitive folder, should be flagged.

( Saliou et al, p2) state that intruders often target poorly secured FTP servers. They attempt to
gain privileged access by trying multiple combinations of username and password.

Alert: Our system must alert any multiple attempted passwords as this is unusual activity.
Detection: This can be detected by counting the number of bad password attempts in a given
time. A threshold can be set according to the expected usage of the server, however I would
set it at a very low level. A user might mistype their password and this is to be expected, but

“Once is happenstance. Twice is coincidence. The third time it’s enemy action.”
Fleming (1959)

Also FTP server versions may be susceptible to buffer overflow attacks. (Microsoft 2009(1))
reports a buffer overflow vulnerability in the FTP server within IIS 5.x and IIS 6.x and IIS 7
which will allow arbitrary code to be run with SYSTEM privileges.

Alert: Our system must alert for possible buffer overflow attempts.
Detection: (Snort Rules, 2010) characterises the above FTP server NLST buffer overflow
attempt as a packet containing the text NLST, containing at least 200 further characters and,
from a decode of the given regular expression, within these 200 characters the text NLST
again, the newline character followed by a space and any non-newline character.

Telnet Server

The Telnet server is an application which uses TCP on port 23 to provide a command line
interface for a remote computer.
Telnet does not encrypt any traffic – not even passwords – and so anyone intercepting a logon
by using a packet sniffer could use these credentials to maliciously log on.
Telnet is also, like any software, vulnerable to exploits. Despite being a venerable (1969)
protocol, exploits are still being found in particular implementations. Recently (Microsoft,

e-Security Page 2
2009(2)) announced a vulnerability in their Telnet implementation which allowed an attacker to
obtain credentials of a logged on user and to log back in with identical user rights.
If an attacker can log on with an identity which has sufficient privileges, then they can do
virtually anything on the server. They can move to any directory and run any executable file,
create user accounts for subsequent logons, delete files and directories and so on.

Alert: Our system must alert when a user logs on or attempts to log on with privileged
access.
Detection: A login as root or administrator can be detected with the username in the content
of a packet.
Also multiple failed logins are unusual other than an attempted brute force password crack
attempt and so will be alerted as noted in the FTP section.

Web Server

The web server is an application which sends content requested by a client program using the
HTTP protocol. The client usually connects on port 80. HTTP, an application layer protocol,
usually uses the TCP/IP protocols to establish a reliable connection between the client and the
server.
HTTP is a stateless protocol which means that the server does not keep information about the
client between requests. If an application needs to track a clients progress from page to page
then this can be done using cookies or using URL encoded parameters e.g.
index.php?user_id=1234. Unfortunately these methods allowed by HTTP can be exploited.
Recently SQL injection attacks have been one of the top exploits against web applications
(sans.org, 2009).
SQL Injection occurs when a web application acting as a front end to a database accepts user
input, either by URL encoded parameters or by form input, which is not validated. This could
allow an attacker not only to modify, add or delete data but compromise the whole machine.
“Certain SQL Servers such as Microsoft SQL Server contain Stored and Extended
Procedures (database server functions). If an attacker can obtain access to these
Procedures it may be possible to compromise the entire machine.” (CGISecurity.com (2)
2008)
We must therefore alert any attempt at SQL Injection.

Alert: Our system must alert at any attempt at SQL Injection.

Detection: Applications that are vulnerable to this attack build their query string by
concatenating the application SQL query with the user input e.g.
SELECT * FROM ITEMS WHERE ( ItemName =" & userinput & "COLOUR = ORANGE);

If userinput isn‟t validated then it may contain invalid „dangerous‟ characters.

If I included a single quote in the userinput in the web page, such as „fred, then if the
database returns an error, since quotes must be paired, then we know immediately that the
application is vulnerable - the input hasn‟t been validated.

e-Security Page 3
 If I then try X OR 1=1;-- as the user input then I‟ll retrieve the whole table – because the
application will build the query:
SELECT * FROM ITEMS WHERE ItemName = X OR 1 = 1; -- (rest of applications SQL)
The -- comments out the rest of the applications SQL. Since 1=1 always evaluates as true,
every record will match this query. It is easy to move on from here to compromise the whole
database.
We therefore need to check packet contents for these „dangerous‟ characters or their hex
equivalents that would indicate an attempted SQL Injection – a single quote, double hyphen
or a semicolon.

In addition to server vulnerabilities, in this illustration of agent based IDS, alerts have to be
generated for:

 Detection of user administration access over the network.

 Reconnaissance of the system, including host scans and port scans.
 Detection of attacks against the Web server, including a possible Denial-of-Service (DoS)
attack.

User administration access

This is already covered in depth in the previous FTP and Telnet Server sections.

Reconnaissance of the system

System reconnaissance from outside the system is the first stage of any possible attack on a
system (Buchanan, 2010).
The attacker wants to find out which hosts are live, which ports are open on those hosts, which
services are running and the software versions of running services.
Once the attacker has this information then exploits against particular software versions (often
older unpatched versions) and services are widely available via the WWW.

Host Scan Attack Summary

A host scan is where an attacker is trying to reduce a list of possible IP addresses in a network
into a list of available hosts.
(Lyon, 2009) lists several methods used for host discovery. As well as the usual ICMP ping,
host discovery can also be achieved by variety of methods such as a TCP SYN packet to port
443 (https port). Any response - SYN/ACK or RST – would indicate that that host is live.
Similarly any reply from TCP packets sent to port 80 is significant. UDP packets can also be
used for host scanning. When a UDP packet is sent to a closed port it will receive a „Port
Unreachable‟ ICMP reply which indicates that the host is live and running.
It is typically characterised by one host to many hosts, usually in a short time scale. However
this is a „network‟ scan and since we are detecting traffic to our host system only, these would
not be detected.

e-Security Page 4
Port Scan Attack Summary
A port scan is used to determine which ports in a host are open or „Listening‟.
In a port scan there are many attempted port connections to a single machine from a single
source, often to unusual ports.
(Whitaker, 2005) lists several scan types including the following:
TCP Connect() scan, SYN, NULL, FIN, ACK, Xmas-Tree.

In a TCP Connect Scan the attacker follows the full SYN – SYN ACK – ACK TCP handshake.
If the handshake completes then the port is definitely open. However it leaves an open
connection on the host until the connection times out.
In a SYN scan a SYN packet is generated to initiate a connection. If the target port is open, it
will respond with a SYN-ACK packet. The attacker responds with an RST packet, closing the
connection before the handshake is completed.
In a Null scan the attacker sends a packet with no flags set. The TCP protocol states that if such
a packet is received then the receiving station should send an RST (a packet with the RST flag
set) if the port is closed. If no reply is received then the port is open. However (Nessus
Knowledge Base, 2009) states that Windows systems don‟t follow the protocol and send an
RST to all null packets. Thus if any open ports are detected by the SYN scan this indicates that
the system being scanned is definitely not a Windows system.
The FIN flag set in a TCP packet indicates the ending of a TCP session. If such a packet is sent
to a port, then an RST response indicates a closed port. No reply indicates that the port is
listening. (Whitaker, 2005) states that Windows systems do not comply with RFC 793 and so
do not provide accurate results for this type of scan.
An ACK scan is used to detect which ports are open on a firewall and so won‟t be entirely
relevant to our server, however for completeness a packet sent with the ACK flag set, then there
will be no reply from a filtered port. If the port is unfiltered then an RST is returned by the
firewall.
In a Xmas Tree Scan a packet is sent with all flags set, although nMap only sets the URG, PSH
and FIN flags for this scan (Lyon, 2009). It returns the same results as the NULL, FIN and
ACK scans so is not reliable against Windows systems.

Alert: Port scans should be alerted by the system.

Detection: The „non-normal‟ packets e.g. a null packet, can be detected by the TCP flag
settings. Also a port scan will be detected by „one to many‟ port access attempts in a short
time interval.

Attacks against the web server including Denial of Service

There are two main types of attacks against web servers:

1. Web application exploits where an application running on the server is compromised,
potentially allowing access to server files and resources or leading to an application crash
thus denying service to all.

e-Security Page 5
2. Resource starvation exploits where bandwidth or host resources such as memory or CPU
time are consumed thus denying normal service to genuine site users.

Web Application Exploits

(SANS Institute, 2009) states that Web application vulnerabilities such as SQL injection and
Cross-Site Scripting (XSS) flaws in applications account for more than 80% of the
vulnerabilities being discovered.
SQL Injection has already been covered in detail in a previous section.
In Cross-Site Scripting an attacker can use the URL encoded parameters to inject a script into a
dynamically created web page in a similar manner to SQL Injection. This time, however,
instead of SQL code, it is JavaScript, PHP, VBScript or ASP code that is injected into the
application via the user input. Any site that accepts user input and displays it is vulnerable to an
XSS attack if the input is not properly validated.
(Spett, 2005) describes how, when a user is tricked into following a link in disguised format in
e-mail messages, newsgroup postings or various other media, how easy it is to compromise the
users session.
As a simple example of XSS, imagine that I have found a site – http://www.vulnerablesite.com
with the usual search facility where you enter a search term and click „search‟.
If I type a term that will not be found – kshadfg for example – the site will generate a page
saying something like „kshadfg not found‟. You‟d notice that the URL at the top of your web
page would be similar to http://www.vulnerablesite.com/search.asp?error=
kshadfg%20not%20found
The text „kshadfg not found‟ will have been generated by the application to create the returned
html page.
Now if we enter the search term <script> alert(„You have been hacked by Phil‟) </script>,
the generated HTML will include the text <script> alert(„You have been hacked by Phil‟)
</script> which, when rendered by the users browser, will execute the script and a pop up box
with the message „You have been hacked by Phil‟ will appear on the screen.
If we can now get an unsuspecting user to click on the URL:
http://www.vulnerablesite.com/search.asp?error= <script> alert(„You have been hacked by
Phil‟) </script>, vulnerablesite.com will generate the html as outlined above and we will have
run our script on the unsuspecting users computer.
It is very easy to move on from here to „Cookie Steal‟ from a legitimate user of our web server
and effectively take over the session with that user‟s security status. This could lead to account
hijacking or other malicious activity on the server (CGISecurity.com (1) 2003).

Alert: Our system must alert any Cross-Site Scripting attempt.

Detection: Most XSS attacks can be detected by monitoring for the characters <script>, <? ,
<% or their hex equivalents in requests to the web server.

Denial of Service – Bandwidth and Resource starvation exploits

(McDowell, 2004) explains that the most common denial of service attack is when an attacker
floods a host with requests.

e-Security Page 6
A bandwidth attack floods the network with such a high volume of traffic that genuine users
can‟t get through. Often these will be ICMP ECHO requests (pings).
Singh (2005) gives an example of a „smurf attack‟ where the attacker sends an ICMP echo
request, with the source address spoofed to be that of the victim, to a network broadcast address.
The request is broadcast to all stations on the network and each replies to the spoofed (victim‟s)
IP address, so acting like an amplifier for the attack.
Other system resources may be attacked. In a SYN flood attack, the attacker starts a TCP
connection by sending a SYN with a spoofed IP source address. The server will respond with a
SYN-ACK to the spoofed address and so will not receive the required ACK reply to complete
the connection as required by the TCP protocol. This leaves a „half open‟ connection the server
which uses up one of a limited number of data structures needed to complete the connection
until the connection request times out. If many of these SYN packets are sent, then all available
resources are consumed and legitimate users cannot connect. (Computer Emergency Response
Team, 1999).
In a distributed DOS attack, master machines (handlers) will control many „zombie‟(agent)
machines which have been compromised earlier and can start a coordinated attack from
possibly thousands of agents in a „botnet‟. This amplifies the attack many times over and makes
tracing the original attacker very difficult.

Figure 1 - Singh (2005)

Alert: Denial of Service attacks should be alerted.

Detection: Detection of a denial of service attack is difficult. How can you tell which
packets are legitimate and which are not? „Fingerprints‟ for some known attacks are
available, for example the well known Stacheldraht Distributed DOS uses ICMP sequence
values for communication (SNORT Manual 2009) and can be detected. An exploit DOS

e-Security Page 7
 attack via Real Audio Server will contain the hex values FF F4 FF FD 06. However at the
IDS level apparently genuine requests, although part of a DOS attack, cannot be
distinguished from actual genuine ones. A frequency count of requests from each IP address
might help in a simple DOS attack but may be of little value in detecting a DDOS attack
because of the thousands of clients involved. The workload on tracking these may quickly
outstrip the capability of the system.

Design

To illustrate this system I will use three computer systems.

System 1 – A server running Web, TCP and Telnet servers and the IDS software. I will use
Windows Server 2003 Enterprise Edition running in a virtual machine. The IDS
software needs to detect traffic only for our server and so will sit on the same
virtual machine and „sniff‟ on the server‟s network card. For the intrusion detection
software I will use Snort, as it is used extensively in live systems and will be more
realistic than a custom written package.
System 2 – An attack system to simulate the attacks outlined in the Requirements Analysis
section. It will be a PC on the local area network running Backtrack4 from
http://www.backtrack-linux.org/ , which is a customised Linux security distribution
specifically designed for penetration testing. It contains all the tools required to
generate the network traffic required to test the threats identified in the
Requirements Analysis including nMap for port scanning, XHydra for password
cracking/ privilege escalation and Nemesis for packet crafting.
System 3 – The command computer running the „alerting‟ software. This will be another PC on
the network that will be accessing Snort log files and displaying appropriate alerts.
A lightweight application is required for this and I shall develop it in .NET. I will
adopt a „pull‟ methodology, pulling new reports from the IDS at a frequency that
can be chosen. If I used a „push‟ methodology whereby the alerting software alerted
every single change in the log immediately that it happened, it could become rather
annoying to the user.

For System 1
System 2 will be a computer on the local area network.
System 3

e-Security Page 8
Location of detection – not promiscuous – want traffic to server only so local network card.
So the home network will simply be the ip address of the server and the external network will
be any source which is not the server. --INTERNAL attack. Must draw detection as close to
server as possible as this is asset we're protecting.

If your organization has an Internet connection or one or two disgruntled employees (and
whose doesn't!), your computer systems will get attacked. From the five, ten, or even one
hundred daily probes against your Internet infrastructure to the malicious insider slowly
creeping through your most vital information assets, attackers are targeting your systems with
increasing viciousness and stealth.

Implementation
3 computers. Server, attacker, monitor. Implemented as virtual machines, or attacker my laptop?
Does using laptop add anything?
IDS to alert on monitor system.

Local Snort rules to be numbered from 1000001 up, since 100-1000000 are reserved for rules
included in the Snort distribution (Snort Manual, 2009).
For ftp buffer overflow - alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP
NLST overflow attempt"; flow:to_server,established; content:"NLST"; nocase;
isdataat:200,relative; pcre:"/^NLST(?!\n)\s[^\n]{200}/smi"; metadata:policy balanced-ips drop,
policy connectivity-ips drop, policy security-ips drop, service ftp; reference:bugtraq,7909;
reference:cve,1999-1544; reference:cve,2009-3023;
reference:url,www.kb.cert.org/vuls/id/276653;
reference:url,www.microsoft.com/technet/security/bulletin/MS09-053; classtype:attempted-
admin; sid:2374; rev:15;)

For password brute force – but change count and time-

alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:“FTP sa brute force failed login
unicode attempt”; flow:to_server,established; content:“PASS”; reference:url; threshold:type
threshold, track by
_src, count 6000, seconds 1200; priority: 1; classtype:attempted-user; sid:2000001;)

SQL Injection -
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"NII SQL
Injection - Paranoid"; flow:to_server,established; pcre:"/(\%27)|(\')|(%2D%2D)|(\-\-)/i";
classtype:web-application-attack; sid:7002; rev:1;)

e-Security Page 9
Evaluation
Should also assist mitigation by e.g. SnortSam for active configuration of routers to block
detecte attackers.

[From snort dos.html in C:\Documents and

Settings\Phil\Desktop\MSc\e_Security\Coursework\snort dos_files]
Also from same source for other project:
People who wish to rebuild content typically want to parse Libpcap trace files to rebuild TCP
sessions. One of the best tools for this job is Tcpflow. Tcpflow can be run against a dead trace
or a live interface. If given no parameters, Tcpflow will rebuild all TCP sessions it sees, putting
the content from client to server in one file and the content from server to client in another file.
Tcpflow repeats this process for every single TCP session it finds.
What can Snort do about DDoS attacks? Snort's Vulnerability Research Team publishes a set of
rules named ddos.rules. This file contains a small set of signatures for detecting activity caused
by older DoS tools like Tribe Flood Network, Shaft, Trinoo and Stacheldraht. Emerging
Threats publishes bleeding-dos.rules, which contains a greater variety of rules. However, the
question remains: What good are rules like these?
When users or potential users ask if Snort protects against DoS attacks, they usually want to
know if Snort can deflect or mitigate bandwidth consumption attacks. The answer to this
question is probably no. When deployed as an offline, passive device, there is little or nothing
Snort can do to stop or reduce a bandwidth-consuming SYN flood, for example. Snort can
potentially report seeing many SYN segments, but it won't improve the situation. The rules
packaged in ddos.rules and bleeding-dos.rules are designed to either detect DoS agent
command-and-control or possibly identify certain types of attacks that subvert but do not
breach a target.
When deployed as an inline, active device, Snort acts as a so-called intrusion prevention system
and can, in some cases, stop DoS attacks. For example, an intruder may use a malicious packet
to cause a vulnerable Cisco router to reboot or freeze. An inline Snort deployment could
identify and filter the malicious packet, thereby "protecting" the router. If the intruder switched
to a SYN flood or other bandwidth consumption attack against the router, however, Snort
would most likely not be able to counter the attack -- at least not on its own.
2. Can Snort decode encrypted traffic?
Let's assume that encrypted traffic means Secure Sockets Layer (SSL) or Transport Layer
Security (TLS) as used by HTTPS, or Secure Shell protocol 2 as used by OpenSSH.
The short answer is no, Snort cannot decode encrypted traffic. An intruder who attacks a Web
server in the clear on port 80 TCP might be detected by Snort. The same intruder who attacks
the same Web server in an encrypted channel on port 443 TCP will not be detected by Snort.
An intruder who displays the contents of a password file via a Telnet session on port 23 TCP
might be detected by Snort. The same intruder who displays the same password file via a SSH
session on port 22 TCP will not be detected by Snort.

e-Security Page 10
Naïve- eg (from http://www.symantec.com/connect/articles/demystifying-denial-service-
attacks-part-one)

3.2.1 Protecting Microsoft Windows from a SYN Flood attack

Microsoft Windows has a mechanism to detect and start SYN Flood protection. The SYN
flooding attack protection feature detects symptoms of SYN flooding and responds by reducing
the time the server spends on connection requests that it cannot acknowledge.

Specifically, TCP shortens the required interval between SYN-ACK (connection request
acknowledgements) retransmissions. TCP retransmits SYN-ACKS when they are not answered.
As a result, the allotted number of retransmissions is consumed more quickly and the
unacknowledgeable connection request is discarded faster.

When enabled, the system monitors the connections maintained by TCP and starts the SYN
attack flooding protection when the any of the following conditions, symptomatic of SYN
flooding, are found:

 The total number of connections in the half-open (SYN-RCVD) state exceeds the value of
TcpMaxHalfOpen
 The number of connections that remain in the half-open (SYN-RCVD) state even after a
connection request has been retransmitted exceeds the value of TcpMaxHalfOpenRetried
 The number of connection requests the system refuses exceeds the value of
TcpMaxPortsExhausted. The system must refuse all connection requests when its reserve of
open connection ports runs out.

Microsoft suggests the following registry settings:

hkey_local_machine \system \currentcontrolset \services \tcpip \parameters

\synattackprotect=1 REG_DWORD hkey_local_machine \system \currentcontrolset
\services \tcpip \parameters \tcpmaxconnectresponseretransmissions=2
REG_DWORD hkey_local_machine \system \currentcontrolset \services \tcpip
\parameters \tcpmaxdataretransmissions=3 REG_DWORD

References:

Buchanan W. (2009) CSN11102 e-Security Course Notes Edinburgh: School of Computing,

Napier University

Computer Emergency Response Team (1999) Denial of Service Attacks [Internet] Available at
<http://www.cert.org/tech_tips/denial_of_service.html> [Accessed 12 April 2010]

CGISecurity.com (1) (2003) The Cross-Site Scripting (XSS) FAQ [Internet] Available at
<http://www.cgisecurity.com/xss-faq.html> [Accessed 31 March 2010]

e-Security Page 11
CGISecurity.com (2) (2008) What is SQL Injection? [Internet], Carnegie Mellon University,
Available at <http://www.cgisecurity.com/questions/sql.shtml> [Accessed 31 March 2010]

Denning D. (1987) An Intrusion-Detection Model. IEEE Transactions on Software Engineering,

Vol. SE-13, No. 2, February, pp.222-232.

Fleming, I (1959) Goldfinger, Jonathan Cape, London.

Julish K. (2003) Clustering intrusion detection alarms to support root cause analysis. ACM
Transactions on Information and System Security 6,4

Kruegel, C. Valeur, F. & Vigna, G. (2005) Intrusion Detection and Correlation – Challenges
and Solutions, University of California, Santa Barbara, Springer

Lyon G. (2009) Nmap Network Scanning [Internet] Available from

<http://nmap.org/book/toc.html > [accessed 23 March 2010]

McDowell (2004) National Cyber Alert System – Cyber Security Tip ST04-015 [Internet]
Carnegie Mellon University, Available at < http://www.us-cert.gov/cas/tips/ST04-015.html>

Microsoft (2009 (1)) Security Bulletin MS09-053 Microsoft Internet Information Server FTP
Buffer Overflow [Internet] Microsoft. Available from
<http://www.microsoft.com/technet/security/bulletin/ms09-053.mspx> [Accessed 29 March
2010]

Microsoft (2009 (2)) Security Bulletin MS09-042 Vulnerability in Telnet Could Allow Remote
Code Execution (960859) [Internet] Microsoft. Available from
<http://www.microsoft.com/technet/security/bulletin/ms09-042.mspx> [Accessed 29 March
2010]

Nessus Knowledge Base (2009) Nessus Knowledge Base – Synlogger [Internet] Available at
http://www.edgeos.com/nessuskb/results.cgi?gui_section=&kw=synlogger&nessusrc_section=
[Accessed 7 April 2010]

Network Intrusion Detection, 3rd Edition

By Stephen Northcutt, Judy Novak
Published Aug 27, 2002 by Sams.

RFC 959 (1985) RFC959 [Internet] Available from <http://www.rfc-editor.org/rfc/rfc959.txt>

[accessed 23 March 2010]

Saliou L, Dr Buchanan W, Graves J, Dr Munoz J Novel Framework for Automated Security

Abstraction, Modelling, Implementation and Verification [Internet] ECIW 2005: The 4th

e-Security Page 12
European Conference On Information Warfare & Security Available at < http://www.academic-
conferences.org/eciw2005/eciw2005-home.htm> [Accessed 22 March 2010]

SANS Institute (2009) The Top Cyber Security Risks [Internet] SANS Institute. Available at
<http://www.sans.org/top-cyber-security-risks/?ref=top20 > [Accessed 29 March 2010]

Sing, A. (2005) Demystifying Denial-Of-Service attacks [Internet] Symantec. Available at <

http://www.symantec.com/connect/articles/demystifying-denial-service-attacks-part-one>
[Accessed 12 April 2010]

Snort Manual (2009) SNORT Users Manual [Internet], Sourcefire Inc. Available from
<http://www.snort.org/assets/125/snort_manual-2_8_5_1.pdf > [Accessed 14 March 2010]

Spett K. (2005) Cross Site Scripting – Are your web applications vulnerable?, Atlanta, SPI
Dynamics.

Security Focus (2009) http://www.securityfocus.com/advisories/3641

Whitaker A. and Newman D. (2005) Penetration Testing and Network Defense [sic],
Indianapolis, Cisco Press (in coursework folder – penetration testing.htm)

Wireshark University (2007) WSU04: Wireshark Network Forensics - Appendix F: Snort Rules
[Internet] Protocol Analysis Institute, Inc. , Available at
http://www.securisite.org/biblioteca/Wireshark/shark_net_forensics_and_security/pdf_files/Ap
pendix%20F%20-%20Sample%20Snort%20Rules.pdf [Accessed 6 April 2010]

Snort Rules (2010) Snort Rules, [Internet], Snort.Org

Copyright 2003
Dimensions: Special (all other)
Pages: 512
Edition: 3rd
Book
ISBN-10: 0-7357-1265-4
ISBN-13: 978-

http://www.securityfocus.com/infocus/1855

Sebek 3: tracking the attackers, part one

e-Security Page 13
Raul Siles, GSE 2006-01-16
http://www.securityfocus.com/infocus/1898
Integrating More Intelligence into Your IDS, Part 1
Don Parker and Ryan Wegner 2008-03-05

Identifying p2p

http://www.securityfocus.com/print/infocus/1843

e-Security Page 14