To fairly analyze security impact by GCB on organizations using private network and/or firewall, we need to consider for what purposes organizations use firewalls/NATs and which of them are broken by GCB.
- IPv4 address shortage & easy network management
- Address concealment
- Block inbound connections
- Outbound connections are inherently securer than inbound ones
- Management can keep employees from running undesirable services
- Unprepared servers can be protected from attacks
- Block outbound connections
- Designate a few trusted applications and GCBnize them.
- Set your firewall/NAT so that no inbound connections are allowed and outbound connections only from those trusted applications are allowed.
- IDS & Logging
One of the most important reasons to use private networks is because IPv4 addresses are being sold out and private networks make network management easy. Obviously GCB has no adversary effect on this goal. In light of this purpose, inbound connections being blocked is a side-effect. GCB removes this undesirable side-effect.
Private network is considered somewhat secure because the addresses of hosts are hidden from outside. In GCB, private addresses are brought public at some level because some GCB commands contains private addresses. To handle this, the communication between client/server and GCB inagent must be secured. Unfortunately, GCB commands are transferred as not encrypted.
Organizations block inbound connections for many reasons. I believe that the followings are major reasons:
Outbound connections are generally considered securer than inbound ones because the former is more difficult to attack than the latter and because some attacks are only possible for servers. To attack a client, the bugler generally does IP spoofing and packet hijacking. On the other hand, some attacks toward servers can be easily done by IP spoofing alone. SYN-flooding is a popular example. GCB has no adversary effect here, because every connection is outbound!
By blocking inbound connections to arbitrary addresses, an organization can keep members from running undesirable or insecure services. Unfortunately, GCB defects this objective because undesirable softwares can also be GCBnized without organization's permission.
Maybe this is the biggest reason that organizations block inbound connections. Unlike clients, servers are generally wide-open to any client. There are many legacy servers not well prepared to attacks. By blocking inbound connections, those servers are protected from attacks launched outside the private or firewalled network.
Definitely GCB makes servers accessible from outside and this can introduce security problems. However, we must understand that there are two contending interests. One is to protect nodes from attacks by closing the door and the other is to collaborate with the world by opening the door. If an organization can sacrifice one for the other, the solution is easy. However, in most cases one goal must be achieved with the other sacrificed as little as possible.
I would claim that GCB is an optimal solution of this optimization problem for two reasons--sorry for not mathematically precise and correct. First, GCB opens the firewall/NAT only as much and as long as required. GCB invites inbound communications toward an address only if there is a GCBnized server listening on the address. Second, GCB opens the firewall/NAT in the most restrictive way. Note that the pinhole created by a packet traversing from the inside to the outside is the most restrictive in most firewalls/NATs. Only packets with the same sender and receiver's address get passed. For those two reasons, if we GCBnize only well-prepared servers so that attacker cannot exploit the access to those servers to attack other (non-GCBnized) servers in the network, non-GCBnized nodes and servers remain still safe. This is not true for the common practice that firewall/NAT is opened manually for a range of addresses. It is generally impossible to know in advance how long and what addresses a server will listen on. Therefore, administrator must open much more addresses than necessary and for much longer period. These extra opening can be exploited by buglers to attack innocent servers.
Outbound connections are blocked, though not common as inbound case, for similar reasons. Since GCB assumes that outbound connections are allowed, you cannot use GCB if the security policy of your network is so strict that this assumption is not true. However, you can still make your network very secure and open just as much as necessary by doing:
Firewall/NAT provides a chokepoint of network flow so that other protection systems such as anti-virus, logging, and Intrusion Detection System (IDS) can easily be placed. In GCB, every communication with outside (including GCB inagent) occurs through the firewall/NAT. Thus it has no effect on this goal.