Date: Mon, 19 Feb 2001 11:30:09 -0800 From: "Edward W. M." <edward_wm@hotmail.com> To: cjclark@reflexnet.net Cc: fbsdsec@killaz-r-us.com, freebsd-security@FreeBSD.ORG Subject: Re: Fw: Remote logging Message-ID: <LC4-LFD3tgx8VUkRacU0000021d@hotmail.com>
next in thread | raw e-mail | index | archive | help
Crist J. Clark <cjclark@reflexnet.net> writes:
>Not much point. You can always send a SIGKILL which cannot be caught
>by the process. The attacker would have to cooperate by sending
>syslogd(8) a SIGTERM or SIGINT, but why would he do that?
Exactly, so here's an idea. What if we moved syslogd into the
kernel and set up a sysctl knob for turning syslog on and off
(syslog.active for example). Each activity change would be
logged, of course.
So what's the use of that, you might wonder. If remote logging is
set up, the intruder could write a script that would take down
the network interface(s), turn syslog off and bring the network
interface(s) up again. He could also use ipf or ipfw to block
outgoing syslog traffic.
Well, that's where 3 other sysctl knobs come into play:
- net.ifs_immutable (boolean)
if set to 1, the active network interfaces cannot be
brought down or changed in any way
- syslog.net.incoming.prevent_block (boolean)
if set to 1, any attempt to block incoming syslog packets
(with ipf/ipfw) would fail
- syslog.net.outgoing.prevent_block (boolean)
if set to 1, any attempt to block outgoing syslog packets
(with ipf/ipfw) would fail
Perhaps there would be a syslogctl, which would take arguments
like:
- start, stop, restart, status and other standard syslogd arguments
this is all self-explanatory (status would display remote logging
settings and the relevant sysctl values, among other things)
- secure options
the following matrix explains best what each option would do
to the sysctl values:
syslog. syslog.
net. net.
net. incoming. outgoing.
ifs_immutable prevent_block prevent_block
secure 1 1 1
secure in 1 1 X
secure in only 1 1 0
secure out 1 X 1
secure out only 1 0 1
secure off 0 0 0
All changes would first be logged, then attempted and then
the change status would be reported (success/failure). That way
if someone does take over your machine, they will have to turn off
at least one of the sysctl values, which cannot go undetected
anymore. And if the status change report after the attempted
change report message is missing, you can be sure that the
attacker has done something to prevent further networking
activity.
If they take the network interface down, they will not be able to
forge the status change report message. If they block outgoing
syslog packets with ipf/ipfw, they will have to inject the forged
syslog status report packet at a lower level in order to circumvent
ipf/ipfw rules. Even if they were successful, you would notice that
something is wrong because there would be no syslog activity from
that host (no mark for example).
Last, but not least, the kernel would prevent any attempts to bind
the syslog socket when syslogd would not be running, so syslog
spoofing to remote machines would become more difficult. The bottom
line is, regardless of whether the attacker would manage to make it
look as if syslog were still active on a certain host, you would know
for sure that a syslog status change has occurred, so you could set
up a script which would send you an SMS upon detecting any such
change. That would give an attacker a few minutes at best, so they
would have to be really well prepared and organized to be able to
pull off anything that goes beyond rendering the system useless. In
any case, you would know that something is wrong, what you would do
with that information is entirely up to your security policy (or
should I say vigilance and diligence).
Well, it was just an idea.
Edward W. M.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?LC4-LFD3tgx8VUkRacU0000021d>