'IT'에 해당되는 글 215건

  1. 2008.10.22 Leveraging The Semantic Web by CEOinIRVINE
  2. 2008.10.21 Motorola Readies Its Own Android Social Smartphone by CEOinIRVINE
  3. 2008.10.19 Tech Beat Unlocked Android? No So Fast Posted by: Stephen Wildstrom on October 16 by CEOinIRVINE
  4. 2008.10.19 Nokia: Investors Cheer Mixed Results by CEOinIRVINE
  5. 2008.10.19 The iPhone Isn't A Great Phone by CEOinIRVINE 1
  6. 2008.10.15 Linux Daylight Saving Time by CEOinIRVINE
  7. 2008.10.14 Earphones offer good sound, bad fit by CEOinIRVINE
  8. 2008.10.14 Tech, Telecom, and Web Earnings Look Bleak by CEOinIRVINE
  9. 2008.10.14 [5] Snort Tuning: Reduce False Positives by CEOinIRVINE
  10. 2008.10.14 [4] Snort Configuration: preprocessing punk packets : preprocessor by CEOinIRVINE

Leveraging The Semantic Web

IT 2008. 10. 22. 01:16

The number of publicly available Web services is exploding. Check out John Musser's masterpiece, programmableweb.com, to get the hard evidence. Companies are publishing application program interfaces (APIs) to support e-commerce partnerships (eBay), syndicate content (Mochila), provide access to advanced functionality (Google Maps), allow use of raw computing resources (Amazon Web Services) and serve a horde of other purposes.

As this number continues to grow, the problem of how to find useful services will grow ever larger. How will services be described? How will they be found? What would be possible if you could really search for services based on a machine-readable description of what they did? This is the problem of service discovery, and finding a successful solution will come to affect many different aspects of our lives or create a semantic bottleneck.

The JargonSpy can already hear some of you saying, "What's the big deal? Can't we find services the way we find Web pages?" It is true that we could solve some of the problem of finding services with a search engine. Most services out there have an interface description that is machine readable (a Web Services Description Language, or WSDL, file), along with some sort of text description. If I search for "map APIs," Google Maps comes up near the top.

I thought the same way until I moderated the 2008 International Research Forum. There, I was introduced to the topic of semantic service discovery, which promises a whole new set of benefits.

There are three main use cases for semantic service discovery. First, there is you and me wanting to do something. If a service could help us, how would we know? Second, there is the developer seeking to build an application using services. How can the right services be found? Third, there is the idea that an intelligent program could automatically assemble a new service or application based on a machine-readable semantic description. Is this even possible?

Before we look at how this might work, it is important to understand what will happen if we do not solve this problem. If the number of services keeps growing, but we cannot easily find them to use them, then first of all, the economic incentive for creating the services will drop. The more people using and benefiting from the publication of services, the more investment will be made in them. But this is not a large problem. We are living without the services we don't know about now, aren't we?

The second effect of hard-to-find services will be a boon for systems integrators and creators of niche applications. They will learn about the services that are out there, help people find the ones they need and put them to work. Hands-on understanding of publicly available services could become another body of knowledge like the ability to configure and customize enterprise resource planning systems. The less service discovery is a black art, the smaller the size of the semantic bottleneck to unlock value for everyone.

A variety of things are needed to ease service discovery. Part of the solution will be in the ontologies and categorizations provided by the semantic Web. By classifying the parameters in Web service interfaces and expressing relationships between them, a person or a program will be able to walk down or query a tree structure and find all the services that have to do with specific entities like a customer and an airline. So far, so good.

The problem that has yet to be solved is finding out what that service does. Is it possible to describe in a machine-readable way the before-and-after state of a service, so that a person or a program could know what was changed when the service was invoked? For example, does a travel service just look up an airline schedule or does it book the ticket and charge my credit card? Standards such as Semantic Annotations for WSDL and OWL-S are attempting to get this right. So far the jury is still out and will be for a long time.

If somehow we can even get part of the way there, you can imagine all sorts of new offers being made when you look at your search results. Instead of just Web pages, you will be offered services to help do things that your query might indicate you want to do. If you are a programmer, you will be able to express your desire for a service to book hotels and find a list of them to compare. Or, if semantic service discovery is really achieved, you will have the ability to enter an environment in which you express your needs and services and an application will be created for you.

Of course, another effect of high-quality semantic descriptions will be the equivalent of semantic service discovery optimization, something like search engine optimization, in which people try to describe their services in a way that promotes their use. That of course is a problem of victory. The real question facing us now is whether we will get there at all.

Are you finding the Web applications and services that you need? Let the JargonSpy know. Please share your thoughts in the Reader Comments section below.

Posted by CEOinIRVINE
l

 

Amid a boom in social-network-friendly handsets, Motorola prepares a new entry, but its Android may not debut until 2009's second quarter

 

http://images.businessweek.com/story/08/370/1018_moto_android.jpg

Photo: Getty Images; Illustration: Angelos Dosoulas



 

As the wireless world awaits the Oct. 22 debut of the first phone based on the Google-backed Android software, engineers at Motorola (MOT) are hard at work on their own Android handset. Motorola's version will boast an iPhone-like touch screen, a slide-out qwerty keyboard, and a host of social-network-friendly features, BusinessWeek.com has learned.

Motorola has been showing spec sheets and images of the phone to carriers around the world in the past two months and is likely to introduce the handset in the U.S. sometime in the second quarter of 2009, according to people familiar with Motorola's plans. Building a phone based on the highly anticipated Android operating system is part of Motorola's effort to revive a loss-making handset division that has forfeited market share amid a drought of bestselling phones. Motorola stock, which on Oct. 17 rose a penny to 5.62, is hovering near a 16-year low.

The phone will appear among a new class of social smartphones designed to make it easy for users to connect quickly and easily to mobile social networks such as Facebook and News Corp.'s (NWS) MySpace (BusinessWeek, 10/10/08). Such phones let users message in-network friends directly from phone contact lists, for example. A Facebook representative declined to comment on the company's work with Motorola. MySpace.com didn't respond to a request for comment.

Motorola declined to elaborate on its plans, but said in a statement: "We're excited about the innovation possibilities on Android and look forward to delivering great products in partnership with Google (GOOG)" and the community of developers known as the Open Handset Alliance that are working on the Android operating system.

