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

Thu May 24 17:06:43 UTC 2007
Dexter Ang <thepoch 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.


I guess I'll have to read up on openvpn then. My problem is that I usually
have to monitor  "on-the-go", basically anywhere and everywhere.

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.


I've already set up all PHP apps to require SSL by forcefully redirecting
using a .htaccess file. Didn't think about the basicauth part though. Though
judging from the comments I get, I'll probably just avoid exposing any PHP
apps as much as possible.

> 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
>
> IMHO, reducing exposure by reducing access is the best thing you can do.
>
> Hope this helps!


Any suggestion definitely helps. High appreciate the tips and references.

dex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos/attachments/20070525/a504d371/attachment-0005.html>