Advanced Persistent Errata – Defending The Castle Part 1

Tuesday, February 23, 2010

Cross-Posted from the AEON Security Blog here:

Many security professionals have sent me irrate comments via e-mail like: “You’re insane! You can’t block China!”; “How long have you been in security! You can’t block a whole country!” These remarks come in response to my writings concerning “cyberwarfare“, “China” and similar themes. In today’s blog entry, I bring to you: “Advanced Persistent Errata – Defending The Castle;” in other words, “Blocking ANYONE you damn well choose to block.” Security managers will recognize some of these themes specifically as ISO27002 11.4.4, as well as other controls listed in ISO27002 (11.1.1, 11.4.1, 11.4.6, and don’t forget the mentions of ISO 18028-1:2006, ISO 18028-2:2006, ISO 18028-3:2005, ISO 18028-4:2005, ISO 18028-5:2006.) Enough about the numbering for now, as it can become headache inducing.

Far too many security professionals swear by their blood, sweat and tears that you cannot outright block entire countries, and they are incorrect; sort of. In order to prove a point, I will expound on what I mean when I post “such stupid comments” as “Block China… Duh!” Please keep in mind, this has nothing to do with China specifically, but more along the lines of using common sense, networking ingenuity, teamwork and security know-how. Rather than write an entire wiki-like entry on networking, security, ISMS systems, et al, I’m hoping that the reader has a decent grasp of networking, systems administration, security engineering and perhaps a little exposure to security architectures. For those looking for a more thorough understanding of ISMS systems, theories and standards themes, I recommend Keith Willet’s “Information Assurance Architecture” [1], and for those running Windows, I sincerely recommend Brian Honan’s “Implementing ISO27001 in a Windows® Environment.” [2]

Again, keeping away from re-writing books, this article assumes that a risk assessment and analysis, a business case analysis and security GAP assessments have been done, at least to some degree. For that, I suggest “Googling” around for variations of those terms. I now return to my irregularly scheduled programming: the technicalities. In order to achieve the creation, deployment and or restructuring of a strongly guarded and segmented infrastructure, one first needs a concise view of what their network is doing, what its objectives are, and what one needs to accomplish in order to keep the “visible” and “accessible” part of a company online. The two terms in relation to this writing need to be fully understood: Visibility, Accessibility.

Almost all businesses in this day and age are somehow interconnected to “something” and there are going to be portions of a company that may need to be both visible and accessible from the Internet. However, not everything will truly need to be connected; therefore, the remainder of your infrastructure should not be visible nor accessible from the world at any given point in time. There is a big difference between a network “having” access to portions of the world, than there are “portions of the world having access to that network.” I will explain this later. For now, I will assume (which I hate to do) that – you have some form of structured guide of what it is – your business needs to accomplish with regards to visibility and accessibility via the Internet.

Because networks are all different, I will attempt to explain this on a smaller scale in hopes that I can provide you with a more concise understanding of why you “CAN” block out anyone you please. The key here is to fully understand what one is doing and why one is doing it. Below is a broad example of four networks, consisting of three government entities and the Internet. We will call them: Example Government Network 1, Example Government Network 2 and, finally, Example Government Webservers 1. Three networks with three distinct objectives.  For the hardcore security and pentester crowd,  in a future entry, I will attempt to explain, dissect and defend against tunneling OUT. (Stay tuned)


Behind Example Government Network 1 is a staff dedicated to making sure that the country runs properly. Their needs are simple ones: access “TO” the Internet for browsing, access TO e-mail which resides off-site and perhaps access to another government network. There is no reason for anyone outside of the government spectrum to access this network, ever.

Behind Example Government Network 2 is a set of staff responsible for another task. Perhaps it’s the FTC, FCC, FBI, or NSA; it really doesn’t matter what agency or portion of the government it represents. What matters is that they too have accessibility to similar functions as Example Government Network 2. They may need to allow connections from other networks in the government arena.

Behind Example Government Webservers is a set of servers with information available to the public. Information, documentation and processes running here need to be accessible to the public at large. They may give users in the public space (the Internet) the ability to search for documents, register for services, etc.

As a network and/or security engineer, segmenting these networks is not a difficult task from the technical perspective. On an enterprise level, it may be time consuming, but the tradeoff in costs to implement – far outweighs the cost of a compromise. What often becomes difficult is determining who needs to interconnect with these servers and what types of information need to be placed on these servers. A huge problem with many businesses and government agencies is that, in the race to “go digital,” many overlooked security and other themes from the onset. Many administrators and engineers are often frustrated at having to “work miracles” to just keep them running, let alone having to continuously run around performing other miracles. For the “techies” it becomes similar to applying putty to any leaky pipes. The logical and correct solution however is to outright replace those pipes before they fully break.  One can argue the cost metrics until their faces turn blue, but these arguments and qualms often take away from actually accomplishing anything useful.

Since networks are often already exposed in some shape form or fashion, you’d need to document the obvious: who can access what; why and when they can do these accesses; and from where can they do it. I could speak of classification, truly ensuring that information stored on these servers has the proper classification types — for example, in the case of government agencies,  there should be no Top Secret, Secret, FOUO or other information disseminated on the publicly accessible servers (but an explanation of those controls would also be like writing a book). Instead, I’ll focus on a more granular view than that of a manager – acting as a “security liaison” of sorts. Think of this view as perhaps a mix between a security manager, a security/network architect and a security/network engineer.

