Sponsored by listeners like you
Get ready… next weekend you find out if all your systems were actually patched. We’re definitely interested in hearing the war stories on this one. In this episode George and I discuss more on DST patches and a handy utility for taking care of your systems. We also chat about more virtualization and cover lots of good listener feedback.
Enjoy!
Links mentioned in this podcast:
RIM Blackberry DST Risk Scenarios
George’s Awareness Posters
CentOS
Groundwork Open Source
Network UPS Tools
Server Technology
EVDO
Community Server
Inno Setup
Access to MySQL Tool-Bullzip.com
IntelliAdmin Network Administrator
Seagull Scientific-Bartender MS Patch Notice
VMware Fusion Beta
Parallels
Other sites mentioned in this podcast:
ARRL
Hello-Radio
Mike Tech Show
PaulDotCom Security Weekly
In re “SuperDuper” (I’m a registered user) a new version was released last week; it may have fixed any network issues. (I have yet to try it over a network, but maybe I’ll try it sometime this week.)
You mention that you’re looking for another source for servers. I’ve used PogoLinux for servers and I’ve been happy with them.
Hey guys,
Thanks for mentioning Server Technology during your podcast. Server Technology manufactures and distributes cabinet power distribution units. Our FSTS is a great solution for single power supply servers. It can accept 2 infeeds from different power sources. If one drops off it will continue to power the load from the other infeed.
You can read more on Server Technology on our website and our blog at ServerTechBlog.com
Thanks and keep up the great podcast!
I think your podcast is very informative, I like hearing about the stuff you learned in the school of hard knocks, however…
There are occasional things I hear on your podcast which make me cringe. One of the things mentioned near the end of this podcast was the discussion of a php exploit. I think that it was great that you disabled the php script, however I don’t think that you used a secure method.
You said that you placed a document within that directory so that the default page would no longer be index.php, but index.html. That does not solve the problem. If someone types in index.php, then you are in no better condition. More alarming however, you mentioned that the config file had the default name and was in the same directory as the php application. That should NEVER be the case, you should always move config files out of document root.
say you run a php bulletin board at:
g:/www/forums/index.php
or
/usr/home/USERNAME/www/docs/forums/
Your config should be at:
g:/www-conf/forums.conf
or
/usr/home/USERNAME/www/conf/forums.conf
or some variant thereof out of document root for the web server.
Another alternative is to make the server config so that all files in that directory can only be run, not read. If someone manages to attempt to access the files to read their contents instead of executing the contents, said person will get a 403 error, permission denied.
To see examples look for old config files for a /cgi-bin/ directory. This is often done by moving the cgi-bin out of the document root, making a script alias for it.