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-0004.html>