<div dir="auto"><span>I think what Jimmy is referring to is what I was
suggesting by removing the extensions / making the question impossible to
answer. Basically a series of rapid fire changes while tailing the
logs and seeing what stops the spam. Once you know what worked
then you can submit as an official patch. But being able to quickly
try these things on a server actually under attack is the fastest path
toward identifying the fix. <br></span><br><div id="cm_footer"
class="cm_footer" style="opacity: 1;"><div id="cm_signature"><b>J.P.
Maxwell</b> | <a href="http://tipit.net">tipit.net</a> | <a
href="http://www.fibercove.com">fibercove.com</a></div></div><span><br></span><div
id="cm_replymail_content_wrap"><div
class="cm_replymail_content_1456507630_wrapper">On Fri, Feb 26, 2016 at
11:25 AM, Paul Belanger <pabelanger@redhat.com> wrote:<br><div
id="cm_replymail_content_1456507630" style="overflow: visible;"><blockquote
style="margin:0;border-left: #D6D6D6 1px solid;padding-left: 10px;">On Fri,
Feb 26, 2016 at 11:08:18AM -0600, Jimmy McArthur wrote:<br>> Given the
state of the wiki a the moment, I think taking the quickest path<br>> to
get it fixed would be prudent. Is there a way we can get JP root
access<br>> to this server, even temporarily? We get 25% of our website
traffic (2<br>> million visitors) to the wiki. I realize we're all after
the same thing, but<br>> spammers are not going to hit the dev
environment, so there's really no way<br>> to tell if teh problem is
fixed without actually working directly on the<br>> production machine.
This should be a 30 minute fix.<br>> <br>I am still unclear what the
30min fix is. If really 30mins, then it shouldn't be<br>hard to get the fix
into our workflow. Could somebody please elaborate.<br><br>If we are
talking about deploying new versions of php or mediawiki manually, I<br>not
be in-favor of this. To me, while the attack sucks, we should be working
on<br>2 fronts. Getting the help needed to mitigate the attack, then
adding the<br>changes into -infra workflow in parallel.<br><br>> I
realize there is a lot of risk in giving ssh access to infra machines,
but<br>> I think it's worth taking a look at either putting this machine
in a place<br>> where a different level of admin could access it without
giving away the<br>> keys to the entire OpenStack infrastructure or
figuring out a way to set up<br>> credentials with varying levels of
access.<br>> <br>As a note, all the work I've been doing to help with
the attack hasn't require<br>SSH access for me to wiki.o.o. I did need
infra-root help to expose our<br>configuration safely. I'd rather take
some time to see what the fixes are,<br>having infra-root apply changes,
then move them into puppet.<br><br>It also has been discussed to simply
disable write access to the wiki if we<br>really want spamming to stop,
obviously that will affect normal usage.<br><br>> Jimmy<br>> <br>>
Paul Belanger wrote:<br>> >On Fri, Feb 26, 2016 at 10:12:12AM -0600,
JP Maxwell wrote:<br>> >>But if you wanted to upgrade everything,
remove the mobile view extension,<br>> >>test in a dev/staging
environment then deploy to production fingers<br>> >>crossed, I
think that would be a valid approach as well.<br>> >><br>>
>Current review up[1]. I'll launch a node tonight / tomorrow locally to
see how<br>> >puppet reacts. I suspect there will be some
issues.<br>> ><br>> >If infra-roots are fine with this
approach, we can use that box to test against.<br>> ><br>> >[1]
https://review.openstack.org/#/c/285405/<br>> ><br>> >>J.P.
Maxwell | tipit.net | fibercove.com<br>> >>On Feb 26, 2016 10:08
AM, "JP Maxwell"<jp@tipit.net> wrote:<br>> >><br>>
>>>Plus one except in this case it is much easier to know if our
efforts are<br>> >>>working on production because the spam
either stops or not.<br>> >>><br>> >>>J.P. Maxwell
| tipit.net | fibercove.com<br>> >>>On Feb 26, 2016 9:48 AM,
"Paul Belanger"<pabelanger@redhat.com> wrote:<br>>
>>><br>> >>>>On Fri, Feb 26, 2016 at 09:18:00AM
-0600, JP Maxwell wrote:<br>> >>>>>I really think you
might consider the option that there is a<br>>
>>>>vulnerability<br>> >>>>>in one of the
extensions. If that is the case black listing IPs will be<br>>
>>>>an<br>> >>>>>ongoing wild goose
chase.<br>> >>>>><br>> >>>>>I think
this would be easily proven or disproven by making the questy<br>>
>>>>>question impossible and see if the spam
continues.<br>> >>>>><br>> >>>>We'll have
to let an infra-root make that call. Since nobody would be<br>>
>>>>able to<br>> >>>>use the wiki. Honestly, I'd
rather spend the time standing up a mirror dev<br>>
>>>>instance for us to work on, rather then production.<br>>
>>>><br>> >>>>>J.P. Maxwell | tipit.net |
fibercove.com<br>> >>>>>On Feb 26, 2016 9:12 AM, "Paul
Belanger"<pabelanger@redhat.com> wrote:<br>>
>>>>><br>> >>>>>>On Thu, Feb 25, 2016
at 08:10:34PM -0800, Elizabeth K. Joseph wrote:<br>>
>>>>>>>On Thu, Feb 25, 2016 at 6:35 AM, Jeremy
Stanley<fungi@yuggoth.org><br>>
>>>>>>wrote:<br>> >>>>>>>>On
2016-02-25 02:46:13 -0600 (-0600), JP Maxwell wrote:<br>>
>>>>>>>>>Please be aware that you can now create
accounts under the mobile<br>> >>>>>>>>>view
in the wiki native user table. I just created an account for<br>>
>>>>>>>>>JpMaxMan. Not sure if this matters but
wanted to make sure you<br>> >>>>>>>>>were
aware.<br>> >>>>>>>>Oh, yes I think having a
random garbage question/answer was in<br>> >>>>fact<br>>
>>>>>>>>previously preventing account creation
under the mobile view. We<br>> >>>>>>>>probably
need a way to disable mobile view account creation as it<br>>
>>>>>>>>bypasses OpenID authentication
entirely.<br>> >>>>>>>So that's what it was doing!
We'll have to tackle the mobile view<br>> >>>>issue.<br>>
>>>>>>>Otherwise, quick update here:<br>>
>>>>>>><br>> >>>>>>>The
captcha didn't appear to help stem the spam tide. We'll want to<br>>
>>>>>>>explore and start implementing some of the
other solutions.<br>> >>>>>>><br>>
>>>>>>>I did some database poking around today and it
does seem like all<br>> >>>>the<br>>
>>>>>>>users do have launchpad accounts and email
addresses.<br>> >>>>>>><br>>
>>>>>>So, I have a few hours before jumping on my plane
and checked into<br>> >>>>this.<br>>
>>>>>>We are<br>> >>>>>>using
QuestyCaptcha which according to docs, should almost be<br>>
>>>>impossible<br>> >>>>>>for<br>>
>>>>>>spammers to by pass in an automated fashion. So,
either our captcha<br>> >>>>is too<br>>
>>>>>>easy, or we didn't set it up properly. I don't
have SSH on wiki.o.o<br>> >>>>so<br>>
>>>>>>others<br>> >>>>>>will have to
check logs. I did test new pages and edits, and was<br>>
>>>>promoted<br>> >>>>>>by<br>>
>>>>>>captcha.<br>> >>>>>><br>>
>>>>>>As a next step, we might need to add additional
apache2 configuration<br>> >>>>to<br>>
>>>>>>blacklist IPs. I am reading up on that
now.<br>> >>>>>><br>>
>>>>>>>--<br>>
>>>>>>>Elizabeth Krumbach Joseph || Lyz ||
pleia2<br>> >>>>>>><br>>
>>>>>>>_______________________________________________<br>>
>>>>>>>OpenStack-Infra mailing list<br>>
>>>>>>>OpenStack-Infra@lists.openstack.org<br>>
>>>>>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra<br>>
>>>>>>_______________________________________________<br>>
>>>>>>OpenStack-Infra mailing list<br>>
>>>>>>OpenStack-Infra@lists.openstack.org<br>>
>>>>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra<br>>
>>>>>><br>> ><br>>
>_______________________________________________<br>>
>OpenStack-Infra mailing list<br>>
>OpenStack-Infra@lists.openstack.org<br>>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra<br>>
<br><br>> _______________________________________________<br>>
OpenStack-Infra mailing list<br>>
OpenStack-Infra@lists.openstack.org<br>>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra<br><br><br>_______________________________________________<br>OpenStack-Infra
mailing
list<br>OpenStack-Infra@lists.openstack.org<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra<br></blockquote></div></div></div></div>