Recomendamos que todos os usuários de WordPress atualizem imediatamente seus blogs, tendo em vista o risco de infecção por trojans das versões mais antigas.

Para maiores informações sugerimos a leitura do excelente artigo: Trojan infecta blogs em forma de applet.

• Vulnerabilidade do WordPress possibilita roubo de visitas (0)
• Como fazer backup do WordPress (0)
• Atualizando o WordPress para versão 2.8 com segurança (0)
• WordPress de alta performance com Lighttpd (10)
• Vulnerabilidade no novo WP pode ocasionar DoS (5)

Agora, mais do que nunca, usuários do WordPress devem se preocupar com suas senhas, pois umas pessoas muito boas andaram desenvolvendo um sistema que faz tentativas de invasão por força bruta e armazena num banco de dados distribuído os resultados das tentativas.

Se você não captou a maldade, a ideia permite criar um grande cadastro de blogs com as respectivas senhas (fracas) para que sirva-se deles quem bem entender.

A notícia completa (em Inglês) está aqui.

Um motivo a mais para que os usuários em geral passem a levar a sério a responsabilidade que têm sobre suas senhas é uma recente decisão judicial que dá conta que empresas de hospedagem de site não são responsáveis por ataques “hacker” (sic). Particularmente, achamos que é fundamental que as pessoas se conscientizem de que são responsáveis por suas senhas, sejam do que forem, e que o desleixo pode implicar consequências e prejuízos exclusivamente para o desleixado.

• Vulnerabilidade do WordPress possibilita roubo de visitas (0)
• Como viver feliz para sempre com seu provedor de hospedagem (1)
• WordPress de alta performance com Lighttpd (10)
• O tema do WordPress pode sobrecarregar seu servidor (0)
• Isto é uma ordem: atualize seu WP agora! (5)

Portscanning, ou varredura de portas numa tradução livre, é simplesmente a atividade de tentar fazer com que uma máquina conecte em todas as portas TCP disponíveis em outra, com o objetivo de localizar quais portas estejam abertas.

Até aí não existe nenhum problema.

O problema é que os crackers costumam utilizar o portscanning como primeiro passo numa tentativa de invasão, justamente para tentar inferir o que está rodando no servidor, para a partir disso decidir que possíveis vulnerabilidades explorar.

Por esta razão, qualquer firewall minimamente antenado vai primar por detectar o mais cedo possível quaisquer sinais de invasão, e bloquear o acesso do possível agressor à máquina.

“E o Filezilla com isso”, você deve estar pensando.

O Filezilla é um cliente de FTP bastante popular, mas isso não é garantia de qualidade. Um dos problemas muito graves que o programa apresenta é justamente abrir uma nova conexão (chamada de passiva) em uma porta diferente para cada objeto que se vá transferir.

Como os arquivos costumam ser pequenos num website comum, bem como costumam ser transferidos múltiplos simultaneamente (mas isso não faz tanta diferença), a sucessão de portas abertas num período curto caracteriza o portscanning.

Descobrimos que o problema era com o Filezilla porque os clientes que alertaram sobre o problema foram unânimes em dizer que estavam utilizando este programa para transferir arquivos quando o problema começou.

Caso você tenha sido atingido por este problema, deve considerar tomar as seguintes atitudes.

1. Reiniciar o modem para que troque o seu IP, e você possa continuar acessando o servidor a partir de então.
2. Caso não seja possível reiniciar o modem, aguarde o prazo para liberação automática do IP (uma hora).
3. Caso nenhuma das duas acima seja possível, abra um tíquete de suporte informando o seu IP para que ele seja manualmente removido do firewall da sua máquina.
4. E para resolver definitivamente o problema troque de cliente de FTP, existem muitos que não descuidam de reaproveitar conexões abertas em vez de abrir novas.

A melhor sugestão que damos, no entanto, é que habilite acesso shell às suas contas, e passe a utilizar o WinSCP (caso seja usuário de Windows) para transferir seus arquivos: muito mais seguro, e sem efeitos colaterais oriundos de má programação.

• Vulnerabilidade do WordPress possibilita roubo de visitas (0)
• Incompatibilidade entre ModSecurity e Joomla (0)
• Como viver feliz para sempre com seu provedor de hospedagem (1)
• A culpa nem sempre é do servidor! (1)
• Qual o melhor plugin de cache para o WordPress? (8)

