<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
nate wrote:
<blockquote cite="mid20060922142615.GA23174@campin.net" type="cite">
<pre wrap="">On Fri, Sep 22, 2006 at 03:18:50PM +0100, Hari Sekhon wrote:
</pre>
<blockquote type="cite">
<pre wrap="">After all, you couldn't somebody just write a loop to send garbage to it
and fill the whole machine up, not to mention drown out all other valid
logs so you miss any important events (oops, I am giving away too much
here?). I'm actually tempted to write an attack for this right now...
</pre>
</blockquote>
<pre wrap=""><!---->
This is always a risk. It's obvious enough that it's not discussed much.
syslog-ng has tcp wrappers support, and you always have packet
filtering.
You should certainly block unauthorized IPs, but your authorized IPs are
just as scary as the others. The miscreant will either be an authorized
user or have compromised an authorized account and will flood your
syslog server from there.
If you want to dicuss DoS, come up with a way to deal with that.
</pre>
</blockquote>
<br>
I agree. Unfortunately, the syslog protocol is insecure by nature and
therefore we are left with either old ip filtering which as you said
still leaves a problem, in that a miscreant will either be an
authorized user or have compromised an authorised user's account.<br>
<br>
In fact, it's even worse because you can simply spoof an address of a
real server to get through. It's even easier if you allow udp because
they could just fire off udp packets without even having to reply to
them and therefore you don't even need to take over the ip of the
spoofed machine.<br>
<br>
One possibility is that you could try and surpass syslog protocol by
allowing only syslog-ng tcp connections and providing some
authentication mechanism like certificates or keys or something, like
ssh keys or some other public private certificate system. Although the
overhead will be considerable, both in machine terms and humans admin
terms, but I can't think of any other way of really doing this at the
moment.<br>
<br>
Perhaps instead of the connection being authenticated, the packets
themselves could be signed, although I'm no cryptography expert to know
how secure that would be against forgery.<br>
<br>
Would it be more secure to use a tcp SSL tunnel using or something and
then set up tunnels for the syslog machines? Although highly secure in
that only specific machines could go through to the server and loop
back in to the syslog server, you'd be left with those servers being
the only points of failure regarding malicious users or compromised
accounts, other than the syslog-ng server itself.<br>
<br>
I feel that it would be a huge and difficult task to add serious
security to syslog-ng beyond this.<br>
<br>
just my 3 cents...<br>
<br>
-h<br>
<pre class="moz-signature" cols="72">--
Hari Sekhon</pre>
</body>
</html>