On Thu, Feb 21, 2013 at 01:34:13AM +0000, Warren Bailey wrote:

I can't help but wonder what would happen if US Corporations simply blocked all inbound Chinese traffic. Sure it would hurt their business, but imagine what the Chinese people would do in response.

Would it hurt their business? Really? Well, if they're eBay, probably. If they're Joe's Fill Dirt and Croissants in Omaha, then probably not, because nobody, NOBODY in China is ever actually going to purchase a truckload of dirt or a tasty croissant from Joe. So would it actually matter if they couldn't get to Joe's web site or Joe's mail server or especially Joe's VPN server? Probably not. Nobody in Peru, Egypt, or Romania is likely to be buying from Joe any time soon either. This is why I've been using geoblocking at the network and host levels for over a decade, and it works. But it does require that you make an effort to study and understand your own traffic patterns as well as your organizational requirements. [1] I use it on a country-by-country basis (thank you ipdeny.com) and on a service-by-service basis: a particular host might allow http from anywhere, but ssh only from the country it's in. I also deny selected networks access to selected services, e.g., Amazon's cloud doesn't get access to port 25 because of the non-stop spam and Amazon's refusal to do anything about it. Anything on the Spamhaus DROP or EDROP lists (thank you Spamhaus) is not part of my view of the Internet. And so on. Combined, all this achieves lossless compression of abusive traffic. This is not a security fix, per se; any services that are vulnerable are still vulnerable. But it does cut down on the attack surface as measured along one axis, which in turn reduces the scope of some problems and renders them more tractable to other approaches. An even better approach, when appropriate, is to block everything and then only enable access selectively. This is a particularly good idea when defending things like ssh. Do you *really* need to allow incoming ssh from the entire planet? Or could "the US, Canada, the UK and Germany" suffice? If so, then why aren't you enforcing that? Do you really think it's a good idea to give someone with a 15-million member global botnet 3 or 5 or 10 brute-force attempts *per bot* before fail2ban or similar kicks in? I don't. I think 0 attempts per most bots is a much better idea. Let 'em eat packet drops while they try to figure out which subset of bots can even *reach* your ssh server. Which brings me to the NYTimes, and the alleged hacking by the Chinese. Why, given that the NYTimes apparently handed wads of cash over to various consulting firms, did none of those firms get the NYTimes to make a first-order attempt at solving this problem? Why in the world was anything in their corporate infrastructure accessible from the 2410 networks and 143,067,136 IP addresses in China? Who signed off on THAT? (Yes, yes, I *know* that the NYTimes has staff there, some permanently and some transiently. A one-off solution crafted for this use case would suffice. I've done it. It's not hard. And I doubt that it would need to work for more than, what, a few dozen of the NYTimes' 7500 employees? Clone and customize for Rio, Paris, Moscow, and other locations. This isn't hard either. Oh, and lock it out of everything that a field reporter/editor/photographer doesn't need, e.g., there is absolutely no way someone coming in through one of those should be able to reach the subscriber database.) Two more notes: first, blocking inbound traffic is usually not enough. Blocks should almost always be bidirectional. [2] This is especially important for things like the DROP/EDROP lists, because then spam payloads, phishes, malware, etc. won't be able to phone home quite so readily, and while your users will still be able to click on links that lead to bad things...they won't get there. Second, this may sound complex. It's not. I handle my needs with make, rsync, a little shell, a little perl, and other similar tools, but clearly you could do the same thing with any system configuration management setup. And with proper logging, it's not hard to discover the mistakes and edge cases, to apply suitable fixes and temporary point exceptions, and so on. ---rsk [1] 'Now, your typical IT executive, when I discuss this concept with him or her, will stand up and say something like, "That sounds great, but our enterprise network is really complicated. Knowing about all the different apps that we rely on would be impossible! What you're saying sounds reasonable until you think about it and realize how absurd it is!" To which I respond, "How can you call yourself a 'Chief Technology Officer' if you have no idea what your technology is doing?" A CTO isn't going to know detail about every application on the network, but if you haven't got a vague idea what's going on it's impossible to do capacity planning, disaster planning, security planning, or virtually any of the things in a CTO's charter.' --- Marcus Ranum [2] "We were so concerned with getting out that we never stopped to consider what we might be letting in, until it was too late." Let's see who recognizes that one. ;-) ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE