[BlueOnyx:05501] Re: Dealing with /admin URL 'hijacking

[James Darbyshire]

Hi guys,

Sorry for my late response, I have been out in the big red outback for the
past few days...

Steph, I feel we are banging on about essentially the same thing, so I won't
go on... As for PHP system calls, obviously if the directory has the correct
permissions and someone calls a system command with the correct permissions
then there isn't much we can do to stop that. However, a good log viewer if
going to minimise this risk, and (I don't use this) but in my old place of
work the server sent an email (which went to SMS) to the system
administrators whenever someone logged in as root/sudo.

Of course, PHP permissions should be set correctly, and should probably only
be able to read/write in the apache websites, and read the php.ini file. We
don't allow individual crontabs or ssh access to our clients.

An application level firewall would be great for certain applications, as
long as it was not too restrictive and easily setup.

You should see my Windows servers...... If you think BX is vulnerable... The
amount of worms that get caught, the amount of times someone tries to break
the security... It's unreal!

ISP/Host responsibility... I have never put it to the test, and I can see
logic in your argument, but that is what an EULA is for. It limits/mitigates
our responsibility for them getting hacked with software they provide. In
fact, even if we are running software which gets hacked on our website (e.g.
WHMCS/BMS) then we are still not liable. Now, as I mentioned in my first
emails, our servers can only be accessed from within a VPN. This is the case
for all of our systems (and in fact there are no systems on client servers -
too risky) so our BMS can only be access through the VPN etc...

Enjoyed this discussion, and would welcome any security tips and trick which
people do to secure their boxes - always interesting to see what others are
doing!

James

On 26 September 2010 17:48, Abdul Rashid Abdullah <webmaster at muntada.com>wrote:

> Fantastic discussion.  Thanks for playing.  ;-)
>
>
> On 9/25/10 11:47 PM, "Jeff Jones" <jeffrhysjones at mac.com> wrote:
>
> > So refreshing to see good intelligent argument on the list without either
> > party getting abusive and resorting to slagging the other off (or perhaps
> that
> > is to come?!!?)
> >
> > Seriously though, I know this sounds a bit corny but I think both
> approaches
> > are correct, meaning that (here in the UK at least) in order to pass PCI
> DSS
> > 2.x requirements, they don't like pretty much anything generic, be that
> server
> > admin URL or CMS admin URL. I'm sure that any CMS vendor that has a
> product
> > where it's difficult / impossible to change the admin URL (like ours) is
> going
> > to need to think about sorting this in the near future.
> >
> > But PCI requirements weren't around when CobaltOS was first designed,
> although
> > there have been some significant improvements to security (like the login
> /
> > server locker outer) - I think there is still a way to go before any one
> gets
> > a 'native' BX box past PCI.
> >
> > For one there is the issue of the generic 'admin' account which I believe
> > can't be changed.
> >
> > So as this is a BX list, for perhaps the discussion of BX issues and
> suggested
> > improvements, on a server level it would be great if BX could enable you
> to
> > change the admin URL via the GUI, in whatever way people thought best.
> Ditto
> > for other things like admin account, and I think there was someone a
> while
> > back that said some essential BX service was causing his PCI scanner to
> fail
> > for some reason.
> >
> > All BX can really do a about CMS security is to improve the ease of
> locking
> > down the underlying Php engine / application server - something which has
> been
> > really improved from BO to BX.
> >
> > It makes me wonder about sticking an L7 Application Based firewall on BX
> - is
> > that something anyone has looked at? Is there a leading open source
> project
> > out there?
> >
> > Cheers,
> >
> > Jeff
> > _______________________________________________
> > Blueonyx mailing list
> > Blueonyx at blueonyx.it
> > http://www.blueonyx.it/mailman/listinfo/blueonyx
> >
>
>
> _______________________________________________
> Blueonyx mailing list
> Blueonyx at blueonyx.it
> http://www.blueonyx.it/mailman/listinfo/blueonyx
>



-- 
Regards,

James Darbyshire
jamesdarbyshire at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20100929/767ed63c/attachment.html>