Na verdade, a propagação de DNS é uma das coisas mais chatas que eu já vi em todos esses anos nessa indústria vital: você altera a configuração de DNS do seu domínio, e a Internet inteira pode demorar até umas 48h (quando não mais) para passar a acessar o novo servidor.

Se alguém quiser saber por que este efeito desagradável acontece, é só perguntar. Mas para agora o que queremos é mostrar um jeito bem simples de fazer esta verificação.

Para executar esta receita você vai precisar dos seguintes…

Ingredientes

• Um navegador Mozilla Firefox.
• Uma extensão ShowIP para o Mozilla Firefox.

Modo de Preparo

Se você ainda não tiver o Mozilla Firefox instalado em seu computador, por favor visite o site Get Firefox e baixe a versão adequada ao seu sistema operacional e no idioma de sua preferência.

Uma vez que o seu computador já esteja rodando o Firefox, acesse com ele a página de download da extensão ShowIP e baixe a versão mais recente. Já pode fazer a instalação imediata no Firefox.

Quando solicitado, reinicie o Firefox.

Mode de Servir

Esta receita não requer nenhum requinte para ser servida, ou qualquer acompanhamento.

Basta você acessar um site (qualquer um) e observar que no canto inferior direito da janela do Firefox agora aparece, em vermelho, o endereço IP do site que você está visitando. Veja na imagem abaixo o que eu enxergo quando visito o site da PortoFácil (se você estiver vendo um IP diferente deste da imagem, é sinal que o site da PortoFácil mudou de servidor recentemente).

Então, para saber se o DNS do seu site já propagou, basta você saber qual é o IP do novo servidor, e comparar com a informação que o ShowIP dá: se os dois valores forem iguais, seu site está propagado; se forem diferentes é melhor você tomar mais um chazinho enquanto o novo endereço se propaga Internet afora.

• GMail for Domains não recebe mensagens do meu próprio domínio? Bug no cPanel! (0)
• Como viver feliz para sempre com seu provedor de hospedagem (1)
• Apache turbinado com Nginx (4)
• Vale a pena usar o DB-Cache no WordPress? (5)
• O tema do WordPress pode sobrecarregar seu servidor (0)

O Bruno Alves (fonte extremamente confiável) explica (neste post) como o ataque pode acontecer, e também ensina os meios de proteção.

A Via Hospedagem também explica neste post como fazer para proteger-se, de maneira um pouco mais direta para quem não quer saber de teoria e partir direto para a prática.

Recomendamos a todos os usuários de WordPress que instalem o plugin referenciado nos dois textos acima citados, a fim de manter seu blog e seu servidor livres desta vulnerabilidade.

Atualização: se você não instalou o plugin no seu blog ainda, não se preocupe muito, pois nas próximas horas sai a versão 2.8.5 do WordPress, que corrige este e mais outros pequenos problemas de segurança.

• Vulnerabilidade do WordPress possibilita roubo de visitas (0)
• WordPress de alta performance com Lighttpd (10)
• Plugins WordPress a serem evitados (14)
• O tema do WordPress pode sobrecarregar seu servidor (0)
• Novos plugins indispensáveis para o WordPress (0)

Até bem pouco tempo, nós recomendávamos o Hyper Cache como o plugin de cache mais adequado para o WordPress. Entretanto, problemas recentemente apresentados, de gravidade muito considerável, fizeram-nos repensar esta indicação aos clientes da PortoFácil.

Com a ajuda do J. Noronha, do blog O Fim da Várzea, entretanto, temos novas considerações a fazer a este respeito.

Aliás, verdade seja dita: o Noronha fez todo o trabalho pesado, fez todos os testes e comparações, e apenas nos entregou o resultado mastigado. E este resultado das pesquisas do Noronha é que vamos apresentar de maneira mais amigável aqui, agora.

Basicamente, temos duas opções de plugin para o WordPress a considerar: o Hyper Cache, já citado, e o WP Super Cache.

Os principais pontos fortes do Hyper Cache são:

• facilidade de instalação e configuração;
• suporte a plugins que geram versões “mobile” do site.

Os principais fontos fracos do Hyper Cache são:

• maior consumo de memória RAM;
• instabilidade crítica nas últimas versões do plugin (que, felizmente, não afetam 100% dos usuários).

Já os principais pontos fortes do WP-Super-Cache são:

