Eu sou relativamente novo no mundo da administração de sistemas. Eu tenho trabalhado em um aplicativo recentemente e quando eu verificar meus logs do servidor de aplicativos, eu constantemente recebo vários endereços IP tentando ssh no meu servidor pela força bruta. Aqui está um exemplo do meu log do servidor:
Feb 14 04:07:20 foodwiz3 sshd[1264]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Feb 14 04:07:21 foodwiz3 sshd[1264]: reverse mapping checking getaddrinfo for coenamor.columbiansabbatical.com [23.249.167.223] failed - POSSIBLE BREAK-IN ATTEMPT!
Feb 14 04:07:21 foodwiz3 sshd[1264]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=23.249.167.223 user=root
Feb 14 04:07:23 foodwiz3 sshd[1264]: Failed password for root from 23.249.167.223 port 32997 ssh2
Feb 14 04:07:23 foodwiz3 sshd[1264]: Received disconnect from 23.249.167.223: 11: Bye Bye [preauth]
Feb 14 04:13:04 foodwiz3 sshd[1289]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Feb 14 04:13:05 foodwiz3 sshd[1289]: reverse mapping checking getaddrinfo for coenamor.columbiansabbatical.com [23.249.167.223] failed - POSSIBLE BREAK-IN ATTEMPT!
Feb 14 04:13:05 foodwiz3 sshd[1289]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=23.249.167.223 user=root
Feb 14 04:13:07 foodwiz3 sshd[1289]: Failed password for root from 23.249.167.223 port 41562 ssh2
Isso é algo bastante normal, ou eu deveria estar preocupado / fazendo algo sobre isso?
Bem-vindo ao maravilhoso mundo da Internet ... Você:
ssh ? Mas a verdadeira resposta é: Sim, isso é normal : o BotNet Maffia sempre pode usar alguns servidores extras mal protegidos ...
É bastante normal ter testes de login suficientes para criar um registro de inundação.
Alterar portas SSH é mais um tipo de solução de 'segurança por obscuridade', mas ajuda na inundação. Eu enfatizo que não é muito elegante; existem portas de facto para serviços por uma razão.
Como ele deve estar ativado por padrão, mas garanta que você não possa executar o SSH em seu servidor como root. É o nome de usuário que é bastante consistente entre os servidores e, portanto, o principal alvo para tentativas de login por força bruta de senha. Aplique a configuração com a seguinte linha em sshd_config :
PermitRootLogin no
Veja também fail2ban que monitora os logs do sshd para reincidentes. Por exemplo, 5 logins com falha em 3 minutos de um determinado IP teriam esse IP bloqueado por 10 minutos. Eu aumentei o tempo de proibição para 24 horas para reduzir ainda mais o spam de log - com sucesso. :)
Eu sugiro que você faça algumas coisas:
/ etc / ssh / sshd_config
# What ports, IPs and protocols we listen for
Port 50022
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
Instal fail2ban - monitora os arquivos de log e proíbe temporariamente ou persistentemente
endereços sujeitos a falhas, atualizando as regras de firewall existentes ( iptables ).
Certifique-se de listar em branco seus locais confiáveis.
Sim, preocupe-se . Você pode nunca se queimar, mas deve seguir as melhores práticas de TI. É melhor prevenir do que remediar.
Sou administrador de rede em um hospital. É sempre uma idéia ruim para conectar uma caixa diretamente à internet. O que você está vendo são todos os milhares de scanners automáticos que examinam a vulnerabilidade na Internet. Eu vejo esses e todos os tipos de coisas (varreduras de porta, vários testes de vulnerabilidade conhecidos) para todos os tipos de software (ssh, telnet, ftp, etc) aparecem em nossa caixa de IDs. Sua máquina deve estar por trás de uma solução de firewall / NAT e você deve encaminhar apenas as portas necessárias para a Internet (80, 443 etc). É relativamente fácil de fazer. O fato de ter algo que você pode usar para gerenciar (SSH telnet) é uma má idéia ter que enfrentar a Internet porque se - por qualquer razão - houver um bug no software SSH / telnet nesse servidor, o bot automatizado irá detectá-lo em um piscar de olhos e você vai ser ferrado. Bugs no software acontecem o tempo todo e pode demorar um pouco para um patch ser lançado ou para você se lembrar de corrigi-lo.
Se você precisar gerenciar remotamente, procure configurar algo como uma solução de VPN ou usar o Windows, configure o gateway de serviços de terminal para a área de trabalho remota. Eu sei que você pode usar uma caixa Linux ou Windows separada com 2 NICs para configurar roteamento e acesso remoto para VPN e NAT, se você é apenas uma pequena loja. Caso contrário, fornecedores como a Cisco possuem soluções de firewall / NAT de hardware (Cisco ASA).
Em resumo, coloque sua máquina atrás do NAT. Apenas a porta encaminha as portas necessárias para executar a finalidade do serviço. Não redirecione os serviços usados para gerenciamento para a Internet, em vez disso, procure na VPN por gerenciamento remoto.
P.S. A alteração das portas SSH pode ajudar com o volume de log, mas não impede o acesso ao SSH. Qualquer um dos milhares de localizadores de vulnerabilidades automatizadas pode e fará varreduras de portas para ver quais portas estão atendendo a quais serviços. Você mesmo pode fazer isso com uma ferramenta chamada nmap .
Você pode configurar o firewall interno do kernel por iptables . Para que apenas algumas máquinas possam ssh para o seu servidor e deixar outros pacotes IP caírem. Veja man iptables para mais informações.
Por exemplo, se 192.168.1.67 é o host do qual você é ssh, então no tipo de servidor:
sudo iptables -A INPUT -p tcp --dport ssh -s 192.168.1.67 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport ssh -j DROP
sudo iptables-save
Você realmente precisa do seu servidor na internet? Se você realmente quiser tê-lo na internet, verifique se ele está seguro antes de colocá-lo lá.
Mudar a porta é apenas segurança através da obscuridade. Se o invasor for mais sofisticado do que apenas executar scripts, isso não ajudará.
Algumas coisas já mencionadas que recomendo também:
Eu acabei de entrar nesta comunidade porque há duas coisas que não foram adequadamente abordadas.
Outro exemplo para @cff answer, se você pretende banir sucessivas "tentativas" em seu servidor SSH:
sudo iptables -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW -m recent --update --seconds 600 --hitcount 4 --name DEFAULT --mask 255.255.255.255 --rsource -j DROP
sudo iptables -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW -m recent --set --name DEFAULT --mask 255.255.255.255 --rsource
sudo iptables-save
Esta é uma tentativa de conexão de 'tags' e se mais de 4 acontecer em 600s (10mn), a origem é 'banida'. Use isso em vez da solução @cff porque é mais seguro (se você bloquear, aguarde 10 minutos e tente novamente).