Wednesday, December 5, 2007

china, modern malware, and common sense

[china]

so schneier keys into an article over at the times online about china doing mass pwnage around the series of tubes... i find it interesting how china has been just flaunting the lack of order and law enforcement across international interconnected networks. i think the first real thing i heard about was Titan Rain, and it has gone on and on since then.

i wonder if china is going to force some type of global agreement on protocols for interfering in internet traffic in the name of security. something requiring the cooperation of ISPs to null route traffic from offending blocks or something... i donno what's gonna happen, but it seems like this can't go on forever, and we've been seeing ISPs arguing to interfere w/ traffic for some time now... i love the EFF, but i wonder if net neutrality is gonna win out or not...

anyway, the most fascinating bit in here (imo) is that a

security expert who has also seen the letter said that among the techniques used by Chinese groups were "custom Trojans", software designed to hack into the network of a particular firm and feed back confidential data


say wot dawg?!? lmao... so this reminds me of back in the day the first time i ever heard of chinese UO farmers who sat and clicked for hours on end to level grind characters and items to sell to players in the states and elsewhere. never before that moment had i imagined these tasks being mass-produced, but in great chinese modern tradition, they made it happen.

so here we have the same. now the idea of the dedicated attacker is tilted sideways. no longer are we talking about a lone hacker or small elite group attacking a singular target of interest for glory or profit... no, this implies a frickin chinese farm of malware authors doing recon, writing malware, and collecting data.

and not just from .govs, but it has moved into the private sector, w/ financials and the like...

personally, i'm amazed that this hasn't been brought to china's attention on a broader and higher political level. i mean, it isn't like they could claim ignorance of private citizens or organized crime doing these attacks when they've invested so heavily into monitoring and controlling the inet traffic flowing throughout their country...


[modern malware]

maybe i'm behind the times, but sunbelt points out malware which looks at user agent to differentiate between mac and windows and sploit accordingly...

anyway, i got a kick outta running across it b/c my very first bit of infosec writing was a paper submitted to a security site (before blogs existed, lol) kinda talked about this type of thing. basically, i said that future virii wouldn't be the single sploit variety we saw at the time. we'd see virii which contained multiple payloads and attack vectors, and would attempt to id the vulns of a host, and even mb perform priviledge escalation attacks. it was all very out there in retrospect, and i'd link to it if i could find it, but the best i've done is a google cache of a table of contents which contains the title of the paper...

anyway, i may have overdone the complexity and imagined it happening sooner than it did, but it seems we're getting there...


[common sense]

ok, i stumbled across this paper talking about span ports versus taps... i don't mean to dog on it, because it is fairly well written and seems pretty accurate, but it irritated me on some level...

it talks about the advent of the SPAN port, and how it was viewed as a great simplification of monitoring traffic flows across a wire... then it goes on to say that SPAN ports aren't all that great... why not? well, because you really can't use them in GB and 10GB environments... and b/c they change frame timing, and error frames often aren't forwarded, and you'll get packet loss if the switch gets overloaded, and some more stuff.

this is kinda lame of me to say, but all of the people i know who have ever wondered if they should use a tap or a SPAN for a given implementation are already aware of at least the basics of most of these issues.

plus, it ignores the fact that running a tap means that i'll be using two ports on my sensor, since every tap i've ever seen ran two outputs to allow for full throughput viewing of TX and RX on the RX of your sensor(s). in some situations, this is a significant downside to a tap. not to mention the fact that a decent 10/100 tap is gonna cost you at least a few hundred bucks (unless the market has changed a lot since i last looked).

also, if my switch is getting overloaded, i've got bigger problems than a few dropped packets to a span port... in my real world experience, most switches tend to hang at 1-2% utilization, and when they go up towards 40+% proc, you're experiencing trouble on your network...

i guess the bit about the article that bugged me was that it didn't seem to attempt to frame the discussion into the real world at all. in reality, there are a ton of enterprise level orgs that don't have anything close to GB inet bandwidth... not to mention the multitudes of mom n pops... similarly, there are tons of enterprise orgs which run internal GB and 10GB links who don't monitor their internal segments w/ IDS or traffic analysis tools. many of these orgs only monitor their ingress/egress points. not to mention the tons of mom n pop shops who don't run GB internally at all.

so i walk away from the article saying "taps are the only real way to go", but the reality is that in many cases dropping your IDS or analysis tool on a span port on the managed switch that the client/customer already owns will do the job great. it'll save them some money, and the org will be more secure. if i'm droppin 10 IDS's in at remote sites, i'm saving them a chunk of change for a small compromise in risk, and in my book, that is a net gain and a good security tradeoff in the real world...

it is a well written article tho...

No comments: