FreeBSD 8.0 “Watchdog Timeout” dropa conexão ethernet

3

Recentemente minha caixa FreeBSD 8.0 (GENERIC) foi atingida com uma grande quantidade de pedidos de um IP em Taiwan, tentando adivinhar senhas e todas essas coisas. De qualquer forma, resumindo a história, notei que em certo ponto não consegui entrar na caixa. Depois de fazer o login diretamente, notei um número enorme de palpites de senha e a mensagem msk0: watchdog timeout . msk0 referindo-se à minha conexão ethernet com fio.

Eu trouxe a interface de volta com ifconfig msk0 up e consegui fazer o ping com sucesso no endereço dessa interface. No entanto, ao tentar executar o ping no meu roteador principal, ao qual a caixa está diretamente conectada, ele desligou. A tentativa de pingar meu endereço IP externo retornou um monte de sendto: no buffer space available .

O problema foi resolvido com uma reinicialização, mas obviamente essa não é a maneira ideal de fazer isso. No caso de algo como isso acontecer novamente, quais etapas devo seguir para restaurar a conectividade? Eu li que às vezes isso pode ser evitado com watchdog -t 0 , mas não tenho certeza se quero ir por esse caminho.

Quando se trata de profilaxia, existe uma maneira de recusar conexões de IPs que possuem um determinado número de logins com falha por um determinado período de tempo? Por exemplo, 15 logons com falha resultariam em conexões recusadas para as próximas doze horas?

    
por JBirch 15.08.2010 / 15:34

2 respostas

2

Eu não sei sobre chips que o msk0 suporta; mas eu vi problemas semelhantes em muitos outros cards / chips / drivers. 99,9% do tempo é uma implementação de firmware com bugs (geralmente devido à fabricação barata) que não manipula corretamente o (s) timer (s) do watchdog.

Além disso, esse é um chip da Marvel, e a Marvel não é amigável ao código aberto; poderia ser um problema com o próprio driver. De qualquer forma, o melhor lugar para começar é a parte inferior da página do manual sobre a solução de problemas de NICs .

Eu tive meu quinhão desse tipo de problema; Eu encontrei a solução mais fácil é mudar para NICs mais caras (embora você pode encontrar os mais antigos no eBay por quase nada; minha primeira escolha para equipamentos domésticos).

Se a solução de problemas não resolver o problema, há mais especialistas em solução de problemas nos fóruns do FreeBSD .

    
por 15.08.2010 / 16:24
4

Senti falta da última parte da sua pergunta com a minha outra resposta, por isso vou adicioná-la aqui rapidamente.

Eu uso e recomendo a todos com um servidor * nix voltado para o público: Fail2Ban

Está na árvore de ports sob segurança / py-fail2ban, então é fácil começar.
Depois que ele for aberto, abra /usr/local/etc/fail2ban/jails.local no seu editor favorito. Aqui está um início rápido se você usar o IPFW. Se você usar pf, seria um pouco diferente.

[DEFAULT]
maxretry = 10

[auth-bsd-ipfw]
enabled  = true
filter   = bsd-sshd
action   = bsd-ipfw
logpath  = /var/log/auth.log

Ative o serviço echo 'fail2ban_enable="YES"' >> /etc/rc.conf e inicie-o /usr/local/etc/rc.d/fail2ban start

Monitore o conteúdo da tabela 1 no IPFW por um tempo para ter certeza de que você não ficará trancado com ipfw table 1 list . Quando estiver funcionando como esperado, adicione uma regra de firewall para bloquear os IPs na tabela 1: ipfw add 00030 deny ip from "table(1)" to me . Certifique-se de adicionar isso ao seu conjunto de regras de inicialização, para que ele seja carregado na reinicialização.

O Fail2Ban pode ser usado para monitorar praticamente qualquer arquivo de log. A maioria dos serviços já registra logins com falha em um arquivo de log e a maioria dos outros pode ser feita para; e há muitos exemplos encontrados pelo Google também (ou perguntando aqui).

    
por 15.08.2010 / 23:45