Introduction: Intrusion Detection

CS 493/693 Lecture, Dr. Lawlor, 2006/01/20

Talk about syllabus.  Talk about prerequisites.  Talk about HW1, bug/exploit/patch cycle.

Intrusion Detection: Before the Compromise

Packets dance across the ether.  Bad packets. 

Can you tell good traffic from bad?  Always?  Usually?  Can your firewall?

Intrusion Detection: After the Compromise

You sit down in front of a computer that's been compromised.  You ask the computer to list all the processes running.  It then lies to you--the list of processes leaves out the executable busily sending gigs of spam from your machine.  You ask the computer what files have been changed.  It lies again--it leaves out the entire directory containing the spam bot.

Is this paranoia?  Not really-- Sony's Neil Diamond CD contains software that does exactly this!

The problem of lying hardware is akin to the "self-reference" problem in logic.  As the computer says, "All computers are liars".  (Or "This sentence is false.")

It's also akin to the old "mole" problem in intelligence agencies.  How do you know your spies are really working for you, and not just selling your secrets to Osama?

How do you catch a liar?  Inconsistencies.  Did the breakin itself show up in the logs, or has it been erased?  Is the paging and network behavior consistent with what the computer says?  Does the disk look the same after I boot from a known-good CD? How do I know you're really a cop?

The Stereotypical Security Hole: Buffer Overflow

The classic writeup of buffer overflows is hacker Aleph-One's "Smashing the Stack for Fun and Profit".  Go read it.

Complete vulnerability and exploit example