Alvin Oga wrote:
> i think that if you leave the attackd box alone..
> you have an easier time catching the attacker...
> - assuming that is the goal... as it would be
> for some of our customers ... catch um red handed..
This particular attack is a worm.
The "hosts" of the worm probably dont even know their affected.
> running tripwire and other ids are good and bad...
> - bad because its too late...they got in
> - bad to use tripwire..because youdont have the original
> version ... tripwire tells you the binary been tampered
For completeness sake, lets say Tripwire tells the files/directories
modified.
Most OSs these days have some form of package management system
allowing you to restore files which you identified as changed.
You could say, an LKM (or other kernel/system-file mods) can obscure the
results you see, but that can be counteracted if you boot from a known
clean,
forensically-geared CD, etc etc...
You could go on forever with attack->solution scenarios.
Most scenarios i can think of can be defeated by proper forensic
processes,
you just need to decide when the cost of acheiving the information you
seek
outweighs the cost of the information itself.
> - tripwire will flag more false "possible attacks" than
> it does in catching the hacker in the act
Tripwire was designed to track changes not "attacks".
That being said, it is also true that day-to-day system changes can
obscure malicious changes to the viewer of Tripwire output.
If you follow good practices (document, backup and reset your tripwire
DB
after applying patches, etc) it helps unobscure system from malicious
changes.
Agreed, this may not always be possible, espescially if there are many
changes to the system, or lack of Administrative resources to fulfill
this
requirement, etc etc..
> - good because you MIGHT find them but probably not...
> - tripwire typically runs once a day...
> - it only takes say 5 minutes to get into the
> server and hide yourself..
You get out of security as much as you put in. <tm>
If you don't put the effort into patching, monitoring, then expect to
someday be rebuilding your system from scratch because you have no
way to tell when your system was in a good state last.
> security is a risk and how much time and energy and resources
> iand competency you have...vs the attackers... hopefully
> one can stay one step ahead ???
I wouldn't say thats entirely true.
Security is about managing risks. There will be risks you can manage,
and there will be risks you cannot. (The dog ate the Tripwire DB
etc....)
What makes a good security manager is the ability to manage risk
efficiently,
not technical superiority over attackers.
Eg: Joe Bloggs may not know ASM, but he knows enough to recover file A,
and apply patch B to restore a compromised system.
Being technical does help though! :)
Regards,
Chris.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
