Re: how to detect successful intrusions

On Wed, 09 Aug 2006, in the Usenet newsgroup comp.os.linux.security, in article
<pan.2006.08.09.09.26.39.125000@xxxxxxxx>, Rob van Riel wrote:

Moe Trin wrote:

It can if you don't give them access. That's a major key to security.

True, but an air gap firewall also lock me out. As long as I can access
the system from the outside, the outside has access as well.

Yes, but now you should start looking at probabilities. Anything _can_
happen - I _could_ be abducted by four beautiful women, plied with drink,
and.... but I rather doubt that's going to happen.

Hence the question about detection after the fact. Absolute security is
not possible given the requirements of the system, so I need to take into
account the possibility that security will fail.

Will they have physical access? If so, you are screwed. There is nothing
you can do in that case.

Not really. Let me digress for a moment into a different arena. Both

<Good idea snipped>

See my reply to Unruh's post for reasons why I wouldn't trust these
otherwise sensible tests.

I'd suspect that you want to think more about this technique.

Maybe I am paranoid:-)

"It's only called paranoid when they AREN'T after you"

OK, let's look at your reply to Mr. Unruh. You write:

--------
Some unpleasant character breaks into my system and changes thing so that
next time I log in myself, I end up logged in to a virtual machine running
inside the real one, that looks exactly like the real machine (in effect a
honeypot VM running on my machine and intended to keep me unaware of the
fact that my machine has been taken over). I wouldn't know how to set this
up myself, but it's probably possible.

Yes, it is possible. The bad guy would have to load (at least) a kernel
module that hides his activities. If the person manages to do so, you'd
likely find it very difficult (if not impossible) to detect directly. What
you would see is the opposite, meaning if you broke something by for
example replacing some critical application, you _wouldn't_ see a problem
because the bad guy is hiding the information from you - sort of like you
can't see a cloud on a moonless night, but you can detect that it's there
because you can't see the stars.

You can make this somewhat more difficult by other means. One example is to
use "read-only" media. Where I work, our publicly visible servers are run
from CDs, so that while you _can_ (perhaps) subvert the running kernel, you
can't permanently take over the system. This can further be made more
difficult by not using a modular kernel - BUT the difficulties occur both for
the bad guy AND the legitimate user.

Therefore, to test the integrety of the machine, I would have to take it
offline (I _DO_ still control the power supply), and either reboot it from
trusted media or move the harddisk over to a trusted machine for analysis.

except that this would not detect a RAM resident program. It _would_
remove it for the moment, but the bad guy could reinstall it later using
the same hole he got in through in the first place.

----------

It's not the many I'm not running that have me worried, its the very few
that I do have....

Another thing that makes it difficult for the bad guy is the wide variety of
Linux distributions. Which one are you running? If you've ever tried to
install a winmodem driver, you'd be aware that they only work for a specific
distribution and release. A driver (or mal-ware module) is going to be quite
specific to how which kernel was compiled. Do you have the needed compiler,
compiler tools, and header files installed?

Ah, yes, nut unfortunately for me, there's only one Joe User on my system.
If that account goes up in pyrotechnics, I'm toast. The only advantage
then of having a *nix box is that cleaning up the mess afterwards is
easier, because I don't have to rebuild the entire environment.

and the backups are located where? My sister and I retain backups for
each other. They're encrypted, and we live over 4000 KM apart, but on
the Internet, that's about 0.040 seconds. I don't need to back up the
entire system - only the data and configurations. Last year as a test, I
rebuilt a system (I was actually replacing the primary fileserver with
new hardware), using the install CDs and then grabbing the data from
across the country. That was actually the slow spot, as I was only
getting about 10 Megabytes per minute, and it took nearly two hours to
copy all of the data. Bottom line - not quite three hours to rebuild a
file server from scratch. I could have but that time in half using the
local backups.

Old guy
.

Relevant Pages

  • amd64 bitops fix for -Os
    ... filesystem, the kernel mostly hangs. ... When optimizing for speed, the generated code is such that the flags ... Obviously the asm statement must not rely on the compiler setting up ... -inline long find_first_zero_bit(const unsigned long * addr, ...
    (Linux-Kernel)
  • Re: amd64 bitops fix for -Os
    ... > kernel build. ... because its inline asm assumes at least one iteration ... the generated code is such that the flags ... although in a perfect world the compiler would be ...
    (Linux-Kernel)
  • Newbie Q: spca5xx webcam driver installation problem
    ... with the included default makefile. ... Building SPCA5XX driver for 2.5/2.6 kernel. ... # Setup the tools ... # Setup compiler warnings ...
    (comp.os.linux.setup)
  • Re: Problem setting up lm-sensors
    ... >> they built the kernel. ... >> Why does the Makefile not use .config? ... >> I assume no one wants to see that 727 line Makefile. ... >> question as to what compiler I should use. ...
    (comp.os.linux.misc)
  • Re: [INFO] Kernel strict versioning
    ... >> if you have the same kernel version on identical machines, ... And kernels compiled with one compiler are different than those compiled ... And it has distinctions on dozens of other configuration options too. ...
    (Linux-Kernel)