É normal obter centenas de tentativas de invasão por dia?

196

Acabei de verificar o servidor /var/log/auth.loge descobri que estou recebendo mais de 500 notificações com falha de tentativa de invasão por senha por dia! Meu site é pequeno e seu URL é obscuro. Isso é normal? Devo tomar alguma medida?

Kyle
fonte
2
Até bloquearmos todas as portas externas desnecessárias, lembro que não apenas tivemos muitas tentativas de invasão, mas um dia foi tão ruim que estávamos sendo invadidos por dois países diferentes - ao mesmo tempo! Então, sim, centenas de tentativas de invasão são perfeitamente normais.
Django Reinhardt
91
Temos servidores que experimentam uma nova "sequência" de ataque uma vez a cada 16 segundos. Uma única sequência é geralmente um lote de cerca de 100 tentativas em várias portas. Apenas para brincadeiras, um dia liguei um servidor sem patch fora do nosso firewall; Demorou menos de 10 minutos a partir do momento em que foi ligado para que ele se desenvolvesse. Point é que a internet é realmente uma selva; tente não ser comido.
NotMe
2
Eu posso ver que eu postei minha pergunta no site errado: superuser.com/questions/200896/…
Justin C
6
Embora eu concorde com outras pessoas, isso é normal em portas comuns necessárias (80, 443). Eu praticamente eliminei essas tentativas na minha porta SSH, simplesmente alterando a porta padrão de 22 para algo obscuro como 6022, por exemplo. Só fazer isso, sozinho, quase eliminou 99% desse tipo de ataque.
Quilo
2
Se você deseja alterar sua porta SSH, há motivos de segurança para mantê-la abaixo da porta 1024 (somente o root pode abrir portas <1024, para protegê-lo de outros usuários que estão sequestrando o SSH).
Brendan Longo

Respostas:

207

Na internet de hoje, isso é bastante normal, infelizmente. Há hordas de botnets tentando acessar cada servidor encontrado em redes IP inteiras. Normalmente, eles usam ataques simples de dicionário em contas conhecidas (como contas raiz ou certas aplicações).

Os alvos de ataque não são encontrados via entradas do Google ou DNS, mas os atacantes apenas tentam todos os endereços IP em uma determinada sub-rede (por exemplo, de empresas conhecidas de hospedagem de servidores raiz). Portanto, não importa que o seu URL (daí a entrada DNS) seja bastante obscuro.

Por isso é tão importante:

  • proibir o login root no SSH ( howto )
  • use senhas fortes em qualquer lugar (também em seus aplicativos da web)
  • para SSH, use a autenticação de chave pública se possível e desativar senha-auth completamente ( howto )

Além disso, você pode instalar o fail2ban, que verificará o authlog e, se encontrar uma certa quantidade de tentativas de logon com falha de um IP, continuará adicionando esse IP ao /etc/hosts.denyiptables / netfilter para bloquear o invasor por alguns minutos.

Além dos ataques SSH, também está se tornando comum verificar seu servidor da Web em busca de aplicativos da Web vulneráveis ​​(alguns aplicativos de blog, CMSs, phpmyadmin etc.). Portanto, mantenha-os atualizados e configurados com segurança também!

Holger Just
fonte
21
Aplicativos como o fail2ban podem ajudar muito a impedir 'temporariamente' esses bots de atingirem o servidor em horários bobos pela manhã :-) Eu configurei o meu para proibir 3 tentativas incorretas por 24 horas.
emtunc
46
E mova a porta do ssh de 22 para 222. Isso funciona muito bem.
Tom O'Connor
40
+1, apenas autenticação de chave pública :)
0xC0000022L 08/03
3
@STATUS_ACCESS_DENIED: as ações fail2ban executadas são apenas listas de comandos do shell a serem executados. Portanto, é realmente flexível e fácil fazer o trabalho corretamente com qualquer configuração personalizada. A melhor referência é fazer o download e olhar action.d/iptables.conf.
18113 mattdm em
4
Bloquear atacantes como esse é uma perda de tempo. Se você desabilitar o login root, há uma boa chance de que ninguém sequer adivinhe seu nome de login correto, sem falar na senha. O próprio SSH já está solicitando uma senha de limitação de taxa; portanto, mesmo que eles saibam seu nome de usuário (os bots aleatórios não), se você tiver uma senha decente, eles nunca a adivinharão.
Brendan Long
58

