nate wrote: 
On Fri, Sep 22, 2006 at 03:18:50PM +0100, Hari Sekhon wrote:
  
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...
    

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.

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.

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.

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.

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.

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.

I feel that it would be a huge and difficult task to add serious security to syslog-ng beyond this.

just my 3 cents...

-h
-- 
Hari Sekhon