System Administration

If You Can't See It, It Can't See You

A few days back, Scott Mace, referring to a Gartner report on deep packet inspection, makes some comments about the network's edge, in the sense that firewalls redefine what the end-points are. Well, yeah, but his comments are confusing:

[T]he edge is creeping closer to the nodes originating the service or providing the client.

Isn't that the functional definition of the edge, those nodes? His conclusion, that service must move out of the network itself, is the end-to-end model.

Brett Morgan points out that some Aussie students routed around firewall-based service degradation by encrypting their packets. I mentioned the same thing in June after reading an article trying to sell content inspection as a means of differentiating service levels: You can't inspect the content if you can't read it. Think of a border guard charged with keeping subversive content out of the country: if he can't read German, how can he tell the difference between Mein Kampf and Das Kapital?

In its conclusion, Gartner states,

Web services will force perimeter defenses to be more aware of what types of traffic they allow to access the network via port 80 as code, such as SOAP elements, and control messages, such as XML statements. Firewall vendors must offer solutions that can control this traffic.

The perimeter cannot defend against these attacks without knowing what's inside the perimeter. Without that, the perimeter device cannot predict what effect a particular SOAP message might have. What the perimeter device can defend against would be known attacks on flaws in the infrastructure. Though it may be able to identify attempts at buffer overflows and such, doing so will require application developers to think about the size of the messages they are passing — and that's highly unlikely.

Effective security balances usability with stumbling blocks. If the security precautions make things too unusable, then 1) they will impair the work that was meant to be done in the first place, and 2) the users will ignore them.

11:21:01 AM # Google It!
categories: Industry, Security, System Administration

Package Manglement

Matt Croydon points to an OSNews article on Autopackage. I hadn't heard of that one before. Package management is one of those things that is reinvented over and over and over again. I'd like some incremental improvement in this area that doesn't require us to throw out existing systems just to get the nifty features.

The problem with most of the package systems I've seen is that they assume that you'll use only them; they are monolithic. In a heterogenous environment, even a POSIX-compliant one, that's an invalid assumption. Some packages will be installed by simple copying of the binaries. And then there are the OS vendors themselves, who insist on changing things without notice.

So what to do? I have a fantasy of a build farm that takes source from the repository, compiles it for a particular target platform, makes a vendor-specific package, then installs it on the host. Sounds like the BSD ports system, doesn't it? There's a significant difference in that my fantasy inserts one step: make a vendor-specific package, including Microsoft Installer files.

But like I said, it's a fantasy, perhaps a masochistic one.

10:01:20 AM # Google It!
categories: System Administration