I agree - definitely keep the OSSEC server on it's own box so it isn't compromised if the web server is compromised, and also so you can also delegate that same box as a central syslog box in case you have other servers you want to send logs to. The important thing to understand about OSSEC is that it is by no means a first-line of preventative defense. Meaning, if a skilled hacker knows *exactly* what he or she is doing, he could potentially get in on the very first attempt (for example, a well-crafted cross-site scripting or SQL injection attempt against your web server). This is because OSSEC is, by nature, reactive in that it needs to analyze the logs *first* before taking any actionable measure. That said, OSSEC can make it *very* difficult to profile and scan a server for vulnerabilities if you have it configured properly.
Depending on your web applications, there might be 'alternatives' to throttling back traffic and have OSSEC assist but mechanisms would likely need to be built into the web application itself. Essentially, if you can potentially blacklist IPs in the application, you could enable OSSEC active response on the OSSEC server itself and have it launch a script that queries the portion of the web app that would block the offending IP(s). I'm not sure about agentless active response otherwise. I think you would still need to have the OSSEC agent installed on each server. In fact, if you want to really offload everything to the OSSEC server with true AR, you could install the OSSEC agent on the web servers but disable file-integrity monitoring and log monitoring (essentially just have the agents running with AR enabled). Then have the web servers forward their Apache syslogs to the central OSSEC server and setup your active responses to launch on the web servers accordingly based on what happens in the logs. Hopefully that all made sense... it's a bit late for me so I apologize if not :) On Thu, Nov 10, 2011 at 9:46 PM, treydock <[email protected]> wrote: > > > On Nov 10, 11:16 pm, Tom Mostard <[email protected]> wrote: > > Hi, Jeremy, > > > > Since the OSSEC will be installed on the same server as the Apache > server, > > I thought OSSEC would use too much processing. > > Do you think that this would be a problem? The OSSEC "server" is gonna > > check the whole traffic - and it is a heavy traffic - , so it is going to > > use the CPU, a lot. > > > > It's going to be a Linux box, in the beginning, otherwise I'll use a > > FreeBSD. > > > > Thanks for the reply, > > > > Tom > > > > 2011/11/11 Jeremy Lee <[email protected]> > > > > > > > > > > > > > > > > > I think it's a great idea - I'm assuming this is a Linux box? You can > > > setup OSSEC to monitor the Apache logs and utilize active response to > ward > > > off potential abusers. Some time up-front will need to be spent tuning > the > > > rules, etc but it's well worth it. > > > > > If you have another web server (or more) for load balancing, you'd > > > actually want OSSEC setup in a server-agent configuration, with an > agent on > > > each web server reporting to the central OSSEC server. That way you'll > be > > > able to correlate across all web servers. > > > > > Hope that helps. > > > > > --Jeremy > > > > > On Thu, Nov 10, 2011 at 8:22 PM, Tom Mostard <[email protected] > >wrote: > > > > >> Hi, folks, > > > > >> I've got a newbie question, I hope someone can say something about it. > > > > >> I'm planning to put out a web server (running Apache) which is gonna > have > > >> a heavy load of traffic. > > >> And I'm wondering about installing OSSEC on this server. > > >> What do you guys think about it? > > > > >> In the future, I'm gonna have another web server for load balance. > > >> Should I install OSSEC on the both server, or should I think about > > >> another architectural design? > > > > >> Thanks, > > > > >> Tom > > If possible I'd recommend separating the server portion of OSSEC from > your production systems. This way if your public web server is > compromised it won't keep OSSEC from being useful to your other > systems. OSSEC's primary ability to protect web servers is by > monitoring the Apache logs, which actually doesn't use too many > resources. > > One alternative to monitoring the logs on your high traffic server is > using syslog to send all logs to a collection server and have OSSEC > monitor those files. That would keep the processing done by OSSEC off > the web server, but I'm unsure how active responses would work. That > part would take some tweaking. I've seen mention on this list of > having active response send it's commands to remote systems, such that > multiple systems block the same IP when any of the servers detects a > threat.
