Proftpd cai o tempo todo em um EC2

[zekkerj]

Esteja à vontade. Quando você aceitar que teu servidor não está caindo, e sim sendo derrubado, estaremos aqui pra te ajudar.

[cpaynes]

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

[emanueltavares]

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.

[cpaynes]

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

[zekkerj]

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...

[emanueltavares]

Obrigado, vou testar e já retorno.

[emanueltavares]

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:

Código Selecionar Expandir


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.

[cpaynes]

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"

[emanueltavares]

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:

Código Selecionar Expandir


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
}


Código Selecionar Expandir


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!

[cpaynes]

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.

[emanueltavares]

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.

Código Selecionar Expandir

# 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

[zekkerj]

ô 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...

[emanueltavares]

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

[zekkerj]

Duas palavras pra você: se vira.
Aliás, três: Tchau.

[emanueltavares]

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