Internet Security

Privacy Policy

2008-02-29T23:13:00.000-08:00

Internet security Privacy Statement

What follows is the Privacy Statement for allInternet security websites (a.k.a. blogs) including all the websites run under the Id-secure.blogspot.com domain.

Please read this statement regarding our blogs. If you have questions please ask us via our contact form.

Email Addresses

You may choose to add your email address to our contact list via the forms on our websites. We agree that we will never share you email with any third party and that we will remove your email at your request. We don’t currently send advertising via email, but in the future our email may contain advertisements and we may send dedicated email messages from our advertisers without revealing your email addresses to them. If you have any problem removing your email address please contact us via our contact form.

Ownership of Information

Internet security is the sole owner of any information collected on our websites.

Comments/Message Boards

MostInternet security websites contain comment sections (a.k.a. message boards). We do not actively monitor these comments and the information on them is for entertainment purposes only. If we are alerted to something we deem inappropriate in any way, we may delete it at our discretion. We use email validation on most of our message boards in order to reduce “comment spam.” These email addresses will not be shared with any third party.

Cookies

Currently we assign cookies to our readers in order to save their preferences. This data is not shared with any third party. Accessing our websites is not dependent on accepting cookies and all major browsers allow you to disable cookies if you wish.

Third Party Cookies

Many of our advertisers use cookies in order to determine the number of times you have seen an advertisement. This is done to limit the number times you are shown the same advertisement.Internet security does not have access to this data.

Traffic Reports

Our industry-standard traffic reporting records IP addresses, Internet service provider information, referrer strings, browser types and the date and time pages are loaded. We use this information in the aggregate only to provide traffic statistics to advertisers and to figure out which features and editorials are most popular.

Legal proceedings

We will make every effort to preserve user privacy butInternet security may need to disclose information when required by law.

Business Transitions

IfInternet security is acquired by or merges with another firm, the assets of our websites, including personal information, will likely be transferred to the new firm.

Links

Internet security websites frequently link to other websites. We are not responsible for the content or business practices of these websites. When you leave our websites we encourage you to read the destination site’s privacy policy. This privacy statement applies solely to information collected byInternet security

Notification of Changes

WhenInternet security makes changes to this privacy policy we will post those changes here.

Contact Information

If you have any questions regarding our privacy policy, please contact us.

New Info About Spyware cleaner

2007-12-17T07:10:00.000-08:00

In the age of computer when human work is entirely dependent on the Internet, we can't even step ahead without latest advancements. When computer is going to help us in every stream of our life, this is also true that even being a machine, it faces problems like Spyware and Adware. It ultimately affects us, and unknowingly we are sharing our privacy with the strangers. This entire problem not only makes our work suffer but also irritates us. Isn't it? If same, is the scenario with you then you must be aware of latest Spyware Cleaners available all over. Definitely these Spyware cleaner or rather we can call it as Spyware doctors will help us out.

A Spyware removal tool or Spyware cleaner can save our computer from number of ways like:

Protection From Pop Ups: Spyware may attack your system in various kinds: by disturbing, annoying and irritating pop-up ads. Every time you open web page, popup bombarded your screen with their useless information and pictures. You can also encounter with this problem when you are not surfing the Internet. From time to time, they emerge while you are surfing, but these pop ups advertisements are not connected to the websites you are browsing.

Effect On Your Homepage: It normally happens with you, when you detect that the properties of your home page setting is automatically changed in the internet browser and you attempt to correct it fails. This indicates the unwanted Spyware has captured your system. And after that whenever tries to surf or open some webpage, all unwanted Internet pages starts popping up. And as expected whenever you tend to change the settings, it slips back as you open the window of Internet browser. In that situation, you feel the need of any Spyware Adware remover, which helps you to get back in to the normal settings and also increase the speed of your PC.

The threat of Spyware programs is always on your pc until and unless you installed any Spyware cleaner on your computer. As the saying prevention is better than cure, don't think much and take precaution by installing any free anti-Spyware or free Spyware cleaner.

If you want to stop Spyware effects on your computer than go for any authentic anti-Spyware software like Spyware doctor or any other best recommended Spyware cleaner and make your system 100% from Spyware.

Author is admin and technical expert associated with development of computer security and performance enhancing software like Registry Cleaner, Anti Spyware, Window Cleaner, Anti Spam Filter. Visit: Home Page. Learn secrets for an efficient Anti Spyware. Visit PCMantra informative Resource Center to read more about products.

Article Source: Free Articles from http://www.ArticleSphere.com

Securing your computer from invaders

2007-12-17T07:06:00.000-08:00

How do I secure my Microsoft Windows home computer? By implementing the following guideline you will be increasing your computers security integrity making it harder for intruders to break in:

1. Anti-Virus. After installing your operating system or purchasing a new computer the first priority is to immediately install an anti-virus package to protect you when you first connect to the internet. You should choose a package that will automatically update itself on a daily basis or make sure you configure your chosen package to update its virus definitions at a specific time when it is connected to the internet.

2. Patch The Operating System. Once you have your anti-virus installed you can connect to the internet and click on your Update Windows icon which will take you through the process of downloading and installing the latest system patches. Also, make sure that the downloading and installing of important updates is set to automatic.

3. Firewall Defence. Microsoft Windows has a built in basic Firewall but it is always advisable to install a third party Firewall as this will prevent any unrecognised outbound connections or buy a router which has a built in Firewall for the ultimate first line of defence protection.

4. Spyware Protection. Make sure that you have a memory resident Spyware application which monitors any changes that are being made to the registry or Internet Explorer. These tend not to be included in the free Spyware programs available and some of the freeware programs actually contain Spyware. By purchasing a brand named Spyware package you will get a more advanced software package which include the memory resident program and does not contain any Spyware. Configure the Spyware program to automatically download any new updates and allow it to scan your hard drive at least once a week to pick up any malicious code for you to remove.

5. Email Spam. Be sure to set up an email spam filter on your email account. This is a fairly simple process and there will usually be a help icon which will guide you through the process. Basically you will be blocking all email coming into your inbox until you apply a rule that allows only emails that you define as being safe of from know contacts, anything else is sent to the junkbox. You will have to be careful as if you are awaiting an email from a new contact, the email will be sent to your junkbox. You will have to find that email and add it to your safe contacts list and in the future it will arrive in your inbox. DO NOT OPEN ANY SPAMMED EMAILS OR ATTACHMENTS AS THIS WILL INDICATE THAT YOUR EMAIL ADDRES IS VALID AND / OR IT CAN CONTAIN A VIRUS.

6. Wireless Security. If you have a wireless home network then make sure you have wireless encryption enabled preventing any unauthorised connections to your network or internet.

7. Downloading Software or Music. If you download software applications using a Peer to Peer networking program like Limewire or Kazaa then be careful as some of the files can contain viruses or spyware.

8. Backup, Backup, Backup! Purchase an external hard drive as this can be used to backup all your music, video and picture files, just in case your PC becomes infected with a virus and crashes the operating system and you need to re-install Windows. You can the view all of you files without loosing them.

9. Encryption. If you keep sensitive data on your PC then applying encryption to these files makes it hard for someone to view the contents.

10. Passwords. Try to use a password which is not a commonly used name but one that is unique, either by adding uppercase characters and numbers to the word, which strengthens the passwords encryption.

Maxx is a an IT Technician for a modern state of the art Secondary School supporting many users in various areas of IT and specialising in Video Conferencing home and abroad. For more information about anti virus, spyware, computer security, PC hardware and internet security programs then visit www.PC-Dome.co.uk

Hacking Exposed: Network Security Secrets & Solutions (Hacking Exposed)

2007-12-08T06:26:00.000-08:00

Whenever Hollywood does a movie in which someone breaks into a computer, the hacking scenes are completely laughable to anyone who knows the first thing about computer security. Think of Hacking Exposed: Network Security Secrets and Solutions as a computer thriller for people with a clue. This is a technical book, certainly--URLs, procedures, and bits of advice take the place of plot and characters--but the information about hackers' tools will leave you wondering exactly how vulnerable your system is. More to the point, the explicit instructions for stealing supposedly secure information (a Windows NT machine's Security Access Manager file, for example) will leave you absolutely certain that your computers have gaping holes in their armor.

The book describes the security characteristics of several computer-industry pillars, including Windows NT, Unix, Novell NetWare, and certain firewalls. It also explains what sorts of attacks against these systems are feasible, which are popular, and what tools exist to make them easier. The authors walk the reader through numerous attacks, explaining exactly what attackers want, how they defeat the relevant security features, and what they do once they've achieved their goal. In what might be called after-action reports, countermeasures that can help steer bad buys toward less-well-defended prey are explained. If you run Linux, you may want to supplement the Unix information in this book with Maximum Linux Security, another practical-minded and very popular security text. --David Wall

Find more here

Source : http://securityfocus.com

Windows 2000 (Hacking Exposed)

2007-12-08T06:24:00.000-08:00

With a revised Microsoft operating system comes a revised set of security holes and means of attacking them. Hacking Exposed: Windows 2000 presents a snapshot of known Windows 2000 security weaknesses and the tools that have been developed to exploit them, in turn enabling system operators to mount better defenses. This book builds on and contributes to the small but respected Hacking Exposed series, giving network administrators a detailed picture of the threats their Windows 2000 machines face--and all the motivation they should need to install the latest patches right away. Which points out a characteristic of this book: Many of the problems it catalogs are known bugs that shouldn't be a problem if you've installed the latest fixes and have good password and privilege policies. The point: Even with this book on your shelf, keep an eye on the security sites for news of emerging problems.

Joel Scambray and Stuart McClure have chosen to organize their book according to the steps involved in system compromise (identifying a target, gaining access and privileges, using or destroying the system, and so on) as well as by area of vulnerability. In addition to well-written passages that explain general hacking strategies and concepts, the authors devote sections to software (meaning native Windows commands, tools that are part of the Windows NT/2000 Resource Kit, as well as external software). Sometimes, they'll just offer a description, but most of the time, the authors present a step-by-step guide to carrying out the exploit at hand. This is a valuable book that every Windows 2000 expert should read closely. --David Wall

Find more here

Hacking Exposed Windows: Microsoft Windows Security Secrets and Solutions, Third Edition (Hacking Exposed)

2007-12-08T06:21:00.000-08:00

The latest Windows security attack and defense strategies

"Securing Windows begins with reading this book." --James Costello (CISSP) IT Security Specialist, Honeywell

Meet the challenges of Windows security with the exclusive Hacking Exposed "attack-countermeasure" approach. Learn how real-world malicious hackers conduct reconnaissance of targets and then exploit common misconfigurations and software flaws on both clients and servers. See leading-edge exploitation techniques demonstrated, and learn how the latest countermeasures in Windows XP, Vista, and Server 2003/2008 can mitigate these attacks. Get practical advice based on the authors' and contributors' many years as security professionals hired to break into the world's largest IT infrastructures. Dramatically improve the security of Microsoft technology deployments of all sizes when you learn to:

*
Establish business relevance and context for security by highlighting real-world risks
* Take a tour of the Windows security architecture from the hacker's perspective, exposing old and new vulnerabilities that can easily be avoided
* Understand how hackers use reconnaissance techniques such as footprinting, scanning, banner grabbing, DNS queries, and Google searches to locate vulnerable Windows systems
* Learn how information is extracted anonymously from Windows using simple NetBIOS, SMB, MSRPC, SNMP, and Active Directory enumeration techniques
* Prevent the latest remote network exploits such as password grinding via WMI and Terminal Server, passive Kerberos logon sniffing, rogue server/man-in-the-middle attacks, and cracking vulnerable services
* See up close how professional hackers reverse engineer and develop new Windows exploits
* Identify and eliminate rootkits, malware, and stealth software
* Fortify SQL Server against external and insider attacks
* Harden your clients and users against the latest e-mail phishing, spyware, adware, and Internet Explorer threats
* Deploy and configure the latest Windows security countermeasures, including BitLocker, Integrity Levels, User Account Control, the updated Windows Firewall, Group Policy, Vista Service Refactoring/Hardening, SafeSEH, GS, DEP, Patchguard, and Address Space Layout Randomization

Find more here

Windows Server 2003 (Hacking Exposed)

2007-12-08T06:19:00.000-08:00

"The most demystifying source of information since Toto exposed the Wizard. Hacking Exposed Windows Server 2003 eliminates the mystique and levels the playing field by revealing the science behind the curtain." --Greg Wood, General Manager, Information Security, Microsoft Corporation
From the best-selling co-authors of the world-renowned book, Hacking Exposed, comes Hacking Exposed Windows Server 2003. You’ll learn, step-by-step, how to defend against the latest attacks by understanding how intruders enter and pilfer compromised networks and weaknesses. All the new security features and exploits in Windows Server 2003 are covered.

Find more here

Source : http://securityfocus.com

Hacking Exposed [BARGAIN PRICE]

2007-12-08T05:56:00.000-08:00

A lot of computer-security textbooks approach the subject from a defensive point of view. "Do this, and probably you'll survive a particular kind of attack," they say. In refreshing contrast, Hacking Exposed, Second Edition talks about security from an offensive angle. A Jane's-like catalog of the weaponry that black-hat hackers use is laid out in full. Readers see what programs are out there, get a rundown on what the programs can do, and benefit from detailed explanations of concepts (such as wardialing and rootkits) that most system administrators kind of understand, but perhaps not in detail. The book also walks through how to use the more powerful and popular hacker software, including L0phtCrack. This new edition has been updated extensively, largely with the results of "honeypot" exercises (in which attacks on sacrificial machines are monitored) and Windows 2000 public security trials. There's a lot of new stuff on e-mail worms, distributed denial-of-service (DDoS) attacks, and attacks that involve routing protocols.

The result of all of this familiarity with bad-guy tools is a leg up on defending against them. Hacking Exposed wastes no time in explaining how to implement the countermeasures--where they exist--that will render known attacks ineffective. Taking on the major network operating systems and network devices one at a time, the authors tell you exactly what Unix configuration files to alter, what Windows NT Registry keys to change, and what settings to make in NetWare. They spare no criticism of products with which they aren't impressed, and don't hesitate to point out inherent, uncorrectable security weaknesses where they find them. This book is no mere rehashing of generally accepted security practices. It and its companion Web site are the best way for all of you network administrators to know thine enemies. --David Wall

Find more here

Configuring Netscreen Firewalls [ILLUSTRATED]

2007-12-08T05:47:00.000-08:00

The first book on the market covering the #2 best-selling firewall appliances in the world from NetScreen. This book continues Syngress' history from ISA Server to Check Point to Cisco Pix of being first to market with best-selling firewall books for security professionals.

Configuring NetScreen Firewalls is the first book to deliver an in-depth look at the NetScreen firewall product line. It covers all of the aspects of the NetScreen product line from the SOHO devices to the Enterprise NetScreen firewalls. Also covered are advanced troubleshooting techniques and the NetScreen Security Manager. This book offers novice users a complete opportunity to learn the NetScreen firewall appliance. Advanced users will find it a rich technical resource.

* NetScreen is the #2 best-selling firewall appliance in the world (behind only Cisco PIX) and there are no competing books.

* Covers the materials found on the NetScreen NCSA 5.0 exam.

* Syngress firewall books are consistent best-sellers with market-leading books on ISA Server, Cisco PIX, and Check Point Next Generation.

Find more here

Security Power Tools [ILLUSTRATED]

2007-12-06T06:09:00.000-08:00

What if you could sit down with some of the most talented security engineers in the world and ask any network security question you wanted? Security Power Tools lets you do exactly that! Members of Juniper Networks' Security Engineering team and a few guest experts reveal how to use, tweak, and push the most popular network security applications, utilities, and tools available using Windows, Linux, Mac OS X, and Unix platforms.

Designed to be browsed, Security Power Tools offers you multiple approaches to network security via 23 cross-referenced chapters that review the best security tools on the planet for both black hat techniques and white hat defense tactics. It's a must-have reference for network administrators, engineers and consultants with tips, tricks, and how-to advice for an assortment of freeware and commercial tools, ranging from intermediate level command-line operations to advanced programming of self-hiding exploits.

Security Power Tools details best practices for:

* Reconnaissance -- including tools for network scanning such as nmap; vulnerability scanning tools for Windows and Linux; LAN reconnaissance; tools to help with wireless reconnaissance; and custom packet generation
* Penetration -- such as the Metasploit framework for automated penetration of remote computers; tools to find wireless networks; exploitation framework applications; and tricks and tools to manipulate shellcodes
* Control -- including the configuration of several tools for use as backdoors; and a review of known rootkits for Windows and Linux
* Defense -- including host-based firewalls; host hardening for Windows and Linux networks; communication security with ssh; email security and anti-malware; and device security testing
* Monitoring -- such as tools to capture, and analyze packets; network monitoring with Honeyd and snort; and host monitoring of production servers for file changes
* Discovery -- including The Forensic Toolkit, SysInternals and other popular forensic tools; application fuzzer and fuzzing techniques; and the art of binary reverse engineering using tools like Interactive Disassembler and Ollydbg

A practical and timely network security ethics chapter written by a Stanford University professor of law completes the suite of topics and makes this book a goldmine of security information. Save yourself a ton of headaches and be prepared for any network security dilemma with Security Power Tools.

Find more here

Hacking Exposed Web Applications, 2nd Ed. (Hacking Exposed)

2007-12-06T06:05:00.000-08:00

Implement bulletproof e-business security the proven Hacking Exposed way

Defend against the latest Web-based attacks by looking at your Web applications through the eyes of a malicious intruder. Fully revised and updated to cover the latest Web exploitation techniques, Hacking Exposed Web Applications, Second Edition shows you, step-by-step, how cyber-criminals target vulnerable sites, gain access, steal critical data, and execute devastating attacks. All of the cutting-edge threats and vulnerabilities are covered in full detail alongside real-world examples, case studies, and battle-tested countermeasures from the authors' experiences as gray hat security professionals.

*
Find out how hackers use infrastructure and application profiling to perform reconnaissance and enter vulnerable systems
*
Get details on exploits, evasion techniques, and countermeasures for the most popular Web platforms, including IIS, Apache, PHP, and ASP.NET
*
Learn the strengths and weaknesses of common Web authentication mechanisms, including password-based, multifactor, and single sign-on mechanisms like Passport
*
See how to excise the heart of any Web application's access controls through advanced session analysis, hijacking, and fixation techniques
*
Find and fix input validation flaws, including cross-site scripting (XSS), SQL injection, HTTP response splitting, encoding, and special character abuse
*
Get an in-depth presentation of the newest SQL injection techniques, including blind attacks, advanced exploitation through subqueries, Oracle exploits, and improved countermeasures
*
Learn about the latest XML Web Services hacks, Web management attacks, and DDoS attacks, including click fraud
*
Tour Firefox and IE exploits, as well as the newest socially-driven client attacks like phishing and adware

Find more here

Exploiting Online Games: Cheating Massively Distributed Systems (Addison-Wesley Software Security Series)

2007-12-06T06:01:00.000-08:00

"Imagine trying to play defense in football without ever studying offense. You would not know when a run was coming, how to defend pass patterns, nor when to blitz. In computer systems, as in football, a defender must be able to think like an attacker. I say it in my class every semester, you don't want to be the last person to attack your own system--you should be the first.

"The world is quickly going online. While I caution against online voting, it is clear that online gaming is taking the Internet by storm. In our new age where virtual items carry real dollar value, and fortunes are won and lost over items that do not really exist, the new threats to the intrepid gamer are all too real. To protect against these hazards, you must understand them, and this groundbreaking book is the only comprehensive source of information on how to exploit computer games. Every White Hat should read it. It's their only hope of staying only one step behind the bad guys."

--Aviel D. Rubin, Ph.D.
Professor, Computer Science
Technical Director, Information Security Institute
Johns Hopkins University

"Everyone's talking about virtual worlds. But no one's talking about virtual-world security. Greg Hoglund and Gary McGraw are the perfect pair to show just how vulnerable these online games can be."

--Cade Metz
Senior Editor
PC Magazine

"If we're going to improve our security practices, frank discussions like the ones in this book are the only way forward. Or as the authors of this book might say, when you're facing off against Heinous Demons of Insecurity, you need experienced companions, not to mention a Vorpal Sword of Security Knowledge."

--Edward W. Felten, Ph.D.
Professor of Computer Science and Public Affairs
Director, Center for Information Technology Policy
Princeton University

"Historically, games have been used by warfighters to develop new capabilities and to hone existing skills--especially in the Air Force. The authors turn this simple concept on itself, making games themselves the subject and target of the 'hacking game,' and along the way creating a masterly publication that is as meaningful to the gamer as it is to the serious security system professional.

"Massively distributed systems will define the software field of play for at least the next quarter century. Understanding how they work is important, but understanding how they can be manipulated is essential for the security professional. This book provides the cornerstone for that knowledge."

--Daniel McGarvey
Chief, Information Protection Directorate
United States Air Force

"Like a lot of kids, Gary and I came to computing (and later to computer security) through games. At first, we were fascinated with playing games on our Apple ][s, but then became bored with the few games we could afford. We tried copying each other's games, but ran up against copy-protection schemes. So we set out to understand those schemes and how they could be defeated. Pretty quickly, we realized that it was a lot more fun to disassemble and work around the protections in a game than it was to play it.

"With the thriving economies of today's online games, people not only have the classic hacker's motivation to understand and bypass the security of games, but also the criminal motivation of cold, hard cash. That's a combination that's hard to stop. The first step, taken by this book, is revealing the techniques that are being used today."

--Greg Morrisett, Ph.D.
Allen B. Cutting Professor of Computer Science
School of Engineering and Applied Sciences
Harvard University

"If you're playing online games today and you don't understand security, you're at a real disadvantage. If you're designing the massive distributed systems of tomorrow and you don't learn from games, you're just plain sunk."

--Brian Chess, Ph.D.
Founder/Chief Scientist, Fortify Software
Coauthor of Secure Programming with Static Analysis

"This book offers up a fascinating tour of the battle for software security on a whole new front: attacking an online game. Newcomers will find it incredibly eye opening and even veterans of the field will enjoy some of the same old programming mistakes given brilliant new light in a way that only massively-multiplayer-supermega-blow-em-up games can deliver. w00t!"

--Pravir Chandra
Principal Consultant, Cigital
Coauthor of Network Security with OpenSSL

If you are a gamer, a game developer, a software security professional, or an interested bystander, this book exposes the inner workings of online-game security for all to see.

From the authors of the best-selling Exploiting Software, Exploiting Online Games takes a frank look at controversial security issues surrounding MMORPGs, such as World of Warcraft™ and Second Life®. This no-holds-barred book comes fully loaded with code examples, debuggers, bots, and hacks.

This book covers

* Why online games are a harbinger of software security issues to come
* How millions of gamers have created billion-dollar virtual economies
* How game companies invade personal privacy
* Why some gamers cheat
* Techniques for breaking online game security
* How to build a bot to play a game for you
* Methods for total conversion and advanced mods

Written by the world's foremost software security experts, this book takes a close look at security problems associated with advanced, massively distributed software. With hundreds of thousands of interacting users, today's online games are a bellwether of modern software. The kinds of attack and defense techniques described in Exploiting Online Games are tomorrow's security techniques on display today.

Find more here

Source : http://securityfocus.com

Google Hacking for Penetration Testers, Volume 1 [ILLUSTRATED]

2007-12-06T05:54:00.000-08:00

Google, the most popular search engine worldwide, provides web surfers with an easy-to-use guide to the Internet, with web and image searches, language translation, and a range of features that make web navigation simple enough for even the novice user. What many users dont realize is that the deceptively simple components that make Google so easy to use are the same features that generously unlock security flaws for the malicious hacker. Vulnerabilities in website security can be discovered through Google hacking, techniques applied to the search engine by computer criminals, identity thieves, and even terrorists to uncover secure information. This book beats Google hackers to the punch, equipping web administrators with penetration testing applications to ensure their site is invulnerable to a hackers search.

Penetration Testing with Google Hacks explores the explosive growth of a technique known as "Google Hacking." When the modern security landscape includes such heady topics as "blind SQL injection" and "integer overflows," it's refreshing to see such a deceptively simple tool bent to achieve such amazing results; this is hacking in the purest sense of the word. Readers will learn how to torque Google to detect SQL injection points and login portals, execute port scans and CGI scans, fingerprint web servers, locate incredible information caches such as firewall and IDS logs, password databases, SQL dumps and much more - all without sending a single packet to the target! Borrowing the techniques pioneered by malicious "Google hackers," this talk aims to show security practitioners how to properly protect clients from this often overlooked and dangerous form of information leakage.

*First book about Google targeting IT professionals and security leaks through web browsing.

*Author Johnny Long, the authority on Google hacking, will be speaking about "Google Hacking" at the Black
Hat 2004 Briefing. His presentation on penetrating security flaws with Google is expected to create a lot of buzz and exposure for the topic.

*Johnny Long's Web site hosts the largest repository of Google security exposures and is the most popular destination for security professionals who want to learn about the dark side of Google.

Find more here

Extrusion Detection: Security Monitoring for Internal Intrusions

2007-12-06T05:40:00.000-08:00

Overcome Your Fastest-Growing Security Problem: Internal, Client-Based Attacks

Today's most devastating security attacks are launched from within the company, by intruders who have compromised your users' Web browsers, e-mail and chat clients, and other Internet-connected software. Hardening your network perimeter won't solve this problem. You must systematically protect client software and monitor the traffic it generates.

Extrusion Detection is a comprehensive guide to preventing, detecting, and mitigating security breaches from the inside out. Top security consultant Richard Bejtlich offers clear, easy-to-understand explanations of today's client-based threats and effective, step-by-step solutions, demonstrated against real traffic and data. You will learn how to assess threats from internal clients, instrument networks to detect anomalies in outgoing traffic, architect networks to resist internal attacks, and respond effectively when attacks occur.

Bejtlich's The Tao of Network Security Monitoring earned acclaim as the definitive guide to overcoming external threats. Now, in Extrusion Detection, he brings the same level of insight to defending against today's rapidly emerging internal threats. Whether you're an architect, analyst, engineer, administrator, or IT manager, you face a new generation of security risks. Get this book and protect yourself.

Coverage includes

* Architecting defensible networks with pervasive awareness: theory, techniques, and tools
* Defending against malicious sites, Internet Explorer exploitations, bots, Trojans, worms, and more
* Dissecting session and full-content data to reveal unauthorized activity
* Implementing effective Layer 3 network access control
* Responding to internal attacks, including step-by-step network forensics
* Assessing your network's current ability to resist internal attacks
* Setting reasonable corporate access policies
* Detailed case studies, including the discovery of internal and IRC-based bot nets
* Advanced extrusion detection: from data collection to host and vulnerability enumeration
Find more here

The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities

2007-12-06T05:36:00.000-08:00

This is one of the most detailed, sophisticated, and useful guides to software security auditing ever written. The authors are leading security consultants and researchers who have personally uncovered vulnerabilities in applications ranging from sendmail to Microsoft Exchange, Check Point VPN to Internet Explorer. Drawing on their extraordinary experience, they introduce a start-to-finish methodology for “ripping apart” applications to reveal even the most subtle and well-hidden security flaws.

The Art of Software Security Assessment covers the full spectrum of software vulnerabilities in both UNIX/Linux and Windows environments. It demonstrates how to audit security in applications of all sizes and functions, including network and Web software. Moreover, it teaches using extensive examples of real code drawn from past flaws in many of the industry's highest-profile applications.

Coverage includes

• Code auditing: theory, practice, proven methodologies, and secrets of the trade

• Bridging the gap between secure software design and post-implementation review

• Performing architectural assessment: design review, threat modeling, and operational review

• Identifying vulnerabilities related to memory management, data types, and malformed data

• UNIX/Linux assessment: privileges, files, and processes

• Windows-specific issues, including objects and the filesystem

• Auditing interprocess communication, synchronization, and state

• Evaluating network software: IP stacks, firewalls, and common application protocols

• Auditing Web applications and technologies
Find more here

Counter Hack Reloaded: A Step-by-Step Guide to Computer Attacks and Effective Defenses (2nd Edition) The Radia Perlman Series in Computer Networking

2007-12-06T05:33:00.000-08:00

casual among them--seek out softer targets. Counter Hack aims to provide its readers with enough knowledge to toughen their Unix and Microsoft Windows systems against attacks in general, and with specific knowledge of the more common sorts of attacks that can be carried out by relatively unskilled "script kiddies." The approach author Ed Skoudis has chosen is effective, in that his readers accumulate the knowledge they need and generally enjoy the process.

The best part of this book may be two chapters, one each for Windows and Unix, that explain the essential security terms, conventions, procedures, and behaviors of each operating system. This is the sort of information that readers need--a Unix person getting into Windows administration for the first time needs an introduction to the Microsoft security scheme, and vice versa. A third chapter explains TCP/IP with focus on security. With that groundwork in place, Skoudis explains how (with emphasis on tools) attackers look for vulnerabilities in systems, gain access, and maintain their access for periods of time without being discovered. You'll probably want to search online resources for more specific information--Skoudis refers to several--but this book by itself will provide you with the vocabulary and foundation knowledge you need to get the details you want. --David Wall
Find more here

Professional Assembly Language (Programmer to Programmer) (Paperback)

2007-12-06T05:30:00.000-08:00

Every high level language program (such as C and C++) is converted by a compiler into assembly language before it is linked into an executable program. This book shows you how to view the assembly language code generated by the compiler and understand how it is created. With that knowledge you can tweak the assembly language code generated by the compiler or create your own assembly language routines. This code-intensive guide is divided into three sections - basics of the assembly language program development environment, assembly language programming, and advanced assembly language techniques. It shows how to decipher the compiler-generated assembly language code, and how to make functions in your programs faster and more efficient to increase the performance of an application. What you will learn from this book: -The benefits of examining the assembly language code generated from your high-level language program -How to create stand-alone assembly language programs for the Linux Pentium environment -Ways to incorporate advanced functions and libraries in assembly language programs -How to incorporate assembly language routines in your C and C++ applications -Ways to use Linux system calls in your assembly language programs -How to utilize Pentium MMX and SSE functions in your applications

Find more here

How to monitoring security network

2007-11-19T11:39:00.000-08:00

eBay, iTunes, PayPal – these are just a few of the places that most of us enter our credit card and personal information every day. Since the internet became an integral part of each of our lives, the treat of identity theft is a daily reality for all but the most paranoid of internet users.

While we assume that the sites listed above are secure, how many of us have in fact checked to see to what lengths these companies go to keep their user’s information safe from hackers? I’m sure very few.

Because we can’t count on our registrants to be careful when entering information onto the registration website, as event planners, we must make sure that we do the research to ensure that our registrant’s information is safe with our online registration company. We want to send potential registrants to a site that portrays our event in a positive light. This means a website designed to our specifications, with professional quality and ease of use. But, most importantly, it means knowing that all information put online for our event will be safe from identity thieves.

One of the most important aspects of a strong security system is frequent testing and monitoring of those systems. To receive the highest rank of Level 1 PCI compliance from Visa, companies must invest a large number of resources to ensure that they are as secure as major banks and credit card companies. As of yet, very few registration companies hold this ranking, but wouldn’t it be nice to know that your registration company values your registrants’ security enough to make it one of their highest priorities?

Constant monitoring and testing of security is a vital part of maintain the highest possible level of security. Some methods of monitoring include an independent daily audit for over 3,000 security checks, (exceeding the highest government standards including the FBI “Top twenty security vulnerabilities” test) and separate hourly, daily, weekly, and monthly backups that are archived for at least two years.

Other important factors to look for are the TRUSTe and Thawte logos. These companies monitor the strength and maintenance of privacy policies and information encryption. According to the website, to be certified by TRUSTe, companies must have their privacy policy open for review by TRUSTe, post notice and disclosure of collection and use practices of personally identifiable information, and give users choice and consent over how their information is used and shared.

While TRUSTe ensures that companies hold to their privacy policies and never use information without the user’s consent, Thawte verifies SSL (Secure Socket Layer) encryption, meaning that the encryption of credit card information entered on the site if of the highest level possible. However, to be verified by Thawte, companies must meet stringent checklist of qualifications including both authentication and verification processes. For the authentication process, Thawte must confirm that the company registration details are entirely true and that the domain is in fact owned by the requesting party. To complete the verification process, Thawte uses a third party telephone listing to confirm that the authorized person requesting a certificate is employed by requesting party.

These are just a couple of the certifications to look for when choosing your online event registration system. When you send your attendees to the registration site, you want to be 100% sure that their data will be 100% safe so they won’t have to research the security, but if they do, you can be confident that they’ll like what they find.

By:

Article Directory: http://www.articledashboard.com

Source : http://securityfocus.com

Computer security and other

2007-11-04T07:48:00.000-08:00

Computer security has an important role in one's life of computers. This subject should not be taken lightly. Everytime you go online your system is tested. Below I have given you some good tips for your computer life. 1. New Computer When buying a new computer, it is important for you to turn the firewall on. The firewall will not protect you all the way but somewhat. Its better than nothing. 2. Email Attachments in unknown emails are usually a threat. Never open any attachment from an unknown email. Sometimes, the email subject said something about you getting a greeting card and ask you to click the link inside that email. These emails can contain anything from viruses or spyware. If the link inside that email is something like an ip address (http://aaa.bbb.x.y/) instead of a domain name, never click it. 3. Update Your Virus Definition Installing an antivirus will not be enough. Constant update is needed so you can receive new virus definition. New threats are being created everyday and updating your virus definition on regular basis is crucial to detect newer threats. 4. Don't Surf Suspicious Sites Opening a porn site will also increase your risk of getting a virus. Application such as cracks and patches from sites will also increase your risk. Using these tips will decrease the risk of getting your private information stolen by an outsider. However, these tips are not enough to protect your computer as this is only a basic computer security tips. Learn more. http://computertips-rick.blogspot.com/

More articles from this pro: http://www.ArticlePros.com/author.php?Rick Dog

Network storage devices

2007-11-04T02:14:00.000-08:00

The need for storage devices is growing by leaps and bounds. In addition there are a number of options available depending on specific storage requirements. There are numerous options available with SAN. The two most popular variants are Fibre channel (FC) and Internet Protocol (IP). In a FC SAN the disc arrays are connected using fibre channel connections. An FC switch acts as the central point of control for data flowing through the SAN. Hence, FC or IP depends upon the application. If the data is critical, Fibre Channel is a better option. A low cost SAN is an integrated package that includes an FC switch, high-performance software and disc storage that can be hooked up to two servers.

An IP SAN uses the internet small Computer System Interface iSCSI protocol and Gigabit Ethernet over Cat 6 cabling to hook up disc arrays over a Transmission control protocol / Internet protocol (TCP/IP) network. These SANs provide native-level block access and data transfer and are similar in this respect to traditional FC SANs. Essentially a customer data centre requires various transport technologies that enable long distance connectivity in a cost effective manner. Fiber Channel is better for high speed connectivity and applications such as ERP and databases. For a small organization IP SAN would suffice. A judicious mix of both IP and Fiber Channel is required to balance cost and efficiency of storage systems and devices.

NAS and SAN

NAS is a data storage mechanism where the storage devices are connected directly to the network. These devices are assigned an IP address and then can be accessed by clients via a server that acts as a gateway to the data or in some cases allows the device to be accessed directly by the clients without any intermediary. Easy manageability is a important feature of NAS. It is focused on simple file serving needs. NAS and SAN are complimentary to each other. The trend is towards hybrid solutions. SAN can be used as a back end and NAS as the front end ie having a NAS header in a SAN environment.

Large organizations with enterprise networks and a wide geographical spread are opting for SAN whereas small and medium businesses find NAS a better option. In SAN there is a movement towards IP because one can use the same protocol as the network leading to a lesser cost of implementation.
Growth in chassis –based SAN switches is faster than in the fabric switch segment because of SAN and storage consolidation and linking of first generation SAN islands. Also ,the need to implement SAN extension solutions for data replication and business continuity is driving the need for intelligent multilayer SAN switches and related products.

Ultimately the choice between San or NAS depends on a number of factors. The cost of implementation, ease of maintenance, fault tolerance and security are some of the aspects which have to be considered while adapting a particular storage system. It is also possible to have a hybrid system with both SAN and NAS being used simultaneously. . One fit all is no longer feasible and the trend is towards a mixed bag of options.

By:

Article Directory: http://www.articledashboard.com

Computer registry

2007-11-03T13:14:00.000-07:00

Trying to fix a computer registry problem can be a real pain to deal with. Im going to show you a few simple steps you can try to fix your problem, if all else fails I have a surefire way I can tell you about later. Lets get started; here are a few things you need to consider when fixing your registry problem.

-First, take a look back and try to remember when the problem started. Was it a site you visited or did you just turn on your pc one day and the problem was there?

-Second, you need to realize that there are some people out there who like to wreck people's computers for fun. I know it sounds pretty messed up but we are mainly talking about teenagers here who are trying to impress there friends. You need to also realize kids are smart today when it comes to computer technology; they have made it where they have all corners covered. This is a problem for you, because even methods that should work do not.

How can I fix this registry problem on my computer?