• maturidade do código (é derivado do WP-Cache, o plugin de cache mais antigo do qual alguém ainda se lembra);
• estabilidade (uma vez instalado e configurado);
• habilidade de, mediante regras de reescrita de URL, servir arquivos estáticos diretamente ao visitante;
• o modo “lock-down”, no qual nada invalida o cache até que o administrador assim defina.
• menor consumo de memória RAM.

Em contrapartida, os principais pontos fracos do WP-Super-Cache são:

• instalação não trivial (é necessário criar muitos arquivos manualmente);
• às vezes o plugin não está funcionando, mas o administrador pode nem desconfiar, pois os indícios de problema não são óbvios.

Como se pode ver, são muitas variáveis a se considerar, embora se perguntados os administradores de blogs tendem a ser unânimes, respondendo algo como: “eu quero um que funcione”.

Destarte, há umas poucas linhas gerais que podem ser seguidas para nortear a escolha de um plugin de cache.

1. Seu servidor tem bastante RAM (VPS+3 ou melhor)? Se sim, você pode optar pelo Hyper Cache, caso contrário considere o WP-Super-Cache.
2. Você sabe cumprir todos os passos para instalar o WP-Super-Cache (que diferente do concorrente não é simplesmente instalar e ativar)? Se sim, considere-o; caso contrário fique com o Hyper Cache.
3. Você oferece uma versão compatível com telefones celulares ou PDAs? Se sim escolha o Hyper Cache.

Caso você queira instalar um ou outro plugin de cache em seu blog, já sabe: basta abrir um ticket de suporte, e a gente faz pra você.

• Hyper Cache: instalando corretamente (13)
• Vale a pena usar o DB-Cache no WordPress? (5)
• O tema do WordPress pode sobrecarregar seu servidor (0)
• Ferramentas de cache agressivas para WordPress (6)
• Emule o Landing Sites com JavaScript (1)

Entretanto, nem tudo são flores no reino da Dinamarca (talvez seja melhor parar com os trocadilhos): a última versão realmente estável do HyperCache — pelo que pudemos constatar — é a 2.4.3. A versão mais recente (2.5.1 no momento da redação deste texto) está com erro de código um pouco difícil de detectar, com um efeito devastador: em vez de servir o conteúdo normal para um visitante que deveria ver uma página do cache ele está servindo uma página em branco, mas para o administrador do blog ele serve o conteúdo normalmente.

A recomendação neste caso é simples: não atualize seu HyperCache. Não é para todo mundo que ele está dando problema, mas por via das dúvidas é melhor manter a versão 2.4.3 até que seja divulgada uma versão superior à 2.5.1.

Atualização: o autor do Hyper Cache liberou há umas poucas horas a versão 2.5.5 do plugin, que aparentemente resolve todos os problemas conhecidos. Estamos testando em alguns blogs, e em breve voltaremos a recomendar (ou não) o seu uso.

E quando sair esta nova versão, a sugestão é que não atualize, mas sim abra um ticket conosco pedindo para que façamos o teste, para garantir que você não perderá visitantes por causa de um plugin mal comportado.

E se você ainda não é cliente da PortoFácil e a sua hospedagem não toma conta do WordPress pra você, está esperando o quê pra mudar pra cá?

• O tema do WordPress pode sobrecarregar seu servidor (0)
• Vulnerabilidade do WordPress possibilita roubo de visitas (0)
• Hyper Cache: instalando corretamente (13)
• Atualizando o WordPress para versão 2.8 com segurança (0)
• Vale a pena usar o DB-Cache no WordPress? (5)

Uma situação bastante comum é um sistema totalmente estabilizado que de uma hora para outra passa a apresentar instabilidades, “engasgamentos”, travamentos e outros efeitos pavorosos. À primeira vista nada mudou, nem houve aumento considerável da visitação ao site, então vem a dúvida: será que é o servidor?

Entretanto, invariavelmente, uma análise mais aprofundada e mais criteriosa acaba por revelar um ou mais fatos dos abaixo citados, ou de natureza semelhante.

• Atualização do WordPress.
• Instalação ou atualização de algum plugin.
• Modificação no tema (substituição ou personalização).

