OSSEC on a high traffic web server

[Tom Mostard]

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

[Jeremy Lee]

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 

[Tom Mostard]

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 <jpl...@gmail.com>

[treydock]

I've been using OSSEC on all my public facing web servers (and now
internal due to recent compromise of someone else in my network) for a
little over a year, and am amazed at how much potential problems and
actual threats are thwarted. I'd HIGHLY recommend enabling the "route-
null" active response, as that will block ALL traffic to any IP seen
as a threat. I'd also recommend monitoring the active-response.log
file to be alerted of potential and known attacks. The alert is now
built into 2.6 but some useful info is here,
http://itscblog.tamu.edu/ossec-email-alerts-on-active-responses/. If
your running a tried and true CMS, you won't have much trouble, but if
there is development done on the server, you need to make sure to
whitelist any developer's IPs. Many times I've been doing changes to
a site and would generate too many errors which would then get me
blocked for 10 minutes. So now my desktop at work is white-listed.
Even my lower traffic sites are constantly getting trolled by bots
poking to find out if I have certain vulnerable applications
installed, but OSSEC does an amazing job at stopping all attempts.

An example...my multisite Wordpress server is constantly getting poked
at by bots looking for timthumb.php and various DB management apps.
Over time OSSEC will give you a good way of knowing what common things
attackers are looking for, and you can adjust accordingly.

- Trey

[treydock]

On Nov 10, 11:16 pm, Tom Mostard <capmosta...@gmail.com> 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 <jpl...@gmail.com>
>
>
>
>
>
>
>
> > 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 <capmosta...@gmail.com>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.

[Jeremy Lee]

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 :)

[Joe]

On Nov 10, 2011, at 9:16 PM, Tom Mostard wrote:

> The OSSEC "server" is gonna check the whole traffic

OSSEC won't check network traffic like an Intrusion Detection System (snort) or Web Application Firewall (mod_security). It will monitor your Apache logs for known web attacks.

As recommending, it's best to just install the agent.

Since your webserver is exposed directly to the internet, I recommend increasing the frequency of syscheck. A lot can happen in 86400 seconds. I run it every 15 minutes, but that's my choice and it works for me.