From Marcus’s talk:

1. Q: What does a packet filter do? A: Looks at a few parts of packet headers and decides if it is bad. If it is, it drops it.
2. Q: What does a stateful firewall do? A: Looks at a more of a packet and decides if it’s bad. It uses the loose concept of “state” to help it. If it’s deemed inappropriate, it gets discarded.
3. Q: What does an IDS do? A: Looks at a bunch of stuff in the packet and decides if it’s bad or not based on signatures and/or some heuristics. If it’s bad, it notifies you.
4. Q: What does an IPS do? A: Looks at a bunch of stuff in the packet and decides if it’s bad or not based on signatures and/or some heuristics. If it’s bad, it drops the traffic and/or notifies you.

Marcus went on to ask: what’s the difference between these supposedly fundamentally different technologies? The answer was clear — not much. They’re all doing some sort of detection and then performing an action based on the result.

(Here I’m going off on my own tangent so I’ll leave Marcus out of this)

So, ultimately there’s very little difference between a rudimentary packet filter from 10 years ago and a modern IPS. I see all these devices becoming one; I think a good name would be a “Security Check Point”, or a security “Gateway”.

The point is that in the future you won’t have to isolate these different technologies. You’ll just lay down a diagram of your environment and decide where you want filtering. Virtually every device on your network will be able to do all of these functions. All the way from the border router to the workstation.

This is the next evolution in the security space, I think. It’s even more advanced than NAC. Essentially, all pivot points and end hosts in the enterprise are part of the collective. The SIM/SEM functions as the brain. If there are performance issues then one type of security or another can be disabled on various pivots as needed, but in general all pivots will be able to perform all functions.

When an incident occurs, the system will simply isolate the problem by implementing ACLs on the nearest pivot point. If it wanted to, it could even push security information down to all other systems in the enterprise. To the security system, routers, firewalls, workstations, servers — they’re all the same. They’re just security nodes with various properties. Imagine object-oriented programming.

Using this model a security engineer could look at their network and simply assign logical security zones based on trust. The software would do the rest. The hardware at that point becomes transparent. It’s just carrying out the conceptual wishes of the engineer. I imagine an interface like the one in Minority Report, with a large view of the network infrastructure being displayed:

These here are all trust level 3… (dragging and dropping with arm motions). This here is a priority filter (points at a central hub, holds, and selects from a dynamic context menu). Trust level 0 resides here (pointing at a cluster of server nodes). All surrounding filters move to sensitivity 9 and associate reporting procedures with the existing standard.

So basically, you design how you want it to work, and the devices just make it happen. There’s no need for this kind of firewall or that kind of IDS — all security devices will merge into one — with each of them being able to do all filtering. The only reason they were separate was because they came into existence independently and there were performance issues. As these issues fade away there will be no reason whatsover to keep their functions separate.

Anyway, just a few thoughts…

For those who are into this sort of thing, the idea is very simple. China blocks people from going to certain sites by having their firewall kill browser sessions that contain certain banned keywords.

This particular security technique is based on sitting in between the users and the Internet, monitoring for banned words at the firewall, and then sending “kill packets” to the client when they ask for something China doesn’t want them to see. These “kill packets” (RSTs) tell the requesting computer to drop the connection immediately, which results in the user not getting the page they were looking for. Simple enough.

Unfortunately for China, it’s fairly trivial to drop various types of packets using a firewall on the client side.

In other words, the entire content filtering system is based on client systems receiving and responding normally to the firewall’s kill packets. If the client simply drops those packets, i.e. ignores them, then their session will continue on as if there were no filtering device in place at all.

And to make it even cooler, one can use TTL values to determine which RST packets are probably legitimately coming from the endpoint, and which are coming from a security device in the middle. So one could say, for example, “Drop all incoming packets with the RST flag set that have a TTL less than x.”

Of course, the firewall admin could exploit that rule by increasing the TTL on their outgoing RSTs, but then one could simply open up the rule and drop all RSTs. Cat and mouse, as usual.

Anyway, the idea’s quite interesting and it’ll be fun to see how it plays out.

http://edge.i-hacked.com/firewalls-ready-to-go-with-vmware-virtual-machines

If you’re a security geek, like many of my friends are, this is very exciting. Check it out:

http://www.nufw.org/