'Rule'에 해당되는 글 4건

  1. 2008.12.24 Play Clean With Wash Sale Rule by CEOinIRVINE
  2. 2008.12.20 Judge toughens Madoff's home detention rules by CEOinIRVINE
  3. 2008.12.16 Court allows lawsuits over 'light' cigarettes by CEOinIRVINE
  4. 2008.10.14 [2] Snort Configuration : Rule Installation by CEOinIRVINE

You can still book some losses for this year, but be careful not to get them disallowed by the wash sale rule.


row2image

Run, don't walk, into the high yields and safety of municipal bonds. Which ones? Click here for current buys from Marilyn Cohen in Forbes Tax-Advantaged Investor.

Several times in the first half of 2008, it looked like the Federal Reserve and the Treasury just might be able to pull the U.S. economy and financial markets out of the enveloping funk that began to gather in earnest about one year ago as stocks topped out. As we now know, the pain was just beginning and stocks went on a big slide; the Dow Jones Industrial Average now has a virtual lock on finishing 2008 with one of its five worst annual percentage losses in the history of the index, nestled among Depression-era years and the horrendous Panic of 1907.

Add to the steep slide in the overall market a far more precipitous crash in all things related to commodities and emerging markets and you could be forgiven for getting caught still holding a few losers in your portfolio this time of year--maybe a copper stock, a few Chinese stocks, an oil company or fertilizer maker, or perhaps mutual funds or exchange-traded funds that hold some of these hot investments gone cold. You may have had a massive capital gains distribution this month, or are about to have one, and you'd like to reduce your tax liability.

Article Controls

imageemail

imageprint

imagereprint

imagenewsletter

comments (1)

imageshare

Yahoo! Buzz

Now it's time to counter that pain you've felt as an investor with at least a bit of relief as a taxpayer.

Selling out of losing investments inside of a taxable account allows you to realize both short-term and long-term capital losses, which you can use to offset gains for tax purposes. If your losses exceed your realized gains, you can deduct up to $3,000 from ordinary income for the tax year when you booked the loss--and carry forward anything above $3,000 until you die.

But if you want to make sure your losses do some good for you this year, you need to pay attention to something called the "wash sale rule," which disallows a realized loss if you purchase the same, or "substantially identical securities," 30 days before or 30 days after the day you booked the loss.

It is not the end of the world to have a wash sale disallowed: The IRS simply adds back the amount of the disallowed loss to your original basis, in effect lowering your tax burden in whatever year you properly dispose of the investment.

If you were counting on that loss to offset gains you made this year, however, you need to make sure to play by the rules. Section 1091 of the Internal Revenue Code details the wash rule and the IRS lays it all out in Publication 550, available on its Web site.

'Business' 카테고리의 다른 글

November existing home sales fall by 8.6 percent  (0) 2008.12.24
Stocks hold gains despite sluggish housing data  (0) 2008.12.24
Stumbling Giants: EA And Take-Two  (0) 2008.12.24
Life In A Recession  (0) 2008.12.24
Company of the Year: Nasdaq  (0) 2008.12.24
Posted by CEOinIRVINE
l

Facing a growing chorus of angry investors, disgraced financier Bernard Madoff lost his right to leave his home Friday and was ordered to hire private around-the-clock security guards to protect him. U.S. Magistrate Judge Theodore H. Katz approved the revised bail conditions after prosecutors sent a letter requesting them earlier in the day. The letter, signed by Assistant U.S. Attorney Marc O. Litt, did not explain why the bail conditions needed to be tightened.

Madoff, 70, a former Nasdaq stock market chairman, has become one of the most vilified people in America since word broke last week that he allegedly plundered $50 billion from investors.

The changes eliminated a curfew established this week that allowed Madoff to leave his Manhattan apartment during the day. Now, he will be confined to his apartment at all times, except for court appearances.

The order calls for Madoff's wife to pay for a security firm to provide 24-hour video monitoring of Madoff's apartment doors. It also requires communications devices and services enabling the firm to send a direct signal from an observation post to the FBI if there is an "appearance of harm or flight."

"The security firm will provide additional guards available on request if necessary to prevent harm or flight," the order said.

Madoff's lawyer, Ira Lee Sorkin, said the order "speaks for itself."

About his client's safety, Sorkin said: "We are always concerned about the health and well-being of high-profile clients and we take whatever measures are appropriate."

