CSEC640 Lab 2

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)


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.


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.


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.


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.


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.


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;)


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.


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

Documents

CSEC640 Lab 2