"Dave Hull" [email protected] wrote:
Another was, if you're writing code that's going to take user input, it is
often
repeated in secure programming literature that you should check the user
input
and make sure it's sane, that it fits your application. It is assumed that
you
That's not just 'secure' programming, but 'sane' programming. It is a maxim of the military that "No plan survives contact with the enemy." As a technical support veteran, I have formulated the analogous "No software survives contact with the user". Yes, it's a bit hyperbolic, but I've seen enough of what end users do to know that the proverbial Million Monkeys have a long way to go.
Shouldn't this same idea apply to services on your system? Say you want to
offer
SSH. Unless you're an ISP or something, you shouldn't need to offer SSH
access
to any address anywhere. You know what IP ranges you generally operate
from,
set your firewall to allow access from IPs within those ranges and deny everything else.
The problem with that one is 'generally'. You never know when an ISP will change the IP range that you use in a location, and you also never know when you're going to be somewhere else and need to get in.
It might be better to have an extra layer of security for an IP outside that range. For instance, you might have it challenge the user to enter some special password (or just su to root to run a command that validates the session) and if that fails, dump them before they can do anything else.