Madoff's bail conditions have been gradually increased as angry investors who lost billions seek information about what happened to money they thought was safely invested with someone who was widely respected on Wall Street for nearly half a century. A week ago, he was released on $10 million bail only on the signature of he and his wife. When he could not get a total of five signatures on his bail package to vouch for him, a curfew was imposed.

The bail development occurred a day after Madoff was ordered to provide a written list by year-end of his assets and liabilities, a key step in finding what is left for investors.

U.S. District Judge Louis L. Stanton signed an order late Thursday requiring Madoff to provide a verified accounting of all his assets, liabilities and property to the Securities and Exchange Commission.

The court filings came as investigators spent another day trying to untangle Madoff's operation. Investigators have started serving grand jury subpoenas requiring witnesses to testify and seeking documents, according to an official familiar with the case. The official, who spoke on condition of anonymity because the investigation is ongoing, declined to identify who was served or specify what documents were wanted.

Also Friday, Tufts University became the latest group to come forward as a Madoff victim, saying it lost $20 million, or about 2 percent of the school's endowment.

The school invested the money with an investment firm called Ascot Partners LP, managed by the chairman of GMAC Financial Services, J. Ezra Merkin. Other universities also lost a bundle with Ascot through the Madoff connection, including New York Law School.

The judge's order, agreed to by Madoff, demanded details of all assets, funds or property held by Madoff and the names and locations of entities, bank accounts, brokerage accounts, investments or assets held by his business, Bernard L. Madoff Investment Securities LLC.

The order also puts control of all of his artwork, property, cars, jewelry and other items in the hands of a court-appointed receiver.

The order also requires that the receiver, lawyer Lee Richards, prevent the disposal of any of the assets of Madoff Securities International Ltd. and determine to what extent funds were comingled between Madoff's U.S. operations and any businesses overseas.

Madoff and his family essentially turned him in to authorities last week, blowing the whistle on what authorities said he confessed was a "giant Ponzi scheme."

Authorities say Madoff confessed to family members that he had for years been paying returns to certain investors out of the principal received from others until he had only $200 million to $300 million remaining.

The charge against Madoff carries a potential penalty of up to 20 years in prison. Other charges could be added as the case is presented to a grand jury.

The trustee in charge of the Madoff liquidation has hired Lazard Freres & Co. LLC to assist in the sale of the trading operations of Bernard L. Madoff Investment Securities LLC., the global financial advisory and asset management firms.

Associated Press Writer Tom Hays contributed to this report.


Posted by CEOinIRVINE
l

The Supreme Court ruled Monday that lawsuits may proceed against tobacco companies for allegedly deceptive marketing of "light" cigarettes.

In a 5-4 split won by the court's liberals, the court said that smokers may use state consumer protection laws to sue cigarette makers for the way they promote "light" and "low tar" brands.'



The decision was at odds with recent anti-consumer rulings that limited state regulation of business in favor of federal power.

The tobacco companies argued that the lawsuits are barred by the federal cigarette labeling law, which forbids states from regulating any aspect of cigarette advertising that involves smoking and health.

Justice John Paul Stevens, however, said in his majority opinion that the labeling law does not shield the companies from state laws against deceptive practices.

People suing the cigarette makers still must prove that the use of 'light' and 'lowered tar' actually violate the state anti-fraud laws, but those lawsuits may go forward, Stevens said.

He was joined by the other liberal justices, Stephen Breyer, Ruth Bader Ginsburg and David Souter, as well as Justice Anthony Kennedy, whose vote often decides cases where there is an ideological division.



'Business' 카테고리의 다른 글

How We All Will End The Recession  (0) 2008.12.17
Street Rallies Ahead Of Fed  (0) 2008.12.17
US commission investigates possible violations  (0) 2008.12.16
Why You Need Wii Accessories  (0) 2008.12.16
Finding A Virus Scanner That Works  (0) 2008.12.16
Posted by CEOinIRVINE
l

Rule Installation

Snort comes with more than enough rules to satiate your diet. We’re always surprised to learn about new rules that inventive people have made from all over the world; many have been added to the public domain.

Our goals in building a well-tuned IDS installation is to first enable most, if not all, of the rules that come with Snort. This enabling produces a ton of output (most is likely irrelevant to your network environment), but it gives you a great introduction to the type and frequency of the alerts pounding on your front door. From there, tuning Snort is like Goldilocks faced with her choices: Start with the bed that’s way too big and then keep refining until it’s “jusssst right.”

