Yo, you are a pal :)
On Oct 1, 1:18 pm, "dan (ddp)" <[email protected]> wrote: > 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 <[email protected]> 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/[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
