Tutorial Debian 8 x64 com ISPConfig e NginX: Firewall

Um servidor sem Firewall é como aguardar por um desastre anunciado, você sabe que vai acontecer e, como administrador de sistemas, tem que tomar providências para minimizar os estragos.

Durante algumas semanas deixei o meu site num servidor que a gente chama “honey pot“. Esse tipo de servidor é usado para, propositalmente, receber ataques e fazer log de tudo direcionando-os para determinados arquivos do sistema. Com essa técnica consegue-se filtrar e catalogar os tipos mais comuns de ataques, e as análises extraídas servem de base para melhorar as defesas do sistema.

Neste artigo Vamos acionar o Firewall do ISPConfig (Bastille Firewall), reconfigurar o Fail2Ban melhorando a detecção, ajustar o JailKit, acertar o NginX para mitigar ataques DDoS e, opcionalmente, instalar o Logwatch e desativar o modo recursivo do BIND.

Configurando o Firewall do Sistema

* Acesse o terminal SSH como superusuário root para executar os comando de instalação e configuração.

1 Acionando o Firewall do ISPConfig

No artigo anterior deste tutorial mostrei como adicionar as portas para o modo passivo do FTP ao firewall do ISPConfig, se você pulou aquele passo ou não prestou atenção, proceda da seguinte maneira:

Acesse: ISPConfig → Sistema → Firewall

Clique no botão “Adicionar Registro de Firewall” e confirme a tela que abrirá (se já havia adicionado o Firewall simplesmente abra a configuração existente), em seguida clique na linha de configuração e na caixa de “Portas TCP abertas” adicione “40110:40210” (portas para o FTP passivo) desta maneira:

20,21,22,25,53,80,110,143,443,587,993,995,3306,8080,8081,10000,40110:40210

* Pode-se parar o firewall do ISPConfig pelo console a qualquer momento digitando: /etc/init.d/bastille-firewall stop (isso pode ser útil caso queira testar se algum serviço externo não está conseguindo acessar o servidor por causa de alguma restrição de porta)

2 Reconfigurando o Fail2Ban e melhorando a detecção de ataques

Fail2Ban é a ferramenta responsável por detectar ataques ao servidor e automaticamente aplicar regras de ban. Alguns serviços básicos já estão configurados, mas vamos adicionar outros para minimizar riscos.

* Antes de adicionar os filtros abaixo ao Postfix, verifique se você tem um nome de servidor FQDN configurado, isso é muito importante para o correto funcionamento. Para uma melhor explicação veja o passo “Antes de começar” neste link.

2a ⇒ Edite o arquivo /etc/postfix/main.cf e altere/adicione as linhas abaixo:

#Próximo à Linha 57: Substitua a instrução "smtpd_recipient_restrictions" por esta abaixo (note que é uma linha única. e note também que no script novo de instalação há suporte a greylisting de emails e que o repositório padrão configurado para checagens é o zen.spamhaus.org. O SpamHaus é conhecido por cometer "enganos" com IPs legítimos, caso decida usar o serviço deles não precisa alterar a linha 57):

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf, reject_unknown_recipient_domain, permit
 
#Próximo às linhas 66 e 67: Substitua as linhas com instruções "smtpd_sender_restrictions" e "smtpd_client_restrictions" pelo bloco de código abaixo:

#EDIT Out/2016: Ajuste das instruções para a nova versão do instalador do ISPConfig, mantido o bloco antigo somente para compatibilidade

smtpd_data_restrictions = reject_unauth_pipelining
smtpd_delay_reject = yes
smtpd_sender_restrictions = 
   permit_mynetworks,
   reject_non_fqdn_sender,
   reject_unknown_sender_domain,
   check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf,
   permit
smtpd_client_restrictions = 
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unknown_client_hostname,
   check_client_access mysql:/etc/postfix/mysql-virtual_client.cf,
   permit

#Para instalações a partir de Out/2016 use este bloco de código:
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_delay_reject = yes
smtpd_sender_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_non_fqdn_sender,
   reject_unknown_sender_domain,
   check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf,
   permit
smtpd_client_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unknown_client_hostname,
   check_client_access mysql:/etc/postfix/mysql-virtual_client.cf,
   permit

OPCIONAL mas altamente RECOMENDÁVEL: Ainda no arquivo main.cf pode-se adicionar uma linha para garantir que somente o root e usuários de sistema consigam enviar emails através de scripts no servidor. Isso é muito útil para revendas de sites que não conseguem controlar os scripts dos programadores, ou ainda em casos quando hackers injetam um script PHP no site que dispara emails de SPAM. Adicionando esta linha somente o root e contas autenticadas, que tenham caixa de email, poderão enviar.

authorized_submit_users = !www, root, static:all

2b ⇒ Edite o arquivo /etc/postfix/header_checks e adicione a linha abaixo:

/^X-Spam-Level: \*{15,}.*/ DISCARD

2c ⇒ Edite o arquivo /etc/fail2ban/jail.local apagando todo o conteúdo e substituindo por este abaixo:

[DEFAULT]

# Adicione IPs internos e o DNS do Google na lista de redes confiaveis
ignoreip = 127.0.0.0/8 10.0.0.0/8 8.8.8.8 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22 104.16.0.0/12 108.162.192.0/18 131.0.72.0/22 141.101.64.0/18 162.158.0.0/15 172.64.0.0/13 173.245.48.0/20 188.114.96.0/20 190.93.240.0/20 197.234.240.0/22 198.41.128.0/17 199.27.128.0/21
# Se você utiliza o ManageWP terá que adicionar os IPs da rede deles na WhiteList também (após o último IP na lista acima acrescente um espaço em branco e cole estes endereços):
# 192.155.230.147 174.37.199.34 89.216.23.220 77.105.2.42 77.105.2.43 77.105.2.44 77.105.2.45 77.105.2.46 77.105.2.47
# E para a CloudFlare adicione os seguintes IPs
# 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22 104.16.0.0/12 108.162.192.0/18 131.0.72.0/22 141.101.64.0/18 162.158.0.0/15 172.64.0.0/13 173.245.48.0/20 188.114.96.0/20 190.93.240.0/20 197.234.240.0/22 198.41.128.0/17 199.27.128.0/21

