Open Stack

My intention is to make a series of rapid fire changes to the config files
while tailing the log files in order to quickly suss out if the spammers
are defeating or bypassing captcha and what change would need to be
implemented to prevent this from happening. Once we actually know what is
happening and how to stop it then we would propose a permanent patch which
could be submitted through the normal processes.

J.P. Maxwell | tipit.net | fibercove.com
On Mar 22, 2016 5:39 PM, "Jeremy Stanley" <fungi at yuggoth.org> wrote:

> On 2016-03-22 08:23:08 -0500 (-0500), JP Maxwell wrote:
> > If anyone wants to approve this I am still happy to help.
> >
> > https://review.openstack.org/#/c/285641/1
>
> Can you elaborate on how you intend to help which has to be done
> first with root access to the server (rather than merely with the
> assistance of someone with root access)? The commit message on that
> change indicates you just want access to logs files, which I or
> other root sysadmins can certainly provide.
>
> We want to make sure that all modifications are reflected in
> configuration management so that it's reviewed, tracked and
> repeatable, and this is why we generally limit production server
> root access to people who also have the ability to approve
> configuration management changes for the same servers. This service
> is already in a bit of an unfortunate state because years ago we
> were less strict and in a moment of weakness allowed the MW
> deployment/migration to precede the configuration management of that
> deployment (which was subsequently never completed). We need to make
> sure its tenuous situation doesn't regress further.
>
> > I don't think you are ever going to be successful at blocking
> > accounts or IPs. You must block the creation of the spam by the
> > bots. IMHO focusing on improving the captcha or understanding the
> > bypass path around the captcha is the best short term path to
> > accomplish this.
>
> I'm pretty sure we have consensus on this already. Blocking accounts
> and manual cleanup are only viewed as a temporary workaround while
> we plan for a safe upgrade to a more recent MW (and as a
> prerequisite, more recent Ubuntu) release so that we can take
> advantage of current access control measures and similar mitigation
> solutions developed by their community in response to escalating
> advancement in defacement and valdalism on Wikipedia and elsewhere.
> --
> Jeremy Stanley
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20160322/a2bb0deb/attachment.html>