Protegendo a interface administrativa do Wordpress em uma porta alternativa

Question

Eu tenho um blog Wordpress auto-hospedado. Sempre que possível, tento proteger as interfaces administrativas para aplicativos da Web usando a autenticação de certificado de cliente SSL e X.509. Eu tenho tudo isso funcionando corretamente para coisas como o phpMyAdmin, então os bits técnicos com o servidor web estão todos no lugar.

Minha configuração de hospedagem é:

• nginx 0.7.x
• PHP 5.2.10 com o patch fpm
• MySQL 5.x

Estou executando tudo isso em um VPS, então tenho apenas um IP externo. Eu tenho vários outros sites SSL em execução na caixa: um na porta padrão e todos os outros em portas alternativas (para que cada um possa ter um certificado diferente correspondido ao seu nome de host).

Minha intenção era ter dois blocos de configuração de servidor:

1. uma porta blog.domain.com de veiculação 80 que retornou 404 se você tentou acessar qualquer coisa em / wp-admin
2. outro em execução na porta 8443 com SSL sem restrições de URL, mas que exigia a apresentação de um certificado de cliente X.509 válido.

O problema que estou enfrentando é que o Wordpress não gosta de ser acessado em duas portas diferentes. Sempre que tento acessar o link , ele me redireciona para link , que é um vhost totalmente diferente (o site principal no servidor, em execução na porta padrão). Em seguida, recebo um erro de nome de certificado no navegador e, mesmo que eu cancele o aviso, não estou mais falando com o site wordpress.

A URL principal do blog é armazenada na tabela wp_options:

mysql> select option_value from wp_options where option_name = 'siteurl';
+------------------------------+
| option_value                 |
+------------------------------+
| http://blog.domain.com       |
+------------------------------+
1 row in set (0.00 sec)

mysql >

Por isso, não é possível fazer uma segunda cópia dos arquivos do blog com o URL principal definido como link e acessar o interface administrativa dessa maneira.

Alguma idéia?

UPDATE

Depois de jogar por algum tempo com as respostas sugeridas, cheguei à conclusão de que não é possível fazer exatamente o que eu quero. A ativação dos recursos no wordpress resulta em usuários que fazem solicitações SSL para / wp- (admin | login | register), o que eles não podem fazer se eu precisar de certificados do cliente X.509 no lado do SSL.

A melhor solução que criei foi a configuração de um front-end SSL com autenticação de certificado que apenas enviava solicitações por proxy para o nginx não-SSL. Mesmo assim, não consigo cortar totalmente o acesso não-SSL ao / wp-admin, porque muito do CSS e do Javascript usados no registro de usuários e no gerenciamento de perfis vêm desse diretório.

Eu posso permitir acesso ao CSS, imagens e Javascript em / wp-admin via HTTP e apenas requer acesso SSL para os scripts PHP, mas os usuários não podem modificar seu perfil (esquemas de cores, nomes de exibição, etc.) O próximo passo seria identificar o subconjunto de scripts PHP necessários para usuários normais e deixar que estes passem pelo HTTP enquanto rejeitam o resto, mas então eu sou um escravo da equipe de desenvolvimento do wordpress, caso eles reorganizem as coisas.

Eu acho que este se resume a treinar-me para gerenciar apenas o blog sobre SSL, mesmo que o servidor me permita fazê-lo através de HTTP simples.

    

Answer 1

Isso pode ajudá-lo, a partir do wordpress 2.6, você pode forçar o administrador e as áreas de login a serem configuradas.

link

  define('FORCE_SSL_LOGIN', true);
  define('FORCE_SSL_ADMIN', true);

Sometimes, you want your whole wp-admin to run over a secure connection using the https protocol. Conceptually, the procedure works like this:

Set up two virtual hosts with the same url (the blog url), one secure, the other not. On the secure virtual host, set up a rewrite rule that shuttles all non-wp-admin traffic to the insecure site. On the insecure virtual host, set up a rewrite rule that shuttles all traffic to wp-admin to the secure host. Put in a filter (via a plugin) that filters the links in wp-admin so that once activated, administrative links are rewritten to use https and that edits cookies to work only over encrypted connections.

O plug-in mencionado é chamado admin ssl .

    

Answer 2

Estou enfrentando um problema semelhante, estou usando o wordpress há muito tempo e quero forçar / wp-admin / a trabalhar sobre SSL.

Então eu fiz:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/(wp-login.php|wp-admin/) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Isso está quase funcionando. Quando eu vou para link eu sou redirecionado para wp-login.php sobre SSL, mas depois do processo de loggin eu estou sendo redirecionado para https://website/http://website/wp-admin/ (isso não é um erro de digitação) porque o wordpress usa redirecionamento interno que não funciona bem com a regra de reescrita.
Ao carregar o link novamente, sou redirecionado para o link e tudo está funcionando bem.

Mas antes do recente lançamento do Wordpress havia outro problema, na página wp-login.php, a ação do formulário de login foi definida como link . Então, as informações de login foram enviadas em claro. (Então o patch wp-login.php foi necessário)

Recentes (desde a versão 2.6.0) o lançamento do Wordpress adiciona uma configuração FORCE_SSL_LOGIN . Colocar define ('FORCE_SSL_LOGIN','true'); em wp-config.php fará a ação do formulário em wp-login.php para o link (com uma pequena alteração em wp-login.php você pode adicionar: 8443)

Portanto, com 'FORCE_SSL_LOGIN + reescreve, é seguro, mas ainda tenho que recarregar o URL do wp-admin após o processo de login.

2.6.0 também adiciona FORCE_SSL_ADMIN , mas quando eu configuro isso para true (com ou com minha reescrita configurada) eu redireciono indefinidamente para o link Então você pode tentar setar FORCE_SSL_LOGIN para true e patchar wp-login.php para usar a porta 8443 e você também pode tentar FORCE_SSL_ADMIN (não sei ainda porque não está funcionando para mim, pode ser para você)

    

Answer 3

Mhhh ... Eu tenho uma suspeita de que isso exigiria que o wordpress mangling separasse a seção wp-admin do site principal, o que, até onde eu sei, não foi projetado para ser.

Você não pode configurar um vhost SSL seguro (com o mesmo docroot) e depois via magia .htaccess (o que eu fiz antes) forçar todos os pedidos / wp-admin a passarem por https em vez de http?

Isso obviamente não separa toda a seção administrativa, mas pelo menos significa que o tráfego não criptografado está parado.