Categoria: WordPress

Dicas de segurança para sites WordPress

Hudson Santos Segurança, WordPress Deixe um comentário

Outra dica para ficarmos de olho está relacionada ao entendimento de como o código malicioso se aproveita para iniciar seus trabalhos em sites WordPress vulneráveis. Assim podemos evitar abrir brecha. É um pouco sobre isso que escrevo nesse POST.

Entenda o mecanismo

Normalmente é um processo em grande parte automatizado por sistemas preparados pra isso, mas que só vão ter sucesso, dentre outras, nas seguintes condições:

Condição 1 – Permissões

As permissões dos arquivos foram alteradas pelo administrador desavisado, dando permissão para quem não deveria.

Então muita atenção quando algum plugin ou tem algum erro e, para resolver, os tutoriais orientam ajustar as permissões. Existem incontáveis tutoriais condenáveis mandando colocar tudo 777 (isso é escancarar a segurança, como pendurar todas as chaves no portão na frente de casa).

Basta os robôs de varredura, que trabalham dia e noite (simples como um visitante acessando o site), descobrirem que determinado site está escancarado, e automaticamente ele vai executar um arsenal de explorações conhecidas até conseguir entrar mais a fundo.

Dica de como se proteger

Então a maneira de se proteger é entender como funcionam as permissões e monitorar para que estejam sempre em ordem. Aqui nesse link tem orientações do próprio wordpress.org sobre como devem estar as permissões em um site WordPress. E para quem administra servidores linux, aqui nesse post mostro um pouco mais detalhes sobre como isso funciona.

Condição 2 – Backdoor

A própria pessoa que ‘monta’ o site introduz um backdoor sem saber. Isso infelizmente acontece muito. Nesse caso, mesmo com as permissões OK, e outros mecanismos de segurança também OK, a backdoor já está lá, camuflada e prontinha esperando conexão de quem explorar, sejam humanos ou robôs. Daí basta os robôs explorarem injetando mais código malicioso através da backdoor e o cenário está montado para inúmeros tipos de atividade maliciosa ao mesmo tempo.

Dica de como se proteger

A maneira de se proteger é sempre olhar o código e buscar apenas plugins/temas oficiais do wordpress.org, que tenham reputação a zelar. Desconfiar sempre de plugins muito bons e gratuitos ou muito baratos.

Condição 3 – Novas vulnerabilidades

Algum dos componentes do site ou servidor até então seguro passa a estar vulnerável. Pode ser o sistema operacional, banco de dados, webserver, php, WordPress, plugins, temas… enfim, uma infinidade de componentes.

Pesquisadores e programadores passam dia e noite descobrindo erros em seus códigos e corrigindo, e quando publicam a correção o criminoso estuda e desenvolve o código da exploração para todo mundo que não atualizar o dado sistema com a última versão corrigida. Além disso, normalmente ele treina os robôs para varrerem a internet atrás de sites executando a versão. Essa informação é tão fácil de obter quanto uma simples visita a um site. Por exemplo, aqui nesse link até pouco tempo atrás era possível saber, em milésimos de segundo, qual a versão desse plugin usado aqui no BLOG. Agora me diga: quanto tempo você acha que um desavisado leva pra atualizar um componente vulnerável pra última versão segura? Às vezes anos…

Daí os robôs exploram e injetam ainda mais códigos maliciosos dentro dos interesses de quem comanda essas redes maliciosas.

Dica de como se proteger

Então a maneira de se proteger é mantendo *tudo* sempre o mais atualizado possível.

Condição 4 – Zero-days

Algum componente vulnerável e nenhum dos interessados em corrigir sabe disso. São as chamadas vulnerabilidades “Zero-day”. Nesses casos apenas especialistas muito bem pagos conseguem se proteger, e mesmo assim muito desafiador. É por esses caminhos que muitos criminosos atuam nesse exato momento sem nem mesmo estarem sendo monitorados ou investigados. Estão completamente incógnitos.

Dica de como se proteger

Então não tem muito o que fazer a não ser monitorar a ‘pegada’ – footprint – atividade estranha no servidor. Se a vulnerabilidade estiver sendo explorada para efetuar tarefas leves, dificilmente será percebida, agora se estiver consumindo muito recurso, fica mais fácil de perceber. Normalmente WAFs (que são firewalls de aplicação web, tais como como Wordfence ou Cloudflare) ajudam nisso pois fornecem métricas interessantes.

Concluindo

Então é mais ou menos por aí. Existem ainda inúmeras outras condições. Essas quatro foram as primeiras que me vieram em mente ao escrever esse POST. Quanto mais conhecimento for obtido nessa área e melhor forem implementados os controles, mais seguro é o site. E quanto mais seguro, melhor é a continuidade do negócio ao qual o site pertence. Também mais fácil a atuação de analistas de segurança para uma resposta rápida caso algo aconteça, o que também é fundamental.

