ClearNet Security: Tag ids

The booming exploit market and bye bye to swaths of products

tate@ClearNetSec.com (Tate Hansen) — Thu, 31 Jan 2008 23:50:00 -0700

There are lots of articles mentioning the Digital Armaments bounty for exploits. I wrote a snippet on the commercial exploit market about a month ago, whereby I was simply listing the prices for subscribing to the different exploit houses.

I guess I forgot to consider another complexity of all this and that is from the influence the organizations who compete to purchase exploits are having (e.g. iDefense, 3COM/TippingPoint, Governments, people and groups w/lots of money).

I wonder how extensive this really goes – I mean, it seems this market is in a boom of sorts which implies there are lots of private exploits trading hands. Exactly how many would be interesting to know. Hell, any numbers would be nice.

One thing is apparent though, if this market continues to grow then how can any security products based on “knowing attacks” succeed? They won't. An IDS vendor is not going to be able to afford to purchase all; no company will have a monopoly.

building a better security events system

tate@ClearNetSec.com (Tate Hansen) — Sat, 30 Jun 2007 15:56:00 -0600

It’s hard to build a decision support system based on partial views of the world.

My goal is to identify interesting events on a network and to prioritize those events based on sets of attributes. Yes, there are lots of products that do this. But most focus on a slice of the world (e.g. an IDS fires an alert based on a regex match on a single packet). And that is boring.

Doing it for the whole world is where the action is at.

Capture an alert fired from an IDS, check netflow for a session, note a “first-time” event recorded in a syslog message, mix in statistical data mining and learning techniques – and do it all in near real time. This is how things get interesting.

Unfortunately it’s hard to get complete visibility (i.e. get all syslog, all netflow, all application logs, etc.). There must be a point though where I can get enough information to successfully prioritize interesting events. I’m not sure exactly where that’s at, but it’s a fun problem to work on.

The picture is of the inside of IT-Universitetet in Copenhagen where I’m working for a few weeks. The meeting rooms all jet out into the open space in the middle – a pretty cool design.

Time for an IDS?

Cory Stoker — Fri, 27 Oct 2006 15:37:00 -0600

Often we run into a scenario where a client wants to improve security by implementing an IDS. Now this is OK but often we find out that they are not exactly "ready". What I mean by this is to effectively deploy an IDS on a network you should first cover your bases with what you already got. Before going IDS wild, are you using your existing infrastructure to get the knowledge you need first?

Of course just throwing out an IDS is a quick hit; it can cover your ass if the regulatory audit kids drop by, but for lots it becomes a security lame duck. Do you know how to really make it a valuable component of your security?

"Yeah we have [insert IDS vendor here] in place off the 6509."

"Sweet, what does your ruleset look like?"

"Well I think we have all rules enabled right now."

"Ok, what networks are you watching?"

"We want to see both ways so we are not restricting the nets."

"Do you know what kind of traffic and how much are you seeing?"

"Well, not really, but we have all the usual suspects: SMTP, HTTP, HTTPS, FTP and even IM."

"Do you know how much activity you’re seeing for each of those?"

"Man, we just threw it out there, its working!"

Yeah, that $20k went far. The point is to get off this copy-cat buy and forget.

First, I am a believer in doing the macro before the micro. You can’t pick whether a rule should be enabled or not until you know what’s going on in your network. Enabling all will protect you is bullshit. In fact, enabling all can make things worse (easier to exhaust resources, get blinded, or rev up the false positive counters). And forget about dealing with IDS evasion techniques.

Take logging, a macro thing. Logging is an enabler. Deducing traffic patterns is a macro enabler. You need to do these things first before considering an IDS. Engineers like to complain how hard it is to watch logs and I can empathize, but it is really not that hard to get some valuable numbers. Which firewall rules are taking hits, which are not? What kind of traffic are you seeing and how much? A couple scripts can get you those numbers.

So before you do the IDS thing, do these things at a minimum:

Grab your firewall rulesets and the counters for each allow/deny rule. With this you info you can teach your IDS where to look (vitally important both direction so ingress and egress).
Learn traffic patterns. What protocols are in use, which networks, and in what amounts. High, average, low - all good numbers. Use this to tune the rulesets. Now you can identify something like your top 100 talkers. If some server catapults to #1, check it out.\
What apps are running. Learn all the things your environment is hosting. When do your backups run, which servers like to talk to which? Again, information vital to getting value from an your infrastructure that will enable you to get even more value from your IDS.

Scan fast and evade triggers

tate@ClearNetSec.com (Tate Hansen) — Tue, 14 Mar 2006 03:48:00 -0700

I've wanted to build this for a long time, alas the pain and costs of obtaining disparate public IPv4 blocks is high. I want to perform 65k port scans fast, accurately, and avoid 95% of the IDSes, IPSes, or whatever other ‘smart’ devices are in my way. It can be done.

Buy or lease some servers
Find a few data centers that connect to different Tier 1 providers
Justify and purchase IP blocks from ARIN (or another regional registry)
Setup scan server(s)
Setup NAT server(s)
Write some code to distribute port scans
Feel cool when you can scan like crazy
Feel really cool when no ‘smart’ devices alert, block, or rate limit you because you haven’t triggered any threshold ‘rules’
Act surprised when the client mentions his team didn’t see or report any anomalous behavior

Here is a high-level diagram of what I want:

Of course, there are some realities which make this hard to build. Registries prefer to hand out contiguous net blocks, but it would be far more desirable to have a bunch of smaller non-contiguous net blocks. Some ‘smart’ devices do detect scans based on the source net block, not just via a single source IP. Bandwidth and latency conditions are always in play. I still want it. A scan setup like this can increase accuracy, be fast, is distributed, and raises the difficulty for detection.

FYI: Initial costs from ARIN for different net block sizes

Category	Initial Registration Fee (US Dollars)	Assignment Size
X-small/ Micro-allocation	$1,250	/24 - < /20
Small	$2,250	/20 - /19
Medium	$4,500	> /19 - /16
Large	$9,000	> /16 - /14
X-large	$18,000	> /14