Alguns 100 estão bem ... No mês passado, descobri que um dos meus servidores tinha 40k tentativas com falha. Passei pelo problema de traçá-los: Mapa

Depois que mudei a porta ssh e implementei Port Knocking, o número caiu para 0 :-)

Bart De Vos
fonte
2
Bom mapa. Eu adoraria saber como fazer isso!
jftuga
9
@ jftuga Eu obtive todos os IPs dos logs primeiro. grep 'Failed password' /var/log/secure* | grep sshd | grep -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' | sort | uniq(remova o | uniq no final se desejar permitir duplicatas). Você pode colocá-los em um CSV e enviá-lo para zeemaps.com. Tenho visto melhor mapas seguida mina, onde eles usariam a contagem para colorir o mapa (verde para vermelho para o número de tentativas por concelho), mas eu não jet imaginei que um fora
Bart De Vos
3
O que você quer dizer com 'Port Knocking implementado'? Existe um aplicativo que eu possa instalar via apt-get para fazer isso? O número de cair para 0 soa agradável
18
A segurança através da obscuridade é prejudicada. Está perfeitamente bem desde que faça parte da estratégia geral e não de toda a estratégia. Afinal, o que mais é uma senha que não seja uma string obscura?
Joel Coel
5
@ Joel Coel, é uma string secreta , em oposição à maior parte da segurança por questões de obscuridade - um processo obscuro, mas não necessariamente secreto.
tobyodavies
29

Eu, pelo menos, uso um "tarpit" além de permitir apenas a autenticação de chave pública e não permitir logins raiz.

Em netfilterhá um recentmódulo, que você pode usar com ( INPUTcadeia):

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource
iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP
iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

O que isso faz é que todas as tentativas de conexão à porta 22 sejam listadas pelo recentmódulo com IP e outras coisas sob o nome "tarpit" (se você estiver curioso, veja /proc/net/xt_recent/tarpit). Obviamente você pode usar outros nomes.

Para listar ou excluir IPs, use:

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit
echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

Essa taxa limita as tentativas para 5 em 300 segundos. Observe que os usuários com uma conexão existente não são incomodados por esse limite, porque eles já têm uma conexão estabelecida e podem criar mais (mesmo acima do limite da taxa).

Ajuste as regras ao seu gosto, mas certifique-se de que elas sejam adicionadas nessa ordem (por exemplo, ao adicionar e usá-las nessa ordem, ao inserir na ordem inversa).

Isso reduz o ruído imensamente. Ele também fornece segurança real (contra brutalidade), diferente da segurança percebida de alterar a porta. No entanto, eu ainda recomendo alterar a porta, se possível no seu ambiente. Também reduzirá muito o nível de ruído ...

Você ainda pode combinar isso com o fail2ban, embora eu esteja funcionando bem sem ele e apenas as regras acima.

EDITAR:

É possível bloquear-se fazendo isso, para que você possa adicionar algo como o seguinte, que permite liberar o banimento ao bater em uma porta específica:

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove
0xC0000022L
fonte
2
Eu uso isso e consigo me bloquear ocasionalmente, então gosto de configurar outra porta para que você possa "bater" para eliminar sua proibição.
benlumley
@ Benlumley: bom ponto. Porta batendo pode ser igualmente útil para mudar a porta padrão - ou mesmo ambos em combinação ...
0xC0000022L
@ benlumley: viu seu comentário (agora removido por Sam). Eu absolutamente não se importa se a resposta fica editado / melhorada;)
0xC0000022L
15

Você pode implementar fail2ban ou métodos semelhantes, como bloquear o SSH no seu IP. Infelizmente, os bots tentam acessar o força bruta o tempo todo, por isso é bastante normal, você precisa ter uma boa senha.

Jacob
fonte
3
Se você estiver usando SSH, considere a autenticação de chave pública. Isso é um pouco mais seguro que a autenticação por senha.
Piskvor
12

Sim . É bastante normal hoje em dia.