Já falamos aqui umas mil vezes sobre o Hyper Cache, em nossa opinião o melhor plugin de cache atualmente disponível para o WordPress. Ele é um ótimo plugin, mas tem uma particularidade que muitas vezes fica esquecida: após atualizar o plugin é necessário entrar em sua página de configurações e salvá-las novamente, a fim de que o sistema de cache fique ativo! Se não cumprir este pequeno ritual o site passa a funcionar sem cache ativo, o que em caso de site de visitação um pouco mais alta pode implicar o travamento total da máquina.

Da mesma forma, o tema em uso no site pode ser um vilão do ponto de vista da programação (“loops” mal escritos, “queries” não otimizadas) como do ponto de vista do webdesign mesmo.

Recentemente tivemos um caso de um servidor que de repente passou a apresentar problemas como os descritos no começo deste texto. Investigando um pouco descobrimos que uma das imagens que o tema referencia não existe, o que faz com que cada chamada a esta imagem (logo, a cada página carregada) acabe gerando uma requisição malsucedida ao servidor, obrigando o WordPress a processar a sua página de erro de conteúdo não encontrado. Acontece que neste tema em especial a página 404.php é bastante complexa, requerendo bastante processamento, o que acaba por criar uma sobrecarga inesperada mas totalmente compreensível no servidor.

Se você quiser verificar seu site em busca de links quebrados, existem muitas ferramentas para este fim na Internet (a maioria na forma de programas executáveis para Windows, algumas poucas que rodam online, direto do navegador). Não é nosso objetivo nem de nossa alçada indicar uma ferramenta destas, mas é certo que encontrando e removendo chamadas a arquivos inexistentes dentro de seu próprio site você estará colaborando muito para que ele funcione de maneira mais estável e eficiente.

• Vale a pena usar o DB-Cache no WordPress? (5)
• Qual o melhor plugin de cache para o WordPress? (8)
• Como viver feliz para sempre com seu provedor de hospedagem (1)
• Hyper Cache: instalando corretamente (13)
• Ferramentas de cache agressivas para WordPress (6)

Não precisa ser o Sylar, mas às vezes é importante saber como as coisas funcionam internamente

Acontece que sempre que há uma grande atualização do WordPress muitos problemas acabam acontecendo: dificilmente os autores de plugins observam as boas práticas que garantiriam atualização tranquila do WordPress, e tampouco preocupam-se em reescrever os plugins de forma a adequá-los a eventuais mudanças na especificação do sistema.

Além das notícias que se ouvem diariamente sobre problemas causados pela atualização do WordPress, temos enfrentado algumas situações aqui na PortoFácil que nos permitem escrever um despretensioso guia de práticas saudáveis com o objetivo de promover a atualização o mais segura possível do WordPress.

1. Desative todos os plugins de seu WordPress.
2. Exclua os arquivos dos plugins que você não usa.
3. Utilize o próprio WordPress para fazer a atualização (caso não funcione, atualize manualmente).
4. Uma vez concluído o processo de atualização do WP vá à página de plugins, e atualize um por um dos que estejam desatualizados (o próprio WordPress avisa).
5. Ative cada plugin, teste o blog inteiro (incluindo feeds, painel de controle, e as opções dos plugins previamente ativos — a partir do segundo plugin ativado, naturalmente); caso o AJAX deixe de funcionar, ou páginas brancas apareçam, desative o último plugin ativado, ou será impossível de usar o WP.

Seguindo os passos acima o risco de você ter problemas com a nova versão do WordPress ficam bastante reduzidas, embora não fiquem anuladas. Caso você não consiga atualizar seu WordPress, abra um ticket de suporte que a gente ajuda no que for possível.

• O tema do WordPress pode sobrecarregar seu servidor (0)
• Erros no WordPress 2.7 após atualização (4)
• Atenção! Versão nova do HyperCache causando problemas! (8)
• Vulnerabilidade do WordPress possibilita roubo de visitas (0)
• Hyper Cache: instalando corretamente (13)

Que tal uma turbina auxiliar para fazer a principal ainda melhor?

Em linhas gerais, o servidor web e o cliente (o navegador do visitante) cumprem os seguintes passos.