This section delves into those messy-looking rules files.

How the rules files are organized

Snort’s rules directory sorts hundreds of rules into rules files according to their purpose. Although the rules are cataloged a few different ways and some of the rule categories have overlapping domains, there’s certainly a method to the madness.

Rules files fit into eight major categories:

  • Low-level protocols (icmp, netbios, tcp, udp)

  • High-level protocols (http, ftp, dns, pop3, imap)

  • Web server specific (web-attack, web-cgi, web-client)

  • Exploit specific (shellcode, backdoor, exploit)

  • Service impacting (dos, ddos)

  • Policy specific (policy, info, misc, porn)

  • Scanning and probing activities (scan, bad-traffic)

  • Viruses, worms, and other malware (virus)

An in-depth rule structure

The best way to find out how the whole rule system works is to get your hands dirty with a typical example:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS 
(msg:"WEB-IIS CodeRed v2 root.exe access"; flow:to_server,established; 
uricontent:"/root.exe"; nocase; classtype:web application-attack; 
reference:url, www.cert.org/advisories/CA-2001 19.html; sid:1256;  rev:7;)

This rule demonstrates many of the options that you’re likely to encounter with your own setup. We picked the Code Red worm alert from the web-iis.rules file as our starting point.

 Tip  Here’s a piece-by-piece explanation of that Code Red worm rule, which appeared earlier in this section:

  • The alert directive (in bold in the following alert snippet) tells Snort that if the packet matches this rule, then the rule should send its output through the alert facility.

    alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS...

    The overwhelming majority of Snort’s rules use the alert facility, although optionally, you can use the log facility. Chapter 6 explains the difference between these two facilities.

  • The tcp keyword is an argument that identifies which network protocols the rule applies to. The following alert snipped shows the tcp keyword in bold:

    alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS...

    Because the tcp keyword is specified, Snort knows to match this rule only to network traffic using the TCP protocol (other protocols, such as UDP) will be ignored.

  • The network source and destination arguments are highlighted in bold in the following statement:

    alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS...

    The preceding network source and destination arguments (including port numbers) tell Snort to alert on any traffic that is either

    • From the $EXTERNAL_NET on any port

    • To any of our Web servers on the defined Web ports.

     Technical Stuff  The network source and destination arguments use the variables established at the beginning of the snort.conf file (the arguments beginning with the $). These substitutions provide convenience and readability for managing a large collection of rules, which can easily top a few thousand entries.

  • The last part of the rule gets even more granular with information the rule should match on, as well as what Snort should do if the rule does match . The following snippet shows what this looks like:

    (msg:"WEB-IIS CodeRed v2 root.exe access"; flow:to_server,established; 
    uricontent:"/root.exe"; nocase; classtype:web application-attack; reference:url, 
    www.cert.org/advisories/CA-2001-19.html; sid:1256;  rev:7;)
    • A few other tests tucked away in that last section must be passed before an alert is generated. The flow: and uricontent: keywords further refine the rule. In this case, if the uricontent (URI stands for universal resource identifier) contains the text "/root.exe". The flow says that the connection should be going to the server and should already be established. IP listed in your var HTTP_SERVERS section of snort.conf, then an alert is generated with the message "WEB-IIS CodeRed v2 root.exe access".

    Snort also identifies the type of attack by classifying it as a "web applications-attack." It further identifies the exact nature of the alert setting the "sid" (Snort IDentification) field to 1256. Sids are unique identifiers to Snort. They can nail down an offense to exactly one alert. The reference: keyword provides a log entry regarding any other information that’s known about the nature of the attack. References are often URLs to security-related Web sites, such as CERT, Whitehats, or SecurityFocus, which provide advisories on what the attack is and how to patch for it (if possible). In our Code Red example, we point to the CERT Web site with the following URL:

    http://www.cert.org/advisories/CA-2001-19.html

Figure 8-1 shows a graphical overview of how a Snort rule is laid out. In it, you see many of the bits and pieces of a rule.

Image from book
Figure 8-1: The Snort rules layout. Click to collapse