Por favor, use apenas autenticação de chave pública para fins administrativos, se possível. Gere uma chave privada em sua estação de trabalho:

$ ssh-keygen -t dsa

Copie o conteúdo de ~ / .ssh / id_dsa.pub para seus servidores ~ / .ssh / allowed_keys (e /root/.ssh/authorized_keys, caso você precise de login root direto).

Configure seus servidores / etc / ssh / sshd_config para aceitar apenas autenticação de chave pública:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

Se você tiver muitos servidores, poderá usar o Puppet para executar chaves públicas e configurações neles.

Examine Denyhosts e fail2ban para bloquear tentativas repetidas de login SSH e consulte Snort se você precisar de IDS / IPS completo.

jkj
fonte
2
Eu não recomendaria o uso de autenticação de chave pública no SSH para acesso ao shell do seu servidor. Se sua estação de trabalho estiver comprometida ou, ainda pior, roubada, agora alguém terá acesso aberto aos seus servidores sem a necessidade de uma senha. A autenticação de chave pública é mais para situações em que você precisa de algo como um script ou programa para poder ter acesso SSH a outro sistema sem precisar de uma senha, para que você não precise incorporar senhas de texto sem formatação no seu script / programa.
Usuário registrado
5
@ Conta excluída: você pode definir uma senha para a chave privada SSH.
Phil Cohen
2
O comentário "Usuário registrado" está incorreto. Apenas para esclarecer: sempre defina uma boa senha na sua chave privada e não armazene a chave privada em nenhum servidor. Mantenha a chave privada em sua própria estação de trabalho. Depois de adicionar a chave a um programa ssh-agent e digitar sua senha, você poderá efetuar login em todos os sistemas que possuem a chave pública instalada, sem precisar redigitar sua senha uma vez. Ative o encaminhamento de agente em seu cliente ssh para poder efetuar login de servidor em servidor. Roubar sua chave privada é ruim, mas com uma senha decente, não é tão ruim quanto uma senha roubada.
Martijn Heemels
Certo, nem pense em armazenar as chaves privadas do administrador sem criptografia.
Yrk
8

use http://denyhosts.sourceforge.net/

e sim, você deve usar a autenticação de chave pública e desativar a autenticação de senha.

número 5
fonte
Desabilitar a autenticação de senha nem sempre é uma solução viável.
Publiccert
6

As tentativas são mecanizadas, portanto os números parecem bons (sim, eles são altos em comparação com alguns sites e os baixos em comparação com outros). Você deve seguir as etapas normalmente necessárias: Considera seus sites como alvos de ataque todos os dias, mesmo quando não detecta um ataque; não detectar um ataque, não significa que ele não existe .

adamo
fonte
6

Eu diria que apenas obter apenas 500 é meio baixo.

Em um empregador anterior, um dos pesquisadores de segurança de computadores chamou o fluxo constante de tentativas de invasão de "equivalente na internet ao ruído cósmico ". Ele o descreveu como um fluxo contínuo normal de tráfego malicioso que procurava sistemas na Internet e explorava automaticamente scripts para tentar sequestrar o sistema. As redes de bots e outros sistemas maliciosos perpetuamente varreriam e analisariam novamente a Internet em busca de sistemas vulneráveis, como o SETI.

James Schek
fonte
6

Sim,

isso é comum, mas isso não significa que você não deve lutar contra a boa luta. Aqui estão algumas etapas sobre como você pode tornar seu servidor mais seguro.

Evite endereços IP associados ao DNS

Você pode reduzir bastante esse número em ambientes compartilhados ou de colocation desativando o acesso SSH em qualquer endereço IP associado a nomes de domínio. Os endereços IP não pertencentes ao domínio não listados receberão menos desse tipo de tráfego, portanto, compre um IP não listado e use-o apenas para acesso SSH.

Use uma VPN para todo o acesso SSH

Se você estiver em um ambiente em que possa implementar o IPsec / VPN em uma rede privada no ambiente do servidor, isso é ideal. Desative todo o acesso à Internet SSH, verifique se você tem uma solução de luzes apagadas integrada. Configure sua VPN e permita apenas o acesso SSH a partir da sua VPN.

Implementar regras de endereço IP para acesso SSH