1. O cliente inicia uma requisição para o servidor.
2. O programa se conecta ao seu servidor (o SEU, não o dele).
3. Seu servidor (o Apache, em ambientes baseados no cPanel) cria um novo processo para manipular a requisição.
4. Caso o cliente tenha requisitado um conteúdo dinâmico, o servidor web executa um ou mais processos em modo CGI, ou ativa seu módulo interno (como o mod_php) e aguarda até que a requisição tenha sido processada. Ao receber a página resultante o servidor a envia para o cliente.
5. Caso o cliente tenha requisitado algum arquivo estático, o servidor web envia o arquivo para o cliente.
6. O navegador do cliente recebe a resopsta, fecha a conexão com o servidor e exibe o conteúdo.Falando assim, de um único objeto, parece simples.

Agora multiplique este processo pela quantidade de objetos que há numa página (imagens, arquivos CSS, de JavaScript, animações em Flash, etc), e multiplique novamente pela quantidade de requisições simultâneas para ter uma ideia um pouco mais aproximada do trabalho pesado que o Apache tem de fazer a cada instante de sua “marvada” vida.

E ainda mais “marvada” se considerarmos que, por definição, os clientes são lentos, e em muitos casos o Apache vai manter um processo aberto — consumindo memória e ciclos de processamento — apenas aguardando que o cliente termine de baixar o conteúdo servido pelo webserver.

Como a capacidade de processamento dos servidores (computadores, nesse caso) é finita, a solução para garantir que uma mesma máquina possa atender mais visitantes simultâneos é simples: adicionar mais memória e processador, para que o Apache tenha recursos para rodar todos os processos simultâneos que este cenário implica.

Ou então — para quem tem coisa melhor a fazer com seu dinheiro do que investir em hardware quando a solução pode vir por software (livre, ainda por cima) — instalar um outro servidor web “em paralelo” com o Apache para dividir o trabalho. Naturalmente um servidor muito mais leve, que requeira muito menos memória para executar seus processos. No caso em análise, o nginx trata de todo o conteúdo estático do website, e o Apache só tem que lidar com a parte dinâmica.

Desta forma conseguimos uma redução bastante grande no número de processos “filhos” abertos pelo Apache (no passo 3 do esquema acima), pois em vez de abrir um novo processo para cada objeto estático, ele vai deixar que o único processo de comunicação com o nginx delegue a requisição, sobrando tempo e recursos para processar os scripts que realmente dependem do Apache para funcionar.

A título de esclarecimento: o nginx é um servidor web completo, e a única razão de termos escolhido rodá-lo como proxy no Apache foi para não quebrar a compatibilidade com o cPanel, de cujas facilidades a maior parte dos clientes não pode abrir mão.

Na maioria dos casos não é necessário modificar nenhum script do website para tirar vantagem dessa configuração que agora é a padrão para todos os VPSs da PortoFácil: basta ativar o nginx em proxy e curtir a vida vendo o servidor aumentar automagicamente sua capacidade de atendimento de requisições.

Estes também são apaches, mas de outro tipo.

A utilização do nginx em conjunto com o cPanel tem dois efeitos colaterais que podem impedir o seu uso por parte de quem revende hospedagem.

• O tráfego gerado pelo nginx não aparece nos relatórios de consumo de banda do cPanel/WHM — o que geraria um controle subestimado do consumo de banda de cada cliente da revenda.
• É necessário rodar um pequeno script manualmente (até que encontremos uma solução melhor) ao final do processo de criação de uma nova conta, a fim de gerar a configuração do nginx necessária para o novo domínio — o que inviabilizaria a vida de quem cria e apaga muitos domínios diariamente. Atualização: isto não é mais verdade: agora os servidores com Nginx criam e deletam domínios de maneira transparente pelo cPanel/WHMM, sem a necessidade de intervenções externas.

Falar de assuntos técnicos, potencialmente espinhosos, sem cair na superficialidade, é um desafio que, em se tratando de Apache e nginx, parece-me impossível de ser cumprido. Diversos termos técnicos ficaram de fora do presente texto, intencionalmente, porque não serviriam ao propósito de informar em linhas gerais, em vez de formar relatar especificações técnicas deste ou daquele programa.

Mas satisfeito mesmo estarei é quando receber a primeira mensagem do primeiro cliente a acreditar no poder do nginx dizendo que valeu a pena a mudança, e que doravante não quer saber de outra coisa!

• VPS+: a nova geração de VPSs da PortoFácil (7)
• Emule o Landing Sites com JavaScript (1)
• WordPress de alta performance com Lighttpd (10)
• O Servidor Mais Rápido que Já Configurei (0)
• Servidores Virtuais Privados – VPS – na PortoFácil (0)