Tutorial Debian 8 x64 com ISPConfig e NginX: Configurações Adicionais

Após a instalação e configuração do servidor e dos sites existem algumas tarefas diárias que devemos executar para monitorar os arquivos e os serviços.

Neste artigo adicional aprenda como direcionar os emails do root para uma conta válida pois não é possível fazer acesso POP na conta do root. E veremos ainda como criar alguns scripts que ajudam na administração.

Segurança: Scripts e Configurações Adicionais
1 Redirecione os emails do root para outra conta

Isso é importante pois alguns emails administrativos do servidor são enviados somente para o superusuário root na máquina local. Por exemplo: se alguém cadastrar um segundo usuário admin no ISPConfig um email será enviado ao root.

1a ⇒ Acesse o terminal SSH como root

1b ⇒ Edite o arquivo /root/.forward (para visualizar arquivos com um ponto no início “arquivos ocultos” digite o comando ls -al). Adicione a seguinte linha:

* Substitua o email abaixo por outro válido e que exista

[email protected]

1c ⇒ Método Alternativo: Caso o primeiro método não seja possível ou não funcione em seu sistema use esta segunda opção. Edite o arquivo /etc/aliases e no final adicione uma nova linha (DICA: direcione para outra conta interna no próprio servidor como a contato de algum site, caso o SMTP esteja bloqueado por algum motivo mesmo assim você poderá recuperar os emails via POP):

root: [email protected]

Após salvar o arquivo digite o comando:

root# newaliases

2 Script para monitorar alteração nos arquivos dos sites

Alguns leitores reportaram recentemente que tiveram os sites hackeados, não pelo motivo de terem invadido o servidor mas somente um site isolado (via code injection ou senha fraca cadastrada para o site). Após analisar os ataques nota-se que o invasor instala arquivos adicionais que enviam spam ou atacam outros sites a partir do VPS.

Veja abaixo como criar um script simples de monitoramento, muito útil para detectar infecções por malware e outras pragas.

2a ⇒ Crie um arquivo de script no diretório /root mudando as permissões para que somente o root consiga alterar e executar:

root# touch /root/site-monitor

root# chmod 700 /root/site-monitor

2b ⇒ Edite o arquivo e cole o seguinte conteúdo, substituindo os textos em vermelho por informações do seu servidor e pelos seus emails:

* Note que configurei o comando find para encontrar arquivos modificados nos últimos 60 minutos pois criaremos uma tarefa agendada para executar a cada hora

* Se nenhuma alteração for encontrada o email não será enviado

* Cole os comandos abaixo no arquivo de script sem alterar espaçamentos ou formatação, isso é importante pois usaremos um bloco de código here docs na configuração

* O site fatorbinario.com abaixo representado está em um caminho definido por padrão em instalações com ISPConfig. Para outros CPs ou sistemas veja qual o caminho definido para o site. (Pode-se ainda usar coringas de shell)

#!/bin/bash
# Monitora o site e verifica os arquivos alterados na ultima hora

SITEMONRESULTS=$(find /var/www/fatorbinario.com/web -type f -mmin -60 -exec ls -ls {} \;)
if [ ! -z "${SITEMONRESULTS}" ];
then
cat <<EOF | /usr/sbin/sendmail -t
To: [email protected]
Subject: Arquivos do site alterados na ultima hora
From: [email protected]

Os seguintes arquivos do site foram alterados:

$SITEMONRESULTS

EOF
fi

2c ⇒ Teste e veja se o script funciona. Copie um arquivo qualquer para o diretório do site e rode o script (se o arquivo for detectado você receberá um email com a path completa e demais detalhes):

root# /root/site-monitor

2d ⇒ Crie um agendamento no Cron para executar a verificação a cada hora. No exemplo abaixo executaremos o script sempre aos 30 minutos de cada hora.

* Caso solicite qual o editor você deseja configurar escolha o primeiro (nano)

root# crontab -e

Dentro do arquivo abra uma nova linha ao final e digite:

30 * * * * /root/site-monitor

Para sair e gravar tecle “CTRL + X” em seguida tecle “Y” e ENTER

Para consultar a alteração no crontab digite:

root# crontab -l

2e ⇒ ALTERNATIVA usando o comando mutt para enviar a mensagem com os resultados em arquivo anexado:

