locks keep lawful people out...    

The Security Skeptic

Dave Piscitello's Security Weblog

Skeptic (sceptic): a person inclined to question or doubt accepted opinions.

Web www.corecom.com The Security Skeptic
Mon, 30 Jun 2003 00:00:00 00, 105
Server Load Balancing
Server load balancing is an effective way of improving or maintaining web server performance. If you are not familiar with this concept, you may find my column, Server Load Balancing Concepts (and the vClass) helpful.

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID105 by Dave Piscitello  


Sat, 28 Jun 2003 00:00:00 00, 75
National Do Not Call Registry

Finally, a service from the FTC to reduce unsolicited telephone calls!

Visit The National Do Not Call Registry, register your phone number(s), visit the hyperlink the FTC emails you, and most telemarketers must abide by Federal Trade Commission "Do Not Call" provisions of the Telemarketing Sales Act, and cease calling anyone who has registered phone numbers with the FTC.

Some of the teeth of this legislation are missing. Organizations with - you bet, considerable lobby influence - can still call you. So who might these be? Long distance phone companies, airlines, banks and credit unions, insurance businesses, political organizations, and telephone surveyors.

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID75 by Dave Piscitello  


Fri, 27 Jun 2003 00:00:00 00, 76
W32/Sobig.e@MM

While not a particularly malicious worm, W32/Sobig.e@MM spread pretty fast. What's remarkable to me is just how many copies I've received - over fifty! - and they are likely to still come until the virus deactivates on July 14, 2003.

Symantec has a virus removal tool, and a so-so description. I'd really like AV companies to explain more about whether the virus is perceived as a proof-of concept, etc., At least Symantec doesn't throw FUD like many other AV response centers (I hate the blanket "Horrors! A virus! It will damage your computer!" missives so many .edu centers post).

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID76 by Dave Piscitello  


Thu, 26 Jun 2003 00:00:00 00, 74
Greylisting

Evan Harris has published an interesting paper describing a method of thwarting SPAM at Message Transfer Agents rather than at the user level.

The article, The Next Step in the Spam Control War: Greylisting, explains how MTAs can exploit a characteristic of spamming applications that Evan calls "fire and forget": basically, spam engines blast through their lists of recipients once, and apparently ignore SMTP errors. Harris explains that by blocking initial mail delivery attempts (distinguishable by "triplets" the MTA maintains), and returning a temporary failure code, spamming applications are thwarted but legitimate mail is not permanently blocked.

This looks like an interesting but probably short-lived solution. Spammers will eventually break down and expand their grubby little applications to circumvent the block attempts.

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID74 by Dave Piscitello  


Thu, 19 Jun 2003 00:00:00 00, 73
What requests are failing at your web site?

I routinely run a terrific (and free) log analyzer, Analog, on my web site. One of the helpful features of the reports Analog generates is pie charts. The pie chart I find very helpful, and informative, shows failed requests. Here's a recent example, illustrating 3 months of web activity:

The chart shows that Microsoft's URLscan blocks a big chunk of what are presumably automated web attacks. I can tell from some source IPs associated with this failure that my addresses fall into someone's scan range. The source's never change, so perhaps these are systems owned by an attacker (unknown to their operator). It also shows that ultra-conservative Dave blocks access to robots.txt for fear of bad bots, spiders and crawlers. Last and sadly, it shows just how persistent probes for Nimbda and variant vulnerabilities really are.

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID73 by Dave Piscitello  


Legality of Honeypots Legality of Honeypots

Lance Spitzner, a pioneer in Honyepots and Honeynets, has published an interesting column at SecurityFocus.com entitled "Honeypots: Are they Illegal?" This is coincidental to a four-part series Network World has delivered through push email that describes Honeypots (I commented on the 1st of these in an earlier blog).

If you are unfamiliar with the subject, read my honeypots primer at Core Competence's web site.

