cunt
Why the obscenity?
Like, for example "Source?"
If I disagree with one or more points in a post but would appreciate evidence to the contrary, what is the appropriate way to reply to the other points without incorrectly implying that I agree with the points with which I actually disagree?
For most everybody, individuals and businesses, there is no reason whatsoever to allow Chinese traffic. Ditto Russian, Ukrainian, Brazilian, etc.
If PhilsHobbyShop.com were to block all traffic from BRIC and Ukraine, even ports 443 (HTTPS) and 80 (HTTP), customers in those countries would choose one of Phil's Hobby Shop's competitors. And even if you're referring to blocking SSH and HTTPS administration interfaces and not blocking HTTPS customer interfaces, that still means all the other server technicians need to reconfigure the server every time a technician takes an international vacation (during which he's theoretically always on call for emergencies).
You
I was referring not to my own situation but to the situations of others.
don't have the luxury of an always-on box at home, aka a "server"?
Not everybody has the luxury of an unlimited electricity budget to keep a box at home from going to sleep after 30 minutes of lack of input.
Seriously, any old piece of crap system will work and you can use the free dyndns.com service to keep the IP resolvable to static hostname.
But will the SSH server implementing a default deny policy know to check the free dyndns.com service to see which IP addresses are allowed to connect? If so, all you've done is added the length of your dyndns.com account's password to your SSH password. And the last time I used a free service similar to dyndns.com, I got a monthly e-mail asking me to click through and solve a CAPTCHA within the next seven days to keep the name active.
Also, I've never had an ISP block any incoming ports other than port 80 or 25.
Not everybody has the luxury of a home ISP that allows 60,000+ different incoming ports. Some ISPs don't even give home customers a dynamic IPv4 address; all outgoing connections pass through a carrier-grade NAT, and all incoming connections are refused.
I'm not sure where your Web access brainstorm comes from but it has no place in a security strategy of default deny. Default deny is very very simple. Either you are a trusted IP or you aren't.
The web access part is the interface to specify which IPs are trusted IPs at the moment and which aren't.
I always have my home server available on a fixed IP
Not everybody has the luxury of 1. a home server and 2. an ISP TOS that allows a home server. And even in your case, all you've done is added the length of your home server's password to your SSH password.
Don't most people use attempt limits now?
See replies to macbeth66's post asking the same question.
An attacker can only try logging in a few times a minute.
How does your system determine which IP addresses belong to a particular attacker's botnet?
Then only allow the IPs you want to connect.
So how do you predict the IP address of the machines from which you will be connecting in advance? If you expose a web interface to edit the list of allowed IP addresses so that you can connect from an additional IP address, all you've done is added the length of that web interface's password to your SSH password.
Denyhosts/fail2ban is a much better solution.
Not if the brute force attempts are distributed across thousands of different
Typically server hosting with ipv6 will assign a
Which would require you to switch to a hosting provider with IPv6 and move your own home or office to an area whose ISP offers IPv6.
You lock up an account after a few password failures.
Which opens up a denial of service opportunity for anyone who can guess the primary administrators' usernames: the botnet could log in with an incorrect password several times to lock out the legit user. Cue a truck roll to reset the lockout.
Kleeneness is next to Godelness.
