-----Original Message-----
From: snort-users-bounces@lists.sourceforge.net
[mailto:snort-users-bounces@lists.sourceforge.net] On Behalf Of mark antony
Sent: Friday, August 18, 2006 1:00 AM
To: snort-users@lists.sourceforge.net
Cc: snort-users-admin@lists.sourceforge.net
Subject: [Snort-users] Request for urgent help.
Respected sir
I am am new to use this snort. I have no idea how to use this. I need
some information regarding this question. If i dont do this i am gonna fail the
subject. The university did not provided any guidence on how to use the snort.
I dont know anything. Please some one help me out.
You are a security specialist working for ABC Incorporated. ABC use
SNORT as their NIDS which protects their IP sub-network being in the range of
203.40.27.128 - 203.40.27.255.
Is it September already?
(a)
A recent security vulnerability has been found in OpenSSH. A junior
staff member within the security team developed a new SNORT rule to detect this
attack. Your supervisor has asked you to check the work of the junior staff
member to ensure there are no errors in the SNORT rule.
The security vulnerability is described as follows:
A buffer overflow has been detected in the OpenSSH server. Exploits
have been released and exhibit the following characteristics:
<!--[if !supportLists]-->· <!--[endif]-->A payload positioned
100 bytes from the start of the data with a string message "You are mine"
<!--[if !supportLists]-->· <!--[endif]-->After the above
payload, there is a variable field of 4 bytes specifying a return address.
These 4 bytes can be any value.
<!--[if !supportLists]-->· <!--[endif]-->Following the variable
4 bytes return address is the exploit code signature given in HEX as AB 8F 23
8A BC 92
The rule should:
<!--[if !supportLists]-->· <!--[endif]-->when triggered, drop
and then log the packet only.
<!--[if !supportLists]-->· <!--[endif]-->detect attacks from
inside and outside their private network.
<!--[if !supportLists]-->· <!--[endif]-->include a message with
the log entry as "OpenSSH exploit attempt".
<!--[if !supportLists]-->· <!--[endif]-->include a reference to
the CVE number CAN-2006-06-3318
<!--[if !supportLists]-->· <!--[endif]-->Have a classification
of attempted-admin
The rule written by the junior staff member is as follows:
alert udp !203.40.27.0/24 any -> 203.40.27.128/24 23 (msg: "OpenSSH
exploit attempt"; cve:CAN-2006-06-3318; classtype: attempted-admin; content:
"You are mine"; depth: 12; offset:100; content: "AB 8F 23 8A BC 92"; depth:6;
offset:4;)
The rule above contains 8 syntax or logic errors. Your task is to
review the above rule and identify these errors which may prevent the rule from
detecting legitimate attacks, or will cause false positives. For all the
mistakes, identify the error, explain why it is wrong, and then fix the error.
EXAMPLE:
Here is a sample rule with a mistake in it.
alert udp any 53 -> any 53 (msg: "DNS attack"; content: "XYZ";)
Here is an example of the solution format:
Error 1: alert udp any 53 ->
The source port is given as 53, however requests to a DNS server from a
client will use ephemeral ports, and therefore should be given as any. To
correct this mistake, the rule should read:
Solution 1: alert udp any any -> any 53
Make sure to:
<!--[if !supportLists]-->· <!--[endif]-->Number each of the
errors you find as shown above (ie. Error 1)
<!--[if !supportLists]-->· <!--[endif]-->Provide a copy of the
portion of the rule which contains the error. Be sure to include keywords
around the error to make it clear which part of the rule you are referring to.
If you prefer, for each error, re-write the entire rule and highlight the error
(see next point)
<!--[if !supportLists]-->· <!--[endif]-->Highlight in some way
the specific part of the rule you are referring. In the example above, the
source port number "53" was underlined. If you do not make it clear which part
of the rule is incorrect, no marks can be given.
<!--[if !supportLists]-->· <!--[endif]-->Be sure to include a
clear explanation of why the rule was wrong and how it should be fixed
<!--[if !supportLists]-->· <!--[endif]-->Re-write the portion
of the rule again with the correction included and highlighted (ie underlined)
MARKING CRITERIA:
Each correctly identified error with a clear explanation and a correct
fix for the error will be assigned a ¼ mark. No part marks will be assigned,
so if you correctly identify the error, but do not provide an appropriate fix
or your explanation of the error is vague or incorrect, no marks will be
assigned.
(b)
(4 marks)
Your supervisor asks you to implement a SNORT IDS rule to detect and
alert all attempts at exploiting the vulnerability as described below for any
computer on the internal network. He then asks you to write an explanation of
each component of the rule, so other security specialists in your team can see
how your rule is written. The rule should notify the security team when an
attempt is made using the message: "NEW PING O' DEATH EXPLOIT ATTEMPT". Be
sure to allocate an appropriate sid value and a revision number for your new
rule, the appropriate class type for this attack, and that you include the
appropriate CVE id and a nessus vulnerability scanner id as described below.
A new atomic denial of service attack has been discovered. It behaves
similarly to the Ping o' death exploit that caused great chaos many years ago -
once the victim's computer receives the exploit packet, it will immediately
crash. Thus, it has been named "New Ping o' Death" and has a CVE of
"2006-0721" and nessus id of "21091". The attack is a single ping request with
an invalid code field. Current variants of the exploit have been using a code
field value of '1001' (expressed here in binary), however your rule should
detect all ping requests with an invalid code field value. Furthermore, to
exploit the vulnerability the type of service value should be set to "Minimise
delay".
An example of how to layout your solution follows:
var HOME_NET 138.77.23.0/16
var EXTERNAL_NET !138.77.23.0/16
Your explanation of the above in italics
drop udp $EXTERNAL_NET any -> $HOME_NET 993
Your explanation of the above, and so on...
An example explanation for a SNORT rule option:
content: "USER root"; nocase;
The content of the packet must contain the string "USER root" to be
matched. Furthermore, the nocase option specifies that the string "USER root"
should be matched case insensitively. In other words, it will match that
string whether in upper, lower or mixed capitalisation.
_____
On Yahoo!7
360°: Your own space to share what you want with who you want!
<http://au.rd.yahoo.com/mail/tag/**http%3A%2F%2Fau.360.yahoo.com%2F>
_____
On Yahoo!7
Coming soon: Celebrity Survivor - 11 celebrities, 25 days, unlimited
drama
<http://au.rd.yahoo.com/mail/tag/**http%3A%2F%2Fau.yahoo.com%2Fcelebrity-survivor%2F>
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Snort-users mailing list
Snort-users@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users
