Estou recebendo isso com bastante frequência em /var/log/secure.log :
Nov 5 10:50:49 www sshd[775]: reverse mapping checking getaddrinfo for 124.107.32.54.pldt.net [124.107.32.54] failed - POSSIBLE BREAK-IN ATTEMPT!
Nov 5 10:50:49 www sshd[775]: Invalid user weber from 124.107.32.54
Nov 5 10:51:18 www sshd[802]: Invalid user weblogic from 66.178.48.196
Nov 5 10:51:56 www sshd[826]: reverse mapping checking getaddrinfo for gw-baneasa-v422.comtelnetworks.eu [193.230.208.98] failed - POSSIBLE BREAK-IN ATTEMPT!
Nov 5 10:51:56 www sshd[826]: Invalid user webmail from 193.230.208.98
Nov 5 10:52:22 www sshd[860]: Invalid user webmail from 150.214.102.129
Nov 5 10:53:29 www sshd[905]: Invalid user webmaster from 195.205.203.6
Nov 5 10:53:57 www sshd[928]: Invalid user webmaster from 86.101.90.21
Nov 5 10:54:29 www sshd[943]: Invalid user webservd from 151.118.130.225
Eu desabilitei todas as formas de autenticação SSH, exceto publickey , então acho que elas não conseguirão entrar. Mas eu deveria estar mais preocupado com isso?
Uma boa alternativa para mover sua porta SSH é usar algo como Blockhosts . É um script python que varre seus arquivos de log (geralmente /var/log/auth.log) para esses tipos de coisas, e coloca entradas dinâmicas em /etc/hosts.allow para bloquear pessoas que fazem varredura de força bruta. Eu uso-o para um bom efeito no meu SSH e vsftpd instala a pessoas na lista negra após 5 senhas incorretas em uma linha.
Como já foi mencionado, é apenas uma verificação automática, que tenta anexar um dicionário a um tipo de alvo conhecido (para o invasor, é claro).
Como uma técnica de redução de ruído você pode alterar a porta SSHD no seu servidor, você pode atingir esse objetivo de uma maneira muito simples seguindo o .
NOTA : Esta abordagem tem nada a ver com segurança real (como todos sabem que a segurança através da obscuridade não é segurança de todo), mas pode ajudar a manter os script kiddies longe, e o seu syslog vai agradecer:)
EDITAR :
Uma implementação alternativa da abordagem de lista negra pode ser obtida usando Listas negras de força bruta SSH pública em tempo real, como sshbl.org .
Uma alternativa para a abordagem BL local é, em vez disso, a boa BFD (Detecção de força bruta)
Você também pode querer considerar o uso de fail2ban .
Restringir seu método de autenticação a publickey é um ótimo começo. Usando um scanner de log Denyhosts ou Blockhosts (como disse Graeme) ajudará a proteger contra tentativas repetidas do mesmo endereço. O Denyhosts tem um banco de dados compartilhado opcional que permite bloquear endereços que outras pessoas viram.
Além de restringir o método de autenticação, a melhor solução que encontrei é mover o SSH para uma porta diferente. As varreduras parecem estar focadas na porta 22. Depois de sair dessa porta, as tentativas em cada um dos meus servidores caíram para zero.
Se você tiver o ssh ligado, isso fará com que sua máquina pareça um alvo interessante, já que é mais provável que seja um servidor e, portanto, vale a pena invadir do ponto de vista do hacker.
Você pode fazer segurança por obscuridade e mover sua porta ssh. Você pode fazer isso na máquina com este link de que também funciona no 10.5. Eu não fiz isso em 10.6, mas eu não conheço nenhuma razão para que isso não funcione também.
Você também pode fazer isso em um firewall para traduzir uma solicitação externa para uma porta diferente para encaminhar para 22 nesta máquina. Este é apenas um método diferente de segurança pela obscuridade.
Você pode desativar o ssh de fora e usar uma VPN apenas para entrar. Do ponto de vista de segurança, essa é a melhor opção.
Em qualquer caso, verifique se você tem uma senha strong. Se você tiver uma senha strong, ela não entrará, mas deixará na porta padrão o potencial para um mini ataque de negação de serviço sobrecarregando a máquina com solicitações de autenticação ou pelo menos uma pequena perda de desempenho. / p>
Você notará que eles estão praticamente tentando todos os tipos de logons em ordem alfabética. Outra camada de segurança é ter um nome de login não padrão. Você pode apostar que eles vão tentar admin e root, por exemplo.
Também gosto de desativar o protocolo ssh1 mais antigo e menos seguro: link
Você tem a porta 22 exposta ao mundo. Você pode usar os recursos de firewall do OSX incorporados para restringir os IPs que podem acessar sua máquina ou pode colocar algum tipo de dispositivo / servidor de firewall na frente de sua rede e exigir que as pessoas se conectem a isso (normalmente via VPN) antes de conectar para o (s) seu (s) servidor (es).
Eu pessoalmente não me incomodaria em mudar a porta do SSH. Segurança pela obscuridade é um mito. Os scanners de porta podem descobrir facilmente que tipo de serviço está sendo executado em uma porta não padrão e tornar os ambientes fora do padrão podem causar problemas com os fornecedores ou adicionar mais coisas para garantir que todas as pessoas recém-contratadas saibam fazer isso. Apenas adiciona mais coisas para documentar e garantir que sejam padronizadas.
Não se preocupe com isso. É uma varredura automática, você acabou de ganhar o sorteio dessa vez.
É bom saber, acho que o Blockhosts é uma alternativa melhor para o SSH
Daniela, Baneasa