Flow or direction operators represent how traffic is traversing the network. Their use is pretty straightforward:

  • The > operator tells Snort that the network on the left should be regarded as the source, and the one on the right should be the destination.

     Technical Stuff  There isn’t a <- operator. All instances using it are written by flip-flopping the arguments around the > command.

  • The <> operator will match any traffic between the network on the left and the network on the right, regardless of which network originated the traffic.

     Warning   The directionless operator (<>) can sometimes cause a bit of confusion with its use. It seems to makes sense that you would inspect traffic flowing both ways from one computer or network to another, but that inspection happens infrequently. Most Snort rules look something like this:

    $EXTERNAL_NET any -> (internal host / port)

    A rule that matches too broadly (which the preceding rule would do if it contained <>) produces a huge Snort log and unduly burdens the processing engine as it inspects everything that passes by.

Elements of the rule header

Sifting through the directory of rules shows that all the rules contain header information, though most have a jumble of different items in their bodies. The header is just a front-end filter that separates out traffic by using five key sifting factors: source IP address, destination IP address, source port, destination port, and protocol.

Rule actions

Snort comes built-in with five different rule actions. Each gives you a lot of power in building your arsenal.

 Tip  Before changing the default behavior of your Snort rules, spend some time watching it operate in your environment and use its output to help you reduce noisy false positives.

Here are Snort’s five rule actions:

  • The log action merely logs the offending packets to the output logging that we set up when the Snort sensor was configured. The output plug-ins options are many and varied, giving you a rich set of choices. A per-rule log directive lets you customize logging down to a remarkable level.

  • The alert action can print a log entry and post a notification when some event is associated with a higher priority and probably needs a personal touch.

     Technical Stuff  The alert action is the default action for most rules that come with Snort. Snort’s job, after all, is to alert us of an attack on our network!

  • The pass action can ignore a matched packet and continue processing.

    The pass action is useful when you’re tuning your rules and need to disable some of the noisier ones so that you can actually see the output of what you’re working with.

  • The most powerful of the Snort actions is the activate keyword. Activate operates in concert with the dynamic action by triggering an alert and running what’s specified by the associated dynamic rule.

     Technical Stuff  The activate/dynamic pair is ideal for catching a complex series of attacks that may otherwise go unnoticed.

  • The dynamic action is associated with a rule that shouldn’t run until another event is encountered. You combine the dynamic action with the activate action to set up a second level of processing in certain circumstances.

     Technical Stuff  The activate/dynamic pair isn’t often used in common Snort setups, but it can be a handy tool for advanced intrusion detection.

Protocols

Snort, as a network IDS, must operate on the lowest level of the network to do its job. Snort grabs Ethernet frames directly from the wire. Inside of those frames are the four protocols that the free version of Snort normally scans: IP, ICMP, TCP, and UDP.

 Technical Stuff  Snort’s developers are attempting include other protocols, such as HTTP, 802.11, and ARP. The keywords for building your rules should include only one of the original four.

For example, let’s say employees aren’t allowed to use the eBay auction Web site on the job. A particular employee has been reprimanded for spending hours browsing eBay, and HR wants to monitor his behavior. The following rule logs all Web traffic that contains ebay.com coming from the host 192.168.1.18 with the message eBaying:

log tcp 192.168.1.18/32 any -> any 80 (msg:"eBaying"; uricontent:"ebay.com";)

Source/destination

The last part of a well-formed Snort rule is probably the most important piece of configuration data: The two IP address ranges that are involved with the communication. The source and destination networks are identified in a rule that takes this form:

(source network) (port) -> (destination network) (port)

 Tip  CIDR (Classless Inter Domain Routing) notation is used for the network arguments. CIDR notation is that funny way of expressing an IP address using a / and another number — for example, 10.35.24.0/24, which means a Class C network of 254 hosts on network 10.35.24.0 (plus the first and last addresses that are reserved for the network address and the broadcast address, namely 10.35.24.0 and 10.35.24.255).

For the Snort rules files, you really deal with only two types of entries:

  • Networks (which contain a /)

  • Hosts (which omit /)

    Omitting / is a shorthand way of saying, "Just the single IP address, if you please." For example, the address 10.35.24.66 indicates just one host for matching against.

You can also enter ranges of port numbers, similar to ranges of IP addresses. Most of the examples that we cover in this chapter are single ports, such as 80 for the Web port, 443 for the encrypted Web port, and 25 for sendmail. The entire range of available ports extends from 0 to 65535.

