> In this case, one would suppose that the system would use the audit tools
> (though they could simply be compiled and placed on the system in binary
> form, which may be a better compromise.)
Yep!
> Insecurity isn't a result of tools on the host, it's a result of poorly
> written services, libraries and OS'.
Hummm . . . maybe. Some tools, because of their task, have issues no
matter how they are written. Any development system under the sun has
this problem. Executables maybe be ammune because their config files
cannot be changed.
> Don't count on it. It's not that difficult to format a piece of memory
> and use it as a RAM disk, mount a remote disk on another compromised
> machine, etc. Solving the problem, rather than solving the predominant
> symptoms is more difficult than it would first appear.
Hummm . . . not if you do not have the device file created and have no
way to configure one. hehehehehe! Like I said . . . minimal.
> This means that loss of network connectivity to the log host is a good
> denial of log attack.
Only if you log using a NIC that is public. You could use a NIC whose
only purpose is to support the firewall.
Paul
---------------------------------------------------------------------------
Paul B. Brown [EMAIL PROTECTED]
President
Brown Technologies Network, Inc. http://www.btechnet.com/
Systems and Applications Design, Development, Deployment, and Maintenance
---------------------------------------------------------------------------
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
