Horst Herb wrote: > On Monday 09 October 2006 16:41, Tim Churches wrote: >> is very secure - easier said that done: witness hackers owning Horst's >> servers in Germany not once, but twice, via HTTP as I recall, due to >> insecure wiki CGI scripts written by third parties (is that correct, >> Horst? > > Not the http protocol that is the problem, but application security holes - > in > my case the combination of flaws in TikiWiki + PHP
Yeah, but the hackers got in and exploited the Web application security holes via HTTP on port 80 - that was my point - David wants to forward such access to a box on his internal network. > Main lesson learned was to mount temp directory as "non-executable" - the > intruder wouldn't have been able to do anything but delete temp files > otherwsie, but once he gained enough privileges to write to the temp > directory, it was a simple matter of installing a p2p server runing in that > directory as unprivileged user > > First time it was much worse - TikiWiki was installed by somebody else, I > didn't check - it was installed as a user with enough privileges to > compromise the whole system and that in fact happened then. > Lesson learned - always install web interactive software under a user account > with no other privileges than reading /writing the applications working > directory We are exploring the use of SElinux, which come standard in Fedora Core and RHEL, but can be compiled into other Linuxes I think - it allows one to really lock down what a Web application can and can't do - not just writing files, but access to ports, interacting with other processes etc. Even if hackers get root access, they still can't defeat an SElinux cage. Downside is that it is a complete pig to set up, and very few people seem to know much about it, even if you offer to pay for their expertise. > Aagin: http as such is not the problem. It is the application that interacts > via that protocol. Yeah, that's what I said... > Another reason to love RoR - if you use it's "Mongrel" web server, it appears > rather straightforward and transparent to secure the infrastructure that does > the web serving bit: for people with only modest traffic load (<100 > hits/minute) it does the trick without overly hard performance penalty One does need to be very careful with Apache (or other fully-fledged Web servers - IIS is even worse) - a minor and seemingly inconspicuous change to the config file can expose a lot on your system. For example, a lot of Apache installations come with mod_dav, which allows various applications to write files on the Web server via the DAV protocol (over HTTP) - that needs to be VERY carefully configured indeed... better to disable it. Anyway, there are heaps of tutorials out there on how to secure Apache - default Apache installations only tend to be moderately secure - but if you allow HTTP through your firewall as David wants to do, you want your Apache configuration to be VERY, VERY secure, I would think. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
