At the end of May, I left my claustrophobic apartment in Silicon Valley
for our grand move to Seattle. No, I'm not going there to work for
Microsoft, thank you (Good Linux/Unix suggestions welcome, however...).
It was a sad day. No, I wasn't sad to be leaving the horrible heat, the
strip-mall-ville skyline, or the land of a thousand midriffs. Good
riddance, I say. I was mourning the moment when I would power off my
machines and put them in boxes for the big move.

Four machines, each with uptimes of a year or more. Sure, I had to
reboot for a kernel upgrade now- and-then just like the next guy, but
that's it in the Linux and Unix world. Take that, Bill. (Whoops, I guess
he's a neighbor now.) My machines had performed flawlessly, through
blackouts and earthquakes [1]. However, one machine that had been
running the most smoothly was the one that was failing to do its
function.

I'd set up a honeypot on one of the systems. It was running a two year
old intentionally-outdated Linux distro full of bugs and instant-root
holes. In the year it'd been running, no one had gotten in.

I had an IDS set up to watch the network and, with extensive host
logging enabled, I could see that tons of attempts to break in had
occurred. Most of the daemons were running with holes -- old Wu-FTPd,
POP and IMAP bugs -- pretty much everything but Apache had some problem
that should have been exploitable to grant you shell access. Quite a few
brute-force password cracking attempts were made, but I did have strong
or locked passwords on all accounts, so I didn't expect those to
succeed.

So what was keeping all these buggy programs from being exploited? The
machine was running Linux, but not on a PC. Instead, I'd installed it on
the only spare machine I had: an old Sparc 5.

All the entry points were buffer overflows and format string bugs. Most
of the attacks were simple automated exploit scripts built from exploits
or proof-of-concepts that were released to BugTraq and other full
disclosure locations. Most of the code released to these venues tries to
prove a vulnerability can be exploited, but only concentrates on the
most popular Linux computer architecture: the x86 CPU.

Sun Sparcs use a completely different CPU architecture. A compiled
binary on a PC won't run whatsoever on a Sparc; same goes for any other
foreign machine like Alpha, MIPS, etc.... The attackers who had grabbed
the public exploits were all trying to use PC shellcodes, which could
crash the affected servers but wouldn't ever compromise them. So,
because the CPU couldn't run the code supplied by the attackers, it
stayed relatively safe in spite of the fact that it was horribly out of
date.

Now, I'm not suggesting that you put Linux on machines with non-x86 CPUs
and consider your security process completed. Different CPUs make the
cracker's job harder [2], but had any of the crackers wanted to get into
this machine, it should have been trivial. They wanted to break into
*any* machine, not this one in particular. Since their scripts didn't
crack it, they didn't try to get into it manually. They'd doubtless have
better luck somewhere else anyway.

So my Sparc honeypot experience left me with one conclusion: Invest in
more floor space and put up a PC if I wanted to watch the bad guys in
action.

Or I could install Windows....

NOTES

[1] The only earthquake we noticed during our three year sentence in
California was a 5.2 about 30 miles away. Had we left a few weeks
earlier, we wouldn't even have had that one.

[2] I'll even argue with this comment myself. It's not harder to create
Sparc shell code, per se, it's just that more folks write their
exploits assuming an x86 processor. Thus the attacker must
write/borrow Sparc shell code to use instead. It's this extra level
of effort that most newbie crackers don't have, or don't bother
investing. Had they been determined, it would have taken another
half hour of research and testing to adjust their scripts to account
for alternate CPU types. The problem is that many attacks result in
only two possible outcomes: The attack is successful and they get
access, or the affected daemon crashes and they don't have a second
chance to try a different exploit.

» posted by ITworld staff

ITworld

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine