I spotted a new user which was created _after_ we put the form
back to maintainance mode. The POST was directly done to the
renamed script. I think the renamed script URL was at some point
found in the form but I don't know who made the change.
The files modification dates are (UTC):
May 10 06:41 for the renamed script with exposed new url
May 9 13:39 for the renamed script with no exposed new url
May 9 18:31 when the form was put in maintainance mode
The POST to renamed script happened 24 hours after the exposed url
11/May/2016:05:54:01 -0700
And resulted in the creation of a "vvk" user (with .ru email address):
createTimestamp: 20160511125401Z
The POST came from ip 77.242.110.178, which also issued a GET
for the the renamed-form URL at:
11/May/2016:05:51:36 -0700
The very first request to the renamed script was issued on
[09/May/2016:22:59:33 -0700] from 173.247.202.130
That is: May 10 05:59 UTC
For now I removed the execute bit from the disabled script, but let
me know if it was an "internal" backdoor legitimately used.
On May 11, 2016 8:46 AM, “Sandro Santilli” <strk@keybit.net> wrote:
I spotted a new user which was created after we put the form
back to maintainance mode. The POST was directly done to the
renamed script. I think the renamed script URL was at some point
found in the form but I don’t know who made the change.
The files modification dates are (UTC):
May 10 06:41 for the renamed script with exposed new url
May 9 13:39 for the renamed script with no exposed new url
May 9 18:31 when the form was put in maintainance mode
The POST to renamed script happened 24 hours after the exposed url
11/May/2016:05:54:01 -0700
And resulted in the creation of a “vvk” user (with .ru email address):
createTimestamp: 20160511125401Z
The POST came from ip 77.242.110.178, which also issued a GET
for the the renamed-form URL at:
11/May/2016:05:51:36 -0700
The very first request to the renamed script was issued on
[09/May/2016:22:59:33 -0700] from 173.247.202.130
That is: May 10 05:59 UTC
For now I removed the execute bit from the disabled script, but let
me know if it was an “internal” backdoor legitimately used.
On Wed, May 11, 2016 at 09:05:24AM -0700, Frank Warmerdam wrote:
I did this.
People need to create IDs!
How about moving the creation script under auth/, allowing
users from specific project groups to create more users ?
Then the maintainance page could report something like:
"ask another OSGeo User to create the account for you"
But I understand this would be problematic as whoever creates
the user needs to know the user password, correct ?
--strk;
On May 11, 2016 8:46 AM, "Sandro Santilli" <strk@keybit.net> wrote:
> I spotted a new user which was created _after_ we put the form
> back to maintainance mode. The POST was directly done to the
> renamed script. I think the renamed script URL was at some point
> found in the form but I don't know who made the change.
>
> The files modification dates are (UTC):
>
> May 10 06:41 for the renamed script with exposed new url
> May 9 13:39 for the renamed script with no exposed new url
> May 9 18:31 when the form was put in maintainance mode
>
> The POST to renamed script happened 24 hours after the exposed url
>
> 11/May/2016:05:54:01 -0700
>
> And resulted in the creation of a "vvk" user (with .ru email address):
>
> createTimestamp: 20160511125401Z
>
> The POST came from ip 77.242.110.178, which also issued a GET
> for the the renamed-form URL at:
>
> 11/May/2016:05:51:36 -0700
>
> The very first request to the renamed script was issued on
>
> [09/May/2016:22:59:33 -0700] from 173.247.202.130
> That is: May 10 05:59 UTC
>
> For now I removed the execute bit from the disabled script, but let
> me know if it was an "internal" backdoor legitimately used.
>
> --strk;
That's also a huge barrier to new users. Email confirmation is higher
priority to me. We could modify the Maintenance page, to say that during
maintenance new users need to contact an admin to have an account
created. But yes without the email confirmation/ability of users to
set/reset their own passwords, we make temp passwords and send via email
(currently how resets work).
-Alex
On 05/11/2016 09:45 AM, Sandro Santilli wrote:
On Wed, May 11, 2016 at 09:05:24AM -0700, Frank Warmerdam wrote:
I did this.
People need to create IDs!
How about moving the creation script under auth/, allowing
users from specific project groups to create more users ?
Then the maintainance page could report something like:
"ask another OSGeo User to create the account for you"
But I understand this would be problematic as whoever creates
the user needs to know the user password, correct ?
--strk;
On May 11, 2016 8:46 AM, "Sandro Santilli" <strk@keybit.net> wrote:
I spotted a new user which was created _after_ we put the form
back to maintainance mode. The POST was directly done to the
renamed script. I think the renamed script URL was at some point
found in the form but I don't know who made the change.
The files modification dates are (UTC):
May 10 06:41 for the renamed script with exposed new url
May 9 13:39 for the renamed script with no exposed new url
May 9 18:31 when the form was put in maintainance mode
The POST to renamed script happened 24 hours after the exposed url
11/May/2016:05:54:01 -0700
And resulted in the creation of a "vvk" user (with .ru email address):
createTimestamp: 20160511125401Z
The POST came from ip 77.242.110.178, which also issued a GET
for the the renamed-form URL at:
11/May/2016:05:51:36 -0700
The very first request to the renamed script was issued on
[09/May/2016:22:59:33 -0700] from 173.247.202.130
That is: May 10 05:59 UTC
For now I removed the execute bit from the disabled script, but let
me know if it was an "internal" backdoor legitimately used.
On Wed, May 11, 2016 at 09:49:30AM -0700, Alex M wrote:
That's also a huge barrier to new users. Email confirmation is higher
priority to me. We could modify the Maintenance page, to say that during
maintenance new users need to contact an admin to have an account
created. But yes without the email confirmation/ability of users to
set/reset their own passwords, we make temp passwords and send via email
(currently how resets work).
Couldn't we just use the reset code for registration ?
Rather than asking for a password, invoke the resetter,
so this would also automatically serve as a kind of
email confirmation (no email control, no known password).
On Wed, May 11, 2016 at 09:49:30AM -0700, Alex M wrote:
That's also a huge barrier to new users. Email confirmation is higher
priority to me. We could modify the Maintenance page, to say that during
maintenance new users need to contact an admin to have an account
created. But yes without the email confirmation/ability of users to
set/reset their own passwords, we make temp passwords and send via email
(currently how resets work).
Couldn't we just use the reset code for registration ?
Rather than asking for a password, invoke the resetter,
so this would also automatically serve as a kind of
email confirmation (no email control, no known password).
I don't know what reset code you're talking about? If you mean generate
a reset code and email the user, that is what I'm thinking.
I disagree, at most inactive accounts should be disabled, not deleted.
You don't want new people coming in and spoofing previous users, nor do
you want to orphan content. Also spam accounts tend to be active not
inactive.
PS: osgeo trac is being spammed now, could anyone setup the proper
configuration and BadContent page ? I'm gone for today.
--strk;
I'm tied up for quite a while at work, if someone else has some time
that would be great. I assume the new wiki page about Trac Spam
describes what to do?
On Wed, May 11, 2016 at 6:58 PM, Alex M <tech_dev@wildintellect.com> wrote:
On 05/11/2016 09:52 AM, Sandro Santilli wrote:
...
PS: osgeo trac is being spammed now, could anyone setup the proper
configuration
I would do but I have no admin rights on that trac instance.
and BadContent page ? I'm gone for today.
At least BadContent I have created.
--strk;
I'm tied up for quite a while at work, if someone else has some time
that would be great. I assume the new wiki page about Trac Spam
describes what to do?
For now clone from a different trac instance... (someone with admin
rights on osgeo trac and a different one like that of grass).
On Wed, May 11, 2016 at 09:58:26AM -0700, Alex M wrote:
On 05/11/2016 09:52 AM, Sandro Santilli wrote:
> On Wed, May 11, 2016 at 09:49:30AM -0700, Alex M wrote:
>> That's also a huge barrier to new users. Email confirmation is higher
>> priority to me. We could modify the Maintenance page, to say that during
>> maintenance new users need to contact an admin to have an account
>> created. But yes without the email confirmation/ability of users to
>> set/reset their own passwords, we make temp passwords and send via email
>> (currently how resets work).
>
> Couldn't we just use the reset code for registration ?
> Rather than asking for a password, invoke the resetter,
> so this would also automatically serve as a kind of
> email confirmation (no email control, no known password).
I don't know what reset code you're talking about? If you mean generate
a reset code and email the user, that is what I'm thinking.
I was referring to your "currently how resets work", if that's how it
works then yes. There's no much else we can do. But also for _new_
registrations we should do that.
I disagree, at most inactive accounts should be disabled, not deleted.
Yes, disabled is better. But we want a way to tell if an account
is enabled or disabled, via ldapsearch (and document that). Do
you know how could that be done ?
PS: I launched my fantastic SQL script to delete all recent spam from
the known spammer accounts. Let me know if you find more spam so
we can grow the list of spammers.
On Wed, May 11, 2016 at 07:01:19PM +0200, Markus Neteler wrote:
On Wed, May 11, 2016 at 6:58 PM, Alex M <tech_dev@wildintellect.com> wrote:
> On 05/11/2016 09:52 AM, Sandro Santilli wrote:
...
>> PS: osgeo trac is being spammed now, could anyone setup the proper
>> configuration
I would do but I have no admin rights on that trac instance.
On Wed, May 11, 2016 at 08:00:00PM +0200, Sandro Santilli wrote:
On Wed, May 11, 2016 at 09:58:26AM -0700, Alex M wrote:
> I disagree, at most inactive accounts should be disabled, not deleted.
Yes, disabled is better. But we want a way to tell if an account
is enabled or disabled, via ldapsearch (and document that). Do
you know how could that be done ?
On Wed, May 11, 2016 at 06:45:44PM +0200, Sandro Santilli wrote:
On Wed, May 11, 2016 at 09:05:24AM -0700, Frank Warmerdam wrote:
> I did this.
>
> People need to create IDs!
How about moving the creation script under auth/, allowing
users from specific project groups to create more users ?
Then the maintainance page could report something like:
"ask another OSGeo User to create the account for you"
But I understand this would be problematic as whoever creates
the user needs to know the user password, correct ?
So I had another idea, and implemented it.
During spam attacks (like now) the form will show "maintainance"
(or other) message _UNLESS_ a given token is passed to the URL.
This gives us an easy way to keep using the script.
Also, if we like the idea, we could also communicate the light-token to
legit users that need to register (as the GSOC student who asked today)
and change it after. Eventually we could use a multi-token approach
so to add per-user tokens.