Old URLs gone because of SEO vulnerability, why new URLs?

OK,
I see that the old SEO plugin had to be replaced.

Is there some reason why re-directs haven’t been implemented to enable the old URLs to work?

That has no impact whatsoever to the old plugin if the plugin has been removed or disabled.

In fact, making lemonade from lemons in this situation, I would guess that there isn’t a proxy or accelerator in front of the web server. This might be an opportunity to consider implementing a proxy/accelerator (even if in a virtual machine), for these devices a common capability is to re-write URLs.

I’m also wondering what a SEO plugin likely has to do with any main website (eg Forums). I would think that the any authentication is managed completely separately from the main web content. I’m hazarding a guess that the new URLs might have something to do with whole new re-build/deployment with new routing? If so, then maybe this should be thought out to be better managed in the future although I understand that often expediency (get back up and running) can have priority over doing things “nicely.”

TSU

On Tue, 07 Jan 2014 19:56:01 +0000, tsu2 wrote:

> I’m also wondering what a SEO plugin likely has to do with any main
> website (eg Forums). I would think that the any authentication is
> managed completely separately from the main web content. I’m hazarding a
> guess that the new URLs might have something to do with whole new
> re-build/deployment with new routing?

The SEO plugin is specific to vBulletin, is no longer maintained (the
company that makes it went out of business), and has a vulnerability that
can be used to compromise the integrity of the vBulletin database.

While our implementation does not use the database to store
authentication information (so there’s no need to change your password),
the SEO plugin uses the same database tables, so for sites that run it
and that use the vBulletin database to store login credentials, that
creates a potential compromise.

As for why there aren’t redirects - there are a lot of URLs in here, and
a redirect engine wouldn’t work well to deal with it. It’s a pain, but
over about a month, it’ll become a non-issue.

Jim

–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

On Tue, 07 Jan 2014 19:56:01 +0000, tsu2 wrote:

> Is there some reason why re-directs haven’t been implemented to enable
> the old URLs to work?

They have now, it sounds like.

The team just had higher priorities to sort out before they did that.

Jim

Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

Thx Jim,

First, I want to congratulate the people who undoubtedly worked really hard to get the Forums back up. I know that if something doesn’t work properly, it can be a really difficult job to overcome obstacles.

A few ideas/opinions… Possibly things to consider preparing for similar future issues…

• I’m guessing from the new URLs that the “new” forums are simply deployed as a new Virtual Webserver (the path denotes the new and different virtual webserver).
• Although I haven’t explored its use, there <is> an Apache module that can re-write the URLs to conform with the old path. Yes, it will put an additional load on the machine, unknown what the actual impact would be.
• From all appearances, it looks like the webserver may be “naked” – There are benefits to putting it behind a Web Application Proxy. Squid probably should be fine although I don’t have experience with it… I’ve used commercial Web Application proxies (aka Reverse Proxy and Web Accelerators) which should have similar functionality and do everything I describe below well.
• If you deploy a Web Application Proxy
  • It should be able to filter any potential Injection type attacks(I assume that’s the type of attack
    your SEO plugin was vulnerable to). The proxy looks like the webserver to the client,
    but it doesn’t have the same full functionality so is difficult to exploit
  • Depending on how you deploy, it can offload load from the webserver.
  • It might perform IDS and maybe even IPS

Usually for both above re-direct implementations, it’s a simple file that contains only the few rules (my guess less than 5) necessary to define a new Virtual Server.

Anyway,
Congrats again to all the hard work that went into getting the Forums back up!

TSU

On Thu, 09 Jan 2014 23:36:01 +0000, tsu2 wrote:

> Thx Jim,
>
> First, I want to congratulate the people who undoubtedly worked really
> hard to get the Forums back up. I know that if something doesn’t work
> properly, it can be a really difficult job to overcome obstacles.
>
> A few ideas/opinions… Possibly things to consider preparing for
> similar future issues…
>
> - I’m guessing from the new URLs that the “new” forums are simply
> deployed as a new Virtual Webserver (the path denotes the new and
> different virtual webserver).

Actually, the SEO plugin, as I understand it, creates URLs from the
existing content that is there - so the “new” URLs are actually the “old”
URLs, but what was exposed were the SEO URLs so Google and other search
engines could crawl the content.

> - Although I haven’t explored its use, there <is> an Apache module that
> can re-write the URLs to conform with the old path. Yes, it will put an
> additional load on the machine, unknown what the actual impact would be.

You probably just haven’t seen my other post, but they got it working,
and I assume it’s with a rewrite rule.

> - From all appearances, it looks like the webserver may be “naked” –
> There are benefits to putting it behind a Web Application Proxy. Squid
> probably should be fine although I don’t have experience with it… I’ve
> used commercial Web Application proxies (aka Reverse Proxy and Web
> Accelerators) which should have similar functionality and do everything
> I describe below well.
> - If you deploy a Web Application Proxy - It should be able to filter
> any potential Injection type attacks(I assume that’s the type of attack
> your SEO plugin was vulnerable to). The proxy looks like the webserver
> to the client,
> but it doesn’t have the same full functionality so is difficult to
> exploit - Depending on how you deploy, it can offload load from the
> webserver. - It might perform IDS and maybe even IPS
>
> Usually for both above re-direct implementations, it’s a simple file
> that contains only the few rules (my guess less than 5) necessary to
> define a new Virtual Server.

I’ll leave the specifics of the installation (reverse proxy/not a reverse
proxy) to the guys who manage the data center. They’ve got tons of
experience with this - I believe there’s a reverse proxy in play, but I
could be wrong about that.

My opinion, though, is that AppArmor could be used to help prevent this
type of attack - that’s what it’s designed to do.

> Anyway,
> Congrats again to all the hard work that went into getting the Forums
> back up!

Will make sure the guys doing the work know about it. Even with no
passwords compromised, they got the system back up much faster than
others who have been hit with various exploits.

Jim

Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

Will make sure the guys doing the work know about it. Even with no
passwords compromised, they got the system back up much faster than
others who have been hit with various exploits.

Jim]

Well done to the team responsible for getting the Forums back up and online.