Jeremy Chadwick написав(ла):
The above looks like sshguard.
Yes, several people have pointed this out. Thanks!
I've personally never trusted something that *automatically* adjusts firewall
rules based on data read from text
logs or packets coming in off the Internet. The risks involved are insanely
high.
An IP participating in a detected attack like this one, may also be the
source of another problem, which may not be detected... I can't afford
to monitor this system at all times, hence the reliance on automatic
defenses -- better to crash/reboot than be taken over...
Stop for a moment and think what would happen to your box if a
distributed brute-force attack (e.g. 300,000 different IPs) was launched
against it; someone executing 20-30 SSH login attempts per IP. I'm
willing to bet adding 300,000 individual ipfw entries would cause some
serious havok on your machine (speculative: exhausted kernel memory, or
at a bare minimum, exhaust the number of remaining ipfw rule entries)
Yes, this is something I'm suspecting happening. But should not there be
some frantic messages, when the system is getting closer to this point?
There is nothing in the logs...
Surely you don't have that many users who SSH into the NAT router from
random public IPs all over the world, rather than via the LAN? Surely
if you yourself often SSH into your NAT router from a Blackberry device,
that you wouldn't have much of a problem adding a /19 to the allow list.
That's a hell of a lot better than allowing 0/0 and denying individual
/32s.
Myself -- and the owner of the box -- travel quite a bit, ssh-ing "home"
from anywhere in the world. Although we could, I suppose, find out the
destination-country's IP-allocation and add it before leaving, that
would be quite tedious to manage...
A different approach: consider putting sshd on a different port, rather
than the default of 22. A lot of people I know do this, solely to
decrease the number of brute-force attempts you see above; I've never
seen any of those brute-force attacking programs portscan, then attack
against a port which returns a OpenSSH string.
That's sounds kinda lame -- and temporary... Like buying an SUV to be
higher (and heavier) than other cars, this only works, until everyone
has an SUV :-) Once enough people move their sshd to different ports,
the next release of the ssh-attack will be doing the portscanning, no
doubt... Essential liberty vs. temporary security and all that :)
Finally, consider moving to pf instead, if you really feel ipfw is
what's causing your machine to crash. You might be pleasantly surprised
by the syntax, and overall administrative usability (it is significantly
superior to ipfw, IMHO).
Thanks for the suggestion... But would this solve the suspected problems
with kernel memory exhaustion, etc.? Whatever the firewall method, it
still needs to keep the rules memorized somewhere...
Yours,
-mi
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