Ao mesmo tempo, mecanismos de segurança são importantes e podem ajudar, mas estão longe de ser garantia de segurança. É como se comparássemos com vigilantes ou câmeras de segurança. Melhoram a sensação de segurança e ajudam a resolver alguns problemas pontuais, mas sabemos que de certo tempo pra cá nós vemos a transmissão de barbaridades acontecendo justamente pelas imagens de câmeras de segurança. Elas não impedem, apenas registram.

Cabe a cada um de nós fazer nossa parte em busca de conhecimentos necessários e segurança nesse território perigoso que sempre foi a Internet. Assim ao menos nossos sites WordPress estarão um pouco mais seguros.

Como sempre, obrigado pela leitura.

POST de TESTE – Gutenberg block editor

Hudson Santos Business, Dicas de Ferramentas, WordPress Deixe um comentário
Um pouco melhor a cada dia =)

Depois de bem estável, resolvi testar e atualizar para a versão 5.1.1 do WordPress aqui no blog. Isso implica a aderência, por padrão, do novo editor Gutenberg (em detrimento ao bom e velho TinyMCE) que usa blocos na construção do conteúdo.

Enquanto muitos ficam com medo da nova tecnologia, saiba que é mais rápido e fácil do que o TinyMCE.. bem menos botões. Tudo ficou mais simples e fácil. Me sinto na frente de uma máquina de escrever olivetti, onde só o que se vê são as teclas do teclado e o texto sendo digitado, saindo logo acima.

Para quem preferir continuar com o editor clássico, o WordPress ainda dará suporte para o plugin do Editor Clássico até 2021.

O plugin Editor Clássico restaura o editor anterior do WordPress e a tela de edição de posts, do jeitão antigo. Para instalá-lo, visite sua página de plugins e clique no botão “Instalar agora” ao lado do “Editor Clássico”. Depois que a instalação do plugin terminar, clique em “Ativar” e pronto!

O WordPress também ressalta observação para usuários de tecnologia assistiva: se tiver problemas de usabilidade com o editor de blocos, recomendamos que continue usando o editor clássico.

Plugin este que hoje, 1º de Abril de 2019 conta com mais de 4 milhões instalações ativas e teve sua última atualização de código ha 1 mês.

Mas por enquanto, estou experimentando o Gutenberg e decidido a continuar com ele. Ao menos até que algo me mostre o contrário. Sendo que durante o período de experimento, tenho adicionado exemplos de código como este:

<?php

/* This 3 lines should be commented when finishing development */
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

Ou ainda texto pré formadato como este:

While I agree with this statement, it’s worth noting that in most cases, it is possible to send a mail merge or a group email to multiple recipients from a regular Gmail account, especially if the Gmail account being used has a long history with Google and is established as a legitimate account belonging to a real person.

Ou ainda block-quote (citações – tipo de bloco é o “Citar”) como esta que é bem usada aqui no blog e os fiéis leitores sabem:

“Definitivamente não enviei mais de 500 mensagens, e mesmo assim o Gmail está rejeitando as mensagens.“

Existe ainda outro tipo de citação maior, mais destacada, que é o bloco “Citação”:

O que me refiro quando digo mensagens (de 1 destinatário) não é que estou tendo este problema apenas com um destinatário. Mas sim que todas as mensagens que estou tendo esse problema, não são mensagens com vários destinatários, mas sim mensagens simples, enviadas para apenas um destinatário.

E ainda vídeos incorporados como este do YouTube, usando o bloco de código incorporado:

Então fica a dica. Tudo foi relativamente fácil de fazer. Únicos dois sustos que tive foram:

  1. Na hora de usar o botão “Visualizar” o que estou escrevendo como se já estivesse publicado. Não apareceu nada além do título. Então percebí que é porque lá em cima na barra de edição, ao lado do botão Visualizar, o status mostrava o link “Salvar como rascunho” ao invés de “Salvo.”. Um pouco lento esse intervalo de auto-save do Gutenbert, mas tudo bem.
  2. Ainda não consegui inserir um ícone no meio do texto, como por exemplo um smile, ou um check (v) em html. Mas deve ter alguma maneira de fazer. Anteriormente a gente variava entre as abas “Visualização” e “Texto” e fazia horrores.

Mas agora tudo parece apenas um pouco diferente. Sugiro que, se ainda não o fez, tire um tempo para exercitar. Nunca é tarde. Para quem for mais tradicionalista fique com o editor clássico, a opção do plugin está aí (e tem bastante aderência). Para quem for mais moderno, insista no Gutenberg e aprenda como fazer as coisas nele. Algo de bom Matt Mullenweg e sua comunidade devem ter visto nele para colocá-lo assim como padrão no WordPress.

nginx Error: 413 Request Entity Too Large

