Now it’s Java properties.

I say once again - the last thing to do is to extend the language. Before that try a new API or have your IDE do it. In the case of Java properties I really don’t see any reason whatsoever for this being in the language as it’s blatantly something that can be done in the IDE plenty well enough. That just leaves a couple of arguments:

1. More readable - I can understand perfectly well from the method name what set* and get* do, surely I’m not the only one?
2. Reduces boilerplate - Indirecting through a method allows more flexibility and a modern IDE can fold these things away so we don’t have to see them. Finally, some boilerplate actually makes code more explicit and therefore more easily understood which is far more important.

Elliotte and others already have the rest of the reasoning nailed so I’m not wasting any more breath.

Common practice these days is to have a firewall between corporate’dom and the internet and only open port 80. It’s claimed this is secure but is it and what is this approach costing us? And is the price worth paying?

We tend to argue against open ports at the firewall for two reasons:

1. Denial Of Service Attacks
2. Hacks

Denial Of Service Attacks

The mere act of opening a port leaves one open to such attacks. The difficult bit is having access to sufficient resources with which to attack the target. This drives some to look for more sophisticated attacks that don’t require a “stampeding herd” of machines but there are very few of these people because:

1. You have to be expert
2. You have to have lots of time

In conclusion, denial of service attacks are a part of being on the net and firewalls help very little in this regard. What’s really needed is intrusion detection software and dynamic response/adaption something the firewall doesn’t facilitate.

Hacks

The reason a hack works at all is because it exploits some weakness in some service somewhere. But these weaknesses vary by OS, machine and software version. Blocking everything at the firewall works but really and truthfully we should:

1. Keep our machines up to date
2. Manage this machine by machine because they each have different needs and services

How Secure Are We?

Given the above we can see that boundary firewalls actually provide little effective protection against attack because to provide service, we must open the firewall and as soon as we do it, the hoardes can rush in. Certainly a firewall can stop certain kinds of packet spoofing, remote login etc but we don’t need to close all ports to achieve this goal.

In summary, firewalls are hammers and we are attempting to treat all security issues as nails to beat on.

The Cost of the “No open ports” Strategy

Because port 80 is the only one open, we are seeing everything tunnelled via http. This leads to a whole series of complications:

1. Not everything we would like to use has support for tunnelling over http
2. http is not suitable for all applications, it can be made to work but it’s complex and fragile
3. Given that all traffic looks like http it is difficult to manage/monitor traffic for individual services
4. Multplexing and demultiplexing all this network traffic manifests in our architectures - e.g. configuring our front-line httpd’s to redirect traffic based on URL components

Connection building in certain directions is impossible in most cases which denies us architectural options:

1. Callbacks are not viable - leading us to deploy polling solutions which perform badly and prevent us from building solutions that offer timely updates
2. Protocols other than http cannot be used

The border firewall becomes a point of contention trying to serve conflicting policies for individual services. Changes to the policy are slow owing to the need for agreement from so many parties or, in the worst case, no change happens at all.

We Really Need to Change

Firewalls as they are typically used are the software equivalent of a “Maginot Line” and history is littered with examples of failed border-control policy such that the military at least have learnt that defense in depth is a more appropriate solution. The “Maginot Line philosophy” denies us various software architecture options that would make our systems less complex and more scalable.

Certain elements might argue that all of this should lead us to base our services solely on the web architecture but that denies us certain kinds of desirable abstraction such that we expend lots of effort close to the metal attempting to force our solutions into a single generic approach. This would be somewhat akin to the pain we suffer trying to tunnel everything over http, not good.

Amazon’s EC2 provides some interesting possibilities in that it provides a more flexible firewall policy than straight border control and perhaps the most significant aspect of EC2 is that the firewall configuration can be controlled programmatically thus it would be possible for a service to configure the firewall to suit it’s needs on demand. If nothing else, such an option can speed up deployment removing the need to fiddle with http tunnelling and de-multiplexing or to discuss policy with a centralized admin authority.

In conclusion, we need to look at changing our policy and other approaches such as providing infrastructure that can secure individual services with appropriate policies from machine through to software level. Much of our current software infrastructure has little support for such a strategy and will need to change but surely it will be for the better?

Technorati Tags: architecture, distributed systems, technology

• Creating Passionate Users: Sensemaking 3:The search for a representation
  (tags: management productivity psychology)