Mobile Networking Wave

In the next year, social networking phones are expected to be a hit with the 16- to 34-year-old crowd, analysts say. According to consultancy Informa (INF), the number of mobile social-networking users will rise from 2.3% of global cell-phone users at the end of 2007 to as many as 23% of all mobile users by the end of 2012.

The Android handset will feature a touch screen about the size of those on Apple's (AAPL) iPhone, people familiar with the phone say. While it takes some of the design cues from Krave ZN4, the first touch-screen phone from Motorola launched with Verizon Wireless on Oct. 14, it's not certain whether the Android phone screen will feature Krave's distinctive and interactive clear flip screen.

Like the world's first Android phone, from HTC, Motorola's Android-based device will offer a slide-out Qwerty keyboard. People who've seen the pictures and spec sheets for the device say it looks like a higher-end version of the HTC phone, called the T-Mobile G1. But it's expected to sell for less, at prices similar to the Krave, which is available for $150 with a two-year contract. After carrier subsidies, the G1 will retail for $180 with a two-year contract.

Slow Off the Mark

Motorola's new phone likely won't be ready to launch in the U.S.  

Posted by CEOinIRVINE
l

T-Mobile has said the buyers of the new G1 Android phone will be able to unlock it 90 days after purchase so it can be used on other networks. But U.S. buyers who think this will let them escape T-Mo’s shaky 3G service are going to be disappointed.

The reason for this is that U.S. carriers in general, and T-Mobile in particular, are in their own world when it comes to 3G technology. To understand what this means, you’ll have to put up with a lot of detail about who does what at which frequencies.

In countries where GSM technology is the standard, that is to say nearly everywhere except the U.S., Canada, Japan, and Korea, things are simple. Voice and low-speed data services are at 900 and 1800 MHz and 3G runs at 2100.

In countries where GSM technology is the standard, that is to say nearly everywhere except the U.S., Canada, Japan, and Korea, things are simple. Voice and low-speed data services are at 900 and 1800 MHz and 3G runs at 2100.

In the U.S., T-Mobile and AT&T both use GSM technologies, but there are fundamental incompatibilities in their 3G services. AT&T runs its 2G and 3G services at 850 and 1900 MHz. T-Mobile's 3G service uses 2100 MHz to transmit and 1700 MHz to receive.

The G1 can handle 2G service at 850, 900, 1800, and 1900 MHz, which pretty well covers the world's markets. But 3G comes only at 1700 and 2100 MHz. That takes care of T-Mobile in the U.S. and everyone else in the rest of the world. But it leaves out AT&T's 3G service.

So the bottom line in that you may be able to get your G1 unlocked, but using it for high-speed data in the U.S. on anything but T-Mobile is a non-starter.

'IT' 카테고리의 다른 글

Leveraging The Semantic Web  (0) 2008.10.22
Motorola Readies Its Own Android Social Smartphone  (0) 2008.10.21
Nokia: Investors Cheer Mixed Results  (0) 2008.10.19
The iPhone Isn't A Great Phone  (1) 2008.10.19
Linux Daylight Saving Time  (0) 2008.10.15
Posted by CEOinIRVINE
l

Investors were undeniably nervous heading into Nokia's third-quarter earnings release on Oct. 16. Against a global backdrop of volatile trading in stock markets, shares in the Finnish mobile-phone giant had lost nearly a third of their value in the past two months—outpacing a 24% decline for the S&P Europe 350 index over the same period.

Some of the blame fell on a Sept. 5 warning from Nokia (NOK) that it expected to lose market share and report lower profits (BusinessWeek.com, 9/5/08) for the quarter. But investors also worried that the ongoing global economic turmoil could pull the rug out from under Nokia's sales—a concern now facing the broader consumer electronics industry as it heads into the crucial holiday season (BusinessWeek.com, 10/16/08).

Yet when the third-quarter results finally were revealed, showing a 5% year-over-year decline in revenues and 30% drop in net income, investors were sufficiently gratified to drive up Nokia's New York-traded shares by nearly 10%. That such soft numbers provoked a relief rally indicates how pessimistic shareholders were. "The fact that guidance remained by and large unchanged gave some comfort to the market," says Richard Windsor, a London-based technology analyst with brokerage Nomura Securities.

Consumers Are Still Buying Handsets

It's not merely a matter of seeing the glass as half-full. Though revenues, at €12.24 billion ($16.48 billion) came in 3.9% shy of market expectations, earnings per share were spot on the mark, gross profit margins for handsets grew slightly, and operating margin was better than in the previous quarter. In other words, Nokia wasn't even close to a meltdown: In a tough market environment, the company managed to keep profitability on track despite a decline in volume.

More important, Nokia reassured the market that there's no wholesale collapse taking place in handset demand. Its own unit shipments in the quarter grew by 5%, even as revenues slipped, and executives repeated their prediction that the mobile-phone market as a whole will grow 10.5% this year, to 1.26 billion units. That implies 14% unit growth in the fourth quarter compared to the third—somewhat lower than historical norms, but still a huge vote of confidence in consumer spending at a time when many indicators are pointing downward. Nokia promises to maintain or grow its estimated 38% third-quarter market share in the last three months of the year.

