[ubuntu-uk] Website Hacked.....

[Matthew Macdonald-Wallace]

Quoting William Anderson <neuro at well.com>:

> 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≈.

Sorry, I meant Shell access is banned.  We've also created anti-virus  
signatures for use with ClamAV that looks for known exploit scripts  
and content on upload which seems to be working fairly well.

>> [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.



It may not be within our duty of care, but education does seem to  
reduce the number of repeat incidents on a domain! :)

M.
-- 
Matthew Macdonald-Wallace
matthew at truthisfreedom.org.uk
http://www.truthisfreedom.org.uk/