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

Walt Reed centos at kplex.org
Thu May 24 10:44:43 UTC 2007


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

IMHO, reducing exposure by reducing access is the best thing you can do.

Hope this helps!



More information about the CentOS mailing list