For a range of ports, you just place a colon between the two ports. The following rule looks for any traffic containing “ebay.com” occuring on any TCP port between 1 and 1023.

log tcp 192.168.1.18/32 any -> any 1:1023 (msg:"eBaying"; uricontent:
"ebay.com";)

You can also include the maximum and minimum ports ranges by simply leaving off a number. For example :1023 means a range of ports from 0–1023, and 1024: refers to a range of 1024–65535.

Wildcards

Wildcards simplify rules. Wildcards work just like those “splat” asterisks that you can type into a DOS window or Unix shell to list only certain files. In Snort, the any keyword is the most powerful wildcard — and it’s all over the place. You’re allowed to use the any wildcard in both the network and port configurations: any matches everything for the category you placed it in.

 Tip  In the preceding section, we used the any wildcard in a couple of places. When the host 192.168.1.18 tries to start a communication on any port with any host on ports 1–1023 with the text "ebay.com" as part of a URI, then . . . bingo! That’s a match, and the message eBaying appears in the logs.

Elements of the rule body

After being mangled by the pre-processors and whittled down by the filters of the rule’s header, the rule’s body contains a virtual cornucopia of tests.

The most powerful test is pattern-matching what slips through for either specific keywords, phrases, or strings of binary data. Often, this inspection is the most critical, because what’s being searched for is the “fingerprint” of the attack itself.

Many of the most powerful features of Snort’s detection engine reside in the body of the rule. Each feature has a different style, syntax, and set of options. This flexibility can make rule management somewhat complicated, but very worthwhile.

The layout of the rule body

Snort’s rule body must follow this specific structure:

  • The body section of a rule is always wrapped by one set of parentheses.

  • Body options (keywords, instructions, tests, and commands) are within the parentheses.

  • Each body option is separated by a semicolon.

  • Each body option usually conforms to this format (the value is wrapped in double quotes):

    item: "value";
  • The entire line is terminated with a semicolon.

While the structure contains a lot of punctuation, it helps keeps things straight for both Snort and the person managing it.

The “content” option

Content analysis flushes out specific attack signatures within the packet. The particulars of the content option is applied to each and every packet that matches the header of the rule and can be expressed in either plain text form (ASCII) or geek-speak (Hexadecimal).

Worms, viruses, and server cracks are normally transmitted onto your network as raw machine code, which, to the naked eye, looks like gobbledy-gook, but is in fact a series of instructions that harm your computers and servers.

 Tip  Content matching is typically done at the application layer (Layer 7) of the OSI networking model.

Text content matching (ASCII)

As a simple scenario for demonstration purposes, let’s say you’re concerned about employees trading computer hacking information within your organization. You can create a rule that generates an alert whenever an e-mail is sent to your primary mail server (the mail server’s IP address is 172.16.30.7) containing the word "hacking". The mail port is 25; most mail is transmitted using the TCP protocol, so the following rule illustrates how we can use the content keyword to craft a rule to meet our goal.

alert tcp $EXTERNAL_NET any -> 172.16.30.7 25 (msg:"Found hacking reference 
in e-mail"; content:"hacking";)

 Technical Stuff  Content analysis (by either text or hexadecimal matching) is used in more than two-thirds of the rules that come with Snort.

Hexadecimal content matching

Hexadecimal (hex) content, although expressed differently than ASCII text, is ultimately treated the same as ASCII by the Snort processing engine. In both cases, the text is reduced to what the computer deals with best: bits, which is then matched against the data streaming across your network. Hex is just a shorthand way of representing the zeros and ones of binary machine code.

 Tip  Hexadecimal is like a numerical alphabet that is 16 characters long, as compared with English (which has 26 letters) or decimal math (which has 10 numerals). Hexadecimal is often referred to as base-16 because the “alphabet” it uses has only 16 “letters” (0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F). Hexadecimal strings entered into a Snort rule body contain only those characters and none others. If you create a hexadecimal string with nonhex characters, expect that Snort will turn up its nose.

Here’s a real example right out of the rules directory:

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"EXPLOIT ssh CRC32 overflow 
filler"; flow:to_server,established; content:"|00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00|"; reference:bugtraq,2347; reference:cve,CVE-2001-0144; 
classtype:shellcode-detect; sid:1325;  rev:3;)