Your best bet would be to simply reinstall your windows operating system and see if that clears the problem. In all reality this will probably not work, but it works in a very small percentage of cases. You also need to be prepared to lose all your data on your computer unless you back it up. You could find some great software that will take care of your problem also; you can actually check my blog in the link below for a surefire fix if nothing else works for you. I hope you found this article helpful, and I hope you fix your computer registry.

Corey is a self proclaimed Computer expert. You can do a registry repair scan at http://registryrepaircenter.blogspot.com and Fix Your Computers Registry now!

Article Source: http://EzineArticles.com/?expert=Corey_J_Thompson

Recover Your Data

2007-11-03T13:13:00.001-07:00

Recent technology in the field of online computer backups has made data center disaster recovery plans a breeze.

In the old days (think before 2005), data center disaster recovery plans were only marginally effective. Data had to be stored on CD's, in folders, on zip disks (remember those?), and on backup computers. Many businesses didn't bother to backup data to a separate location at all.

The major flaw with backing up to "the backup computer" has always been an issue of security. Most backup computers are connected to a network in the office, which allows for easy data transfer. Certain threats, like system bugs or viruses, to any of the computers on the network then become threats to all the computers on the network. Clearly, this plan does not represent a secure data backup system.

Advances in technology have addressed these issues. Many computer backup systems now feature online computer backups, and businesses are now able to store their data online, keeping their data centers secure and safe from viruses and system bugs.

Online computer backup systems can add additional security to important data with the use of password systems that restrict access to the data. This type of security extends data protection to address hackers and unauthorized personnel.

Online computer backups also save space at the office. Typically, more data can be stored online than in any folder, CD or even backup computer. This translates to increases in work efficiency and production.

Businesses small and large are now better equipped to deal with any disaster, because all the important data is stored remotely, in a central location, which makes for much more efficient data center disaster recovery plans.

No matter what catastrophe hits, online computer backups have these businesses covered. Business owners can be assured that whether a file got corrupted or a full system crash occurred, their data has remained safe.

Realize, however, that when choosing a computer backup system with an online backup system, it is advisable to make sure that it can deliver the goods. If it can, then you have probably found a data center disaster recovery plan that will maximize your disaster coverage.

A good computer backup system with online computer backup can prevent the untimely death of your business. Click here to find out more about data center disaster recovery plans. Go to: http://hk-data-center-disaster-recovery-plan.blogspot.com/

Article Source: http://EzineArticles.com/?expert=Gil_Nelson

A PHP cache

2007-11-03T13:02:00.000-07:00

If you look at a PHP source file you will notice one thing. It's a source file. Not particularly surprising, but think about when you deploy a PHP application, what do you deploy? PHP source files. Now for many other languages; Java, C, etc when you deploy an application you deploy the compiled file. So, the question that you want to ask yourself is this, how much time does a PHP application spend compiling source files vs running the code? I'll answer that for you, a lot.

There are advantages to being able to deploy source files though. It makes it easy to do on the fly modifications or bug fixes to a program, much like we used to do in the early BASIC languages. Just change the file and the next time it's accessed your change is reflected. So, how do we keep the dynamic nature of PHP, but not recompile our files every time they are accessed?

A PHP cache. It's surprising to me that this concept isn't built into the base PHP engine, but perhaps that's because some company's can sell this add on to speed up PHP. Luckily for us, some companies/open source projects provide this plug in to PHP at no charge. These plug ins are generally known as PHP accelerators, some of them do some optimization and then caching and some only do caching. I'm not going to pass judgement on which one is the best, any of them are better than nothing, but I decided to use APC, the Alternative PHP Cache. I chose this one because it is still in active development and is open source and free.

Alternative php cache can be found at php.net, just look down the left column for APC. It comes in source form, so you will need to compile it before installing it, don't worry about that part. If you're using Red Hat 4 or CentOS4 I'll tell you exactly how to do it. If you're using something else, you'll need the same tools, but getting the tools might be a bit different.

1. The Tools
Do you know how many web sites, forums and blogs I went to with my error messages before I found the answers as to what I was missing when I was trying to install APC - Alternative PHP Cache? Two days worth, but I finally found the correct combination and it's really quite obvious as is everything once you know the answer. There are three sets of dev tools that you will need.

1a. You'll need a package called "Development Tools" this will include all the important dev tools like the GCC compiler, etc.
1b. You'll need a package called php-devel which as you might guess are development tools for PHP
1c. You'll need a package called httpd-devel which of course are dev tools for Apache web server.

On Red Hat or CentOS getting these should be as easy as the following 3 commands:

yum groupinstall "Development Tools"
yum install php-devel
yum install httpd-devel

You'll do these three one at a time and follow any instructions (usually just saying yes).

Now it's time to follow the instructions contained in the APC package. Since these may change over time I'm not going to go through them. They are very complete. If you follow the instructions and get an apc.so file out of it, then you're all set, just modify your php.ini file and you're good to go.

There are two problems that I encountered that you may encounter too. The first is an error when running phpize. I ignored this error and everything succeeded okay, but not before I spent hours looking for the solution to this error. Here is the error.
configure.in:9: warning: underquoted definition of PHP_WITH_PHP_CONFIG

run info '(automake)Extending aclocal'

or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
configure.in:32: warning: underquoted definition of PHP_EXT_BUILDDIR
configure.in:33: warning: underquoted definition of PHP_EXT_DIR
configure.in:34: warning: underquoted definition of PHP_EXT_SRCDIR
configure.in:35: warning: underquoted definition of PHP_ALWAYS_SHARED
acinclude.m4:19: warning: underquoted definition of PHP_PROG_RE2C

People would have had me updating my PHP version from 4.3.9 and everything else under the sun to get rid of this error, but in the end it didn't matter. My APC compiled and installed nicely and I am good to go.

The other slight problem that I ran into was the location of php-config. The install instructions wanted me to do the following:

./configure --enable-apc-mmap --with-apxs
--with-php-config=/usr/local/php/bin/php-config

However my php-config is in /usr/bin/php-config. Making that change allowed this part to work.

So, have at it, once it's done you can expect to see huge improvements in your web site response times and reductions on your CPU load. One more quick note, My server hosts about 20 web sites, but only 3 or 4 are really busy. To reduce the memory footprint of caching everything for all 20 sites I used the apc.filters property. Although this property is slightly flawed for non qualified includes, it worked nicely for my Serendipity blogs. Your mileage with this property will vary according to the software you are using and how it does it's includes.

Jon runs UFC fan site UFC Results come to UFC Results at http://www.ufcresultslive.com for UFC Results, Predictions, News and of course Fighter Rankings.

Article Source: http://EzineArticles.com/?expert=Jon_Murray

Definition Hacking and Hacker

2007-11-03T12:57:00.000-07:00

•What is hacking?

According to Computer Crime Research Center (US), “Hacking is unauthorized use of computer and network resources”.

•Who is a hacker?

A hacker is a gifted programmer; a programmer for whom computing is its own reward and also enjoys the challenge of breaking into other computers, networks, cracking applications, etc.

•How the hacker can hack a system?

Hackers hack by exploiting the weaknesses of the target system, network, etc, for poor configuration applications and web servers, unpatched or old software, poorly chosen or default passwords and disabled security controls.

•Why hack at all?

Hackers hack because they want it that way. There is no specific reason why they do that. Some does hacking to test their computer skills, others do that to steal specific data from the target. Once a vulnerable point is identified in the system, they definitely attempt to hack to try to gain administrative access to the machine.

•Different types of hackers

The different types of hacker are

1.WhiteHats are the hackers that try to make the movement go forward by working as system administrators, security experts and by maintaining web sites with new technologies, news events, bug reports, and much more.

2.Black hackers attack other’s systems; whereas White hackers do exactly opposite i.e., defend against attacks.

3.Crackers penetrate networks and try to take advantage of something they discover in the process; they are really malicious.

4.Script Kiddie, does not really possess any skills except for the tools, uses tools and techniques developed by WhiteHats, BlackHats and Crackers to deface sites, destroy information, and do other types of digital-vandalism.

•Basic Hacking Methodology

The basic steps for any hacking methodology are

1.Information gathering (Probe)

2.Attack (Advancement & Entrenchment)

3.Infiltration or Extraction

•Most Prevalent Hacking Attack Categories

Hackers preferably attack the organizations systems infrastructure and commercial applications. If the systems are well secured then the hacker may resort to social engineering or focus upon the target application vulnerabilities.

The four most prevalent attack categories are

1.Exploitation of Application-related privileges: Some server-based applications run with specific User or group permissions. By using Race conditions or Buffer overflow attacks these applications’ security can be compromised.

2.Client-side manipulation: Hackers bypass client-side validations by supplying incorrect data formats or data to the server in an attempt to reveal both the functionality and secured data.

3.Race Conditions: When the coding is not done properly for an application to access specific variables, files, and data or installed the appropriate checks to implement simultaneous accesses then the hacker can get unintended access to data through both trusted and untrusted server application components.

4.Buffer Overflow Attacks: Normally applications take data as an input and pass it to memory buffers for manipulation. If the coders do not put a checkpoint to check whether the size of data is too big for a buffer then they are bound to be a complications. Hackers may take this condition as an advantage and can embed their own commands within the oversized data package. Perfectly implemented, these commands can acquire System Administrator privileges to the hacker.

•Cyber attacks: What are they?

Cyber attacks happen on a nation-wide scale and includes clogging up the adversary country’s computers which handle sensitive information like logistics, communications, war strategies, shutting down their civil utilities, like national power grid, jamming radar sites, crushing military’s computers, and downing commercial websites, etc.

•Hacker’s tools

There are so many tools available in the Net and also in the market using which anybody can do the basic hacking. A few tools are

1.DSniff -- a suite of programs that can be used in penetration and auditing testing.

2.Ethereal -- the widely used network protocol analyzer.

3.AirSnort -- a wireless LAN (WLAN) tool which recovers encryption keys.

4.Netcat -- a simple Unix utility which writes and reads data across network connections, using UDP or TCP protocol.

•Hacking in day-to-day life

To name a few…

1.Application hacking

2.Email hacking

3.Password hacking

4.Key Loggers…

•The key to winning the war against hackers…

The first step is to know both the state of one’s own network and its vulnerabilities and also the tactics hackers employ and deploy. Strategic analysts proclaim the key, to escape being hacked by somebody, is network security. But again, unfamiliarity of hacker’s activities and ignorance of how to deploy firewalls and other security features effectively can make you the hacker’s favorite target.

“Hope for the best and plan for the worst” should be the motto in drawing strategies against hackers.

Article Source: http://EzineArticles.com/?expert=Pavan_M_Kumar

ZIP then, RAR now. What’s next?

2007-11-02T21:01:00.000-07:00

NUWAR is at it again. It has tweaked its technique one more time.

Last week, WORM_NUWAR.AOP was found arriving as a file contained in a password-protected ZIP archive, an attempt to evade file scanning. The password to the archive is in an image used as message body, an attempt to evade anti-spam technology. While NUWAR is known for its distinct social engineering schemes — either by using sensational email messages about war or love, or by using incredibly timely email details — WORM_NUWAR.AOP had an interesting scheme itself. It used email messages posing as a notification from an antivirus company. “Worm Detected!” the email message declared.

Apart from the specific detection for the file within the archive, Trend Micro also detects the malicious password-protected ZIP file as WORM_NUWAR.ZIP.

Now, a new NUWAR variant is making its rounds contained in a password-protected RAR archive. Detected by Trend Micro as WORM_NUWAR.AOS, the worm was spammed using email messages that continue what WORM_NUWAR.AOP started, albeit with a wider scope: the email messages now also declare “Virus Detected!” and “Spyware Detected”, among others. As with WORM_NUWAR.AOP, the message body is an image file. Trend Micro detects the malicious password-protected RAR archive as WORM_NUWAR.RAR. WORM_NUWAR.AOS, however, was clearly spammed, because it has a propagation routine of its own using email messages that NUWAR has been associated with — messages of love. “For You….My Love”, “I Love Thee”. Like several of its predecessors, on execution WORM_NUWAR.AOS drops NUWAR’s partner-in-crime, TROJ_SMALL.EDW, known for creating P2P-based connection between all affected computers, forming a link that ultimately assists NUWAR in its own pump-and-dump spam attack.

With the release of WORM_NUWAR.AOS, it doesn’t look like NUWAR is letting up any time soon. In just a few months, it has shown an interesting pattern of social engineering tactics. Its authors seem to be always watching out for events to exploit, or, when there is none, they come up with a new tactic altogether.

NUWAR is clearly a social engineering attack. Users are the primary target. Users should therefore be extra vigilant.

Source : Trend micro blog

ZLOB Crosses Over

2007-11-02T20:56:00.000-07:00

ZLOB Trojans, which proliferated in 2006, are known for using fake codec downloads as their social engineering technique to entice users into downloading the malicious software on their systems. Initially, they are also known to affect Windows-based platforms only. Today, this Trojan family seems to be crossing over to the “other side”.

Intego, who recently partnered with Trend Micro to directly distribute Mac security products, tipped Macworld of the existence of a ZLOB Trojan that affects Mac OS X. Intego reports that the malware disguises itself as video program that when opened, displays a message that a codec is needed to run the program properly. In the background, however, it downloads then launches an installer that asks the user to enter administrator password. ZLOB variants are notorious for this type of routine. Thus, Trend Micro detects the said malware as TROJ_ZLOB.GAF.

It can be downloaded from the Web site http://{BLOCKED}tracodec.com/download/ and arrives as a .DMG file, the common format used by Mac installers. Depending on the IP address that downloads the Trojan, this Web site gives back a copy of the Trojan with a different MD5sum. Note that Trend Micro created the detection OSX_ DNSCHAN.A for the DMG file and UNIX_DNSCHAN.A for the Bash script file inside the said DMG.

Malware are crossing over. Mac fandom, beware!

Data provided by Trend Micro Senior Software Engineer Feike Hacquebord. Additional information from Elizabeth Bookman

Source : Trendmicro

Spyware Protection - Is Your PC Protected ?

2007-10-18T08:58:00.000-07:00

No doubt that we use computer in almost every part of our life. Be it at work or at home, computer just as important as other necessity. One part of using a computer is being connected to the internet. This internet connection which can be used for a variety of purposes will sometimes open unwanted doors. These will be in the form of numerous dangers which can hurt your computer’s working abilities. Spyware protection can help to provide the answer.

These protection programs are known under many names. Some of these software programs are more popular than others. These are programs which you can get to detect the presence of spyware and other harmful intruders into your computer environment. While some of these programs are limited in use there are others that you can use in place of these.

You will have the opportunity of downloading these spyware detection programs if you want them. You can also see the demo versions to see if they are worth your time and effort. When you are downloading one of these spyware detection programs make sure that you have chosen the correct version as there are different programs with different specifications that you can choose from.

You will be able to use many different popular spyware protection programs to find and remove or destroy spyware programs. As these are software programs are well known and popular, you have probably heard of their capabilities and features. You will find demo versions to see what can be accomplished with their help.

To see more details about these programs you will need to hunt around for information. The internet is one such option which will allow you to see the different brands of spyware protection programs that you can use for your computer.

When you are thinking about installing any of these spyware protection programs make sure that have the latest version on hand. The latest version which is installed on your computer you will provide you with some of the latest advantages to be found in these programs.

When you look at either downloading or buying any of these spyware protection programs always make sure that you have understood the instructions exactly. This will help in the easier installation of the program. By using these spyware detection programs which have been created to stop spyware invasions you will be able to set your computers system settings to intercept these intruder programs. Spyware protection hits these unwanted programs before they have a chance to get activated from within your computer when you access the internet.

Source : http://spyware removal tips

Backdoor.IRC.Bot

2007-09-25T08:37:00.000-07:00

Systems Affected: Windows 2000, Windows 95, Windows 98, Windows Me, Windows NT, Windows Server 2003, Windows XP

When Backdoor.IRC.Bot is executed, it may create a copy of itself in the %Windir% or the %System% folders.

Note:

* %System% is a variable that refers to the System folder. By default this is C:\Windows\System (Windows 95/98/Me), C:\Winnt\System32 (Windows NT/2000), or C:\Windows\System32 (Windows XP).
* %Windir% is a variable that refers to the Windows installation folder. By default, this is C:\Windows (Windows 95/98/Me/XP) or C:\Winnt (Windows NT/2000).

In most cases, this Trojan uses one or more of the common loading points to ensure that it runs when you start Windows. For information about common loading points, read one of these documents:

* Common loading points of threats in Windows NT/2000/XP
* Common loading points of threats in Windows 95/98/Me

Some of the actions that Backdoor.IRC.Bot can perform include:

* Listening on an IRC channel for commands from a remote attacker, allowing them to control a compromised computer.
* Connecting through TCP port 6667 or 18067 to an IRC server.
* Viewing system information, such as running processes, software installed, and other items.
* Terminating processes.
* Flooding the IRC channels.
* Flooding mailboxes (mailbombing) .
* Executing programs and scripts on the compromised computer.
* Uploading or downloading the files to the compromised computer.
* Updating the version of the Trojan.
* Participating in a Distributed Denial of Service (DDoS) attack on a remote host.
* Searching files on the compromised computer.
* Executing commands on command.com.
* Scanning for computers with the LSASS vulnerability (described in Microsoft Security Bulletin MS04-011)
* Uninstalling the Trojan.

Recommendations

Symantec Security Response encourages all users and administrators to adhere to the following basic security "best practices":

* Turn off and remove unneeded services. By default, many operating systems install auxiliary services that are not critical, such as an FTP server, telnet, and a Web server. These services are avenues of attack. If they are removed, blended threats have less avenues of attack and you have fewer services to maintain through patch updates.
* If a blended threat exploits one or more network services, disable, or block access to, those services until a patch is applied.
* Always keep your patch levels up-to-date, especially on computers that host public services and are accessible through the firewall, such as HTTP, FTP, mail, and DNS services (for example, all Windows-based computers should have the current Service Pack installed.). Additionally, please apply any security updates that are mentioned in this writeup, in trusted Security Bulletins, or on vendor Web sites.
* Enforce a password policy. Complex passwords make it difficult to crack password files on compromised computers. This helps to prevent or limit damage when a computer is compromised.
* Configure your email server to block or remove email that contains file attachments that are commonly used to spread viruses, such as .vbs, .bat, .exe, .pif and .scr files.
* Isolate infected computers quickly to prevent further compromising your organization. Perform a forensic analysis and restore the computers using trusted media.
* Train employees not to open attachments unless they are expecting them. Also, do not execute software that is downloaded from the Internet unless it has been scanned for viruses. Simply visiting a compromised Web site can cause infection if certain browser vulnerabilities are not patched.

Writeup By: Tony Lee

Source : http://www.symantec.com

Calling the CyberCops: Law Enforcement and Incident Handling

2007-09-07T07:27:00.000-07:00

A velvety darkness enfolds the room. From somewhere just on the edge of awareness a strange, rhythmic pulsing disturbs your sleep, yanking you rudely into the conscious world. For a few unreal moments you are disoriented and anxious, until your brain processes the sensory information flooding into it and reaches the conclusion that your beeper is going off. After scrambling madly in the dark, knocking over your bedside lamp, you eventually retrieve the offending little box and peer blearily at its antiseptic charcoal-on-gray message.

It's now 3:00 AM and you're sitting at a console in your computer room at the office, staring at a new directory named "ADMROCKS." You've been hacked. Your personal data space has been violated. Some nameless script kiddie has made a mockery of your well-laid security plans. What are you going to do about it?

History suggests that you'll clean up the mess, file a report with your boss, and maybe, if you're particularly community-minded, post some sanitized logs or exploit scripts to a public computer security forum such as the Security Focus "Incidents" mailing list. I mean, there's no point in calling the cops, right? They can't or won't do anything about it, right? Isn't that what you read all the time in news stories and in complaints posted on the Internet?

To a certain extent, there is some truth to this assertion. There are many thousands of computer intrusions reported each year, and their numbers having been growing far more rapidly than the staffing and training efforts of law enforcement agencies have been able to accommodate. Life is like that sometimes. Does this mean it's pointless to report your breakin to the cops? Of course not. It just means that you need to optimize the quality of the data you provide to them, in order to maximize the chances that they'll be able to help you. Garbage in, garbage out applies here as surely as it does to virtually every other aspect of IT operations.

Most of what we know, or think we know, about cops is based on television shows and movies. Law enforcement is a perennial favorite topic of the entertainment industry, and portrayals run the gamut from self-sacrificing throw-yourself-on-the-live-grenade types to amoral robotic enforcers to frankly evil psychopathic criminals. Law enforcement agents have power to curtail our liberty, or at least ruin our day, and so we either fear or envy them (depending on whether or not you want to be one). Fear breeds loathing and mistrust; envy just breeds more envy. These are marketable emotions from Hollywood's point of view, so it doesn't take much of a conceptual leap to see why it is in their interests to exaggerate the potential for scandalous conduct by officials of the public trust.

The truth is, as it often turns out to be, far less interesting. Cops are just people; they make mistakes, feel impatience, cut corners, daydream, overlook things, and generally behave just like every other human being on this hapless planet. There is nothing that can be or, in my opinion, should be done about this. I like to believe that I'm dealing with other human beings, fallibilities notwithstanding; I'm more comfortable among my own kind. People who never make mistakes give me the heebie-jeebies. But hey, maybe that's just me.

Swinging around once more to the question of whether or not to involve the authorities in your IT crime scene, think about this: are you (and your senior management) willing to provide the resources, both in terms of technical expertise and downtime of the affected system(s), necessary for any chance at a successful investigation and prosecution? Remember that the purposes for which law enforcement agencies exist, as all of us my age or older know from watching "Adam-12," are to 'serve and protect.' Protect people and assets from assault, serve by pursuing and delivering suspected lawbreakers to the judiciary establishment for trial.

Obviously once you've been hacked it's a little late for the 'protect' part, so we should shift our attention to 'serve.' The police will serve you by investigating the crime and, if possible, bringing the responsible party/parties to justice, but only if that's what you want them to do. You're the one who has suffered a loss; you're the one who needs to initiate the process of recovering from that loss to the greatest extent possible.

Corporate entities in a capitalistic economy are concerned primarily with profits, and only those actions which in some way enhance the ability of the organization to generate those profits are likely to be supported. Don't forget this simple maxim when you contemplate what actions to take following a system compromise. The urge for vengeance may be strong, but if it doesn't make sense fiscally, it probably ain't gonna happen (unless of course you own the company, but that's rather rare for a computer security manager. If you are the owner/CEO of the company, you can skip all this philosophical stuff and go straight to implementation. The rest of us will catch up to you there).

