Don't Panic. Plan
Connecting to the Internet means exposing your network to attackers, from script kiddies to skilled black hats. But the situation is not as dire as you might believe. We consulted
April 28, 2003
![Network Computing logo Network Computing logo](https://eu-images.contentstack.com/v3/assets/bltde8121fc52c5c8f3/blt3f3d0318f746b1c2/65a530e4187606040a1d8b8c/placeholder.png?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
The key is in understanding the attack types. After gathering and interpreting data from a variety of sources--including CAIDA (Cooperative Association for Internet Data Analysis), ISS (Internet Security Systems), NIST's ICAT and Security Focus--and conferring with people on the information-security front lines, we came to several conclusions about the real dangers your organization
faces from Internet-borne attacks and how you can minimize your risk.
Reconnaissance Mission
An attack's progression is straightforward, typically following a well-defined set of steps. Getting root or administrative privileges is often the attacker's goal (for a detailed account of an actual attack see "Anatomy of a Network Intrusion").
The first phase is network reconnaissance. The attacker discovers as much as he or she can about the target using public databases and documents, as well as more invasive scanners and banner grabbers. Once services have been identified, the attacker tries to discover vulnerabilities, either through more research or by using a tool designed to determine if the service is susceptible.Know Who's Out There
Local & Remote Vulns / Loss Typeclick to enlarge |
Connect to the Internet and within moments you will see attack activity in the form of port and network scanners--a Network Intelligence customer who runs a relatively small network says he receives thousands of scans per week.
We charted the scan sources and targets for the top five active ports, as reported by the Internet Storm Center, on a specified date (see "Top 5 Port Scans for March 18, 2003"), and discovered that a relatively small pool of IP addresses scanned a large number of IP addresses. During this 24-hour period, ISC logged 9,598 unique IP addresses scanning for Port 445, which is used for file sharing (SMB) on Microsoft Windows 2000, and logged 161,532 targets of port scans for Port 445--roughly 16 times as many targets as sources.
From a damage point of view, scans typically are harmless. IDSs classify scans as low-level attacks, but they don't harm servers or services. Common wisdom says scans are precursors to attacks, and though that may be true, there isn't a 1:1 relationship. If Port 445 is open, that doesn't guarantee the attacker will return, but it does make it more likely that he or she will.If an attacker finds services with exploitable vulnerabilities, the attack phase begins. If your servers are vulnerable, attackers may be able to get access to the computer or to data stored on the computer. Attack methods fall into two categories: automated and targeted. Much like scanning, automated attack tools are easy to build and will blindly try attacks against every host in a netblock or find hosts using a port scan and then attack. Either way, these brute-force attacks count on the probability that vulnerable servers will be running. Check your Web server logs and you'll likely see Unicode-encoded URL strings, regardless of the operating system or Web server running.
Automated attacks and worms are opportunistic and, like scans, are part of daily life on the Internet. There isn't much you can do to block these attempts, and unless you can track their origins and get someone at the source organization or upstream ISP to intervene on your behalf, you can't really stop the attacks. Some ISPs and many college campuses will cut off users if they receive enough complaints coupled with evidence that an attack has originated from their networks. Filing a report with the owner of the netblock or its upstream provider is an option if you are under a concerted scan or automated attack.
Top 5 Port Scans for March 18, 2003click to enlarge |
Fast-spreading worms are particularly vicious. The authors of an analysis published by CAIDA, "The Spread of the Sapphire/Slammer Worm", estimate that a single instance of a worm could infect seven hosts per minute, plus or minus one minute, with the resulting infected population doubling every 8.5 seconds, plus or minus one second. Sapphire, for example, peaked in about three minutes at 55 million scans per second, eventually exhausting the available bandwidth of various networks and leveling out its scan rate. "Top Five Security Events" (below) shows the startling effect of worm activity. The number of attack events for common protocols remains relatively stable. The attacks on Port 1434, used by Sapphire/Slammer, show the impact. Worm writers are getting better at building propagation methods and as a result, worms are picking up many of the reconnaissance techniques used by targeted attackers.
Writing a smart worm is a challenge, and we should consider ourselves lucky that common worms and viruses don't really do any serious harm. One of the surprising conclusions of the CAIDA report is that, even for applications with deployments of fewer than 20,000 nodes on the Internet, a worm still can spread very fast. It's not just widespread software that can be used to wreak havoc. If you develop software and want to perform in-depth security testing, check out our review of Cenzic's Hailstorm Protocol Modeler on page 103.
An Easy Mark?
Targeted attacks are much more dangerous than random scans because your organization has been singled out for a takeover. Whether the coup succeeds depends on a number of variables, but knowing you've been targeted is crucial. Finding out the goal of the attack is the next step.
Top 5 Security Eventsclick to enlarge |
The bad news: The more skilled the attacker, the less likely he or she will be noticed during the attack. The good news: Targeted attacks comprise a small portion of overall attacks, and successful targeted attacks are rarer still. For example, in 2002, ISS Managed Security Service noted 5,052 incidents, encompassing port scans to severe attacks, but only about 80--1.6 percent--were severe enough that ISS' Emergency Response Service needed to deal with the attack.A whopping 82.53 percent of all attacks originated on North American computers, according to ISS' "Top Attacking Regions From October 28, 2002, to December 31, 2002". Perhaps it's the high U.S. per-capita connectivity rate or the number of unpatched and unmaintained systems on campus and broadband networks that are used as relay points by attackers trying to cover their tracks. The truth is there's no way to tell if the attacker is sitting at the keyboard of the attacking computer or if he or she is hopping through multiple systems.
You could try to track the attacker by starting at the system that's directly attacking you, asking the person who administers that system to track the attack to the next hop, contact that administrator, get him or her to track the connection to the next hop, and so on. Of course, you will have to deal with multiple languages, convince others to help you, hope they have the technical experience to ferret out the next hop, and so on. Unless you're planning to prosecute the attacker and are willing to call in the feds, this is a fruitless pursuit.A large number of tools attack well-known vulnerabilities for which patches or workarounds are available. It's not uncommon to find two- to three-year-old vulnerabilities in systems on the Internet. Let's face it: There are so many vulnerabilities that it's hard to avoid some weaknesses in a system. Roughly 3,920 new vulnerabilities were discovered between January 2000 and March 3, 2003, according to data from the ICAT Metabase. Of that total, nearly 1,400 remote vulnerabilities are classified as high severity, meaning an account can be had on the target and the target can be taken over (see "Local and Remote Vulnerabilities by Severity Since 2000").
The overwhelming loss type with a high severity classification is security protection (see "Loss Type by Severity Since 2000,"). Security protection is defined by ICAT as giving the attacker privileges he or she is not allowed to have according to your access-control policy. Security protection can be subclassified as "obtain all privileges such as root or administrator," and "obtain some privileges," which corresponds to access less than root or administrator. It's not surprising that security protection has the highest number of vulnerabilities because the goal of most attacks is to get shell access via a command prompt or by executing commands through a vulnerable application on the remote system. Once shell access is gained, you can kiss your protection good-bye.
Local & Top Attacking Regions / Attatck Destination By Sectorclick to enlarge |
The types of vulnerabilities indicate where the bulk of vulnerability searching is focused and where weaknesses can be found: Error classes are designations indicating the type of error condition. Input validation, design and boundary errors (see "Vulnerabilities by Error Class,") make up the lion's share of vulnerabilities as classified by Bugtraq's Security Focus team. Input validation describes a vulnerability where input is not validated as syntactically correct or the application doesn't correctly handle extraneous or missing fields. As more applications are ported to a Web model, we expect to see more input validation-class attacks. In contrast, boundary errors are buffer overflows where an attacker exploits a programming error that allows the attacker to execute code. Design errors are more difficult to correct and range from poorly implemented algorithms to shoddily designed user interfaces.
Using ICAT or Bugtraq, you can get a feel for known vulnerabilities and, provided you keep current with patches and subscribe to vulnerability mailing lists or your vendors' security lists, you can mitigate the risk of connecting to the Internet (for a review of patching products see, "PatchLink Helps Keep Windows Closed"). Although there are many rumblings of zero-day exploits--malicious attempts to take advantage of a flaw before the vendor issues a fix--there are few identifiable examples. The best you can do is keep your systems patched, implement appropriate security measures, and root for the good guys.
Vulnerabilities by Error classclick to enlarge |
Thanks to ISS; the NIST ICAT team; Johannes Ullrich, CTO for the Internet Storm Center; CAIDA; and the Bugtraq community for supplying data and answering (often numerous) questions during the preparation of this article.
Mike fratto is a senior technology editor based in Network Computing's Syracuse University Real-World Labs®; he covers all security-related topics. Prior to joining this magazine, Mike worked as an independent consultant in central New York. Write to him at [email protected].
Post a comment or question on this story.When you connect to the Internet, you are going to be scanned and attacked--but you can fight back and win. The key: Be consistent and methodical in your response. Keep current on patching, implement sound network-configuration practices, and keep up to date on current dangers. These organizations can help:
• CAIDA: The Cooperative Association for Internet Data Analysis is a group of commercial, government and research entities working to build a robust and scalable global Internet infrastructure.
• ICAT Metabase: A searchable index on computer vulnerabilities, ICAT provides very granular search capabilities and links to vulnerabilities and patch information.• ISS Security Center: Security tools vendor Internet Security Systems' X-Force security intelligence is touted as the No. 1 security advisory, representing 45 percent of all vulnerabilities discovered by commercial research entities.
• Security Focus: Owned by Symantec, the SecurityFocus site hosts the Bugtraq mailing list and a forum for security experts to discuss new IT threats and attacks as well as ways to prevent security breaches.Full disclosure--publicly disclosing the details of vulnerabilities--has long been the subject of heated debate in the security community and remains a double-edged sword.
On the one hand, full disclosure holds a vendor's feet to the fire so it will fix vulnerabilities quickly. The whole movement to full disclosure was in direct response to vendors ignoring security problems, and 62 percent of readers polled for this article say vendors wouldn't fix problems if they weren't exposed. Publishing vulnerabilities with working source code or step-by-step instructions proves that a vulnerability exists and forces vendors to acknowledge the problem while allowing software users to check their systems for holes. Of course, these codes and instructions also land in the hands of any script-kid who can work a browser.
The question is: Does the benefit of full disclosure outweigh the value of nondisclosure or limited disclosure? A move to nondisclosure--for example, making disclosure a criminal offense--would take us back to the bad old days before Bugtraq was started. The underground would have all the tools, and vendors would keep problems quiet. Cynical? No, just realistic. Vendors aren't inherently evil, but they aren't going to spend money where they don't need to, and fixing vulnerabilities costs money. Perhaps the Environmental Protection Agency has the right idea: Companies are forced to properly handle hazardous materials from cradle to grave or face expensive fines, the cost of clean-up and possible criminal prosecution brought about by Superfund legislation.
Partial disclosure sounds feasible. Announce the vulnerability, but don't give out details. Although that initially keeps exploit code out of the hands of script-kiddies, any programmer can use the information in partial disclosure to shorten the development time of a working exploit. That isn't much better. The side effect is that you have to rely on the vendor that created the vulnerability to fix it, and you can't check that the fix worked. And let's not forget that leakage happens.Ninety-six percent of those polled say full disclosure serves as a check and balance to vendors, which otherwise wouldn't fess up to security vulnerabilities. The famous tagline used by L0pht Heavy Industries, now @Stake, "Making the theoretical practical since 1992," was in direct response to Microsoft, which had stated that a vulnerability was highly theoretical. Now, that doesn't mean vendors should be surprised by vulnerabilities announced on public lists. Many researchers notify vendors about security problems and work with them until a solution is found, and many vendors have programs in place to support vulnerability reporting. As long as researchers and vendors work together, the Internet community is served. Full disclosure works.Before you start throwing stones at neighbors with vulnerable networks, take a good look at your own network. Traffic flows are two-way streets and screwed-up configurations affect systems near and far. It takes a village to raze a network.
In some cases, you may have to get your service provider to make configuration changes for you. It's worth the hassle--the more relatively minor misconfigurations get fixed, the better off everyone will be. In no particular order, here's a checklist to get you started:
• Filter outbound traffic: If the firewall is blocking only inbound traffic, you're using only half its capabilities. Start identifying necessary outbound traffic and disallowing everything else. Doing so makes getting data through the firewall more difficult.
• Filter your egress: Your organization should know what subnets are hosted on the network. Allowing only traffic originating from those subnets to traverse the border router or firewall prevents traffic with spoofed source addresses from passing. Enable antispoofing at the router.
• Disable directed broadcasts: Directed broadcasts are a side effect of networking. Send an ICMP Echo Request to a network broadcast address, and all available hosts will respond. There is little need to allow directed broadcasts--or any from from foreign networks. Disable directed broadcasts at the router.
E-Poll Resultsclick to enlarge |
• Block protocols at the router: Some traffic--such as NetBIOS, SNMP and some ICMP types, including echo request, time request and subnet request--shouldn't traverse the border. Just drop it all at the router and be done with it. That way, even if a badly configured firewall crops up, the traffic won't leak out.
• Implement tiered defenses: If you have one border router between your network and the world, what happens if it is compromised? Examine your traffic flows and design your network to restrict flows even if components fail.
You May Also Like
Maximizing cloud potential: Building and operating an effective Cloud Center of Excellence (CCoE)
September 10, 2024Radical Automation of ITSM
September 19, 2024Unleash the power of the browser to secure any device in minutes
September 24, 2024