3

Recently my FreeBSD 8.0 (GENERIC) box was hit with a large amount of requests from an IP in Taiwan, trying to guess passwords and all of that stuff. Anyway, long story short, I noticed at a certain point I couldn't ssh into the box. After logging in directly, I noticed a huge number of password guesses, and the message msk0: watchdog timeout. msk0 referring to my wired ethernet connection.

I brought the interface back up with ifconfig msk0 up, and was successfully able to ping the address of that interface. However, when trying to ping my main router, which the box is directly connected to, it hung. Attempting to ping my external IP address returned a whole bunch of sendto: no buffer space available.

The problem was resolved with a reboot, but obviously this isn't the ideal way to go about it. In the case of something like this happening again, what steps should I take to restore connectivity? I've read that sometimes it can be prevented with watchdog -t 0, but I'm not sure I want to go down that avenue.

When it comes to prophylaxis, is there a way to refuse connections from IPs that have a certain number of failed logins for a certain period of time? For example, 15 failed logons would result in refused connections for the next twelve hours?

JBirch
  • 175
  • 2
  • 8
  • It might be an idea to split your last paragraph into a separate question, as it may receive more answers that way. – hmallett Aug 15 '10 at 15:02
  • That's a very good point hmallet. It was tacked on as an afterthought; I imagine documentation for that is much more obvious, and I might even find the answer with a few well thought out `man -k` choices. I'll probably take your advice if I cannot find the information myself :) – JBirch Aug 15 '10 at 15:10

2 Answers2

4

I missed the last part of your question with my other answer, so I'll add it here quick.

I use and highly recommend to everyone with a public facing *nix server: Fail2Ban

It's in the ports tree under security/py-fail2ban, so it's easy to get started.
After it's built open /usr/local/etc/fail2ban/jails.local in your favorite editor. Here's a quick start if you use IPFW. If you use pf it would be slightly different.

[DEFAULT]
maxretry = 10

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

Enable the service echo 'fail2ban_enable="YES"' >> /etc/rc.conf and start it /usr/local/etc/rc.d/fail2ban start

Monitor the contents of table 1 in IPFW for a while to be sure you're not going to lock yourself out with ipfw table 1 list. Once it's working as expected add a firewall rule to block IPs in table 1: ipfw add 00030 deny ip from "table(1)" to me. Be sure to add this to your start-up ruleset so it's loaded on reboot.

Fail2Ban can be used to monitor just about any log file. Most services already log failed logins to a log file, and most others can be made to; and there's plenty of examples found via Google too (or asking here).

Community
  • 1
Chris S
  • 77,337
  • 11
  • 120
  • 212
2

I don't know about chips that msk0 supports; but I've seen similar problems on a lot of other cards/chips/drivers. 99.9% of the time it's a buggy firmware implementation (usually due cheap manufacturing) not handling the watchdog timer(s) correctly.

Additionally, that's a Marvel chip, and Marvel has not been open source friendly; it could be a problem with the driver itself. Either way the best place to start is the bottom of the Handbook page on Troubleshooting NICs.

I've had my fair share of these sorts of problem; I've found the easiest solution is to switch to more expensive NICs (though you can find older ones on eBay for next to nothing; my first choice for home equipment).

If the troubleshooting doesn't resolve the issue, there's more troubleshooting experts on the FreeBSD forums too.

Chris S
  • 77,337
  • 11
  • 120
  • 212
  • Thanks Chris! I appreciate an answer that's probably going to teach me a lot about the underlying implementation. I'm not against purchasing a NIC - it's only using the onboard (that is, on the motherboard) NIC at the moment. Which chips or manufacturers would you recommend for really robust support when it comes to drivers? – JBirch Aug 15 '10 at 14:40
  • msk has had quite a few changes since 8.0-RELEASE (have a look at http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/msk/if_msk.c). Updating to 8.1, or RELENG_* may help. On the other hand Intel and Broadcom NICs seem to work very well. – hmallett Aug 15 '10 at 15:04
  • Ah, those revisions are much more recent than what I'm using (I believe 8.0-RELEASE was in November or something). I'll try my hand at that first, and then try my other options. Great information! – JBirch Aug 15 '10 at 15:12
  • @JBirch, in your case I'd definitely try updating and troubleshooting before buying something; but you may find at some point that it's just not going to be reliable. If you do end up there, like hmallett said, the Intel, Broadcom, QLogic chips seem rock solid; I've also had good luck with Realtek (though the performance isn't the same; YGWYPF). Personally I'm a fan of the HP NC-Series cards; but there's plenty of others that work great too. I've had problems with Via, RaLink, and nVidia chips the most. – Chris S Aug 15 '10 at 21:29
  • Sound advice. I'm very appreciative :) – JBirch Aug 15 '10 at 21:53