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:

Gestão em infraestrutura de Servidores Cloud VPS e Dedicados. Planos mensais acessíveis e consultoria diferenciada para agências de marketing.
Envie um email para [email protected] e solicite uma análise gratuita!

  • 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!

  • Felipe

    Boa noite, estou tentando instalar o ioncube, utilizei seu tutorial mas o site continua pedindo ion cube, o que será que falta ?
    https://fatorbinario.com/comunidade/topico/como-instalar-o-ioncube-php-loader/ – utilizei <<< este tutorial
    mas ainda não está rodando eu acho…

  • Deveria funcionar…

  • Felipe

    esse link quem me deu foi a digitalocean…

  • O problema parece ser a versão do Loader. Você fez os testes sugeridos no tutorial?

  • Felipe

    fiz sim tudo do tutorial

  • Felipe

    sabe como resolve isso ?

  • Felipe
  • Opa Luis, bom dia!

    Deixa eu te perguntar…

    Existe algum tutorial para indicar que ensina como criar um script para realizar atualizações de segurança do sistema de maneira automática e a prova de erros? hehe

    Tentei usar direto no terminal o “apt-get update” e o “apt-get upgrade” para atualizar o sistema, mas o clamav retornou um erro parecido com esse ao executar o segundo comando: “E: SUB-PROCESS /USR/BIN/DPKG RETURNED AN ERROR CODE (1)”

    Aí acabei voltando um bkp (snapshot) do me vps pq não sabia como resolver o problema.

    Daí, se tivesse um script que executasse o processo e já tivesse mecanismos para prevenir esse tipo de erro, seria bacana!

    To pesquisando aqui e vi que algumas pessoas dizem para usar o “apt-get autoclean” e o “apt-get clean” antes dos comandos que utilizei para atualizar ou então alterar o sources.list caso o erro persista.

    Enfim! To um pouco perdido nessa questão das atualizações…

    Se você puder me dar um norte ou indicar algum tutorial (pode ser em inglês mesmo) confiável, agradeço desde já! =)

    Outra coisa, quando se atualizam o PHP aparece um janela perguntando se eu desejo manter o php.ini local modificado ou atualizar para a nova versão… Nesse caso é melhor manter o arquivo local ou atualizar para o novo php.ini e refazer as alterações indicadas na parte de otimizações do seu tutorial?

  • O apt-get upgrade já é o melhor processo para atualizações. Mas pelo jeito você quer alguma coisa que faça um pré-processamento e avise antes.. acho isso meio improvável.

    Criar um snapshot como segurança é sempre a melhor opção. E quanto aos erros teria que caçar um por um e solucionar.. sempre foi assim com upgrades.

    Se o erro é no Clamav e você não usa ele, no tutorial ensino a desativá-lo e pode ser por isso que dá erro. Eu deixaria ele quieto num canto mesmo com o erro, você não precisa de anti-virus na maioria dos casos.

    A atualização do PHP sempre irá solicitar se deseja manter o .ini ou atualizar criando um novo. Se você lembra exatamente o que foi alterado pode atualizar ele e alterar novamente os parâmetros anteriores somente (na maioria das vezes eu mantenho o que já está lá, dificilmente eles alteram parâmetros significativos em sub-versões).

  • Entendi! Tinha pensando em deixar quieto mesmo esse erro justamente por não usar o clamav, mas na insegurança da primeira tentativa de upgrade, resolvi voltar o bkp. Mas vou tentar novamente hoje a noite e se o erro ocorrer no clamav, vou deixar quieto já que não uso.

    Quanto ao php.ini, vou manter o arquivo local mesmo então.

    Muito obrigado pela ajuda!

    E aproveitando mais sobre esse assunto de segurança e a sua boa vontade…

    Você sabe me dizer como instalar o let’s encrypt nesse servidor do seu tutorial configurado com debian e ispconfig? O certificado é instalado no servidor e funciona em todos os sites ou cada site deve ter um certificado? Tenho essa dúvida (bem de inciante) pq vi que cada site tem uma aba SSL lá no ispconfig e vi também que no blog do ispconfig diz que a versão 3.1.2 do painel suporta o let’s encrypt, mas não entendi muito bem como seria a instalação.

    P.S: tenho sites que já utilizam o SSL do cloudflare, mas vi num fórum do let’s encrypt que ainda assim seria legal configurar um certificado deles (let’s encrypt) para fazer a proteção entre os servidores do cloudflare e o meu, já que a proteção entre o navegador e o cloudflare já é feita pelo certificado do próprio cloudflare.

  • Quando der o erro novamente copie ele inteiro e mande aqui.

    Eu instalo o Lets Encrypt para todos os meus clientes. Aquele certificado permite emitir somente para cada domínio, não tem opção wildcard. Instalo o SSL sempre na mão pois a opção automática direto no painel deve funcionar bem para Apache mas como uso NginX prefiro emitir manualmente mesmo.

    Sim, é melhor instalar no servidor. O SSL aqui do Fator Binário é Lets Encrypt e coloco ele também para os acessos de ISPConfig, Roundcube e phpMyAdmin.

    *Como você é leitor antigo aqui no Fator e sempre colabora com comentários bem elaborados faz o seguinte, me adiciona no Skype e pluga um microfone que te passo isso e fazemos uma sessão de consultoria free na boa. Sábado é sempre o melhor dia para isso se você puder e quiser.

  • Uoww sensacional, quero sim! MUITO obrigado. Já enviei convite para os 2 Luis Fator Binário que encontrei lá no Skype… hehe

    A gente combina por por lá o melhor horário para você! =)

  • O nickname oficial do Fator Binário é “fatorbinario”

  • Felipe

    Você poderia intalar o ioncube pra mim? quanto você cobra pela instalação ?

  • Qual empresa de hosting está o VPS? Qual a versão do Linux? Instalou usando o tutorial aqui do site? Qual a versão do PHP? E se você instalou alguma gambiarra adicional ao PHP, por exemplo o Suhosin?

    Posso até te ajudar nisso mas preciso saber essas informações.

  • Felipe

    DigitalOcean – debian 8 64bit , nem sei de suhosin…nunca usei isso, VPS mais barato da digital ocean, php 5.5 eu acho , acho que nao tem gambiarra nao….só fiz do seu tutorial mesmo….

  • Legal. Mais tarde vou fazer uns testes e ver se tem bug. Te aviso…

  • Acertei o tutorial do IONCube com as observações para o Debian 8 X84 com PHP 5.6, veja lá as observações com as linhas DEBIAN8_X64: https://fatorbinario.com/comunidade/topico/como-instalar-o-ioncube-php-loader/

    Estava tudo certo é só baixar e usar os arquivos certos.

  • Acertei o tutorial do IONCube com as observações para o Debian 8 X84 com PHP 5.6, veja lá as observações com DEBIAN8_X64: https://fatorbinario.com/comunidade/topico/como-instalar-o-ioncube-php-loader/

  • Felipe

    Cara, tentei, aqui continua não funcionando…acho que tem algo que impeça o funcionamento do ioncube ?

  • Felipe

    http://trombaporn.com.br/test.php , veja ai continua desinstalado…

  • Tá amarrado com alguma coisa maligna. Ou a gente chama o Gandalf para exorcizar isso ou acertamos um horário para acessar o servidor e ver o que tá acontecendo.

  • Felipe

    Cara pode ser se tiver Skype me add felipegabrielsantana, se vc puder resolver esse problema espiritual pra mim…Vê o que vc cobra p fazer … Valeu tentei de tudo já …valeu

  • Acessei o servidor e o problema era que o seu /etc/init.d/php5-fpm estava sem conteúdo dentro do script, tava zerado. Como eu te falei, era bruxaria mesmo..

  • Agora foi. Acessei o servidor e o problema era que o seu /etc/init.d/php5-fpm estava sem conteúdo dentro do script, tava zerado. Como eu te falei, era bruxaria mesmo..

  • Felipe

    foi mesmo obrigado por resolver o problema, muito agradecido

  • Samuel Batista

    Oi Luis Bom dia!

    os scripts não estão funcionando mais pra mim
    olha o que da para os comandos de testes >

    [email protected]:~# /root/rkhunter-monitor
    -bash: /root/rkhunter-monitor: /bin/bash^M: bad interpreter: No such file or directory

    [email protected]:~# /root/mysql-monitor
    -bash: /root/mysql-monitor: /bin/bash^M: bad interpreter: No such file or directory

    [email protected]:~# /root/site-monitor
    -bash: /root/site-monitor: /bin/bash^M: bad interpreter: No such file or directory

  • Funcionava antes?
    Se sim é porque você recentemente deve ter feito algum upgrade ou exclui o link para o BASH seguindo algum outro tutorial suicida na internet.

    Qual tipo de manutenção no sistema você fez recentemente?

  • Samuel Batista

    Nao foi manutenção nao, foi durante a configuração seguindo o tutorial.

    Eu acredito que tenha feito algo errado então, agora difícil vai ser é achar onde errei.
    Tem alguma dica?

  • Ok. É que você disse que estava dando erro em todos e achei que já funcionava antes, mas pelo jeito você está configurando pela primeira vez, é isso?

    Então o problema é o editor que você está usando para escrever os scripts, eu sempre uso o Notepad++ com WinSCP e nunca tive problemas, e mesmo que você esteja usando eles verifique se a formatação está como “UTF-8 SEM BOM”.

    Isso ai com certeza é o CR/LF no final das linhas. E tenha certeza que o script começa do jeito que está no tutorial com aquele “#” apontando para o caminho do BASH. Não pode nem existir linha em branco no início.

    Se mesmo assim não conseguir apague eles e use o NANO.

  • Samuel Batista

    Vlw Luissssss o problema realmente era o editor sublime, o que me deixa intrigado é que antes funcionava com ele, mas agora que o notepad++ serviu direitinho e que sei que vc usa ele vou ficar com ele mesmo.
    Mais uma vez muito obrigado!

  • Sublime dá muita dor de cabeça. Os clientes que atendo e insistem com ele sempre reportam bizarrices.

  • Rafael Oliveira de Santana

    Ola Luis, como vai.
    Tava dando uma pesquisa e achei esse artigo aqui, que fala do Mod Security pro Nginx. https://www.vultr.com/docs/how-to-install-modsecurity-for-nginx-on-centos-7-debian-8-and-ubuntu-16-04
    O que acha a respeito? Compensa adicionar nessa configuração acima?

  • Se quiser tentar manda bala, mas veja lá se as melhores opções do módulo não está somente na versão paga, olha só:
    https://www.nginx.com/blog/modsecurity-waf-released/