# Antes de adicionar jails configure valores padrão de ação e ban (pode-se alterar cada jail individualmente)
# Os valores abaixo sao exemplos e estao em segundos: bantime (600 segundos); findtime (300 segundos); maxretry (4 tentativas):
bantime = 600
findtime = 300
maxretry = 4

#Altere o modo de detecção para o Debian reconhecer as alterações de arquivo corretamente:
backend = polling

#
# JAILS
#
[ssh]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log

[ssh-ddos]
enabled = true
port = ssh
filter = sshd-ddos
logpath = /var/log/auth.log
maxretry = 6

[dropbear]
enabled = true
port = ssh
filter = dropbear
logpath = /var/log/auth.log
maxretry = 6

# Monitora as tentativas de autenticação para diretórios protegidos no NginX
[nginx-http-auth]
enabled = true
filter = nginx-http-auth
port = http,https
logpath = /var/log/nginx/error.log

[pure-ftpd]
enabled = true
port = ftp,ftp-data,ftps,ftps-data
filter = pure-ftpd
logpath = /var/log/syslog
maxretry = 6

[pureftpd]
enabled = true
port = ftp
filter = pureftpd
logpath = /var/log/syslog
maxretry = 6

[postfix]
enabled = true
port = smtp,ssmtp,submission
filter = postfix
logpath = /var/log/mail.log
bantime = 1800
findtime = 600
maxretry = 3

[sasl]
enabled = true
port = smtp,ssmtp,submission,imap2,imap3,imaps,pop3,pop3s
filter = postfix-sasl
logpath = /var/log/mail.log

[dovecot]
enabled = true
port = smtp,ssmtp,submission,imap2,imap3,imaps,pop3,pop3s
filter = dovecot
logpath = /var/log/mail.log

#Bloqueando ataques DDoS no BIND9, servidor DNS. Note que mudamos o arquivo padrao de log e tambem trocamos o 
#action para hostsdeny, isso e necessario pois ataques ao DNS devem ser barrados logo na entrada do servidor
[named-refused-udp]
enabled = true
port = domain,953
protocol = udp
filter = named-refused
#logpath = /var/log/named/security.log
logpath = /var/log/daemon.log
action = hostsdeny
bantime = 1800
findtime = 300
maxretry = 10

[named-refused-tcp]
enabled = true
port = domain,953
protocol = tcp
filter = named-refused
#logpath = /var/log/named/security.log
logpath = /var/log/daemon.log
action = hostsdeny
bantime = 1800
findtime = 300
maxretry = 10

2d ⇒ Edite o arquivo /etc/fail2ban/filter.d/named-refused.conf e na linha 40, logo acima de “# DEV Notes:” digite:

ignoreregex = 

# Note que é um parâmetro sem valor, somente para não dar erro na inicialização do Fail2Ban. O mais comum é "WARNING 'ignoreregex' not defined in 'Definition'. Using default one"

2e ⇒ Edite o arquivo /etc/fail2ban/filter.d/postfix.conf e adicione as linhas em negrito abaixo (Isso é MUITO IMPORTANTE pois há um bug de detecção no filtro original, para identar as linhas use espaços normais):