Se a VLAN não for uma opção, configure seu roteador ou regras de firewall para permitir apenas conexões SSH a partir de um intervalo de endereços IP conhecido.

Se você seguir estas etapas, dormirá muito mais facilmente durante a noite sabendo que alguém teria que comprometer a rede de suas empresas de hospedagem para obter acesso ao servidor através do SSH.

Ben DeMott
fonte
5

É bastante normal ver centenas de conexões SSH com falha.

Se você tiver a opção, simplesmente altero minha porta SSH para algo fora do padrão. Isso não necessariamente torna seu servidor mais seguro, mas com certeza limpa os logs (e permite que você veja alguém tentando invadir deliberadamente!)

Adrian Macneil
fonte
5

Além de usar um mecanismo de bloqueio automatizado como fail2ban, você tem mais uma opção: entre em contato com o ISP do endereço de abuso do invasor. Pode parecer completamente inútil, mas no caso do script-kiddie, seu ISP está mais do que disposto a agir sobre eles.

Para encontrar o endereço de abuso, comece com arin.net e procure o endereço IP usando whois. Você pode ser redirecionado para outro registro regional, mas eventualmente poderá encontrar o ISP responsável pelo bloco IP que contém o endereço. Procure o endereço abuse @ ou apenas envie o contato técnico.

Envie a eles uma mensagem educada com as entradas relevantes do arquivo de log (remova todas as informações particulares) e peça para que tomem medidas contra o host infrator.

JRW
fonte
4
Costumávamos fazer isso. No entanto, a quantidade de tempo gasto versus o benefício recebido foi tão pequena que não importa.
NotMe
1
Uma variante dessa tática que é mais eficaz, mas muito mais arriscada, é relatar o ISP ao nó intermediário. Mas você DEVE ter evidências de seu relatório sólidas. Certa vez, fiz um ISP com sérios problemas, porque eles estavam ignorando seus relatórios de abuso.
staticsan
1
Uma vez que fiz isso, a mensagem de abuso chegou ao hacker, em vez de alguém encarregado dos servidores. Desde então, não me incomodo mais, apenas muitos problemas.
wump
Isso realmente não vai ajudar na maioria dos casos e pode ser demorado
RichVel
4

Eu recomendaria não usar o fail2ban, mas executar o SSH (e outros) em uma porta não padrão. Não acredito em segurança pela obscuridade, mas acho que essa é uma excelente maneira de reduzir o ruído em seus logs.

Logins com falha em portas não padrão serão poucos e distantes entre si e também podem indicar ataques mais direcionados.

Você pode ir além e instalar um honeypot SSH, como o Kippo, para 'deixar entrar' os bruteforcers e ver o que eles fariam se tivesse a chance.

Andy Smith
fonte
Haha, Kippo parece muito legal. Vou instalá-lo em um servidor apenas para ver o que eles estão tentando fazer.
wump
4

Sim, é normal. O que digo aos clientes em sua situação com pequenos sites.

Esteja sempre preparado para ser hackeado.

Tenha uma cópia do seu site em um servidor de desenvolvimento. Essa pode ser a área de trabalho do Windows usando o XAMPP, que você pode obter gratuitamente.

SEMPRE faça alterações no seu servidor de desenvolvimento e depois faça o upload para o seu site ativo. Se for um CMS como o Wordpress, faça suas postagens no servidor dev e copie e cole-as no servidor ativo.

NUNCA baixe nada do seu site ativo para o servidor de desenvolvimento.

Monitore suas páginas da web regularmente quanto a alterações que você não fez. Especificamente, links ocultos para medicamentos ou produtos para aprimoramento. Você pode encontrar muitos suplementos e programas do navegador que farão isso por você.

Se você está comprometido. Notifique seu host, exclua tudo, altere todas as senhas e faça o upload do seu servidor de desenvolvimento limpo para o servidor da web agora vazio. Trabalhe com seu host para evitar uma recorrência.

Você não precisa de uma equipe de segurança para um site pequeno. Isso é o que seu host deve fornecer. Caso contrário, obtenha outro host que seja muito mais fácil de fazer quando você tiver um servidor de desenvolvimento, em vez de tentar mover o servidor ativo.

Espero que isto ajude.

J Litten
fonte
2
+1 em "Esteja sempre preparado para ser invadido".
User78940
3

Outra maneira de pará-lo (como eu pessoalmente não gosto de mover a porta SSH): decida se você pode listar todas as redes das quais você deseja logar e permita que elas acessem sua porta SSH.

As entradas WHOIS dos ISPs locais me ajudaram a reduzir os ataques para 1-2 tentativas de login por mês (naquela época, era cerca de 1k / dia). Eu os detectei usando denyhosts .

pesado
fonte
3

Além das outras excelentes sugestões que você já recebeu, também gosto de usar a diretiva AllowUsers, se apropriado para o servidor especificado. Isso permite que apenas usuários especificados efetuem login via SSH, o que reduz bastante a possibilidade de obter acesso por meio de uma conta de convidado / serviço / sistema configurada de maneira insegura.

Exemplo:

AllowUsers admin jsmith jdoe

A opção AllowUsers especifica e controla quais usuários podem acessar serviços ssh. Vários usuários podem ser especificados, separados por espaços.

Jay
fonte
3

Sim, é normal. Você pode :

  • Reduza a oportunidade de ataque usando fwknop

O Fwknop é uma das melhores implementações de porta-batida, porque não é falsificado e realmente se autentica, em vez de apenas autorizar uma conexão.

  • Você pode alterar a porta que o Openssh usa, mas não está realmente melhorando a segurança.

  • Fortaleça a autenticação ssh usando o Google-authenticator ou wikid

Isso protegerá ataques baseados em senha e a possibilidade de um determinado atacante / ataque direcionado comprometer sua máquina administrativa e roubar sua combinação de ssh-chave e senha.

Veja o mais recente comp pwn2own para ver como é fácil para um invasor comprometido sua caixa de administração totalmente corrigida.

Hilton D
fonte
1

Infelizmente isso é bastante normal. Você deve adicionar algo como fail2ban ao seu sistema para detectar e banir automaticamente os invasores. Se você ainda não o fez, também deve considerar o uso do ssh com chaves públicas e não permitir o login root sobre o ssh. Se usar ftp para transferir arquivos para o sistema, considere usar scp / sftp.

user619714
fonte
1

Implementei a porta batendo e tenho algumas análises por dia. Eles não têm conexão, então vão embora. Registro e relato todo o acesso às portas envolvidas.

Também executei o fail2ban com o Shorewall como um firewall para colocar temporariamente na lista negra de invasores persistentes.

Se você não precisar de acesso à Internet para SSH, desative-o. Se você possui alguns endereços conhecidos que precisam de acesso remoto, limite o acesso a esses endereços.

Limitar o acesso a chaves autorizadas também pode ser útil.

BillThor
fonte
0

Eu uso pam_abla lista negra temporária de forçadores brutos, e funciona muito bem. Eu acho que é melhor ter autorização no PAM usando seu próprio banco de dados, em vez de depender de hosts.denyou iptables.

Outra vantagem é que pam_ablnão depende da verificação dos arquivos de log.

Christoffer Hammarström
fonte
0

É completamente normal nos dias de hoje.
Você pode configurar o limite de "burst" no firewall para novas conexões de entrada na porta SSH
ou instalar um dos muitos analisadores de log a'la fail2ban ou alterar a porta SSH;).

O último é o mais fácil. Em máquinas carregadas pesadas, essas tentativas de amaciamento podem ter uma influência muito ruim em todo o sistema.

-
Atenciosamente,
Robert

Robert
fonte
0

Sim, é normal.

Acabei de alterar a porta ssh do padrão 22. Meu servidor, minhas regras :) basta editar / etc / ssh / sshd_config, alterar a porta e reiniciar o serviço. O único lado negativo é que você deve se lembrar de incluir essa porta na configuração de todos os clientes ssh que você usa.

John
fonte
0
  • Desabilite o login root (em todos os usuários root do sistema linux, para que os bots possam adivinhar com facilidade o nome do usuário).

  • alterar a porta padrão de 22

  • Permitir acesso ssh somente de ip conhecidos

  • Use uma senha alfanumérica forte para o usuário com acesso ssh

Kevin Parker
fonte