To use a hex match for content searching, wrap the hexadecimal characters to find with the pipe symbols (|). White space can separate out single bytes of hexadecimal data (“00 00”). Snort ignores the white space, which is only there to preserve the readability to the rule crafter.

The preceding rule is meant to watch for an attempted exploitation of the Secure Shell server application (sshd) by scanning traffic coming from anywhere on the external network and destined for your home network on port 22 (the sshd port). The content search is a long series of binary zeros (18 sets of two, to be exact). How can a pattern of zeros be unique? A pattern of zeros is frequently found in attack code and is often a give-away that someone is doing something you don’t like.

Mixing it up

You can mix and match the style of content searching without confusing Snort. As long as the binary data you want to search for has the bookends of the pipe characters, that block of text can be intermingled with other, plain ASCII text. What follows is a good example from the back-door.rules file.

alert tcp $EXTERNAL_NET any -> $HOME_NET 12345:12346 (msg:"BACKDOOR netbus 
getinfo"; flow:to_server,established; content:"GetInfo|0d|"; 
reference:arachnids,403; classtype:misc-activity; sid:110; rev:3;)

Notice how the content search string is constructed: GetInfo|0d|. This string tells Snort’s pattern matching subsystem to watch for the text phrase GetInfo with a carriage return at the end. Pretty nifty, eh? Inserting hex into a plain text string is useful for representing characters that can’t be represented by plain text, such as a carriage return. You can drift between text and binary content all within the same search string.

The “depth” option

It would be nice if malicious content always occurred at the beginning or end of a packet. Unfortunately, malicious content can occur almost anywhere in a packet. The depth option specifies how many bytes into a packet the Snort processor should look before moving on to the next rule.

The main reason for using the depth option is to restrict the search to the most likely places where a match is found, without wasting valuable processor resources to search the entire packet. For example, if you want to find the HTTP protocol version as part of a Web site communication, look in the first few hundred bytes. Because a packet may be as large as 1,500 bytes (less the header overhead), it makes a lot of sense to give Snort a break, especially if what it must look through are millions upon millions of packets.

The following rule from the web-misc.rules file reveals that you need only 15 bytes to catch the sadmind worm. Hence, the content GET x http/1.0 is always encountered at the very beginning of the packet.

web-misc.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
 (msg:"WEB-MISC sadmind worm access"; flow:to_server,established; content:"GET x 
HTTP/1.0"; offset:0; depth:15; classtype:attempted-recon; 
reference:url,www.cert.org/advisories/CA-2001-11.html; sid:1375;  rev:5;)

The “nocase” option

The nocase option, which appears in more than a third of the rules that ship with Snort, basically says to ignore the case of the characters submitted for searching. Because the nocase directive takes no arguments, it’s normally just used with a terminating semicolon. The following example from the info.rules file finds the text LOGIN FAILED or LoGIn FaIlEd on a telnet session port.

alert tcp $HOME_NET 23 -> $EXTERNAL_NET any (msg:"INFO TELNET Bad Login"; 
content: "Login failed";  nocase; flow:from_server,established; 
classtype:bad-unknown; sid:492; rev:6;)

The “offset” option

Another tool that gives us a more precise scope on where in the packet to look is the offset option. Offset works by skipping over the number of bytes supplied to the right of the colon. So, offset:90 skips the first 90 bytes of the packet and then begins searching for the string given as part of the content keyword. Offset and depth work nicely together to make the search area of a packet limited to a window that is bracketed by the two. Basically, if you know where to look and what to look for, you can use these two options to help Snort get a fast grip on where to spend its time.

The Uniform Resource Identifier (URI) option

You can use the uricontent option to conduct a similar type of content searching. Its purpose is similar to the depth and offset options: to reduce the overall processing burden on Snort as it watches for more attacks to effectively do its job.

The uricontent option works much like the content one, except it restricts its searching to only URIs in the payload of the packet. URIs (Uniform Resource Identifiers) in Snort can specify other protocols than http, such as ftp, gopher, rsync, and https.

The uricontent option only searches for the given text in URIs that is found in the packet. If URIs aren’t present, no match occurs. URI searching is good for catching malicious commands that are readily evident as they often appear in the location request to a Web server. The following rule from the web-iis.rules file shows an exploit attempt against the IIS server using both content and uricontent analysis:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-IIS 
.asa HTTP header buffer overflow attempt"; flow:to_server,established; content:
"HTTP|2F|"; nocase; uricontent:".asa"; nocase; content:"|3A|"; content:"|0A|"; 
content:"|00|"; reference:bugtraq,4476; classtype:web-application-attack; 
sid:1802; rev:4;)