To be sure, there are trouble spots. Sales in Europe—traditionally Nokia's stronghold, although China is now its largest single market—fell by a worrisome 5.5% vs. last year's third quarter. (Sales in the U.S. were even worse, down 16.7%, but that was due primarily to the company's exit from CDMA phones; units were flat vs. the second quarter.) "The financial crisis has affected U.S. and European markets," said Nokia Chief Executive Olli-Pekka Kallasvuo in an interview.

Cheaper Models Are Selling Better

At the same time, Kallasvuo noted, "many economies are still experiencing rapid GDP growth, even as we speak." The proof is in the numbers: Year-over-year unit sales growth in Latin America was 14.6%, while the Asia-Pacific region, excluding Greater China, grew 13.9% and the Middle East and Africa climbed 11.4%. These aren't piddling markets, either: The three regions together accounted for 56% of Nokia's total volume.

Posted by CEOinIRVINE
l

The iPhone Isn't A Great Phone

IT 2008. 10. 19. 03:21
Burlingame, Calif. -

Apple's iPhone could be the most awesome 4.7 ounces of gadget on the planet.

It surfs the Web. It plays music. It plays games. It can download new applications on the fly.

It is not, however, the world's greatest mobile phone. There, we said it. Yes, despite Apple (nasdaq: AAPL - news - people ) Chief Executive Steve Jobs' maniacal attention to detail, the iPhone isn't perfect.

Just ask telecommunications consultant Gregory Gorman. He loves his iPhone and takes it everywhere with him.

Yet when he wants to actually, you know, call someone, he grabs his Nokia (nyse: NOK - news - people ) N95.

"It's not consistent enough an experience from a voice perspective that I'm willing to go to that phone exclusively," Gorman says. "There are dropped calls, the call quality isn't great and sometimes you just get disconnected."

He's not alone. While consultant Andy Seybold says the iPhone has "changed the game forever," he doesn't use one.

Instead, he carries a BlackBerry for e-mail and a Motorola (nyse: MOT - news - people ) 750 flip phone for placing calls.

"The only real combination product that ever sold well is a clock radio; everything else is a compromise," Seybold says.

Not that there's anything wrong with the iPhone.

Will Strauss, president of Forward Concepts, says the iPhone uses many of the same parts used by other phones around the world. That means in terms of call quality it's no better, or worse, than many of its competitors.

However, Apple has struggled to adapt to 3G, releasing new software last month to help smooth things out.

That's common, Strauss and Seybold say. Most phone companies struggle to adapt to the new high-speed networks.

However, it's just a matter of time, experts say, before Apple makes the software tweaks needed to overcome that.

Another problem is that AT&T (nyse: T - news - people ), iPhone's service provider, is still building out its high-speed network. That means high-speed data service isn't available in many areas.

The real problem for Apple is that it's tough to build a smart phone that can compete with the ease of use of a simple flip phone equipped with buttons.

"Steve Jobs is trying to cast the iPhone as a great corporate phone and a great small business phone and a great game device, and it can't be all of these things," Seybold says. "The iPhone is not all things to all people; the BlackBerry is not all things to all people."

Of course, this doesn't make the iPhone any less irresistible. Strauss says he knows at least two engineers at Motorola who carry them. "They love them and think they're great," Strauss says.

Posted by CEOinIRVINE
l

Linux Daylight Saving Time

IT 2008. 10. 15. 03:33
How to : DST settings on Redhat 4.0 and any other OS.


Wikipedia defines DST as follows:
Daylight saving time (DST), also known as summer time in British English, is the convention of advancing clocks so that evenings have more daylight and mornings have less. Typically clocks are adjusted forward one hour in late winter or early spring and are adjusted backward in autumn. Details vary by location and change occasionally; see When it starts and stops below.

Do I need to apply the DST patch on my server?

DST patch is only required in few countries such as North America countries (e.g. United States. DST is not required in India and Asia (China, Hong Kong, Macau, Taiwan) at all (however once we had DST). Please see this wikipedia article. It display usage and a short history of daylight saving time by location in alphabetic order.

Daylight Saving Time map image worldwild
(See DST heat map)

Do I need to apply the DST patch on AIX/UNIX/Linux/HP-UX/Solaris/Windows servers running in IST (Indian) timezone?

I’ve received at least 8-10 email regarding IST timetonze. Short answer is no (see heat map).

Task: Verify if you need DST update i.e. display timezone data

Use the zdump utility to display timezone data.
# zdump -v Australia/Queensland
# zdump -v /etc/localtime | grep 2007

If you see date “Sun Mar 11” your system is already patched and no need to read further.

Many of our servers located in north America and all of these server powered by RedHat enterprise Linux or Debian Linux or MS-Windows server 2003.

If you are running RHEL 4.0...

Update tzdata package:
# up2date -u tzdata
# system-config-date

OR
# cp /usr/share/zoneinfo/ America/NewYork /etc/localtime
# zdump -v /etc/localtime |grep 2008

If you are running Debian/Ubuntu Linux...

Use apt-get to update tzdata package:
$ sudo apt-get install tzdata
OR
# apt-get install tzdata

Run tzconfig to update your configuration:
# tzconfig
# zdump -v /etc/localtime |grep 2008

Microsoft Window Server / XP DST

Please see - how to configure daylight saving time for the United States in 2007

Sun Java and DST

A few servers running Sun Java requires update as well.

Manually update DST under Linux

You can manually update your configuration by following these inductions as well.

Check DST using a Webbrowser

You can also check your Linux or Windows workstation by visiting the University of Minnesota's DST time check site (browser with javascript support required).

'IT' 카테고리의 다른 글

Nokia: Investors Cheer Mixed Results  (0) 2008.10.19
The iPhone Isn't A Great Phone  (1) 2008.10.19
Earphones offer good sound, bad fit  (0) 2008.10.14
Tech, Telecom, and Web Earnings Look Bleak  (0) 2008.10.14
[5] Snort Tuning: Reduce False Positives  (0) 2008.10.14
Posted by CEOinIRVINE
l

(CNET) -- Purists might not like it, but mobile phones and MP3 players are converging at a record pace.

Earphones offer good sound, bad fit

Even reputable professional audio companies are starting to take notice, as evidenced by Shure's latest personal earphone offering, the SE102 MPA.

The $99 sound isolating set comes bundled with an extension cable with an inline mic and call button, so it's designed to play nice with your iPhone or other music phone.

The SE102s aren't the best Shure earbuds we've laid ears on -- the type and number of ear fittings is limited and audio is a bit brittle at times -- but they're still a big improvement over the sets that come with most music mobiles.

The Shure SE102 MPA earphones are fairly standard in design. Each black earpiece is bulbous and conical with an angled arm that fits into the ear.


Shure includes four sets of silicone ear tips -- one small, two medium, and one large -- but no flanged or foam set, which prevented us from getting a completely secure fit. We really had to shove them in our ear to hear any bass and as the ear pieces are fairly large, this did not make for a particularly comfortable experience.

Also, the apertures of the arms are a bit larger than other SE models, so you can't use any of the tips designed for other Shure sets. Still, those with average-to-large ears shouldn't have too much trouble. When you're not wearing the earphones, you can store them in the soft travel pouch included in the box.

The SE102's cord style is typical of the SE line. The initial 18-inch Y-cable terminates in a 3.5mm gold-plated straight plug with the dual-band design accepted by the majority of MP3 players. (Each band outputs a channel--left or right--combined for stereo audio.)

Shure then includes a 3-foot extender cable--a necessity for any listening scenario where you're not wearing your device around your neck or carrying it in a shirt pocket. As the SE102 MPA's name suggest, the extender is a music phone adapter with an inline mic and call answer/end button.

The MPA terminates in another gold-plated straight plug, this one with a triple band design--the extra one is for the input from the mic. (Note that triple-banded plugs won't work properly with many standard MP3 players.)

Calls taken through the Shure SE102 sound quite good on both ends, as well they should given the wired design. Music audio quality is also good, for the most part.

The SE102s provide a nice thump on the low-end, but only if you can get a really good seal with the ear. In fact, we noticed some distortion on one bass-heavy track, so they may be a bit too heavy at times. Also, some fast electronic and alternative can have a tendency to come across slightly brittle and harsh, but some may find the extra crispness at the high-end appealing.

In general, though, audio has a nice, balanced response across all genres. Music sounds clear and solid overall, though not as stunning as with higher-end Shure SE models. Still, the SE102 earphones are on par with other $100 sets


Posted by CEOinIRVINE
l

Analysts say third-quarter results are likely to be dragged down by the global economic crisis

High tech, an industry that once seemed shielded from the U.S. financial crisis, has grown increasingly vulnerable. Evidence will begin arriving of just how much impact the meltdown has had on some of the nation's biggest tech companies when they release results for the third quarter and issue outlooks for the make-or-break yearend period.

The Nasdaq stock market has tumbled, and analysts have slashed growth and share-price forecasts for a range of tech bellwethers, from chipmakers to consumer electronics giants to vendors of telecommunications gear, as customers tighten their belts and slash spending plans. Companies reporting in the coming days and weeks include Intel (INTC), eBay (EBAY), Apple (AAPL), and Google (GOOG).

Falling demand for computers and the chips needed to run them is likely to show up in results released by Intel, the world's largest semiconductor maker, which reports on Oct. 14. Analysts expect Intel to report a 34¢ per-share profit on sales of $10.27 billion, but they'll be on the lookout for any signal that they should reduce fourth-quarter projections for profit of 40¢ per share on sales of $10.87 billion. Intel rival Advanced Micro Devices (AMD) reports on Oct. 16; analysts see it posting third-quarter sales of $1.4 billion and a loss of 40¢ a share. They expect a 25¢-per-share loss on sales of $1.6 billion for the fourth quarter.

A Lower-Cost Apple Laptop?

On Oct. 9 market researcher iSuppli trimmed its forecast for 2008 worldwide semiconductor revenue growth by a half-percentage point, to $280 billion. "We had already begun to see signs of problems among chip companies before the credit crisis hit," says iSuppli analyst Dale Ford. Gartner (IT) said sales of semiconductor capital equipment, the gear chipmakers use in their factories, will decline more than 25% this year and continue to slide in 2009.

The first big computer maker to release figures for the September quarter is Apple (AAPL), which reports on Oct. 21. There's growing concern that Apple may be experiencing a slowdown (BusinessWeek.com, 09/24/08) in Mac sales. "Cracks may be starting to form in its PC business, where the firm has enjoyed growth driven by the iPod and iPhone halo effect, and by broad-based share gains," wrote FBR Research analyst Craig Berger in a research note issued on Oct. 8. Berger estimates that Apple has cut its orders by 17%. The company is expected to report sales of $8.07 billion and per-share profit of $1.11. For the December period, Apple is expected to record $10.83 billion in sales and a $1.70 per-share profit.

Apple is also set to take the wraps off a new line of notebooks on Oct. 14. Piper Jaffray analyst Gene Munster says he expects Apple to reveal, among other things, a notebook that sells for $899 to $999, less than the company's other computers. A lower-priced notebook would help explain a drop in gross margins that the company warned about (BusinessWeek.com 07/22/08) when it last reported earnings in July.

Posted by CEOinIRVINE
l

Fine Tuning: Reducing False Positives

You can fine-tune your Snort installation to reduce false positives. The single largest, easiest way to approach that goal is to turn off unneeded rule processing.

Removing unnecessary rules

Thousands upon thousands of rules come standard with Snort, and that number doesn’t include any that you may have borrowed from elsewhere or created yourself. Probably less than half of these rules are relevant to what is running around your shop.

Cataloging your network

Probably the best place to start when you want to remove rules is with your network topology map. If you have a gigantic ocean-crossing organization, you have lots of network diagrams laying about giving you the placement of your technology assets with specific details on the hardware in use, operating system, installed applications, available services, and such access credentials as the user and group.

 Tip  The best filters to strip unneeded rules from your setup are operating systems and installed network applications.

Scanning your network

Scanning your network is a quick way of finding out whether any rogue services or rogue computers are lurking on your IP network. Looking through the eyes of the enemy is often rewarding from a planning and understanding standpoint.

Your favorite tools for network or service mapping are ideal for collecting this info. For example, NMAP (a popular open-source network mapping tool, found at http://www.insecure.org/) produces a very quick understanding of how curious passers-by see your network.

Commenting out any unneeded rules

Your goal in creating this network audit is to find rules in your Snort rules directory, open them, and place a “#” before them, which disables them from being found or logged.

 Tip  If you have a network of only Windows 98 workstations and those platforms don’t offer any services, you can safely disable all the Linux and Unix exploits, probes, and other attacks within Snort. It’s a waste of time to see them in your logs or have Snort look for them.

Coming up with an action plan

Let’s say you’re running a 30-person insurance claims-processing office, with lots of medical and financial records stored on four different file servers (all four running Windows 2003 Server). The company processes its own e-mail and Web services, outsources spam and virus-filtering to a third-party, and runs a few custom applications to handle the ordinary course of business. Staff members also use Windows XP Professional computers and laptops for daily activities. The office does not have any Macintosh or Unix computers (although e-mail may be moved to an open-source solution, time permitting). There’s a firewall for NAT. Access Control Lists (ACLs) block everything except inbound mail to the mail server and Web traffic to the Web server.

This office’s system administrator first needs to organize what’s known about the network into a report. Table 9-2 summarizes the most important points from the preceding example network.

Table 9-2: Network Summary

Host IP Address

O/S

Exposed Services (Ports)

10.0.0.1

Cisco Routers & Switches

None

10.0.0.2

Windows 2003

25, 80

10.0.0.3

Windows 2003

25, 110, 143, 993, 995

10.0.0.4

Windows 2003

80, 443, 3218

10.0.0.5

Windows 2003

80

10.0.0.6-

Windows XP Professional

Not available through the firewall 10.0.0.28

The network summary is your roadmap for removing unneeded junk from your rules and configuration files. For example, most of the rules in web-cgi.rules still apply. However, you can comment out almost half of the lines in shellcode.rules and everything in rservices.rules.

Usually, you decide which rules to remove based on several factors: The source and destination ports, the protocol, and the message body of the rule, which should give you an extra bit of explanation of whether the rule applies.

For example, check the following rule from the exploit.rules file:

alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"EXPLOIT x86 windows 
               MailMax overflow"; flow:to_server,established; content:"|eb45 eb20 
               5bfc 33c9 b182 8bf3 802b|"; reference:bugtraq,2312; 
               reference:cve,CVE-1999-0404; classtype:attempted-admin; sid:310;  
               rev:5;)
  • The header of the rule indicates that it’s designed to catch an exploit directed at an SMTP (mail) service listening on the well-known port 25.

  • The message part of the body of the rule suggests that the exploit was engineered to operate on an Intel x86 processor running the Windows operating system and the MailMax application server software.

Many of the stars align for this rule to match the example network, but not all of them. For example, if the mail implementation is offered using the Microsoft Exchange service instead of MailMax, the buffer overflow indicated by this rule isn’t a threat. You can safely comment it out.

Using a security audit tool

A security auditing tool is an excellent way to tune your Snort installation. A vulnerability scanning tool produces a detailed view of the specific vulnerabilities that each host on your network may be susceptible to.

We recommend investigating a very robust and capable tool called Nessus (http://www.nessus.org/), which was written by developers guided by the same principles that drove Snort’s creation:

  • An extensible client-server architecture using plug-ins.

  • An up-to-date set of vulnerabilities in its testing database.

  • A robust scripting language.

The Nessus server runs on Linux and Unix systems, and a client is available for Windows systems (NessusWX).

Once Nessus has been executed against your internal network, you can use its output to locate machines that are vulnerable to attacks. If you can patch the vulnerabilities Nessus found, then by all means patch them. If you can’t patch the vulnerabilities, then your Nessus output is a list of attacks you need to watch out for.

Nessus can test thousands of attacks (all developed as plug-ins). Once a Nessus report is available, we found that the most ideal method for locating and editing your Snort rules is to compare one of the unique identification tags that both systems share:

For example, after running Nessus, you find that hackers can use CVE-1999-0494 against one of your mail servers. A little shorthand Unix grep- ping easily locates that rule within Snort’s rule files:

# cd /usr/local/snort/rules
# grep "CVE-1999-0494" *.rules
pop3.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET 110 (msg:"POP3 USER overflow attempt"; flow:to_server,established; content:"USER"; nocase; content:!"|0a|"; within:50; reference:bugtraq,789; reference:cve,CVE-1999-0494; reference:nessus,10311; classtype:attempted-admin; sid:1866; rev:5;)

 Warning   You found a vulnerability. Make sure that you patch it and update your Snort rules.

Posted by CEOinIRVINE
l

Preprocessing Punk Packets

Snort relies on a packet-sniffing subprocess using the pcap library of functions, which it gets from either the Linux libpcap library (see Chapter 4) or the Windows WinPcap driver (see Chapter 5). Snort is a network packet sniffer, so it works by detecting well-defined patterns (signatures) as network traffic flows by. As Figure 9-1 shows, preprocessing is the first stop on the long train ride for a packet through Snort’s systems.

The signature analysis that most people associate with a network IDS comes into play with Snort’s detection systems, which are built by using the rules files explored in Chapter 8. Snort has a robust and flexible system of rules; that flexibility puts a lot of bullets in the belts of security administrators.

This low overhead and plug-in architecture gives Snort such a remarkable efficiency. You can turn on or off different elements as needed for every installation, which is one reason why Snort fits “just right” in most environments. If you don’t need certain functions, turn them off. Preprocessing is one of the shining examples of that philosophy in action.

Image from book
Figure 9-1: Follow Snort’s nose as data packets travel through its many systems.

Defining preprocessing

 Remember  Preprocessing fits into this whole quilt at the lowest level: the network layer. The purpose of preprocessing is to remove as much work as possible from the detection engine and associated plug-ins (which are far more processor intensive) by removing packets that just waste Snort’s time.

 Tip  Imagine having a million tiny balls of three different colors — red, blue, and yellow — and each ball has a number printed on it. Preprocessing is like sorting the jumbled balls into three trash cans by color and then looking through the pre-sorted balls for a specific number. If you know that only red balls can represent an attack in progress, then it makes no sense to spend time carefully checking the numbers on any of the blue and yellow balls.

Understanding the benefits of preprocessing

Preprocessing performs lots of useful tasks for a well-oiled Snort IDS. It provides a clearer picture of a stream of communications between the computers, instead of just relying on a single packet without any context. When two computers are exchanging information, the “conversation” that they’re engaged in is usually called a session. Sessions have a well-defined beginning and end, as well as rules for who can speak and at what time.

Session analysis reduces both false positives and false negatives and gives the detection engine more visibility of the kind of behavior that is actually occurring. Packet inspection with preprocessing can reveal a lot about what tricks those wily hackers are employing to subvert the integrity of network communications, and possibly evade network security sensors.

Looking under the packet magnifying glass

When normal network communication transpires (for example, when someone is browsing for a movie showtime on Yahoo!), little bits of data go back and forth in a well-defined, choreographed dance. Some advanced packet preprocessors detect ill-formed and inconsistent packets, which are usually indicative of illicit behavior. Such network scanning tools as Nmap and Strobe allow for the manufacture of fake packets that can cause information leaks and system crashes.

Detecting anomalies

Snort implements its preprocessing functions at the decoder level after the packet has been broken out into its major fields and before the rule-processing engine does any pattern matching or rule analysis. This processing order gives you the most flexibility and keeps Snort operating at near-wire speed.

When you implement more and more front-end analysis, speed is sacrificed. In essence, the more examination you do, the slower the entire system, but, the better the results. One of the most important themes with tuning Snort — or any other IDS — is trying to find that fine line between too much noise and missed attacks: Eradicating false positives should be your first and foremost goal.

This goal makes Snort’s method of preprocessor plug-in design a well thought- out and attractive option. If you want to expend the extra resources to scour packet streams for more data, simply turn preprocessing on. If you don’t want the hassle, turn preprocessing off.

Keeping packets in a row

In this section we explore how we can setup and use the best of the preprocessors that come standard with your Snort distribution: stream4 and frag2. Without stream4 and frag2, your Snort system would be oblivious to scans against your network and attempts to bypass your IDS or firewall.

The stream4 preprocessor

The stream4 preprocessor was built to help Snort get a better view of TCP sessions by providing stateful inspection and session reassembly. According to its original design, Snort is basically stateless. The stream4 preprocessor, when enabled, allows Snort to monitor thousands of concurrent sessions and has the added flexibility of activating state management for user-defined ports. By restricting the preprocessor to only a few ports, you can save a lot of processing power, which would normally be wasted on trying to keep track of potentially millions of sessions in a large-scale network.

Also, you can set stream4 to alert you when sniffed packets aren’t part of any session at all. This event really only occurs when a hacker is trying to masquerade as one of the computers involved in a session or is trying to insert himself into the communications stream, often called a man-in-the-middle attack.

Stream4 also allows the construction of rules using the flow keyword that can identify the direction and state of the traffic. These rules are especially helpful in determining how sessions begin and end and whether an attack is inbound or outbound from your network, as well as giving some indication as to the nature of the session. (Chapter 8 shows rules building and testing, including many rules that rely on the stream4 preprocessor for a complete analysis.)

Configuring the stream4 preprocessor

 Tip  To enable stream4, open your snort.conf file with a text editor and make sure that the following line is uncommented:

preprocessor stream4: detect_scans, keepstats machine

The stream4 preprocessor has several different options, which you include as a comma-separated list, as shown in the preceding example. The following options govern what you can configure the preprocessor to look for (including portscans and state problems):

  • detect_scans: The detect_scans option (which is normally set to Off if it’s not included on the configuration file) instructs the stream4 preprocessor to alert when a portscan is attempting to avoid detection by using stealth techniques. Because the regular way TCP/IP traffic works involves a three-step handshake, which many types of stealth portscanners intentionally fail, they’re snooped out by using this stream4 parameter.

  • detect_state_problems: The detect_state_problems option (which defaults to Off if not explicitly set) instructs the stream4 preprocessor to analyze how the state of a flow of TCP packets is kept. This feature is intended to catch faults or failures if the state mechanism of a TCP session is somehow altered by a peer. Given how noisy this parameter can be, we don’t recommend it unless you intend on doing some heavy in-depth analysis. Although good at detecting packets that are malformed, many implementations of TCP/IP have small variations that trip this sensor.

  • disable_evasion_alerts: The disable_evasion_alerts option is an advanced setting that detects special cases where an attacker tries to fool an IDS detection engine into ignoring a packet, but the packet gets to the target.

     Tip  We recommend leaving this option off (which is the default). It can generate many false positives and eat lots of processing power.

  • ttl_limit: TTL means Time To Live and is a common term used when talking about packet transmissions over a network. A TTL setting can help keep tabs on how much time a packet flow takes to reach its destination. Sometimes an attacker tries to evade detection or masquerade as being somewhere else by twiddling the TTL settings with a session. You can use the ttl_limit option to alert you to a big variation in the TTL setting across a stream of traffic. This parameter is hard to tune properly, but it’s a safe bet to use 10 as a starting point as the maxi- mum TTL.

  • keepstats: The keepstats parameter accumulates a set of statistical data on the connection tracking and session state analysis, which can be logged with either the machine keyword (which actually is a text file) or the "binary" keyword, which tools such as Barnyard can read.

  • noinspect: To curb excessive processing on a busy Snort installation, the noinspect switch can restrict the stateful inspection to only those ports listed with the stream4_reassemble preprocessor.

  • timeout: The timeout parameter sets an idle time after which stream4 stops monitoring a particular session. Basically, if Snort doesn’t see a packet as part of an active session in its table within the time specified by the timeout switch, then that session is flushed from memory. Because this option defaults to 30 seconds without even specifying it, Snort’s normal behavior is to only perform stateful analysis of traffic that has been active within a 30-second window.

  • log_flushed_streams: The stream4 preprocessor works by building a session block from the little packets that comprise the entire stream. Using this method, the preprocessor can look for anomalous behavior and perform rule testing. This session block, which is kind of like a gigantic packet, can be flushed to disk for troubleshooting and further analysis. The log_flushed_streams parameter to stream4, if used, instructs the preprocessor to drop the session block in the logs when it triggers an alert.

Our advice is to experiment with the preceding options, see what works well for you, stick with it for a time, and then go back and tune as attack trends change.

Stream4 and session reassembly

Somewhat similar to session tracking (see the preceding section), Snort’s stream4 preprocessor also supports full session reassembly. By keeping a window of packets that comprise a session in memory, Snort can alert you to attacks that span multiple packets.

TCP connections can have data fragmented across a group of packets, while UDP transmissions are required to contain all the data in a single packet. Many applications that use TCP for their transfer medium are interactive in nature and often have lots of fragmentation. SSH and telnet session are notorious for splitting data in this way.

By reassembling packets, Snort’s analysis and detection engines can catch the sneakiest of attacks. For example, say that you wanted notification when someone transmits a sequence of characters containing /etc/passwd (the location of the users and groups on a Unix operating system) over a telnet session. Telnet sends a separate packet for each keystroke. So, in essence, what you’d have is thousands of little packets, with one character in each, which is horrible for a rule-matching system like Snort. Reassembly globs all of those individual packets into a giant packet to which the rules engine can analyze.

Session reassembly is set up in much the same way as the stream4 preprocessor (which we discussed in the preceding section). By adding the following line to your snort.conf configuration file, you can enable the reassembly features.

preprocessor stream4_reassemble: both ports 21 23 80 110

The following options are available in the stream4_reassemble preprocessor:

  • clientonly, serveronly, both: The first parameters given to stream4_reassemble identify which sides of the connection to conduct reassembly on.

    • Clientonly refers to traffic inbound to what you’ve defined as $HOME_NET in your snort.conf file.

    • serveronly refers to traffic outbound.

    • Both means reassembly of everything.

  • ports: The ports parameter directs Snort’s stream4 preprocessor to restrict its reassembly activity to just the ports identified with this switch.

    • By using the default keyword, Snort performs reassembly on ports 21 23 25 53 80 110 111 143 and 513.

    • The keyword all performs reassembly on all ports, which we don’t recommend (except for short periods of testing).

  • noalerts: The noalerts parameter tells stream4 not to report on strange or problematic issues encountered during reassembly. For example, traffic manually inserted into a stream or modified packets is detected and logged, and stream4_reassemble generates an alert, unless this option has been indicated.

The preceding example of stream4_reassemble usage should be enough for most people. If you either use other protocols where you want reassembly to occur or run telnet, FTP, HTTP, or POP on nonstandard ports, change the ports listing to the appropriate application ports for your configuration.

The frag2 preprocessor

Because many varieties of devices are out there (and many can transfer data over TCP/IP), subtle implementation differences result in packets that must sometimes be reorganized and chopped into smaller packets, a process that’s called fragmentation.

 Technical Stuff  To a network-based IDS, fragmentation can result in false negatives (real attacks that are missed) because the attack actually spans several packets. The original offending data may have been in a single packet at the beginning of its journey, but through the normal process of routing, it may have been redistributed over several packets, which hides it well. Such fragmentation poses a special problem for Snort, but, thinking ahead, the Snort team has an answer: the frag2 preprocessor.

By enabling frag2 in your snort.conf file, Snort’s packet decoder uses a similar reassembly process for reconstructing fragmented packets, before submitting them to the detection engine. It takes the pieces and puts Humpty Dumpty back together again.

To enable the frag2 preprocessor, use a configuration like this:

preprocessor frag2: timeout 60

Normalizing network traffic

The decoding and normalization of certain types of network traffic is an important preprocessing chore. Pattern matching systems like Snort can fail when an attacker introduces subtle variations. These variations are perfectly acceptable and even warranted in most cases, but they can be misused by attackers.

There are many ways to encode a Web page address into a URL It’s possible for two encoded URLs to look completely different to the human eye, but are the same as far as a Web server is concerned. For example, the following two URLs are exactly the same, yet they look entirely different.

http://www.somewhere.tld/cgi-bin/form-mail.pl?execstuff
http://0/%63g%69%2d%62in/%66%6fr%6d%2d%6d%61%69l%2e%70l?%65%78%65%63%73%74uf%66

Of course, these different notations can easily trip up a Snort rule, which matches against an exact pattern. In the preceding example, consider that a rule matches the form-mail.pl string of bytes, which generates a Snort alert. The second URL would sneak by the detection engine, though it’s just as lethal as the first.

Snort’s normalization preprocessors are an excellent way to combat these open doors. The following sections cover three of these preprocessors in more depth: HTTP, telnet, and RPC (Remote Procedure Call).

http_inspect: a preprocessor for HTTP

With Snort 2.1, the http_decode preprocessor gave way to the http_inspect preprocessor. If you use Snort 2.0, use http_decode. If you use Snort 2.1 (or later), use http_inspect.

 Tip  We recommend installing and using the http_inspect preprocessor. Using http_inspect normalizes all packets containing different forms of HTTP communication into a state that Snort can easily compare and scan through its rules. A huge amount of Web traffic crosses the Net, and many attacks rely on the HTTP protocol as their transmission medium.

To configure your Snort system so that it normalizes Web traffic, you need to put a few lines in your snort.conf configuration file that look something like the following:

preprocessor http_inspect: global iis_unicode_map unicode.map 1252
preprocessor http_inspect_server: server default profile all ports { 80 }
preprocessor http_inspect_server: server 172.16.1.1 profile all ports { 80 }

The first configuration line, which contains the keyword http_inspect, is for setting up the global behavior of the preprocessor, whereas the other lines with http_inspect_server in them are for specializing the configuration for individual machines. You need to include the iis_unicode_map keyword and its argument. Without it, Snort complains and refuses to start.

The options that follow the http_inspect_server keywords include the

  • Ports on which the preprocessor should operate (between the {}s).

  • A series of operations that should be used when normalizing the traffic.

The options described in the next sections are some of the most useful http_inspect options. They show how HTTP preprocessing really works.

iis_unicode <yes|no>

Characters in English and Western-European languages are normally represented using the ASCII encoding system. ASCII doesn’t cut the mustard for languages that require extended character sets, so a larger encoding system called Unicode, or UTF-8, is used. By using the iis_unicode keyword to the http_inspect_server preprocessor, all non-ASCII characters are converted back into ASCII for comparison.

 Tip  The iis_unicode option is important because it alerts on attempts to hide a URL by using different encoding techniques.

double_encode <yes|no>

Double encoding is often used to preserve % in URI encoding. The percent sign is most frequently used as an escape character within a URL, giving uses the full spectrum of additional characters as part of their input. Because hackers may try to disguise their attempts using a way to obfuscate their traffic with extra %’s, this option helps trap and contain them.

iis_backslash <yes|no>

Windows and DOS systems use the back-slash character \, much like Unix systems use the / character. Web browsers, Web servers, and URLs follow the lead of the Unix world and use the forward slash as part of an encoded URL. Microsoft’s IIS Web server can treat both identically, yet Snort only matches on exact sequences of bytes. The iis_backslash parameter can catch odd sequences of slashes as part of an attacker’s behavior.

apache_whitespace

The apache_whitespace parameter helps when a muck of whitespace characters try to sneak around the detection engine. The apache_whitespace option automatically converts all tabs in a URL into spaces, before the detection engine compares the data in the URL against the Snort rules.

telnet_decode: a preprocessor for telnet sessions

In much the same way that http traffic can be preprocessed before being turned over to the detection engine for adjudication, telnet remote interactive command-line sessions can be sent through a preprocessor.

 Technical Stuff  The two peers using the telnet protocol do their housekeeping via an inline protocol that can often trip-up the Snort detection engine. The inline negotiation channel involves such flow control parameters as discussing features the client and server support and what kind of terminal should be emulated. This noise is useless for the detection engine. By using the telnet_decode preprocessor, telnet protocol chatter can be filtered out before being analyzed for security rule matches.

The following is an example of how to configure telnet_decode in your snort.conf configuration file:

preprocessor telnet_decode: 23

The trailing 23 is the port number that the preprocessor should restrict its activity to. Telnet normally runs on port 23, but if you run your telnet daemon on a different port, then change this number to that port.

 Tip  You can specify multiple ports by adding to the end of the config line, separated by spaces.

rpc_decode: a preprocessor for RPC connections

Applications that use Remote Procedure Calls (RPC connections) use a different connection method than most common network services. Servers using RPC don’t listen on published well-known ports, such as TCP port 22 for telnet or TCP port 80 for HTTP. Servers using RPC bind to a random, unreserved port and publish that they’re available to another application (the local portmapper). You may already be familiar with portmapper if you’ve seen what application is listening on a TCP and UDP ports 111 on a standard Unix computer.

 Tip  How can you snort when you don’t know where to put your nose? The answer is to decode the traffic on port 111, which is the traffic cop port. It isn’t a perfect answer, but it helps get the job done.

To configure the rpc_decode preprocessor, insert the following line into your snort.conf configuration file:

preprocessor rpc_decode: 111 32711

The numbers that follow the colon are ports to regard for decoding. Port 32711 is a port that Sun’s Solaris operating system uses for portmapper in addition to port 111.

Deciding what’s normal and what’s not

A big advantage of using a preprocessor plug-in is the detection of anomalous protocol behavior. With anomaly detection preprocessors, Snort can be extended to detect attacks using more advanced techniques than simple pattern or port matching.

Some of the best examples of this advanced analysis are well demonstrated with the portscan and bo preprocessors.

portscan, portscan2, conversation

Portscanning is a technique that hackers use to “get the lay of the land” of a network that they intend to target. If we compare digital attacks to real-world warfare ones, portscanning is analogous to sending a surveillance and reconnaissance team to catalog the buildings, access portals, and armed guards that protect an installation.

Typical Snort rules can’t see whether an individual packet is part of a probing attack. The portscan, portscan2, and conversation preprocessors operate on both

  • Individual packets

  • Groups of packets

What makes a portscan a portscan? Together, several factors paint a pretty good picture of the prober’s intent:

  • The time over which the packets were sent.

  • The number of destination ports the packets were directed toward.

  • The number of destination hosts addressed by the packets.

Snort’s portscan preprocessor operates by watching for a specified number of packets, sent within a certain timeframe, directed at any of the hosts on our network. For example, portscan produces an alert if it’s programmed with a threshold that 100 different ports were addressed within 5 minutes all from the same IP address source.

The portscan preprocessor is configured in the Snort configuration file with a line like this:

preprocessor portscan: 172.16.100.0/24 10 30 /var/log/snort/portscan.log

For the specifics on those options, check the configuration flags, which conform to this setting:

preprocessor portscan: <network> <# of ports> <time period> <logfile>

The example shows that this instance of the portscan preprocessor is set up to produce alerts whenever someone is probing the 172.16.100.0 Class C network with at least 10 different ports within 30 seconds.

 Tip  A configuration line in your snort.conf file can tell the system to ignore certain networks. This line is handy when you do port scans of your own network for topology mapping purposes. To configure portscan-ignorehosts, edit your snort.conf file and input a line using the following syntax:

preprocessor portscan-ignorehosts: network/netmask

To ignore networks 192.168.4.0/24 and the host 10.10.10.66, add the following line to snort.conf:

preprocessor portscan-ignorehosts: 192.168.4.0/24 10.10.10.66/32
Sneaky stealthy snoops: advanced portscan techniques

The portscan preprocessor has an interesting advanced behavior that helps you detect obvious rogues who are trying to paint a picture of what you have online. Often hackers use specialized tools to try mapping a network by slipping “broken” or “invalid” packets past Snort. Many of those packets should never be seen within the context of normal network communications, and others shouldn’t exist at all. Snort can catch these stealth-scanning methods by using the portscan preprocessor’s ability to detect these manufactured fake packets. Table 9-1 summarizes the most common stealth portscanning techniques.

Table 9-1: Stealth Techniques Detected by Snort

Packet Type

Description

FIN

Only the FIN flag in the packet header is on.

NULL

No flags are on (which should never happen).

SYN/FIN

Only the SYN and FIN flags are present.

XMAS

Only the FIN, URG, and PSH flags have been set.

Back Orifice (bo)

 Technical Stuff  In the late 1990s, an underground hacking group named The Cult of the Dead Cow (CDC) created a remote administration application called Back Orifice (a play on Microsoft’s Back Office program suite) to control Windows operating system computers from afar. While Back Orifice can be used for legitimate system administration, it’s also a favorite backdoor program for intruders. All you must do is trick someone into installing the program, which isn’t hard because it’s small and easy to package with other programs.

 Tip  The bo preprocessor focuses on traffic associated with the Back Orifice tool, which is an incredibly strong indication of a hacker in your midst.

The bo preprocessor can detect the first few moments of a BO connection attempt across the network and alert on it appropriately. Configuring the bo preprocessor is straightforward. Simply edit your snort.conf file and add the following:

preprocessor bo

Experimental preprocessors

A handful of other preprocessors — some developed by groups outside of the Snort development organization — are out there. These experimental and third-party can

  • Handle ARP spoofing. (ARP stands for Address Resolution Protocol and deals with how computers’ IP addresses are found on a local Ethernet network.)

  • Look aggressively for unknown exploit code that hasn’t been identified by a signature yet.

  • Analyze the other protocols found in a standard internal network.

'IT' 카테고리의 다른 글

Tech, Telecom, and Web Earnings Look Bleak  (0) 2008.10.14
[5] Snort Tuning: Reduce False Positives  (0) 2008.10.14
[3] Snort Configuration : Refinement  (1) 2008.10.14
[2] Snort Configuration : Rule Installation  (0) 2008.10.14
Snort Configuration [1]  (0) 2008.10.14
Posted by CEOinIRVINE
l