Beruflich Dokumente
Kultur Dokumente
(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.
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.
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:
This is already covered in depth in the previous FTP and Telnet Server sections.
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.
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.
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.
(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.
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
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;)
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.
e-Security Page 10
Naïve- eg (from http://www.symantec.com/connect/articles/demystifying-denial-service-
attacks-part-one)
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.
References:
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]
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
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]
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]
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.
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]
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
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