[CentOS] Suggested way to remotely monitor servers and networks these days?

Sat May 26 14:25:41 UTC 2007
Matty <matty91 at gmail.com>

On 5/24/07, Walt Reed <centos at kplex.org> wrote:
> On Thu, May 24, 2007 at 08:36:11AM +0800, Dexter Ang said:
> > I'm just wondering what is the recommended way of monitoring servers and
> > networks remotely. My current setup is to install and configure cacti and
> > nagios. I've set these up to require SSL. This way, I can easily go to them
> > and login from wherever I am and monitor (almost) everything I need to
> > monitor.
>
> I've setup some services like this where I configure the firewall to
> only allow access to the tools from known IP addresses, and then setup
> openvpn to allow access from unknown IP's.
>
> Another option is to put all PHP / restricted apps in SSL protected
> areas, and then use apache basicauth to restrict access to the php
> application, not relying on the application to provide security.
>
> > The problem is that leaving cacti open was the most stupid thing I've done.
> > After checking /var/log/httpd/error_log, I saw that someone exploited a
> > cacti php file and the result was:
>
> <snip>
>
> > which immediately downloaded ShellBOT to /tmp and executed it. It was a good
> > thing I caught this as early as I did. So, what's everyone elses solution
> > these days? Or is it simply a matter of creating a /tmp partition and
> > mounting it noexec?
>
> I mount /tmp with nosuid,noexec and this is normally OK, but I have run
> into a couple issues.
>
> For example, some RPM's fail to install because they run a script from
> /tmp during the process. HP driver / utilities  are notorious for this.
>
> On an unrelated note, I don't know WHAT it is about PHP, but I've seen
> more remote exploits from PHP apps than anything else.
>
> http://www.securityfocus.com/news/11430
> http://blog.php-security.org/
>
> It's enough that I'm very close to banning all PHP applications from my
> site, or at least require all php apps to go through a security audit
> before they are deployed. There are other things you can do too:
>
> http://linuxmafia.com/faq/Security/php.html

In addition to the suggestions listed in the link above, you shoud
apply the hardened PHP (formerly known as suhosin) patch to your PHP
source code, and ensure that your PHP binaries are built with
exec-shield support. Exec-shield and the hardened PHP patch will
protect your PHP environment against most stack, heap and integer
overflow attacks, and will provide some breathing room when the latest
PHP security vulnerability is announced. If your interested in setting
it up exec-shield and installing the hardened PHP patch, check out the
following links:

Exec-shiled white paper:
https://www.redhat.com/f/pdf/rhel/WHP0006US_Execshield.pdf

Building and installing the hardened PHP patch:
http://prefetch.net/blog/index.php/2006/10/15/securing-php-installations/

Thanks,
- Ryan
-- 
UNIX Administrator
http://prefetch.net