Hi Steph,<div><br></div><div>At risk of turning this into a email yo-yo, (and please don't take this, or anything I have said as an attack on you or your chosen best practises) I reply to your email. I am always up for a good debate, and hearing other's points of view - especially when there is no clear-cut answer, and all methods are mainly someone's interpretation/education of what 'best practise' is. Important to note that best practise changes, and yesterdays best may be today's worst.</div>
<div><br></div><div>As stated in my previous emails, I agree, changing the default path from /admin to something different is definitely best practise, and I actually encourage anyone to do this, however my warnings were against the myriad of people who think that placing something in a directory which is unlikely to be found is security. This is something I have found in the past, where hosting companies have provides directories such as /adm-a8r30 or provided an obscure port number for the admin panel.</div>
<div><br></div><div>What I fail to understand from your emails, is how breaching something like a CMS would allow access to a shell. Surely if someone is using the same access credentials for their CMS as their shell then the alarm bells should be on overdrive. Current best practise suggests that security is compartmentalised, meaning that a breach in one area does not mean we are nearing the apocalypse for all areas.</div>
<div><br></div><div>If a client gets hacked, yes it is bad. And yes it should have been spotted and acted upon years ago. And yes as the host you are responsible for guiding them in the right direction to ensure it does not happen again. However, I doubt that there are many sites out there, which, if hacked, would cause the parent company to be shutdown. The days of merchant accounts being redirected to another account number causing someone to go bust are pretty well gone, and even if it does happen, in most cases you are protected for the entirety of your 'lost' capital.</div>
<div><br></div><div>As I stated in my previous email, I can only talk for the Australian (and British) legal systems, where the host is responsible for the security of the server, and the client is responsible for the security of the installed software, so in these systems there would be no legal defence costs for a host, as there is simply no problem with a CMS being hacked, those credentials having access to shell, and then gaining access to the root user of the system. I am not saying that it can't happen, but with proper planning and security measures it becomes such a small possibility that it is not worth persisted worry about.</div>
<div><br></div><div>FYI we restrict access to the root user and other 'administrative' users to come from one public IP, meaning that in order to shell into our box you have to be connected to the VPN first. It works a charm, because even if someone does know your public IP they cannot gain access to the most important areas.</div>
<div><br></div><div>Regards,</div><div><br></div><div>James Darbyshire</div><div><br></div><div><br><br><div class="gmail_quote">On 26 September 2010 13:07, Stephanie Sullivan <span dir="ltr"><<a href="mailto:ses@aviaweb.com">ses@aviaweb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">








<div lang="EN-US" link="blue" vlink="purple">

<div>

<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D">Ah, James,</span></p>

<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D"> </span></p>

<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D">Indeed security through obscurity is not security. However,
changing default paths improves the odds of avoiding an attack and can be an
important part in an overall security plan. In fact suggesting one thing is “the
answer” is not at all my intention and I hope you are not trying to suggest
there is “a solution”...</span></p>

<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D"> </span></p>

<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D">And if the client is breached, gets shell, and well, whatever,
the server is potentially much more at risk. Far more so than if the client was
not breached.</span></p>

<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D"> </span></p>

<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D">In any case, I may not have been clear in my wording when I was
writing about who is responsible where. The client may claim the hosting
company had some complicit negligence. Even if not true, legal fees can be
staggering and the overhead of a defense great.</span></p>

<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D"> </span></p>

<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D">Reputations can be trashed, even when not deserved, and that has
repurcutions. </span></p>

<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D"> </span></p>

<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D">If my client gets hacked it’s bad for them and that is bad
for my buisness, especially if they go out of business.</span></p>

<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D"> </span></p>

<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D">            Thanks,</span></p>

<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D">                        -Stephanie</span></p>

<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D"> </span></p>

<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D"> </span></p>

<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D"> </span></p>

<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">

<div>

<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">

<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt">
<a href="mailto:blueonyx-bounces@blueonyx.it" target="_blank">blueonyx-bounces@blueonyx.it</a> [mailto:<a href="mailto:blueonyx-bounces@blueonyx.it" target="_blank">blueonyx-bounces@blueonyx.it</a>] <b>On Behalf
Of </b>James Darbyshire<br>
<b>Sent:</b> Saturday, September 25, 2010 7:38 PM</span></p><div class="im"><br>
<b>To:</b> BlueOnyx General Mailing List<br>
</div><b>Subject:</b> [BlueOnyx:05466] Re: Dealing with /admin URL 'hijacking<p></p>

</div>

</div><div><div></div><div class="h5">

<p class="MsoNormal"> </p>

<p>Steph,</p>

<p>But what you are suggesting is that security by obscurity is the answer in
this case - which is a dangerous path to follow.</p>

<p>It may be easier for someone to break into the CMS than into the BO backend,
but once they are into BO then they can do everything you suggested, not only
to one site, but to every site on that host.</p>

<p>I don't know how uou run your business, or how the law works in the US, but
here in Australia the client is responsible for the security of what they
install on their website, and the host is responsible for the security of the
server. If a CMS was hacked, I would not be responsible.</p>

<p>Of course the optimal solution would be to use some kind of TLS and
intelligent intrusion detection software on both systems which locks access out
when it thinks an attack is taking place.</p>

<p>Rashid, I suspect you are correct on saying that BO authentication is
probably harder to crack than that of a stock CMS, but the point sound be that
yes an attacker can get into one website and cause havoc, but only within that
CMS on that specific site. Other sites will be unaffected. I would also hazard
a guess that many people are not as vigilant as you or I, and do not frequently
change their passwords.</p>

<p>In short, I don't believe security by obscurity is the answer in either
case, but I would rather the attacker accessed one site only, and not the server
which has access to all.</p>

<p>Regards,</p>

<p>James Darbyshire</p>

<p>Sent from my Samsung Droid™</p>

<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">

<p class="MsoNormal" style="margin-bottom:12.0pt">On 26/09/2010 1:28 AM,
"Stephanie Sullivan" <<a href="mailto:ses@aviaweb.com" target="_blank">ses@aviaweb.com</a>>
wrote:</p>

<div>

<div>

<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">I must not concur. That’s not the
worst thing. Picture this:</span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">They break into my client’s
zencart, oscommerce or CC processor integrated  cms (as joomla and drupal
have plugins/extensions and I have clients using them). The get into the
client’s site and modify the CC credentials to process using their bogus
merchant account. Maybe they put a hack in to steal their CC numbers. Now you
have a security breach that has big legal implications that you and/or your
client have to legally disclose in the US. You probably have clients screaming
at you about bogus charges on their card. Eventually the site is defaced and
their tracks are covered by wiping most of your database. </span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Finally your client’s reputation
is damaged/destroyed and they are angry with you and spread the word they got
hacked on your platform damaging your reputation, etc…</span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">I would think it’s far from the
worst thing. Of course it may be worse if you are the client than the hosting
company.</span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">               
Thanks,</span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">                               
-Stephanie</span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>

<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">

<div>

<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">

<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> <a href="mailto:blueonyx-bounces@blueonyx.it" target="_blank">blueonyx-bounces@blueonyx.it</a>
[mailto:<a href="mailto:blueonyx-bounces@blueonyx.it" target="_blank">blueonyx-bounces@blueonyx.it</a>]
<b>On Behalf Of </b>James Darbyshire<br>
<b>Sent:</b> Saturday, September 25, 2010 10:30 AM</span></p>

<p><span style="font-size:10.0pt;color:#500050"><br>
To: BlueOnyx General Mailing List</span><span style="font-size:10.0pt"></span></p>

<p class="MsoNormal"><b><span style="font-size:10.0pt">Subject:</span></b><span style="font-size:10.0pt"> [BlueOnyx:05461] Re: Dealing with /admin URL
'hijacking</span></p>

</div>

</div>

<p><span style="color:#500050"><br>
<br>
 <br>
<br>
I disagree. Certainly it is not best practise for any admin functions to be
accessible through ...</span></p>

</div>

</div>

</div>

<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Blueonyx mailing list<br>
<a href="mailto:Blueonyx@blueonyx.it" target="_blank">Blueonyx@blueonyx.it</a><br>
<a href="http://www.blueonyx.it/mailman/listinfo/blueonyx" target="_blank">http://www.blueonyx.it/mailman/listinfo/blueonyx</a></p>

</blockquote>

</div></div></div>

</div>

</div>


<br>_______________________________________________<br>
Blueonyx mailing list<br>
<a href="mailto:Blueonyx@blueonyx.it">Blueonyx@blueonyx.it</a><br>
<a href="http://www.blueonyx.it/mailman/listinfo/blueonyx" target="_blank">http://www.blueonyx.it/mailman/listinfo/blueonyx</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Regards,<br><br>James Darbyshire<br><a href="mailto:jamesdarbyshire@gmail.com">jamesdarbyshire@gmail.com</a><br>
</div>