"Dave Hull" <dphull@insipid.com> 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.