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