The style of segmenting I refer to when I make my posts “is the proper method” that could be used to minimize the likelihood of an event where an attacker compromises a network from an outside source. In this model, routers, firewalls AND servers would be configured with appropriate configurations that would allow or disallow entire networks and/or services from being accessible.  In the cases of Example Government Networks 1 and 2, time based firewall rules can also be configured.  Let’s think about this on a logical level for a moment: “If no one is connected to or working on a specific machine inside any of those networks, should there be a reason that they allow either incoming or outgoing connections? Is there is a need for accessibility?” This is not a new concept. If no accessibility is needed, block all connectivity, in or out or specify who can access exactly what and from where.  Again, you CAN block anyone you choose to block.

This entire argument needs to come to the table between managers and administrators of systems, networks and software; however, far too often managers are capable of making horrible decisions. Many of these decisions are made by paper based designs.  For example, Mr. Willet’s book makes note of this using what he defines as IA CONOPS – or Information Assurance Concept of Operations. His description of it is: “A CONOPS takes an architecture and applies it conceptually to the organization. A CONOPS is a paper-based model of how the architecture will work in context of the enterprise business environment, technical environment, business processes, and overall culture.

Reality sinks in.  Many networks are already in place and many of these networks were horribly designed long before frameworks were available. Putting them in proper “security” order from this perspective is difficult. If I had to “re-invent the wheel” for an existing architecture, as an engineer, administrator or manager, I would be hard pressed to get the job done.  It would likely negatively impact the business, as there would surely be network, systems and application outages or flakiness.  This does not mean that it cannot be done, just understand that what I am suggesting – something along the lines of surgery. Carefully take existing applications, software and hardware and use them to their full potential. Many applications and hardware already HAVE the controls in place.  They’re simply not being used effectively. Often there is little need to add additional “firewalls, IPS’, IDS’, etc. ” into the mix. I say: use your brain.

Here is a real world example of “blocking anyone I damn well choose to block.” We offer managed VoIP services here at AEON. We also offer VoIP trunking at the carrier level. Think of us as an ITSP for other VoIP companies, or as a “Vonage for Vonage.” Because of the nature of how we interconnect with other carriers and providers, we have publicly available and accessible nodes. Because we also offer managed VoIP services – some would equate this to a “PBX in the Cloud” – we need to be extra vigilant against attacks such as brute force attacks on PBX’s, phishers and other VoIP based attacks. I have seen, analyzed and investigated quite a few of these attacks, and I have had the opportunity to discuss with other VoIP security professionals these themes on VOIPSA [3].

As a security engineer, my concern is the security of my systems that are publicly available. Because we are “global” in the sense that we have customers from all around the world, it would be absurd for me to block the world–right? No, wrong! Many of my systems outright block EVERYONE until I allow them in, yet my systems are still operational 24/7/365. I have customers in Asia, Europe, Africa, Latin America, and the list goes on. I worry little about ANY country period.

To go a step further, for the techies who may read this, here is a snippet of a brutally written shell script used on certain Linux based PBX’s to block countries:

#!/bin/sh site=http://bgp. potaroo. net/ipv4-stats/allocated- wget -qO - "$site"apnic.html|\ awk -F ">" '{print $2}'|sed 's:/:.0.0.0/:g'|\ awk '/./{print "iptables -A INPUT -s "$1" -p tcp --dport 22 -j DROP"}'|grep -v "<\|IPv4" wget -qO - "$site"lacnic.html|\ awk -F ">" '{print $2}'|sed 's:/:.0.0.0/:g'|\ awk '/./{print "iptables -A INPUT -s "$1" -p tcp --dport 22 -j DROP"}'|grep -v "<\|IPv4" wget -qO - "$site"ripe.html|\ awk -F ">" '{print $2}'|sed 's:/:.0.0.0/:g'|\ awk '/./{print "iptables -A INPUT -s "$1" -p tcp --dport 22 -j DROP"}'|grep -v "<\|IPv4" wget -qO - "$site"afrinic.html|\ awk -F ">" '{print $2}'|sed 's:/:.0.0.0/:g'|\ awk '/./{print "iptables -A INPUT -s "$1" -p tcp --dport 22 -j DROP"}'|grep -v "<\|Ipv4"

My oh my. Imagine that! Blocking not only Asian networks, but European networks, African networks and Latin American networks. Some nerve! Now mind you, this would not necessarily work on an enterprise network with hundreds, perhaps thousands of machines… Or would it? Surely it would, however it would need some tweaking. So take note of what is meant by “blocking” countries.

In the above snippet, I use the “always up-to-date” lists of KNOWN addresses for ALL countries and block them from accessing services on the server that the script runs on. These are used on top of my existing firewall rules on these machines, and don’t forget that a completely separate firewall does do other filtering. There is nothing that stops me from blocking MY servers from making OUTBOUND connections to other machines. For example, on the PBX’s themselves, I know what their role is, so I can outright block all outbound services anywhere and solely allow those I need to have access out. The same goes for the incoming services: block all inbound services anywhere and solely allow those I need to have access in. Remember, I do state here that these rules run on top of other rules. I’ve allowed in those whom I want in and EVERYONE else gets blocked.

Anyhow, this was a rather long and rambling. I will get back to more writings on blocking, designing, engineering, rambling, manager-fights in a future update. For now, however, I hope the “naysayers” understand that “can’t” should never be a word used when it comes to information technology. Especially when it comes to security. “You can’t block. . . !Nonsense. You CAN and you outright should. However, I thought a little clarity was needed to make my contentions more explicit. I hope this helped.


Possibly Related Articles:
Network Access Control Enterprise Security
Enterprise Security China Network Access Control
Post Rating I Like this!
Anthony M. Freed I agree - Protect the castle, or pay the price -Great post from Aeon!
Dennis Brixius Great article for the un-initiated with only one pet peeve of mine in the article.

Why in IT do we use "operational 24/7/365" -- is this to signify that we only do it for 7 years, like the itch -- it should be 24/365 or 24/7/52...