Steve Youngs wrote:
>
<snip>
>
> This assumes that the intruder has write access to your filesystem.
> By this stage it is too late. And whether you use modules or not is
> not going to make much difference. The intruder could just as easily
> overwrite your kernel image with an evil one, re-run lilo then cause
> the system to go down for reboot.
>
<snip>
You do not understand. A typical cracker will not aim at your computer.
It will be far too uninteresting. A typical cracker will try to use your
computer as a relay to other - perhaps more interesting - machines in
the local network, e.g.
So if he installs new programs or a new kernel, it will be detected by
tripwire the next time you run it.
If he needs to install a new kernel and therfore reboot the machine,
this will definitely not go unnoticed. But if the compromise is
detected, there will be counter-measures and the cracker will have to
start from the beginning, perhaps even waiting for the lan to become
publicly connected again.
So the main target at which he will aim is to compromise a box, install
a Trojan Horse to sneak passwords and the like and make its intrusion
invisible by editing the syslog and so on. But against all such things
exist counter-measures (mailing of every syslog entry to another
machine, e.g.) that any decent security-aware admin will take.
A compromized system is not so much of a problem as long as the
intrusion is readily detecteand counter-measures taken. What is REALLY,
REALLY a problem is when a Trojan Horse sits in you LAN and sneaks all
your users passwords, analyzes network traffic, installs Trojans on
other boxes in your LAN and does any other ugly thing you can think of
for weeks WITHOUT being detected. Then the intruder can hit your LAN
quite hard once he feels the time is right.
Having said that, said module would be absolutely perfect for that. It
could
1.) Hide itself through replacement read/write syscalls
2.) Switch your eth card into promiscuous mode and quietly anylyze your
traffic and mail the results to your address
3.) Sneak password by listening to the keyboard and installing itself on
other - more central - boxes.
4.) Faking your backups for a few weeks
5.) On Dec, 24th issue rm -rf / simpultaneously on all machines it
compromized.
Marc
--
Marc Mutz <[EMAIL PROTECTED]> http://marc.mutz.com/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics
PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)