In summary, if you want to snag the dude (or, more importantly, if you want anything done to the dude once he's collared), you need to call the cops. Of course, your insurance company might be also interested in documentation of the incident, as might any of a number of other departments, divisions, task forces, and interest groups in some way connected with your organization. However, if do you call the cops, be prepared to give them something to work with.
Thinking like a Cop

Now let's switch roles. You're a detective on a metropolitan police force. In college you majored in accounting and minored in criminal justice. You work mainly on white-collar crimes: bank fraud, embezzlement, stuff like that. The Lieutenant calls you into his office.

"Sit down," he says, "The department's been taking a lot of heat lately because we don't have a dedicated cybercrimes squad. As of today, you are that squad."

You look at him blankly.

"Next week you take a beginning course in Unix, then the week after that one on computer security."

You stand up to leave.

"Oh, and here's your first case...some hacker broke into XYZ Company last night. Get on it."

Sound like a script from a bad cop show? Nope, it's real life. This is more or less the way a lot of computer crimes detectives got their start. Is it the best way to generate cybercops? Maybe not, but often it's the most expedient from a police administrator's viewpoint. In writing about the problem of producing cops that know computers well enough to understand cybercrimes, I coined the phrase "[If you need something that barks and flies,] It's a lot easier to train a parrot to bark than a dog to fly." My point in employing this somewhat labored metaphor is that police work, for all its complexity, is much easier to pick up than the extremely esoteric knowledge needed to plumb the depths of buffer overflows, IP address spoofing, and man-in-the-middle attacks. Most really successful computer security experts have spent years sitting at consoles, hacking away at operating system kernels and coding nifty little utilities for this problem or that. They just can't teach that during the three months or so at the Police Academy.

Be that as it may, most agencies have been forced by budgetary or administrative circumstances to assign minimally computer-savvy investigators to their computer crimes squads. Most officers will therefore be somewhat at a disadvantage if you expect them to come in and know exactly what steps to take to secure evidence from your specific machines and network. Having a cooperative, extremely knowledgeable company representative such as a systems administrator working closely with the investigator is really essential for maximizing the efficiency of the data-gathering phase and minimizing the downtime of involved systems.

Imagine yourself in the cop's shoes, and provide support for the investigation accordingly. Peace officers are public servants, paid from tax revenues, so it makes sense from both a fiscal and a logistical point of view to make things as easy for them as you can. Your goal as the complainant should be to facilitate the investigation; the hardest task the officer should face is tracking and arresting the criminal, not getting access to and gathering usable evidence from the crime scene.
Law Enforcement's Role in Computer Security Incident Handling

Computer crimes are just that: crimes. Violations of existing law. Conceptually they differ little from any of the other so-called "white-collar" crimes, except that they frequently involve perpetrators who have no physical presence at or even near the crime scene. The usual physical evidence relied upon by forensics analysts, such as fingerprints, footprints, tire marks, signs of forced entry, traces of DNA or bodily fluids, and so on, is conspicuously absent when the crime was carried out from tens, hundreds, or even thousands of miles away.

The task of any investigator is to collect as much evidence as can be found at the scene, analyze that evidence for clues to the perpetrator's identity, and then follow up on leads generated by this analysis. When no direct physical evidence exists, inferential evidence, or evidence that some aspect of the system has been modified as a direct result of the intrusion, is the primary source of clues.

Just as in the case of physical breakins, however, the exact nature and positioning of evidence can be crucial to unraveling the chain of events. Time stamps in logs, records of network activity, new directories and files created by the attacker, incoming/outgoing mail or other packets during the period when the intruder was actively exploiting the system; all of these are important pieces of the overall puzzle. It is important to remember that any change made to the system prior to the arrival of the investigator(s) may obscure or even erase vital forensic information. Under most circumstances, the best thing you can do is to take the box off the network and leave it alone.
What's in it for Them?

Why should law enforcement care about your breakin? The answer to this question may seem obvious (that's what they're paid to do), but consider this: police departments generally get their funding based on the number of cases they handle, and often on the number of cases they successfully prosecute. Some agencies have a minimum loss/damage dollar value below which the prosecuting attorney's office won't bother to pursue a conviction. There are simply too many crimes and not enough resources to devote the same level of effort to each one. This is just a fact of life in any society without unlimited manpower and money (and if you know of one that does not belong in this category, please tell me about it).

The primary benefits of involving law enforcement are twofold:

1. You get legal documentation of the event and of your response to it;
2. You initiate a process that may benefit not only your organization, but others who have been or will be hit by this same perpetrator.

The police, on the other hand, look for cases where evidence of sufficient quantity and quality exists that there is a reasonable chance of finding and prosecuting the perpetrator, and for documentable loss that meets or exceeds their mandated minimum value. If you can provide the 'raw materials' they need to justify their involvement, they're a lot more likely to accept your case and pursue it with the vigor it needs for a successful conclusion. That's not to say that they won't even show up if you don't meet these criteria; I simply suggest that the easier you make it for the investigators, the more likely they'll be able to do the job you ask of them. Common sense is just as useful now (but a lot less common, alas) as it was in Thomas Paine's day.
How They View You

As I have taken pains to point out, the folks that are going to show up at your door in response to a report of criminal computer activity are only human. Just as you have preconceptions about them that may or may not change based on your mutual interaction, so they have them about you.

Of course, the nature of any such preconceptions may vary widely by geographical, occupational, or operational identity, as well as (and probably most importantly) according to previous encounters experienced by the investigator(s). If you're a Computer Security Manager at XYZ Corporation and Detective Smith had a very difficult time dealing with your predecessor, or even with your counterpart at a rival company across town, chances are he's not going to be looking forward to your investigation. That doesn't mean he won't be pleasant, or that he won't do a good job--just that he will have his defenses up during at least your first meeting.

You can go a long way towards ensuring a smooth cooperative effort by being professional, cordial, and respectful. Despite what seems to be the prevailing attitude on the 'net these days, most cops aren't out to get you unless you're a criminal. They are professionals, just like you, and appreciate being treated that way. The Golden Rule hasn't lost any of its relevancy.
When to Report, How to Report

As I hope I've established by now, you will have to make the call whether or not to report the incident. If you choose to report, make certain that this decision has been approved and is supported by senior management, or else prepare to get broadsided. CIOs, CEOs, and other three letter executive types don't like to be the last to know about anything that concerns their company, especially where governmental agency involvement is concerned. Any litigation or media coverage resulting from an event needs to be handled by the legal and public relations folks, respectively; to be effective at their jobs, they'll also need as much heads up as you can provide. Dealing with a computer intrusion is really no different than dealing with a physical breakin, with the same considerations and pitfalls. The crime scene needs to be secured as quickly and as tightly as possible, all evidence should be preserved intact, and everyone not directly involved with the investigation should be kept out.

In a complex network environment containing multiple levels of trusted hosts and shared file systems, just finding all the "prints" left by an intruder can be a daunting task. The more familiar you are with and the better documented is your existing system, the easier it will be to determine what, if anything, was modified, deleted, or installed by the attacker. This information is vital, for several reasons. For one thing, it is necessary for making anything like an accurate estimate of monetary damage resulting from the attack. Secondly, the more complete your knowledge of the state of the system, the simpler the task of restoring it to an identical condition (from those copious backups you'd better have made) becomes. Additionally, if you expect to reconstruct a crime in order to understand it, you have to know what the place looked like before the crime was committed.

Much of what follows is going to be necessarily US-centric (because that's where I live), but the general concepts should be extendable more or less intact to any nation where computer crime is likely to surface. Laws and procedures vary, of course, but the basic precepts for investigating and prosecuting crimes are remarkably similar throughout much of the world, because people are people and computers are computers, no matter where they happen to call home.

There are at least six distinct U.S. federal agencies that have jurisdiction over some type of Internet-related crime: The Federal Bureau of Investigation (FBI), the Secret Service, the Customs Service, the Bureau of Alcohol, Tobacco, and Firearms (BATF), the Federal Trade Commission (FTC), and the Securities and Exchange Commission (SEC). According to the publication "How to Report Internet-Related Crime," a product of the Computer Crime and Intellectual Property Section (CCIPS) of the U. S. Dept. of Justice, computer intrusions should be reported to either your local FBI office, the National Infrastructure Protection Center (NIPC) at (202) 324-0303, or your local Secret Service office. Depending on your circumstances, you may wish to involve local law enforcement authorities as well, although chances are good that the ultimate responsibility for the investigation will end up at the state or federal level, since a great many intrusions cross multiple political boundaries.

One of the best ways to ensure that your interactions with law enforcement will be of optimal benefit to both sides is to establish a rapport with the people responsible for computer crimes in your local area before any crimes are committed. Talk with them--find out what they would like to see from you in the event of an incident, and get their take on the proper way to collect and preserve evidence. After all, they're the ones who will have to make use of that evidence in both tracking and prosecuting the perpetrator(s).
The Pros and Cons of Involving Law Enforcement

Deciding whether or not to report can be a complex issue in itself; there are many aspects to consider. Some of the questions that you might want to ask yourself are:

1. How much loss was suffered (and how easy will it be to quantify)?
2. How long ago did the intrusion take place (i.e., how "warm" is the trail)?
3. Do you have complete and unaltered copies of all relevant logs?
4. Is your firm willing to pursue the matter, understanding that the costs may not be insignificant (salaries, backup media, downtime, court appearances, etc.)?

An additional consideration should be that if any of the logs or files needed as evidence contain proprietary or otherwise sensitive information, that information may become a matter of public record during the course of the trial.

One last note: for better or worse, some companies will avoid pursuing an investigation because they have something to hide (or think they do). If your senior management has been involved in any activity that they feel might appear to be incriminating, they may forbid you to bring in law enforcement with little or no explanation. There isn't much you can do about this; you must remember that as a computer security person you usually don't own the data you're protecting. It is management's call, and you will probably have no choice but to go along with whatever they decide.
Following Chains of Command

Any involvement of an outside agency, particularly of the law enforcement variety, is something that most companies control very tightly. Few things will get you in hot water faster than calling in the cops without following the proper chain of command. Any decision to involve an outside organization in the affairs of the company must be reviewed, approved, and supported by senior management. This is doubly true when that organization is governmental in nature, and triply so when it is law enforcement. As I've indicated above, some companies will have to weigh the potential benefits of bringing in law enforcement with the potential risks of having something uncovered they'd rather keep as a company secret. This is not limited to 'hanky-panky;' often proprietary or otherwise business-sensitive information is brought under public scrutiny at a trial. It may even be a strategy of the defense to subpoena information which the company may not want revealed, simply to throw a monkey wrench into the works and cause management to reconsider its commitment to pursuing prosecution. In this instance, as in all others, be certain to CYA.
Collecting Admissible Evidence

To have any chance at all of obtaining a conviction once a cracker is caught, the prosecution will need evidence that is admissible in court. The details of what can and cannot be admitted into a court of law are complex, and vary from country to country; they are outside the scope of this discussion. For our purposes, only a few general guidelines need to be mentioned.

The principal evidence you will probably have will be in the form of logs. It is critically important that you pay heed to the wording of the rules in force in your country governing the use of logs in a trial. For example, U.S. Code Title 28, Section 1732 (28 USC 1732) dictates that copies of logs are admissible, so long as the original logs were made "in the regular course of business ." In a related vein, Rule 803(6) of the US Federal Rules of Evidence states that logs (which might otherwise be considered 'hearsay') are admissible so long as they are "kept in the course of a regularly conducted business activity." This means that you'd be much safer to log everything all the time and deal with the storage issues, rather than try to turn on logging only after a breakin is suspected. Not only is this a bit like closing the barn door after the horse has fled, it may render your logs inadmissible in court.

Any physical object involved in the investigation, be it disk, tape, CPU, CD-ROM, keyboard, right down to the power cord, must be handled in strict accordance with Chain of Custody rules. Essentially this means that all items must be tagged, stored in sealed containers, and the identity of every person who has handled or been responsible for them since they were collected as evidence, along with the date and time, recorded on the label of the container. They must never be left alone in an unsecured location, or otherwise placed in any circumstance where tampering by unauthorized persons is likely to occur. This may seem like a bit much to ask in some circumstances, where many things are happening at once and it is easy to lose track of where things are and who has them. However, a reasonably sharp defense attorney will be quick to pounce on violations of chain of custody rules; if the evidence that is rendered inadmissible by this action is essential to the prosecution of the case, you are SOL. Always err on the side of being too safe and too careful when it comes to evidentiary procedures.
Cyber Crime and the Courts

The interpretation of new laws by the courts is an ongoing and highly dynamic process. Cyberindustry and its attendant cybercrime has, relatively speaking, only recently leapt out from behind a rock and said 'boo' to the judicial system, so crafting, implementation, and final interpretation of computer crime-related legislation is really only in its fractious infancy. It is unlikely that any consistent patterns will emerge until each of the broad areas of legislation has been dragged through the courts (especially the appellate process) a few times.

Meanwhile, it would be prudent to keep abreast of cases being heard and familiarize yourself with the decisions and rationales being issued on an increasingly frequent basis. With the geometrically expanding influence and pervasiveness of the Internet-based economy, every decision that comes out of a computer-related trial is going to carry a great deal of weight, at least until legislation begins to keep pace with the technology. I won't even begin to predict where the legal landscape will stabilize regarding computer crime; you'd have better luck predicting the next lottery winner.

If you figure out how to predict the next lottery winner, however, drop me a note. Maybe we can work something out.

Robert G. Ferrell, CISSP, is the Information Systems Security Officer for the National Business Center of the U.S. Dept. of the Interior. He is also active as a Perl Monger, an Internet Technologist, and a member of the Net Wits. He has been involved with (primarily Unix) systems programming, administration, and security on and off since 1977.

Source : http://securityfocus.com

Intelligence Preparation of The Battlefield

2007-09-07T07:07:00.000-07:00

Introduction

"Intelligence Preparation of the Battlefield" is a term used in the military that defines the methodology employed to reduce uncertainties concerning the enemy, environment, and terrain for all types of operations. It is a continuous process that is used throughout all planned and executed operations. The networked environment which security professionals are tasked with securing is analogous to a battlefield. The myriad of attackers and intruders from the void are the aggressors constantly on the offense. The security professionals are the defenders, entrusted to preserve the confidentiality and integrity of data against these marauders.

Recent efforts focused on assessment of critical systems and infrastructures have turned-up a recurring theme. Specifically, that many system and security administrators are unaware of the level of effort that a determined attacker who is well financed and supported will expend towards successful penetration of a target system or site. Most assume that the major threat will come from "script kiddies", and others, who are simply looking for a soft target, and who will move on to easier targets if the initial attempt at compromise is unsuccessful. While this assumption may be true, consideration should also be given to the concept that an attack may be planned and coordinated to a high degree with the specific intent of breaching the target system no matter the cost or effort required.

Security professionals are expected to have a high level of technical competence, and for the most part this is true. However, these same professionals oft times do not expect the same to be true of those attackers and intruders from whom they defend their sites. Many do not take heed of the axiom that "There's always someone out there smarter, more knowledgeable, or better-equipped than you."
Setting The Scenario

Let's assume that the opposition is well financed and supported, and that their technical expertise is on par with that associated with experienced and well-seasoned security administrators. How might this individual, or possibly attack cell, prepare for a successful penetration of a target system? What are the objectives, methodology, techniques and tools utilized? The following seeks to address the above questions, and extend to those tasked with security related responsibilities an appreciation for the extent and level of effort that, in some cases, may be directed against systems for which they are responsible. It can also serve as a template for an assessment conducted as a preemptive security measure.
The First Steps

The attacker will begin by defining an end-state with regard to the targeted site or systems. This end-state is a clearly defined and obtainable objective. Detailed concepts for courses of action will be formulated and the chosen course of action will concentrate overwhelming "force of effort" at the critical service or vulnerability at the appropriate time and place to achieve the desired effect. Desired results may be denial of service, acquisition of sensitive corporate data, or to establish and maintain access for recurring clandestine access.

Preparation for a successful attack embodies a systematic approach to exploitation. Such an approach fosters effective analysis by enhancing application of professional knowledge, logic and judgment. The attacker will seek to identify and define problems associated with breaching the target defenses, gather facts and make assumptions, develop possible courses of action, and analyze each course of action through 'wargaming". Finally, the attacker will choose the best solution available based on the defined end-state and implement the attack.
Estimate of the Situation

In order to develop a coherent strategy, the attacker will complete a thorough estimate of the situation. He will seek to gain a deeper understanding of the task at hand. A review of known facts and information will be conducted. Specific tasks that must be accomplished will be drawn up, and from this task list a reduced essential task list will be constructed. A determination of all constraints and limitations which may influence task accomplishment will be made. How much time is available, location restrictions - can the target system be accessed from the attacker's current location if outside the physical borders of the country the target is located in, or must he move to closer proximity etc. - the materials required in terms of software and hardware, and the associated cost. The attacker will also determine the acceptable risk. Can he afford to be logged during scanning, is compromise acceptable during the latter stages of the attack, is concealment of the originating attack location necessary, and what about exposure of the sponsor if he is working on the behalf of another entity? Finally, any critical facts and assumptions not covered previously will be addressed, and a continuous time analysis maintained until the attack is complete.
Intelligence Preparation of the Battlefield

How will the attacker accomplish the tasks that have been outlined? By laying out a focused plan for acquisition of critical information required for successful penetration of the target system. The following methodology is an example. Most, if not all, of these steps will be executed:

* Define the Network Environment
* FootPrinting
* Scanning
* Enumeration
* Vulnerability Mapping
* Attack Strategy Development & Wargaming
* Refinement & Implementation of the Attack

Define The Network Environment

Defining the network environment involves footprinting, scanning, and enumeration. FootPrinting allows the attacker to limit the scope of his activities to those systems that are potentially the most lucrative from an vulnerability perspective. Scanning will tell the attacker what ports are open, and services that are running. Enumeration is the extraction of valid account information and exported resources.
FootPrinting

During the footprinting subset of defining the network environment, the attacker's objective is to gather the following information:

* Name and IP of select systems
* Hardware and operating system (including version/build) of the system
* Services available on the system
* Physical location of the system(s)
* Information on individuals associated with the system(s); name, phone #, position, address, knowledgeability etc.
* Build a simple network map for the domain, including connectivity provider and key systems
* Develop any information that may make it easier to conduct "social engineering"

The methodology to accomplish footprinting of the target will involve non-intrusive and stand-off methods. The attacker wants to determine the type of network with which he is dealing, and with whom; system, network, and security administrators. His tactics and techniques will usually involve the following:

* Check for a website associated with the target. Many websites provide a revealing amount of information that can be used in the attack. Other items of interest include: related companies or entities, merger or acquisition news, phone numbers, contact names and email addresses, privacy or security policies indicating the type of security mechanisms in place, links to to other web servers related to the organization.
* Gather information that could be used for social engineering, identity of network systems, system administrators etc. USENET and WEB searches on the system administrators and technical contacts that are found when running host queries. By taking the time to run down this information, the attacker may be able to gain greater insight into the target network. He will also try the system administrator's address on any other machines, if found, when running the host query. Perhaps the system administrator favors one certain machine which can be more readily exploited.

Tools and procedures used to accomplish the task of footprinting:

* Conduct Open Source information gathering on USENET, search engines, Edgar database etc.
* Execute a whois query using the following:

http://www.networksolutions.com/ - whois web interface
http://www.arin.net/ - whois ARIN Whois
http://whois.ripe.net/ - European Whois
http://whois.apnic.net/ - Asia Pacific IP Address Allocations
http://whois.nic.mil/ - US Military
http://whois.nic.gov/ - US Government

or use the native UNIX whois from the command line:

whois |more
whois to gather information on SYSADMIN etc.

Again, the intent is to develop a network map using information gathered during footprinting. The attacker will also want to know who the target gets their upline Internet access from. In the event that he cannot exploit the specified target, he may be able to step back one hop to the service provider for the target and gain access from that vantage point. Additionally, he will figure out which systems are routers and firewalls and place them on the map, as well as identifying key systems such as mail servers, domain name servers, file servers etc.
Scanning & Enumeration

At this point the attacker has a good idea of the machines on the network, their operating systems, who the system administrators are, and any discussions by them as to the topology, policies, management, and administration of their systems posted to newsgroups and other public lists. He also knows that from this point forward everything he does may be logged, and at a minimum will assume it is.

The attacker is now ready to move on to actual reconnaissance of the target, scanning and enumeration. His objectives after the initial assessment of the target system(s) focuses on identifying listening services and open ports. Once promising avenues of entry are identified, more intrusive probing can begin as valid user accounts and poorly protected resource shares are enumerated. The techniques, tools and procedures will vary according to his level of expertise and ability to code custom scripts and programs. Regardless, there is a plethora of open source tools available for use, and he will more than likely make use of some, if not all of the following: NMAP, STROBE, NESSUS and SATAN variants SARA and SAINT if using Linux; WinScan, Sam Spade and others if using a Windows box. Do not discount the fact that commercial products such as CyberCop Scanner and Internet Security Scanner may be used also, as these are available for sale on the open market.

The attacker knows that there is really no good time to ever implement a scan, and that once the decision is made to execute the scan, that it should be done only once. He knows that he may get only one chance, and that another opportunity may not be presented as running a scanner is the equivalent of running up to an occupied building with a crowbar in broad daylight and trying all the doors and windows. He will avoid these types of scans to the maximum extent possible.

The attacker will also make use of tools available as part of the operating system originating the scan and enumeration such as the following for Unix systems:

* host -l -a |more
* nslookup -query=HINFO
* dig
* dig -x Do a reverse dig on a couple of systems found when running the host command to see if they are properly reversed mapped
* dig@ version.bind chaos txt |more (Used to find out if a vulnerable version of "bind" is being run on each of the domain name servers.)
* rpcinfo -p (Used to identify vulnerable or unnecessary RPC services like SPRAYD, STATD, BIOD and WALLD)

Vulnerability Mapping

Once the preceding has been accomplished, the attacker will study and analyze all the information that has been collected. Vulnerability mapping is conducted to match specific exploits to the target systems found during the previous stages. Public sources such as BugTraq and CERT advisories are consulted, public exploit code is reviewed, as well as the output from scanners such as CyberCop, Nesssus and SAINT. If he is not intimately familiar with the operating systems in use, additional study will be conducted prior to gathering the tools required for actually breaching the target.

As a last step to vulnerability mapping, the attacker will gather potential tools for use against the system(s) based on the analysis of the services running, operating system, and other variables. Additionally, evaluation of selected tools to determine what areas they cover is conducted to identify any gaps that may exist in the required capabilities.
Wargaming

The attacker now moves into the final stage before actually conducting the attack, "Attack Strategy Development & Wargaming". The attacker will develop multiple courses of action (COA) and wargame them, selecting the best COA based on all available information. The plan of attack will depend on what is to be accomplished; compromise of security, access, denial of service etc. The attacker will conduct rehearsals, laying out how the attack will be accomplished and working through the exploitation process at least mentally. If possible, he will establish a single machine with the identical distribution as the target and run a series of attacks against it. The intent here is to identify what the attacks are going to look like from the attacking side, and what the attacks will look like from the victim's side. He will also consider the following influencing factors:

* How stealthy does he need to be?
* Does he need root level access to attain his goals?
* Does he want to attain access to other machines? (Deploy sniffers, get passwd files etc.)
* Which exploits are most likely to succeed?
* Will he want to maintain access to the target system, or is this a one crack deal?

The attacker will seek to be totally prepared before any exploits are run. He will not want to be in the position of acquiring access, and then realize that he does not have a log wiper or a sniffer that is required to further his aims. He will also be prepared with strategic backup plans. For example, if the target system doesn't have a compiler, and he needs to compile tools on the system, he will have a compatible compiler ready to FTP to the target site; or have tools pre-compiled for the target operating system. He will adhere to the maxim "FAILING TO PREPARE IS PREPARING TO FAIL!!"
Attack Implementation

Once all is in preparedness, and at the appropriate time based on reconnaissance and analysis of all data, the attack will be initiated. The objectives are to gain access and to subsequently achieve any of the following: escalate privileges, pilfering, create backdoors, covering tracks, and if all else fails and the attacker cannot achieve his goals, possible denial of service attacks. The attacker will execute the identified exploit in an attempt to gain access. If access is gained, and no system administrators are on the system, and if only user level access was gained in the last step, an attempt is now made to gain control of the system through ROOT/ADMINISTRATOR privileges. This can be conducted using password cracking tools and exploits such as Crack 5.0a, L0PHTCrack, rdist, getadmin, sechole , and buffer overflow exploits etc. Onsite system tools will be used as well as tools imported to system.

Assuming ROOT/ADMINISTRATOR privileges have been gained, the attacker will seek to identify mechanisms to access "Trusted Systems" by evaluating trusts, and searching for cleartext passwords etc. Tools and techniques used can include searching for .rhosts files in users home directories and elsewhere, gathering user data, and examining system configuration files.

Once ownership of the target is accomplished, this fact needs to be hidden from the system administrator. For a Unix based system, the attacker will unset the history file, and execute a log wiper to clean entries from UTMP, WTMP, and Lastlog. For Windows based systems, event log and registry entries will be cleared/cleaned.

If the attacker wants to maintain access to the system after initial access is achieved, he will set about creating backdoors for future access. The methodology, tools and techniques are system dependent, but the intent is to create accounts, schedule batch/cron jobs, infect startup files, enable remote control services/software, replace legitimate applications and services with trojans. Possible tools include: netcat, VNC, keystroke loggers, adding items to the Windows startup folder or configuration files (system.ini, win.ini, autoexec.bat, config.sys etc.) For UNIX based systems, entries in the /etc/rc.d directory can be employed.

If all else fails, of if the desired intent is to implement a denial of service (DoS) attack, the intruder will use exploit code to disable target. This is system/operating system specific and can also depend upon the "patch level" of the system state. SYN flood, ICMP techniques, overlapping fragments/offset bugs, and out of bounds options can be employed. Again, the effect will depend in large part on the system state. Has the system administrator installed the current security package and updated the system files to preclude the implementation of the Ping of Death, Smurf, Fraggle, teardrop, boink, and newtear exploits? The attacker knows that once exploits become public, they can quickly become useless against systems where the system administrators are on top of things, but he also knows that new exploits are found daily and that research and experimentation is required to find the most effective tool and technique.
Post Attack Review

Whether or not the attack was successful, the attacker will conduct an extensive review of his efforts. The intent is to identify what worked and what did not and why. What methodologies were successfully employed, what tools and techniques were most effective and why? This information is paramount if the attacker has to step back through any of the preceding steps along the way to accomplish his intended objective, and for use against future targets.
Conclusion

Finally, the dedicated attack is not the work of a "script kiddie", or casual system intruder. The opponent that system and security administrators face in this instance is a professional antagonist whose skills may match or exceed their own. As Seth Ross notes in his book Unix System Security Tools: "There are no Turnkey Security Solutions. If computer security is a game, then the enemy makes the rules".

Whether working for himself or some other sponsor, we can be sure that the dedicated attacker will adhere to the following:

"There is no way to become either a master system administrator or a master cracker overnight. The hard truth is this: You may spend weeks studying source code, vulnerabilities, a particular operating system, or other information before you truly understand the nature of an attack and what can be culled from it. Those are the breaks. There is no substitute for experience, nor is there a substitute for perseverance or patience. If you lack any of these attributes, forget it!! " (Maximum Security, A Hacker's Guide to Protecting Your Internet Site and Network by Anonymous)

We would be wise to heed these words as well...

Doug Fordham is a former Department of Defense, Information Systems Security Project Manager whose responsiblities included computer network defense, security auditing, and vulnerability testing.

Source : http://securityfocus.com

Starting from Scratch: Formatting and Reinstalling after a Security Incident

2007-09-05T08:38:00.000-07:00

Missing files, corrupt data, sluggish performance, programs not working - any of these things could indicate a breach in network security. Once the breach has been identified and mitigated, the painful process of rebuilding and recovery begins. There is a point you reach in the recovery process, after you have done a little digging, put a finger on what might have gone wrong, where you come to the proverbial "fork in the road". Every security professional or systems administrator has faced the decision at some point in his or her career: is it better to try to repair the damage, or just reinstall the system and start from scratch?

This IT dilemma will plague us all at some point. In this article, we will examine the process of starting over, and more specifically, reinstalling as the result of a security incident. We will focus on the steps necessary to prevent a repeat intrusion, get your system back online and ensure a rapid response in the future should this happen again. Needless to say, these steps should be planned in advance of any security incident and should be included in the organization's incident response policy.

Why me?

Before we get into the specifics, let's consider how we have reached this unfortunate point. Obviously, there has been a security incident. An intruder has likely breached and manipulated your machine in some manner. So why not fix the problem? Patch the system, clean up the changes and put it back out there. For any particular exploit, even if a well-documented clean-up procedure is in place, it's hard to ensure that modifications outside of the known scope weren't made. Worms, viruses and rootkits can wreak havoc on any system. They often remove crucial files, embed themselves in other parts of the system and sometimes remain silent. And they can be modified to do other nasty things ? making the documented clean-up routines, released after a major incident, obsolete.

The reality, as any incident response expert can attest to, is that discovering all of the changes made to a cracked system is extremely difficult. Once inside a system, an attacker can implement several backdoors, modify standard system operations (such as logging) and hide files. Unless there is a file integrity checker such as Tripwire in place, it's virtually impossible to guarantee a clean system. And there's no worse feeling then spending hours rebuilding a system, only to have it cracked shortly after putting it back up.

Repairing a compromised system is, without a doubt, one of the most challenging aspects of a security professional's job. While it might seem like the easy way out, wiping a system and installing clean versions of the original software is often the smart choice.

Preparation

Before beginning the rebuilding task, there are a few steps to take that will ease the process. First, consider your response to the cracked system. Obviously, the immediate concern is getting the system back to normal. But in the near future, you might need to investigate the box further, learn how the cracker got in, or perhaps turn the evidence over to law enforcement. With that in mind, consider using a ghosting (disk image copier) or disk duplicating program to dump the contents of the system to another hard drive or storage medium. With the duplicate image set aside, you can immediately get to work on restoring the machine without tainting evidence, and focus on the incident analysis later. A raw system image is a requirement for any type of official incident analysis, so this important step is recommended. If you modify or examine the victimized machine in any way, the data will likely be considered invalid by authorities due to the numerous aspects of the system which can be compromised. Much like a physical crime scene, this digital evidence needs to be documented, preserved and protected from contamination. Disk imaging software, such as Ghost, provide incident handlers and forensics experts with the clean slate they need to begin an investigation. (For more information on dealing with law enforcement agencies in forensic investigations, please see the SecurityFocus article Incident Management with Law Enforcement by Ron Mendel.)

Next, you need to audit the system. Take note of the servers and services running, important configuration files, patches, the third party applications in place, the users, the directory structures, and so on. Additionally, consider saving especially critical files, but be warned that they could have been manipulated or corrupted at some point. Obviously, you'll want to avoid capturing the malicious changes to the system, but you should be able to cull the basics with a general review.

Lastly, have all of the original installation disks, registration codes and support numbers at hand. It's best to have these in place before the process begins, so you aren't frantically digging around for a disk or number in the middle of the setup. In addition to this software repository, keep a journal of each step you take. This record will help track the rebuilding process. Additionally, it might prove to be a handy reference should you need to rebuild the system in the future.

Formatting the Drive

The big step in rebuilding a system, the point of no return, is wiping or formatting the system drives. This will destroy all of the data on the disk and make it possible to reinstall clean, system software.

You might wonder if it's possible to repair or upgrade a system, a choice available for many operating systems. If you repair a system, a process which normally requires an emergency or repair disk, the OS cleanses itself by replacing or reinstalling critical system files or missing applications. The problem with this lies in the fact that while the repair option might catch some modified or missing files, it likely will not recognize what was added to the system. Therefore any backdoors, extra applications or otherwise malicious code will remain in place, undetected. So a complete reinstall including a disk format is the safer choice when dealing with a compromised machine.

Formatting the drive is, today, a relatively simple process. Most modern operating systems simply require you to insert the installation boot disk. Shortly into the process, you are presented with a list of drives and installed OS's. You'll likely want to select all of the drives for formatting. The partitioning (disk spacing) can be handled automatically, but if you have specific requirements, mimic the previous configuration. In the past, formatting a drive was somewhat more tedious and a mysterious process left up to the user. It required a bootable system disk and a program such as 'fdisk'. If you must use this method, boot from the necessary disk and use the utility to wipe the drive clean.

Another option, if you want more control or assistance with this process, is a third party utility such as 'Partition Magic'. Such software makes it easy to resize existing partitions and format drives in a number of different formats. Consider similar utilities if you encounter problems with the OS formatting process described above.

Rebuilding the Systems

With an empty system in front of you, the next step is to reinstall the OS software. This straightforward process will vary depending on your software. Follow the installation guidelines provided to build the bare-bones system. After the OS, move onto installing specific applications, such as servers, utilities and other programs you require. Again, the process is different for each application, but there shouldn't be any unexpected challenges. If possible, and ONLY if you know they were untouched, reinstall the critical configuration and system files copied from the compromised machine. Or, at the very least, review them while configuring the current setup.

By this point, you should have a decent replication of the original system, but keep in mind - it is still offline. Before reconnecting to the network, security needs to be tightened, or we will end up back where we started. Begin by removing any unnecessary open ports or network services. Use a portscanner such as Nmap to determine what servers are listening. Turn off everything but the absolute essentials. Next, review the running applications. Again, if something seems unnecessary, remove it. We want this system to be spartan in terms of processes - each one is a potential vulnerability. Bring the OS and application level patches up to date. These patches, often security related, are available from the vendor sites. It's a good idea to group the patches onto a disk before beginning the rebuild. Therefore, you won't have to put the system online while it's still insecure. Additionally, take note of every patch applied, for future reference.

A vulnerability scanner, such as Nessus, is a good utility to employ during this process. These tools check the system against a known database of vulnerabilities and generate a report of potential threats. Make sure all aspects of the report are addressed before bringing the system up.

Lastly, consider installing an integrity checker (such as Tripwire), which can help in both the short and long terms. Immediately, you'll be concerned with a repeat incident. If you missed the original vulnerability in the rebuilding process and the system is compromised again, an integrity checker will alert you of changes. Long term, the benefits are similar. If the machine is hit again, a quick list of changes will be available. An intrusion detection system, such as Snort, can also help you monitor the network for the attacker's return. Monitoring is a crucial component once a system is back online and both of these utilities can help immensely.

An important point, which deserves repeating, is that the system should, if possible, remain unconnected to any network during the OS reinstallation and patching process. This means that you need to compile all of the necessary software: the OS, specific application and patches, before hand. Rebuilding a machine without network connectivity can be done on some operating systems, but is somewhat difficult on others. If circumstances demand network connectivity, proceed with caution. Make sure ALL listening services are shutdown prior to connection. Additionally, the machine should be placed behind a firewall which blocks inbound traffic requests. Lastly, it should be the only machine on the particular network segment, to prevent an internal virus or worm from reaching the machine. An unpatched machine is extremely vulnerable to multiple threats, so make sure the proper defense techniques are in place before putting the machine on a network for updates.

Going Back Online

Before bringing the system up, you need to create a system backup. Since you just rebuilt the machine from scratch, it's fair to say that a backup was not in place prior to the compromise. Backups are a fundamental aspect of system administration and security. At some point, they will be needed. In addition to the full backup, you need to create a regular schedule for incremental backups. This will help ensure that frequently modified files are saved to a secure medium.

Finally, we can bring the system back online. The fresh build, newly applied patches and security review should prevent an attacker from returning. If the machine is compromised again, it's safe to say you missed the original vulnerability or have fallen prey to an insider attack.

For a while, monitor the system with increased frequency. Review logs, security mechanisms such as filecheckers and intrusion detection systems, and general system activity on a regular and frequent basis. You need to ensure that the machine is no longer vulnerable. Unfortunately, this is invariably a wait-and-see process.

Conclusion

Rebuilding a system is never a pleasant task. It is, however, often the proper choice, when dealing with compromised machines. Sometimes, it's the fastest route to restoring the status quo. The process demonstrates how important regular backups and strict security procedures are for networks. When you do need to start over, the basic steps outlined in this article can ensure a rapid return to action and prevention of further incidents.

Matt Tanase is President of Qaddisin. He and his company provide nationwide security consulting services. Additionally, he maintains The Security Blog and the Wifi Security Project, Web logs dedicated to network security.

Source : http://securityfocus.com

A Method for Forensic Previews

2007-09-02T05:15:00.000-07:00

1. A Classic scene from the information security professional's work life

One of your systems administrators pokes his head in your office door. "The print spooler machine may have been compromised. Can you help me take a look? Some odd files have appeared -- that's all we know right now." Your pulse steps up a few beats: you told Operations on more than one occasion that they should address the availability issues faced by critical servers. The print spooler was one of those servers. If it is hacked, it will have to be taken out of production, and there will be serious consequences due to the service interruption. At least you have documented your interactions with Operations: email is forever, you tell yourself. With that thought, you ponder your options to get the organization through this as painlessly and quickly as you can. There is no backup machine, and obtaining a bit-for-bit copy of the spooler's file space is not practical without taking the machine off line. Since there is no solid evidence that the spooler is hacked, it makes sense to do some reconnoitering before taking the machine out of production for extensive forensics. The things you would like to look at include process and network activity, the status of significant binaries, user and group accounts present, the permissions these accounts have, and so on. But how to proceed with this forensic "preview" of the spooler? You do not wish to damage original evidence, and if the spooler is not hacked there is nothing to worry about. On the other hand, what if it is hacked?
2. The preview process

During any computer forensics operation, the state of the target machine must be left as undisturbed as possible. This underlying principle applies to all forensics activities, ranging from the field preview to the full blown examination in a lab. Nevertheless, there remains an important distinction between a preview operation and lab work: by its nature, the preview is very likely to contaminate original evidence. Examinations in an evidence preservation lab use backup copies of evidence, thereby preserving the initial state of crime scene equipment. Why, then, would an investigator undertake a preview operation? There is often no choice, as the opening scenario demonstrates. But perhaps previews are not that far out of line. After all, risking damage to the original evidence is something an investigator faces during the initial steps of most forensics work. Some level of interaction with the crime scene computer is normally required to obtain a backup for later processing. This issue may even be exacerbated when the crime scene computer is something other than a workstation (such as a mainframe), in which case, significant interaction may be required to backup any evidence.

Where computer forensics is concerned, the idea of less is more carries great weight. The less an investigator has to do to interact with and extract information from evidence (or what may become evidence), the better. In the case of the preview, the goal is to determine whether or not a given target machine has been compromised by some unauthorized agent. This determination has to be made without seizing the target machine and forensically processing a backup of its file space.

Following the preview, appropriate next steps may be taken if there has been some sort of compromise. For example, if a machine is simply infected with a virus, perhaps running a virus scan will be sufficient; if a machine has been turned into a "warez" site, perhaps removing it from production and putting it through a full forensics examination is in order. [ref 1] Clearly, the outcome will depend on the sensitivity of the data assets involved, the standing policies of the organization, and the professional assessment of the investigator.
3. The Four Step Plan

We have established what a preview is, and why an investigator might undertake such work. Now, we turn our attention to the broad steps that comprise the forensic preview activity:

1. Related research
2. Passive network operations
3. Active network operations
4. Active host operations

As we precede through these steps the investigator's activities become progressively more interactive with the target machine and, hopefully, more revealing of the machine's disposition. Unfortunately, as the preview becomes more interactive, it also becomes more dangerous to the state of evidence. Therefore, it is important that the investigator stops the moment a compromise is evident; continuing on would needlessly risk damaging original evidence. With this approach, it may be possible to determine that a given host has been compromised without, for example, having to directly interact with the operating system looking for a root kit.

Before outlining these steps further, a couple of important guidelines deserve attention:

* Always consider the possible legal ramifications of investigatory activities; consult with your organization's legal counsel in advance of such activities. For example, some of the steps outlined below may constitute a violation of privacy, given the right circumstances

* Document all investigative activities taken. The whole reason to do a forensic preview is to determine, without disruption to production services, whether or not a target machine has been compromised. If it has, the investigator may need to account for the interactions that have taken place as a result of the preview. A compromise does not necessarily translate into a full blown investigation: whether or not a target machine suddenly becomes a crime scene computer is contingent on the type of compromise, organizational policy, and the investigator's judgment. Regardless, all previews are the same in that the target machine could become a crime scene computer. If this happens, the investigator's preview documentation will become the start of a chain of custody [ref 2]

3.1 Step 1: Related Research

In the first step, the investigator uses the process of information discovery to research activities related to the target machine. This is not unlike the process of information discovery described in the Field Guide series of forensic articles on SecurityFocus. [ref 1] Of interest are log data and network flow information made accessible at the enterprise level, including:

* File space monitoring (e.g., logs of unexpected changes to files)
* Intrusion detection system (IDS) activity - network and/or physical
* Firewall activity
* Network flows
* Relevant service/application activity
* Interviews with relevant parties (e.g., system administrators, application administrators and users)

The idea is to find evidence of a compromise without interacting with the target machine on any level. Of course, success will depend on the monitoring in place (and that the logs in question are not stored on the target machine), as well as the quality/quantity of information provided by relevant parties.

If evidence of a compromise is found, the investigator should stop the preview and consider handling the target machine as a crime scene computer. Otherwise, the preview should continue to Step 2.
3.2 Step 2: Passive Network Operations

In this step the investigator uses downstream/inline utilities to observe the target machine's ingress and egress traffic. There are a variety of ways to do this, including network taps, network IDS rules, and span ports on switches. Outside of the use of a span port, sniffing on a switch is not necessarily recommended since it may involve poisoning the ARP cache of the target host (changing the host's state, and perhaps interrupting its services). If the target is on a hub, or is wireless, sniffing becomes a safer choice to implement.

The duration used to monitor traffic depends on the investigator's comfort level with the situation. If the target machine is fulfilling a critical function, or stores highly sensitive data, it may be unreasonable to spend a lot of time in this step.

As in Step 1, if evidence of a compromise is found, the target machine may need to be viewed as a crime scene computer. If nothing of interest turns up, the preview should head to Step 3.
3.3 Step 3: Active Network Operations

By Step 3, the safer, non-interactive means of checking the target machine for compromise have been tried. From here on, the target machine's state will be altered by the activities of the preview. The investigator must minimize these activities to prevent significant harm to potential evidence.

In this step, the two primary tools of interest are port and vulnerability scans.

Port scans will not drastically change the state of a target machine. Nevertheless, the investigator should be aware that a listening service may write out log entries or start and stop processes upon connection establishment. If the target machine is running a network IDS, a port scan may cause a change in network disposition: the scanner could become blocked. The investigator should work with the system administrator to determine what services might interact with a port scan. If there is an IDS or firewall on the target machine, it may be possible to configure the scanner with a trusted address.

Unlike the port scan, vulnerability scans can cause significant changes in the state of a target machine. The degree of change depends on how the scanner is configured, with more robust configurations leading to ham-fisted probes and attacks. The system administrator may be able to help fine tune a vulnerability scan, so as to not unnecessarily disturb a host's state. For example, if the target machine has been patched against vulnerability X, it does not make sense to check for X. One reasonable approach is to tune the vulnerability scanner to check for services commonly deployed by script kiddies and malware. Precise and simplistic scans are best: less time will be needed and fewer changes to the target machine's state will result.

Once again, if evidence of a compromise is discovered, the investigator should decide whether or not the target machine becomes a crime scene computer. If no compelling evidence turns up, the preview should advance to Step 4.
3.4 Step 4: Active Host Operations

Here, we directly interact with the target machine's operating system by way of a user account. The careful notes the investigator has been taking all along will carry even more weight in this step, since the activities herein are all but guaranteed to change the target machine's state. Items of interest include basic facts about the target machine's OS, process information, log file data, account information, and the status of file space.

To begin with, the investigator may wish to change the administrative password on the target machine. So long as this is documented, there's little reason that it would jeopardize any evidentiary value. If there is a compromise, it may be negligent to not take steps that help block an attacker's administrative access -- the investigator should consult with legal counsel in advance of preview activities.

In this step, we are concerned with the following information targets:

1. Basic system information
2. Running processes
3. Timed jobs
4. Log files
5. User and group accounts
6. File space status

Utilities that aid in gathering the above should come from a known, secure source. It is recommended that such programs be run off of read-only media (e.g., CD-R) to manage the risk of using compromised programs on the target machine. However, there is a catch: many utilities are not self-contained and may rely upon the use of libraries and other resources on the target machine. It is impractical to fully avoid this situation; after all, by its very nature the forensic preview interacts with what could become original evidence.

Along these lines, as files are accessed on the target machine, the times and dates of these accesses will overwrite values in the relevant file metadata. This could make it difficult to show or know that an attacker has made similar accesses, and highlights the tradeoff of forensic previews: in exchange for not taking a target machine out of service, there may be some contamination to possible evidence.

Thought must also be given to data capture during the preview. The investigator might use a network agent to transmit and remotely store all information (e.g., cryptcat, SBD). Any such agent should use strong encryption to ensure the integrity and confidentiality of transmitted information. As an alternative, data could be stored locally to a diskette or USB drive. The volume of data collected should be quite small, consisting of the text output of various utilities, along with copies and excerpts of logs.

To proceed through Step 4, a script or program could be used to collect most, if not all, of the information desired. [ref 3]

Item 1: Basic System Information

Here, we need to collect the basic facts about the target machine. While it is unlikely that this will yield evidence of compromise, the information establishes a context and helps to inform the preview.

What to capture:

* Hardware configuration (though, nothing requiring an interruption of service, like rebooting to get into BIOS, and so on)
* Operating System used, including version and patch level
* Network configuration (IP and MAC addresses assigned to all NICS, ARP cache)
* Major applications installed (though, not necessarily running), and, if possible, their patch levels
* Purpose of the target machine

Item 2: Running Processes

Under this item, processes listening for network connections are of primary interest. Open ports should be compared with what the system administrator believes should be open. Noting the services commonly associated with these ports can also be useful: if the target machine is suddenly offering an IRC service there could be reason for concern. Of equal importance are unusual outbound destinations or traffic types (for example, perhaps the target machine is not hosting IRC, but there is traffic seen going to an IRC server).

Processes that are not listening to a network port can be of interest, too (e.g., a sniffer process monitoring all of the network traffic on the target machine).

What to capture:

* A list of all running applications (with as much detail as possible: name, owner, resources consumed, duration of execution, process ID, libraries and files used, etc.), broken down by
o Applications listening for network connections
o Applications not listening for network connections
* A list from the system administrator of the applications that should be running

Item 3: Timed Jobs

A timed job is one that is scheduled to execute at some point in the future, perhaps iteratively. It may be that the scripting used in a timed job has been altered for malicious purposes. Thus, the investigator should be careful to not only find out what jobs exist, but to inspect their related programming.

What to capture:

* A list of all timed jobs, broken down by
o Jobs to be run at the system level
o Jobs to be run at the account level
* Results of reviewing (in whatever capacity is useful) scripting used in timed jobs

Item 4: Log Files

For this item, the investigator should gather system/application alerts and log entries. It is possible for preview activities to end up in the log files under review - notes maintained by the investigator will explain such entries.

The investigator should not overlook host-based firewall and network IDS logs. There may also be tremendous value in reviewing logs that are generated by proprietary applications.

What to capture:

* Important system level messages (such as errors, house keeping, application related messages)
* Account access events (authentication and authorization) at both the system and application levels -- to the extent possible, note the fundamental details
o Who (i.e., account in question)
o What (i.e., type of event)
o When
o Where (i.e., from where did the access originate)
o Why (i.e., what was the perceived purpose of the access)
o How (i.e., through what type of channel did the access happen)
* Important application level messages (e.g., web servers, host firewalls, host intrusion detection systems, etc.)

Item 5: User and Group Accounts

Here, we want to see if there are any unauthorized accounts on the target machine, and whether or not any accounts have been assigned unjustified access permissions.

What to capture:

* A list of all individual and group accounts
* A list of all currently active accounts (for example, who is on the system right now? What are they up to?)
* A list of critical file resources (such as data files, applications, etc.) on the target machine, along with their assigned permissions

Item 6: File Space Status

Last, the investigator should enumerate file permissions (note the overlap with User and Group Accounts above), look for unauthorized file activities, and check for unusually named and hidden files. Doing more than this is not practical from a time perspective, and could cause an undue processing burden. If the target machine should become a crime scene computer, there will certainly be occasion to make a file space backup, search for strings of interest, examine slack and unused blocks, and build a timeline of activities.

What to capture:

* A list of important and critical file resources on the target machine, along with their assigned permissions
* Any local, file space monitoring logs (if they exist)
* A list of unusually named, and hidden files

Overall, this step is clearly more involved than the previous ones due to its fully interactive nature. This makes it an ideal candidate for some level of automation through programming and/or scripting. As with the previous three steps, if evidence of a compromise is uncovered, the investigator will need to determine whether or not the target machine is a crime scene computer. If no such evidence is uncovered, the best the investigator can do is claim a low probability that the target machine has been compromised.
4. Departing Thoughts

There may be concern about the time needed to apply this forensic preview method. Going back to the opening scenario, what if it had to be immediately known whether or not the spooler was compromised? This may be a pointless question for the following reasons:

* Of course it has to be immediately known! Is it really ever okay to put something like this off?
* Because the forensic preview activities do not interrupt a target machine's production service, the investigator should be allowed to come to a conclusion as soon as possible -- not within some arbitrarily short time period. That said, this preview method is designed so that analysis happens as the four steps unfold. Doing otherwise may needlessly contaminate potential evidence
* The first three steps have the potential to be evaluated very quickly. Their speed depends on how mature an organization's monitoring processes are, and how readily available and knowledgeable the system administrator is
* The last step can be streamlined if the investigator spends time assembling the necessary tools and a plan of attack

Perhaps a more important issue is what to do if a preview fails to reveal a compromise. A secure target machine is not indicated by a failure to uncover evidence of compromise. At best, an investigator can only claim a low probability that the target machine is compromised. The next steps depend on three things:

1. The organization's policies with respect to incident handling
2. What has lead the system administrator to suspect a compromise
3. The investigator's judgment given the sensitivity and criticality of the data present on the target machine

Based on the above, the target machine might be removed from production for a more thorough examination. On the other hand, given that nothing was found in the forensic preview, the cost of service loss may outweigh the risk of leaving the machine in production. The decision (and risk) rests with an organization's management.

Perhaps the most compelling reason to use a forensic preview method is that it helps to maintain the evidentiary value of a target machine. By using a repeatable, documented method, and by carefully noting all actions taken, the investigator can rationally account for the state of gathered evidence. This is essential if a chain of custody needs to be established as more rigorous forensics operations take place.

Remember that the forensic preview is not a panacea! The bottom line is that some activities in the preview process can significantly disturb potential evidence. To manage this risk it is critical that organizations formally document and implement a preview procedure for investigators to use. Doing so will establish a sound method that can be applied in most any circumstance, assigning credibility to the actions taken by the investigator, and to the evidence gathered.

References

[ref 1] For a complete description of the search and seizure process as it relates to computer crime, please see my earlier series of articles titled "The Field Guide for Investigating Computer Crime" at http://www.securityfocus.com/infocus/1244.

[ref 2] The chain of custody, or chain of evidence is a means of accounting for who has touched a given piece of evidence, when they touched it, and what they did to the evidence.

[ref 3] A forensics toolkit suitable for previews can be found on the web at http://www.e-fense.com/helix/. While still a little rough around the edges, Helix offers tools for preview work on several computing platforms.

Related links

http://www.sans.org/score/checklists/ID_Windows.pdf

http://www.sans.org/score/checklists/ID_Linux.pdf

http://www.sysinternals.com

http://www.cisecurity.org

http://www.cert.org

http://www.cybercrime.gov/s&smanual2002.htm#_IIIA_

http://www.sleuthkit.org/index.php

http://www.securityfocus.com/infocus/1244

http://www.cycom.se/dl/sbd

http://farm9.org/Cryptcat/

http://www.e-fense.com/helix/

About the author

For the past several years, Timothy Wright has been investigating computer fraud and abuse in the private sector and, more recently, higher education. He has worked as a Senior Technology Investigator at one of America's largest financial corporations, and as a lead developer within the financial industry, designing and building web-based home banking software. He presently works as an IT Auditor for a university in the midwest United States, and holds an M.S. in Computer Science, and a B.A. in Philosophy.

Source : http://securityfocus.com

Active Directory Design Considerations for Small Networks

2007-09-02T04:07:00.000-07:00

A lot of people who are new to networking or who work primarily on larger networks seem to underestimate the design considerations for small networks. It kind of makes sense when you think about it though. From an Active Directory standpoint, what’s really to consider? After all, most small networks have a single forest and a single domain. Even so, your network will run a lot more smoothly if you take the time to do a little planning first. In this article, I will discuss some of the issues involved in planning a small Active Directory deployment.
The Definition of a Small Network

The word small means different things to different people. For example, I consider my own network to be small. I’m running a one man show with about 20 computers. On the other hand a fortune 500 company might consider a subsidiary with a thousand users to have a small network. For the purpose of this article, I will define a small network as a network with under a hundred users.
Domain Planning

One of the first things that you will need to plan for your small network is the domain structure. At first, this probably sounds like overkill. After all, most small networks are single forest, single domain. The argument could be made that you need to plan for future growth, but a single Windows Server 2003 domain controller can accommodate millions of objects in the directory. Even if you were using an ancient Windows NT 4.0 domain controller, the limit is still somewhere around 40,000 users. So why is it so important to plan a domain structure for such a small network?

It has to do with administrative control. More than likely, if your network has less than a hundred users, you are probably going to be the network’s only administrator. Geography has a way of changing that though. For example, imagine that those hundred employees are scattered among three different offices in three different parts of the country. Are you still going to try to manage the network for all three offices yourself, or would you prefer to have some help?

Let’s say for the sake of argument that you decide that you do want some help running the networks in the remote offices because they are so far away. The questions now are how much help do you want and how much trust do you have in the remote administrators?

These questions are important because you have a couple of options. If you just want the remote administrators to be able to reset passwords, unlock user accounts, and things like that, then you are probably best off creating an organizational unit for each remote office and then placing the user accounts from each office into the appropriate organizational unit. If on the other hand you want to completely hand over control of the remote offices to the remote administrator (you keep control of the forest) then you are probably better off creating a separate domain for each office.
Resource Planning

For the sake of argument, let’s assume that you decided to go with a single domain for your network. Regardless of whether there are any remote administrators in the picture or not, you are going to have to make some important design decisions regarding your remote offices. These decisions have to do with what types of servers (if any) you want to place in the remote facilities.

These types of decisions are always a big deal, but they are even more important in small companies because you have to balance the cost of the servers (and their impact on your budget) with the benefit that they will provide.

Let’s pretend that your company has a really tight IT budget (hmm… maybe we aren’t pretending on that part) and that you decide not to put any servers at all in the remote offices. Your network can function like this, but you are completely at the mercy of the speed and reliability of the WAN link between the remote office and the main office. If the WAN link were to go down, then nobody in the remote office will even be able to log in.

Of course WAN links go down all the time, and having a whole office full of people who can’t log in until the problem is fixed probably isn’t good for business. So let’s say that we are going to put a domain controller in each remote office so that people can log in whether the WAN link is available or not. Does this really solve the problem though? Not really. If anything, it creates some other problems.

First of all, having a locally available domain controller does not guarantee that users will be able to log in (unless we are talking about Windows NT). In an Active Directory environment, users must be able to contact a global catalog server in order to log in. The only user who can log in without access to a global catalog server is the domain Administrator. This problem is easy to fix though. You can just designate each office’s domain controller to be a global catalog server. This will allow users to log onto the network when the WAN link is down; assuming that the users can communicate with the domain controller.

Even if a domain controller is available locally, and the domain controller is designated to be a global catalog server, users won’t be able to log in if they can’t communicate with the domain controller. There are a couple of things that can cause this to happen. One reason why users might not be able to communicate with the domain controller is because they don’t have an IP address assigned to their computer. Think about that one for a minute. If the only available DHCP server is in another building and the WAN link goes down then nobody in the remote office will be able to lease an IP address. Therefore, it’s probably a good idea to have a DHCP server in the remote office.

Another reason why a domain controller might be inaccessible is because the Active Directory is completely dependant on the DNS. If the DNS server is in the main office and the WAN link goes down then clients in the remote office may not be able to resolve the name of the local domain controller.

So let’s say that you decide to spend some bucks and put a DNS server, a DHCP server, and a domain controller in the remote offices. There are still a couple of issues that you may have to deal with. One issue is excessive replication traffic. Every time the Active Directory is updated in any one of the offices (such as adding a user account or changing a password) the update is propagated across the WAN link to the other domain controllers in the other offices. If the Active Directory is updated frequently, this replication traffic can really put a strain on your bandwidth.

The solution here is to create a separate Active Directory site for each office. Active Directory replication traffic will still need to be sent to the domain controllers in the remote offices, but it can be scheduled and sent in batches rather than constantly flooding the WAN link with replication traffic.

The other problem that you might run into is availability of data. Assuming that the remote offices have a domain controller, a global catalog server, a DHCP server, and a DNS server, then users in that office will be able to log in even if the WAN link goes down. However, being able to log in doesn’t mean much if the users can’t access their data.

There are a couple of ways around this problem. The appropriate course of action would depend on whether or not data is shared among the various offices. If there is no need to share data between offices, then the best course of action is probably to put a file server in each office and have the users save their data directly to that server. If data does need to be shared among offices, then you are probably best off setting up a DFS server in each office. That way, each office contains a server with a full replica of the company’s data. If a WAN link goes down, users can still access the entire data set. When the WAN link comes back up then any changes that have been made to the data are synchronized with the other DFS servers in the other offices.
Conclusion

In this article, I have mentioned a lot of things that need to be present in the remote offices so that users can continue to work even if a WAN link goes down. If budget is a concern, you can probably get by with lumping all of these roles into a single server. It’s usually considered to be a best practice not to use a domain controller as a file server (for security and performance reasons). You have to do what’s appropriate for your individual company. In a situation like the one that I described above, I would recommend placing two servers in each remote office. One server would act as a domain controller, global catalog, DHCP, and DNS server. The other would act as a file server (possibly a DFS server).

About Brien M. Posey

Brien Posey is an award winning author who has written over 3,000 articles and written or contributed to 27 books. You can visit Brien’s personal Web site at www.brienposey.com

Source : /www.windowsnetworking.com

Linux Firewall-related /proc Entries

2007-08-31T07:57:00.001-07:00

By: Brian Hatch 2003-07-14

Most people, when creating a Linux firewall, concentrate soley on manipulating kernel network filters: the rulesets you create using userspace tools such as iptables (2.4 kernels,) ipchains (2.2 kernels,) or even ipfwadm (2.0 kernels).

However there are kernel variables -- independent of any kernel filtering rules -- that affect how the kernel handles network packets. This article will discuss these variables and the effect they have on the network security of your Linux host or firewall.
What is Linux's /proc directory?
There are many settings inside the Linux kernel that can vary from machine to machine. Traditionally, these were set at compile time, or sometimes were modifiable through oft-esoteric system calls. For example each machine has a host name which would be set at boot time using the sethostname(2) system call, while iptables reads and modifies your Netfilter rules using getsockopt(2) and setsockopt(2), respectively.

Modern Linux kernels have many settings that can be changed. Providing or overloading a plethora of system calls becomes unwieldy, and forcing administrators to write C code to change them at run time is a pain. Instead, the /proc filesystem was created.[1] /proc is a virtual filesystem -- it does not reside on any physical or remotely mounted disk -- that provides a view of the system configuration and runtime state.

The /proc filesystem can be navigated just like any filesystem. Entries all appear to be standard files, directories, and symlinks, but are actually views into the kernel information itself. Some of these can be modified by root, but most are read only. To view these files, cat and more are your friends:

# cd /proc
# ls -l version
-r--r--r-- 1 root root 0 Jun 20 18:30 /proc/version
# cat version
Linux version 2.4.21 (guru@example.com) (gcc version 2.95.4 20011002) ...

Note that the kernel fudges a bit the ls output - these files will appear to have content when viewed, but will always have a length of 0 bytes. Rather than waste time figuring out how much output would be produced if the file were viewed, the kernel just reports 0 for most statistics, and gives the current time for all timestamps.

/proc/sys

All the /proc entries that can be modified live inside the /proc/sys directory. You can modify these in two different ways, using standard unix commands and via sysctl. The following examples show how you can set the hostname using both methods:

Changing /proc pseudo-files manually

# ls -l /proc/sys/kernel/hostname
-r--r--r-- 1 root root 0 Jun 20 18:30 /proc/sys/kernel/hostname

# hostname
catinthehat

# cat /proc/sys/kernel/hostname
catinthehat

# echo 'redfishbluefish' > /proc/sys/kernel/hostname

# hostname
redfishbluefish

Changing /proc pseudo-files via sysctl

# hostname
redfishbluefish

# sysctl kernel.hostname
kernel.hostname = redfishbluefish

# sysctl -w kernel.hostname=hop-on-pop
kernel.hostname = hop-on-pop

# hostname
hop-on-pop

Note that the main difference between these two methods is that sysctl uses dots[2] as a separator instead of slashes, and the initial proc.sys is assumed. sysctl can be run with a file as an argument, in which case all variable modifications in that file are performed:

# hostname
hop-on-pop

# cat reset_hostname
kernel.hostname=butterbattlebook

# sysctl -p reset_hostname
; Set our hostname
kernel.hostname=butterbattlebook
;
; Turn on syncookies
net.ipv4.tcp_syncookies = 1

# hostname
butterbattlebook

If -p is used and no filename is provided, the file /etc/sysctl.conf will be read.

The changes you make to /proc variables affect only the currently running kernel - they will revert back to the compile-time defaults at the next reboot. If you wish your changes to be permanent, you can either create a startup script that sets variables to your liking, or you can create a /etc/sysctl.conf file. Most Linux distributions will run sysctl -p at some point during the normal bootup process.

Firewall-related /proc entries
While there are many different kernel variables you can tweak, this article will only discuss those specifically related to protecting your Linux machine from network attacks. Also, we'll restrict ourselves to the IPv4 version, rather than IPv6, since the latter inherits variables settings from the former where appropriate anyway.

If you're interested in learning about other kernel variables, read the proc(5) man page. There are also several files in the kernel source inside the Documentation directory that may provide more information, /usr/src/linux/Documentation/filesystems/proc.txt and /usr/src/linux/Documentation/networking/ip-sysctl.txt are good starting points.

Some kernel variables are integers, such as kernel.random.entropy_avail which contains the bytes of entropy available to the random number generator. Others are arbitrary strings, such as fs.inode-state which contains the number of allocated and free kernel inodes separated by spaces. However most of the firewall-related variables are simple binary values where of '1' means 'on' and '0' means off.

A Linux machine can have more than one interface, and you can set some variables on different interfaces independently. These are in the /proc/sys/net/ipv4/conf directory, which contains all the current interfaces available, such as lo, eth0, eth1, or wav0, and two other directories, all and default.

When you change variables in the /proc/sys/net/ipv4/conf/all directory, the variable for all interfaces and default will be changed as well. When you change variables in /proc/sys/net/ipv4/conf/default, all future interfaces will have the value you specify. This should only affect machines that can add interfaces at run time, such as laptops with PCMCIA cards, or machines that create new interfaces via VPNs or PPP, for example.

Proc files
Below are /proc settings that you can tweak to secure your network configuration. I've prepended each filename with either enable (1) or disable (0) to show you my suggested settings where applicable. You can actually use the following handy shell functions to set these in a startup script if you prefer:

enable () { for file in $@; do echo 1 > $file; done }
disable () { for file in $@; do echo 0 > $file; done }

enable /proc/sys/net/ipv4/icmp_echo_ignore_all
When enabled, ignore all ICMP ECHO REQUEST (ping) packets. Does nothing to actually increase security, but can hide you from ping sweeps, which may prevent you from being port scanned. Nmap, for example, will not scan unpingable hosts unless -P0 is specified. This will prevent normal network connectivity tests, however.

enable /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
When enabled, ignore broadcast and multicast pings. It's a good idea to ignore these to prevent you from becoming an inadvertent participant in a distributed denial of service attack, such as Smurf.

disable /proc/sys/net/ipv4/conf/*/accept_source_route
When source routed packets are allowed, an attacker can forge the source IP address of connections by explicitly saying how a packet should be routed across the Internet. This could enable them to abuse trust relationships or get around TCP Wrapper-style access lists. There's no need for source routing on today's Internet.

enable /proc/sys/net/ipv4/conf/*/rp_filter
When enabled, if a packet comes in on one interface, but our response would go out a different interface, drop the packet. Unnecessary on hosts with only one interface, but remember, PPP and VPN connections usually have their own interface, so it's a good idea to enable it anyway. Can be a problem for routers on a network that has dynamically changing routes. However on firewall/routers that are the single connection between networks, this automatically provides spoofing protection without network ACLs.

disable /proc/sys/net/ipv4/conf/*/accept_redirects
When you send a packet destined to a remote machine you usually send it to a default router. If this machine sends an ICMP redirect, it lets you know that there is a different router to which you should address the packet for a better route, and your machine will send the packet there instead. A cracker can use ICMP redirects to trick you into sending your packets through a machine it controls to perform man-in-the-middle attacks. This should certainly never be enabled on a well configured router.

disable /proc/sys/net/ipv4/conf/*/secure_redirects
Honor ICMP redirects only when they come from a router that is currently set up as a default gateway. Should only be enabled if you have multiple routers on your network. If your network is fairly static and stable, it's better to leave this disabled.

disable /proc/sys/net/ipv4/conf/*/send_redirects
If you're a router and there are alternate routes of which you should inform your clients (you have multiple routers on your networks), you'll want to enable this. If you have a stable network where hosts already have the correct routes set up, this should not be necessary, and it's never needed for non-routing hosts.

disable /proc/sys/net/ipv4/ip_forward
If you're a router this needs to be enabled. This applies to VPN interfaces as well. If you do need to forward packets from one interface to another, make sure you have appropriate kernel ACLs set to allow only the traffic you want to forward.

(integer) /proc/sys/net/ipv4/ipfrag_high_thresh
The kernel needs to allocate memory to be able to reassemble fragmented packets. Once this limit is reached, the kernel will start discarding fragmented packets. Setting this too low or high can leave you vulnerable to a denial of service attack. While under an attack of many fragmented packets, a value too low will cause legitimate fragmented packets to be dropped, a value too high can cause excessive memory and CPU use to defragment attack packets.

(integer) /proc/sys/net/ipv4/ipfrag_low_thresh
Similar to ip_frag_high_thresh, the minimum amount of memory you want to allow for fragment reassembly.

(integer) /proc/sys/net/ipv4/ipfrag_time
The number of seconds the kernel should keep IP fragments before discarding them. Thirty seconds is usually a good time. Decrease this if attackers are forging fragments and you'll be better able to service legitimate connections.

enable /proc/sys/net/ip_always_defrag
Always defragment fragmented packets before passing them along through the firewall. Linux 2.4 and later kernels do not have this /proc entry, defragmentation is turned on by default.

(integer) /proc/sys/net/ipv4/tcp_max_orphans
The number of local sockets that are no longer attached to a process that will be maintained. These sockets are usually the result of failed network connections, such as the FIN-WAIT state where the remote end has not acknowledged the tear down of a TCP connection. After this limit has been reached, orphaned connections are removed from the kernel immediately. If your firewall is acting as a standard packet filter, this variable should not come into play, but it is helpful on connection endpoints such as Web servers. This variable is set at boot time to a value appropriate to the amount of memory on your system.

Other related variables that may be useful include tcp_retries1 (how many TCP retries we send before giving up), tcp_retries2 (how many TCP retries we send that are associated with an existing TCP connection before giving up), tcp_orphan_retries (how many retries to send for connections we've closed), tcp_fin_timeout (how long we'll maintain sockets in partially closed states before dropping them.) All of these parameters can be tweaked to fit the purpose of the machine, and are not purely security related.

(integer) /proc/sys/net/ipv4/icmp_ratelimit
(integer) /proc/sys/net/ipv4/icmp_ratemask
Together, these two variables allow you to limit how frequently specified ICMP packets are generated. icmp_ratelimit defines how many packets that match the icmp_ratemask per jiffie (a unit of time, a 1/100th of a second on most architectures) are allowed. The ratemask is a logical OR of all the ICMP codes you wish to rate limit. (See /usr/include/linux/icmp.h for the actual values.) The default mask includes destination unreachable, source quench, time exceeded and parameter problem. If you increase the limit, you can slow down or potentially confuse port scans, but you may inhibit legitimate network error indicators.

enable /proc/sys/net/ipv4/conf/*/log_martians
Have the kernel send syslog messages when packets are received with addresses that are illegal.

(integer) /proc/sys/net/ipv4/neigh/*/locktime
Reject ARP address changes if the existing entry is less than this many jiffies old. If an attacker on your LAN uses ARP poisoning to perform a man-in-the-middle attack, raising this variable can prevent ARP cache thrashing.

(integer) /proc/sys/net/ipv4/neigh/*/gc_stale_time
How often in seconds to clean out old ARP entries and make a new ARP request. Lower values will allow the server to more quickly adjust to a valid IP migration (good) or an ARP poisoning attack (bad).

disable /proc/sys/net/ipv4/conf/*/proxy_arp
Reply to ARP requests if we have a route to the host in question. This may be necessary in some firewall or VPN/router setups, but is generally a bad idea on hosts.

enable /proc/sys/net/ipv4/tcp_syncookies
A very popular denial of service attack involves a cracker sending many (possibly forged) SYN packets to your server, but never completing the TCP three way handshake. This quickly uses up slots in the kernel's half open queue, preventing legitimate connections from succeeding. Since a connection does not need to be completed, there need be no resources used on the attacking machine, so this is easy to perform and maintain.

If the tcp_syncookies variable is set (only available if your kernel was compiled with CONFIG_SYNCOOKIES) then the kernel handles TCP SYN packets normally until the queue is full, at which point the SYN cookie functionality kicks in.

SYN cookies work by not using a SYN queue at all. Instead the kernel will reply to any SYN packet with a SYN|ACK as normal, but it will present a specially-crafted TCP sequence number that encodes the source and destination IP address and port number and the time the packet was sent. An attacker performing the SYN flood would never have gotten this packet at all if they're spoofing, so they wouldn't respond. A legitimate connection attempt would send the third packet of the three way handshake which includes this sequence number, and the server can verify that it must be in response to a valid SYN cookie and allows the connection, even though there is no corresponding entry in the SYN queue.

Enabling SYN cookies is a very simple way to defeat SYN flood attacks while using only a bit more CPU time for the cookie creation and verification. Since the alternative is to reject all incoming connections, enabling SYN cookies is an obvious choice. For more information about the inner workings of SYN cookies, see http://cr.yp.to/syncookies.html

Summary
When creating a Linux firewall, or hardening a Linux host, there are many kernel variables that can be utilized to help secure the default networking stack. Coupled with more advanced rules, such as Netfilter (iptables) kernel ACLs, you can have a very secure machine with a minimum of fuss.

Brian Hatch is the author of Hacking Linux Exposed, 2nd Edition, Building Linux VPNs, and of the weekly Linux Security: Tips, Tricks, and Hackery Newsletter. While he admits the /proc interface is extremely powerful, he prefers to change kernel variables by modifying /dev/kmem manually using 'dd if=/dev/random of=/dev/kmem bs=2 count=1 seek=...'

Relevant Links

[1] Actually, kernel variables have been tweakable via the _sysctl(2) call since the olden days of the Linux kernel. Unfortunately, the actual kernel variable names change between versions, whereas the locations inside the /proc filesystem are more static, so _sysctl(2) is depreciated.

[2] Sysctl can use slashes instead of dots, actually, but it is traditional/historical to use dots instead.

Source : http://securityfocus.com

The Enemy Within: Firewalls and Backdoors

2007-08-31T07:53:00.000-07:00

Can your security infrastructure protect you when you've left the key under the mat?

As a modern IT professional you've done all the right things to keep the "bad guys" out: you protected your network with firewalls and/or proxies, deployed anti-virus software across all platforms, and secured your mobile workstations with personal firewalls. You may even be in the process of designing and deploying an enterprise-wide network and host intrusion detection framework to help keep an even closer eye on what's going on. Even with all this, are you really safe? Can your multiple-lines of defense truly protect your network from modern methods of intrusion?

This article presents an overview of modern backdoor techniques, discusses how they can be used to bypass the security infrastructure that exists in most network deployments and issues a wake-up call for those relying on current technologies to safeguard their systems/networks.

The Fundamentals of Firewalls

Before a discussion of modern backdoor techniques can take place, it is necessary to first look at what obstacles an attacker must get through. Firewalls are an integral part of a comprehensive security framework for your network. If they are relied on too heavily they can also be the weakest link in your defense strategy.

There are different flavors/combinations of "standard" firewalls to choose from depending on your environment:

Packet filters [1]

* Operates at Layer 3
* Also known as Port-based firewalls
* Each packet is compared to against a list of rules (source/destination address, source/destination port, protocol)
* Inexpensive and fast, but least secure
* 20-year old technology
* Breaks more complex applications (e.g. FTP)
* Example: router access control lists (ACL)

Circuit-level gateways

* Operates at Layer 4
* Relay TCP connections based on port
* Inexpensive but more secure than packet filters
* Generally requires work on the user or application configuration end to support
* Example: SOCKS-based firewalls

Application-level gateways [2]

* Operates at Layer 5
* Application-specific
* Moderately expensive and slower, but more secure and enables user activity logging
* Generally requires work on the user, network or application-configuration end to support
* Example: Web (http) proxy

Stateful, multi-layer inspection firewalls [3]

* Layer 3 filtering
* Layer 4 validation
* Layer 5 inspection
* High level of cost, security and complexity
* Example: CheckPoint Firewall-1

Some newer firewall technologies build upon these foundations and provide additional ways of securing both systems and networks:

"Personal"/host firewalls

This class of firewall has the ability to further enhance security by enabling granular control over what types of system functions and processes have access to networking resources. These firewalls can use various types of signatures and host conditions to allow or deny traffic. Some of the more common functions across personal firewall implementations include:

* Protocol-driver blocking - disallow "non-standard" protocol drivers to be loaded and used by programs
* Application-level blocking - only allow certain applications or libraries to perform network actions or accept incoming connections
* Signature-based blocking - constantly monitor the network traffic and block all known attacks from making it to the host

The added control increases the difficulty of managing security due to the potentially large numbers of systems that may be individually firewalled. It also increases the risk of damage and exposure due to misconfiguration.

Dynamic Network Firewalling

Similar to the signature-based blocking features of personal firewalls, dynamic network firewalling marries the concepts of IDS, standard firewalls (see above) and emerging intrusion prevention techniques to provide "on-the-fly" blocking of specific network connections that fit a defined profile while allowing connections from other sources to the same port(s). This allows a firewall to proactively deny access to, say, clients that are issuing SQL worm attacks against your network while still allowing standard SQL traffic to flow.

The Basics of Backdoors

What is a backdoor? A backdoor is a "mechanism surreptitiously introduced into a computer system to facilitate unauthorized access to the system,"[4] and can be classified into (at least) three categories:

Active

Active backdoors originate outbound connections to one or more hosts. These connections can either provide full, fluid network access between the hosts (i.e. reverse tunnel-based) or be part of a process that actively monitors the compromised system, records information, sends data out in distinct "chunks" and receives both acknowledgements and/or commands from the remote systems.

Passive

Passive backdoors listen on one or more ports for incoming connections from one or more hosts. Similar to the active backdoors, these programs can either be used to establish a forward tunnel into the compromised network or accept distinct commands and return the requested information.

Attack-based

This category of backdoor could also be classified as the "unknown backdoor." It generally arises from a buffer-overflow exploit of poorly-written programs resulting in some type (e.g. root/Administrator-level, user-level, fully-interactive, one-instruction) of command-level access to the compromised system.

There is one common element among the three types of backdoors - they all work by circumventing the elaborate multi-layer security infrastructure you have worked diligently to design and deploy. Most real (i.e. non-script-kiddies) hackers can determine almost immediately if it's worth attempting to meet your perimeter routers and firewalls with a head-on attack. Textbook methods can be relatively easily employed to help discover the types and configurations equipment protecting the borders of your network. Some of these discovery tools can even help detect the presence of proactive network intrusion detection systems (IDS). While there are still daily exceptions, most perimeter networks are configured well enough to make backdoors the emerging method-of-choice for deep-network penetration for a number of reasons:

They avoid immediate detection by well-configured firewalls, network & host IDS.

A perimeter attack will (or should) make your operations consoles light up like a Christmas tree. There is no such thing as a casual or accidental scan of open firewall ports. If you don't have a penetration test scheduled, chances are that you're being probed.

Some proactive environments will immediately lock-out the originating systems' IP address when these scans are detected. Even if this is not the case, risking detection removes the primary reason for getting into your environment: the ability to operate freely and without notice.

They don't rely on potentially hard-to-duplicate, specialized attack methods.

What is more difficult: constructing the precise SYN-Frag attack necessary to cause a buffer-overflow in a CheckPoint firewall (that is two revisions behind the latest patch-level) to render it as helpless as a router without ACLs, or getting an unwitting user to open up an e-mail attachment?

To make it past the outer defenses, it might require the use of 4-6 of these specialized attack methods with no guarantees that one of them won't cause a crash and reboot, rendering the entire attempt useless.

They take advantage of the myriad of exploits available in the soft underbelly of an organization's internal network.

How many Microsoft Windows-based workstations and servers are in your organization? How many *nix systems do you have? How many users do you have with each of these types of systems? How many routers, firewalls and IDS systems do you have?

Chances are significantly higher that in most organizations a hacker will have a much easier time finding an un-patched Windows or *nix system to exploit than they will an un-patched and/or misconfigured piece of perimeter networking/security equipment.

An Inside Job

While this article has presented the concept of backdoors in the context of external penetration attempts, they are not limited to that narrow area of practice. Backdoors can be used by employees, contractors or planted-workers to provide less restrictive and undetectable "remote access" points all across your network.

Regardless of the type of backdoor, there are two primary ways of injecting them into your network. The first method involves getting a user to inadvertently load and run the program on their system(s). Extremely common examples of this include e-mail attachments that exploit un-patched vulnerabilities in client systems, web sites/downloads that have an unexpected/hidden payload, and programs that fall into the classification of "spyware". Unfortunately, these methods are all too common and can result in serious loss of confidentiality and privacy. In the case of "spyware", programs are installed, registry keys are inserted and browser cookies are set that enable the tracking of every network-based move a user makes. This tracking is not limited to Internet sites, which thus make it very easy for these systems to map out all the important places on a company's intranet. While the majority of the "spyware" programs are used to present and track your viewing of web ads, others can be crafted to be sentinels to alert remote sites of your online/offline status, complete with current network connection information.

Even without loading malicious "spyware" backdoors, a user can still be susceptible to a more corporate form of backdoor. Real Networks player performs constant communication to its home network and is nearly impossible to deactivate without reinstalling. Microsoft XP users have the ability to be tracked by either enabling automatic updates or just having their time kept in sync by Microsoft's own time server.

The second method involves actually being on your network in the first place. A trivial example would be installing a custom-program which has a programmer-created backdoor embedded in it. These types of backdoors can be malicious, but they are usually coded as a means of circumventing standard software development processes in order to save time.

A more typical, network-level, generic example would be one which is used to bypass remote access restrictions. This may be the oldest form (relative to the early stages of the Internet) of backdoor, initially used to bypass inbound telnet/rlogin restrictions. The setup is rather straightforward: a user installs a program that doesn't require elevated privileges to execute, then the program is run and it waits for connections on a port that isn't blocked by upstream access control devices. This remote access could be to a multi-user system or to an individual's workstation. Initially only Unix-oriented, these types of programs can be difficult to detect.

These types of backdoors are easier to understand in the context of concrete examples:
Program: BindShell
Available at: http://hysteria.sk/sd/f/junk/bindshell/bindshell.c
Type: PASSIVE

This program is easily modified to run on any defined port - for this example, TCP 1234 - and doesn't support a password, thus allowing anyone access. To access this service, the remote user simply starts a telnet session to the desired host and specifies a port number:

telnet some.insecure.host.org 1234

Variations of this program can also be found at http://packetstormsecurity.nl/ which support UDP connections and encrypted sessions.

There are several techniques that can be used to attempt to detect this, none of which will provide simple or direct isolation. In all cases knowledge of the normal run state of the OS is necessary.

* 'netstat -a' is a program that comes as part of the UNIX operating system and is used to display network port connection status. One would look for port usage that isn't part of the normal run state.
* 'nmap'[5] or 'strobe'[6] external port scanners could be used to identify active or listening ports. Again, knowledge of a normal run state would be extremely helpful.
* 'lsof -i'[7] a public domain program, can be used to list all open files and their resource usage. One would search the output for users running unusual programs that require the use of networking ports.

Program: Sneakin
Available at: http://packetstormsecurity.org/Exploit_Code_Archive/sneakin.tgz
Type: ACTIVE

This program requires elevated privileges and basically waits for two specially-crafted ICMP packets to arrive before starting something very similar to a reverse telnet session which establishes a connection to a remote machine. Sneakin requires LINUX and netcat[8].

The "listening" state is just as difficult to detect as in the above example. A conventional external port scan will not work since the program intercepts and processes ICMP packets while still allowing access to them by the native operating system kernel. LSOF, however will show a process accessing the network adapter in promiscuous mode. In general, LSOF might be the best tool available to detect NICs in this state. Netstat will also provide a clue to this particular backdoor, as it will show two ICMP ports using the raw protocol. Once "sneakin" enters it's ACTIVE state, additional processes using network ports will show up in LSOF and Netstat output.
Program: GlFtpD
Available at: http://www.security-express.com/archives/bugtaq/1999-q4/0443.html
Type: ATTACK

GlFtpD is one of the standard examples of an attack-based backdoor. The premise behind it is simple: an attacker would take advantage of a few misconfigured features of an ftp server, allowing them to deposit and execute backdoor code, in this case BindShell. A weak inbound policy combined with un-proxied, weak outbound policies do the rest.

Sneakin and bindshell are classic tools used against weak inbound firewall policies. Many sites deploy extremely strong inbound policies, making it difficult to gain direct access to the listening ports. Without direct access, a large number of backdoors cannot be exploited. However, the strongest inbound policy can be easily defeated by active backdoors using "tunneling" methodologies. A tunnel, in the context of backdoors, is best explained as a program that sits on the inside of a protected network and establishes an outbound connection to an external host which results in the flow of bi-directional traffic between these systems and/or networks. This is a serious threat to even the most modern security architectures. A popular example of such communications would be to create an encrypted network connection between two hosts using VPN software.

Properly configured, a VPN tunnel will allow total and unrestricted access to the networks that the hosts are gateways for. When provided as a legitimate remote access tool for employees and business partners, VPNs can increase productivity, save time and reduce costs. When they are used to exploit gaps in the security architecture, they can have just the opposite effect.

VPN technology is still fairly new and requires more than casual knowledge to setup and maintain when used legitimately. The learning curve is even steeper when they are being used as a backdoor tool. You don't need a VPN for a tunnel. Taking a step back, it is possible to connect just two hosts using more traditional and widely known software - secure shell. Secure shell - or SSH[9] as it is more commonly referenced - can be used to establish a tunnel between two hosts by allowing the redirection of a port on the client (outside the firewall) to a port on the host (behind the firewall). For example, one could redirect a client port 2200 to host port 23. Assuming the user is currently accessing the client (outside the firewall), they would telnet to the localhost port 2200 and get port 23 on the remote host (behind the firewall). A weak outbound policy allows the connection to be generated from the host behind the firewall. This is a neat and popular trick.

In the same scenario it is also fairly straightforward to provide access to an organization's internal web sites. The user would simply install a copy of a proxying agent - e.g. "squid"[10] web proxy or the Apache "httpd"[11] daemon with proxy support compiled in - on some internal system. The standard software configuration could be used for either agent. The user would then use SSH port redirection to connect client port 3128 to host port 3128. The client, again outside the firewall, now has proxied access to the organization's internal web servers thru proxy port 3128.

This example can be extended further to enable more than one external host to have access to the internal web sites. The addition of a simple port redirector[12] can make the tunneled, proxied connection available (on port 3128) to all users of the remote network.

Conventional techniques will not work in identifying the existence of this type of tunnel. Depending on the platform used, one could monitor network usage and look for consistent or seemingly permanent processes with established network connections to the outside. At a host level, identifying backdoors in this manner would necessitate the building and maintenance of a baseline network usage state (possibly using the tools mentioned earlier). It is also possible to query the boundary firewalls and monitor the connection state tables, focusing on these established connections. Either process is a daunting task in busy/large environments.

A Ready Defense

There is little one can do to completely defend their network from the use of backdoors. The current set of tools - whether it be host or network IDS - are difficult to configure, deploy and use effectively, especially in large organizations. Without the development of special-purpose tools, expressly designed to monitor systems and networks for the presence of backdoors, the only way to defend against these techniques is through a change in thinking. Security managers who think they can simply hide their networks behind a firewall, sit back and declare that "nobody can get in, I closed all the doors" need to take a hard look at their line of thinking. A good defense against backdoors needs to start with a change in network access philosophy. A solid beginning would be to develop strong Internet access policies and implement technologies that limit outbound access via well-configured firewall/outbound-access architectures.

At a network level, stopping backdoors means making it very difficult for them to establish connections outside of your infrastructure. One approach would be to use circuit-level gateways (i.e. SOCKS/port redirection) as a means of restricting backdoors from using high (or any) TCP ports. With simple port redirection, network requests destined for an external endpoint are terminated internally at a device which makes the connection on its behalf to a pre-defined endpoint. While this limits the number of external resources applications can access, it can also create additional administrative and processing overhead and may not work for all applications. With modern SOCKS gateways, the administration can be done on a global policy level with little impact on performance and almost no impact on applications.

An alternative approach would be through the use of (again) highly restrictive outbound access policies - where very few direct outbound connections are allowed - and Web/application-specific proxies that force authentication before access is enabled. The goal is similar to port-redirection: stop unchecked access to external hosts. While most traditional security schools would like nothing more than to close all the doors and windows, modern businesses need access to external resources to function. Unfortunately, almost any outbound access mechanism can potentially be used to provide a conduit for backdoors. Proxy-based architectures enable granular control over what is allowed outside of your network since applications need to "speak the right language" to be permitted access. Tunnels can be established[13] through proxies (especially via SSL connections[14]) but they are much harder to configure, deploy correctly and rely on. With authentication thrown into the mix, a way now exists to identify all connections down to the source (user). All the pieces are then in place to deter (where possible), detect and discover backdoors.

Even with these techniques - which will require time and resources to implement - developing a network access architecture which makes it easy for users to get work done and difficult for backdoors to do their job is not a trivial endeavor. Fundamentally, your aim should be to design an infrastructure that makes it as efficient as possible to tie network connections to users while narrowing down the options for the backdoors.
[1]The Packet Filter: A Basic Network Security Tool - http://www.sans.org/rr/firewall/packet_filter.php
[2]Application-Level Firewalls: Smaller Net, Tighter Filter - http://www.networkcomputing.com/1405/1405f3.html
[3]Anatomy of a Stateful Firewall - http://www.sans.org/rr/firewall/anatomy.php
[4]Detecting Backdoors - http://www.icir.org/vern/papers/backdoor/
[5]nmap home - http://www.insecure.org/
[6]strobe source code - http://www.packetstormsecurity.org/UNIX/scanners/strobe-1.04.tgz
[7]lsof main distribution - ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof
[8]Netcat - The TCP/IP Swiss Army Knife - http://www.sans.org/rr/audit/netcat.php
[9]OpenSSH home - http://www.openssh.org/
[10]Squid Web Proxy Cache home - href="http://www.squid-cache.org/"
[11]Apache httpd Project - http:///httpd.apache.org/
[12]Port Forwarding Tools - http://nucleo.freeservers.com/portfwd/tools.html
[13]rwwwshell - http://www.thc.org/releases/rwwwshell-2.0.pl.gz
[14]ssh-tunnel.pl - http://www.fwtk.org/fwtk/patches/ssh-tunnel.pl

Source : http://securityfocus.com

Potential Trend Micro ServerProtect Security Risk

2007-08-31T06:50:00.000-07:00

Vulnerability Identifier: CVE-2007-1070
Discovery Date: Aug 22, 2007
Related Malware: BKDR_IRCBOT.AJZ
Affected Software:

* Trend Micro ServerProtect for Microsoft Windows 5.58

Description:

Trend Micro has recently been informed by SANS Internet Storm Center (ISC) that there is an increase in scans of port 5168, which is a key communication port utilized by the Trend Micro ServerProtect software.

Trend Micro has been made aware of potential vulnerabilities in ServerProtect and has been actively working on developing patches to eliminate these vulnerabilities. This sudden increase in scanning traffic could indicate that malicious entities may be looking for ways to exploit vulnerable machines.

To our knowledge, there are no confirmed exploits of this vulnerability to date. Nevertheless, we implore security administrators to apply the latest ServerProtect security patch available from Trend Micro as soon as possible to protect against any potential attack.

Patch Information:

The latest security patches and ReadMe text files can be found at the following locations:

* English (Security Patch 4):
http://www.trendmicro.com/download/product.asp?productid=17
* Japanese (Security Patch 2):
http://www.trendmicro.co.jp/download/product.asp?productid=17
* Traditional Chinese (Security Patch 3):
http://www.trendmicro.com/download/zh-tw/product.asp?productid=17

For additional questions and/or concerns, contact your local Trend Micro support representative.
Source : http://trendmicro.com

(MS07-050) Vulnerability in Vector Markup Language Could Allow Remote Code Execution (938127)

2007-08-31T06:45:00.000-07:00

Vulnerability Identifier: CVE-2007-1749
Discovery Date: Aug 14, 2007
Risk: Critical
Affected Software:

* Microsoft Internet Explorer 5.01 Service Pack 4
* Microsoft Internet Explorer 6 (Microsoft Windows Server 2003 Service Pack 1)
* Microsoft Internet Explorer 6 (Microsoft Windows Server 2003 Service Pack 2)
* Microsoft Internet Explorer 6 (Microsoft Windows Server 2003 with SP1 for Itanium-based Systems)
* Microsoft Internet Explorer 6 (Microsoft Windows Server 2003 with SP2 for Itanium-based Systems)
* Microsoft Internet Explorer 6 (Microsoft Windows Server 2003 x64 Edition Service Pack 2)
* Microsoft Internet Explorer 6 (Microsoft Windows Server 2003 x64 Edition)
* Microsoft Internet Explorer 6 (Microsoft Windows Server 2003)
* Microsoft Internet Explorer 6 (Microsoft Windows XP Professional x64 Edition Service Pack 2)
* Microsoft Internet Explorer 6 (Microsoft Windows XP Service Pack 2)
* Microsoft Internet Explorer 6.0 Service Pack 1 (Microsoft Windows XP 64-Bit Edition)
* Microsoft Internet Explorer 7 (Microsoft Windows Server 2003 Service Pack 1)
* Microsoft Internet Explorer 7 (Microsoft Windows Server 2003 Service Pack 2)
* Microsoft Internet Explorer 7 (Microsoft Windows Server 2003 with SP1 for Itanium-based Systems)
* Microsoft Internet Explorer 7 (Microsoft Windows Server 2003 with SP2 for Itanium-based Systems)
* Microsoft Internet Explorer 7 (Microsoft Windows Server 2003 x64 Edition Service Pack 2)
* Microsoft Internet Explorer 7 (Microsoft Windows Server 2003 x64 Edition)
* Microsoft Internet Explorer 7 (Microsoft Windows XP Professional x64 Edition Service Pack 2)
* Microsoft Internet Explorer 7 (Microsoft Windows XP Professional x64 Edition)
* Microsoft Internet Explorer 7 (Microsoft Windows XP Service Pack 2)
* Windows Vista
* Windows Vista x64 Edition

Description:

This security update resolves a privately reported vulnerability in the Vector Markup Language (VML) implementation in Windows. The vulnerability could allow remote code execution if a user views a specially crafted Web page using Internet Explorer. Users whose accounts are configured to have fewer user rights on the system could be less affected than users who operate with administrative user rights.

An attacker could exploit the said vulnerability by creating a specially crafted Web page or HTML e-mail. When a user views the Web page or the message, the vulnerability could allow remote code execution.

Patch Information:

Patches for this vulnerability are available at:

http://www.microsoft.com/technet/security/bulletin/MS07-050.mspx

Source : http://trendmicro.com

Introduction to IPAudit

2007-08-29T05:14:00.000-07:00

IPAudit is a handy tool that will allow you to analyze all packets entering and leaving your network. It listens to a network device in promiscuous mode, just as an IDS sensor would, and provides details on hosts, ports, and protocols. It can be used to monitor bandwidth, connection pairs, detect compromises, discover botnets, and see whos scanning your network. When compared to similar tools, such as Cisco System's Netflow it has many advantages (see the SecurityFocus articles on Netflow, part 1 and part 2). It is easier to setup than Netflow, and if you install it on your existing IDS sensors, there is no extra hardware to purchase. Since it captures traffic from a span port, it does not require that you modify the configuration of your networking equipment, or poke holes in firewalls for Netflow data.

Packet analysis tools like IPAudit help fill the gaps left by an IDS system or an IPS system. How does it do this? An IDS looks for certain signatures or behavior and can alert and log. An IPS looks for the same anomalies but can prevent the attack. Both of these technologies can greatly increase the security of your network -- however, what happens if they miss an attack? How would you know? Even if the IDS sensor matches a packet, a machine can still become compromised. When this happens how do you tell what happened on the network after the compromise? IPAudit can help fill the gaps, in addition to providing you with useful information about your network beyond specific security events. It is most often used by universities where its primary role is to identify who is using the most bandwidth. The author of this article finds it to be useful for all organizations; in fact, many corporate customers will also recognize the benefits and incorporate it into their security tool arsenal.
Installation and configuration
IPAudit is a perl-based application written by John Rifkin at the University Of Connecticut. It can be downloaded from Sourceforge and is licensed under the GNU GPL. IPAudit is a command line tool that uses the libpcap library to listen to traffic and generate data. The IPAudit-Web package includes the IPAudit binary in addition to the web interface that creates reports based on the collected data. Using the Web package is recommended, as it gives you a slick graphical interface complete with traffic charts and a search feature.

You will need to have a Linux or Unix system setup with the libpcap library installed. The latest version can be downloaded from tcpdump.org. In addition to libpcap, you will need Perl, Apache, GNUplot, and a perl module called "Time::ParseDate". Refer to your Linux distribution's documentation for more information on how to install these packages (here's a tip: In Debian Linux, execute the command 'apt-get install libtime-modules-perl' to install Time::ParseDate). Once you have installed these packages you are ready to begin installing IPAudit:

Step 1 - Become root on your system and create a user called "ipaudit". It will need a valid shell and home directory (typically /home/ipaudit, which will be used in this article for simplicity). Now switch to the newly created "ipaudit" user.

Step 2 - Download and unpack the ipaudit-web tarball:

$ tar zxvf tar zxvf ipaudit-web-1.0BETA9.tar.gz

Step 3 - Change to the compile directory:

$ cd ipaudit-web-1.0BETA9/compile

Step 4 - Execute the configure script and run make:

$ ./configure
$ make

Step 5 - Become root and execute the make install commands:

$ su -
Password:
# make install
# make install-cron
# exit (Leave root and become ipaudit user again)
$

Step 6 - Now you will need to edit /home/ipaudit/ipaudit-web.conf

#
LOCALRANGE=127.0.0
#

#
INTERFACE=eth1
#

Change the LOCALRANGE variable to your local subnet on the inside of your network. Also be certain to set the INTERFACE variable to the interface that you have setup to capture the desired traffic on your network.

Step 7 - Add the following lines to your Apache httpd.conf file if they do not already exist:

AllowOverride All
Options MultiViews Indexes Includes FollowSymLinks
Order allow,deny
Allow from all

Options +ExecCGI -Includes -Indexes
SetHandler cgi-script

Note that your Apache server may already contain configuration similar to the above for the "/home/*/public_html" directory. If you do not plan to use the Userdir module for anything other than IPAudit, it is suggested that you comment out the original configuration and replacing it with the configuration above.

Your Apache server will need to support SUEXEC, Mod_Perl, and Mod_Userdir. Once you have modified the Apache configuration restart your Apache server. For more details on the IPAudit-Web installation, refer to the INSTALL file located in the installation directory of that package. It contains more information about the required Perl module Time::ParseDate, SUEXEC, and password protecting your IPADUIT-Web installation. Since is requires just moderate Google hacking skills to find other peoples IPAudit installations, protecting IPAudit with a password would be a very good idea.

Step 8 - Check your installation

Open a web browser and go to:

http:///~ipaudit/

If your installation was successful you should now see a screen like the one shown below in Figure 1.

Figure 1. Running IPAudit's web interface for the first time.

You should make certain that the time on the server running IPAudit is correct and being kept up to date using NTP. Without accurate time, IPAudit will get confused if the time on the packets differs greatly from that of the system time.

After the first half hour mark, IPAudit will begin to graph all of your traffic and generate some reports. The screen should then look similar to the one in Figure 2.

Figure 2. First graph appears after 30 minutes.

The graphs will get more interesting as time goes on and as IPAudit sees more traffic. A "spike" in the graph typically denotes an indication of a problem, such as a host sending out a DoS (Denial of Service) attack.
General reporting
IPAudit's "Network Reports" are useful for many reasons. The thirty-minute and daily reports are exactly the same, except of course for the timeframe. By clicking on the link labeled "-last-" next to the "30min" link you will see the report for the last 30 minutes. At the top of the screen you can see general network statistics, which is good if you are trying to keep tabs on your total bandwidth utilization. This is followed by the busiest local hosts report, which is good way to keep an eye on who is transferring the most data into or out of your organization, as shown in Figure 3.

Figure 3. Displaying the busiest hosts on the local network.

Your servers, such as SMTP mail servers, will typically be close to the top of this list (in addition to your P2P hosts, if you allow that application). Over time you will develop a baseline of your busiest hosts. When checked everyday, you may notice a new host occupying the top busiest host and this would be cause for you to investigate.

The busiest remote hosts report tells you who on the Internet you are transferring the most data to and from.

Figure 4. Displaying the busiest remote hosts.

Typically these tend to be Akamai caching servers, Windows Update IP addresses, and other popular web sites like Google or Yahoo. If one of the sites listed resolves to something unfamiliar like www.evil.com, it should be cause for alarm.

The next report is the, "Possible Incoming Scan Hosts," which shows the IP addresses of the hosts that connected, or tried to connect, to the most unique IP addresses on the local subnet. This report is useful to see who is scanning your network, and what ports they are scanning for.

Figure 5. Top remote IP addresses scanning your network.

It is good to check this table everyday when monitoring a network. It is useful to take the most common ports that the network is being scanned for and research them. The following web sites are useful when determining what applications correspond to the ports attackers are scanning for:

* SANS - From the main page you will find a port search function. This reads from the Dshield database. This page also offers the most up-to-date information on port-scanning trends and general blackhat activity.
* The official port assignments database.
* Google - When in doubt, use Google to find information about ports, for example "tcp port 6881" to check for known Trojans that frequently use a given port.

Port-scanning activity is sometimes due to a new network scanning tool being released (like scannssh), or a new virus or worm that is being circulated. Having this information, it is good to warn the user population if the threat warrants that level of notification. An administrator can then target his notifications towards specific groups. For example, if the network is being scanned for MySQL instances, you should notify the server group and tell them to make certain they have applied all relevant patches and to not expose their servers to the Internet if it can possibly be helped. Oftentimes, you can correlate vulnerability or exploit releases with the portscanning attacks on your network. While you probably have a firewall that blocks these attempts, what if the firewall becomes mis-configured because of a firewall policy change? These reports allow you to react to threats against your network in an informed manner, adding another layer to your network security infrastructure.

Possible outgoing scan hosts are listed next. While the possible incoming scan hosts can be used for proactive measures, the following outgoing scan hosts report is more useful for reactive measures.

Figure 6. Outgoing scan hosts are useful for discovering Trojaned machines.

If I find hosts that are on the inside of the network scanning outwards, it is usually an indication that a machine has become compromised with a worm or virus, and in some cases an actual attacker has taken control of the host and is using to scan for other machines. When you begin to check the reports on a regular basis you will be able to develop a baseline and know what is normal on your network with regards to the number of hosts contacted in a given day. Some hosts need to contact numerous other unique hosts, such as SMTP relay and DNS servers. However, a typical user's workstation usually does not normally contact upwards of 1,000 different hosts on the Internet.

The port that your local hosts are scanning for is significant as well. A machine scanning out to the Internet on port 445 (Windows CIFS) or 6667 (IRC) should raise a red flag and cause you to investigate it as if it were compromised. Port 445, SMB CIFS, is a common port being scanned for on the Internet due to the number of vulnerabilities associated with it. IRC is typically used as a communications mechanim for compromised machines, more commonly known as botnets. However, a machine scanning out on ports 6881 (BitTorrent) or 6346 (GNUTella) would be an indication that the host is running a P2P networking application, which commonly scans the Internet looking for other P2P enabled hosts. The policy within your organization should dictate if this is acceptable behavior or not.

The busiest host pairs table is the final report. It lists which hosts had the largest single transfers between them. It's a good idea to take a look at this list and make certain that the transfers seem normal or not. Normal behavior would be someone downloading a Linux ISO image, whereas less normal behavior could be someone downloading pirated media from an already compromised host.

Going back to the main IPAudit page, you will notice even more reports that you can run. The client/server report can be useful for monitoring who is running the following services on your network:

* HTTP Servers
* Mail Servers
* SSH Servers
* Telnet Servers
* HTTPS Servers

I typically check these reports on a weekly basis to get an idea of who is running what server services on the network. A red flag could be a user workstation that ends up in the top ten SMTP servers listing. This could indicate that the host has been infected and is being used to distribute SPAM. The listing of HTTP servers is useful to see not only who may be running legitimate web servers on your network, but it can also be an indication of anyone tunneling other protocols with HTTP and running it over port 80 or 443 TCP. Since IPAudit only looks at IP and transport layer information, it will not distinguish between actual HTTP traffic and tunneled traffic (which can actually be good in this case).

The traffic type, weekly, and monthly reports all contain summary information about your network. They should be checked weekly to get an overview of what networking protocols are in use, and which hosts transmit and receive the most data. Host reports contain much of the same information as the weekly and monthly reports, except on a per host basis.

The log searching feature is an excellent way to find certain traffic types using multiple criteria, as shown below in Figure 7.

Figure 7. Searching IPAudit's logs.

You can adjust your query to a specific time period, right down to the minute. The IP address can either be a host on the local network or the external network/Internet. The local port is relative to the local address space you specified in the IPAudit-Web configuration file, as is the remote port. The next two fields, Max Lines Displayed and Print Increment tell IPAudit how to print out the query. It is best to start with a low number for the line displayed the first time you run a query, just in case there are thousands of results which could take some time. The session size is a particularly useful field when trying to determine traffic type. Sometimes you want to distinguish between actual data transfers and just portscanning. By playing around with the values in these fields you can do just that (for example, suppose you want to know who actually connected to the MySQL server, not who scanned it). The protocol drop down menu allows you to choose between TCP, UDP, and ICMP. IPAudit tries to keep track of state by indicating whom the first talker was in the connection.

Overall, IPAudit has many useful features and many ways in which to look at your network traffic. The next section will go into more detail on how to use it to detect compromise machines on your network.
Detecting compromised hosts
Similar to an IDS, IPAudit is a historical account of your network traffic. If an exploit comes flying into your network and is picked up by your IDS, it happily logs it. When you go to check the logs you can see this event, including the full packet, and you may say, "Yup, that was an exploit alright, I wonder if it was successful?" IPAudit works in much the same way, except you can use it to detect all behavior exhibited by the potential compromised host after the exploit was launched. Here is an example:

snort: [1:2351:10] NETBIOS DCERPC ISystemActivator path overflow attempt little endian unicode [Classification: Attempted Administrator Privilege Gain] [Priority: 1]: {TCP} 192.168.1.237:4014 -> 192.168.1.223:135

snort: [1:2123:3] ATTACK-RESPONSES Microsoft cmd.exe banner [Classification: Successful Administrator Privilege Gain] [Priority: 1]: {TCP} 192.168.1.223:31337 -> 192.168.1.45:32768

The above Snort alerts indicate that 192.168.1.237 is trying to exploit 192.168.1.223 using a very common exploit that takes advantage of the MS03-026 RPC vulnerability (See the full Snort rule documentation). We then see a very obvious backdoor attempt, most likely a simple Netcat command such as "nc.exe -l -p31337 -e cmd.exe".

Using IPAudit, let's examine the victim host's traffic. I would first go to the IPAudit searchable host feature, enter the timeframe I want to look at, then the IP address. It produces a report as shown in Figure 8.

Figure 8. Search results for a certain timeframe and IP address.

The above data indicated that the host is portscanning for port 445. First, we see that the same source port is used to connect to multiple different destination hosts. In normal TCP communications, a different source port would be used when connecting to a different host. Second, we see many attempts to port 445 on a class B network, with little data being transferred. Also, if we look at the column labeled "First Talker" it indicates that the host on the local network initiated the connection. The "Last Talker" column is blank, telling us that 192.168.1.223 sent out the packets, but received no responses. These are all telltale signs of portscanning.

What if you want to see what happened in addition to the portscanning? If someone did in fact compromise this host then they most likely uploaded some sort of rootkit or IRC bot. Let's take the IP address of the machine that opened the backdoor on our victim host and see what other machines it connected to that day, as shown in Figure 9.

Figure 9. Search showing potentially compromised IP connecting to other machines.

Here we see it connecting to our known victim host and transferring data on port 4000, among others.

After further analysis we see a similar transfer to another host on our network, 192.168.111.69, as shown in Figure 10.

Figure 10. Similar traffic shown with another machine.

The backdoor port is different, but the host is in fact compromised in the same way as 192.168.1.223. This can be verified in the IDS logs:

snort: [1:2123:3] ATTACK-RESPONSES Microsoft cmd.exe banner [Classification: Successful Administrator Privilege Gain] [Priority: 1]: {TCP} 192.168.111.69:2143 -> 192.168.1.45:32768

Using IPAudit we can then continue to map the scope of the compromise. This includes all machines that have become compromised, which servers attacked them, which servers are controlling them via backdoors, and which IRC servers they logged into. We do this by modifying our search criteria to map connections between all hosts involved.

The incident described above was based on a real incident, but was also recreated in a lab. The real incident involved a dozen compromised computers, two IRC servers, an attacking host, and a remote shell host. It was all mapped using IPAudit and correlated with Snort.
Conclusion
IPAudit is a great addition to your network monitoring. It provides reports that give you an overview of your network, inform you of security events, and report on anomalies. When used in conjunction with intrusion detection a security incident can be mapped out in a great deal of detail. Best of all, IPAudit is a free tool that is easy to setup and maintain. You will find it useful to install on all your IDS sensor installations.
About the author
Paul Asadoorian, GCIA, GCIH is the lead security engineer for a large university in the New England area where he designs, implements, and maintains intrusion detection systems, firewalls, and VPNs. He gives regular presentations in the academic community relating to network security. Paul is also the founder of Defensive Intuition, a security company specializing in security auditing, penetration testing, and other security related services.

Source : http://securityfocus.com

Standards in desktop firewall policies

2007-08-29T04:33:00.000-07:00

The idea of a common desktop firewall policy in any size organization is a very good thing. It makes responses to external or internal situations such as virus outbreaks or network-oriented propagation of viruses more predictable. In addition to providing a level of protection against port scanning, attacks or software vulnerabilities, it can provide the organizations local security team a baseline or starting point in dealing with such events.

The purpose of this article is to discuss the need for a desktop firewall policy within an organization, determine how it should be formed, and provide an example of one along with the security benefits it provides an organization.
The Problem
The trick to a good desktop firewall policy is to provide a balance between security and the networking requirements of the applications needed by the organization. It's possible the organization may not yet have a complete knowledge of these requirements. This should make the first attempt to define a standard/global policy interesting, depending on the level of protection one is trying to provide and the situation or environment the desktops may be in.

One thought on an initial policy is to provide a port-based firewall with all inbound ports blocked on the desktop. On the other hand, an old school of thought might involve one blocking only the ports that need to be blocked, by estimating software network requirements and then combining this with an effort to also block the most obvious of possible vulnerabilities or services. Evaluating FTP, Windows IIS or NetBIOS requirements might provide a first pass at a standard global policy. Our old school of thought again would leave the balance tipped toward the (as yet unknown) network requirements of the software, and less toward protection. In other words, offer functionality over security. While providing consistency, cases where the desktop (or laptop) is located off site may not fully satisfy security requirements of the organization.

Location awareness may be a feature of the desktop firewall that one could use to design a policy that changes to better fit a user's location. Some personal firewall solutions provide location awareness as a feature. Location selection could be automatically selected depending on a successful Windows domain login, specific IP address, DNS server address, network adaptor type, or it could be based on the client firewall's ability to connect to a policy manager.

If location awareness is not a built-in feature of the firewall, the policy could be designed around the organization's internal IP address range or, if available, be configured around the DNS domain name. For example:

allow all inbound *.someorganization.org
Issues with a "block all" inbound policy
A block all inbound policy while connected offsite would seem to present the least amount of risk, but might not be completely possible while onsite. The first issue may be caused by the firewall itself. Depending on the vendor, characteristics of the firewall may impact application functionality while using a block all inbound policy. This may include UDP, complex protocols like FTP, NFS, applications running in a service mode, and problems with a Intrusion Prevention System if one is provided with the firewall. Each of these issues will be discussed below.

UDP, being a stateless protocol, is difficult for any firewall to handle. A simple UDP based service may run on port 1313, or example. The UDP client (running the desktop firewall) would attempt to connect to 1313, and assign a port for a reply. There may or may not be a reply; if there is, it won't be easy for the firewall to determine whether or not to allow it. Either the firewall needs to attempt to keep state of all outbound UDP traffic on its own, or UDP port requirements must be known and the firewall must be configured to allow the reply on a case-by-case basis.

An example of a facility requiring UDP might be printer or scanner client that issues a UDP broadcast and then awaits a reply. That reply would come from a scanner or printer the user may want to access, and it might include its status or availability.

FTP could cause another possible issue with the firewall. In some cases the firewall may not support active FTP, which is unusual as Microsoft Windows doesn't support passive mode. Active FTP is where the ftp server will initiate a connection back to the client to do the actual transfer of data. Oddly, FTP is still used and sometimes even embedded within other software. Fixes for active FTP on firewalls can be ugly and may end up being one of the first application-based rules.

Applications running in a service mode can have one of two solutions: either the firewall requires an application-based rule where the application's network access is restricted to predefined ports, or one can simply allow the open port, possibly with some other restricting criteria. Restrictions by IP address or time of day are possible as well, and may be desired.

An Intrusion Prevention System may be an additional feature of a desktop firewall within an enterprise. This would allow the firewall to detect possible attacks by examining the inbound packet and matching data and port usage against a list of known attack signatures. The IPS may be configured to respond by blocking the inbound packet or allowing it and sending an alert. False positives on a firewall supporting IPS could mistakenly block inbound traffic and would need to be analyzed and adjusted on case-by-case basis. Logging the event and allowing the traffic may be the quickest and easiest way to deal with false positives.
The Environment
In this part of the article, we detail what is needed to create an environment where software requirements are known and our corporate standards are enforced:

1. a desktop firewall This is the tool used to enforce restrictions on network access by limiting port and protocol access. The firewall should limit the user's ability to change its configuration, yet provide enough function such that the user can identify issues that may be caused by the firewall policy. The firewall should support port- and application-based filtering.
2. A security policy This will define what is or is not permitted to or from the network, on a standard desktop. Typically this would be generated by a high-ranking security group or set of officials in the organization, and would be generalized into a non-technical document (it could be as simple as block all inbound rule).
3. Knowledge of existing port requirements or a baseline of requirements These would be taken standard or default desktop operating system configuration used in the organization. Typically an organization would have an install tailored to its own requirements, and it may include patches, anti-virus, and common software required by all users. This, combined with the security policy, would form the basic desktop firewall policy.
4. Ability to deploy a single global firewall solution to all desktops This means deploying the solution to all desktops in the organization with a consistent or single policy. Enforcement and tracking of deployment would also be necessary.
5. Facility to provide and update the firewall policy Some firewalls can be centrally managed directly. Depending on the needs or structure of the organization, the minimum requirements would require a common/global firewall policy that can be updated, for example through the replacement of a configuration file. Obviously some form of central software management would need to be in place.
6. Large plastic bat to handle upset users
7. Tools to aid in the analysis of the networking requirements For example, this might include Ethereal for monitoring traffic, the ability to analyze firewall logs, Perl scripts to test firewall rules, Nmap for port scanning, and so on.

"Software Networking Standards" – A potential benefit
If the organization knows the networking requirements of its applications, a policy could easily be created. Then the idea of software networking standards could be enforced through the policy.
An example
In order to provide a firewall policy for the examples below, let's first assume that a policy is designed and configured to block all inbound TCP/UDP, and allow all outbound TCP/UDP. We will also assume the firewall does not properly handle outbound UDP or complex protocols such as FTP. Some known software requirements in this environment may be obvious, for example support the organization permits file sharing. This would require inbound TCP port 445 open . A rule is created to support inbound 445 and also restrict the rule to a range of IP address (192.168.4.0 through 192.168.20.255 in this example, with the understanding that this private IP address range could be used by other organizations such as hotels as well, creating a potential hole for traveling users). Finally, ICMP is allowed for troubleshooting. A sample policy might thus be configured to:

* Allow all inbound and outbound ICMP
* Allow inbound TCP 445 from hosts 192.168.4.0 – 192.168.20.255
* Block all inbound TCP
* Block all inbound UDP
* Allow all outbound TCP
* Allow all outbound UDP

Let's now look at the benefits of using our sample policy.

Benefits of a desktop firewall policy

* The ability to predict the impact of security-related events is enhanced. An event could have many characteristics and take on many different forms. If some of those characteristics involve network port access, the policy may offer an initial form of protection. In addition, network-oriented responses to these events become more predictable. For example, the application of router and network firewall ACLs are sometimes used to deter the propagation of virus and worms. The problem is, the implementation of ACLs could impact production software, in cases where both applications and a security event have similar port requirements. Depending on the characteristics of the event, the example policy may make ACLs unnecessary on some network segments.

* Provide consistent software solutions (as opposed to multiple solutions that provide the same function). Two departments requiring a similar service may deploy two different software solutions. While it is best that departments in any organization coordinate development and deployment in software solutions, the reality is, this doesn't always happen. The policy defined above offers some hurdles for new applications. If the policy happens to conflict with the network requirements of the application a request for a policy enhancement would be required. At this point, if not already, the application becomes known to the organization.

* Restrict the ability for network-oriented programs from hitting the desktop until evaluated. Again, the policy may offer some new hurdles for applications, depending on their requirements. A recent example could be Microsoft's Activesync 4.0 software. The example policy above would require modifications, which could carry the concept of being loose or tight. (Visit Microsoft's Activesync page for the requirements.) The policy impacts the application in several areas: inbound port requirements, backend network construction, and these involve the use UDP along with TCP. A modification of the policy may include a fairly tight rule that binds the local ports to the application for the backend network only, such as:

allow 169.254.2.1 inbound access to the { required ports } AND { executables }

Analysis of the application through the use of Nmap can verify the port requirements on the backend network, but also reveals activity on the primary network. In this case a ‘status' port that is TCP 999 becomes active on the primary network when the handheld that uses Activesync is cradled. In theory one could execute a single port scan against port 999 on a subnet and identify all IP address which currently are ‘syncing' a handheld. Depending on the firewall internals and given the policy defined, Nmap may indicate ‘closed' for port 999. Some firewalls can be configured to drop an inbound packet for a port that is blocked, which would return nothing in this case.

* Restrict the use of service-oriented software. Individuals involved or concerned with security have to be interested and even frustrated with this. Software running on an ordinary desktop (as opposed to a ‘server') that requires a port used for listening could be susceptible to coding errors allowing inbound access or backdoors. They should be avoided.

* Software using unusual protocols will become known (such as systems using the streaming protocol IGMP). While the use of protocols other than IP isn't itselft an issue, it's an advantage to know they are in use. Some firewalls will not pass these protocols, and isolation of their use could be difficult. It's now common for the software provider or vendor to make their networking requirements available for organizations supporting a desktop firewall.

* Track the use of broadcast-oriented software which usually runs as UDP. The example policy in this article would disable the response to a UDP broadcast. A good standard for any organization is to define service-oriented equipment, such as printers and scanners, using static IP addresses, and make the user aware of the names and IP addresses of these facilities that are in their area. The security issue in this case is that the service could be spoofed. A phony print server could be created to capture and forward printouts to the actual server.

* Track the use of backend networks or dual-homed machines. The example policy may reveal a backend, depending on what it is being used for. The use of backend networks won't directly cause security concerns, but their existence and use should be identified. For example, asset and patch management could be impacted, and real vulnerability assessment would also not be possible.

* Software and desktop support can be impacted and simplified. The example policy offers some limitations on what software can do on the network. Software requiring modifications to the policy obviously becomes known, and the specific policy modifications would help create a consistent deployment.

* The example policy would help in the enforcement of the organization's security policies or detection of software which might break this policy. For example, it may be part of the security policy to prohibit the use of database, web, ftp or P2P servers on ordinary desktops. The policy in this example would block those services.

* A global policy could help enforce an organizations specific standards; such as the use of a remote access VPN or streaming media solution. The example policy would most likely require modifications to support VPN. Typically the software requirements of VPN would differ between vendors as well.

* The policy could be used to limit access to services running over non-standard ports. For example, assume that only minimum outbound internet access restrictions are in place and a policy and mechanism exists to monitor and log Internet web access. Typically web access is done using TCP port 80. However it is possible for a user to access an external anonymous web proxy (such as www.proxyblind.org; there are many others) that may run on a port other than 80. This usage would bypass logging and allow the user to surf the web anonymously. A modification to our example policy restricting iexplorer.exe to outbound TCP port 80 could be created. Limitations on other ports commonly used to support anonymous web proxies could also be created (for example, these are often found on TCP ports 3128, 8000 and 8080)

Summary
A common desktop firewall policy could lead to, or help in the enforcement of, software networking standards. If this is something an organization wants, there are clear benefits. Depending on whether the organization is running a firewall with a consistent policy or not, networking standards at some level may already be enforced. New applications may or may not be compatible with this policy, and changes or modifications would need to be requested. Those who deploy new software may need to be a bit more familiar with the network requirements of their software, to be able to adhere to policy.

The desktop firewall, typically just one piece of desktop security, often is combined with patch management, anti-virus and software deployment/management facilities to form a complete security solution. As part of that solution, the desktop firewall's job is to simply block network traffic and detect attacks. Yet the reality is, it can do more than this although added features may not be quite as tangible as the supplying desktop protection.

The implementation and maintenance of a desktop firewall can be a stressful and frustrating experience – particularly for those organizations who do not have a full understanding of their own network requirements. It can cause existing software to become disabled. It could require deployment dates to be extended due to additional development time required to isolate compatibility issues. It may require additional resources or steps to get software to the desktop.
Conclusion
In this article we discussed the need for a desktop firewall policy within an organization. It was discussed how such a policy should be formed, and then an example was provided – along with a detailed discussion of the security benefits it provides an organization.

An old school of thought would resist any restrictions placed on internal network access. But today the stakes are a higher, and security is paramount. At some point in the history of networked computing, an organization has become more accountable for its network traffic and legality of the software it chooses to run. Not many options are available for limiting the use of the network (beyond simply blocking it at the usual choke points, which doesn't allow for the controlling of specific applications). This approach needs to change, as more and more attacks and security concerns come from the soft underbelly of the organization's internal network.

Source : http://securityfocus.com

Antivirus Concerns in XP and .NET Environments

2007-08-26T08:56:00.000-07:00

After Windows NT was released, it took virus writers five years to learn how to infect it. Windows NT 3.1 and the Win32 API were released in late 1993, but it wasn't until August 1998 that W32.Cabanas became the first NT virus by capturing coveted kernel mode access. .NET and some of Microsoft's other initiatives have not been as lucky. The purpose of this article is to discuss antivirus (AV) concerns with .NET and Microsoft Windows XP.

.NET Review

.NET was officially announced by Microsoft in July 2000 at a Microsoft Professional Development Conference. Since then, what .NET has meant and the products involved have changed (and been renamed). .NET is an idea and a programming platform. The basic concept is an evolving extension of Microsoft's Object Linking Embedding (OLE) introduced back in the early days of Windows 3.0. OLE allows you to copy objects and data created in one application, like a spreadsheet graph, to other applications. OLE evolved into ActiveX objects, which are executables you can download and run within an Internet browser.

.NET takes it two steps further by allowing the entire application to be hosted elsewhere (potentially allowing your environment to follow you, no matter where you go) and allowing different distributed software parts to make up one application. For example, your Windows desktop settings, your applications, and your data may be available to you where ever you compute. Running by an Internet kiosk in an airport? Just login and access your desktop and your data. Different applications will co-exist together, over the web, to bring you that integrated environment. One vendor will handle the login and authentication, another will store your data, and each of your applications will be made up of specifically customized components. I'll take two thesauruses, a math equation editor, and a French translation dictionary please. Hold the autocorrect.

All of this magic happens because of new distributed .NET programming platform and a horde of new Microsoft developer tools and languages: C# (C Sharp), Visual J#, VB.NET, Visual Studio .NET, ASP.NET, increased reliance on XML, and a host of other new programming tools and platforms.

The .NET execution framework reminds many people of Java's model. In order for a Java applet to run, it must be executed in a Java Virtual Machine (JVM) environment. .NET executables (regular Windows 32-bit Portable Executables) run on top of a similar environment called the Common Language Runtime or CLR. This is what you are installing when you install the Microsoft .NET Framework component. The CLR runtime engine performs security checks, does type checking, checks memory pointers, loads other component dependencies, and Just-In-Time (JIT) compiles the platform-independent source code into executable code. And further, there are intermediate source code representations (called Microsoft Intermediate Language or MSIL), class files, class loaders, and separate treatment between trusted and untrusted code. Untrusted code is sandboxed and prevented from accessing or risking system resources. This should sound a whole lot like Java to anyone.

I bring up this comparison because .NET is more complex than Java, and complexity doesn't mix well with security. I often hear that Java is very secure because it has only had one widespread in-the-wild exploit. I love Java and the people who designed it did so with security as top priority. But the truth is that Java has had dozens of security holes patched since its release. Just because the white-hatters are the ones finding them doesn't make it a secure platform. Many Java exploits have been found by breaking assumptions between its mesh of interoperating components. See, in order for Java security to work, all the components must work 100% of the time. If one fails, they all fail. Because .NET's execution model is roughly similar, it isn't a hard stretch to believe that many holes will be found in .NET.

Web Services

Web services are the reason for all the complexity. Web services are XML applications, interfaces, and data, designed to be shared across multiple platforms around the Internet. A web service might be a single application hosted by an Application Service Provider (ASP) or it could be a combination of several different vendor's web services making up one application experience for the user. For example, consider a typical online transaction such as buying a pair of jeans. You may use one web service to authenticate your login to the manufacturer's web site, another to help get you the perfect fit, and another to determine delivery details and payments.

Microsoft's Passport was the first example of a web service. Passport allows you to use a single login name and password for all web sites that support Passport authentication. It has tens of millions of users and it has had a series of security issues over the years. In one such instance in May of this year, it was discovered that a remote attacker could send a rather trivial, malicious URL to hotmail.com, be able to change anyone's password and take over the passport account. Maliciously altered Passport accounts can be used to buy goods online and to view confidential data.

The idea that a single, widespread web service with a vulnerability that can immediately expose tens of millions of people to new threats has security experts paying attention. Today's conventional worms and viruses are infecting millions of computers in ten minutes. But a crafty web service worm could potentially conduct millions of falsified commercial transactions in a matter of minutes, something a MS-Office macro virus can't hope to do.

The complexity and popular use of .NET's execution model worries security experts. The widespread sharing of applications, code, and data around the Internet is bound to culminate in interesting future exploits. Lucky for us so far, .NET exploits have been limited to some 'growing pain' problems with Microsoft Passport and a few worms and viruses.

.NET Viruses

There are already at least three .NET worms and viruses: Donut, Serot and Sharpei. Donut, discovered on January 9, 2002, was the first .NET virus. Sent only to researchers as concept malware, the buggy Donut attempts to infect all the .EXE files in the current folder and up to 20 folders above it. It contains a never-executed payload display message and only a small amount of MSIL code. It is mostly normal 32-bit assembly language and the .NET files it infects are turned into regular looking PE files. Donut was the first .NET virus, but it only had a short lead on the others.

Donut was quickly followed up by the Serot, worm which arrives as an impersonated email from support@microsoft.com. It infects all .NET (MSIL) .EXE files on drive C: and will attempt to send itself to all email addresses in the Windows Address Book and those it finds in the Internet Explorer cache folder. Like the virus that followed it, Serot contains a VBS file that does the mass mailing effort. This appears to be easier to do in a script language for the crackers than in MSIL. Serot attempts to terminate antivirus processes on infected PCs and contains a plug-in architecture similar to the one successfully used in the Hybris worm.

Then the Sharpei virus was discovered on February 26, 2002. It arrives in email pretending to be a Microsoft patch, MS02-010.EXE. Written in C#, it drops a Sharp.VBS file that sends itself to all contacts in the Microsoft Outlook address book. After messages are sent, the evidence is deleted from the Sent Items folder in Outlook.

Both the Sharpei and Donut viruses are direct action infectors, meaning they execute and do their damage upon running, and then exit until the next execution. All three "concept" programs have their problems and are unlikely to spread far. Antivirus researchers expect the future to bring memory-resident .NET viruses.

Note: Peter Szor, with Symantec, did detailed write-ups on Donut and Sharpei for the Virus Bulletin publication. You can visit www.peterszor.com or www.virusbtn.com for detailed reading on .NET infections.

Because all three .NET malware programs are very buggy and require .NET to be installed, none spread very far outside research laboratories. But a crucial point, that malware writers are ready to exploit the .NET framework, has been proven. It won't be a five-year wait this time. Meanwhile, new features in other Microsoft platforms have raised concern among AV experts.

Windows XP Concerns

Windows XP has an improved model of NT's HAL, kernel, and user mode processes. Overall, with XP and Server 2003, Microsoft has increased the stability and security of their operating systems. True, Internet Explorer and Outlook continue to be the weak points in Microsoft's Trustworthy Computing initiative, but their core operating systems are becoming more secure out of the box. At the same time, Microsoft cannot resist (and consumers demand) new features, and XP has plenty of those. Some have been exploited, most haven't...yet. The next part of this article will briefly discuss the new feature XP sets that concern computer security analysts.

Windows Media Player

It used to be that you only had to worry about malicious executable content. Data was data was data, and it could not be launched as an attack. Times change and data content is often exploited in today's multimedia world. The content itself can be used maliciously, in a buffer overflow or through embedded script languages. Another common ruse is for the file to have a header claiming it is one type of file, but instead it contains something completely different, bypassing security-checking mechanisms. The multimedia program itself is often used for the attack. If the interface allows scripting or "skin" updating, rogue coders can instruct the program to do things that would otherwise be constrained by one of Internet Explorer's security zones.

Microsoft's Windows Media Player is installed by default on every version of Windows. The original release of XP came with version 8.0, although anyone can upgrade to version 9 for free. Several holes have been found with the Windows Media Player over the last few years, and Microsoft has patched them when reported. The older versions of Windows Media Player have more security holes than the newer versions, but many people are hesitant to upgrade because of their bulkiness and the restrictive Digital Rights Management features of the newer versions. To be fair to Microsoft, let's not forget that Flash files, RealPlayer, Winamp, and just about every other popular media distribution content has be found to have one or more exploit holes over the past year. But network administrators would appreciate it if Windows Media Player was not installed by default and upgrades were not offered to end-users via Windows Update when it has been removed on purpose.

WebDAV (Web Digital Authoring and Versioning)

WebDAV is a feature installed on machines with XP or IIS 5, or greater. WebDAV is a HTTP protocol extension that allows users to publish and collaborate on documents that are stored on the web. Contrary to common belief, WebDAV is a popular open standard and not just a Microsoft feature. There have been a handful of exploits against Microsoft's implementation of WebDAV, including DoS and buffer overflows. The biggest problem with WebDAV is that it is installed and turned on by default when most people don't use it. It's a good, powerful collaboration tool, it just needs more security analysis and should not be turned on by default. WebDAV is not turned on by default on Server 2003 and IIS 6.

Remote Desktop Connection

Remote Desktop Connection allows one XP Pro PC to remotely connect and control another XP Pro PC with a PC Anywhere-style session. Remote Desktop, as it is called in the System Control Panel applet, uses Terminal Server's Remote Desktop Protocol (RDP) over TCP port 3389. It is not turned on by default, and so far has not been exploited. Still, knowing that it is installed as an inactive shell on every Windows XP computer, many of which are poorly secured, raises some concerns.

Remote Assistance

Unlike Remote Desktop Connection, Remote Assistance is turned on by default. It allows one XP user to invite, using either email or instant messaging, another XP user to have remote control access over their PC. Besides desktop control, the remote user can participate in chat sessions and transfer files. Invitations can be open for many days, and the default is 30 days. One of the main concerns is that there is no vetting mechanism to guarantee who is who in the remote assistance scenario. There exists the possibility that a malicious remote user may impersonate a tech support person and plant malicious files. While there have been no public exploits using Remote Assistance, AV experts worry about poorly password protected connections and buffer overflow attacks.

Internet Connetion Firewall (ICF)

Microsoft's first attempt at a desktop firewall is laudable, but comes up a bit short. ICF's main deficiency is that it lacks the ability to block outgoing port traffic. Many malware programs, once installed, will initiate outbound communications to continue their maliciousness. It could be a remote access trojan contacting its originating hacker to advertise the successful intrusion or an email worm with its own SMTP engine sending itself out around the world. In either of these two cases, because ICF allows all outgoing requests by default, the end-user will not be warned. Most of today's personal desktop firewalls would stop the request and alert the user. I hope if Microsoft continues to support ICF as firewall product that additional features sets will be added and its usefulness increased. ICF is also installed on Server 2003.

UPnP

Universal Plug and Play is another feature that should be turned off by default. UPnP allows a Windows machine to discover UPnP devices (ex. printers, scanners, etc.) on the network and to auto-configure their use. UPnP ended up being XP's first big publicly touted hole in December 2001. It was a buffer overflow and could be successfully exploited over the Internet, and if a firewall did not block UDP port 1900, it could be used to gain complete control of the machine. Luckily, UPnP is not even installed on Microsoft's latest offering, Windows 2003.

Simple File Sharing

XP the Home Edition has a feature called Simple File Sharing. When a folder is shared, it is immediately accessible to everyone on the local network and no specific permissions can be set. The folder can be set as read-only, but if changes are allowed, full control is given to anyone who can see the folder. AV experts worry that if a virus or worm gets loose on a home network with Windows XP Home, the malware will have no problem traveling machine to machine using network shares

Windows Messenger

Microsoft's Windows Messenger is installed by default on XP Pro and Home editions. Instant messaging (IM) clients open additional avenues for attacks. First, there have been many buffer overflow attacks against instant messaging clients, even when not turned on and only installed. Second, IM clients allow yet another avenue for the unsuspecting Joe User to receive malicious files. Many antivirus programs do not monitor IM file transfers. Third, there are malicious programs and viruses that specifically target Microsoft's IM clients. Although not attacked nearly as much as IRC and AOL's AIM clients, instant messaging is a technology being used before the security is all in place.

Office XP

Although only affiliated with Windows XP by name only, here's a good point to discuss a potential security problem in Microsoft Office XP. One of the most touted features of Office XP is its ability to read and write files in XML format. Macro viruses, which for several years were the number one infection type, have been mostly tamed by Office's macro security and antivirus software. XML has the potential to allow yet another round of new technology viruses into our Office documents. This is because XML is an everyman's language. An XML file is what you define it to be. Besides text, it can contain executable code, scripting, multi-media content, whatever programmers might want it to contain. As has been proven so many times in the past, flexibility and choice increases the risk of malicious exploitation.

I'm sure there are some features I missed that may be exploited in the future, but at the moment these are the main ones garnering increased scrutiny by security professionals.

Windows XP Security

Before this paper ends, I want to point out that security has been strengthened in Windows XP, and much more so in Windows 2003. XP was the first Microsoft operating system to offer a firewall (ICF), and it's better than nothing for the consumer that isn't motivated to install another vendor's personal firewall product. XP has Encrypted File System (EFS), Windows File Protection (WFP), Certificate Services, IPSEC, Kerberos, Software Restriction Policies, and System Restore. All of these additional features fight malicious code and are welcome additions to the Microsoft family. All security reviews of Server 2003 have been positive. More unnecessary features have been turned off by default and file and registry settings strengthened.

Summary

The complexity of the .NET execution platform worries security experts. Once it is widespread, malicious coders will find holes in between the interoperable layers and then execute security exploits. The persuasive nature of web services means that one malware threat could quickly compromise a large number of machines. There are already three .NET viruses and worms. Although they are buggy, future viruses and worms will be able to perform without error as crackers begin to target .NET.

Windows XP contains much new functionality, some of which has been exploited, and other features which have yet to be maliciously explored. XP also contains many new security features, like Windows File Protection and Internet Connection Firewall, which strengthens the OS's response to security threats.

Roger A. Grimes, CPA, MCSE (NT/2000), CNE (3/4), A+, has been fighting malicious code since 1987 and is the author of Malicious Mobile Code: Virus Protection for Windows (O'Reilly). He is a frequent writer and speaker on computer security topics. His next book, Honeypots for Windows (APress) will be available near the end of the year.

Source : http://securityfocus.com

Malware Analysis for Administrators

2007-08-26T08:54:00.000-07:00

1. Introduction
The threat of malicious software can easily be considered as the greatest threat to Internet security. Earlier, viruses were, more or less, the only form of malware. Nowadays, the threat has grown to include network-aware worms, trojans, DDoS agents, IRC Controlled bots, spyware, and so on. The infection vectors have also changed and grown and malicious agents now use techniques like email harvesting, browser exploits, operating system vulnerabilities, and P2P networks to spread. A relatively large percentage of the software that a normal internet user encounters in his online journeys is or can be malicious in some kind of way. Most of this malware is stopped by antivirus software, spyware removal tools and other similar tools. However, this protection is not always enough and there are times when a small, benign looking binary sneaks through all levels of protection and compromises user data. There may be many reasons for this breach, such as a user irregularly updating his AV signatures, a failure of AV heuristics, the introduction of new or low-profile malware which has not yet been discovered by AV vendors, and custom coded malware which cannot be detected by antivirus software. Though AV software is continually getting better, a small but very significant percentage of malware escapes the automated screening process and manages to enter and wreak havoc on networks. Unfortunately, this percentage is also growing everyday.

It is essential for users and absolutely essential for administrators to be able to determine if a binary is harmful by examining it manually and without relying on the automated scanning engines. The level of information desired differs according to the user's needs. For instance, a normal user might only want to know if a binary is malicious or not, while an administrator might want to completely reverse engineer the binary for his purposes.

Traditionally, malware analysis has been considered to be very complicated, and in fact some of the techniques are still very complicated and beyond a normal user's access. Nevertheless, looking at the current scenario, we can see that there is a clear need for people to learn how to analyze malware themselves. But the caveat is that the analysis techniques have to be simplified and the learning curve has to be made smaller for mass consumption among the general public. Unfortunately, there is not much organized information in the public domain dealing with easy to use malware analysis techniques. This paper tries to fill this void. The focus is on malware reversing but these techniques can be applied to reverse engineer any binary.

Besides the uses mentioned above, malware analysis is used for forensics, honeypot research, security vulnerability research, etc.
2. Background, goals, assumptions and tools
2.1 Background
There are basically two broad categories of techniques that are used for analyzing malware: code analysis and behaviour analysis. In most cases, a combination of both these techniques is used. We will consider code analysis first.

Code analysis is one of the primary techniques used for examining malware. The best way of understanding the way a program works is, of course, to study the source code of the program. However, the source code for most malware is not available. Malicious software is more often distributed in the form of binaries, and binary code can still be examined using debuggers and disassemblers. However, the use of these tools is often beyond the ability of all but a small minority because of the specialized knowledge required and the very steep learning curve needed to acquire it. Given sufficient time, any binary, however large or complicated, can be reversed completely by using code analysis techniques.

On the other hand, behaviour analysis is more concerned with the behavioural aspects of the malicious software. Like a beast kept under observation in a zoo, a binary can be kept in a tightly controlled lab environment and have its behaviour scrutinized. Things like changes it makes to the environment (file system, registry, network, etc), its communication with the rest of the network, its communication with remote devices, and so on are closely observed and information is collected. The collected data is analyzed and the complete picture is reconstructed from these different bits of information.

The best thing about behaviour analysis is that it is within the scope of an average administrator or even a power user. The learning curve is very small and existing knowledge can be leveraged to make the learning process faster. This makes it ideal for teaching newbies the art of malware reverse engineering. These reasons are consistent with our stated goals, focused on the typical administrator, and therefore this paper is mostly concerned with behaviour analysis.

Though reverse engineering using behaviour analysis does not lead to the complete reversing of a binary, it is sufficient for most users' needs. For instance, it is not sufficient for an antivirus researcher but for most other users, behaviour analysis can fulfill all their needs.
2.2 Goals in the analysis
As stated before, our goal is to provide a set of behaviour analysis techniques for reverse engineering malware. Also, the learning curve should be small so that it is within the scope of most people.

Using these methods, people should be able to analyze an unknown binary and determine whether it is malicious or not. Those who require more in-depth knowledge should be able to reverse engineer the binary, understand and document its workings completely.
2.3 Assumptions and definitions
This paper makes a few assumptions for the sake of convenience and clarity. These are:

1. We assume that the malware under consideration is a Win32 based binary on an Intel x86 machine. This is just for the sake of clarity. The basic principles can be just as easily applied to any other platform.
2. We sometimes refer to the malware as "the binary". This does not however mean that the principles are applicable only to a malicious application that is composed of a single binary.
3. The host machine on which the binary is executed is referred to as the "victim host" or the "victim machine".
4. The other machine on the test network is referred to as the "sniffer machine".

2.4 Tools
Since the goal of this paper is to propose a generic set of techniques, the tools mentioned in this paper are just "proposed" tools and are available as references at the end of this document. Any other tool that has the same or similar functionality can be used in place of the proposed ones.
3. Methodology
The framework proposed is broadly divided into six stages. They are:

1. Creating a controlled environment
2. Baselining the environment
3. Information collection
4. Information analysis
5. Reconstructing the big picture
6. Documenting the results

3.1 Creating a controlled environment
The setting up of a controlled and sanitized environment is absolutely essential for analyzing malware. A special "test lab" is created for this purpose. Some essential features of the test lab are:

* At least two machines should be used. One machine is for hosting the malicious binary (victim machine) and the other is for baselining and sniffing the network traffic (sniffer machine). They should be networked in such a way that each of them is able to sniff the other's network traffic.
* The two networked lab machines should be isolated from the rest of the network.
* Fresh copies of Operating Systems should be installed on each of the two machines. It is preferable to have a WinNT kernel family OS on one machine and a *nix based OS on the other. Since we are assuming a Win32 binary, the WinNT machine acts as the "victim host" and the *nix machine is used as the "sniffer machine".
* Tools should be transferred to the relevant machines.
* The binary that is to be examined should be transferred to the relevant machine. Since we are assuming a Win32 binary, it is transferred to the Win32 machine in this case.
* It is highly preferable not to install any other application upon the "victim host" apart from the tools required for analysis.

This is the most basic setup for a malware analysis lab. Apart from this and depending on the situation, more modifications can be carried out. For instance, if the malicious binary tries to communicate with a remote server xyz.com, a DNS server has to be setup in one of the lab machines and a DNS entry for xyz.com has to be created. An excellent paper that discusses the creation of a malware analysis lab is "An Environment for Controlled Worm Replication and Analysis".

We may have to return to this "creating a controlled environment" stage many times during the analysis process. Sometimes, in the light of new information generated during the later stages, the lab will have to be tweaked and modified.
3.2 Baselining the environment
Baselining the environment is the next major step. "Baselining" means taking a snapshot of the current environment. This is the most vital stage in our analysis. If baselining is not done properly, it has a serious effect on the information gathering stage, which in turn seriously effects our understanding of the binary. If baselining is done efficiently, the information generated during the next stage becomes very accurate and the rest of the stages become easy to execute.

To accomplish our goals, the binary which is to be analyzed is executed in a controlled environment and the changes it makes to that environment are captured. Before executing the binary, a snapshot of the environment is created (baseline) and then after execution another snapshot is created. In theory, the difference between the baseline and the final snapshot gives the changes made by the binary.

The elements of the environment that have to be baselined are:

3.2.1 Victim machine
Some of the elements that are to be baselined in the Victim Machine are:

o Filesystem: The file system on the victim host has to be baselined. There are many programs that can create a snapshot of the file system and after a few changes occur, they can point out the modifications. Some of the programs we can use are Winalysis and Installrite.
o Registry: The registry is the next component that is to be baselined. Most malware applications rely on registry entries. Therefore it is crucial to capture registry modifications. Winalysis as mentioned above is one of the available programs that can be used for registry baselining.
o Running processes: A snapshot of the running processes can be created using a number of programs. Some of them are available from Sysinternals.
o Open Ports: A snapshot of the open ports can be created using the 'netstat' utility. However, it does not list the name of the process that is tied to the port. For this, we can use Fport available from Foundstone.
o Users, Groups, Network Shares and Services are some of the other elements that should be baselined.
3.2.2 Network traffic
The next element that has to be baselined is the network traffic. Even when there is no application running on either of the test machines, there will still be some network traffic. This traffic has to be recorded and the "normal traffic" in our test network has to be defined. This is because when deviations occur in the "normal traffic" pattern, we can assume it to be generated by the binary and perform further testing on it.

Sniffing software that is installed on our "sniffer machine" is used for this purpose. Any sniffing software running in verbose mode is sufficient for our purposes. However, to make our task easier, it is preferable to use a protocol analyzer like Ethereal.
3.2.3 External view
Although we have created a snapshot of the open ports in the victim machine, it is always better to create one more snapshot from an external machine. A port scanner running on our "sniffer machine" can achieve this task for us. It goes without saying that Nmap will be the port scanner of choice for most users.

3.3 Information collection
Now that the preparations are over, we can go ahead with our task. This is the only stage where we have an actual interaction with the binary. A lot of raw information about the binary is collected during this stage which is analyzed in the next stage. Therefore, it is very important to carefully record all the information generated in this stage. The steps in the information collection stage are:

3.3.1 Static analysis
During the static analysis stage, we collect as much information about the binary as possible, without executing it. This involves many techniques and tools. Static analysis reveals the scripts, HTML, GUI, passwords, commands, control channels, and so on. Simple things like the file name, size, version string (right-click>properties>version in Win32), are recorded.

Human-readable strings are extracted from the binary and these strings are recorded. A program like Binary Text Scan can be used for this purpose. These strings reveal a lot of information about the function of the binary.

Resources that are embedded in the binary are extracted and recorded. A program like Resource Hacker can be used for this purpose. The resources that can be discovered through this process include GUI elements, scripts, HTML, graphics, icons, and more.
3.3.2 Dynamic analysis
During this stage, we actually execute the binary and observe its interaction with the environment. All monitoring tools including the sniffing software are activated. Different experiments are done to test the response of the running malware process to our probes. Attempts to communicate with other machines are recorded. Basically a new snapshot of the environment is created like in the baselining the environment stage.

After taking a snapshot of all the changes the binary performs in the system, the binary process is terminated. Now, the differences between the new snapshot and the baseline snapshot are determined. The dynamic analysis step is very similar to the baselining the environment stage. Therefore, the tools are reused for this stage. Winalysis and InstallRite can be used for this purpose. Apart from these tools, Filemon and Regmon from Sysinternals can be used for monitoring the file system and the registry dynamically. These tools are used for observing the changes to the file system and the registry.

This information is recorded and forms the input for the next stage of our analysis. The information generated here can be new files, registry entries, open ports, etc.

Sometimes, the static analysis step has to be repeated once more after doing a dynamic analysis.
3.4 Information analysis
This is the stage where we can finally reverse engineer the binary based on all the information collected during the previous stages. Each part of the information is analyzed over and over and the "jigsaw puzzle" is completed. Then the big picture automatically begins to appear and the reverse engineering process is finished. However, before this is achieved, we may have to repeat the previous stages (See figure) several times.

The goals of the individual or organization evaluating the binary determine the type of analysis and because the goals differ, no standard methodology is provided for this stage. Looking for deviations from the stated security policy of an organization based on the information can be the determining factor in some cases.

Although a complete methodology for information analysis is beyond the scope of this paper, a few techniques are presented here. In many cases, these techniques are sufficient for analysis.

3.4.1 Internet searches
A search engine can be used for searching for more information on the binary. Keywords for the search engine can be drawn from the information generated during the "Static Analysis" step during the previous stage. Things like filenames, registry entries, commands, etc. often reveal a lot of information about the malware. Some good sources of information on the internet include Online Virus Databases (mostly maintained by Antivirus Vendors), News Groups and Mailing Lists. Many times, internet searches reveal almost all there is to know about the malware and no further research is needed.
3.4.2 Startup methods
Every malware needs a way to ensure that it is executed when a system reboots. This is the most vulnerable aspect of the malware. There are only a limited number of ways in all operating systems that a program can use to restart automatically when a machine reboots. The information collected during the previous stage can be analyzed to identify the startup method of the malware. A very good source for Startup Methods related information on the Internet is the Paul Collins' Startup List.
3.4.3 Communication protocol
A network protocol analyzer like Ethereal in many cases can identify the communication protocol used by the binary. When this is not the case, the protocol has to be reverse engineered. This is beyond the scope of this document.
3.4.4 Spreading mechanism
If the malware under scrutiny is a self-spreading worm or virus, the collected network traffic data will easily reveal its spreading mechanism. In most cases, a cursory glance is enough.

3.5 Documenting the results
Documenting the results of the malware analysis and reverse engineering exercise is essential. One of the main advantages is that the knowledge incorporated into the documentation can be leveraged for later analysis exercises. The documentation needs differ from individual to individual and organization to organization. The method preferred by the concerned party can be used here.
4. Conclusion
From this article we've seen that a basic behavioral analysis of a binary can be easily performed by an administrator, or indeed by a power user. While this approach does not give the same level of detail as code analysis would, it is sufficient for most people's needs when figuring out what a potentially malicious binary is capable of.

About the author

S.G.Masood is the founding CTO of the Chicago, Illinois based application security startup Circle Technologies. He currently stays in Hyderabad, India and manages the development center.

References

"An Environment for Controlled Worm Replication and Analysis" by Ian Whalley Bill Arnold, David Chess, John Morar, Alla Segal, Morton Swimmer - www.research.ibm.com/antivirus/SciPapers/VB2000INW.htm

"Reverse Engineering Malware" by Lenny Zeltser - www.zeltser.com/sans/gcih-practical/revmalw.html

"Paul Collins' Startup List" - http://www.sysinfo.org/startuplist.php

Archives of the various security and malware related mailing lists, most notably, Bugtraq, Full-Disclosure, Focus-Virus, Incidents.

VMWare - www.vmware.com

Winalysis - www.winalysis.com

Installrite - www.epsilonsquared.com

Fport - www.foundstone.com

Nmap - www.insecure.org

Binary Text Scan - netninja.com/files/bintxtscan.zip

Resource Hacker - www.users.on.net/johnson/resourcehacker/

Filemon and Regmon - www.sysinternals.com

Ethereal - www.ethereal.com

Source : http://securityfocus.com

Recent Security Enhancements in NetBSD (Part 2)

2007-08-26T08:21:00.000-07:00

On one hand, some would claim that exploit mitigation discourages developers from writing secure code and vendors from quickly responding to security incidents: they know there's a safety net guarding them, and so they pay less attention to security when writing code, or taking their time coming up with fixes for security issues.

On the other hand, however, this is also where exploit mitigation technologies excel: they introduce the concept of preventing the successful exploitation of security vulnerabilities, even before a fix is available. Moreover, they prevent entire classes of bugs, and don't require constant updating.

2.2.3 Architectural Integration
So far, the previous two approaches assume the cause of a security breach is a bug in the code that is being exploited. The first approach tries to eliminate such bugs, and the second one tries to make it next to impossible to successfully exploit them. However, some environments require more than just that - for example, the ability to define detailed usage policies and associate them with entities on the system became a mandatory part of many security policies. In our context, we can relate that to the Unix permissions model; simply put, due to the coarse separation between a normal user and a superuser, it cannot be used to express many security policies as detailed as may be required.

That led to the research of various modern security models, of which most recognized ones are fine-grained [ref 5] discretionary access controls (DACs) and mandatory access controls (MACs). To put things simple, DACs focus on the data owner's ability to specify who can use it and for what; MACs focus on a mandatory policy that affects everyone.

These systems allow an administrator - and where applicable, the users - to specify fine-grained policies; effectively, this means that a user or a program can be made to work with the minimal amount of privileges required for their operation (which, as implied above, cannot be done with the traditional Unix security model), resulting in damage containment in case of compromise or otherwise minimized impact from security vulnerabilities.
2.2.4 Layered security
To itself, layered security [ref 6] is not a single approach. Where any of the previous three took a different route, the layered security approach suggests that maximized security can only be achieved by combining efforts on all fronts: code auditing is important, but does not come in place of useful exploit mitigation technologies; and architectural integration, of course, has little to do with any of them.

Although the above may sound obvious, it is not too often when you see an operating system that puts an emphasis on all three aspects; it will usually be the case that only one of the approaches is fully practiced. Following are some short case-studies that illustrate the importance of each approach by using real-world examples.
2.2.5 Case Studies
Shortly after splitting from NetBSD in 1995, OpenBSD became widely known for its unique - at the time - approach to security: proactive code auditing. Instead of retroactively responding to security issues, OpenBSD developers performed thorough code auditing sessions, sweeping for bugs. This act proved itself more than once, after vulnerabilities found in other operating systems were already fixed [ref 7] in OpenBSD.

This, however, did not last too long. In 2002, winds of change blew through the OpenBSD mindset: the long standing fort of code auditing fell, adopting exploit mitigation technologies to its lap [ref 8]. While the reasons behind the move were not published, some speculate that it was the release of an exploit allowing full system compromise of OpenBSD's default configuration [ref 9] that finally proved that even a group of dedicated programmers cannot find all bugs; at least not first.

Said exploit mitigation technologies made their public debut around 1996, with the appearance of the Openwall [ref 10] project, and later evolved dramatically by the PaX [ref 11] project in 2000. Research done in both projects formed the basis of today's exploit mitigation technologies. Another commonality of the two was that they offered an implementation based on Linux - which only makes one wonder why it was OpenBSD that was the first to officially adopt these technologies.

Linux, however, took a different direction. First with the addition of POSIX.1e [ref 12] capabilities in 1999, fine-grained discretionary access controls, later with SELinux [ref 13], an implementation of mandatory access controls, and finally with the introduction of the Linux Security Modules framework [ref 14], abstracting the implementation of both, Linux focused mainly on offering means for an administrator to define a detailed security policy, hoping to minimize the effect of a vulnerability.

Not lagging behind too much, though, exploit mitigation technologies also appeared in the official Linux kernel during 2004-2005; in fact, they also made an entrance to the official Windows world with Windows XP SP2 [ref 15], and Windows Vista is expected to include even more such technologies [ref 16].

Simply put, all three major approaches have been practiced by widely used operating systems at one point or another. It is clear to see that although initially a single approach was chosen, eventually it was understood that layered security is the key to stronger defense of computer systems.
2.3 The NetBSD Perception of Security
Learning from others’ experience, the approach taken by NetBSD employs three main principles:

* Simplicity. There is no point in providing a feature, whether it’s a kernel subsystem or a userland tool, if it’s not intuitive and easy to use. Furthermore, overly complex code is harder to audit, which may lead to additional bugs.
* Layered security. It is well understood that there is no single solution to security. NetBSD addresses security from a variety of angles, including code auditing, adequate and extensible security infrastructure, and exploit mitigation technologies.
* Sane defaults. Accepting that security may not be the highest priority for all users, NetBSD provides sane defaults to fit the common case. Detailed supplementary documentation helps enable and configure the various security features.

Using the above guidelines, a variety of security solutions were evaluated to address different threat models. With emphasis on implementing a solution that would fix a real problem and provide an intuitive and easy to use interface (when one is required), a variety of changes - ranging from tiny hooks, through additional kernel subsystems, to architectural modifications, NetBSD has made important first steps in improving its overall security.

[ref 5] I emphasize fine-grained because DACs already exist on Unix; however, as noted, they are too coarse.
[ref 6] Also known as Defense in Depth.
[ref 7] http://www.openbsd.org/security.html#process
[ref 8] http://www.monkey.org/openbsd/archive/misc/0207/msg01977.html
[ref 9] http://www.securityfocus.com/news/493
[ref 10] http://www.openwall.com
[ref 11] http://pax.grsecurity.net
[ref 12] http://wt.xpilot.org/publications/posix.1e/
[ref 13] http://www.nsa.gov/selinux/papers/module/t1.html
[ref 14] http://www.kroah.com/linux/talks/usenix_security_2002_lsm_paper/lsm.pdf
[ref 15] http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2mempr.mspx
[ref 16] http://blogs.msdn.com/michael_howard/archive/2006/05/26/608315.aspx

Source : http://securityfocus.com

Recent Security Enhancements in NetBSD (Part 1)

2007-08-26T08:16:00.000-07:00

1. Introduction
Running on almost twenty different architectures, and easily portable to others, NetBSD gained its reputation as the most portable operating system on the planet. While that may indicate high quality code, the ever demanding networked world cares about more than just that. Over the past year, NetBSD evolved quite a bit in various areas. This paper, however, will focus on those aspects relating to security.

This paper was written and structured to present a full overview of the recent security enhancements in NetBSD in an easily readable and balanced form that will satisfy new, intermediate, and experienced users. References were sprinkled across the text to provide more information to those who want more detail, while preserving the continuity.

Following this introduction, the paper is presented in five major sections, spread over eight pages. Section 2 presents the bigger picture of security in NetBSD: how NetBSD perceives security, the design decisions of NetBSD software in general and the security infrastructure and features more specifically. Section 3 presents a detailed overview of the recent enhancements in the security infrastructure and features of NetBSD including, where relevant, details about the design, implementation, and possible future development. Section 4 shows current security-related research and development in NetBSD, and then section 5 discusses how the described enhancements work together to provide a more secure platform. Section 6 concludes the paper, and summarizes the availability of the discussed features.
2. The Tao of NetBSD Security
We are all familiar with the mantra that security is a process, not a product. When we consider software development, specifically operating systems, it should be part of the design from the ground up. As the descendent of an operating system over 20 years old, NetBSD carries a security model designed and implemented with different threats in mind; the Internet was smaller, more naive, and less popular.

The following sections will provide background to the approaches taken to enhance the security of the NetBSD operating system: the considerations, existing approaches, and case-studies.
2.1 Considerations
When investigating the enhancement of security in NetBSD, two of the most important leading principles were maintaining compatibility and interoperability [ref 1]. Presenting changes that would dramatically impact the user-base was out of question, and careful planning had to be done. In addition, any change to an underlying back-end had to be well thought-out so it maintains existing semantics without enforcing them during the design stage.
2.2 Security Approaches
Operating system security is nothing new, and NetBSD is not the first to address the issue. In designing software, and security software in particular, it is mandatory to learn from the experience of previous work. Below are some common approaches to security and real-world case studies.
2.2.1 Code Auditing
Code auditing addresses security issues by looking for programming glitches in the source code of the program, often with the assistance of automated tools [ref 2]. Normally the work of vulnerability researchers, when done proactively by the programmers themselves, code auditing has the potential of locating and fixing bugs that have security implications before anyone else finds and exploits them.

While some would argue that striving to produce bug-free code is the one true way of achieving security, this view is a fallacy for two main reasons. The first is that security issues are not always the result of programming errors; while code auditing tries to ensure no software bugs will be maliciously exploited because said bugs would simply not exist, it alone ignores other important aspects, such as configuration errors and user behavior policies.

The second reason is that it is not possible to write bug-free code [ref 3]. Over the past decade, awareness on writing secure code rose significantly; automated tools evolved, allowing easy pinpointing of software bugs; open-source software is available for the review of thousands - if not millions - of people. Yet, we still see new security vulnerabilities on a daily basis. Some of those, ironically, are of the exact same type that affected us ten or twenty years ago [ref 4].
2.2.2 Exploit Mitigation
The unorthodox approach of exploit mitigation addresses bugs from the opposite direction of code auditing: instead of looking for them in and removing them from software to make it more secure, it adds bugs to the exploit code to prevent it from working. While that may be over-simplified, the purpose of exploit mitigation technologies is to interfere with the inner-workings of the exploit, eliminating the - often unusual - conditions that make it work.

[ref 1] Two other leading principles - not impacting the system performance and an easy user interface, will not be discussed in this paper.
[ref 2] Coverity, for example, offered its services to various open-source projects, including NetBSD, for free. See http://scan.coverity.com
[ref 3] http://www.cs.columbia.edu/~smb/papers/acm-predict.pdf
[ref 4] http://www.cert.org/homeusers/buffer_overflow.html

Source : http://securityfocus.com

Analyzing Malicious SSH Login Attempts

2007-08-26T08:09:00.000-07:00

Introduction
Malicious SSH login attempts have been appearing in some administrators' logs for several years. This article revisits the use of honeypots to analyze malicious SSH login attempts and see what can be learned about this activity. The article then offers recommendations on how to secure one's system against these attacks.
Using honeypots for research
The New Zealand Honeynet Alliance is a research organization and member of the Honeynet Alliance, which is dedicated to improving the security of computer systems and networks by researching the behavior, tactics, and tools of black hat hackers through the use of honeypot technology. Honeypots are computer systems whose value lies in their openness to attack and compromise, allowing the researcher to analyze malicious activity on the system.

We have set up such a system at the Victoria University of Wellington to investigate malicious activity that occurs on a university network in New Zealand. This system was a high interaction honeypot that an attacker can interact with like any other system on the network. As far as the attacker is concerned, there should be no discernible difference between the honeypot and other computer systems. However, it is closely monitored through the Honeynet Alliance Roo honeywall that captures all network traffic flowing to and from the honeypot. In addition, system events are recorded on the honeypot itself via its logging facility.

The honeypot ran a standard server configuration of RedHat 9 with a Secure Shell (SSH) server that was accessible via the public Internet. SSH is a program that allows a user to log into another computer over a network via an encrypted channel. After we encountered malicious SSH login attempts in previous setups, we configured our honeypot to allow for additional data collection. We patched the SSH server to record the password along with the account name that was used in the login attempt. The honeypot was brought online on July 11, 2006 and taken offline on August 1, 2006, after 22 full days. The honeypot was attacked numerous times during this period with login attempts on SSH. We take a closer look at the data to determine the tactics of the attackers and to make recommendations to improve security around SSH.

In an additional configuration of the honeypot, which ran from June 28 to July 4, we added the Sebek module that records key strokes of the attacker once the system has been compromised. We configured several user accounts with commonly used passwords. After a few days, an attacker successfully compromised the system. The analysis of this attack and subsequent attacks are presented in this paper and provide us with further insight into how the malicious SSH login attempts are used to compromise systems.
Analysis of SSH Login Attempts
This section analyzes the data captured by our honeypot from July 11 to August 1. The analysis is entirely based on data of system log files of the honeypot, in particular the ‘messages’ log. The ‘messages’ log captures authentication requests to the SSH server. It captures date, time, the IP address from which the login attempt originated, the result of the request (failure or success), the account name and the password used for the authentication request. Two ‘messages’ sample log entries are shown below.

Jul 13 09:37:59 basta sshd[22308]: PW-ATTEMPT: fritz
Jul 13 09:37:59 basta sshd[22308]: Failed password for root from 10.0.160.14
port 39529 ssh2
Jul 13 09:38:02 basta sshd[22310]: Illegal user fatacunike from 10.0.160.14
Jul 13 09:38:02 basta sshd[22310]: PW-ATTEMPT: fatacunike
Jul 13 09:38:02 basta sshd[22310]: Failed password for illegal user fatacunike
from 10.0.160.14 port 40444 ssh2

First, we analyzed the login names that were used on the login attempts. During the sample period, there were 2741 unique account names ranging from common first names, system account names, and common accounts to short alphabetical strings captured by the system logger. Of those, the 15 account names used most often are shown in Table 1. This table shows accounts that usually exist on a system (root, mysql), accounts that are likely to exist on a system (guest, test), as well as common first names (paul). Then Figure 1 shows the distribution of valid and invalid account names that were used.

It comes as no surprise that the invalid account names used far surpass the valid account names. However, we note that 96.30% of all default account names that exist on the honeypot have been used in an attack.

Account Name Number of login attempts
root 1049
admin 97
test 87
guest 40
mysql 31
info 30
oracle 27
postgres 27
testing 27
webmaster 27
paul 25
web 24
user 23
tester 22
pgsql 21

Table 1. Top 15 account names among 2741 attempts.

Figure 1. Number of account names, both existing and invalid.

Next, we looked at the passwords used in the login attempts. The attackers tried a range of passwords with most of the account names. In total during our analysis, they attempted to access 2741 different accounts and used 3649 different passwords. Not all passwords were used with all accounts. The passwords ranged from account names, account names with number sequences, number sequences, and keyboard sequences (like ‘qwerty’). There were a few more complex passwords used with seemingly random letter and number sequences or common substitution passwords (like r00t or c@t@lin).

Table 2 shows the top 15 passwords used in malicious login attempts.

Password Number of login attempts
123456 331
Password 106
Admin 47
Test 46
111111 36
12345 34
administrator 28
Linux 23
Root 22
test123 22
1234 21
123 20
Mysql 19
Apache 18
Master 18

Table 2. Top 15 passwords attempted.

Then we examined who attacked the honeypot and what strategy these attackers used. There were 23 unique IP addresses involved in the login attempts. The attackers were more or less persistent in their attempts to gain access to the system, as shown in Table 3. Ten of the sources tried less than 50 combinations and then gave up. Five tried harder with approximately 170 login attempts, and eight tried even harder with up to 1450 login attempts. Figure 2 shows the breakdown of login attempts per source address.

Number of Login Attempts Unique IP Addresses
< 50 10
50 <= x <= 200 5
> 200 8

Table 3. Frequency range of login attempts.

Figure 2. Failed login attempts by source IP.

A closer look at the attackers reveals more information about how the break-in attempts took place. The attackers tried one single account name per login attempt with a password that mostly matched the account name (e.g. test/test) and moved onto the next account name. Other attackers differed in their strategy. On average, attacker 10.0.179.148 tried five passwords before trying a different account. The passwords used in this attack scheme consisted of the number sequences or the account name with a combination of various number sequences (e.g. admin/admin, admin/admin1, admin/admin123, admin/111111). The attacker at 10.0.105.52 concentrated on the root account, attempting all but one of his login attempts (guest) with that account name. The passwords ranged from common passwords to random number and character sequences (e.g. root/!@#, root/123abc, root/default).

Several attackers exhibited behavior that was likely to evade the attention of an IDS by limiting their attacks to just a few attempts. Attacks became more serious by various degrees. First, the number of login attempts increased; second, the login attempts per account increased, and finally, we saw a concentration of login attempts on a particular account, like root. As attempts became more serious, detection of the attacker would become more likely if an intrusion detection system had been deployed. One would think that the attacker's success rate would increase with more attempts and a subsequent increased danger of detection, but we cannot confirm this as our data did not include a survey of account name/password combinations of existing systems.

In an effort to obtained further information about the methodology and tools the attackers used, we examined the variance and average time period between each login attempt per source IP. We assumed that if a tool was used in the attack, we could easily identify its usage by inspecting these values. A small gap between login attempts and a low variance would indicate usage of a tool, whereas larger irregular gaps would indicate the attacker was actually performing the login attempts in person. Figure 3 summarizes this data.

Figure 3. Average period between login attempts (seconds).

The top five offenders, who are likely to have used tools in their attacks due to the sheer number of attempts, show an average period between attempts of 2 to 4 seconds with a standard deviation that ranges from 0.45 to 1.39 seconds. On the other extreme, we find that the attacker at 10.0.192.15 with an average period between attempts of approximately 7 seconds and a standard deviation of 2.36 seconds - indicating a person might have performed the login attempts. However, the data does not support a clear indication of tool usage as many attack sequences fall in the middle or even below the values of the top offender attack sequences. A possible explanation might be that attack tools were used in most attack sequences and we are only observing network latencies.

Compared to the above attempts, a strong indicator of tool usage is revealed by examination of the account names and passwords used in the attacks from 10.0.255.81 and 10.0.242.26. Although the IP addresses resided in different physical networks and the attacks occurred 4 days apart, the account name/ password combination was identical.
The “Successful” malicious SSH login attempt
In the previous section, we analyzed the data captured of unsuccessful malicious SSH login attempts. The data gives us some insight into how attackers operate, but leaves many questions unresolved. One of those questions is whether or not tools are used in these attacks.

On July 2, an attacker successfully compromised the honeypot by guessing a valid user account name/password on SSH. The data captured during this incident revealed answers to these open questions.

First we examined the actions of the attacker after the successful compromise of the honeypot. Once a valid account name/password was determined, the attacker logged into the honeypot via SSH and proceeded to download an SSH scanner tool. This tool is described in more detail in the following section, but for now it will be summarized as a tool that allows its user to identify and compromise other SSH servers through password guessing attempts. The installed tool was immediately used to scan a class B network from our honeypot. Due to the restrictions on outgoing network connections enforced by the Roo honeywall, the SSH scanner did not identify any SSH servers.

After the initial scan, the attacker proceeded to download and install an IRC Bot. IRC Bots are tools that can control a compromised system remotely via IRC chat channels that the compromised system is set to listen to. Using IRC to control a compromised system is much more covert than using SSH directly, as the attacker does not have to directly log into the system anymore. Further, it allows the attacker to control several such systems, also known as Zombies, at the same time.

The conversations in the IRC channel revealed that the Zombies were used to scan class B networks with an SSH scanner just like the one that had been downloaded to our honeypot. During a period of a couple of hours, four class B networks were scanned with the SSH scanner from various IRC Bots, identifying thousands of SSH servers. A scan took approximately 700 seconds to complete. Further, we witnessed the exchange of an account name/password list with 160,324 unique account name/password combinations. The structure of these account names and passwords was very similar to the ones encountered during the attacks on our honeypot system, but more extensive.
Analysis summary
What do we make of this data captured by our honeypot? SSH is a way to access a computer over a network in a secure, encrypted way and has gained wide acceptance. However, despite its good reputation with respect to security, there are still threats associated with operating SSH on a machine. Password guessing clearly one of these threats, as we have shown in this paper. The mere fact that the SSH server is running and accessible from the Internet attracted 23 sequences of attacks from unique source IPs, with 6,899 login attempts to our honeypot in just 22 days. This equates to roughly one attack and approximately 300 login attempts per day, on average. Some attackers are very serious about performing attacks, executing hundreds of login attempts in a session.

The scanner capture revealed that very powerful tools are used. They are very flexible and can use customized account name/password lists for the attacks. If an attacker wanted to attack a particular domain, they potentially could harvest account names by social engineering and then combine these account names with standard passwords to be used in the attack. Observing the IRC Bot channel, we saw that attackers combined scanning tools with IRC Bot technology to perform scans via Zombies (compromised systems the attackers control via a remote channel). Our performance tests have revealed that the SSH password scanner can scan a class B network in 700 seconds.

Combined with an army of IRC bots, an attacker only needs 525 Zombies to scan the entire IP4 of today's public Internet in just one day. If you have a publicly accessible SSH server, you are very likely to be targeted by one of these attacks.
Recommendations
There are a number of simple methods to protect against these attacks. The most obvious way is to turn off the daemon service, which on many systems is installed by default. If the computer system runs as a desktop machine, there is likely no need for remote access via SSH to log into the machine. If this is not an option, there are numerous other options.

* Use the /etc/hosts.allow and /etc/hosts.deny files found on most Unix and Linux system to restrict daemon access to specific hosts.
* Install a firewall to restrict access to the SSH server from only designated machines and networks. This works particularly well if administration of a machine from an internal network necessitates remote access to that machine.
* Restrict the SSH server to only authenticate particular users or groups.
* Move the listening port of the SSH server from 22 to some other unused port. While this would not prevent attackers from connecting to the server and start guessing password, it will significantly reduce the likelihood of finding your SSH daemon, as attackers use standard SSH clients and attack tools that assume the SSH server is running on its standard port 22.
* Use an alternate authentication method besides simple passwords. More on this below. If this is not an option, ensure that a strong, complex password or passphrase is used.

SSH provides an alternate authentication method which successfully mitigates password guessing attacks. This authentication method is based on cryptographic keys, or so-called private key and public key. The public key is placed onto the server and acts as a custom lock for access to your account. This lock can only be opened with the corresponding private key. Once you provide this key, you gain access. Password guessing attacks would fail as attackers cannot guess or generate such a private key. All modern SSH servers are configured by default to support this authentication method. However, they usually fail back to password-based authentication in case the incorrect private key is provided, opening the door for password guessing attacks once again. The server needs to instead be configured to accept key-based authentication only for this mitigation strategy to be successful.

Setting up SSH with cryptographic keys is very simple and takes only a few minutes. Previous articles written by Brian Hatch have addressed SSH User Identities for secure access between an individual user and an SSH server. For more information on the host key generated by each server, the SSH Host Key Protection article may also be of use. Then, if SSH crytpo keys are in use, the reader may want to further example SSH and ssh-agent to make it easier and faster to login via SSH.

In some instances, password-based authentication or access to an SSH server cannot be disabled. In those cases, other measures need to be taken. We have seen that attackers guess accounts and have good knowledge of existing system accounts and accounts one can commonly find on computer systems. If the attacker is able to guess an account name that exists on the system – on our honeypot this was achieved for 96.30% of the default account names of the RedHat honeypot system – the attacker already has one foot in the door. As such, we recommend not making use of easily guessable account names, such as common first names. Don’t use ‘Peter’, ‘Ian’, or ‘Mark’ but rather create account names that contain a combination of first and last name, like ‘seifer_chr’. This can usually be achieved by the administrator who controls the assignment of account names.

In addition, we have seen that the ‘root’ account is the most often used account name for attacks, as it commonly exists on computer systems. We recommend that remote access to that account simply be disabled. Rather, an administrator should 'su' (superuser) gain access to this account first via a regular user account.

Attackers commonly attempted to guess accounts that exist on most systems by default, like ftp and mysql. Access to the shell can only be obtained for those accounts if a shell is associated with the account. For those accounts like ftp or mysql that simply exist to run a service on the machine, no shell is necessary and should be disabled, effectively barring remote access with these accounts via SSH.

In addition to having account names that cannot be guessed, it is important that the users’ passwords are strong. We have seen that the passwords used in the attacks often match account names or account names with number sequences. We assume that attackers select these passwords as they are most “successful” in malicious login attempts. This implies that at least some users set their passwords to these easily guessable strings. The only way an administrator of a system can prevent users from choosing such passwords is by installing various tools, like passwd+, that force users to choose strong passwords.

Attackers are using tools to perform password guessing and login attempts, such as the captured Scanner, QT, and 55hb. However, despite these tools, the minimum average time of login attempts was around two seconds due to an artificial delay on unsuccessful login attempts that was incorporated into the SSH server, as well as various network delays. While this provides protection against brute force attacks, only a few attempts and guesses are necessary on weak account names and passwords for them to be compromised. Security measures described above should be installed in order to practice security in breadth and depth.
Future work
Our analysis was based on data captured by our honeypot. We are not able to determine how successful these attacks are against systems that can be found on the web. We would have to compare the account name/password combinations used in the attacks to account name/password combinations that exist on real systems in order to determine success rate. Further, we proposed moving the listening port of the SSH server to some other unused port. We need to set up a system with such a configuration to assess its effectiveness.
About the author
Christian Seifert is a member of the New Zealand Honeynet Alliance.
Acknowledgement
Thanks to Jamie Riden for providing additional mitigation strategies on password guessing and references to actual SSH password guessing tools.
Reprints or translations
Reprint or translation requests require prior approval from SecurityFocus.

© 2006 SecurityFocus

Source : http://securityfocus.com

Lessons learned from Microsoft's MS06-013 patch

2007-08-23T03:41:00.000-07:00

On April 11, 2006, as part of Microsoft’s regular "Patch Tuesday," Redmond released MS06-013, a cumulative security patch for Internet Explorer. The patch fixes ten vulnerabilities, some with active exploits in the wild. It also contains a functionality update or change in ActiveX that users who patch via Microsoft Update or Windows Update might not have seen.
This article takes a quick look at the functionality changes in MS06-013, and then discusses the new types of deployment decisions that are being made within enterprise environments in light of this critical Microsoft security patch.

Changing how ActiveX controls work
The functionality update in MS06-013 modifies the way ActiveX controls are handled by Internet Explorer. It’s a direct response to a $521M patent dispute with Eolas, a patent which covers plugins in Web pages that show multimedia content. There is a thread on Bugtraq that does a great job of explaining the background behind this dispute.
While the majority of users will not read the vulnerability announcements, Microsoft did include a reference to one of their Knowledge Base articles that detailed the potential issues after installing the update. KB9212812 states that there will be issues with ActiveX plugins – such as QuickTime, Macromedia, and even Java. Furthermore, some components of enterprise-class software are also impacted. Home users having to jump through an extra hoop to play a video is one thing – core business operations being impacted is quite another. There are many cases where enterprise applications may use these technologies in various ways.

Realizing the potential difficulties, Microsoft further released another Knowledge Base article, KB917425. This one is known as the "Internet Explorer ActiveX compatibility patch." The patch reinstates the expected functionality of ActiveX controls, but requires an additional system reboot in order to take effect. Eventually, in order to comply fully with the patent dispute, the new ActiveX functionality will have to be restored by Microsoft. There is no time frame given, but rest assured it will happen at some point.

While home users are left confused about the changes, enterprise administrators are faced with nothing but bad choices:

Deploy the patch across all systems without the compatibility patch
Deploy the patch across all systems and selectively deploy the compatibility patch
Deploy the patch across all systems, including the compatibility patch
Selectively deploy the patch
Do not deploy the patch
Security is only effective if it is implemented using risk management principles applied in the context of keeping the business running. In other words, no business = no revenue = no company = no need for security. With that in mind, security administrators at companies across the globe had to recently make one of the above choices. As we prepare for future situations like this, let’s do a short analysis of each of these choices:

Deploy the patch across all systems without the compatibility patch
The first option is to do what most security professionals would like to do – patch all vulnerable systems. This is the cleanest approach since it covers the vulnerability and keeps all impacted systems at the same patch-level. It makes managing patch deployments very straightforward and should provide for the least disruption.
However, it may not be realistic to patch all systems in an enterprise without the compatibility patch. It will break certain functionality and could cause a flood of helpdesk calls for any business applications that are affected. The possibility of a disruption in normal business operations is present, however at least all systems will be safely patched.

Deploy the patch across all systems & selectively deploy the compatibility patch
This choice is a bit harder to make. It first requires a decision on whether to identify systems which will be impacted or just exclude all systems potentially impacted – in this case, Windows XP SP2 and Windows 2003 SP1. These are not exactly uncommon operating systems at many organizations. Once that decision is made, the IT department then needs to have the correct infrastructure tools in place to identify these systems and selectively deploy the patch. This means time, money and resources that should be spent supporting real business IT needs will be spent tracking selective patch deployments.
Another side effect of this approach is that a process needs to be put into place to define these deviations in the event that issues arise as a result of the second patch, expending yet more time, money and resources.

Finally, in the case of this particular second patch, there will need to be two reboots per system deployment causing more than just the usual user frustration.

Deploy the patch across all systems, including the compatibility patch
This option has all of the problems of the previous one, but also increases the likelihood of encountering issues associated with the compatibility patch. While the additional patch was supposed to restore functionality, there is always the potential of modified code to cause problems as well as fix issues. IT/Security departments should ideally test both patches prior to deployment.
Selectively deploy the patch / Do not deploy the patch
While mixing and matching compatibility patch deployments can be challenging, there is a real security risk involved with only deploying the main patch to a subset of systems - or even not deploying it at all, especially when it is mitigating known, active exploits on the Internet.
IT/Security departments faced with this alternative are not left completely vulnerable, however. There are a number of desktop and server-based firewall, anti-virus and intrusion prevention components that can defend against known exploits and malicious behaviors. However, these programs are meant to be deployed in a layered security solution, with patching of desktops and mobile systems being the foundation of any good security strategy. Relying solely on the ability of security vendors to stay ahead of the attackers is an unenviable position to be in.

The norm instead of the exception
While IT/Security departments have not faced this situation too often, there is real evidence to suspect that this type of debate will become the norm as opposed to the exception, as software patents generate more litigation and require more remediation.
In the case of the ActiveX patch, Microsoft took advantage of the need for users to fix vulnerabilities in order to satisfy a legal issue with the least amount of cost and administrative overhead as possible, while also getting as widespread a deployment as possible.

It is important for IT/Security departments to be ready for this emerging trend by ensuring some fundamental things are in place:

A comprehensive asset management system to ensure complete knowledge of what’s on the network (and ideally, when new devices are added to the network).
Robust, platform independent patch management tools to make it easier to customize complex deployments
Solid risk management processes and procedures to allow for fast response to vulnerability announcements and threats
A layered security strategy on systems and networks to help mitigate risk while tough decisions need to be made

Conclusion
Most organizations are just getting comfortable with regular vulnerability patch management and now have to adjust their thinking yet again. With the right tools and processes in place, however, the decisions may not have to be so quick or as painful as they no doubt were this time.
In this brief article we’ve looked at some lessons learned from Microsoft’s latest MS06-013 security patch. The patching, monitoring, and deployment of Windows security releases in an enterprise environment is already a significant cost, and the new choices IT/Security departments are faced with will only take these costs higher.

Source : http://securityfocus.com

Default Root Password in Infrant (now Netgear) ReadyNAS "RAIDiator"

2007-08-23T03:38:00.000-07:00

Authors:
Brian Chapados : brian (at) chapados (dot) org [email concealed]
Felix Domke : tmbinc (at) elitedvb (dot) net [email concealed]

Timeline:
Jul 25, 2007 - discovery
Jul 29, 2007 - vendor notification
Aug 6, 2007 - vendor releases fix (ToggleSSH)
Aug 8, 2007 - vendor releases "advisory" [1]
Aug 13, 2007 - public release of this advisory

Severity:
Critical (Remote Root)

Vendor:
Infrant (now Netgear)

Systems Affected:

ReadyNAS devices with RAIDiator 3.01c1-p1, 3.01c1-p6, possibly more

Systems Not Affected:
ReadyNAS devices with RAIDiator 4.0, which disables the SSH-daemon
by default, and lets you change the root password when enabling it.

Overview:
The ReadyNAS is a Network-Attached-Storage (NAS) device based on Linux
2.4.20 and debian-sparc with a custom frontend for management. Out of
the box, the user cannot log in into a shell on the device. There are
two enabled users, one called "admin" (with the default password
"infrant1", which is documented), and another one, "root", which is not
documented. The user "admin" does not have a shell assigned, so it
cannot log in interactively. It is used only for the web frontend.

The root password is generated on each boot with a hardcoded algorithm,
using a hash of the unique Ethernet MAC-address, the software version
number and a shared secret. The root password cannot be changed
permanently, it will be "restored" after each bootup.

The secure shell daemon (sshd) is enabled by default, and cannot be
disabled. The vendor states that this is required to be enabled for fix
problems remotely, in case the user lost its web password, and that
it is not a security risk because the user must first forward access to
port 22 on his router[2]. The latter of course is only true if a.) the
attacker comes from the internet, and b.) the NAS is behind a NAT router.

Technical details:

The ReadyNAS-devices employs a proprietary embedded SoC design, based on
the Infrant NSP IT3107, which is based on a Leon SPARC processor design.
The device boots from its internal flash. The Linux kernel and
initrd-image is contained in flash (and also downloadable from the
Infrant website in order to upgrade devices), but are encrypted with an
on-chip 3DES-based encryption algorithm. Without knowing this key, or
having access to the device, it's not possible to change the initrd image.

The initrd image will look for installed harddisks, and initialize them.
If an uninitialized harddisk is found, it will be added to the RAID
array, and a part of the harddisk will be used for a root filesystem,
which is initialized from a tarball stored in flash.

After the rootfs has been mounted, some consistency checks are done, and
several important configuration files will be "backed up" from encrypted
versions. That means that it's not possible to change arbitrary files,
for examples by mounting a harddrive externally, because they will be
replaced by their backup version on the next boot. The backup files are
encrypted, so they cannot be changed without being able to encrypt these
files.

A part of the /linuxrc file from the initrd image, which is executed
first on bootup, is:

- -------------
SEED1=`/sysroot/sbin/ifconfig eth0|grep HWaddr|sed -e 's/.*HWaddr //'
- -e 's/ //g'`
SEED2=`cut -f2 -d= /sysroot/etc/raidiator_version |cut -f1 -d,`
[*EDIT*: removed SEED3 as friendly requested by vendor]
echo "root:`echo \"$SEED1 $SEED2 $SEED3\" | md5sum | cut -f1 -d' '`" |
chpasswd
# TAKE ME OUT!!
[ -s /sysroot/.os_passwd ] && echo "root:`/sysroot/usr/bin/head -1
/sysroot/.os_passwd`" | chpasswd
###############
/sysroot/bin/mv /etc/passwd /sysroot/etc/passwd 2>$ERR
rm -rf /sysroot/etc/hosts_equiv /sysroot/root/.rhosts
/sysroot/root/.ssh/* 2>$ERR
- -------------

This means that the root password will be initialized with the md5sum of
the following components:

a.) MAC address, as extracted from ifconfig,
b.) the software version number, read from /etc/raidiator_version,
c.) a shared secret string contained in SEED3.

Even if the root password is unique per device (due to the MAC address
being part of the hash), it cannot be considered as secret. First, if
the NAS device is on the local LAN, one can easily query the MAC address
with an ARP request. Second, the default hostname, which is also
displayed in the https-based interface (even for non-authorized users),
is "nas-xx-yy-zz" where xx,yy,zz are the last 3 octets of the MAC address.

Finally, the software revision can be easily determined using a
brute-force approach.

Knowing this, an attacker can login into remote ReadyNAS devices, and
access all data on the system.

Vendor Status:
After contact with the vendor, the vendor released a fix in less than a
week, together with the beta of RAIDiator 4.0, which allows a user
to enable root access with a changable password.
The vendor also released an advisory [1].

Recommendation:

Use the 'ToggleSSH'-addon released by the vendor to disable SSH access.

[1] http://www.infrant.com/forum/viewtopic.php?t=12313
[2] http://www.infrant.com/forum/viewtopic.php?t=3366&start=30

Source http://securityfocus.com

Black Hat and Defcon 2007--

2007-08-20T23:27:00.001-07:00

>> A Multi-Perspective View of the Information Security Landscape
In early August, Las Vegas was home to two world-renowned IT
security conferences, Black Hat USA 2007 and Defcon. These
back-to-back conferences bring together the many diverse groups
that comprise the information security industry, including IT
security professionals, vulnerability researchers, so-called
"feds," and computer hackers. This unique blend of participants
offers a comprehensive, unparalleled look at the information
security landscape.

Black Hat, considered by many to be the more mainstream of the
two gatherings, was founded in 1997 by Jeff Moss to provide
advanced education for security professionals in both the
commercial and federal spaces. Today, the conference features
new, cutting-edge research from the foremost technologists in the
world. A few days of security training is followed by a week of
briefings covering all the latest threats, threat vectors,
security solutions, and more. In addition to the Las Vegas
conference, Black Hat hosts annual events in Singapore, Tokyo,
and Amsterdam. Working with corporations and governments around
the world allows Black Hat's security experts to stay abreast of
global security trends. The recent Black Hat conference held in
Las Vegas has grown considerably since its inception. This year,
it reports an estimated 4000 attendees--a 10 percent gain over
2006 numbers.

Defcon, which immediately follows Black Hat in Las Vegas, has
been around since 1992. Also founded by Jeff Moss, Defcon is
considered to be one of the largest underground hacking events in
the world. While many Black Hat attendees also attend Defcon,
the conference is geared more toward the hacker community.
Defcon is well-known for its casual atmosphere--no ties
required--and it costs a mere $100 to attend. This year, Defcon
generated some media buzz when a Dateline NBC reporter was
exposed and forced to leave the conference for allegedly filming
attendees of a session by noted hacker H.D. Moore. Not
surprisingly, the hacker community frowns on cameras.

Black Hat and Defcon cover a vast array of information security
topics. Following are just five of the hot topics discussed at
this year's conferences.

>> Wi-Fi Traffic Sniffers
Users should think twice before sitting down at the local Wi-Fi
hotspot to access the Internet. According to a paper presented
at Black Hat by Robert Graham, CEO, Errata Security, Web
applications that exchange account information with users pose
serious security risks when accessed via Wi-Fi. Typically, Web
sites use encryption to protect passwords. However, it is common
for other account information exchanged between a browser and a
Web site to not be encrypted.

Using a packet sniffer, a tool used to intercept or log wireless
traffic exchanged between a wireless router and a computer,
cookies can be collected while a user is accessing a Web site via
Wi-Fi. Cookies consist of data sent to a browser by a Web site
that remember certain information about users, such as when they
last logged in. Cookies also include session identifiers--another
type of unique information generated when users log into their
accounts. With the cookie information, the attacker is able to
import the information into another Web browser and use it to
access the user's account. This enables a hacker to read email,
create blog postings, and the like. To combat the risks
associated with Wi-Fi, researchers at Black Hat recommended users
refrain from accessing their accounts unless a virtual private
network (VPN) or secure socket layer (SSL) is used.

>> Web 2.0--AJAX Vulnerability
At Black Hat 2007, a presentation addressing the AJAX application
design flaw--which included live demonstrations of the potential
exploits--generated a great deal of interest among conference
attendees. While Web 2.0 is an exciting and revolutionary
development in online computing, it exposes consumers and
businesses to a broad spectrum of Web threats. Web 2.0
technologies, such as asynchronous Javascript and XML (AJAX),
expand both the attack surface and the security gaps available to
cyber criminals, while the communal interaction premise of Web
2.0 renders users more susceptible to social engineering
techniques. These developments challenge security solutions to
expand protection beyond the traditional client-server endpoints
of online computing. With many more threats unfolding "in the
cloud" of the Web, which in the Web 2.0 paradigm is coming to
function as a dynamic and exploitable operating system,
next-generation security solutions must pay increasing attention
to defense mechanisms that secure Web sites.

The potential consequences of neglecting Web 2.0 protection are
significant. Given the rush to architect Web 2.0 applications to
meet demand, coupled with the underlying security weaknesses of
AJAX, the Web 2.0 ecosystem remains disturbingly vulnerable to
attack. Web developers are not sufficiently ameliorating the
security problem. Interest in AJAX is sky-high and only continues
to grow. Unfortunately, far too many developers rush into AJAX
development without giving proper consideration to security
issues.

>> Botnets
True to form, Botnets emerged as a hot topic at the recent Black
Hat conference in Las Vegas. The use of botnets-networks of
compromised machines infected with malicious programs-remains a
common tool for nefarious Web activity. A bot--sometimes
referred to as a bot worm--is an automated software program that
operates as an agent for a user or another program. While bots
can be used to perform mundane tasks online (e.g., check stock
quotes, compare prices, or collect and index documents), they are
increasingly used for malicious purposes. Malicious bots are
created covertly using a computer virus or worm to install a
backdoor program--such as a Trojan horse (a malicious program
disguised as, or embedded within, legitimate software) or a
drive-by downloader (which exploits Web browsers, e-mail clients,
or operating system bugs to download malware without requiring
any user intervention)--that leaves a PC Internet port open.

Controllers, or botmasters, search for PCs with open ports and
use those ports to install their bot programs. Security experts
call these bot-loaded PCs zombies, because the botmaster can wake
them on command. When bots are installed on multiple PCs, the
network of compromised machines (the botnet) is commanded to
perform an extensive range of malicious activities, including
spam distribution, phishing schemes, keystroke logging, and
distributed denial of service (DDoS) attacks.

>> Voice over IP (VoIP) Exploits Enable Data Theft
VoIP vulnerabilities received considerable attention at Black Hat
this year. While not new to the IT security threat arena, VoIP
exploits are becoming increasingly alarming. For a time, VoIP
vulnerabilities were a nuisance that primarily threatened
service. Today, cyber criminals can use VoIP attacks as a
vector for accessing data and stealing information. During a
VoIP session at Black Hat, researchers from security firm Sipera
demonstrated a technique that could allow a hacker to gain remote
control of a PC running VoIP and the session initiation protocol
(SIP)--an application-layer signaling protocol used for IP-based
communications. By leveraging the flaws in VoIP and SIP, the
demonstration showed how attackers are able to access data stored
on a compromised computer.

According to researchers, a hacker is able to insert a small
script, or code, into a SIP message. When the phone receives the
message, the code executes. This opens up a connection on the
computer that enables access to the data stored on the machine.
Given the evolution of VoIP threats, enterprises, service
providers, and consumers need to become more aware of security
threats to their fixed and mobile VoIP infrastructure.
Protection mechanisms including increasing robustness of phone
protocol implementations, employing VoIP security best practices,
and securing critical network nodes are key to combating VoIP
threats. Additionally, consumers should take proactive steps to
protect data at rest on computers running VoIP applications.

>> Advanced Gaming Consoles
Today's next-generation gaming consoles that offer Internet
connectivity coupled with large hard disk storage and advanced
operating systems, are likely targets for cyber criminals looking
to create botnets, pirate games, and steal personal information.
Today, a virtual world in which console gamers can play with each
other adds another dimension to games. Recently, the big three
in the video gaming industry (Nintendo, Sony, and Microsoft)
released the latest powerful new gaming console technology: Wii,
PlayStation 3, and Xbox 360 respectively. Each is capable of
Internet connectivity, data storage, and use of a third-party
operating system. The processing power and various capabilities
of these new consoles pave the way for more realistic,
interactive, and fun gaming. They also create an appealing
threat vector for malicious attacks.

At present, these game consoles can be used for more than just
gaming, and all three consoles can connect to the Internet via
broadband. This means that content can be downloaded from the
Internet and stored on the on-board hard drive, enabling zombie
game console botnets-especially since many consoles now support
third-party operating systems.

Another consideration is information theft. Massively
multiplayer online games (MMOGs) and user accounts in Xbox Live
and PlayStation Network are prime targets for future spyware.
Keyloggers can be downloaded to console hard drives and
surreptitiously operate in the background. Spyware may not be as
significant a threat to console gaming as it is to other
computers, however. In most normal situations, trade secrets and
sensitive information are rarely stored on game consoles.

For information on how to combat today's complex threats, visit
www.trendmicro.com
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSW
. And stay tuned to the next issue of the FLOD
Newsletter for an in-depth look at these and other topics
emerging from Black Hat and Defcon 2007.

References
Black Hat USA 2007 (http://www.blackhat.com)
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSY

Kirk, Jeremy. (2007, August 01) Researchers: Webb Apps Over Wi-Fi
Puts Data at Risk, InfoWorld,
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSA

http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSA

Hickey, Andrew. (2007, August 07) VoIP Vulnerability Threatens
Data, SearchVoIP.com, http://searchvoip.techtarget.com
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSB

White Hats Expose VoIP Security Threat, ZDNET.co.uk, (2007,
August 07)
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSC

http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSC

************
Quick Links
************

>> View the Latest Threats
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VT

>> Get Product Updates
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VW

>> View this issue online
http://newsletters.trendmicro.com/servlet/website/ResponseForm?mgLEVTTA_TBUA_.40ev.2eEmhLrHgnPLIlpmLFRHohhDJhDpK

>> Read the Malware Blog
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VC

>> Forward to a Friend
http://newsletters.trendmicro.com/servlet/ff/c?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VgVTYDYSW

************
Free Security Tools
************

>> Scan Your PC for Viruses and Spyware
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VD

>> Surf Securely with TrendProtect(TM)
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSR

************
Security Resources
************

>> Common Threats to Your PC
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VST

>> Threats in the Enterprise
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSU

************
Quotables
************
>> Using a packet sniffer, a tool used to intercept or log
wireless traffic exchanged between a wireless router and a
computer, it is possible to collect cookie information while a
user is accessing a Web site via Wi-Fi.
>> Given the rush to architect Web 2.0 applications to meet
demand, coupled with the underlying security weaknesses of AJAX,
the Web 2.0 ecosystem remains disturbingly vulnerable to attack.
>> Today, cyber criminals can use VoIP attacks as a vector for
accessing data and stealing information.
>> Content can be downloaded from the Internet and stored on the
on-board console hard drive, enabling zombie game console
botnets-especially since many consoles now support third-party
operating systems.

Source : http://trendmicro.com

Efficient Registry Cleanup

2007-08-20T23:20:00.000-07:00

How to script a registry cleanup or modification for all user profiles on a given computer.

This article will demonstrate how to script a registry cleanup or modification for all user profiles on a given computer – for instance to do a virus sweep. We will also see how this approach can be used together with a computer startup script within a computer Group Policy Object to modify all user profiles in the domain, site or OU. Yes, we can actually modify user registry settings by using a computer startup script…

In some cases you can be required to delete, add or modify some part of the registry – for all users on a computer at once. In most cases we would prefer to use a Group Policy Object (GPO) on the users to add or modify a given value, but when it comes to removing values we sometimes have to use scripts (unfortunately, you might say). Also, sometimes we want to perform a cleanup task in a single process without having to wait for all users to log on. This article will show how to do this in a fairly easy way.

We will see how it is possible to do the registry modification by using a very efficient registry script – and to combine this with a GPO on the machine level (startup or shutdown), instead of using a GPO on the user object (logon or logoff).
Why would I want to do this?

So, why is that a smart approach? Well, maybe you want to do the “cleanup” during the night, you might want to make sure that a certain value is modified (deleted, added or changed) by the next morning – typically the ‘Run’ or ‘RunOnce’ keys in the user part of the registry after a virus attack - so combined with a Wake-On-Lan (WOL) procedure you can be ready to go home in no time!

In other cases the user might not have the required privileges to perform the cleanup or modification task. The registry key you want to change might be protected by a security permission, making it impossible to use a user GPO (as it will run in the user context). The great thing is that computer startup scripts execute in the context of the System account – that can be very useful to keep in mind in many situations!

Warning!
The code presented in this article is produced for testing purpose only – use in production is at your own risk. The included code is simplified a bit to be easier to understand and read. Please be sure you confirm the script functionality in your test environment before implementing this in production. You can include additional error handling, logging and additional functionality – modify as you want!

I am not saying the code does not work, just making sure you understand that execution is at your own risk.
The background

Before we take too deep a dive into the code, a few things about the registry must be perfectly clear.

It is very common that people think the HKEY_USERS part of the registry is a place where you can see all local profiles on a given computer. However, this is not the case. The HKEY_USERS lists profiles that are currently loaded on the machine, so to speak the profiles that are active in memory. As soon as a user logs on to a computer, an entry will be visible in this part of the registry.

Figure 1

As shown in Figure 1 you will normally be able to see a few profiles loaded – even though only one user is logged on to the console. When a user logs off, the Registry Hive is unloaded and is no longer visible under HKEY_USERS. Here is a short explanation on the loaded hives:

“.DEFAULT” is the default user profile – NOT something that all users will see (like a Public or All Users profile) and NOT a registry profile that is copied to all new users on the computer (these are common misunderstandings). This is however the standard profile in use, even when nobody is logged on – hence the startup profile (loaded before you even reach the desktop). By setting values in this profile you can change options such as desktop background during the logon screen (Ctrl+Alt+Delete), the initial Num/Caps Lock settings etc.

"S-1-5-18” is the “System” Security Identifier (SID)
"S-1-5-19" is the “LocalService” SID
"S-1-5-20" is the “NetworkService” SID

A profile or SID starting with "S-1-5-21-" and ending with "-500" is the SID of the built-in Administrator account. The ‘real’ and active user profiles are all other entries in the HKEY_USERS part of the registry. In the script examples included in this article the above specified profiles are NOT touched – only ‘regular’ users are touched - you could change that easily by deleting a few lines in the code.
Load My Hive…

So, what if I want to modify a profile of a user that is not currently logged on? Well, we have at least two options:

1 - to manually load the hive in Regedit
2 - to create a script that loads the hive dynamically.

Let us look at the first option first. If you open Regedit (Start > Run > Regedit) and browse to the HKEY_USERS entry (you have to click or mark it), then go to the File menu, you should now be able to choose “Load Hive…” (see Figure 2)

Figure 2

At this point we are prompted to enter a path to an NTUSER.DAT file (see Figure 3).

Figure 3

The NTUSER.DAT file is located in the user profile folder. Above, we can see the NTUSER.DAT file of the user ‘test2’. That file is located right below the “C:\Documents and Settings\test2\” folder - on Windows Vista, user profiles are typically stored below the “C:\Users\” folder.

If you cannot see the NTUSER.DAT file as we can in Figure 3, you should go to Tools > Folder options and select “Show hidden files and folders”.

When loading a hive temporarily we need to give it a name – make your own choice. In Figure 4 and the script examples we are using the name: ‘TmpLoadHive’.

Figure 4

Click OK and the hive hierarchy should be visible, and expandable, as shown in Figure 5.

Figure 5

In Figure 5 ‘TmpLoadHive’ has been expanded to show the structure of a loaded user hive – it should look exactly like any other user registry. It is identical to what the user will have in his or her HKEY_CURRENT_USER (HKCU) when logged on to the machine.

When done, remember to unload the user hive again by marking the ‘TmpLoadHive’ hive and going to the File menu > “Unload Hive…” as in Figure 6.

Important!
If you do not unload the hives, you cannot load that hive again until after a reboot, because you cannot load an already loaded hive (this also goes for logged on users – including Fast User switching users). This will also make the script ‘fail’ loading the hive.

Figure 6

That procedure would be very annoying if you had to do it for all user profiles on all computers in your domain, right? Luckily we have another method by using our good old friend REG.EXE.
An old friend to the rescue

The REG.EXE command has two very useful parameters: LOAD and UNLOAD. They do exactly the same stuff as we did manually above. We just have to specify the temporary hive name and a full path to the NTUSER.DAT file we want to load into memory.

You want a script example? Ok, to set the background for the Default User profile we could run the following code:

REG.EXE LOAD HKU\DefU "C:\Documents and Settings\Default User\ntuser.dat"
REG.EXE ADD "HKU\DefU\Control Panel\Desktop" /v Wallpaper /d "C:\Windows\Wallpaper.bmp" /f
REG.EXE UNLOAD HKU\DefU

The above code will first LOAD the hive for the Default User profile into a temporary hive called “DefU” in the “HKEY_USERS” part of the registry database. Then it will set a registry value for the desktop background for the Default User profile, which is the profile that is copied automatically when new users are created (the first time they log on). Finally, it will UNLOAD the temporary hive.
So how can I find the Ntuser.dat files in a script?

When we want to load hive for all users on a given machine we would want to find all user profiles on that machine as safely and easily as possible. We could of course just “browse” through the folders below “Documents and Settings” - or “Users” on Vista/Windows Server 2008 in the code – but we have a better approach that is more accurate.

In the following registry value:

“HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\XXX\ProfileImagePath”

you will find the correct profile folder path for all local users. XXX is the SID of the user, so by going through all of these keys we will have the full paths for all local NTUSER.DAT files.

I have written a VB Script function that lists the user profile folders on a given computer (in a single string separated by pipe “|” characters) – it being local or remote. The functions exclude profiles of the Systemprofile, LocalService, NetworkService and the Local Administrator account – in most cases these are not required in a cleanup, but the ElseIf statements can easily be excluded if required. The function is called “GetUserProfileDirsFromRegistry” and can be found right here.

And what about Roaming profiles you might ask? Well, the NTUSER.DAT files are all we need, so if you want to modify the roaming user profiles instead just go ahead and write a script that ‘browses’ through that roaming profile network location you have...
Delete this value or key…

Well, now we know how to load (or ‘mount’) a user hive within a script, now we just need to change something within that hive. You could probably come up with hundreds of cool things to do, but I have only chosen to use two functions – both of them are for deleting stuff within the loaded registry hive. Here is an explanation:

After a virus attack you might have to do a cleanup of the ‘Run’ key:
“HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run” for all local users. Maybe some piece of malware created an entry that you need to get rid of – for that purpose I created the DeleteSingleValueFromTmpLoadHive sub routine. This routine can delete a single value in the registry.

You might also want to delete an entire registry key, including subkeys and values, eg. “HKEY_CURRENT_USER \Software\Windowsecurity.com”, for that purpose I included the DeleteKeyAndSubsFromTmpLoadHive sub routine.
The golden combination

When combining what we have learned here, and performing some good old VBS scripting, we have a script that performs the following tasks:

1. Find all profile folders on the local computer by reading the registry values mentioned above
2. Ignore built-in OS related profiles, including the local administrator account
3. Load the registry hive from NTUSER.DAT files within the located profile folders
4. Delete a registry key, including all sub-keys, values etc. for each ‘mounted’ user profile *
5. Delete a single registry value for each ‘mounted’ user profile **

* ”\Software\Windowsecurity.com” (and all sub keys/values)
** ”\Software\Microsoft\Windows\CurrentVersion\Run\VirusExecutable”

The script does NOT prompt to confirm when it is completed and any errors will be suppressed (by using ‘On Error Resume Next’ handling). This behavior can of course be modified to fit your needs. As this is not really a scripting article I cannot dive too much into the code, but if you are a bit familiar with scripting you should be able to get a pretty good idea of what it is doing.

The complete code example can be viewed and downloaded here! It has been tested on Microsoft Windows XP, Microsoft Windows Server 2003 and Microsoft Windows Vista.
SYSTEM is here!

At this point we can “hit” a single machine, the local computer from which we execute the script - or to be more accurate: all user hives on it. There is a major limitation though: users in general (hopefully) are NOT local administrators, and so they won’t be able to modify the registry for other users! This means we would want to either run the script as a local admin manually for all machines in the domain – or do something extremely effective: use a Group Policy on the machine level and configure a computer startup script. To learn more about computer startup script see the External Links section.

The beautiful thing about a computer startup script is that first of all it runs in the context of Local System, a very powerful account (so you can do almost anything), and second of all, it can be set to execute on thousands of computers within a few minutes by placing the GPO on the Active Directory domain, site or Organizational Unit (OU) level!

Please be aware, that the first load of the new computer GPO can ‘fail’, in this case you will have to restart the computer (and maybe perform a GPUPDATE /FORCE command just to be sure). Also, please give the script time to execute before logging on – both of these mentioned ‘issues’ can occur due to the way these policies are loaded during system boot. I am not going to address these Group Policy ‘features’ any further in this article.

If you have Wake-On-LAN (WOL) functionality on the network you can boot the computers during night time to do some “cleaning” and shut down the computers afterwards. So by combining scripting, WOL and Group Policy we can perform a very efficient cleanup job within short time – or some other job we might want performed without doing too much work: Imagination is the only limit!
Conclusion

We have seen how to combine scripting and computer startup scripts in Group Policy to perform a cleanup job in a very efficient way. We can now update user profiles even though they are not currently loaded into memory – without even logging on to the system(s).

This approach can be further developed to change other parts of the profiles, maybe files and folders, for all users on a given computer. Feel free to send me any feedback and ideas you might have on this.

Source : http://windowsecurity.com

Linux firewall

2007-06-03T19:47:00.000-07:00

There are many kind of firewall for linux. some of them is free and but not all of firewal for linux free. this some for firewall maybe this will can be your reference:

- IPcop
- Smoothwall
- injoy
- Firestarter
- Sonicwall

you can serach on google use keyword above or you can use keyword free linux firewall.

Secure Socket Tunneling Protocol

2007-05-28T23:26:00.000-07:00

SSTP (Secure Socket Tunneling Protocol) and the VPN capabilities it will offer in future.

The article will give a clear understanding of SSTP and compare standard VPN vs SSTP VPN. The article will also cover the advantages of utilizing both SSTP and VPN simultaneously and what the benefits of using SSTP will be.
VPN

Virtual private network, also referred to as VPN, is a network that is constructed with the use of public wires to join nodes, enabling the user to create networks for the transfer of data. The systems use encryption and various other security measures to ensure that the data is not intercepted by unauthorized users. For years VPN has been used successfully but has recently become problematic due to the increase in the number of organizations encouraging roaming user access. Alternative measures have been looked at to enable this type of access. Many organizations have begun to utilize IPSec and SSL VPN as an alternative. The other new alternative being SSTP, also referred to as ‘Microsoft’s SSL VPN’.
Problems with typical VPN

VPNs typically use an encrypted tunnel that keeps the tunneled data confidential. By doing this when the tunnel routes through typical NATed paths the VPN tunnel stops working. VPNs typically connect a node to an endpoint. It may happen that both the node and the endpoint have the same internal LAN address and, if NAT is involved, all sorts of complications can arise.
SSL VPN

Secure Socket Layer, also referred to as SSL, uses a cryptographic system that uses two keys to encrypt data, the public and private key. The public key is known to everyone and the private only to the recipient. Through this SSL a secure connection between a client and a server is created. SSL VPN allows users to establish secure remote-access from virtually any internet connected web browser, unlike with VPN. The hurdle of unstable connectivity is removed. With SSL VPN an entire session is secured, whereas with only SSL this is not accomplished.
SSTP

Secure socket tunneling protocol, also referred to as SSTP, is by definition an application-layer protocol. It is designed to employ a synchronous communication in a back and forth motion between two programs. It allows many application endpoints over one network connection, between peer nodes, thereby enabling efficient usage of the communication resources that are available to that network.

SSTP protocol is based on SSL instead of PPTP or IPSec and uses TCP Port 443 for relaying SSTP traffic. Although it is closely related to SSL, a direct comparison can not be made between SSL and SSTP as SSTP is only a tunneling protocol unlike SSL. Many reasons exist for choosing SSL and not IPSec as the basis for SSTP. IPSec is directed at supporting site- to-site VPN connectivity and thus SSL was a better base for SSTP development, as it supports roaming. Other reasons for not basing it on IPSec are:

* It does not force strong authentication,
* User clients are a must have,
* Differences exist in the quality and coding of user clients from vendor to vendor,
* Non-IP protocols are not supported by default,
* Because IPSec was developed for site to site secure connections, it is likely to present problems for remote users attempting to connect from a location with a limited number of IP addresses.

SSL VPN proved to be a more compatible basis for the development of SSTP

SSL VPN addresses these issues and more. Unlike basic SSL, SSL VPN secures an entire session. No static IPs are required, and a client is unnecessary in most cases. Since connections are made via a browser over the Internet, the default connection protocol is TCP/IP. Clients connecting via SSL VPN can be presented with a desktop for accessing network resources. Transparent to the user, traffic from their laptop can be restricted to specific resources based on business defined criteria.
SSTP - an extension of VPN

The development of SSTP was brought about by the lack of capability of VPN. The main shortcoming of VPN is its unstable connectivity. This is a consequence of its insufficient coverage areas. SSTP increases the coverage area of VPN connection ubiquitously, rendering this problem no more. SSTP establishes a connection over secure HTTPS; this allows clients to securely access networks behind NAT routers, firewalls and web proxies, without the concern for typical port blocking issues.

SSTP is not designed for site to site VPN connections but is intended to be used for client to site VPN connections.

The success of SSTP can be found in the following features:

*
SSTP uses HTTPS to establish a secure connection
o
The SSTP (VPN) tunnel will function over Secure-HTTP. The problems with VPN connections based on the Point-to-Point Tunneling Protocol (PPTP) or Layer 2 Tunneling Protocol (L2TP) will be eliminated. Web proxies, firewalls and Network Address Translation (NAT) routers located on the path between clients and servers will no longer block VPN connections.
*
Typical port blocking is decreased
o
Blocking issues involving connections in relation to PPTP GRE port blocking or L2TP ESP port blocking via a firewall or NAT router preventing the client from reaching the server will no longer be a problem as ubiquitous connectivity is achieved. Clients will be able to connect from anywhere on the internet.
*
SSTP will be built into Longhorn server
*
SSTP Client will be built into Windows Vista SP1
o SSTP won't require retraining issues as the end-user VPN controls remain unchanged. The SSTP based VPN tunnel plugs directly into current interfaces for Microsoft VPN client and server software.
*
Full support for IPv6. SSTP VPN tunnel can be established across IPv6 internet.
*
It uses integrated network access protection support for client health-check.
*
Strong integration into MS RRAS client and server, with two factor authentication capabilities.
*
Increases the VPN coverage from just a few points to almost any internet connection.
*
SSL encapsulation for traversal over port 443.
*
Can be controlled and managed using application layer firewalls like ISA server.
*
Full network VPN solution, not just an application tunnel for one application.
*
Integration in NAP.
*
Policy integration and configuration possible to help with client health checks.
*
Single session created for the SSL tunnel.
*
Application independent.
*
Stronger forced authentication than IPSec
*
Support for non IP protocols, this is a major improvement over IPSec.
*
No need to buy expensive, hard to configure hardware firewalls that do not support Active directory integration and integrated two factor authentication.

Figure 1.1: The SSTP connection mechanism

How SSTP based VPN connection works in seven steps

1. The SSTP client needs internet connectivity. Once this internet connectivity is verified by the protocol, a TCP connection is established to the server on port 443.
2. SSL negotiation now takes place on top of the already established TCP connection whereby the server certificate is validated. If the certificate is valid, the connection is established, if not the connection is torn down.
3. The client sends an HTTPS request on top of the encrypted SSL session to the server.
4. The client now sends SSTP control packets within the HTTPS session. This in turn establishes the SSTP state machine on both sides for control purposes, both sides now intiate the PPP layer communication.
5. PPP negotiation using SSTP over HTTPS now takes place at both ends. The client is now required to authenticate to the server.
6. The session now binds to the IP interface on both sides and an IP address assigned for routing of traffic.
7. Traffic can now traverse the connection being either IP traffic or otherwise.

Microsoft is confident that this protocol will help alleviate VPN connection issues, The RRAS team are now readying RRAS for SSTP integration and the protocol will be part of the solution going forward. The only prerequisite at present is that the client runs Vista and Longhorn server. The feature set provided by this little protocol is both rich and flexible and the protocol will enhance the user and administrator experience. I predict that devices will start to incorporate this protocol into the stack for secure communication and the headaches of NAT will soon be forgotten as we move into a 443/SSL incorporated solution.

Conclusion

SSTP is a great addition to the VPN toolkit to enable users to remotely and securely connect to the corporate network. Blocking of remote access and NAT issues seem to be forgotten when using this protocol and the technology is stable, well documented and working. This is a great product and it is very welcome in this time of remote access.

Source http://windowsecurity.com

Social engineering reloaded Part II

2007-04-30T08:32:00.000-07:00

Company X's physical (building) security includes badges for all employees, locked doors, security guards, and restricted access. Employees, however, tend to hold doors open for others and don't tend to check the photos on IDs when doing so. Dumpster areas are gated but unlocked, leaving them open to potential dumpster divers. Phone security is standard, allowing internal transfers and outgoing calls with blocked IDs. Remote access is through a VPN with SecureID, the use of which requires permission from a superior and inactive accounts are suspended within 30 days. Wireless access points in the buildings also fall under these restrictions.

As for hardware, remote drives are used, but employees are instructed not to store confidential information on the drives. Laptops are common, but only roughly 30% of users lock them with the provided cables. Shared drives on the internal network are protected by group permissions. On the system level, the company runs weekly virus scans. Security teams have reduced administrative rights on machines so employees can't install rogue programs. Password requirements are fairly standard, requiring a variety of characters, changed every few months.

Software comes standard for each machine. Screen savers are password protected, but not always locked. Most machines are open to Internet access, with the exception of some site blocking. Passwords can be saved in browsers, however. Email suffers from frequent server problems, webmail is not always secure, and IM use internally is rampant.

In the areas where social engineering prevention could be most useful, barely anything is done. When an employee is on the phone with Help Desk support, the employee's number comes up on phone but no standard authentication questions are asked by either the Help Desk staff or the employee being helped. CallerID spoofing would be a very simple way to get a password reset. Security training is available for home network usage and basic encryption, but departments differ in their use of these tools. No standard training is given for new employees, leaving the organization open to staff passing around a wide range of bad habits.

Sadly, Company X's security is not much better than it was ten years ago and it has barely evolved with the times. It's tough enough to keep up with the latest technology, patches, and filters with corporate budget cuts. Security teams tend to get the short end of the stick until the company suffers a major outage from an attack. Since various attacks became more public in recent years, everybody and their brother company claims to be secure - but the reality is that most companies are like Company X, struggling to maintain a basic level of security.
Countermeasures
What could Company X and others like it do to prevent attacks on the social engineering level? On the technical side, they must continue to install spam filters and update software patches, as a bare minimum. Making cryptography standard for email and web access, not allowing passwords to be saved in browsers, and changing to an internal messaging program are key technology step. The next step would be to develop an incident reporting and tracking program. This way they can discover additional holes in their program and attend to those holes. Incident reporting won't necessarily catch the intruders, but it helps to find ways to deter them.

Not to bite the hand that feeds us, but as Mitnick says, "anyone who thinks that security products alone offer true security is settling for the illusion of security." Therefore, training cannot be emphasized enough. New employee training, repeat training, regular updates, and fun security tips can keep the security education process fresh and lively. Some companies now use t-shirts and other paraphernalia to advertise security practices and remind employees to beware of suspicious phone calls and other potential phishing attempts. Help Desk staff need to have proper authentication procedures for all support calls. Security personnel should be adequately trained as well, and screened beyond regular employees in case they themselves pose a risk to the company.

Security policies used to have more bark than bite, but these days it's now common to put more teeth into them. Corporate policies, standards, guidelines, and so on cover a wide range of areas but the important thing is to develop them with growth and accountability in mind. Topics that should be covered in corporate policies include information sensitivity, password protection, ethics, acceptable use, email, database credentials, extranet usage, VPN security, and server security.

Also, pay attention to what's happening on the national and international level as far as ID theft laws and database protection are concerned. New bills are being developed to make identity theft more difficult through the greater protection of personal information.
The bottom line
Unfortunately, the reality is that intruders rarely get caught, and even when they are caught, the penalties haven't traditionally been stiff. Shouldn't we be more worried about serial murderers running loose than a bunch of computer geeks? Seriously though, identity theft, corporate espionage and cyber-terrorism are here to stay, so the bottom line lies in making a commitment to combating potential attackers.

At Company X the buck ultimately stops with the CIO, who must commit to improving their security program before they lose a significant amount of money and intellectual property to a major attack. That requires committing both the financial and people resources to the problem, and not dropping education and training from the budget. As individuals, we must commit to increasing our awareness of the risks we face and the potential openings we create for social engineers to fool us. The key, according to Schneier, lies in, "securing the interaction between the data and the people."

In any good security program, a realistic balance must be reached. There's always a fine line between an "atmosphere of paranoia" and a productive environment. However, if we err on the side of stronger security, knowing human error is the problem, we'll be more likely to achieve success. Just remember that we, the people, are the weakest link and as Mitnick writes, "Don't' be gullible!"
Resources
"A VOIP security plan of attack", Joel Snyder, Network World, September 13, 2004.

"Cisco Denial of Service VoIP Attack", VoIP & Gadgets Blog, January 21, 2005.

"Closing the Floodgates: DDoS Mitigation Techniques", Matthew Tanase, Security Focus, January 7, 2003.

Hacking Exposed: Network Security Secrets & Solutions, McClure, Scambray & Kurtz, Fifth Edition, McGraw-Hill/Osborne, 2005.

"Malicious Malware: attacking the attackers, part 1", Thorsten Holz and Frederic Raynal, Security Focus, Jan 31, 2006.

"Malicious Malware: attacking the attackers, part 2", Thorsten Holz and Frederic Raynal, Security Focus, Feb 2, 2006.

"Phishing losses overestimated - survey", John Leyden, The Register, December 3, 2004.

"Phishing for Savvy Users", Scott Granneman, Security Focus, Nov. 1, 2004. "Phishing, spyware and other pests plagued 2004", Anik Jesdanum, AP, Dec. 30, 2004.

"The SANS Security Policy Project", SANS, 2006.

Secrets & Lies: Digital Security in a Networked World, Bruce Schneier, Wiley Computer Publishing, 2000.

"Social Engineering Fundamentals, Part I: Hacker Tactics", Sarah Granger, Security Focus, Infocus, December 18, 2001.

"Social Engineering Fundamentals, Part II: Combat Strategies", Sarah Granger, Security Focus, Infocus, January 9, 2002.

The Art of Deception, Kevin Mitnick & William L. Simon, Wiley Publishing, Inc., 2002.

The Hacker Ethic, Sarah Granger, Ethics in the Computer Age, ACM Press, 1994.

"Voice over IP Security", Matthew Tanase, Security Focus, March 12, 2004.

Source Article : http://www.securityfocus.com/infocus/1860/2

Social engineering reloaded

2007-04-30T08:30:00.000-07:00

Sarah Granger 2006-03-14

The purpose of this article is to go beyond the basics and explore how social engineering, employed as technology, has evolved over the past few years. A case study of a typical Fortune 1000 company will be discussed, putting emphasis on the importance of education about social engineering for every corporate security program.
Top five hacking moments on film
To break the ice, let's start this article by looking at this author's top five favorite hacking moments in modern movies, all of them quite old-school to emphasize a point:

5. Independence Day: Using an old space ship as cover for two humans to infiltrate the alien mother ship and upload a virus to destroy it.
4. Hackers: Dumpster diving in the target company's trash in order to obtain financial data from printouts.
3. War Games: Password cracking the military computer system by studying its creator.
2. Ferris Bueller's Day Off: Faking a grandmother's death to get Ferris's girlfriend excused from school through multiple phone calls and answering machine recordings.
1. Star Wars: R2-D2 gaining access to the death star main computer and shutting down the garbage dispensers (remember the com link!).

Question: Which of the above hacks did not employ a social engineering technique? Answer: None of the above.

In Independence Day, the characters spoofed the mother ship with a physical Trojan horse. In Hackers, dumpster diving can't be achieved with a computer. In War Games, Matthew Broderick's character studied his target before attempting to crack the password, and then in Ferris Bueller's Day Off, his phone scam was sheer brilliance. You've got to love the low-tech approach. And although it would seem R2-D2's hack was entirely technical, remember he had to sneak into the room with the computer access point before achieving his goal.

The lesson here is that social engineering is a major component of hacking in both fictional and real scenarios. By merely trying to prevent infiltration on a technical level and ignoring the physical-social level, we are leaving ourselves wide open to attack.
Social engineering redefined
Bruce Schneier, author of Secrets & Lies: Digital Security in a Networked World, reminds us that social engineering, aka "socio-technical attacks" is really all about the human aspect, and that means trust. Kevin Mitnick, renowned and reformed hacker, in his book The Art of Deception, goes further to explain that people inherently want to be helpful and therefore are easily duped. They assume a level of trust in order to avoid conflict. It's all about, "gaining access to information that people think is innocuous when it isn't," and then using that information against the real target. We are the weakest link in the security chain. This point cannot be underemphasized. People are the weakest link, not technology.

This article is a followup to a social engineering series written several years ago. The goal is to go beyond the basics and explore how social engineering has been employed as technology has evolved over the past few years. For further information on social engineering, see this author's previous article, "Social Engineering Fundamentals, Part I: Hacker Tactics" and "Part II: Combat Strategies."

Since social engineering involves the human element of any attack, it's important to get into the head of the hacker and understand her motivation. Historically, the motivation has been intellectual challenge, bragging rights, access to sensitive information, simple curiosity, or our biggest fear - malicious intent. By knowing why we are at risk, we can better protect ourselves from the foolish things we do, thereby allowing social engineers to exploit us.

Targets of an attack can be both physical and psychological. Social engineering attacks will occur in person, over the phone, and online. No medium is safe from them. Individuals are targets for rampant identity theft and businesses fall prey to exploitation of a variety of holes. Weak passwords are always a target, as are file backdoors and improperly set permissions. That's the obvious stuff. What's changed over the past few years is that borders progressively don't matter. Words like "cyberterrorism" have become mainstream and we now even have an FBI-organized counter-terrorism posse of hackers waiting to pounce in the event of a massive online terrorist attack. Even some of the best hackers will use social engineering techniques against a victim (in combination with a highly technical approach) because it's simple, easy, and very effective. Social engineering is everywhere.
Types of attacks
The biggest change over the past four years, since our original article series on SecurityFoucs, is the exponential growth of e-commerce. Browsers and the use of the SSL (secure socket layer) protocol now are the norm for viewing everything from financial data to party invitations over webmail. Those of us who still use pine for email are in the minority. The types of attacks we see today tend to be targeted more toward web applications. Hidden programs running on web sites and hidden programs in email enclosures opened through webmail programs can host all kinds of dangers.

Browser add-ons can mask all kinds of rogue programs. DDoS (Distributed Denial of Service) attacks are still quite common and are a royal pain to combat, but they're not increasing in number the way identity theft is. Malware continues to plague everyone, although the widespread viruses of the nineties seem to have taken a back door to the browser back doors, most often installed as drive-by spyware by visiting a website. VoIP (Voice over Internet Protocol), being the new buzzword, has also attracted attackers with results varying from authentication failures to crashing phones.

So how does social engineering fit into the picture? Before employing some of the techniques noted above, some preliminary social engineering can be incredibly fruitful. Footprinting - the art of gathering information (or pre-hacking), is like a robber casing a bank. It's commonly done to research a predetermined target and determine the best opportunities for exploitation. Footprinting can include anything from phone calls from a role playing person asking seemingly innocent questions to physically mapping out buildings and data centers. And footprinting is a major social engineering component of a choreographed attack.
Phishing trips
Phishing is the most common form of social engineering online, and most notably includes email spoofs. It's a rare day where the average email inbox doesn't include some sort of spoof. Today, eBay, Paypal and Citibank are the most common targets. Phishing itself is not new, but the frequency has increased over the past few years. The user receives email claiming that his Paypal account information needs updating and the email includes a link that sends the user to a fake web site where he is instructed to enter his password to update his information. The web site then stores the real passwords for use in identity theft attacks against the real Paypal site. For more information about phishing, see Scott Granneman's article, "Phishing For Savvy Users."

The best response is to delete these messages before even looking at them, just in case a rogue program might be launching in the background. However, to be sure a genuine message from a site like Citibank or eBay isn't being ignored, the best course of action is to log into their main site login, by typing http://www.ebay.com/, and then check the account for a record of the email or of any sort of problem. Due to the nature of phishing, you can't reliably click on a link in your email anymore and be sure it's what it appears.

In the case of eBay, go to "my messages" or "my ebay" to verify the authenticity of the email sent. Paypal doesn't have this feature yet. It's also easy to send a quick note to spoof@ebay.com or spoof@paypal.com, forwarding the message in question, and they will respond quickly as to its authenticity. eBay recently adapted their email sent to users to include usernames in the subject and body of the message, to emphasize authenticity. In general though, the best practice is to assume the email is a fake and remove it permanently from any email archives.
Case study - Company X
To illustrate the importance of incorporating social engineering education into a corporate security program, here is an overview of the security for a fairly typical high-tech company, called "Company X" for the purposes of this article. Company X, a multi-billion dollar organization, spends millions on hardware and security, but in reality it only does the minimum of what is necessary to keep its assets secure. Such is the life of an average security program in the competitive market of high-tech.

Source Article: http://www.securityfocus.com/infocus/1860

What Is FireWall

2007-04-30T07:36:00.000-07:00

Firewall use for filtering incoming packet and outgoing packet and firewall is one important thing to make your network secure. There are four kind of firewall :

1. Packet Filtering
2. Circuit Gateways
3. Applications Gateway
4. Hybrid Firewall.

For The Packet filtering it was provide to be 3 :

1. Dynamic filtering
2. Static Filtering
3. Stateful Inspection.

For more information about Firewall you can search on google or you can find on this link :
1. Firewall.com
2. Firewallguide.com

Investigating an Attempted Intrusion

2007-04-27T08:39:00.000-07:00

This text file is for a server administrator to be able to determain whether or not there is an attempted break-in or intruder, and what the approproate steps are.

This information was provided and written by OptikNerve. This text file is for a server administrator to be able to determain whether or not there is an attempted break-in or intruder, and what the approproate steps are.

Conducting the Investigation
Appropriate policies should be put in place to cover privacy issues and security incident handling before beginning an investigation. If you are intending to prosecute, or press charges against the intruder, then steps must be taken to protect the evidence that you have collected.

When activity occurs that you think could be intruders, there are 4 steps you can take to see if this is an attempted break-in or not.

* Log additional traffic between the source and the destination.
* Log all traffic from the source.
* Identify the system(s).
* Log all the contents of packets form the source.

Fallowing all four of the previous steps, you should make a determination as to wheather this is a attempted break-in or not.

Step 1: Identifing the System(s)
The first step that you would need to take to identify an attempted break-in would be to identify the the system(s) that the user(s) are using. With RealSecure, this could be as easy as just resolving the user's IP address and converting it into a hostname. If you configured the RealSecure console to use DNS, then click on the resolve host name button that is on the display screen. In rare occasions the host name cannot be found. If the DNS look-up fails, then try converting the IP address into a host name other ways (nslookup, dnsquery etc..).

You can use ARIN (www.arin.net) to convert IP addresses into host names, and NetSol (www.networksolutions.com) to lookup the address owner's contact/technical information.

If you cannot retrieve the user's information, it doesn't mean that he or she is attempted or has broken into your system. Successful identification of the host name or IP address doesn't prove that the activity is not an attempted break-in.

The source of this suspicious attack or traffic, may not be the best source of an attempted break-in. Denial of Service attacks (or DoS) attempts usually have spoofed addresses and unauthorized access attempts or probes may come from another system the user has already penatrated (someways like a Proxy).

Step 2: Traffic between source and destination
Seeing an event such as an IP violation or an overflow attack, might not provide the complete evidence of traffic between the destination and the source. It's also important to understand the context of the activity. A good example of this would be the Sendmail WIZ signature. RealSecure has an event that will identify an attempt to exploit the WIZ command in Sendmail. This event identifies any instance of WIZ in a mail message. If the WIZ occurs in the body of the e-mail/message, then it is clearly not an attempted intrusion.

Using RealSecure, a connection event is added to the policy for all traffic between the source and the "suspicious activity" and the destination (see table 01).

These logs will first give you an idea of what traffic is occuring between the source and destination. If the WIZ packet is the only traffic between the two systems, this tells you that it was most likely an attempted break-in. If you find a lot of SMPT/mail traffic between the two systems, you're most likely looking at normal mail traffic.

Step3: Logging traffic from the source
Assuming that the data collected in Step 2 was really unable to determine if the attempted break-in or attack was legitimate or not, you should begin collecting traffic from the source. The data collected might be somewhat limited, but that is expected. If the "attack" is comming from a remote network, you will only be able to view the traffic comming to your system. If the attack is local, you should be able to collect all traffic from the machine and be able to get a better view point on what is really happening or going on. To begin to collect all the traffic from the source, add your connection event (see table 02), to your RealSecure policy.

The connection event is likely to produce information that isn't at any value to the investigation that you are conducting. If you can view the traffic objectively, then this log will be of use to you to give you a good picture of the interactions that sre going on between the source and your system. You must look at the types and the ammount of each type of traffic without the preconception of an attack. Try to understand the traffic or activity that you are seeing. Is it mail traffic? Is it ping traffic? Is it web traffic? Does the traffic probe or come from the suspicious intruder on your system?

Hopefully at this point in time, you have collected the fallowing information:

* The name of the source system.
* The type and frequency of traffic exchanged between or from the source and your system.
* The type and frequency of traffic exchanged between or from the source and destination.

Table 01: RealSecure connection event example: Added to the policy to log attacker's activity. (see step 2)
Event Name Action Source IP Destination IP Protocol Source Port Destination Port
SUS_ACT Notify, Log Source of activity Destination of activity UDP, TCP, and/or ICMP ANY ANY

Table 02: RealSecure connection event example: Added to log all traffic from the attacker's source. (see step 3)
Event Name Action Source IP Destination IP Protocol Source Port Destination Port
SUB_SRC Notify, Log Source of activity ANY UDMP, TCP, and/or ICMP ANY ANY

Table 03: RealSecure connection event example: Added to log packet payloads. (see step 4)
Event Name Action Source IP Destination IP Protocol Source Port Destination Port
SUB_ACT Notify, Log, Log Raw, View Session Source of activity Destination of activity UDP or TCP ANY Port where the traffic is
SUS_ACT Notify, Log, Log Raw, View Session Destination of activity Source of activity UDP or TCP Port where the traffic is ANY

This information will give you a good idea as to the nature of this attack or attempt, but once again, this may not be enough information to prove that this is, or is not an attempted attack.

Step 4: Log packets from the source
The last thing you need to do is to log the contents of packets from the source. To be able to do this, modify your RealSecure policy as shown in table 03 above.

Logging the data raw and viewing their session, you can gather a completed record of the contents of the packets. Using ViewSession allows you to view the contents of packets without waiting for the database to be uploaded to the console. Logging the data raw allows you to create a permanent record.

There should be 2 connection events in the policy, one for every direction of traffic. This allows you to capture both ends of the connection. Try to limit the traffic capture to just one single port for each pair(s) of connection events, thus, letting you view the imformation more easily. If there are multiple targeted ports, then just add additional connection events.

After you have captured the data, trye and exime it. The information you just collected combined with all the other information and logs, should provide the answer to: Does the information that you have collected indicate that an attack is or was being made? If for some reason, you still cannot answer that question, do your best to find someone with past or present knowledge of protocol under investigation.

Examples
The examples that you are about to see will illustrate how these steps have been used in past (real) investigations. The IP and host names have been changed for privacy reasons.

Table 04: Medium-risk event: While installing RealSecure, this information became avialible when suspicious activity occured.
Event Risk Level Source Address Source Port Destination Address Destination Port Protocol Information
IP Protocol Violation Medium 10.10.2.20 80 192.102.2.1 1009 TCP Flags=21

Table 05: RealSecure connection events example: Four policies were added to the log between the source & destination.
Event Name Action Source IP Destination IP Protocol Source Port Destination Port
SUS_TCP Notify, Log 10.10.2.20 192.102.2.1 TCP ANY ANY
SUS_TCP Notify, Log 192.102.2.1 10.10.2.20 TCP ANY ANY
SUS_UDP Notify, Log 10.10.2.20 192.102.2.1 UPD ANY ANY
SUS_UDP Notify, Log 192.102.2.1 10.10.2.20 UDP ANY ANY

Table 06: High-risk event: While installing RealSecure, this information became avialible when suspicious activity occured.
Event Risk Level Source Address Source Post Destination Address Destination Port Protocol
Qmail Buffer Overflow High 172.39.2.1 123 192.102.3.1 25 TCP

Example 1: IP protocol violation
An IP protocol violation is when a packet that has a strange combination of TCP flags, and thats how RealSecure will trigger the event; so then we began our investigation. See table 04 for more details.

From the information that is provided, you can see that the source port implies the Web traffic, and that the source of the undefined traffic is a Web server (or httpd). The problem is that a new network reconnaisssance technique is to use the packets with multiple flags to identify the Operating System of the systems that are on the network.

Step 1
Next we began to try and find out the host name for the source, in which it was a host in Germany:

someone.somewhere.gr

Then, the destination was resolved as a client system:

name.our.url.org

The host name of the source didn't immediatly imply that it was a Web server (or httpd). Since there was no evidence that this was badly formatted Web traffic, we continued the investigation.

Step 2
To identify traffic that is passing between the source and destination, we added four rules to RealSecure (see table 05). We then decided to capture the UDP and TCP traffic between the two systems. If it were true, reconnaissance probe, we figured we'd only see misconfigured packets, but instead the results showed much more. They showed the Web traffic between 2 systems, so clearly, the origional destination was a Web server being accessed by a client browser. At this point, we were determined that we had sufficient evidance to indentify the event as a misconfigured server or a protocol stack producing badly formatted packets. Thus, meaning that steps 3 and 4 were totally unecassary.

Example 2: Qmail Buffer Overflow
We recieved this High-Risk event that was defined or indicated as a Qmail Buffer Overflow. See table 06 for a diagraph.

From the information that was gathered, you can see that the destination port is the SMPT or mail port. This implies that there is an attack against your mail server or mail daemon. Since the system wasn't running Qmail at the time, so we decided to look into this attack a little further.

Step 1
We then attempted to resolve the host names that were involved. The source would resolve and of course we already knew the destination's was the system's firewall. We then went to ARIN and Network Solutions told us that the source was a client system on an ISP (Internet Service Provider). We then of course continued the investigation.

Step 2
We identified the traffic passing from the source and destination by adding our policies that are shown in table 07. The only traffic that was logged, was mail traffic. We began to believe that this was just "normal" or legit mail traffic except with exceptionally long lines of data. We still didn't have any proof that was worth the while, so we had to continue the investigation.

Step 3
We then decided to modify the rules to collect all the traffic from the suspicious source to our network or system (see table 08).

The change we made provided nothing we didn't know already, or nothing useful. The source of the suspicious activity was only making connections to the out-going mail port or firewall on port 25.

Table 07: RealSecure connection events example: Four rules were added to the log activity between the source and destination.
Event Name Action Source IP Destination IP Protocol Source Port Destination Port
SUS_TCP Notify, Log 172.39.2.1 192.102.3.1 TCP ANY ANY
SUS_TCP Notify, Log 192.102.3.1 172.39.2.1 TCP ANY ANY
SUS_UDP Notify, Log 172.39.2.1 192.102.3.1 UDP ANY ANY
SUS_UDP Notify, Log 192.102.3.1 172.39.2.1 UDP ANY ANY

Table 08: RealSecure connection events example: These events were added to log all activity from the source
Event Name Action Source IP Destination IP Protocol Source Port Destination Port
SUS_TCP Notify, Log 172.39.2.1 ANY TCP ANY ANY
SUS_UDP Notify, Log 172.39.2.1 ANY UDP ANY ANY

Table 09: RealSecure connection events example: This change was made last to gather packet contents, which makes the final decision
Event Name Action Source IP Destination IP Protocol Source Port Destination Port
SUS_TCP Notify, Log, Log Raw, View Session 172.39.2.1 192.102.3.1 TCP ANY 25
SUS_TCP Notify, Log, Log Raw, View Session 192.102.3.1 TCP 25 ANY

Step 4
In order to make the final decision as to wheather this was an attempted break in or just normal traffic, we began to gather the packet contents that were causing the Security Event to trigger. We added then added the Log Raw and View Session to the Qmail Buffer Overflow signature, thus, the suspicious activity continued. Then we were able to gather serveral attack packets, and when we viewed the session, there were very long lines of data with a single repeating patteren which was "&pmca".

We believed that this was a case of a very long message line at that point. However, to make the final determination, we made one last rule change that can be viewed at table 09 above.

Soon after making the rule change, we gathered several connections that also set off the Qmail Buffer Overflow Security Event. We inspected the sessions and determined that it was in fact an e-mail message, and not an attack. The messages were still suspicious as they were chain letters with BADLY formatted MIME encapsulation, but it was not an attempted break-in or intrusion.

Conclusion
Intrusion Detection systems today, provide strong and many capabilities to detect suspicious activity and attempted break-ins. By fallowing the four steps that I have provided, one, should be able to determine the true nature of the activity and take the approproate steps torward what the attacker is doing.

Copyright Secure System Administrating Research, 1999 all rights reserved.
Article source : http://www.windowsecurity.com/whitepapers/Investigating_an_Attempted_Intrusion.html