O método acima com sendmail é o que eu uso em meus scripts, mas notei que se houverem muitas atualizações de plugins em um site WordPress por exemplo o email fica com uma listagem muito grande. Neste caso a melhor alternativa é criar um arquivo texto temporário com os resultados e anexar ele na mensagem. Usaremos o comando mutt que permite uma facilidade maior para esse tipo de envio.

Siga os mesmos passos acima mas dentro do script cole o código abaixo substituindo o que está em vermelho (Note que em “From” pode-se alterar o nome do sender além do email dele):

#!/bin/bash
# Monitora o site e verifica os arquivos alterados na ultima hora

SITEMONRESULTS=$(find /var/www/fatorbinario.com/web -type f -mmin -60 -exec ls -ls {} \;)
if [ ! -z "${SITEMONRESULTS}" ];
then
cat > /tmp/sitemonresults.txt <<EOF
$SITEMONRESULTS
EOF
echo "Arquivos do site foram alterados recentemente, verifique a lista em anexo." | mutt -s "Arquivos do site alterados na ultima hora" -e 'my_hdr From:Email que Envia <[email protected]>' [email protected] -a /tmp/sitemonresults.txt
fi

* No script acima o comando FIND pode ser alterado para procurar em vários sites ao mesmo tempo.

Altere isso:

SITEMONRESULTS=$(find /var/www/fatorbinario.com/web -type f -mmin -60 -exec ls -ls {} \;)

Para isso (note que a única alteração é usar o asterisco como wildcard):

SITEMONRESULTS=$(find /var/www/*/web -type f -mmin -60 -exec ls -ls {} \;)

E para procurar em múltiplos sites e excluindo múltiplos diretórios de cache use a opção abaixo (este é o exemplo que uso em meu site ignorando os logs criados pelo UpdraftPlus e o cache gerado pelo WP Fastest Cache):

SITEMONRESULTS=$(find /var/www/*/web -not \( -path "/var/www/*/web/wp-content/updraft/*.txt" -prune \) -not \( -path "/var/www/*/web/wp-content/cache/*" -prune \) -type f -mmin -31 -exec ls -ls {} \;)
3 Script para reiniciar o MySQL automaticamente caso seja desligado

Como já expliquei em outros tutoriais quando a carga no servidor é muito grande alguns serviços começam a ser desligados por segurança. Na maioria das vezes o MySQL é o primeiro a cair.

Por exemplo: se algum site for atacado a CPU e memória ficam a quase 100% de uso por um longo período, drenando todos os recursos. O MySQL tentará fazer novas requisições mas não encontrará disponibilidade, sendo desligado em seguida. Nesses casos podemos simplesmente reiniciar o serviço que os sites voltarão ao normal.

* Não confundir com a falta de memória, que na maioria das vezes resolve-se facilmente adicionando uma partição SWAP ao sistema.

3a ⇒ Crie um arquivo de script no diretório /root mudando as permissões para que somente o root consiga alterar e executar:

root# touch /root/mysql-monitor

root# chmod 700 /root/mysql-monitor

3b ⇒ Edite o arquivo e cole o seguinte conteúdo:

* Este é o único script que funciona corretamente, os demais que aparecem em buscas do Google têm falhas e com certeza não foram devidamente testados.

#!/bin/bash
# Reinicia o MySQL em caso de desligamento
# Ajuda com os comparativos de if: man 1 test

UPMYSQL=$(lsof -i :3306 | grep mysql | wc -l);
if [ "$UPMYSQL" -le 0 ];
then
 /etc/init.d/mysql restart
fi

3c ⇒ Teste e veja se o script funciona:

root# /root/mysql-monitor

3d ⇒ Crie um agendamento no Cron para executar a verificação a cada 5 minutos:

root# crontab -e

Dentro do arquivo abra uma nova linha ao final e digite:

*/5 * * * * /root/mysql-monitor

Para sair e gravar tecle “CTRL + X” em seguida tecle “Y” e ENTER

Script para reiniciar o NginX e o PHP em horários predeterminados

Se você mantém muitos sites em um mesmo servidor ou se tiver um site com muitos acessos talvez já tenha notado que de vez em quando o acesso fica lento. Isso pode acontecer por vários motivos mas o que acontece muito é que se alguém tentar spoofar ou fazer um ataque os processos em memória e cache podem demorar a regenerar.