A couple of interesting characteristics about this rule are worth discussing:

  • When nocase follows a string, its effect is upon the content string immediately prior.

  • The nocase option has no effect upon binary search strings. Leaving it off of those strings just helps the overall flow of the rule.

Classification

The classification options provide an overall description of a rule, along with other helpful information about the rule, that can be used by the Snort program itself and a system administrator. These options include the Snort ID, the alert message to appear in the alert log, the rule revision number, the alert priority, the alert classification, and external references for the exploit or vulnerability that triggered the alert.

Snort IDs

Quite a few options help organize and classify detected alerts. The Snort ID (sid) option is unique to the Snort system and a good way to get a handle on classifications.

The format of the Snort ID value is the same as it as other classification options. For example, a proper usage is as follows:

sid:<ID_VALUE>;

 Warning   When you get the hang of building your own sets of rules, assign each custom rule a unique sid number somewhere above the 1,000,000 mark. That way, updates to the Snort rule base won’t accidentally collide with your custom rule. Table 8-1 gives you a breakdown of the uses for sid ranges.

Table 8-1: Snort ID (sid) Values

Range of Values

Usage

1–100

Reserved for future use

100–1,000,000

For use within the www.snort.org distribution network

1,000,000 +

For use in customizing your own Snort rules

Priority

Snort has a built-in numerical rating for many of the rules that it ships with: The lower the priority number, the higher the risk posed by the attack that tripped the rule. By using the priority option, you can override Snort’s default level and rate how important or impacting a particular rule is to your unique environment. For example, the following command assigns the rule associated with it the highest priority: 1.

priority:1;
Classtype

The classtype option can organize rules into major groups. A few dozen different classification types are spread over three priority levels, which are described in Tables 8-2, 8-3 and 8-4. For inclusion in a rule, the syntax is

classtype:<CLASS_TYPE_NAME>;
Table 8-2: Priority 1 Classifications (Critical Severity)

classtype

Description

attempted-admin

Attempted privilege escalation to an Administrator level

attempted-user

Attempted privilege escalation to a User level

shellcode-detect

Discovered executable code

successful-admin

Achieved successful privilege escalation to an Administrator level

successful-user

Achieved successful privilege escalation to a User level

trojan-activity

Discovered software code of a Trojan Network Attack

unsuccessful-user

Failed privilege escalation to a User level

web application attack

Identified an attack upon a Web server’s application software

Table 8-3: Priority 2 Classifications (Intermediate Severity)

classtype

Description

attempted-dos

Attempted denial-of-service attack

attempted-recon

Attempted information collection (reconnaissance)

   

bad-unknown

Potentially bad traffic seen (malformed)

denial-of-service

Denial-of-service attack possibly underway

misc-attack

A catch-all category

non-standard-protocol

Detection or use of a nonstandard protocol

rpc-portmap-decode

Portmap decode detected

successful-dos

Denial of service detected

successful –recon- largescale

Large-scale information collection (reconnaissance)

successful –recon- limited

Limited information collection (reconnaissance)

suspicious-filename- detect

Strange or unusual filename was detected

suspicious-login

Strange username was found attempting to login

suspicious-call-detect

System call was detected

unusual-client-port- connection

A client was abnormally using a network port

web-application- activity

Access was made to a potentially vulnerable web-app

Table 8-4: Priority 3 Classifications (Low Severity)

classtype

Description

icmp-event

A “ping” packet was detected

misc-activity

Some behavior was detected that may be considered a policy warning

network-scan

A host or network was being scanned

non-suspicious

Regular usage activity was detected

protocol-command-decode

A protocol instruction was decoded

string-detect

A pattern of specific bytes was detected

unknown

Unknown or unclassified traffic

Revision and versions

The Snort people thought ahead and even included a way to keep a version tracking on each individual rule. The software industry uses many version management schemes because the field is so fluid and so dynamic that tight change control is almost a necessity. The format of the option is

