.png)
Estou tentando descobrir os contras de uma configuração atual e descobri uma anomalia potencial. Há uma página da web hospedada em (digamos) webpage.com. Se eu apontar meu domínio (digamos) mydomain.compara o IP bruto de webpage.com, a webpage.compágina da web real será retornada em uma solicitação da web para mydomain.com. Mas será esta uma boa prática? O VirtualHost (ou SNI) deve filtrar consultas com parâmetro 'host' no cabeçalho HTTP, que não estão presentes no servidor?
Responder1
Idealmente, um host virtual é uma boa prática. É uma maneira simples de se proteger contra vários ataques de criação de domínio (facebok.com, aple.com, micro-soft.com), já que o Apache atenderá apenas solicitações de webpage.com. Sem um vhost seria trivial fazer proxy para seu IP bruto, facilitando a criação mencionada.Aqui estáum artigo da Wikipedia sobre isso.
TLDR: Não, torna mais difícil para outras pessoas se passarem pelo seu site.
Curioso: seu site usa SSL? Os navegadores se recusariam a se conectar devido a um certificado inválido se alguém tentasse um ataque de domínio criado. Também como experiência, pegue um domínio antigo que você não usa mais e aponte-o para o mesmo IP. Visite o domínio.
Responder2
Não importa muito. Mesmo se você "proteger" o VirtualHost Xprecedendo-o com NameVirtualHost X, isso não muda muito. Isso verifica o cabeçalho HTTP do Host que chega ao servidor. Mas ainda é muito fácil para qualquer um configurar seu próprio proxy (por exemplo, seu próprio servidor Apache) para redirecionar para o seu site.
Na Internet pública, não é fácil evitar a situação que eu descreveria como: alguém coloca mydomain.comno seu navegador, mas obtém o conteúdo que deveria aparecer ao público como properdomain.com. E o TLS/SNI também não pode evitar isso.