Um truque usado mundo afora é de simplesmente reiniciar os serviços do servidor de páginas web. Após analisar centenas de logs em servidores cheguei à conclusão que os melhores horários para fazer isso são os descritos na configuração do crontab abaixo.

4a ⇒ Crie um arquivo de script no diretório /root mudando as permissões para que somente o root consiga alterar e executar:

root# touch /root/webserver-reload

root# chmod 700 /root/webserver-reload

4b ⇒ Edite o arquivo e cole o seguinte conteúdo:

#!/bin/bash
# Reinicia o PHP-FPM e o NginX

/etc/init.d/php5-fpm restart
/etc/init.d/nginx restart

4c ⇒ Teste e veja se o script funciona:

root# /root/webserver-reload

4d ⇒ Crie um agendamento no Cron para executar a tarefa em horários predeterminados:

root# crontab -e

Dentro do arquivo abra uma nova linha ao final e digite:

30 1,7,12,20 * * * /root/webserver-reload > /dev/null

Para sair e gravar tecle “CTRL + X” em seguida tecle “Y” e ENTER

* A tarefa acima será executada às: 01:30, 07:30, 12:30 e 20:30. São horários mais tranquilos na maioria dos sites mas caso queira pode alterá-los.

* O reload dos serviços demora menos de 2 segundos.

* Adicionando este script aos sistema pode-se combater inclusive ataques DDoS.

5 Script personalizado e melhorado para o RKHunter

O RKHunter ainda é uma das ferramentas mais usadas para detecção de rootkits e malware em servidores. Neste exemplo mostrarei como usar a ferramenta (se você instalou o servidor seguindo o meu tutorial de Debian com ISPConfig o RKHunter já está instalado e ativo mas talvez você não esteja recebendo alertas por email)

No arquivo de configuração padrão o programa que envia emails é o “mail” que nem existe em nossa instalação. E para não ter que instalar mais uma brecha para hackers vamos simplesmente criar um novo script de verificação para o RKHunter e usar o sendmail como nos demais scripts acima.

5a ⇒ O RKHunter já está instalado mas é necessário fazer um primeiro update e atualizar o banco de dados com um “snapshot” dos arquivos atuais assim a ferramenta terá um ponto de comparação para acusar alterações:

root# rkhunter --versioncheck

root# rkhunter --update

root# rkhunter --propupd

5b ⇒ Crie um arquivo de script no diretório /root mudando as permissões para que somente o root consiga alterar e executar:

root# touch /root/rkhunter-monitor

root# chmod 700 /root/rkhunter-monitor

5c ⇒ Edite o arquivo e cole o seguinte conteúdo:

* Substitua as informações em vermelho e não altere o formato do script.

#!/bin/bash
# Executa o RKHunter e envia relatorio por email caso encontre algo suspeito

RKHMONRESULTS=$(/usr/bin/rkhunter --versioncheck --update --cronjob --report-warnings-only)
if [ ! -z "${RKHMONRESULTS}" ];
then
cat <<EOF | /usr/sbin/sendmail -t
To: [email protected]
Subject: Resultado do RKHunter para o servidor
From: [email protected]

Os seguintes avisos foram encontrados:

$RKHMONRESULTS

EOF
fi

5d ⇒ Teste e veja se o script funciona:

root# /root/rkhunter-monitor

NOTA: O comando poderá demorar uns 2 minutos para ser executado. Com a configuração padrão do arquivo /etc/rkhunter.conf você deverá receber um aviso por email mostrando que o login SSH do root está ativado, se quiser suprimir este aviso descomente a linha 306 e altere o parâmetro para “yes“.

OBS: Não há necessidade de ativar os  comandos de MAIL nas linhas 133 e 144 pois o script acima irá se encarregar disso.

5e ⇒ Crie um agendamento no Cron para executar a tarefa todos os dias às 07:40 hrs:

root# crontab -e

Dentro do arquivo abra uma nova linha ao final e digite:

40 7 * * * /root/rkhunter-monitor

Para sair e gravar tecle “CTRL + X” em seguida tecle “Y” e ENTER

6 Habilite o log do Cron

Por padrão o log das tarefas agendadas no Cron do sistema, via Crontab, não está habilitada no Debian. Para ativar siga os seguintes passos:

6a ⇒ Edite o arquivo /etc/rsyslog.conf e descomente a linha 63:

