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