What Is the Future of Firewalls? 414
jlmale0 writes "When I mess with my WAP/router at home or coordinate with the network team at work, it seems like I'm stuck in 1995. We're still manually listing IP address/port combinations for our firewall rules. There's a certain simplicity to this when dealing with a single system, but there are firewalls everywhere these days. What's available for managing complex firewall arrangements? What's being developed? Can I take a Visio diagram, run it through a script, and get a list of firewall rules? What about a GUI that illustrates the current system configuration and then lets me drag and drop systems across firewalls, and have the individual firewall ports automatically configured? What about tying a firewall into an authentication system so that when jdoe logs in, only then are the firewalls opened to pass her traffic? What about managing distributed firewalls so that one repository of rules opens up your system's firewalls, the DMZ firewall, and the public firewall all at once? Let's get a conversation started. What cool projects do I need to know about? What cool management features would you like to see? What's next for firewall management?"
Re:Honestly? (Score:1, Informative)
low latency trading makes me sad.
Standardization is EXTREMELY difficult (Score:2, Informative)
In a star trek world people would work well together but the money is made coming up with the next biggest and best product meaning you beat our the competitors. Working together often eliminates that huge profit margin one gets when they have the "best" tech for "this need". Open Source solutions are often (not always) designed from this viewpoint that "A collaborative effort will result in an ideal product with the motivation being profit profit profit".
Add on top of that is that there are many things that drive technology. Some needs are speed, others are security, etc etc etc.
In my work for the our "data" is our life blood. If it's hacked, destroyed etc... we're screwed. We sell our information so while speed is often important... security is #1. If I was working for the stock exchange, security would come in second merely because time is ESSENTIAL. Security comes immediately after. Get the gist?
Now, when you're talking high level networking where you're dealing with thousands or even hundreds of thousands of connections simultaneously then you have to combine a mix of things.
This is where it makes it extremely difficult to make a program that does everything in simple man terms. That's why there are network administrators and architects. There are far too many variables to turn into a windows like gui where "Are you sure?" will cover it. Here's a small list of the variables you're going to encounter
- Size of network
- Location of all users (remote and local)
- Security requirements (government contracts often require certain levels)
- Company polices (do you need to have site filters for porn sites)
- What kind of filters will you use
- What kind of hardware is this all operating under
- Many routers run different flavors of linux where some commands are different (Cisco *cough*).
It pretty much comes down to... networking in the home is easy because it is simple. You're going to have X number of boxes connected wired or wirelessly to a single incoming connection. Easy.
However, in the real environment you may have 20+ connections coming in with complex equipment that routes and load balances those incoming and outgoing connections. If someone were create a piece of software for this it would need every single manufacturer of routing equipment to work together. That's just not going to happen.
So... the only common things that can happen are learning to write script once you've thought out your network and that's the easy part.
Re:Feature, not bug (Score:3, Informative)
Slow and stupid, though, are dangerous. Humans have a tendency to make stupid, sloppy errors. Anything that requires them to keep hundreds or thousands of complex details in mind brings out the worst in them, and causes stupid misconfigurations. Of course, any tool that allows an MBA to achieve stupid misconfigurations just by dragging objects around in a drool-proof GUI also causes stupid misconfigurations...
Trusted host or trusted user. (Score:1, Informative)
Some firewalls can be configured to allow based on user auth instead of source IP, which is a bit more useful for some situations. Restricted layer 7 proxies generally work this way, with the classic example being Gauntlet.
As a modern example, OpenBSD PF has the integrated pfauth mechanism where you authenticate with system as a user. When you login with ssh to the firewall, it dynamically loads a pre-configured ruleset appropriate to your profile, then drops them when the session is terminated.
This doesn't make configuration any simpler from your point of view, but PF overall makes configuration much simpler for those who understand firewalls.
Matasano Playbook (Score:1, Informative)
http://runplaybook.com/
Re:I, For one, (Score:5, Informative)
Actually on our network we've ended up installing personal firewalls AND boundary ones.
They end up protecting from different attacks, really.
It's all about the defense in depth. We also have intrusion detection and other stuff(I'm not going to get real specific).
If nothing else, a set of hardware firewalls are quicker to update against a new attack than umpteen clients.
Re:Standardized Firewall Config Scripts (Score:2, Informative)
MBAs, meet Novell BorderManager, circa 1997 (Score:3, Informative)
Novell was doing much of what the OP was asking for, back circa 1997, with their BorderManager product.
Unfortunately, Novell always seemed to have the evil MBAs running the company [is there such a good MBA?], and, the last I heard, BorderManager was allowed [decreed? required?] to wither on the vine.
But BorderManager, as originally envisioned [and it was a helluva nice vision], provided a spectacular framework for dealing with these problems.
Oh well, only the good die young [youtube.com].