Matthew Macdonald-Wallace wrote:
> [snip]
>> A strong password is useless if the hack was carried out using a
> remote file include or a vulnerability in code that was on the website
> to elevate permissions. From your other comments in the thread, I
> doubt that your netbook is compromised. I'd lay the blame at the feet
> of Wordpress or similar.
I'd be inclined to agree here. I note you (John) are running WP 2.7.1
on furrycritters.co.uk, so the CMS itself may not be responsible, but
perhaps one of the WP plugins installed, or more likely PHPBB, which is
a very popular attack vector, due to the myriad of holes in the various
versions of the code.
> [use ssh/sftp instead of ftp snippage]
> Unfortunately, there are not a huge number of hosts that allow this as
> it would require enabling command-line access (no matter how
It is possible to enable SFTP access while restricting shell access.
Note that some large vendors, e.g. Dreamhost, do allow SSH access to
allow easy use of services such as cron jobs.
> restricted) to the servers. As a Systems Administrator, end-users are
> _banned_ from accessing my systems because (to put it quite bluntly
> and this is not aimed at anyone in particular, certainly not on this
> mailing list!) the majority of end users simply do not know what they
> are doing when it comes to file ownership, permissions and what
> consitutes "Secure Code".
If they're banned from accessing your systems, how do they upload their
sites? :) In all seriousness, how does restricting access to servers
stop problems with "Secure Code"? If I can only upload files via FTP, I
can still upload some insecure code. It's perfectly possible to enable
shell access for web hosting customers (I know, because I've done it) to
give them the maximum possible flexibility to build and manage sites,
while ensuring all the sites play nice with each other and the servers
that host them≈.
> [snip]
> We generally will provide as much information as we can to our clients
> as we are firm believers that if you point out the errors in the code,
> end-users learn and tend not to get hacked in future! If your hosting
> provider are not doing this, then ask them why not.
It's not always within a hosting provider's duty of care to QA customer
code, although I do believe it's in the same sphere for a provider to
use systems that mitigate against the effects of unfortunate code mistakes.
-n