rev:<#>;

 Technical stuff  Very few rules that come with Snort (less than 10 percent) have a revision number of only 1. Busy enterprise networks are sometimes hostile and fast-paced environments. Sometimes, rules are quickly added during the heat of a malicious event so that immediate visibility is provided to the security managers who must monitor the attack. After some analysis and a firmer understanding of the events takes shape, Snort’s rules are then revised (often only subtly) to reflect what’s known about the event.

Messaging and output

The mesg option creates a customized output message that can be included with any logs, alerts, and data dumps processed by the detection engine. By looking through the rules directory, you can see that the fabricators of the rules file have added messages to almost all the entries that they include. The following is an example of the format of the mesg directive in use:

alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"SMTP sendmail 5.5.5
 exploit"; flow:to_server,established; content:"mail from|3a20227c|"; nocase; 
reference:arachnids,119; classtype:attempted-admin; sid:662; rev:4;)

See how cleverly the Snort makers had the output of this mail exploit attempt reported as “SMTP sendmail 5.5.5 exploit”? Describing the nature of an attack in plain English helps you in the long run (especially when you’re searching through logs at trying to track down a breach).

External references

The second most powerful (and widely used) feature within a Snort rule is the external reference option. You can reference Web-based resources that provide you with tons of additional data on an attack or probe right in the Snort logs.

A few different formats are used. Nearly all are Web site front-ends that look up an attack based on a unique identifier. For example, using the example in the preceding section, we find the following: reference:arachnids,119;

Thanks to this command, when Snort encounters this Sendmail attack, it provides a URL where the user can find out more about the Sendmail attack. Table 8-5 gives a list of Snort’s external references.

Table 8-5: Snort’s External References

Keyword

URL Base

bugtraq

http://www.securityfocus.com/bid/

cve

http://cve.mitre.org/cgi-bin/cvename.cgi?name=

arachNIDS

http://www.whitehats.com/info/IDS

McAfee

http://vil.nai.com/vil/content/v_

Nessus

http://cgi.nessus.org/plugins/dump.php3?id=

url

http:// (a general URL that’s passed straight through)

Proper use of the external keyword takes this form:

Reference: <SYSTEM> <VALUE>

 Technical Stuff  You can tie together any number of reference options as long as they’re separated by a semicolon.

Advanced options and deep dark secrets

The advanced options give you a peek into the dark side: the stuff of the geek-chic and the wizards of computer security.

Flow control

The flow control option lets you define the direction of a network stream. All network communications have two endpoints and a direction, so Snort can be configured to alert whenever one of many other triggers is tripped. Snort’s internal engine must do some fancier processing for the flow control (including some on-the-fly packet reconstruction), but it’s certainly worth the overhead because it lets you know whether an attack actually worked or not.

Regular expressions

A regular expression (regex in computer-nerd circles) is the incredibly powerful voodoo of using wildcards to match substrings within other strings. Without jumping into the deep end of this black art, a regular expression combined with a Snort rule makes for powerful mojo!

Protocol options

Because of Snort’s primary function to act as a low-level packet trap and filtering device, it can make lots of specific selections based on granular network protocol components. For example, sometimes hackers use specialized or fragmented packets to tease at the edge of networks for information about what they may find if they break in. These probing and recon expeditions may otherwise go unnoticed by a system administrator or a security package not configured to watch for such errant behavior. Snort’s native IP rules options put a huge amount of power at your fingertips.

How does Snort deal with all those rules?

Managing the files and their contents, let alone keeping a huge decision tree running, is a fine programmatic accomplishment.

Snort keeps track of all those intricate rules (some with more than 20 different options) with some fancy data processing internally. Without getting too bogged down, the process of reading in a particular rule is governed by a string parser, which cuts apart the rule into its component parts, which are then stored into a series of linked lists.

 Remember  Snort is a busy, complex, and low-level application. Every small or subtle error that goes undetected or that causes minor annoyances can snowball into a huge performance issue under certain circumstances. Although it doesn’t happen often, a misplaced command or configuration option can cause downtime or data loss.

'IT' 카테고리의 다른 글

[4] Snort Configuration: preprocessing punk packets : preprocessor  (0) 2008.10.14
[3] Snort Configuration : Refinement  (1) 2008.10.14
Snort Configuration [1]  (0) 2008.10.14
Snort Location  (0) 2008.10.14
Snort Installation on CentOS 4.6  (0) 2008.10.10
Posted by CEOinIRVINE
l