cron.* /var/log/cron.log

6b ⇒ E reinicie o serviço:

root# /etc/init.d/rsyslog restart

* Os logs das tarefas agendadas começarão a ser gravados em /var/log/cron.log

Índice do Tutorial:

Gerenciamento de Servidores Cloud com atendimento e consultoria em português. Planos mensais com os melhores preços do mercado.
Envie um email para [email protected] e saiba mais!

*Regarding english support please contact me by email or post a comment using the Disqus system. I do offer monthly support and custom server deploy. Now accepting Paypal and Bitcoin!

  • Tô empacado no 2C. Fui fazer o teste do script e retorna o seguinte erro:

    “-bash: /root/site-monitor: /bin/bash^M: bad interpreter: No such file or directory” Alguem pode ajudar?

  • A primeira linha de um script BASH deve sempre começar como está descrito no exemplo incluindo aqueles simbolos.

    Se mesmo assim não der certo é porque o seu editor de textos está inserindo lixo no arquivo. Para solucionar abra o console e edite o arquivo com o editor do Linux NANO, exemplo: nano /root/site-monitor

    E dentro dele cole o script do tutorial.
    Para salvar o arquivo com o nano tecle CTRL + X em seguida Y e ENTER

  • corrija

    Fala grande Luis.
    Fui dar o comando /root/webserver-reload apareceu falha no final. Oq seria isso ?

    [email protected]:~# /root/webserver-reload
    [ ok ] Restarting php5-fpm (via systemctl): php5-fpm.service.
    [….] Restarting nginx (via systemctl): nginx.serviceJob for nginx.service failed. See ‘systemctl status nginx.service’ and ‘journalctl -xn’ for details.
    failed!

  • corrija

    Caro Luis…depois desses passos o servidor desligou, ta dando error 521…
    Será oq aconteceu?
    preciso de sua ajuda…

  • Erro 521 onde?

    Pelo que você escreveu abaixo o NginX não reiniciou.

    Reinicie o servidor com o comando:
    > shutdown -r now

  • corrija

    Quando tento abrir o site, ou o ispconfig dá isso agora.
    Parece que é o nginx…
    TEntei reiniciar o nginx mas da esse erro
    Restarting nginx (via systemctl): nginx.serviceJob for nginx.service failed. See ‘systemctl status nginx.service’ and ‘journalctl -xn’ for details.

    depois q fiz o shutdow o site cai na pagina Apache2 Debian Default Page, mas o ispconfig nao conecta;;;

  • corrija

    Restarting nginx (via systemctl): nginx.serviceJob for nginx.service failed. See ‘systemctl status nginx.service’ and ‘journalctl -xn’ for details.
    failed!

  • Faça o shutdown 0r novamente.

  • corrija

    Luis, eu resolvi.
    Obrigado meu amigo.
    Eu segui os processos e pelo que entendi a porta 80 já estava sendo usada por outro processo e por isso n reiniciava (tb tinha erros no nginx confg.) consegui consertar e ta tudo legal novamente.
    Obrigado pela ajuda. Seu conteúdo é incrível!!

  • Opa Luis! Deixa eu te falar…

    Eu configurei o recurso de microcache do ngnix para um site e escolhi a seguinte pasta para salvar os arquivos de cache: “/dev/shm/microcache”

    A grande questão é que eu recebo todo dia avisos de arquivos suspeitos do rkhunter em relação a esses arquivos de cache…

    “/dev/shm/microcache/b/05/a1bdaa77405af45a606d11371f80705b: data”

    É uma longa lista de mensagens parecidas com essa acima! Estava pesquisando por uma forma de ignorar essa pasta durante os scans e encontrei uma pessoa com um problema bem parecido com o meu neste link: https://sourceforge.net/p/rkhunter/mailman/message/30362584/

    Uma iutra pessoa, nas respostas do link acima, sugeriu mudar nas configurações a opção SCAN_MODE_DEV de THOROUGH para LAZY, mas eu não sei se essa é a melhor opção pq no arquivo de configuração do rkhunter diz o seguinte…

    “A THOROUGH scan will increase the overall runtime of rkhunter. Despite this, it is highly recommended that this value is used.”

    Sendo assim a grande dúvida é a seguinte…

    Você saberia me dizer uma maneira de fazer o rkhunter ignorar a pasta “microcache” criada por mim?

    Desde já o meu muito obrigado!

  • No arquivo /etc/rkhunter.conf entre as linhas 697 a 706, veja o exemplo lá mas basicamente isso deve funcionar:

    ALLOWDEVFILE=/dev/shm/microcache/*

  • Vlw Luis! Consegui resolver, mas tive que adaptar o caminho pq os arquivos são gerados em dois níveis de pastas dinâmicos, aí a solução ficou assim: ALLOWDEVFILE=/dev/shm/microcache/*/*/*

    Mas agora me surgiu mais um problema e mais uma dúvida em relação aos scripts desse tutorial, vamos lá…

    1º [PROBLEMA] – Eu já havia configurado o script “/root/site-monitor” em um outro servidor e por lá o recurso funciona mt bem, mas em um servidor recém configurado não está funcionando! Eu imaginei que fosse algum problema no envio de e-mails então alterei essa linha: “if [ ! -z “${SITEMONRESULTS}” ];” para isso: “if [ -z “${SITEMONRESULTS}” ];”…

    A alteração feita foi apenas remover o sinal de negação (!) para enviar o e-mails mesmo que não tenha encontrado arquivos alterados, então conclui que o e-mail está enviando bem, assim como é enviado corretamente pelo script do rkhunter. Me parece que o problema é que a variável SITEMONRESULTS não está sendo carregada com as alterações feitas nos diretórios dos sites nos últimos 60 minutos, mas em outro servidor o mesmo script funciona muito bem.

    Tem alguma ideia do que possa estar acontecendo?

    2º [DÚVIDA] – Quando eu testo o script “/root/mysql-monitor” não aparece na tela que o mysql foi reiniciado assim como aparece no script de reinicialização do ngnix e do php. Acredito que seja pq a condição IF não esteja sendo atendida já que, pelo que entendi, a ideia é acionar esse script só em casos de desligamento. A dúvida é…

    Ao rodar “/root/mysql-monitor” para testar se o script está funcionando, devo esperar algum feedback de reinicialização do mysql ou não é apresentado saída nenhuma mesmo?

  • Você pode executar o comando find que está entre parênteses pelo console, não precisa ser dentro do script para testar. Copie desde o find até o ponto e virgula e cole no console, veja o que aparece.

    O monitoramento de MySQL não mostrará saida alguma mas funciona 100% quando o MySQL cair ou arrebentar.

    Os scripts funcionam bem e uso em vários servidores de clientes.. veja se o timestamp do servidor está correto, digite “date” e olhe também os arquivos de log se estão gravando o horário certo. *Há algumas diferenças no Kernel compilado usado na Vultr para a Digital Ocean, na Digital ele é melhor otimizado. Um exemplo é o rsync que nem vem na ISO pela Vultr, outro é o mutt que fica defeituoso na Vultr (tem um truque legal para usar o mutt enviando email mesmo com a porta SMTP bloqueada mas não funciona lá).

  • Vlw Luis! Dúvida esclarecida sobre o script do MySql, mas agora surgiu outra dúvida sobre o outro script… hehe

    Fiz o que você recomendou, digitei o comando find diretamente no console e realmente não está retornando nada, mesmo tendo adicionado diversas vezes arquivos diferentes no diretório do site. Também verifiquei o “date” e a hora está certinha, nos arquivos de log também está gravando tudo direito.

    Mas aí, para testar em uma pasta diferente, executei o comando find para a pasta de logs do site e vi que o find acusava o arquivo error.log de ter sido alterado na última hora, então abri um arquivo TXT que havia copiado para o diretório web do site e alterei o seu conteúdo, executei o comando novamente para /web/ e tudo funcionou bem!

    Eu nem havia tentado fazer isso antes pq nesse trecho do tutorial, que vou reproduzir logo abaixo, dá a entender que basta copiar o arquivo e o comando find encontrará o arquivo adicionado, mas só funcionou aqui pra mim depois de ter alterado o conteúdo do arquivo adicionado…

    “Teste e veja se o script funciona. Copie um arquivo qualquer para o diretório do site e rode o script (se o arquivo for detectado você receberá um email com a path completa e demais detalhes)”

    O funcionamento é esse mesmo? Esse comando só retorna arquivos recém alterados e não os recém adicionados?

  • Funciona com os adicionados sim, o comando find é do prórpio sistema. Deve estar havendo algum problema na detecção dessas modificações. Tomara que isso não cause falha de detecção nos arquivos de log usados pelo Fail2Ban ou o seu sistema estará em risco. Você instalou Debian 8 x64 ?

    Eu uso esse script no meu próprio site e recebo o email avisando toda vez que adiciono um plugin ou alguém sobe um avatar na Comunidade por exemplo.

  • Sim, instalei o debian 8 X64 com ISPconfig e tal, segui o seu tutorial à risca! Fui testar agora no primeiro servidor que configurei e está do mesmo jeito, mas não havia percebido antes pq o e-mail sempre era disparado por conta de outros arquivos existentes alterados, mas arquivos recém adicionados nunca são incluídos na listagem.

    Ambos os servers só retornam alguma coisa quando um arquivo é alterado. Vou pesquisar aqui e vê se descubro o que está acontecendo. Se conseguir uma resposta, volto aqui para compartilhar. Se tiver uma ideia ou sugestão de qual caminho seguir, também ficaria (mais ainda) mt grato!

  • Eu não quero parecer chato Glauber mas alguns clientes pediram para configurar na Vultr e tive vários problemas lá, na Digital eles recompilam o Kernel que é melhor adaptado. O meu palpite é de que falta algum módulo no kernel do sistema, mas é só um chute..

    Farei uma instalação nova para cliente agora à tarde na Digital, assim que terminar vou testar o script e ver se mudou alguma coisa, mas nos últimos servidores configurados estava 100%.

  • Esquenta não Luis! Sei que quando recomenda a digital ocean sua intenção é ajudar, mas pra mim agora é inviável mudar de host pq to atrasado em outros projetos por aqui, mas acabei conseguindo resolver o problema mudando a forma como o comando find estava filtrando os arquivos…

    Antes era assim:

    find /var/www/*/web -type f -mmin -60 -exec ls -ls {} ;

    Agora está assim:

    find /var/www/*/web -type f -cmin -60 -exec ls -ls {} ;

    Como você sabe eu sou inexperiente em linux e configuração de servidores, mas pesquisando a respeito do “cmin” e do “mmin” eu pude perceber que a diferença entre os dois é a seguinte:

    Se você mudar o conteúdo do arquivo, ambos (cmin ou mmin) funcionam!

    Mas se você mudar um metadado/status do arquivo (ex: Nome,Permissão etc) aí apenas o “cmin” funciona…

    Fiz o teste aqui e percebi que quando adiciono um arquivo novo e digito o find com o “cmin” ele retorna o arquivo recém adicionado e alterei o conteúdo de um arquivo que já existia pra fazer o teste e ele também funcionou, ou seja, retorna tanto os arquivos o recém adicionados quanto os recém modificados! =D

    Talvez no karnel otimizado da digital ocean isso não faça diferença e por isso o problema nunca ocorreu com vc, mas na vultr tive que fazer essa pequena alteração pra fazer funcionar…

    Minha principal referência foi essa aqui: https://d5levelfc.wordpress.com/2013/11/27/find-command-with-cmin-amin-mmin-test/

    Espero que isso ajude outros leitores que talvez passem por um problema parecido. Acredito que isso não gere nenhum impacto no funcionamento/segurança do script. O que você acha?

  • Legal. Até agora não tive problemas com essa detecção por isso apontei que o problema pode estar no kernel. Para saber se o Fail2Ban está detectando verifique o log dele e veja se tem bans no SSH por exemplo, em qualquer servidor o SSH é o mais atacado mesmo em instalações novas.

    E como sempre valeu pela contribuição nos comentários.

  • Sim! O log está cheio de linhas como essa abaixo…

    2016-08-09 17:09:36,144 fail2ban.actions[1162]: WARNING [ssh] Ban 116.31.116.7

    E no servidor configurado a mais tempo além do bans para ssh, tem tbm um monte de ban para outros serviços como pureftp e postfix…

    Acho que posso ficar tranquilo né? hehe

  • Sim, parece tudo certo no Fail2Ban. Vou dar uma olhada no caso de detecção dos arquivos no site.

  • Show! Qualquer novidade volto a comentar por aqui… obrigadão!

  • Rafael Oliveira de Santana

    Muito show esse seu tutorial hein!