Security Concerns about the nsca daemon

[Andreas Ericsson]

Marc Haber wrote:
> On Wed, Feb 22, 2006 at 11:08:30AM +0100, Andreas Ericsson wrote:
> 
>>Marc Haber wrote:
>>
>>>And while we're at it, nsca should use tcp-wrappers itself so that it
>>>can be tcp wrapped without having to add inetd to possible attack
>>>vectors.
>>
>>Nopes. I could implement some basic tcp-wrappers-like thing in the nsca 
>>core, but I won't make it use tcp-wrappers.
> 
> 
> Why? linking against libwrap is quite easy, I am told. Most programs I
> am aware of control libwrap linking via ./configure option, so that
> feature could be turned off if undesired.
> 

I'm not even going to argue against this. I *know* that writing 10 lines 
of C code is faster and better than doing some arcane m4 magic to detect 
the presence and usability of a possibly buggy libwrap.

> 
>>It'd be much better to do 
>>some simple firewalling anyway.
> 
> 
> That's be one more line of defense. tcp wrappers can do much more than
> simple filtering, such as logging ident and/or allowing access
> depending on ident answer.
> 

Such things are easily spoofed, and for "ident" to work the connecting 
server needs to be running identd which is just plain stupid (so nobody 
does it any more). Besides, logging a connection attempt requires a 
single line of code. Not exactly a tiring task.

nsca already has sufficient access validation (the password in the 
config file). That said, doing "allowed_hosts" verification is so simple 
it's laughable, even if you allow network ranges.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642