Re: Suggested way to remotely monitor servers and networks these days?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On 5/24/07, Walt Reed <centos@xxxxxxxxx> 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux