A visualizar apenas posts da categoria Servidores e Paineis de Controlo

No meu último artigo falei sobre os resultados de performance com e sem Memcached. Algumas das perguntas foram sobre que tipo de servidor tinha e em que empresa estava alojado.

Datacenter genérico

Estou actualmente com a RamNode e tenho um VPS KVM com discos SSD.

Quando escrevi o artigo anterior tinha a VPS com apenas 2GB de Ram, entretanto reduziram os preços e decidi aumentar para 3GB de Ram e ter mais espaço em disco. A máquina encontra-se na Holanda e as latências são baixas, ao nível de um outro servidor que tinha em Inglaterra.

Já estou com esta empresa desde Dezembro de 2015 e não me posso queixar, o uptime é fantástico e a performance dos servidores é muito boa para o valor praticado.

Portanto se ficaram curiosos com a performance reportada no último artigo e se procuram um servidor rápido com discos SSD, possibilidade de ter licença do CPanel mais barata e sem gastar rios de dinheiro já sabem, é na RamNode.

A equipa do CPanel tem andado ocupada com novas funcionalidades de performance e segurança, uma delas é o suporte a HTTP2 com o Easy Apache 4. Está disponível de forma experimental, mas dos testes que efectuei está bastante estável.

E os sites demoram menos 40% do tempo a carregar!

SR71 Blackbird

Efectuei alguns testes através do Pingdom de forma faseada para obter uma média antes e depois de aplicar o protocolo HTTP/2 na página inicial do Mais Gasolina por efectuar pedidos de vários endereços e ter vários tipos de recursos a serem carregados (CSS, JS, imagens, fontes, etc). No total são feitos 47 pedidos e é descarregado um total de 390kB.

Com HTTP/1.1 a média de carregamento ficou nos 1.26s até todos os conteúdos estarem disponíveis, já com HTTP/2.0 a média ficou nos 758ms, uma diferença considerável, perto de 40% mais rápido.

A instalação é extremamente simples, basta seguir os passos indicados na página onde foi pedida esta funcionalidade e em menos de 2 minutos ter os vossos sites com HTTP/2, presumindo que já têm SSL activo, mas se não têm o CPanel também trata disso.

Depois disso podem consultar os headers a partir do vosso browser ou usar uma ferramenta como HTTP2 Test da KeyCDN para verificar que o vosso site já suporta HTTP/2.

Uma forma de tornar o Apache mais rápido é desactivar o suporte a ficheiros .htaccess. Neste artigo vamos aprender como o fazer, mas sem perder a versatilidade que um .htaccess permite.

Comboio Maglev

Os ficheiros .htaccess permitem definir configurações especificas a um determinado domínio sem ser necessário aceder às configurações do servidor em si. Isto é óptimo para ambientes de alojamento partilhado ou servidores privados com vários websites, permitindo configurações independentes para cada domínio.

Mas esta leitura é lenta, o Apache na sua configuração padrão pode recuar vários directórios à procura de um ficheiro .htaccess e aplicar as suas regras. Isto é feito em cada pedido, mesmo com conteúdo estático. Se desactivarmos esta funcionalidade o Apache fica muito mais rápido.

Desactivar é simples, mas queremos manter as regras do mod_rewrite, mod_expires e afins. Estes são os passos que segui para o fazer num servidor com CPanel, mas existem outras formas de o fazer.

Desactivar o .htaccess

Através do WHM do CPanel se acedermos a Apache Configuration > Include Editor vamos editar o ficheiro post_virtualhost_global.conf onde vamos colocar as nossas configurações. Este ficheiro não é rescrito na actualização do Apache, sendo através do CPanel o método ideal em vez de editar os ficheiros do Virtual Host directamente via SSH.

Neste ficheiro vamos colocar os apontadores para os nossos ficheiros .htaccess

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Regras gerais
<Directory "/">
	IndexIgnore *
	AllowOverride none
</Directory>

# Regras separadas por directório, por site
<Directory "/home/username/public_html/">
	IncludeOptional /home/username/public_html/.htacces[s]
</Directory>

<Directory "/home/outrousername/public_html/">
	IncludeOptional /home/outrousername/public_html/.htacces[s]
</Directory>

Explicando o código, no directório inicial “/” vamos aplicar as regras comuns a todo o servidor, neste caso remover os indexes das pastas sem ficheiros index e desactivar o .htaccess com o AllowOverride como none.

Depois para cada pasta de cada site que temos vamos criar uma entrada onde colocamos o ficheiro .htaccess.

O ficheiro é incluído sempre dentro de um parâmetro Directory. Assim em caso de erro no ficheiro ou um ataque apenas vamos afectar aquele domínio.

Usa-se o IncludeOptional com um pequeno truque que encontrei no Stack Overflow para que seja verificado um padrão no nome do ficheiro, desta forma se o ficheiro for eventualmente eliminado não ocorrem erros de configuração e o Apache continua a funcionar.

Se pretenderem também podem copiar o conteúdo do ficheiro .htaccess para aqui, mas desta forma o conteúdo fica separado em ficheiros por cada site, torna-se mais fácil a sua gestão e mantém-se a compatibilidade com algumas funcionalidades do CPanel ou scripts como o WordPress.

Porque é mais rápido desta forma?

Ao contrário de um ficheiro .htaccess carregado pela forma convencional, onde as regras são interpretadas e aplicadas sempre que é feito um pedido (mesmo em conteúdo estático), aqui as regras são carregadas e interpretadas quando o Apache inicia, ficando em memória.

Removemos assim o processo de verificar várias pastas à procura de ficheiros .htaccess e a leitura dos mesmos.

Pontos a ter em conta

Desta forma continua a ser possível usar ficheiros .htaccess, mas o modo de funcionamento não é igual.

Como indiquei os ficheiros são lidos quando o Apache arranca, isto quer dizer que podemos remover ou editar estes ficheiros e as novas regras apenas são aplicadas se reiniciarmos o serviço. Dependendo do sistema operativo onde estamos a correr podemos forçar via SSH o carregamento das regras com um reload.

A versão 58 do CPanel e WHM começou a ser distribuída no canal RELEASE de forma faseada, devendo chegar a toda a gente até ao fim desta semana.

Com esta versão vem uma novidade já esperada, a renovação automática de certificados grátis.

Agência de segurança a espiar

Se não estiveram desligados da tecnologia nos últimos anos sabem certamente que o futuro da web é encriptado. O próprio Google já usa o HTTPS como um sinal de qualidade para os resultados de pesquisa e o novo protocolo HTTP2 só funciona com encriptação em certos browsers (Chrome e Firefox).

Neste momento já existem várias entidades com certificados grátis para a verificação de domínios, sendo a Let’s Encrypt a mais falada do momento. Embora já se encontrassem certificados a menos de 4 Eur por ano, um certificado grátis vai permitir que toda a web possa passar para HTTPS sem custos.

O único problema é que estes certificados têm uma duração limitada de 3 meses e isto obriga a que os processos de renovação sejam automatizados. Não que seja mau, um certificado de curta duração permite teoricamente mais segurança.

Renovação e instalação automática

Com esta nova versão passa a esta disponível a opção Manage AutoSSL. De momento apenas existe disponível como entidade certificadora o CPanel através da Comodo, mas existem planos para incluir também a Let’s Encrypt, já existindo um plugin em fase de testes.

Significa que através do WHM passa a ser tão simples como activar o serviço, escolher as contas onde pretendemos certificados grátis e clicar em Run. Os certificados são gerados, instalados e passam a ser renovados automaticamente.

Deixa de ser necessária a criação de crons para a renovação automática, como fazia com o Let’s Encript, e a partir do CPanel é feita essa gestão.

E porque é isto positivo, se já era possível com algum trabalho ter acesso a certificados grátis? Deixamos de nos preocupar com API’s que estejam sempre a mudar (estou a olhar para ti Let’s Encrypt) uma vez que a equipa do CPanel trata disso. Os utilizadores mais leigos podem também activar SSL sem conhecimentos de bash e gestão de crons. E as empresas que fornecem alojamento partilhado com CPanel podem adicionar aos seus pacotes de alojamento um certificado SSL para o domínio, grátis.

Actualização a 13/08/2016:
Já se encontra disponível o Let’s Encrypt sendo necessário correr um comando por SSH. Mais informações no site do CPanel

O EasyApache 4 vai ser o configurador pré-definido de Apache e PHP no CPanel a partir da versão 58 do WHM. No entanto mesmo com a versão 56 é já possível usar o EasyApache 4.

A actualização não é transparente, mas vale bem a pena.

Stand CPanel numa feira tecnológica

Testei o PHP7 e como todos os meus sites funcionavam (blogs em WordPress também) queria ter o PHP7 no servidor de produção, mas apenas é possível com o EasyApache 4.

EasyApache 3 vs 4

As grandes diferenças da versão 3 é que a actualização é automática, a instalação muito mais rápida e podemos ter várias versões do PHP. Para instalar um módulo ou actualizar a versão do PHP e Apache deixa de ser necessário recompilar tudo, passa a funcionar com RPMs.

No entanto não é possível criar um perfil de forma fácil pelo interface web, tem que ser feito manualmente com um ficheiro JSON e a documentação ainda não é grande coisa. Para um servidor único não é chato, mas para deploy em vários servidores pode ser uma dor de cabeça.

A minha experiência

É preciso aceder por SSH e correr um script de actualização de EA3 para EA4. Na teoria a instalação é migrada para o EA4, mas no meu caso com configurações de MPM e FastCGI o PHP deixou de funcionar.

Ponto positivo, o script que reverte para EA3 funciona bem e voltou tudo a funcionar. Com mais tempo voltei a correr a actualização e foi necessário reconfigurar o Apache e PHP.

Como apenas pretendo o PHP7 tentei criar um perfil em separado com os módulos que já tinha. Desisti e através do interface gráfico comecei a escolher os módulos que precisava. Depois de repostas as configurações do Apache e actualizada a configuração do PHP7 tinha o servidor pronto. Como a instalação é bem rápida coloquei primeiro uma das versões padrão com tudo e mais alguma coisa e fui removendo os módulos que não me interessavam. O downtime foi de cerca de 15 minutos.

As actualizações tem sido feitas sem problema, tendo já recebido duas actualizações do Apache e uma do PHP. Os sites continuam a funcionar sem qualquer interrupção e a versão é actualizada. Acabam-se assim as recompilações manuais, só por isso vale bem a pena.

Depois temos o suporte a PHP7 que é bem mais rápido e se tiverem sites com código legacy podem manter a correr o PHP 5.5 ou 5.6 e decidir que sites usam que versão.

Se tiverem tempo para experimentar recomendo actualizar o EasyApache para a versão 4 e ficarem já precavidos quando a versão 58 começar a ser distribuída no canal RELEASE de actualizações.

Efectuei a alteração de MySQL para MariaDB no meu servidor em produção com CPanel. O upgrade foi feito directamente pelo painel de controlo sem qualquer problema ou downtime.

MariaDB em CPanel

Certamente já conhecem a história, ou novela, da Oracle, MySQL, equipa de desenvolvimento do MySQL e MariaDB. Se não conhecem a versão altamente reduzida é que o criador do MySQL chateou-se com a Oracle e criou o MariaDB. Não é assim tão linear, mas já ficam com uma ideia.

Já andava para mudar para MariaDB há algum tempo, tinha visto que a performance era superior e era bastante simples a migração entre MySQL 5.6 e MariaDB 10. Fiz alguns testes localmente por causa de umas queries do Mais Gasolina com coordenadas, e vi na minha máquina local uma redução no uso de RAM e as queries ligeiramente mais rápidas nas tabelas em InnoDB. Não cheguei a converter nada de MyISAM para AriaDB.

Para mim o melhor do MariaDB é o nome. Como está a ser adoptado em massa vão-se acabar os clientes e colegas que dizem “My Sequel” em vez de “My Ésse Cue Éle” e passam a dizer MariaDB.

Actualização pelo WHM / CPanel

O servidor de produção onde tenho os sites alojados está a correr CPanel e este permite a actualização de forma transparente de MySQL para MariaDB. Aproveitei um problema com o meu antigo fornecedor (tmzVPS), o qual não recomendo de todo, migrei para outra empresa com mais qualidade e aproveitei para testar o upgrade para MariaDB. Assim se algo corresse mal era só voltar atrás porque tinha ainda o outro servidor em produção, mas foi tudo bastante linear e não existiu qualquer downtime durante o processo.

Com o MySQLTuner verifiquei que as optimizações que tinha feito no MySQL continuavam activas, com a mesma configuração, e limitei-me a fazer uns testes e no meu caso a diferença de performance foi muito ligeira.

Pessoalmente recomendo a fazer a actualização para MariaDB antes de um upgrade para MySQL 5.7 uma vez que podem existir problemas de compatibilidade. E o MariaDB está mais que testado, o Google já usa, a Wikipedia está a usar desde 2013 e várias distribuições Linux deixaram de trazer MySQL para trazer MariaDB.

E o melhor de tudo é que é tirar um e colocar outro. Não existem alterações nas queries, os binários continuam com os mesmos nomes (mysqlcheck, mysqldump, etc) portanto não é necessária qualquer alteração em código já em uso.

Com as notícias da NSA, as falhas de segurança recentes do OpenSSL (Hearthbleed e POODLE) e os futuros erros a serem apresentados por alguns browsers em certificados emitidos com SHA-1 os utilizadores de sites com SSL vão ficando com cada vez mais receio sobre a segurança e confidencialidade dos seus dados.

Com este guia é possível ter uma classificação mais alta no teste da Qualys e melhorar a segurança e confiança dos utilizadores num website com SSL.

Classificação A+ no teste da Qualys para o Mais Gasolina

Os passos que irem indicar aplicam-se a um servidor com CPanel/WHM e Apache 2.4, configuração que estou a correr no servidor onde se encontra o Mais Gasolina.

O código do site foi totalmente rescrito com performance, segurança e privacidade em mente. Todas as informações pessoais dos utilizadores encontram-se encriptadas na base de dados, mas isso não chega. Com o aumento de utilizadores a aceder através de redes wifi abertas a segurança é comprometida se o acesso não for feito por HTTPS.

O teste da Qualys permite ver como se encontra a configuração de um servidor e o estado do certificado, ajudando a perceber se a nossa configuração é a correcta e se vai funcionar nos browsers mais utilizados. Podem consultar o resultado do Mais Gasolina que está em A+. Poderia ser melhor, mas iria bloquear o acesso a utilizadores com Android 2.3 que ainda são uma fatia considerável nos acessos com Android ao site.

Emitir o certificado em SHA-2

O certificado e os respectivos CAs devem ser actualizados para SHA-2. Caso o certificado ainda esteja emitido em SHA-1 este é o primeiro passo a efectuar.

O artigo Actualizar certificados de SHA-1 para SHA-2 explica como o fazer e instalar.

Actualizar as cifras no Apache

Através do Web Hosting Manager em Service Configuration > Apache Configuration > Global Configuration é necessário definir o parâmetro SSL Cipher Suite com o seguinte:

1
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4

Esta é a cifra que estou a utilizar e, embora não seja perfeita, permite o acesso a clientes com Android 2.3 sem comprometer a segurança do servidor com suporte a Forward Secrecy.

O parâmetro SSL/TLS Cipher Suite também deve ser alterado, caso ainda não tenham alterado é muito provável que o servidor esteja exposto ao POODLE.

1
All -SSLv2 -SSLv3

Isto irá permitir que todos os protocolos, excepto SSLv2 e v3 possam ser usados no servidor. Ficam assim activas as versões 1.0, 1.1 e 1.2 do TLS.

Bloquear ataques com renegociação do protocolo e compressão

No Web Hosting Manager em Service Configuration > Apache Configuration > Include Editor adicionamos ao Pre Main Include no ficheiro All versions o seguinte:

1
2
SSLHonorCipherOrder On
SSLCompression off

Isto vai bloquear os ataques quando é utilizado um protocolo inferior ao mais recente suportado pelo browser. Ao desactivar a compressão do SSL bloqueamos também os ataques BREACH e CRIME. Não confundir com a compressão de um website, esta continua activa.

Activar HSTS

Ainda no Web Hosting Manager em Service Configuration > Apache Configuration > Include Editor adicionamos ao Pre VirtualHost Include no ficheiro All versions o seguinte:

1
2
3
<IfModule mod_headers.c>
Header add Strict-Transport-Security "max-age=15768000;includeSubDomains" env=HTTPS
</IfModule>

Isto vai adicionar o header Strict-Transport-Security a todos os websites que são acedidos por HTTPS. É necessário ter o mod_headers instalado, pode ser facilmente adicionado através do EasyApache no WHM.

 

Espero que esta configuração seja útil. É possível que não funcione em todos os sistemas, mas foi o que utilizei no Mais Gasolina para obter a classificação A+ no teste com o CPanel/WHM e o Apache 2.4.

Estas alterações são todas feitas pelo interface do Web Hosting Manager para evitar que sejam perdidas em futuras actualizações, situação comum quando se edita os ficheiros manualmente.

Actualização a 16/05/2017:
Actualizadas as cifras para incluir ChaCha20 e remover algumas cifras consideradas fracas
 
Copyright © 1985 - 2017 Eduardo Maio. Alguns direitos reservados.
eduardomaio.net - Às vezes mais valia ser Agricultor do que Programador
Ao navegar no blog eduardomaio.net está a concordar com os termos legais e de privacidade.