Tenho 3 servidores dedicados, todos rodando CentOS, localizados fisicamente no Canadá.
No servidor mais recente, o cPHulk começou a detectar (e colocar na lista negra) tentativas de login malsucedidas. Tudo começou no dia em que o servidor foi colocado online. Desde então, recebo de 15 a 30 e-mails diariamente do cPHulk informando que houve um "grande número de tentativas de login malsucedidas".
Percebi que todas as tentativas vinham da China, então instalei o csf e bloqueei totalmente a China. Alguns dias depois, os ataques voltaram, mas de países diferentes. Até agora bloqueei quatro países por desespero, mas sei que não é uma solução legítima. Agora eles vêm de países que não posso bloquear porque posso esperar tráfego legítimo desses países.
Também estou recebendo ataques de IPs que não parecem estar associados a um país, como nesta captura de tela:
Não estou preocupado que eles consigam adivinhar a senha, pois a senha que uso é muito forte.
Então minhas perguntas são,por que eles estão visando meu servidor e como o encontraram tão rapidamente? Como posso mitigar essas tentativas de login sem bloquear países inteiros? E de onde vem esse IP na captura de tela?Meu único palpite é que, de alguma forma, recebi um IP com uma reputação terrível, mas minha experiência e conhecimento como administrador de servidor são um pouco limitados, então nem sei a plausibilidade disso.
Responder1
Como disse Michael Hampton: Eles [TM] fazem isso com todo mundo. Seus scripts detectaram um endereço IP escutando em uma porta e estão jogando nomes de usuário e senhas para ver se alguma coisa pega. Esseé um mapa de ataques ao vivo.
Se os e-mails incomodarem você, você pode colocar IPs de login permitidos na lista de permissões e receber um e-mail quando alguém fizer login em um site que não esteja na lista de permissões.
Quanto ao IP na captura de tela,0.42.0.0:
O endereço 0.0.0.0 só pode ser usado como endereço de um pacote de saída quando um computador está aprendendo qual endereço IP deve usar. Nunca é usado como endereço de destino. Endereços começando com “0”. às vezes são usados para transmissões para dispositivos conectados diretamente.
Se você vir endereços começando com "0." nos registros, eles provavelmente estão em uso na sua rede, que pode ser tão pequena quanto um computador conectado a um gateway doméstico.
Este bloco foi atribuído pela IETF, a organização que desenvolve protocolos de Internet, no documento padrão, RFC 1122, e está documentado posteriormente no documento de melhores práticas atuais RFC 6890. A IANA está listada como registrante para deixar claro que esta rede é não atribuído a nenhuma organização única.
Esses documentos podem ser encontrados em: http://datatracker.ietf.org/doc/rfc1122 http://datatracker.ietf.org/doc/rfc6890
Responder2
Estou surpreso que ninguém tenha mencionado isso, mas uma maneira drástica de se livrar desses ataques de força bruta muito comuns é configurar um daemon de porta comoknockd. Assim, a menos que o invasor verifique sua máquina com uma sequência específica de portas na ordem correta, ele nem mesmo encontrará uma porta SSH aberta. Para usuários legítimos, muitos clientes SSH suportam isso e são capazes de acionar a sequência de portas correta antes de se conectarem ao servidor ssh.
Mas, obviamente, a autenticação não trivial com uma prisão fail2ban em execução e tempos apropriados de localização e banimento é suficiente em quase todos os casos.
Responder3
Se for apenas sobre sshd- veja, por exemplo, aquihttps://unix.stackexchange.com/questions/21639/internet-ssh-server-security-considerations.
Devo confiar no uso de nome de usuário e senha, não de chaves. Para ser mais seguro, começo sshdem uma porta não padrão, que parece impedir cerca de 99% ou mais dos ataques. Em seguida, defina LoginGraceTimesuas configurações sshd como, digamos. 10 Isso significa que, após 3 tentativas fracassadas, a próxima tentativa só poderá ser feita após 10 segundos, o que dá a qualquer tentativa de autenticação 10 segundos antes de fechar a conexão. Então, a força bruta não existe maisqueforte :) . Certifique-se também de definir PermitRootLogin no.