The scalability problem comes in two ways: (1) While all our OSSEC agent hosts have unique FQDN's, the relative host name i.e. the name that appears in the agent host syslog for example, may not be unique. For example, app01.applesauce.com and app01.bananapeel.com have the same relative host name in their respective syslogs: app01 We might want app01.applesauce not to block the source IP host but we might want app01.bananapeel to do just that. So, if the correct syntax for <hostname> is <hostname>app01</ hostname>, we would be in trouble. I am not sure that using an IP address or an FQDN for <hostname> will work because I believe that the OSSEC server reads off the <hostname> directly from the log entry.
(2) Let's say that on a customer subnet, we have five hosts that we want to whitelist. We would have to derive a rule for each one of them. Right now, we are managing 150+ hosts - I could end up writing up quite a few rules :) There are quite a few situations where we want whitelisting where the source or attack IP is a host whose behavior creates log messages on the target host that fall under a rule that triggers an active response, but where we know the source or attack IP is harmless. We definitely would want active response to be triggered to protect the target host if the source or attack IP were any other host. I have done some research in the meantime: [ossec-list] Re: Can agents have their own white list which adds to the server white list? http://www.mail-archive.com/[email protected]/msg02761.html The ossec-list discussion thread (year date 2007) just above seems to indicate that the rule method is more fine grained than the outright whitelist method, but Peter Abraham's objection to the rule method is the same as mine: we are monitoring lots of agents and we could be adding to the clutter with as many rules. Again, if agents could be whitelisted at the agent rather than at the server, the manual configuration work would be simpler. Is there a way to whitelist at the agent level? If not, is there another option aside from the rule method? The whitelist method at the server is too much of a blunt instrument for us. On Oct 1, 11:55 am, Michael Starks <[email protected]> wrote: > On Fri, 1 Oct 2010 07:36:55 -0700 (PDT), blacklight <[email protected]> > wrote: > > > I just spoke with my boss - the method I ran by you is cumbersome and > > lacks scalability. Is there a way to get whitelisting implemented at > > the agent level? > > I'm a bit confused. The rule method is easy to implement on the manager > and is effective against the one host, which I understand is your goal. > Whitelisting the IP for all active responses is also easy to implement on > the manager and easy to do. Where's the scalability problem? > > -- > [I] Immutable Security > Information Security, Privacy and Personal > Libertyhttp://www.immutablesecurity.com
