On Thu, Feb 21, 2013 at 11:47:44AM -0600, Naslund, Steve wrote: [a number of very good points ] Geoblocking, like passive OS fingerprinting (another technique that reduces attack surface as measured along one axis but can be defeated by a reasonably clueful attacker), doesn't really solve problems, per se. If you have a web app that's vulnerable to SQL injection attacks, then it's still just as hackable -- all the attacker has to do is try from somewhere else, from something else. But... 1. It raises the bar. And it cuts down on the noise, which is one of the security meta-problems we face: our logs capture so much cruft, so many instances of attacks and abuse and mistakes and misconfigurations and malfunctions, that we struggle to understand what they're trying to tell us. That problem is so bad that there's an entire subindustry built around the task of trying to reduce what's in the logs to something that a human brain can process in finite time. Mountains of time and wads of cash have been spent on the thorny problems that arise when we try to figure out what to pay attention to and what to ignore... and we still screw it up. Often. So even if the *only* effect of doing so is to shrink the size of the logs: that's a win. (And used judiciously, it can be a HUGE win, as in "several orders of magnitude".) So if your security guy is as busy as you say...maybe this would be a good idea. And let me note in passing that by raising the bar, it ensures that you're faced with a somewhat higher class of attacker. It's one thing to be hacked by a competent, diligent adversary who wields their tools with rapier-like precision; it's another to be owned by a script kiddie who has no idea what they're doing and doesn't even read the language your assets are using. That's just embarassing. 2. Outbound blocks work too, y'know. Does anybody in your marketing department need to reach Elbonia? If not, then why are you allowing packets from that group's desktops to go there? Because either (a) it's someone doing something they shouldn't or (b) it's something doing something it shouldn't, as in a bot trying to phone home or a data exfiltration attack or something else unpleasant. So if there's no business need for that group to exchange packets with Elbonia or any of 82 other countries, why *aren't* you blocking that? 3. Yes, this can turn into a moderate-sized matrix of inbound and outbound rules. That's why make(1) and similar tools are your friends, because they'll let you manage this without needing to resort to scotch by 9:30 AM. And yes, sometimes things will break (because something's changed) -- but the brokeness is the best kind of brokeness: obvious, deterministic, repeatable, fixable. It's not hard. But it does require that you actually know what your own systems are doing and why. 4. "We were hacked from China" is wearing awfully damn thin as the feeble whining excuse of people who should have bidirectionally firewalled out China from their corporate infrastructure (note: not necessarily their public-facing servers) years ago. And "our data was exfiltrated to Elbonia" is getting thin as an excuse too: if you do not have an organizational need to allow outbound network traffic to Elbonia, then why the hell are you letting so much as a single packet go there? Like I said: at least make them work for it. A little. Instead of doing profoundly idiotic things like the NYTimes (e.g., "infrastructure reachable from the planet", "using M$ software", "actually believing that anti-virus software will work despite a quarter-century of uninterrupted failure", etc.). That's not making them work for it: that's inviting them in, rolling out the red carpet, and handing them celebratory champagne. ---rsk