Thinking about it a bit more, I don't think it's a bad idea. Just not sure how it would be implimented.
I have one idea on how to do it with currently available source, but I'm not sure it's possible. I've asked though, so hopefully I'll have an answer soon-ish. If it isn't possible to do it in the way I'm thinking, there may be a bribe of beer or something involved to make it possible. :P I'm also wondering (and not able to try it out at the moment) if the "location" option is available in rules. Usually location is the agent name or filename the alert came from. If that is indeed an available option it could help solve the problem of the multiple app01's. On Fri, Oct 1, 2010 at 12:40 PM, blacklight <vphu...@yahoo.com> wrote: > 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/ossec-list@googlegroups.com/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 <ossec-l...@michaelstarks.com> > wrote: >> On Fri, 1 Oct 2010 07:36:55 -0700 (PDT), blacklight <vphu...@yahoo.com> >> 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
