Fórum Ubuntu Linux - PT
Suporte Técnico => Servidores => Tópico iniciado por: emanueltavares em 14 de Abril de 2016, 14:51
-
Pessoal,
Encontrei aqui no forum uns dois tópicos com esse tema, mas não a solução.
Utilizo a plataforma AWS há um bom tempo e de uns tempos pra cá quando instalo o Proftpd ele cai por inatividade de tempos em tempos.
É um transtorno. Eu nunca tinha visto isso acontecer antes.
Rodo em modo Standalone e mascarando o IP.
Vlw!
Emanuel
-
Defina "cai por inatividade".
Quem está caindo, o serviço, ou a conexão do cliente?
-
Cai o serviço.
Eu sou obrigado a dar um service proftpd restart o tempo todo.
[]'s
-
O que os logs do sistema e do proftpd dizem? Alguma dica de qual seja o motivo?
Seu sistema está atualizado?
-
Eu fico imaginando em que log poderia constar algo.
Ele simplesmente para de aceitar conexões.
Eu encontrei mais dois posts aqui no fórum do final do ano passado com problemas semelhantes e sem resposta.
Segue meu proftpd.conf
#
# /etc/proftpd/proftpd.conf -- This is a basic ProFTPD configuration file.
# To really apply changes, reload proftpd after modifications, if
# it runs in daemon mode. It is not required in inetd/xinetd mode.
#
# Includes DSO modules
Include /etc/proftpd/modules.conf
# Set off to disable IPv6 support which is annoying on IPv4 only boxes.
UseIPv6 on
# If set on you can experience a longer connection delay in many cases.
IdentLookups on
ServerName "CONNIX 1"
ServerType standalone
DeferWelcome off
MultilineRFC2228 on
DefaultServer on
ShowSymlinks on
TimeoutNoTransfer 600
TimeoutStalled 600
TimeoutIdle 1200
DisplayLogin welcome.msg
DisplayChdir .message true
ListOptions "-l"
DenyFilter \*.*/
# Use this to jail all users in their homes
DefaultRoot ~
# Users require a valid shell listed in /etc/shells to login.
# Use this directive to release that constrain.
RequireValidShell off
# Port 21 is the standard FTP port.
Port 21
# In some cases you have to specify passive ports range to by-pass
# firewall limitations. Ephemeral ports can be used for that, but
# feel free to use a more narrow range.
# PassivePorts 49152 65534
PassivePorts 49152 49180
# If your host was NATted, this option is useful in order to
# allow passive tranfers to work. You have to use your public
# address and opening the passive ports used on your firewall as well.
MasqueradeAddress 52.1.73.157
# This is useful for masquerading address with dynamic IPs:
# refresh any configured MasqueradeAddress directives every 8 hours
<IfModule mod_dynmasq.c>
# DynMasqRefresh 28800
</IfModule>
# To prevent DoS attacks, set the maximum number of child processes
# to 30. If you need to allow more than 30 concurrent connections
# at once, simply increase this value. Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd)
MaxInstances 30
# Set the user and group that the server normally runs at.
User proftpd
Group nogroup
# Umask 022 is a good standard umask to prevent new files and dirs
# (second parm) from being group and world writable.
Umask 022 022
# Normally, we want files to be overwriteable.
AllowOverwrite on
# Uncomment this if you are using NIS or LDAP via NSS to retrieve passwords:
# PersistentPasswd off
# This is required to use both PAM-based authentication and local passwords
# AuthOrder mod_auth_pam.c* mod_auth_unix.c
# Be warned: use of this directive impacts CPU average load!
# Uncomment this if you like to see progress and transfer rate with ftpwho
# in downloads. That is not needed for uploads rates.
#
# UseSendFile off
TransferLog /var/log/proftpd/xferlog
SystemLog /var/log/proftpd/proftpd.log
# Logging onto /var/log/lastlog is enabled but set to off by default
#UseLastlog on
# In order to keep log file dates consistent after chroot, use timezone info
# from /etc/localtime. If this is not set, and proftpd is configured to
# chroot (e.g. DefaultRoot or <Anonymous>), it will use the non-daylight
# savings timezone regardless of whether DST is in effect.
#SetEnv TZ :/etc/localtime
<IfModule mod_quotatab.c>
QuotaEngine off
</IfModule>
<IfModule mod_ratio.c>
Ratios off
</IfModule>
# Delay engine reduces impact of the so-called Timing Attack described in
# http://www.securityfocus.com/bid/11430/discuss
# It is on by default.
<IfModule mod_delay.c>
DelayEngine on
</IfModule>
<IfModule mod_ctrls.c>
ControlsEngine off
ControlsMaxClients 2
ControlsLog /var/log/proftpd/controls.log
ControlsInterval 5
ControlsSocket /var/run/proftpd/proftpd.sock
</IfModule>
<IfModule mod_ctrls_admin.c>
AdminControlsEngine off
</IfModule>
#
# Alternative authentication frameworks
#
#Include /etc/proftpd/ldap.conf
#Include /etc/proftpd/sql.conf
#
# This is used for FTPS connections
#
#Include /etc/proftpd/tls.conf
#
# Useful to keep VirtualHost/VirtualRoot directives separated
#
#Include /etc/proftpd/virtuals.conf
# A basic anonymous configuration, no upload directories.
# <Anonymous ~ftp>
# User ftp
# Group nogroup
# # We want clients to be able to login with "anonymous" as well as "ftp"
# UserAlias anonymous ftp
# # Cosmetic changes, all files belongs to ftp user
# DirFakeUser on ftp
# DirFakeGroup on ftp
#
# RequireValidShell off
#
# # Limit the maximum number of anonymous logins
# MaxClients 10
#
# # We want 'welcome.msg' displayed at login, and '.message' displayed
# # in each newly chdired directory.
# DisplayLogin welcome.msg
# DisplayChdir .message
#
# # Limit WRITE everywhere in the anonymous chroot
# <Directory *>
# <Limit WRITE>
# DenyAll
# </Limit>
# </Directory>
#
# # Uncomment this if you're brave.
# # <Directory incoming>
# # # Umask 022 is a good standard umask to prevent new files and dirs
# # # (second parm) from being group and world writable.
# # Umask 022 022
# # <Limit READ WRITE>
# # DenyAll
# # </Limit>
# # <Limit STOR>
# # AllowAll
# # </Limit>
# # </Directory>
#
# </Anonymous>
# Include other custom configuration files
Include /etc/proftpd/conf.d/
-
Os logs devem estar aqui:
TransferLog /var/log/proftpd/xferlog
SystemLog /var/log/proftpd/proftpd.log
Ou alguma coisa no:
/var/log/messasges
/var/log/syslog
Essa instância EC2, possui 512Mb de ram? Não estaria ficando sem ram por um acaso?
Isso ocasionaria um kill do processo.
-
Creio que me expressei mal.
Não sou um especialista em infra, mas conheço os logs e não encontro nada que justifique.
O que eu estou vendo é uma série de tentativas frustradas de entrar no servidor, que você pode ver nesse trecho do proftpd.log:
016-04-14 14:00:11,253 ip-172-30-2-151 proftpd[8622] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): FTP session opened.
2016-04-14 14:00:11,357 ip-172-30-2-151 proftpd[8621] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): FTP session closed.
2016-04-14 14:00:11,466 ip-172-30-2-151 proftpd[8622] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): USER conhecen: no such user found from host1.webinformativomarketing.com [95.110.236.43] to ::ffff:172.30.2.151:21
2016-04-14 14:00:11,968 ip-172-30-2-151 proftpd[8623] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): FTP session opened.
2016-04-14 14:00:12,075 ip-172-30-2-151 proftpd[8622] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): FTP session closed.
2016-04-14 14:00:12,191 ip-172-30-2-151 proftpd[8623] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): USER conhecen: no such user found from host1.webinformativomarketing.com [95.110.236.43] to ::ffff:172.30.2.151:21
2016-04-14 14:00:12,541 ip-172-30-2-151 proftpd[8624] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): FTP session opened.
2016-04-14 14:00:12,653 ip-172-30-2-151 proftpd[8623] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): FTP session closed.
2016-04-14 14:00:12,753 ip-172-30-2-151 proftpd[8624] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): USER conhecen: no such user found from host1.webinformativomarketing.com [95.110.236.43] to ::ffff:172.30.2.151:21
2016-04-14 14:00:13,134 ip-172-30-2-151 proftpd[8625] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): FTP session opened.
2016-04-14 14:00:13,239 ip-172-30-2-151 proftpd[8624] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): FTP session closed.
2016-04-14 14:00:13,356 ip-172-30-2-151 proftpd[8625] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): USER conhecen: no such user found from host1.webinformativomarketing.com [95.110.236.43] to ::ffff:172.30.2.151:21
2016-04-14 14:00:13,713 ip-172-30-2-151 proftpd[8626] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): FTP session opened.
2016-04-14 14:00:13,824 ip-172-30-2-151 proftpd[8625] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): FTP session closed.
2016-04-14 14:00:13,926 ip-172-30-2-151 proftpd[8626] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): USER conhecen: no such user found from host1.webinformativomarketing.com [95.110.236.43] to ::ffff:172.30.2.151:21
2016-04-14 14:00:14,298 ip-172-30-2-151 proftpd[8627] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): FTP session opened.
2016-04-14 14:00:14,404 ip-172-30-2-151 proftpd[8626] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): FTP session closed.
2016-04-14 14:00:14,521 ip-172-30-2-151 proftpd[8627] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): USER conhecen: no such user found from host1.webinformativomarketing.com [95.110.236.43] to ::ffff:172.30.2.151:21
2016-04-14 14:00:14,874 ip-172-30-2-151 proftpd[8628] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): FTP session opened.
2016-04-14 14:00:14,984 ip-172-30-2-151 proftpd[8627] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): FTP session closed.
2016-04-14 14:00:15,082 ip-172-30-2-151 proftpd[8628] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): USER conhecen: no such user found from host1.webinformativomarketing.com [95.110.236.43] to ::ffff:172.30.2.151:21
2016-04-14 14:00:15,516 ip-172-30-2-151 proftpd[8629] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): FTP session opened.
2016-04-14 14:00:15,620 ip-172-30-2-151 proftpd[8628] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): FTP session closed.
2016-04-14 14:00:15,739 ip-172-30-2-151 proftpd[8629] ip-172-30-2-151.ec2.internal (host1.webinformativomarketing.com[95.110.236.43]): USER conhecen: no such user found from host1.webinformativomarketing.com [95.110.236.43] to ::ffff:172.30.2.151:21
Há muitas! Isso pode fazer o servidor cair?
Quanto a memória, não, é um servidor produção.
-
Essas tentativas de conexão estão vindo de você?
Que arquivo foi esse que vc postou?
-
Não são tentativas minhas. O usuário o cara está chutando.
Como comentei, é o proftpd.log.
-
Tá tudo indicando que vc está sob ataque... hora de questionar: vc precisa mesmo oferecer o serviço ftp? não dá pra trabalhar com outros serviços, como HTTP ou HTTPS?
-
Não tem jeito e o meu servidor está sob ataque a vida inteira. Hoje não está tão popular e estamos redesenvolvendo, mas é o site JornalExpress - www.jex.com.br, onde qualquer pessoa pode criar um jornal online.
Um outro cliente, o maior portal de estruturas metálicas do país - www.metalica.com.br, que também tem uma visitação expressiva, está com o mesmo problema no servidor dele na AWS.
Por outro lado, o site está completando 16 anos e nunca tivemos esse tipo de problema antes. Sempre tivemos FTP na máquina.
Usamos o FTP apenas para subir programas, mas é imprescindível.
Para mim parece um problema qualquer de configuração. Posso até imaginar que algo o derruba por segurança, sei lá, mas está estranho.
[]'s
Emanuel
-
Mude a porta do serviço FTP, ou crie um serviço HTTP/HTTPS pra fazer o upload de seus programas.
Outra alternativa muito interessante é enviar arquivos via scp/ssh/sshfs (desde que faça isso sem usar as portas padrão, que são muito visadas por ataque).
-
Conheço todas elas, mas isso não explica o porquê de durante 15 anos o serviço funcionar e agora parar.
No servidor do Metálica, por exemplo, isso não seria possível, pois há um editor que possui acesso e é leigo.
Não tem nada errado no proftpd.conf?
-
Você pode atravessar a rua fora da faixa durante 40 anos sem acontecer nada, e ser atropelado no próximo aniversário. Te descobriram, descobriram um serviço explorável, e estão explorando... e vão continuar explorando enquanto você oferecer o serviço, até que uma coisa aconteça: ou você esconde esse serviço em outra porta, ou você o protege contra tentativas seguidas de conexão (informe-se sobre "fail2ban"), ou deixa de usar FTP. A escolha é sua, o bônus (ou o ônus) também.
-
Desculpe, mas não ajudou.
Obrigado.
-
Esteja à vontade. Quando você aceitar que teu servidor não está caindo, e sim sendo derrubado, estaremos aqui pra te ajudar.
-
Mas suas quedas podem ter relação com essas tentativas de acesso sim.
Use um modo verboso para descobrir algo.
De qualquer forma, mude a porta como o Zekkerj recomendou.
http://www.proftpd.org/docs/howto/Debugging.html
http://www.proftpd.org/docs/howto/Logging.html
http://www.proftpd.org/docs/directives/linked/config_ref_DebugLevel.html
-
Estou pensando realmente nesses acessos, mas considero trocar a porta uma saída inadequada. É como se, para evitar ataques, eu movesse a porta 80 do HTTP.
O que eu estranho é que esse tipo de situação, tentativas de invasão, são normais para mim e nunca vi o ProFTP fazer isso.
-
Para o protocolo http, existem outras manobras.
Se não optar pela troca da porta, experimente o Fail2ban:
http://www.fail2ban.org/wiki/index.php/ProFTPd
-
Lembrando que o fail2ban não vai impedir o cara de derrubar teu serviço ftp, mas vai impedir dele voltar a derrubar, como acontece agora...
-
Obrigado, vou testar e já retorno.
-
Ainda não pude realizar o teste do Fail2ban, mas hoje aconteceu um fato que pode corroborar a tese de não serem os acessos indevidos.
Um servidor recém instalado do zero, em um cliente nada a ver com o resto, estava com seu FTP fora do ar. Antes de religá-lo, olhei o log e encontrei um kill no processo do nada:
2016-04-25 06:35:28,969 ip-172-31-54-225 proftpd[1074] ip-172-31-54-225.ec2.internal: ProFTPD killed (signal 15)
2016-04-25 06:35:28,969 ip-172-31-54-225 proftpd[1074] ip-172-31-54-225.ec2.internal: ProFTPD 1.3.5rc3 standalone mode SHUTDOWN
2016-04-25 15:21:21,235 ip-172-31-54-225 proftpd[23334] ip-172-31-54-225.ec2.internal: ProFTPD 1.3.5rc3 (devel) (built Fri Dec 20 2013 18:05:41 UTC) standalone mode STARTUP
2016-04-25 15:21:23,378 ip-172-31-54-225 proftpd[23334] ip-172-31-54-225.ec2.internal: ProFTPD killed (signal 15)
2016-04-25 15:21:23,378 ip-172-31-54-225 proftpd[23334] ip-172-31-54-225.ec2.internal: ProFTPD 1.3.5rc3 standalone mode SHUTDOWN
2016-04-25 15:21:23,996 ip-172-31-54-225 proftpd[23394] ip-172-31-54-225.ec2.internal: ProFTPD 1.3.5rc3 (devel) (built Fri Dec 20 2013 18:05:41 UTC) standalone mode STARTUP
root@ip-172-31-54-225:/var/log/proftpd#
Na continuação fui eu religando.
Ainda me parece uma queda por timeout.
-
Esse killed (signal 15), podem ser duas coisas:
1 - Já falei anteriormente sobre a falta de memória em algum momento. Se for alguma instância sem swap e com pouca ram, isso pode ocorrer.
2 - Pode ser um bug dessa versão de SO/Proftd que stá usando. Para estes servers que estão matando o processo, está usando a mesma versão de SO? Quem sabe a mesma imagem do marketplace.
Confere se no seu /etc/init.d/proftpd
Procure a linha:
start-stop-daemon --stop --signal $SIGNAL --quiet --pidfile "$PIDFILE"
E altere o valor --quiet para --retry 1, e monitore.
start-stop-daemon --stop --signal $SIGNAL --retry 1 --quiet --pidfile "$PIDFILE"
-
Oi,
1. Não é falta de memória. Eu tenho três instâncias distintas, em clientes distintos, em nuvens distintas e todas apresentam o problema. Faço instalação padrão, alterando apenas o IP.
2. Estou usando a versão disponível na AWS e a instalação é via APT-GET padrão. Isso me deixa mais frustrado ainda, pois nunca vi um comportamento desses. Eu acabei de criar um servidor para um novo cliente, tudo padrão, e está acontecendo a mesma coisa. Por sinal, como o log dele é muito pequeno, consegui isolar esse KILL
Localizei três linhas parecidas com a que você me mandou, em duas circunstâncias diferentes:
start()
{
log_daemon_msg "Starting ftp server" "$NAME"
start-stop-daemon --start --quiet --pidfile "$PIDFILE" --oknodo --exec $DAEMON -- -c $CONFIG_FILE $OPTIONS
if [ $? != 0 ]; then
log_end_msg 1
exit 1
else
log_end_msg 0
fi
}
signal()
{
if [ "$1" = "stop" ]; then
SIGNAL="TERM"
log_daemon_msg "Stopping ftp server" "$NAME"
else
if [ "$1" = "reload" ]; then
SIGNAL="HUP"
log_daemon_msg "Reloading ftp server" "$NAME"
else
echo "ERR: wrong parameter given to signal()"
exit 1
fi
fi
if [ -f "$PIDFILE" ]; then
start-stop-daemon --stop --signal $SIGNAL --quiet --pidfile "$PIDFILE"
if [ $? = 0 ]; then
log_end_msg 0
else
SIGNAL="KILL"
start-stop-daemon --stop --signal $SIGNAL --quiet --pidfile "$PIDFILE" --retry=TERM/10/KILL/5
if [ $? != 0 ]; then
log_end_msg 1
[ $2 != 0 ] || exit 0
else
log_end_msg 0
fi
fi
if [ "$SIGNAL" = "KILL" ]; then
rm -f "$PIDFILE"
fi
else
log_end_msg 0
fi
}
Vlw!
-
Buenas..
1. Não é falta de memória. Eu tenho três instâncias distintas, em clientes distintos, em nuvens distintas e todas apresentam o problema. Faço instalação padrão, alterando apenas o IP.
Não quero ser insistente mas como você monitora os recursos do teu servidor? Uso de ram, CPU, disco... Usa alguma ferramenta como Zabbix, nagios?
2. Estou usando a versão disponível na AWS e a instalação é via APT-GET padrão...........
É a mesma imagem para todos?
Posta a versão de SO e do Proftpd aqui.
-
Estou frustrado. Não recebi nenhuma resposta objetiva.
Estou convencido que é algo na imagem da AWS, pois servidores novos, criados há um mês, apresentam o mesmo comportamento.
Além disso, a informação de que não é uma máquina isolada passou batido.
Não tem ninguém que conheça ProFTP para dar uma dica, ou me enviar um proftpd.conf que esteja funcionando?
Ontem eu me lembrei de um back up antigo e olhei o proftpd.conf. Encontrei uma diferença: no antigo o parâmetro de Delay Engine estava desligado e ele agora vem ligado por default.
Desliguei e estou analisando para ver se resolveu.
# Delay engine reduces impact of the so-called Timing Attack described in
# http://www.securityfocus.com/bid/11430/discuss
# It is on by default.
<IfModule mod_delay.c>
DelayEngine off
</IfModule>
[]'s
Emanuel
-
ô Emanuel, além de teimoso você é mal-agradecido, né? Você recebeu várias respostas objetivas sim.
Desculpa se não foram as respostas que você queria, mas o mundo é assim, lide com isso...
-
Ofensas pessoais nunca são boas.
Eu não sou teimoso. Teimosia é insistir em teses que não existem. São vários servidores, em várias VPCs, todos estão com problemas de memória?
Me recomendaram alterar uma linha, humildemente mostrei que haviam várias e perguntei qual, alguém se manifestou?
Falaram em ataques. Qual servidor? Todos?
Todas as hipóteses eu respondi educadamente, mas aparentemente ninguém sabe o que está acontecendo.
Eu encontrei uma diferença no proftpd.conf, mas não estou confiante.
Não sou mal-agradecido, apenas estou recebendo perguntas e mais perguntas no lugar de respostas. Sinto as pessoas chutando.
Insisto que minha instalação é padrão. Coloco o IP, fecho o root directory e ponho no ar. Se tenho de fazer algo agora eu não sei o que é. Instalo essas máquinas Ubuntu da AWS desde 2012 e nunca tinha passado por isso.
Att.,
Emanuel
-
Duas palavras pra você: se vira.
Aliás, três: Tchau.
-
Entrei nesse fórum achando que conseguiria uma resposta e tenho de ser ofendido? Dureza.
Fica em aberto. Alguém tem experiência em ambiente AWS que possa me auxiliar?
Obrigado,
Emanuel
-
Para registro, eu havia recebido a dica, mas perguntei onde aplicar e não recebi resposta.
Encontrei o porquê do problema, é um erro que ocorre no logrotate. Ele para o processo, mas não consegue dar o restart.
Há mais de 6.000 resultados no Google para "proftpd randomly killed".
-
Então posta exatamente o que você fez para corrigir.
Assim outros colegas podem usufruir da solução.
-
Justo.
No /etc/init.d/proftpd alterar as linhas, são duas:
start-stop-daemon --stop --signal $SIGNAL --quiet --pidfile "$PIDFILE"
Para
start-stop-daemon --stop --signal $SIGNAL --retry 1 --quiet --pidfile "$PIDFILE"
O problema é causado por uma falha no logrotate, que não está colocando o serviço de volta no ar.
Eu tinha recebido essa dica aqui, mas sem a explicação do porquê e se era para aplicar nas duas linhas.
[]'s
Emanuel Alexandre Tavares
-
Emanuel,
Em alguns posts anteriores, foi exatamente isso que lhe indiquei a fazer. ;)
Por isso lhe pedi para postar a solução.
Eu tinha recebido essa dica aqui, mas sem a explicação do porquê e se era para aplicar nas duas linhas.
O ideal é se colocar nos dois lados, o nosso e o seu. Não sabemos ao certo como está o seu ambiente, então ajudamos de acordo com as nossas experiências, não estamos conectados no seu ambiente para validar o que falamos, esse é sua responsabilidade, e em algumas vezes para chegar em alguma conclusão indicamos a fazer alguns procedimentos como forma de troubleshooting.
Quando lhe indiquei a fazer essa alteração, se você tivesse realizado ela, nós teríamos explicado. Vale ressaltar que nem todos dispõem de tempo suficiente para viver aqui resolvendo problemas dos outros, temos outras atividades em paralelo que consomem um tempo expressivo, mas mesmo assim buscamos ajuda e ajudar os colegas. Da mesma forma tempo para detalhar tudo. Naquele dia eu estava bem corrido.
Abraços.
-
Amigo, recomendo utilizar um programa chamado acunetix para efetuar testes de vulnerabilidade.
Ele faz um scan e um relatório de erros no site/servidor com as soluções de cada problema.
-
Este fórum é complicado mesmo.
Desisto.
Eu não posso pegar servidores em produção e aplicar uma alteração sem saber o que estou fazendo.
Sinto muito se você é muito ocupado. Eu também sou.
-
Antes de sair, passe no caixa e pegue de volta o dinheiro que você pagou pra ter seu suporte técnico...