Web Server Attacks and Mitigation Using Snort
Content
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:attemptedadmin; sid:2374; rev:15;) For password brute force – but change count and timealert 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-serviceattacks-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.academicconferences.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: 978http://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
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:attemptedadmin; sid:2374; rev:15;) For password brute force – but change count and timealert 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-serviceattacks-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.academicconferences.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: 978http://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