Hudson Santos Linux, Linux(Rede);, WordPress Deixe um comentário

Ao instalar um WordPress, um dos problemas que talvez enfrente seja: Erro: 413 Request Entity Too Large
Costuma aparecer ao fazer upload de um plugin, tema, mídia ou arquivo qualquer para seu wordpress. Indica que o tamanho do que você está ‘upando‘ é muito grande. Maior do que o esperado.

O que é necessário fazer pra solucionar?

Basta adicionar a seguinte instrução ao arquivo de configuração do nginx que define o wordpress (/etc/nginx/sites-available/seu_wordpress.conf):

server {
client_max_body_size <Tamanho Desejado>M;
…
}

 
Dessa maneira, passamos a barreira do nginx.
Daí seu blog começa a avisar que o limite encontrado foi no upload_max_filesize do php.ini.
Então, visando ultrapassar a barreira do php.ini, basta incluir isso no final do .htaccess que esta na raiz do blog(/var/www/seu_wordpress/):

php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300
php_value max_input_time 300

 
Feito, isso, ultrapassamos a barreira do php.
Agora sim. Tudo funcionando:

Instalando tema do arquivo enviado: meutema.zip

Descompactando o pacote…

 

Referências:
http://www.wpbeginner.com/wp-tutorials/how-to-increase-the-maximum-file-upload-size-in-wordpress/
http://pt.stackoverflow.com/questions/41619/enviando-arquivos-no-nginx-erro-413-request-entity-too-large

Desenvolvimento de temas WordPress a partir de template HTML– Parte 1

Thiago Santos WordPress Deixe um comentário

Após a instalação do wordpress, crie a pasta com o nome que quiser em wordpress/wp-content/themes/pasta-criada/.

Dentro dela extrai seu template siga os seguintes passos.

O primeiro passo a ser feito é subdividir seu index em páginas lógicas. Inicialmente serão criados os seguintes arquivos:

  • header.php
  • footer.php
  • index.php
  • functions.php
  • style.css

No arquivo header.php, como o nome já diz, irá todo o cabeçalho que estamos acostumados a fazer num index normal, desde o doctype até o fechamento do <header>.

No footer.php seria o que colocamos no rodapé do nosso bom e velho index, do início do <footer> até o final, onde tem o </html>.

No index.php irá toda a parte principal do site onde será colocado todo o conteúdo e o loop (que será explicado mais detalhadamente em futuro POST da série).

No functions.php será onde colocaremos todas as funções do WordPress, a parte mais programática da coisa.

E finalmente crie o style.css. Para o wordpress reconhecer um tema é necessário ter um arquivo style.css com comentários, contendo as informações do tema. Então dentro do style.css adicione o comentário:

/*
Theme Name: Seu Tema
Theme URI: https://blog.smallbee.com.br/
Description: Meu primeiro tema em wordpress.
Author: Seu nome
Author URI: https://blog.smallbee.com.br/
Version: 1.0
Tags: WordPress, smallbee
*/

Agora no index.php adicione na primeira linha a função
<?php get_header(); ?>
que chamará o arquivo header.php. E na última linha
<?php get_footer(); ?>
que chamará o footer.php.

Configurando o Header

Para adicionar título dinâmico utilize a template tag
<?php bloginfo('name'); ?>
entre as tags title ficando assim:

<title><?php bloginfo('name'); ?></title>

Para adicionar descrição dinâmica utilize a template tag <?php bloginfo('description'); ?> na meta tag description, ficando assim:

<meta name="description" content="<?php bloginfo('description'); ?>">

Para colocar a codificação do site adicione a template tag <?php bloginfo('charset'); ?> na meta tag charset <meta charset="<?php bloginfo('charset'); ?>">

Na criação de temas para wordpress é obrigatório o uso de caminho absoluto de imagens, scripts e estilos. A template tag <?php bloginfo( ‘template_url’ ); ?>. Então adicione em todas imagens, scripts e estilos <?php bloginfo( 'template_url' ); ?>/

Exemplos:

<img src="<?php bloginfo( 'template_directory' ); ?>/img//logo.png" alt="Smallbee">

<script src="<?php bloginfo( 'template_url' ); ?>/js/main.js"></script>

<link href="<?php bloginfo( 'template_url' ); ?>/css/main.css" rel="stylesheet">

Pronto! Está feita a primeira parte! Para ver seu mais novo tema em funcionamento, ainda faltam alguns passos que serão postados no decorrer da série, mas você já pode ver seu monstrinho disponível ao acessar seu wordpress/wp-admin no menu Aparência -> Temas e ele estará lá…

Obrigado pela leitura!

Para aprofundar o seu conhecimento da template tag bloginfo consulte a documentação do wordpress, seu melhor amigo a partir de agora: https://codex.wordpress.org/Function_Reference/bloginfo