If you try the location method before I get a chance, let us know if it works or not.
On Fri, Oct 1, 2010 at 1:26 PM, blacklight <vphu...@yahoo.com> wrote: > Yo, you are a pal :) > > > On Oct 1, 1:18 pm, "dan (ddp)" <ddp...@gmail.com> 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 <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
