LAB 2 – SNORT
Randy Rose
CSEC640, Monitoring, Auditing, Intrusion Detection, Intrusion Prevention, and Penetration Testing
Section 9042
22 March 2015
Randy Rose CSEC640 Lab 2
Question 1 [10%] What does each of the flags in this snort command line do? Answer one by one clearly in a list or table
format. Document the source of your information as well.
snort -r snort.out -P 5000 -c csec640.rules -e -X -v –k none -l log
FLAG Description -r This switch tells Snort to read the output file snort.out rather than run on the
live network link. From an analysis perspective, this is often the best way to determine exactly what occurred during an actual or potential cyber security incident.
-P This switch sets the explicit packet snap length to that specified in the variable element, in this case 5000 bytes. If no value is specified, a default snap length of 1514 bytes is used. Snap length is the actual length in bytes of the packet data captured and stored by the tool.
-c This switch calls the configuration or rules files specified in the variable element.
-e This switch turns on the display and logging option for Layer 2 (Link Layer) packet headers.
-X This switch tells Snort to present all raw packet data from Layer 2 up through the TCP/IP stack.
-v This switch is seen in many tools. It tells Snort (and other tools) to be verbose, or effusive. In other words, it is a request for the tool to provide more information to the user than normal and to display this information on the screen and in the logs. Verbosity can slow down performance, thus the –v switch is not recommended when using Snort as an Intrusion Detection System (IDS).
-k This switch configures checksum mode. Options for checksum mode include all, noip, notcp, noudp, noicmp, and none. -k all is used for checksum verification for all supported protocols. -k noip turns off IP checksum verification only. -k notcp disables TCP checksum verification only. -k noudp disables UDP checksum verification only. -k noicmp disables ICMP checksum verification only. -k none disables checksum verification altogether. In this case, the checksum mode is set to none, indicating that checksums will not be used at all.
-l This switch tells Snort to log output to the specified directory. The default logging directory is /var/log/snort.
(Snort Version 2.9.6.2)
Randy Rose CSEC640 Lab 2
Question 2 [60% - 10% for each of the 6 Snort rules]
There are several distinct packet signatures in the packet trace file. In the trace file, there are 30 packets
total. Your task is to create 6 new snort rules that will uniquely identify 6 different packet signatures. One
Snort rule is already shown as an example (i.e., alert icmp any any -> 192.168.10.2 any (msg:"ping
detected"; itype:8; sid:999;)). Since you were already provided with the example snort rule, you need to
“comment out” that the example rule in the csec640.rules file by putting the “#” at the beginning of
the line in front of the word “alert”. Look though the packet trace to identify the other rules. Look for
more general signatures where you can, however, be careful not to write signatures that are too general
(e.g., no 3 “any”s in a single rule). Part of the intent of the lab is to learn how to write effective rules. It
is easy to write a rule that matches all TCP or IP datagrams regardless of content, but this would be a very
ineffective rule at detecting anomalous or malicious activity.
Include in your answer the 6 additional rules you have created and c:\snort\bin\log\alert.ids output
(include the screenshots of the alert output for each rule in your answer). The alert output file is
appended each time snort has output, so you want to erase the alert file by typing del
C:\snort\bin\log\alert.ids before each snort run while experimenting with different rules. Be sure to
include a descriptive message ("msg" and “sid:xxx”) with each alert. In addition, briefly explain each rule
you write.
Rule #1: alert tcp 192.168.1.5 any -> 192.168.10.2 any (flags:RP;
msg:"Potential TCP Reset attack"; sid:9999999;)
This rule alerts on all TCP packets coming in to the victim host with both the RST and PSH flags set. There are legitimate reasons for packets to have both flags set, such as breaking up suspicious or malicious connections without compromising communications to all connections. However, floods of packets containing both RST and PSH flags are indicative of a TCP Reset attack, which is essentially a Denial of Service (DoS) attack. This rule can be useful in identifying external hosts pushing potentially malicious TCP Reset packets to the destination host. Once additional sources are identified, the leftmost portion of the rule can be appended to target those source addresses, such as alert tcp 192.168.1.10 any -> 192.168.10.2 any.
Randy Rose CSEC640 Lab 2
Rule #2:
alert tcp 192.168.1.5 any -> 192.168.10.2 80 (msg:"GET Linux Remote
Users"; content:"GET"; content:".rhosts"; sid:9999998;)
This rule will alert on TCP traffic from source 192.168.1.5 on any port going to destination 192.68.10.2 on port 80 which contains a GET request for the Linux remote hosts file (/.rhosts, /root/.rhosts, or /etc/.rhosts). This rule is not practical for normal IDS functionality but may be useful if the suspected attack vector is through malicious GET requests or it is suspected that the rhosts file was surreptitiously accessed or even compromised.
Randy Rose CSEC640 Lab 2
Rule #3: alert icmp 192.168.1.255 any -> 192.168.10.2 any (msg:"ICMP flood";
content:"|2121 2121|"; sid:9999997;)
This rule alerts on ICMP packets with the bytecode string 2121 2121 in the data payload coming from 192.168.1.255 and going to 192.68.10.2. 2121 2121 is represented in the ASCII text as !! !!. This content is clearly not a command to the destination to perform any response function. This is a useful rule for detecting actual or potential ICMP-based DoS attacks.
Randy Rose CSEC640 Lab 2
Rule #4: alert icmp 192.168.1.5 any -> 192.168.10.2 any (msg:"ICMP
Fragmentation needed"; Itype:3; Icode:4; sid:9999996;)
This rule alerts on any ICMP traffic with the code value set to 4, which indicates packet
fragmentation is needed. According to RFC 1812, routers are required to use this code
with the “Don’t Fragment” flag set originating Code 4 “Destination Unreachable” (type
3) messages. The results below show this in effect with the language: “DESTINATION
UNREACHABLE: FRAGMENTATION NEEDED, DF SET” (Baker, 1995, p. 82).
Rule #5: alert udp 255.255.255.255 any -> 192.168.10.2 any (msg:"BOOTP
Malformed Packet"; ttl:1; content:"|44|"; sid:9999994;)
This rule identifies malformed Bootstrap protocol packets throwing the error “Unknown
message type” with a TTL value of 1 and only traversing over UDP from source host
255.255.255.255 (which is a broadcast address) to destination 192.168.10.2. This rule is
useful in identifying potential or actual DHCP-based attacks or some other indicators of
packet corruption.
Randy Rose CSEC640 Lab 2
Rule #6: alert udp 192.168.1.5 53 -> 192.168.10.2 53 (msg:"Potential DNS
Malformed Packet Flood"; content:"|04 08 13 2f 62 69 6e 2f 73 68|";
sid:9999993;)
This rule alerts on potential DNS malformed packet flooding attack traffic over UDP on
port 53 from source 192.168.1.5 to 192.168.10.2 on port 53. Port 53 is the default DNS
port and UDP is the default DNS transport layer protocol. This attack essential involves
causing a DoS by sending packets without actual DNS queries in the payload. The
content string in this specific rule is |04 08 13 2f 62 69 6e 2f 73 68|. This
translates to the ASCII values …/bin/sh, which indicate attack traffic as that string is
not a valid DNS query.
Randy Rose CSEC640 Lab 2
Question 3 [20%] The threat expert links above describes Gimmiv.a as:
“….it could technically be classified as a network-aware trojan that employs functionality of a
typical RPC DCOM network-aware worm to attack other hosts in the network.”
Describe your interpretation of the above quote. Focus on the behavior and explain how the code could
impact a network. Explain in a few paragraphs what specific techniques you may use to detect the above
threat caused by Gimmiv.a. What snort rule(s) should you use to prevent (or detect) the above threat? You
will have to do research to explain your answers sufficiently. RPC is Microsoft’s answer to client-server communication on a Microsoft domain an DCOM allows software and software components to communicate directly with other network distributed software over RPC. Thus, the quote above indicates that Gimmiv.A acts more like a worm that leverages the capabilities of RPC and DCOM streamlined network communications than it acts like typical Trojans, which require user interaction for distribution. To my knowledge, this was a unique method of infection from a Trojan as previous Trojans may have been “network-aware” but did not mirror worms in their copious use of network vulnerabilities for widespread distribution. Gimmiv.A leverages a Microsoft vulnerability that allows remote code execution (Microsoft, 2008). Peter Silberman suggests the following Snort signature for detecting Gimmiv.A Trojan activity on a local system: alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN
Gimmiv.A.dll Infection"; flow: to_server,established; uricontent:"/test";
uricontent:".php"; uricontent:"?abc="; uricontent:"?def=";
reference:url,www.microsoft.com/security/portal/Entry.aspx?name=T
rojanSpy%3aWin32%2fGimmiv.A; classtype:trojan-activity; sid:2008689; rev:2;)
According to the blog post by Sergei Shevchenko provided in this lab, Gimmiv.A sends a
malicious RPC request with a network canonicalization request for the path
\c\..\..\AAAAAAAAAAAAAAAAAAAAAAAAAAAAA. This request could easily be flagged by
Snort using the ASCII or bytecode strings. Therefore, I would modify Silberman’s rule to
the following for capturing this step:
alert tcp $HOME_NET any -> $HOME_NET 139 (msg:"Gimmiv.A RPC
NetPathCanonicalize"; content=”\c\..\..\AAAAAAAAAAAAAAAAAAAAAAAAAAAAA”;
reference:url,www.microsoft.com/security/portal/Entry.aspx?name=T
rojanSpy%3aWin32%2fGimmiv.A; classtype:trojan-activity; sid:2008690;)
Shevchenko also notes that Gimmiv.A begins probing other hosts by sending them sequences of bytes containing the strings “abcde” and “12345.” This traffic can be detected using the following rules: alert tcp $HOME_NET any -> $HOME_NET any (msg:"Gimmiv.A probe";
content=”abcde”; sid:2008691;)
Randy Rose CSEC640 Lab 2
alert tcp $HOME_NET any -> $HOME_NET any (msg:"Gimmiv.A probe";
content=”12345”; sid:2008691;)
(Shevchenko, 2008). Question 4 [10%] You learned a covert channel in Week 6. Do you think IDS like Snort can easily detect a covert channel?
For example, can you write an effective set of Snort rules to prevent any information leak through a
covert channel? Explain your answer in detail and support your answer with research and documentation.
Snort IDS, and other IDS products, can be used to detect covert channel activity. Covert
channels still rely on legitimate TCP and UDP communications, so effectively written
IDS rules can identify when illegitimate content is masked or obfuscated within
legitimate packets. While there are limitations to using signatures for detection due to
the rapidly changing nature of threats, knowledge of known covert markers can lead to
well-written signatures for signature-based, or knowledge-based, detection. Knowledge
of the protocols and expectations of legitimate traffic can lead to well-written signatures
for anomalous detection via behavior-based IDS (Borders & Prakash, 2004, p. 111;
Jasolka & Khedri, 2011, pp. 1-2; Rowland, 1997; UMUC, n.d., p. 5).
Signature-based markers can include alerts similar to the following which identifies
HTTP GET requests hidden in ICMP packets:
alert icmp any any -> $HOST_ADDR any (msg:”Covert ICMP traffic”;
content:”GET”; content:”HTTP/1.1”; sid:9999999)
Similar rules can be written for TCP and UDP and can go in either direction. Similarly,
the content can be changed to include known bytecode patterns or other types of data
being passed covertly over ICMP, including directory traversal (i.e. \..\..\etc\) and
similar attacks.
Behavior-based IDS rules can include the negation option ! for detecting covert activity.
For example, if expected ICMP ping content is the string “abcdefghijklmnop,” then the
following rule can be used to detect ping packets without that string:
Alert icmp any any -> $HOST_ADDR any (msg:”Potential covert ICMP
traffic”; content:!“abcdefghijklmnop”; sid:9999998)
As above, these rules can be adjusted based upon protocol, address, and content to
match the desired output alerts.
Randy Rose CSEC640 Lab 2
References
Baker, F. (Ed.). (1995). Requirements for IP version 4 routers [RFC1812]. Retrieved from
http://www.networksorcery.com/enp/rfc/rfc1812.txt
Jaskolka, J., & Kedri, R. (2007). Exploring covert channels. Proceedings of the 44th Hawaii
International Conference on System Sciences (pp. 1-10). Retrieved from
https://learn.umuc.edu/content/enforced/57193-026826-01-2152-GO2-9042/
Week%206/Jaskolka2011-exploring-covert-channels.pdf?_&d2lSessionVal
=t0wDtiwx40wEL5GoDKb4V085K&ou=57193
Microsoft. (2008). Microsoft security bulletin MS08-067 – critical. Retrieved from
https://technet.microsoft.com/library/security/ms08-067
Rowland, C. H. (1997). Covert channels in the TCP/IP protocol suite. First Monday Peer-
Reviewed Journal on the Internet, 2(5). Retrieved from http://www.firstmonday.org/
htbin/cgiwrap/bin/ojs/index.php/fm/article/view/528/449
Shevchenko, S. (2008). Gimmiv.A exploits critical vulnerability (MS08-067). ThreatExpert
Blog. Retrieved from http://blog.threatexpert.com/2008/10/gimmiva-exploits-zero-
day-vulnerability.html
Silberman, P. (2009). Snort my memory [PDF document]. Retrieved from
https://www.blackhat.com/presentations/bh-dc-09/Silberman/BlackHat-DC-09-
Silberman-Snort-My-Memory-slides.pdf
Snort (Version 2.9.6.2) [Computer software]. San Jose, CA: Cisco Systems, Inc.
Snort. (2014). Writing Snort rules. Retrieved from http://manual.snort.org/node27.html
UMUC. (n.d.). CSEC 640 monitoring, auditing, intrusion detection, intrusion prevention, and
penetration testing: Intrusion detection and prevention systems [Computer-based
training module]. Retrieved from https://leoprdws.umuc.edu/
Wireshark. (2010). SnapLen. Retrieved from https://wiki.wireshark.org/SnapLen
Recommended