failregex = ^%(__prefix_line)sNOQUEUE: reject: RCPT from \S+\[<HOST>\]: 554 5\.7\.1 .*$
^%(__prefix_line)sNOQUEUE: reject: RCPT from \S+\[<HOST>\]: 450 4\.7\.1 : Helo command rejected: Host not found; from=<> to=<> proto=ESMTP helo= *$
^%(__prefix_line)sNOQUEUE: reject: VRFY from \S+\[<HOST>\]: 550 5\.1\.1 .*$
^%(__prefix_line)simproper command pipelining after \S+ from [^[]*\[<HOST>\]:?$
^%(__prefix_line)sNOQUEUE: reject: RCPT from \S+\[<HOST>\]: 454 4\.7\.1 :*$
^%(__prefix_line)sNOQUEUE: reject: RCPT from \S+\[<HOST>\]: 454 4\.7\.1 .*$
reject: RCPT from (.*)\[<HOST>\]: 550 5.1.1
reject: RCPT from (.*)\[<HOST>\]: 450 4.7.1
reject: RCPT from (.*)\[<HOST>\]: 554 5.7.1
reject: RCPT from unknown\[<HOST>\]: 454 4.7.1
warning: Illegal address syntax from unknown\[<HOST>\]
warning: non-SMTP command from unknown\[<HOST>\]:

2f ⇒ Reinicie o postfix e o fail2ban

root# /etc/init.d/fail2ban restart

root# /etc/init.d/postfix restart

• Caso queira fazer experiências com jails no Fail2Ban use o comando abaixo, após reiniciar o serviço ele mostrará erros e avisos:

root# /etc/init.d/fail2ban status
3 Ajuste do JailKit

O JailKit permite configurar usuários de site em chroot, ou seja, em seções enjauladas. Caso um hacker consiga entrar no servidor através de algum exploit ele não terá acesso aos arquivos externos ao site.

Esse tipo de usuário é criado no ISPConfig em “Sites/Usuários de Shell”, mas se você somente acessa o servidor pelo usuário root ou outro usuário limitado de sistema, e para subir os sites cria usuários FTP, então não precisa preocupar-se muito com isso.

• Edite o arquivo /usr/local/ispconfig/server/scripts/create_jailkit_chroot.sh e adicione esta linha ao final (note que estamos modificando um script do próprio ISPConfig, caso faça um upgrade do painel futuramente verifique este arquivo novamente):

chmod g-w $CHROOT_HOMEDIR/bin

* Isso serve para que os usuários em chroot consigam fazer login SSH no servidor. Há um “bug” na criação do diretório bin dos sites quando adicionados pelo ISPConfig, se não consertarmos este bug os usuários em jail não conseguem fazer login (a seção SSH simplesmente desaparece após conectar)

* * Caso já tenha adicionado um usuário SSH de site antes de fazer a alteração acima então altere a permissão do subdiretório /bin dentro do espaço de site adicionado pelo ISPConfig para 0755. Por exemplo, digamos que o seu site seja meusite.com.br, então o caminho desse diretório /bin será: /var/www/meusite.com.br/bin

* * * Os erros encontrados no arquivo de log são parecidos com estes:

Dec 8 13:52:36 debian8 jk_chrootsh[29365]: path /var/www/clients/client0/web1/bin/ is group writable

Dec 8 13:52:36 debian8 jk_chrootsh[29365]: abort, /var/www/clients/client0/web1 is not a safe jail, check ownership and permissions

• Edite o arquivo /etc/jailkit/jk_init.ini e adicione ao final da linha 71 em [basicshell] (dependendo da distribuição Linux que você instalou essa linha poderá ser a 74 em [paths]). No parâmetro “executables=” adicione, ao final da linha, os comandos zip e unzip (note as vírgulas), assim os usuários em Jail de site poderão usar os comandos:

, /usr/bin/zip, /usr/bin/unzip

E por último reinicie o Jailkit:

> /etc/init.d/jailkit restart
4 Mitigando ataques DDoS ao NginX

Para a segurança e estabilidade do servidor este passo é de grande importância. Faremos o bloqueio da página padrão do NginX exibida pelo número IP e a limitação de conexões ao servidor por IP. Faremos as alterações primeiro porque acessar o servidor na porta 80 pelo número IP não ajuda em nada, só serve para ver se o NginX está funcionando, mas se ele não estivesse online nem mesmo o ISPConfig abriria.

E também porque deixar o acesso livre à página default pelo número IP é uma grande brecha para ataques DDoS. Mesmo se você configurar os domínios pela CloudFlare alguém pode descobrir o número IP do servidor e ordenar um ataque de negação de serviço ao VPS pelo IP. Por isso mostrarei abaixo como usar uma instrução especial do NginX para “interromper” a conexão para acessos diretos.

E por último o limite de acessos por IP mitiga em muito ataques ao servidor, neste caso são conexões aos sites e não ao IP do servidor.

Note que os demais serviços e páginas continuarão funcionando normalmente após as alterações.

  • Seguindo o nosso tutorial você deve ter notado que digitando o IP do servidor abre uma página padrão do Apache, isso acontece porque o script instalador não alterou o caminho da página padrão. Se quiser simplesmente modificá-la edite o arquivo /etc/nginx/sites-enabled/default e na linha 30 altere para “root /usr/share/nginx/html;“, e em seguida reinicie o nginx. Ou se preferir, siga os passos abaixo para desativá-la completamente.

4a ⇒ OPCIONAL: Altere o arquivo /etc/nginx/sites-enabled/default:

#Comente as linhas 30, 33 e 40 colocando um sinal de "#" no início, e adicione a linha 36 retornando a instrução 444

#root /usr/share/nginx/html;
 
# Add index.php to the list if you are using PHP
#index index.html index.htm index.nginx-debian.html;

server_name _;
return 444;
location / {
    # First attempt to serve request as file, then
    # as directory, then fall back to displaying a 404.
    #try_files $uri $uri/ =404;
}

4b ⇒ Altere o arquivo /etc/nginx/nginx.conf:

#Adicionando estas linhas no arquivo de configuração do NginX limitará o número de conexões ativas por número IP aos sites mitigando ataques DDoS (note que mesmo adicionando as linhas ainda será necessário adicionar as diretivas por site conforme passo 4d)

#Logo no início do bloco "http {" do arquivo nginx.conf adicione as linhas em vermelho conforme mostrado abaixo

http {

   ##
   # Basic Settings
   ##

#Habilite a linha 22 se quiser "ocultar" a versão do NginX, algumas ferramentas que analisam vulnerabilidades mostram uma mensagem como esta: "Server signature: HTTP response contains the version of the web server exposing its vulnerabilities."  

server_tokens off;

limit_conn_zone $binary_remote_addr zone=conn_limit_per_ip:10m;
limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=5r/s;

#Se você usa a CloudFlare o serviço deles faz com que os IPs nos logs de acesso aparecam somente os deles, adicione as seguintes linhas para mostrar o IP real de acesso:

set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 104.16.0.0/12;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 199.27.128.0/21;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
 
sendfile on;
tcp_nopush on;

4c ⇒ Reinicie o NginX:

root# /etc/init.d/nginx restart

Caso tenha optado pelo passo 4a tente acessar a página novamente pelo número IP, note que exibirá uma mensagem de que “Nenhum dado foi recebido” (ERR_EMPTY_RESPONSE). Isso acontece porque modificamos a diretiva return para Status 444 que simplesmente interrompe e fecha a conexão com o navegador cliente impossibilitando ataques de negação de serviço.

4d ⇒ Após reiniciar o NginX adicione estas diretivas na caixa de diretivas NginX de cada site no ISPConfig (caso tente adicionar as diretivas sem editar o arquivo nginx.conf e reiniciar o serviço os sites ficarão offline):

ATENÇÃO: Em alguns sites leitores relatam problemas com CSS e imagens falham ao carregar. Em sites WordPress com Revolution Slider causará erros de CSS deixando de exibir alguns componentes como por exemplo a logo do site. O erro mais comum que aparece nos logs é este: “You have some jquery.js library include that comes after the revolution files js include“. A documentação para as regras abaixo é um pouco confusa mas consegui contornar o problema, veja o edit:

EDIT (março/2016): Após vários testes e com a ajuda do leitor Dan Rezende isolei o problema e modifiquei as regras abaixo, em especial a linha 4 (limit_req zone). Foi retirado o parâmetro nodelay e aumentado o burst de 10 para 20. Desta maneira você conseguirá manter as regras anti-DDoS sem afetar o CSS do site.

#Diretivas NginX por site para mitigar ataques DDoS
limit_conn conn_limit_per_ip 6;
limit_conn_log_level warn;
limit_conn_status 444;

#Caso o CSS do site nao carregue corretamente aumente o burst na proxima linha gradativamente ate solucionar
limit_req zone=req_limit_per_ip burst=20;
limit_req_log_level warn;
limit_req_status 444;
5 OPCIONAL: Instalação do Logwatch

Logwatch é uma ferramenta que verifica os arquivos de log diariamente e cria um relatório das principais atividades como ataques e acessos, enviando o relatório por email se configurado. Uma melhor explicação pode ser encontrada neste link.

5a ⇒ Baixe e instale o Logwatch:

root# apt-get -y install logwatch

5b ⇒ Edite o arquivo /usr/share/logwatch/default.conf/logwatch.conf:

#Linha 35 altere para que o relatorio seja enviado por email
Output = mail

#Linha 37 altere o formato para HTML facilitando a leitura
Format = html

#Linha 44 configure para qual email o relatorio será enviado (pode ser uma conta interna ou externa)
MailTo = [email protected]

#Linha 77 altere o nivel de detalhes para Medio que é suficiente
Detail = Med

5c ⇒ Faça um teste. Não é necessário reiniciar nenhum serviço, digite o comando abaixo (um email será entregue com o relatório do dia anterior e os próximos relatórios serão enviados automaticamente pois uma tarefa foi adicionada ao Cron durante a instalação):

root# logwatch
6 Fix para erros do named nos arquivos de log

Este passo é opcional e somente se você não pretende criar zonas DNS diretamente no servidor, como eu costumo ensinar nos tutoriais.

Durante a instalação e testes me deparei com um flood de mensagens de erro infinitas no arquivo /var/log/daemon.log, que são gravadas pelo serviço named (BIND9) e parecidas com esta:

Dec 18 17:32:54 debian8 named[2143]: client 66.1.64.135#11696 (dominio_qualquer.com): query (cache) 'dominio_qualquer.com/A/IN' denied

Para sanar o flood nos logs é necessário desativar o modo recursivo do BIND.

Se quiser desativá-lo edite o arquivo /etc/bind/named.conf.options e adicione estas linhas antes de fechar o bloco “options” (*adicione somente as 3 linhas em negrito):

    auth-nxdomain no; # conform to RFC1035
    listen-on-v6 { any; };
    recursion no;
    additional-from-auth no;
    additional-from-cache no;
};

• Reinicie o BIND9:

root# /etc/init.d/bind9 restart

• Verifique também que nos arquivos de log algumas datas estão erradas. Isso acontece porque alteramos o timezone anteriormente. Reinicie o servidor para acertar isso:

root# shutdown -r now

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

  • Marcio Sposito

    Caro Luiz, no item 4 – Mitigando ataques DDoS ao NginX a pagina de boas vindas do nginxs abre com o endereçamento de IP mas não com o dominio apontando para este mesmo IP atravé de redirecionamento. É normal isto?

  • Com o ISPConfig configurado, somente acessa sites através de vHosts, ou seja você tem que criar o espaço de site no painel e criar a tabela DNS apontando para o IP do VPS. Ainda é possivel acessar a página de boas vindas via IP mas somente ela, no passo 4 eu mostro como desativar isso pra evitar problemas com ataques.

  • Rafael

    Boa Noite Luis! Não sei se lembra de mim, mas comentei um erro lá no tutorial 4, simplesmente eu tinha feito a instalação errada! Instalado Apache entre outras coisas erradas. Já foi corrigido!

    Bom, a dúvida agora é a seguinte, fiz todos os processos para desativar a página de Boas Vindas do NginX, mas ela continua! Se eu acessar com http:// IP ele nao acessa nada. Se colocar https:// IP ele acessa a página normalmente.

    Sabe me dizer se foi erro nos procedimentos ou existe alguma relação o https?

  • A tabela DNS está na CLoudFlare? Se sim é porque a CloudFlare cede um certificado gratuito para os sites.

    Mas não se preocupe com isso pois dificilmente alguém vai atacar pela porta https.

  • Rafael

    Esta é a minha dúvida, pois nem cheguei ainda na configuração da Tabela DNS, e também instalei o logwatch e ele não envia o email… Mas olhando o log, ele esta tentando conectar com o gmail (no meu caso), mas não consegue a conexão.

  • No caso do email você tem que liberar a porta com a DigitalOcean pois ela vem bloqueada por padrão.

  • Rafael

    Ok, irei requisitar a liberação pra eles. E no caso, no log o logwatch esta tentando enviar o email… Tem como parar ele? Eu desativei o cron já, mas não sei como fazer ele parar de tentar enviar o email.

  • Sim, na linha 35 onde alterou para output = mail substitua novamente para output = file. Ae vai parar de enviar email..

  • Weslley Almeida

    Boa tarde, Luis.

    Estou com um probleminha no firewall.

    Adicionei todas as portas no ISPConfig, mas continua dando Conexão Recusada la no Registro.br

    TCP: 20,21,22,25,53,80,110,143,443,587,993,995,3306,8080,8081,10000,40110:40210
    UDP: 53,3306

    # /etc/init.d/bastille-firewall status

    Chain INPUT (policy DROP 0 packets, 0 bytes)
    pkts bytes target prot opt in out source destination
    0 0 fail2ban-pureftpd tcp — * * 0.0.0.0/0 0.0.0.0/0 multiport dports 21
    16 816 fail2ban-dovecot tcp — * * 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,587,143,220,993,110,995
    16 816 fail2ban-sasl tcp — * * 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,587,143,220,993,110,995
    16 816 fail2ban-postfix tcp — * * 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,587
    0 0 fail2ban-pure-ftpd tcp — * * 0.0.0.0/0 0.0.0.0/0 multiport dports 21,20,990,989
    0 0 fail2ban-nginx-http-auth tcp — * * 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443
    295 19614 fail2ban-ssh-ddos tcp — * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22
    295 19614 fail2ban-dropbear tcp — * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22
    295 19614 fail2ban-ssh tcp — * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22
    0 0 DROP tcp — !lo * 0.0.0.0/0 127.0.0.0/8
    3603 345K ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
    107 6420 ACCEPT all — lo * 0.0.0.0/0 0.0.0.0/0
    0 0 DROP all — * * 224.0.0.0/4 0.0.0.0/0
    0 0 PUB_IN all — eth+ * 0.0.0.0/0 0.0.0.0/0
    0 0 PUB_IN all — ppp+ * 0.0.0.0/0 0.0.0.0/0
    0 0 PUB_IN all — slip+ * 0.0.0.0/0 0.0.0.0/0
    683 45783 PUB_IN all — venet+ * 0.0.0.0/0 0.0.0.0/0
    0 0 PUB_IN all — bond+ * 0.0.0.0/0 0.0.0.0/0
    0 0 DROP all — * * 0.0.0.0/0 0.0.0.0/0

    Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts bytes target prot opt in out source destination
    0 0 ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
    0 0 DROP all — * * 0.0.0.0/0 0.0.0.0/0

    Chain OUTPUT (policy ACCEPT 2464 packets, 214K bytes)
    pkts bytes target prot opt in out source destination
    0 0 PUB_OUT all — * eth+ 0.0.0.0/0 0.0.0.0/0
    0 0 PUB_OUT all — * ppp+ 0.0.0.0/0 0.0.0.0/0
    0 0 PUB_OUT all — * slip+ 0.0.0.0/0 0.0.0.0/0
    1181 334K PUB_OUT all — * venet+ 0.0.0.0/0 0.0.0.0/0
    0 0 PUB_OUT all — * bond+ 0.0.0.0/0 0.0.0.0/0

    Chain INT_IN (0 references)
    pkts bytes target prot opt in out source destination
    0 0 ACCEPT icmp — * * 0.0.0.0/0 0.0.0.0/0
    0 0 DROP all — * * 0.0.0.0/0 0.0.0.0/0

    Chain INT_OUT (0 references)
    pkts bytes target prot opt in out source destination
    0 0 ACCEPT icmp — * * 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0

    Chain PAROLE (17 references)
    pkts bytes target prot opt in out source destination
    34 1784 ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0

    Chain PUB_IN (5 references)
    pkts bytes target prot opt in out source destination
    0 0 ACCEPT icmp — * * 0.0.0.0/0 0.0.0.0/0 icmptype 3
    4 240 ACCEPT icmp — * * 0.0.0.0/0 0.0.0.0/0 icmptype 0
    0 0 ACCEPT icmp — * * 0.0.0.0/0 0.0.0.0/0 icmptype 11
    1 60 ACCEPT icmp — * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:20
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
    2 120 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:110
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:143
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:587
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:993
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:995
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306
    32 1664 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8081
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:10000
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:40110:40210
    530 38230 ACCEPT udp — * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
    0 0 ACCEPT udp — * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3306
    0 0 DROP icmp — * * 0.0.0.0/0 0.0.0.0/0
    114 5469 DROP all — * * 0.0.0.0/0 0.0.0.0/0

    Chain PUB_OUT (5 references)
    pkts bytes target prot opt in out source destination
    1179 331K ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0

    Chain fail2ban-dovecot (1 references)
    pkts bytes target prot opt in out source destination
    16 816 RETURN all — * * 0.0.0.0/0 0.0.0.0/0

    Chain fail2ban-dropbear (1 references)
    pkts bytes target prot opt in out source destination
    295 19614 RETURN all — * * 0.0.0.0/0 0.0.0.0/0

    Chain fail2ban-nginx-http-auth (1 references)
    pkts bytes target prot opt in out source destination
    0 0 RETURN all — * * 0.0.0.0/0 0.0.0.0/0

    Chain fail2ban-postfix (1 references)
    pkts bytes target prot opt in out source destination
    16 816 RETURN all — * * 0.0.0.0/0 0.0.0.0/0

    Chain fail2ban-pure-ftpd (1 references)
    pkts bytes target prot opt in out source destination
    0 0 RETURN all — * * 0.0.0.0/0 0.0.0.0/0

    Chain fail2ban-pureftpd (1 references)
    pkts bytes target prot opt in out source destination
    0 0 RETURN all — * * 0.0.0.0/0 0.0.0.0/0

    Chain fail2ban-sasl (1 references)
    pkts bytes target prot opt in out source destination
    16 816 RETURN all — * * 0.0.0.0/0 0.0.0.0/0

    Chain fail2ban-ssh (1 references)
    pkts bytes target prot opt in out source destination
    295 19614 RETURN all — * * 0.0.0.0/0 0.0.0.0/0

    Chain fail2ban-ssh-ddos (1 references)
    pkts bytes target prot opt in out source destination
    295 19614 RETURN all — * * 0.0.0.0/0 0.0.0.0/0

    —————————————————————————————————————————

    Pode me ajudar com esse problema.

  • Weslley Almeida

    Boa tarde, Luis.

    Estou com um probleminha no firewall.

    Adicionei todas as portas no ISPConfig, mas continua dando Conexão Recusada la no Registro.br

    TCP: 20,21,22,25,53,80,110,143,443,587,993,995,3306,8080,8081,10000,40110:40210
    UDP: 53,3306

    # /etc/init.d/bastille-firewall status

    Chain PUB_IN (5 references)
    pkts bytes target prot opt in out source destination
    0 0 ACCEPT icmp — * * 0.0.0.0/0 0.0.0.0/0 icmptype 3
    4 240 ACCEPT icmp — * * 0.0.0.0/0 0.0.0.0/0 icmptype 0
    0 0 ACCEPT icmp — * * 0.0.0.0/0 0.0.0.0/0 icmptype 11
    1 60 ACCEPT icmp — * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:20
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
    2 120 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:110
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:143
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:587
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:993
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:995
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306
    32 1664 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8081
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:10000
    0 0 PAROLE tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:40110:40210
    530 38230 ACCEPT udp — * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
    0 0 ACCEPT udp — * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3306
    0 0 DROP icmp — * * 0.0.0.0/0 0.0.0.0/0
    114 5469 DROP all — * * 0.0.0.0/0 0.0.0.0/0

    Quando tento reinicia-lo:

    # /etc/init.d/bastille-firewall restart

    modprobe: ERROR: ../libkmod/libkmod.c:508 kmod_lookup_alias_from_builtin_file() could not open builtin file ‘/lib/modules/2.6.32-042stab112.15/modules.builtin.bin’
    modprobe: FATAL: Module ip_tables not found.
    modprobe: ERROR: ../libkmod/libkmod.c:508 kmod_lookup_alias_from_builtin_file() could not open builtin file ‘/lib/modules/2.6.32-042stab112.15/modules.builtin.bin’
    modprobe: FATAL: Module ip_conntrack not found.
    modprobe: ERROR: ../libkmod/libkmod.c:508 kmod_lookup_alias_from_builtin_file() could not open builtin file ‘/lib/modules/2.6.32-042stab112.15/modules.builtin.bin’
    modprobe: FATAL: Module ip_conntrack_ftp not found.
    modprobe: ERROR: ../libkmod/libkmod.c:508 kmod_lookup_alias_from_builtin_file() could not open builtin file ‘/lib/modules/2.6.32-042stab112.15/modules.builtin.bin’
    modprobe: FATAL: Module ipt_LOG not found.
    Setting up IP spoofing protection… done.
    Allowing traffic from trusted interfaces… done.
    Setting up chains for public/internal interface traffic… done.
    Setting up general rules… done.
    Setting up outbound rules… done.

    —————————————

    Pode me ajudar com esse problema.

  • Qual porta recusada você se refere?

    O Registro BR normalmente é usado somente para registrar domínios..

  • Weslley Almeida

    Porta – 53

    Descobri que o problema esta no resolv.conf.

    No painel do ISPConfig ele atribui 8.8.8.8,8.8.4.4 para o DNS, mas no resolv.conf tem apenas o 8.8.8.8.

    Altero os nameservers para:

    nameserver 8.8.8.8
    nameserver 8.8.4.4
    nameserver 2001:4860:4860::8888
    nameserver 2001:4860:4860::8844

    Passa um tempo e o Registro reconhece autoridade, mas passa algumas horas e da recusado de novo.

    Acesso o resolv.conf e volta para: nameserver 8.8.8.8

    Os sites estão ficando offline toda hora.

  • Você escreveu a tabela DNS onde?

    Melhor coisa que existe é escrever ela na CloudFlare e apontar os NS pra lá.
    Além de fazer proxy-cache ainda tem proteção e anti-DDoS.

    Até hoje ajudei a configurar centenas de sites e nunca precisei lidar nesses NS do ISPConfig..

  • Weslley Almeida

    No próprio ISPConfig.

    Tenho alguns sites de clientes para desenvolver e hospedar, mas nem meu próprio domínio valida autoridade no Registro.br.

    Como faço para manter os nameserver no resolv.conf?

    Qualquer alteração volta para o padrão.

    Vou deixar o firewall desativado até descobrir porque esta acontecendo isso.

    Estou começando a me chatear, funciona uma hora e para. Depois volta a funcionar do nada.

  • Então Wesley, eu não sei exatamente como você está tentando fazer a tabela, mas escreva ela no CloudFlare que é o mais profissional que pode ficar.

    – Crei o site no ISPConfig
    – Escreva a tabela na CloudFlare
    – Aponte os NS para aqueles da sua conta na CloudFlare
    – Depois do site desenvolvido e o NS propagado você terá proxy cache e proteção adicional grátis. Os sites ficam muito rápidos.

    * Manter a tabela DNS no próprio servidor pode te dar uma tremenda dor de cabeça desnecessária. Imagine a seguinte situação: Um determinado dia o seu servidor pode parar ou por algum motivo sua conta na empresa de hosting pode deixar de existir. Se você escrever a tabela DNS no próprio servidor você terá que migrar os registros para outro lugar (isso não é como simplesmente alterar os IPs), e o tempo que irá demorar para propagar os novos registros pode ser de até 48 horas. Escreva a tabela na CloudFlare que você evita tudo isso.

  • Weslley Almeida

    Luis, primeiramente quero agradecer e pedir desculpas por ficar amolando.
    Tenho que criar a tabela de todos os sites que colocar no ISPConfig na CloudFlare?
    A tabela do Droplet eu destruo ou pode deixar?
    Quero configurar os outros sites com meus ns. ex: colocar la no registro.br o ns1 e ns2.meudominio,com. Consigo fazer isso?

    Mais uma vez, muito obrigado pela atenção.

  • Ok, agora entendi.

    Então é melhor escrever a tabela direto no seu hosting, por exemplo Digital Ocean. O que você quer são NameServers customizados, veja como fazer neste link: https://fatorbinario.com/comunidade/topico/nameservers-customizados-o-que-sao-e-como-fazer-para-configura-los/

  • Weslley Almeida

    Deixei tudo na CloudFlare mesmo.
    Estou com outra dúvida, mas vou postar na página da Tabela DNS, porque pode ajudar outros.
    Muito Obrigado!

  • Eric

    Na parte 4 notei que n~tenho essa pasta Nginxs, Luis. Será que faltou a instalação dessa parte? Ta tudo funcionando normalmente…

  • Durante a instalação você tem que selecionar NginX quando aparece a opção NginX/Apache. Para selecionar usa as setas do teclado e marca com barra de espaços.

    Mas se você já fez isso pode ser que tenha que dar um refresh no WinSCP para a pasta aparecer.

  • Alex

    Fiz a configuração do Jailkit, mas quando acesso com usuário ssh, não consigo executar comandos como composer e git, dá comando não encontrado, só consigo executá-los com o usuário root (o que não é recomendado).

    O que posso fazer para que os outros usuários sejam capazes de executar os comandos?

  • Veja o meu mini tutorial para adicionar o zip, use o mesmo método:
    https://fatorbinario.com/comunidade/topico/adicionando-os-comandos-zip-e-unzip-para-os-usuarios-em-jail-no-ispconfig/

    E não esqueça de fazer aquela última parte para usuários já adicionados.

  • Jean A. Silva

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

    Esta ocorrendo falha ao tentar restart no nginx.
    Poderia me ajudar?.

  • > /etc/init.d/apache2 stop

    > /etc/init.d/nginx restart

    Se continuar dando erro você fez alguma coisa errada no arquivo /etc/nginx/nginx.conf

  • Jean A. Silva

    Prezado Luis,

    Isso é normal ao tentar restartar o Jalkit?.

    Stopping jailkit: jk_socketd/usr/sbin/jk_socketd: no process found
    done.
    Starting jailkit: jk_socketdversion 2.19, no sockets specified in configfile /etc/jailkit/jk_socketd.ini or on commandline, nothing to do, exiting…
    done.

  • É sim.
    Ali só exibe umas mensagens de “feito” e tals..

  • JosehRoberto

    Luis, então, como sugestão, seria interessante lá no tutorial no item “3 Ajuste do JailKit”, informar que esta mensagem de erro é normal.

  • Nilton Neto

    Esse erro do Logwatch aparaceu depois de instalar e editar.
    Após dar o comando (logwatch) ele apresenta o erro abaixo:

    sendmail: fatal: User root(0) is not allowed to submit mail

    No outro servidor que tenho ele envia e-mail normalmente e nunca apresentou esse erro.

    Tem ideia de onde eu estou errando Luis?

  • Sim. No final do passo 2A eu mudei a regra para:
    authorized_submit_users = !www, !root

    Tire a exclamação da frente de “root”. Vou deixar o tutorial como antes para não confundir..

  • Nilton Neto

    Obrigado Luís!

  • Edson Correa

    Olá Luis, vi que você configurou várias diretivas no Fail2ban inclusive o ssh para ban com 4 tentativas. Porém, tenho recebido via Logwatch todo santo dia ips tentando acesso root no sshd por 5000 ou 9000 vezes! Isso com certeza são robôs. Tem como bloquear esses ips automaticamente? Acredito que esse número elevado de tentativas cause algum impacto em performance no servidor, ou não?

  • O Fail2Ban bloqueia automaticamente. Porém no tutorial está com ban para 10 minutos e ae o bot tenta novamente.

    Pode elevar o ban SSH para 1 hora ou até mais se quiser, é só copiar aquela linha de bantime e colar ela no final do bloco SSH do jail.local. Mas tenha consciência de que se você mesmo errar a senha poderá ficar sem acesso pelo tempo configurado. Caso aconteça isso poderá simplesmente reiniciar seu modem para pegar um IP novo ou acessar o servidor via console no painel da conta da Digital e reiniciar o fail2ban por lá.

  • Edson Correa

    Bacana. Vou tentar lá. Agora o que me deixou cismado é que no relatório de hoje por exemplo, um IP fez 9411 tentativas! Se está configurado o ban para 10 minutos, pela lógica não teria como ele fazer mais de 144 tentativas em um dia. Ou o ban não está funcionando corretamente ou o logwatch está pegando um período de tempo maior do que 24h.

  • O arquivo com logs do fail2ban é o /var/log/fail2ban.log. E tem que ver também se o logwatch não está contando o total de tentativas.. o fail2ban bane mas passa para o iptables tratar o problema o que não impede a pessoa de continuar disparando, ela somente não terá acesso ao serviço mas é o iptables que acerta isso.

  • Jean A. Silva

    Ola Luis, boa noite!

    Esta mensagem é normal?

    Stopping jailkit: jk_socketd/usr/sbin/jk_socketd: no process found
    done.

    Starting jailkit: jk_socketdversion 2.19, no sockets specified in configfile /etc/jailkit/jk_socketd.i ni or on commandline, nothing to do, exiting…
    done.

  • É normal sim. Ela é esquisita desse jeito porque o certo seria rodar para cada usuário e como você ainda não tem usuários em jail quando instala o servidor diz ali que não encontrou nenhum processo e avisa que não há nada a fazer.

  • Alex

    Olá Luis.

    Estou usando a configuração do postfix do tutorial.
    Na última semana recebi esta notificação da DO:
    your Server/Customer with the IP: *#.#.#.#* (mail.domain.com) has attacked one of our servers/partners.

    The attackers used the method/service: *mail*
    verifiquei o log de email e o postfix está enviando spam para vários emails desconhecidos, gerando gigantescos arquivos de logs.

    Por ora, interrompi o serviço do postfix.

    Tem alguma ideia de como corrigir o problema?

  • Tenho sim.
    Se você seguir todo o tutorial atentamente incluindo o firewall e colocando senhas dificeis para as contas de email fica tudo 100%.

    Não adianta seguir somente a configuração de email do tutorial, tem que seguir o tutorial de Debian 8 inteiro que esses ataques são bloqueados. Já configurei mais de 1.000 servidores e hoje atendo mais de 100 servidores com mensalidade e não tem esse problema, mas sei do que você está falando..

  • Alex

    Certo.

    Posso ter deixado passar alguma configuração, esse servidor em questão já estava a mais de um ano funcionando sem problemas.

    Se eu verificar as configurações e fazer as correções o ataque é interrompido, né? sem precisar fazer nova instalação?

  • A Digital é bem chata pra isso. Se você não der jeito na situação eles vão bloquear sua conta.

    Mas sim, tem que fazer as regras de firewall, fail2ban e regras Postfix.

  • Victor Dantas

    Olá Luis. Eu instalei um site joomla e um moodle utilizando seu tutorial. Porém o site moodle não abre (Eu não sei a diretivas moodle para nginx, as que encontrei na internet não funcionam). O site joomla funciona tudo bem, porém, o smartslider3 (extensão) fica travado e alguns efeitos do css. Aumentei o valor de burst até chegar a 5000 e nada! Grande abraço e parabéns pelo brilhante tutorial!

  • Desative as linhas de Anti DDoS nas diretivas do site no ISPConfig, nem sempre aquilo dá certo. É o caminho mais rápido para segurar alguns tipos de ataques mas em 50% dos sites dá problema de CSS ou banners/sliders.

    Para o Moodle, edite o arquivo config.php dele e altere ou adicione essas linhas:
    $CFG->xsendfile = ‘X-Accel-Redirect’;
    $CFG->xsendfilealiases = array(
    ‘/dataroot/’ => $CFG->dataroot
    );

    E nas diretivas NginX do site no ISPConfig coloque estas, substituindo pela PATH correta:
    *Em SEUSITEMOODLE.com.br troque pelo dominio do site e tenha certeza que colocou /web/ ao final da linha.

    location /dataroot/ {
    internal;
    alias /var/www/SEUSITEMOODLE.com.br/web/;
    }

    Talvez você precise ainda da diretiva “location /” para o site, que não é publicada na documentação oficial:

    location / {
    # moodle rewrite rules
    rewrite ^/(.*.php)(/)(.*)$ /$1?file=/$3 last;
    }

    *Avise aqui se deu certo.

  • Victor Dantas

    Oi Luis! Desativei as linhas DDos e o joomla continua com o slider travado. Vejo que o css funciona em parte.
    O moodle não funcionou, mesmo colocando essas diretivas. Vou reinstalar o moodle, já que estou migrando de um servidor apache para nginx, talvez resolva o problema.

  • Apague o cache do Joomla. E tem que ver como você está migrando esse site.. nunca faça como root.

  • Victor Dantas

    Apaguei o cache e nada. Migrei usando ssh usando o comando rsync. Utilizei um usuário jail para migrar, Tanto do servidor atual tanto para o servidor antigo. Eu estou achando que esses componentes (extensões) joomla não funcionam em nginx ou tem algum bug que não conheço. Vejo os logs e não aparece error algum. Vi a documentação dessas extensões e não tem suporte para nginx. Em relação ao moodle a documentação é bem pequena para nginx e eles recomendam apache, porém apache come muita memoria, por isso meu interesse em nginx.

  • Victor Dantas

    (Resolvido) Oi Luís! A solução foi instalar o servidor novamente e optar por apache, alguma coisa que eu não sei impedia que os sites funcionassem no nginx, acho que pelo motivo deles terem sidos instalados no apache. Segui todo o tutorial e nas partes de nginx busquei na internet como fazer no apache, em especial a certificação https dos sites. Parabéns pelos tutoriais estão excelentes. Ps: Instalei um servidor debian8 + nginx e fiz a instalação do zero do joomla e instalei as extensão que estavam com problemas e resolveu. Porém, o site que tenho tem muita coisa para programar do zero, já que quando tentei fazer o backup pela ferramente akeeba e ficou com o mesmo error.

  • Obrigado por postar o feedback.

    Um dos meus clientes é programador bem conhecido e antigo de Joomla, ele trabalha com isso desde o início do CMS. Levantei 4 servidores para ele com NginX e da mesma forma descrita no tutorial e até agora não houve problemas sérios, somente acertos leves mas por causa de email.

    Em todo caso bom que tenha resolvido.

  • Olá Luís …. cheguei até o comando colado abaixo, sem problemas … apena agora tive essa resposta negativa, o que pode ser ?

    Meu domínio fqdn está apontado apenas por IP a partir do GoDaddy ….

    a vps está em hpv1.dbthost.com

    a situação é ssa :

    [email protected]:~# /etc/init.d/jailkit restart
    Stopping jailkit: jk_socketd/usr/sbin/jk_socketd: no process found
    done.
    Starting jailkit: jk_socketdversion 2.19, no sockets specified in configfile /etc/jailkit/jk_socketd.ini or on commandline, nothing to do, exiting…
    done.
    [email protected]:~#

    Obrigado por sua ajuda, abraço !

  • Isso não é erro, tem muita gente que confunde a saída do comando. Ali simplesmente avisa que não encontrou usuários em Jail a alterar e diz que não há nada a fazer.

    Mas mesmo assim é necessário executar o comando.

  • Obrigado Luis … depois vi …

    Conclui a parte do firewall e cheguei na parte do email …
    inclusive pedi a liberação da porta 25

    mas quando coloco https://ip_numero:8081/squirrelmail dá o erro abaixo

    An error occurred during a connection to 67.205.183.204:8081. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG

    eu criri a conta do email, no domínio do qual a vps é subdomínio … isso não tem problema ?
    por enquanto apontei o domínio apenas pelo IP (A) …. e não usei nenhum ns1, estou usando os padrões da godaddy mesmo … tem problema ?

    Abraço

  • O tutorial com Debian 8 instala o Roundcube por padrão e não o Squirrelmail. E se tiver problemas em acessar a URL do webmail ou phpmyadmin siga este outro artigo para resolver: https://fatorbinario.com/tutorial-ssl-com-lets-encrypt-certificado-gratuito-e-homologado-para-lojas-virtuais/

  • André

    no item 4c ⇒ depois q reinicia o NginX é possível acessar o IP colocando na frente https://MEU_IP – o (ERR_EMPTY_RESPONSE) só aparece pro http://MEU_IP

  • Com o ISPConfig não tem como acessar o site com o IP simplesmente. Tem que adicionar o site ao painel.

  • Feliciano sampaio

    concordo penei 15 minutos so para descobrir isso rsrs

  • Feliciano sampaio

    Passo 6: o comando “root# shutdown -r now” fica travado no meu SSH não acontece nada e também não libera o ssh para novo comandos o que eu fiz de Errado?

  • Esse comando reinicia o servidor. Você não tem mais acesso na tela atual do SSH por causa disso. Tem que fechar a tela atual e reabrir a conexão.