Although he qualifies his commentary by disclaiming any authority on legal issues, Lance offers helpful opinions about the legality of honeypots in three areas: entrapment, liability and privacy.

I absolutely concur that honeypots are not a form of entrapment: attackers aren't coerced into breaking into computers, and entrapment is a moot issue if you are not a member or agent of law enforcement.

Privacy, Lance tells us, is a mirky water. I particularly like his recommendation regarding banners and the benefit they bring (read the column!).

Lastly, there's liability: if an attacker uses your honeypot to deface Microsoft's home page, are you liable? More importantly, are you any more liable than if they used any other computer under your administration?

Honest, read the column. Buy Lance's book. Visit the Honeynets project.

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID72 by Dave Piscitello  


Mon, 16 Jun 2003 00:00:00 00, 69
Denial of Power Attack (Theoretical)?

The susceptibility of SNMP to attack is well-known. Here's a theoretical SNMP-based attack one could launch against an intranet or server farm. I think an attacker can spoof server (and client) systems that monitor a networked UPS into shutting down.

Assume

  • you find a way into a company A (e.g., from war driving or trojan)

  • company A uses SNMP to monitor UPS

  • company A's SNMP read-only community string is default, easily guessed, or captured off the air/wire

First, the attacker scans the SNMP port until he finds responders. Next, the attacker walks the MIB to verify the device is a UPS. Spoofing the IP address of the UPS, the attacker issues the trap upsTrapOnBattery (described below), indicating a very small value of estimated minutes of battery remain to all IPs in the same subnet (perhaps the attacker refines this by reading the list of trap recipients to possibly determine which are management stations and which are servers since he doesn't want to notify the management stations.

Won't at least some servers respond to the trap by shutting down?

Is this wild speculation or yet another reason to find a more secure way to manage networks than SNMP?

The IETF UPS MIB trap upsTrapOnBatteryis as follows:

upsTrapOnBattery NOTIFICATION-TYPE

OBJECTS { upsEstimatedMinutesRemaining, upsSecondsOnBattery, upsConfigLowBattTime }

STATUS current

DESCRIPTION

"The UPS is operating on battery power. This trap is persistent and is

resent at one minute intervals until the UPS either turns off or is no longer

running on battery."

::= { upsTraps 1 }

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID69 by Dave Piscitello  


Fri, 13 Jun 2003 00:00:00 00, 71
Microsoft, the AntiVirus Company: DOUBTing FUD

Microsoft announces they are entering the AntiVirus market and the fear, uncertainty, doubt - and paranoia - is unleashed.

FEAR! Should the major antivirus players close shop and find new products and markets? Will Symantec, Trend Micro, NAI, et. al. fall by the wayside as TCP/IP stack vendors did almost a decade ago (does anyone remember FTP Software and its brethren? does anyone care?)

UNCERTAINTY! Will MSFT's AV product compete and conflict with my favorite product? Will this spur another decade of lame litigation and even lamer settlement?

PARANOIA. Ohmygod! Can't you all see that this is just another example of how Micrsoft will control our collective minds and computers through its insidious Windows Update? We've got to STOP them!

For me, the buck stops at DOUBT.

Even if the consumer market embraces Microsoft's AV solution - a big IF indeed - I doubt Microsoft will satisfy the enterprise market for AV for a long time, if ever. Too much of Microsoft's orientation is "individual PC": in its current incarnation, Windows Update doesn't have the controls enterprises need to manage large user populations. There's also the AV gateway market, and coordination across desktop/gateway products. I'm betting that Symantec, et. al., won't be shifting markets any faster than Philip Morris. Many people might choke on the notion, but there's an argument to be made that if Microsoft had not included a TCP/IP stack in Windows 9x, the consumer Internet would not have materialized. Ask yourself: what percentage of the consumer Internet population would install TCP/IP correctly? (Answer: about the same percentage as installs 3rd party IPsec software).

While we're talking about Windows Update, I think it's time to lighten up. For the average consumer, Windows Update is not dramatically different than A/V definition update processes. By and large, we're talking about an overwhelming majority of PC users who mostly shrug their shoulders when informed of the privacy implications, if they react at all. Be honest: when you venture outside the security and technology crew you hang with (please say you do this on occasion), do people talk about worries over Microsoft's intrusion on your privacy, or do they ask you how to Google?

I'm ready to concede that consumers want and need automated maintenance, especially when it comes to security. My colleague and friend, Marcus Ranum, ranted in response to the National Strategy to Secure Cyberspace that:

"If the feds want a CyberStrategy that really helps secure the critical infrastructure they should mandate and enforce use of personal firewalls and anti-virus capabilities on every Windows, Mac, and UNIX machine in the federal government."

I'll argue here that non-government consumers need A/V and PFWs just as much. Aren't the frequency of PC intrusions, DDOS and spam zombies ample evidence we just might need this?

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID71 by Dave Piscitello  


Thu, 12 Jun 2003 00:00:00 00, 67
Worm propagation and Routing Instability

James Cowie and Andy Ogielski of Renesys Corporation published a paper entitled "Global Routing Instabilities during Code Red II and Nimda Worm Propagation" in September 2001 that described how two major worm incidents - Code Red II and Nimbda - adversely affected the global routing infrastructure (both more so than the September 11 attacks). The authors speculate that, as the worms propagated, scans on web servers induced congestion, affected flow diversity, and also caused certain internet access routers to shut down. Organizations began disconnecting networks.

Such events are supposed to stimulate routing protocol updates to adapt topology and traffic flows, but they occurred too quickly for the Border Gateway Protocol to respond appropriately. Cowie and Ogielski offer fascinating histograms of BGP activity to corroborate their claim.

Tim Griffin's paper, "BGP Impact of SQL Worm, 1/25/2003" illustrates how BGP histograms from the more recent SQL Slammer worm incident provide additional evidence that worms adversely affect Internet routing. Slammer, however, was frighteningly faster than its predecessors, and offers grounds for speculating how "flash worms" might be used to disrupt the Internet in even grander proportions.

Ido Dubrowsky does a nice job considering both papers in his June 11 article, "Effects of Worms on Internet Routing Stability ", where he draws the sobering conclusion that we need to "build even greater resiliency into the Internet infrastructure to prevent such events from recurring with even more impact."

Find Cowie and Ogielski's paper here; Tim Griffin's paper here; and Ido's paper at Securityfocus.com.

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID67 by Dave Piscitello  


Anecdotal Evidence that AV Gateways Help

Minor data point for people who ask "does an Anti-Virus Gateway really help?"

Over the past 11 days, the AntiVirus gateway operated by my ISP detected and quarantined 53 infected email messages and attachments. Only one infected email reached my workstation. Fortunately, eyeballing the message from the suspicious sender,support@microsoft.com, convinced me to discard rather than open it. I learned of the worm this email was propagating about 20 minutes later, and downloaded appropriate virus definitions shortly thereafter.

I spot-check the efficacy of the AV and Anti-SPAM gateways provided by Hargray, and I can't help but conclude this is an increasingly necessary layer of defense, and a "must-have" service when you are selecting a provider for home office and small business Internet service.

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID66 by Dave Piscitello  


Wed, 11 Jun 2003 00:00:00 00, 65
SPAMmer tricks - The Privacy Policy Sleight of Hand

I occasionally examine the hundreds of blocked emails my Postini Anti-SPAM service quarantines. After 10 minutes, I always arrive at the same conclusion:

SPAMmers are truly invertebrates.

They'll resort to any sham or scam to convince you and law enforcement (such as it is) that what they transmit is legitimate. The latest thinly veiled excuse appended to SPAM is a trailer that suggests it's YOUR fault. Here's an excerpt from an increasingly popular SPAM trailer:

"Why was this email sent to you? At some point you registered or made a purchase on a Web site with privacy policies explaining that they may share your information with partners who will send you valuable offers from time to time. "

Notice that the message does not indicate that the sender is a partner of that web site operator, nor that the sender actually obtained your email address from that operator.

It's abuse, plain and simple. Forward it to whatever anti-SPAM service you're using and help stamp out SPAM.

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID65 by Dave Piscitello  


Tue, 10 Jun 2003 00:00:00 00, 70
Security Vulnerability Reporting and Response Guide - DISCLOSURE Guidelines at last?

The Security Vulnerability Reporting and Response Guide is available for free download via the OIS.

This is a draft report prepared by the Organization for Internet Safety. OIS is a consortia of security companies (@stake, BindView Corp., The SCO Group, Foundstone, Guardent, Internet Security Systems, Inc., Microsoft Corp., Network Associates, Oracle Corporation, SGI and Symantec) They hope to help organizations improve security through the adoption of a formal process for reporting (disclosing) vulnerabilities to vendors and garnering timely vendor response.

The report is out for public comment, so download and RTFR!

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID70 by Dave Piscitello  


Mon, 09 Jun 2003 00:00:00 00, 64
Mission Work 2003

I've been away with my son on an Episcopal Youth Community mission trip to Sewanee, Tennessee since June 1st.

You can view a photo journal of the services we performed for an under-served and very poor appalachian community here.

As part of his community service, Dave swapped his laptop for a manly, heavy-duty ditch witch.

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID64 by Dave Piscitello  


Mon, 02 Jun 2003 00:00:00 00, 63
Do I want a SOHO firewall or NAT box?

A recent post on the firewall-wizards mail list asked whether a small office firewall offered more security than a NAT device.

The ensuing thread reveals a lot about how difficult it is to characterize small office security and access products into these simple categories.

One thing I'm very confident in stating is that:

All firewalls do NAT, but not all NAT devices do firewalling...

All the firewalls I've ever configured, small office or enterprise class, do at least one form of NAT - IP masquerading, a.k.a., dynamic NAT, which is more accuratley called Port Address Translation - where the only public IP address revealed to the outside world (Internet) is the firewall's public IP address. Most enterprise firewalls do static and 1:1 NAT (you can read more about all three here.

Today, it's hard to classify devices as firewall appliances or NAT devices. A look at the history (such a short time span probably only deserves to be called a chronology of events) of SOHO access and security devices reveals why.

In the broadband access marketplace, access devices began as little more than xDSL and cable modems. Early broadband "consumer" users and service providers heavy into consumer markets were ignorant of the need and hence reluctant to buy small office firewalls; i.e., the kind that do (stateful) packet inspection, terminate manly VPNs, and block some set of well-known denial of service and broadly automated attacks. These were and remain 2x-5x the cost of NAT devices, and for good reason.

Consumers did know they wanted to share broadband access across home and small office networks, and service providers (even the bad ones) realized they didn't have enough IP addresses to hand out like after-dinner mints, so NAT was quickly incorporated into modems to make everyone happy. The result was an access modem that does address and port remapping, elementary (two-port) routing or bridging, and service/authentication using some PPP variant (e.g., PPPoE).

If a NAT Device filters traffic, is it a firewall?

Some vendors added DHCP, a piddly set of security features (simple default inbound and coarsely adjustable outbound filters) and even a VPN - whatever they could squeeze into a commodity-priced product - and everyone began calling these devices SOHO firewalls.

Most "began as NAT" devices fail at least one basic litmus test: the NAT/firewall software doesn't undergo the kind of software audit, testing, and scrutiny firewall vendors are accustomed to imposing (inflicting) on their appliances.

Add any feature set you want. Claim a box is a firewall. Until you've scrubbed the code and subjected the device to accepted, common firewall evaluation criteria and it proves its mettle, it's a NAT box.

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID63 by Dave Piscitello