Slashdot Mirror
What Is the Future of Firewalls?
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?"
When you finish your MBA- it'll all become clear.
Sounds like someone wants to get rid of the network team by implementing a few DIY tools...
Do you get a free Belkin 54g with your MBA?
No. Which makes me a sad panda.
Large print giveth, and the small print taketh away
Damn you spam Mongolians!
'We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.' RPF
All the tools suck. Firewalls cause more harm than good. The platforms are all mediocre. In my world (low latency trading), pulling firewalls out is one of the highest priorities if it can be done (legally and reputationally).
"Nature doesn't care how smart you are. You can still be wrong." - Richard Feynman
Did anyone play Borderlands for the PC? Remember what a nightmare it was to get multiplayer working on that thing? uPnP sorts out some bits, but having a file that you can upload to the firewall to configure that would be nice. There are scores of profitable websites out there that will walk you through how to configure your router for bit torrent -- clearly there's a need for Something Better. If not config scripts/files, then something else.
I still can't host Borderlands multiplayer games.
moox. for a new generation.
Everything you said sounds like it can just be scripted, not some sort of fundamental shift in the way we think about firewalls. The beauty of the Unix philosophy (do one thing and do it well) is that it works at an almost intuitive level. The more complexity you layer on at the base level, the less clear things become for someone trying to understand it.
This signature serves no purpose other than to help you see which posts were made by me.
INTERNET -> PORT80, PORT443
His point being more and more is routed through ports 80 and 443 in an effort to avoid firewall restrictions. I often think he was right. Consequences for firewalls left up to reader.
"Developed internally at Google, this system is designed to utilize common definitions of networks and services and high-level policy files to facilitate the development and manipulation of network access control filters (ACLs) for various platforms." http://code.google.com/p/capirca/
Yes sir, couldn't get it working properly at first, but I dragged and dropped it outside the red box, and it seems to be working. Problem solved!
I hate grammar Nazi's.
... firewalls would be so much simpler:
The Security Flag in the IPv4 Header
(I saw some other Slashdot comment with this link in it, but it just fits so well here!)
Some firewalls are shit: see, anything relating to SonicWALL or PepLINK (trust me, its a combination that *sucks*
Others are useful once you have the basic idea. Anything is good when configured nicely; even iptables has a reasonable idea of how to do firewall stuff.
Either way, firewalls *are* pretty much entirely shit. There is no "drop-in" security
Firewall Builder does most of what the submitter is looking for already.
I don't have a lot of trouble with firewalls at home. I'm running a WRT54GL with Tomato (previously was using DD-WRT but I like the graphing in Tomato, and didn't need anything available in DD-WRT but not Tomato so I switched). This setup has given me no trouble (baring one stupid r/c game/simulator with networking that is a total mess and doesn't work properly with or without a router - and even that works intermittently). However I'm not doing anything too advanced with it.
Once you do get to enterprise networking the picture quickly changes. Bear in mind this isn't my area of expertise but I do need to understand the firewalls I work with for trouble shooting. Each architecture is unique. The design decisions aren't well represented in something like Visio and the rules couldn't possibly be generated from that. I would be suspicious of any tool that claimed to be a one click solution from diagram to ready to implement firewall rules. I'm happy to be proven wrong but I've not seen such a tool. Complex means complex, and that often requires those hand rules are tweaked.
These posts express my own personal views, not those of my employer
I hope firewalls (well, specifically, NAT routers, DMZs, port forwarding, etc- which all seem to get grouped in 'firewalls') in general will become much LESS of an issue in the future thanks to IPv6. In that world, everything's got a unique address so there's really no need for NAT, private subnets, or the routing issues associated with those.
IMHO, the task of firewalling has been (somewhat incorrectly) pushed on the device doing the routing, when it should be handled on the device itself. Hosts, actual end points, should be able to decided what they will do with the traffic that gets to them, not something in the middle. It's been placed on the router because in our current IPv4 / NAT world, it has to be put there, so the traffic can even *make it to* said end point host. That's not the case with the worldwide-unique addresses of IPv6.
As such, in the IPv6 world of the eventual future, firewalls will exist more due to policy than security (i.e. access to certain services will be disallowed if you're on a corporate network). The security firewalling will need to be done on the device itself, which makes good sense- don't want people ssh hammering your laptop? Well, don't run that service, or restrict it to only devices you trust.
I haven't looked, but I'm sure there's and iPhone app for that.
Task Mangler
Anything that lets you automagically configure a firewall from outside of it is a potential exploit waiting to happen. Things that are stupid, slow, and require physical access are that much more secure.
I think that firewall administration has been allowed to remain shoddy because most people who aren't gamers or server admins don't need to change the settings at all. Gamers are usually obsessed enough with playing that they will take the time to figure it out. And sysadmins, well it's their job to know how to do that stuff.
This isn't an excuse for things being the way they are, but an explanation. Most people just vaguely understand that a firewall protects their computer, but they don't know any more than that and will probably never have to configure one. If the archetypal grandmother or joe six pack ever has a reason to manage firewall settings (unlikely) then an easy configuration tool will appear over night. Unless a widespread need arises, limited demand will translate to limited effort spent developing user-friendly tools.
If you can get past that, then you deserve the goodies, IMHO.
When in doubt use port triggering instead of forwarding, and enable uPnP.
Check out junipers UAC system. It does this quite well when paired with netscreen firewalls.
Just wish I had one ...
How many times did you reboot it?
They'll firewall it for you..
For justice, we must go to Don Corleone
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.
If you're talking about Inbound, then, sorry. I just can't trust you guys.
Guns don't kill people, "with glowing hearts" kills people.
I feel like things might be able to be simplified a little better if there were better use of certificates for authentication and encryption. Of course, that requires a better (free) method of managing and authenticating the certificates themselves.
It might not have a lot of improvements in the realm of firewalls, but it might enable better/easier VPN and control over routing rules. Instead of dealing with IPs and MAC addresses, you could allow specific users and machines. Of course, I'm not sure how much you want to deal with the overhead of all that. Current IP-based routing is doing well enough, and speed matters.
Otherwise, I don't know... IPv6 and ditching NAT? As far as the feeding a Visio diagram in, I'm not sure how much I want my firewall interpreting diagrams for intent. Some firewalls already have GUIs of some kind or another, with varying degrees of helpfulness.
For my purposes, I wouldn't mind seeing cheap, standard, dead-simple VPN that's supported across all clients without additional software installs. Firewalls are only one part of that problem. I imagine a better system of distributing/verifying certs might help.
The BSD 'pf' packet filter is pretty good. There is even a FreeBSD-based project known as pfsense which you might want to take a look at, as it offers a pretty-much drop-in solution for packet filtering, as well as NAT, load balancing, VPN connectivity, etc. There is a web-based administration GUI as well. It looks pretty sweet, but I haven't played with it much in any serious deployment personally.
Cisco Security Manager does all that and more. The key features being Interface roles and ACL/device hierarchy.
Obviously this is not opensource.
-- You can be a geeklord too
UTM: unified threat management.
Disclaimer: I work for a manufacturer of such devices.
The better ones integrate with Active Directory and/or Kerberos to authenticate sessions, and do spam and virus scanning (using a quarantine server, if available).
Some will even decrypt and reencrypt HTTPS traffic to check what's in it. (They resign the server's cert with their own CA cert that the user's browser has to trust -- in some environments, an intermediate CA cert can be imported signed by a CA cert that has already been pushed to the desktops.)
Some will even set up VPNs via a PC-based admin app in a step as simply as drag and drop.
That said, they don't come cheap: figure $500 and up for a home/SOHO office version (3 lan ports, DMZ, and one or two WAN ports (for WAN failover), along with licensing for virus and SPAM scoring server access.
In Liberty, Rene
It's not quite as nifty as what the post mentions, but Playbook by Matasano "syncs your firewall configurations with a secure web-based console"
http://runplaybook.com/
(note: my only relationship with Matasano is that I like their blog)
I've been contacted by several Internet security product vendors recently (after I attended a free network security conference in town). The "in" thing right now seems to be selling "security appliances" that can intelligently sniff traffic on port 80 or 443 and discern what's actually going through. Of course, right now, they seem to be trying to sell these as additions to your environment, rather than replacements for existing traditional firewalls ... but it's only a matter of time before it all gets rolled together into one product.
I don't have a one-of-those, I just have my scripts call iptables :-/ it's not as flash as drag 'n drop, but I tried programming a virtual usb mouse to automate clicking things on the screen when things happen, but while trying to write the detection software that tells it to click certain rules when somebody plugs their computer into the network, which was detected by pointing a webcam at the network switch to watch when lights came on/off, my head fell off. Turns out, I needed my head on.
The revolution will not be televised... but it will have a page on Wikipedia
Characteristically, firewalls are simply just that: a barrier to entry into a restricted, trusted area unless you're a loud to do so. So I'm confused why I would, first of all, want something 'automagically' configured for me in an enterprise setting? There's a very good reason your network admins at your workplace highly scrutinise over a single IP address: because it's important your infrastructure, IT/perimeter security standards and business, and it's their job to. If they aren't at least, on a high-level, asking you the 5-W's about why you need the rule(s) and you don't have answers, why should they even allow it?
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?
That's what tiered firewall-VPN solutions are for.
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?
Port knocking is pretty helpful in this, but can also bite your security-through-stealthy-obscurity right in the ass as well.
Can I take a Visio diagram, run it through a script, and get a list of firewall rules?
Visio diagrams are for documentation and suits. I couldn't hold any merit to that because firewall rules aren't just something you slap together (unless you're doing it for fun or at home or want Johnny Cracker hosting pr0n on an anonymous FTP on your computer at home). Flow-based solutions process rules in a top-down fashion, so it takes very good sets of eyes to develop rules that aren't going to be a liability, cause backdoors, trump existing rules and break security or flat out cause things to not work anymore in your production environment.
Not simply port numbering but actual protocol identification. That's what all the major players are doing for "next generation" firewalling.
PALO ALTO NETWORKS
Standardization among endpoints is the only real way to lessen the headache. If you know that workstations need to use port X and protocol Y it's much easier to setup. Without it you have some goofball configuring RDP to listen on 32322 not 3389 like most everyone else.
OK, jlmale0, are you working on requirements or marketing for a product in this space? You can tell us, it's OK.
I blame Microsoft for making complex problems appear simple. They put a simple and limited layer over the top of a complex background to hide it and suddenly everyone thinks they can be a sysadmin without having a clue about how it works underneath, and without that clue the user gets it wrong once they try and do anything vaguely complicated.
Firewalls are the the same, only more so. You _need_ to understand what is happening to the packets as they move through your networks if you want to admin anything beyond a simple 'internet on one side, intranet on the other, nat in between' firewall. A point and click interface might be fine for home use (although it almost certainly won't have sufficient egress filtering) but for something with more than a single internal network requiring complex separation rules between them you need to know what you are doing.
So to answer the OP, the future of firewalls is network admins understanding their jobs, same as it's always been. Text representation of firewall rules with sufficient comments is just fine.
Yes, find someone who knows something about networking and more importantly about firewalls Try someone who has a CCSP or CCIE:Security as part of their title. Some of the things you are talking about have existed for years on Cisco Pix and ASAs like downloadable ACLs (Where based on your credentials you get firewalled differently) which can be applied across a whole enterprise of firewalls. Dynamic inspection of traffic, like h.323 traffic, so you don't have to open a whole range of ports other than the signalling port.
Dear lord, gui based management of a fleet of firewalls? You want to drag and drop things and make magic happen when you do that? Sounds pretty reckless and dangerous to me. That's like saying because you can ride a bicycle, you should be allowed to drive a hazmat semi at top speed through downtown LA. If you don't understand what the rules are and how they will be applied in the first place, you are likely just going to cause problems (like accidentally shutting off your company's ability to sell their trinkets online because you locked it down on accident.)
By the way, I don't care what the kid from the nerd herd tells you, Belkin and Linksys do not sell firewalls. They sell quasi-routers with nat and some limited form of access control. Finally, UPnP is not the answer to your problem, that just makes it easy for people to put devices on your network to open security holes up in your firewall, which is why it's not supported on most enterprise grade firewalls (and wouldn't work anyway if you looked at the way most enterprises build their networks)
Create a GUI interface using Visual Basic. See if you can track an IP address
When you finish your MBA- it'll all become clear.
After some cost/benefit analysis on the ideas above, I think yes. It's not going anywhere.
Live today, because you never know what tomorrow brings
Yes, there are those outside cases. However, consider how many scenarios can be easily covered with an "exceptioned template".
Take IP tables, for instance. It typically goes something like this: Deny all, do NAT/masq from the inside, do traffic shaping/QoS, and finally allow specific ports/do specific port forwarding. It's formalistic and not all that complex, once you understand it - and it's largely linear, with most of the scripts following the same basics.
For 90%+ of scenarios, it would be easy to instigate a framework for transparent transport of rules between systems (homogeneous and maybe even heterogeneous ones) or automatically setting rules based on inside services. The problem with doing it, however, is that it would provide a negligible benefit over what's out there now (as firewall rules tend to rarely change).
The security ramifications of such an application seem like they'd be hit and miss, internally. Yes. you want to prevent hosts from talking to each other when they've got no reason to - though there are other methods for doing this in a cleaner, less granular/more centralized fashion (802.1q VLANs). It works better because, again, it covers 90%+ of conceivable scenarios with less configuration.
It all comes down to KISS. Sometimes firewall restrictions are appropriate; sometimes something else is. More often than not, though, people use what they know and misapply it for fear of not being able to grasp a new technology in time to properly implement it, and we end up with a gongshow.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Its funny TFA makes it sound like Firewalls havn't changed at all in years. I was just commenting the other day how firewalls are now able to log not only what machine sent or received what packet but the process name and id and user context of the host computer responsibile for initiating or receiving the request. What is possible and the level of integration throughout the technology stacks is incredible and scary.
Coupled with ipsec you can now strongly authenticate individual ip/tcp sessions between any system on the network. What is available to those who are willing to move beyond a soho device and the absurd notion that ports are somehow related to service is actually quite significant in modern operating environments.
Firewalls are just as importantly about logging and monitoring access as they are about implementing access controls but very few administrators take this seriously and fail to review their logs.
Firewalls for ad-hoc access control in my view set a dangerous precident by shifting the responsibility from the end systems where the most amount of information is available to provide authentication and authorization to the network which is quite stupid and easily fooled. Internal machines must not be assumed safe just because they are on an internal leg of a firewall... PPL who make these assumptions are idiots and it happens everywhere.
I seriously think the world would have been better off had firewalls never existed and authentication/authorization of acesss to network resources were not treated as second class citizens.
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.
Errr what ? may be GUI might not have future.
dentists reading
Firewall management is difficult when a lot of holes and special rules are created. This happens when firewalls are used for things that god never intended such as enterprise wide point to point specialized rules. The trick is to go from security requirements and policies and design a network and gating solution that meets those needs without creating a lot of complexity.
In a dynamic organization, this means that the policies, rules and design have to be revamped on a regular basis to keep things simple and to prevent spaghetti connections and firewall sieves from developing.
You are specifying solutions and rules instead of stating the problem to be solved.
I always forward a block of 100 ports to each active intranet IP on my network, with the first digits being the last octet of the IP.
eg: 192.168.x.101 gets ports 10100-10199.
Using this system, along with a domain server that will assign each machine a predictable IP, makes things a lot easier.
There are two problems with your question.
The first is you may believe tools and diagrams will take the pain out of implementing and enforcing security policy. Network design is systems design. Diagrams are essential in communicating that a system meets the requirements to stakeholders and management who make budgets and can't visualize how improved security adds value. But firewalls and their associated diagrams are just one element of security. What about OS patches, authentication and physical security? You know that firewalls run software and software needs maintenance. Pointing to a well executed diagram won't save you from applying vendor software updates. Are your policies sane? Security tools are only as good as the policies they implement and the people who use them. You're tool may show you that you have correctly hidden an important asset from the outside world, but are all your assets protected? Does your organization give out VPN logins to unqualified users? Are you using a VPN? Can your services run over a tunnel? If your servers or services can be secured do you really need to block all ports and selectively open a few? Can any of your services take advantage of TCP Wrappers?
"When you finish your MBA- it'll all become clear." is spot on. Perform a cost benefit analysis. Figure out how many hours at your rate it will take to to cobble together some scripts or pay a developer for a custom tool. Then figure out how much it would cost to hire a qualified network engineer. Then figure out the cost of loosing business due to denial of service or network intrusions. Then realize that you still probably a network engineer to correct your diagrams and security policies after you use a custom tool. You can always do your own taxes and defend yourself in court, but can you afford to be wrong? Complex problems need people with specialized knowledge.
The second problem is no tool programmer in their right mind would want to write a program to generate scripts from Visio. I'm a programmer, not a network guy, but like many programmers I've run Linux and OpenBSD development and webservers and done my best to keep them secure. I've also used Viso, and Visual Paradigm and some other very expensive commercial tools for creating UML diagrams. In less time than it would take me to figure out how to correctly draw something in Visio, I could have skimmed the man pages and the internet for the correct syntax required to write a rule in iptables or pf. Viso is not an intuitive tool for working in most domains. Adobe Illustrator with all its quirks makes more sense in comparison. If you want a neat toy or project, take a look at GNU DIA, or Argo UML and write patches to generate configuration files. Even if you are successful there is no standard operating system or vendor independent language for defining firewall rules. Don't ever expect to drag and drop a policy to migrate rules from a Linux based appliance to a Cisco router to a Juniper switch to a BSD based appliance. Cisco has made billions by locking in customers to their own standards. Linux and BSD are integrated into many firewall appliances but they also have their own version dependent quirks and special sauce from vendors.
:D :D
and fo sure, he/she will be a very qualified professional: an MBA that knows a lot of terms about firewalls, learnt from a sysadmin's tech magazine dated Feb 1997.
when somebody plugs their computer into the network, which was detected by pointing a webcam at the network switch to watch when lights came on/off
You seem to be going to a lot of trouble to avoid using SNMP ;) .
Dear lord, gui based management of a fleet of firewalls? You want to drag and drop things and make magic happen when you do that? Sounds pretty reckless and dangerous to me. That's like saying because you can ride a bicycle, you should be allowed to drive a hazmat semi at top speed through downtown LA. If you don't understand what the rules are and how they will be applied in the first place, you are likely just going to cause problems (like accidentally shutting off your company's ability to sell their trinkets online because you locked it down on accident.)
I can't think of a single reason why knowing what the rules do precludes using a GUI tool to simplify and automate management.
Manually editing text is time-consuming, fatiguing and error prone. Have a tool to automate that sort of thing is one of the fundamental reasons for having computers in the first place.
you should not be configuring a mission critical firewall.
Secure perimeters are illusions. Every machine needs its own defense. Firewalls are good for NAT, which foils a few, and stateful inspection, which fools a few more. Otherwise, internal firewalling and boundary checks are the only answer, coupled to download security hashing checks-- and those get bitten, too.
Belief in firewalls and secure perimeters are the reason that some 30% of all machines in a domain are bot'd somehow..... along with Checkpoint, Norton, Microsoft, and so on. A CCIE or CCSP gives you someone that can help, but there's no guarantee that someone won't click on a site that will give your browsers a headache, then the infection, and so on.
The MuSystems guys can tell you about fuzzing attacks that will leave most equipment in a state of mush. With enough pounding, you can break about anything. Sorry to be dour, but you have to use best practices, and protect each indivdual device, not just the perimeter.
---- Teach Peace. It's Cheaper Than War.
This guy has never had to clean up a virus outbreak, in which our firewall stopped it from being able to connect directly out and download it's payload.
I'm a network security engineer, and we use Juniper, and we can make a rule across all firewalls with their NSM product. You have to be a place with money to have that ability though.
The biggest issue is viruses, and trying to control data leakage from a company. People who are trying to send/receive data see it is a problem; network security guys are here to save you from yourselves.
http://runplaybook.com/
The future of firewalls (at least on the enterprise) seems to be layer 7 rules. Look at what Palo Alto gear does using FPGAs and custom rules for each application... its kind of an "antivirus on the wire", with all the bad implications (easy to circumvent on targetted attacks, etc) that has.
This is the future of firewalls. It's expensive now because it's new. But soon, you'll be able to do this on your SOHO (or SMB) firewalls: http://www.paloaltonetworks.com/
The Dread Pirate Roberts is here for your soul!
Sounds like you got a good comfortable job configuring firewalls, why the fuck would you give that up?
...
Been done. www.linesider.net. Set up some groups, IP addresses, ports, etc. and have it configure both IPTables and secure tunnels for all networks involved. The core networks involved need a network appliance plugged in to listen to the provisioning signals.
There was some good work done 10 years back on "trust management" via a system called Keynote. The basic idea was that you set global policies and the system deals with the details of translating them to iptables rules, Cisco router stuff, et cetera -- sort of a high-level language for network management, with at least some prototype compilers. Credible people were involved and the papers were plausible.
One link is http://www.crypto.com/trustmgt/kn.html
I have not looked at this stuff in years. Anyone know where it went?
how was the resulting game of Marco-Polo? fun?
This seemed like a reasonable sig at the time.
The only thing a firewall is good at is limiting which side can initiate connections (I am using the word connection loosely). Everything else is a futile effort because servers can and do use arbitrary ports and in the future protocols will be encrypted to avoid all sorts of attacks, thereby also making deep packet inspection obsolete. On the server side, firewalls are unnecessary and at best an added layer of stuff to manage. If you don't want anyone to connect, don't bind the port. The concept of a "trusted network" is fundamentally flawed.
I can't think of a single reason why knowing what the rules do precludes using a GUI tool to simplify and automate management.
Manually editing text is time-consuming, fatiguing and error prone. Have a tool to automate that sort of thing is one of the fundamental reasons for having computers in the first place.
Fair enough. It might have been presumptuous of me to assume that a gui based "drag 'n drop" system would lead to someone creating policies and applying them before checking to see how they are applied and what the end-effect would be. A lot of time when someone is looking for a GUI system of that nature, they are looking for a way to not spend money on a security professional, but instead let a person with minimal training manage these devices.
Any tool is only as useful as the person using it. If you have your janitor programming your firewall because it happens to sit in his closet, then you probably have bigger problems on your hands anyway.
I'll admit, in my office, we script the heck out of a lot of configurations, but that doesn't mean we fire and forget. We still have to look at the end result and see how this stuff is going to fly before we apply it.
Yes, firewalls are only a first-line-of-defense tool. Making the assumption that a firewall is an end-all-be-all solution is not a good practice. You do need to have a network perimeter to filter out a large factor of attacks, internal borders to mitigate internal problems, and desktop/server security to protect you from your users.
That is why we have firewalls, content filters, network access control devices, intrusion prevention systems, and desktop products (like Cisco Security Agent).
You can't get your whole network security from a single solution and not necessarily a single vendor.
I am in a virtual reality and have been contacted by the future: Firewalls are smart devices using ACL's, behavior-based algorithms that grow, and are necessary. resistance is futile.
There are currently a number of applications being developed by DORKA which will allow PHBs to manage their own corporate firewalls from an Excel spreadsheet or Microsoft JET database. The applications are being developed from a usability standpoint rather than a security standpoint which allows all traffic to be allowed by default (IPv6 is ignored for simplicity because nobody understands it anyway). When the software detects a DDoS, Intrusion, or Security Breach in progress, it will send an email to the managing PHB and trigger a rule to route BLAME packets through Layer 8 instead. All there is to the interface is a red button marked "Easy" a Yellow button marked "Out To Lunch", and a red button marked "WTF?". You should find it very exciting.
boycott slashdot February 10th - 17th check out: altSlashdot.org
Governments/Agencies are already doing this on a large scale.
Those huge cables that connect your country to the internet? They're all monitored with super-sized versions of these: Packet Forensics MITM devices
Yes, I can theoretically envision (and I think you were hinting at) an overriding system/application, combining:
1. iptables / tcpd / selinux, etc at the host level
2. tcpdump to get an idea of "normal" traffic
3. nmap for checking
4. expect for logging into text-based systems for config changes
5. secure comms between systems
etc, etc.
However, I don't think it will be practical to have a canned GUI thing - too many variables, too many things to go wrong.
A better approach is just have a secure system: no firewalls, strip out unrequired services, configure required services securely, user account sandboxing, etc. Have a linux/Unix distribution setup for security and usability *on installation* and have automatic, secured updating. Obviously this will not work with Windows, but I think modern distributions are potentially good enough for this provided they are setup correctly for the critical installation stage and initial update.
Sure, users can't be trusted, but they can't be trusted with firewalls or whatever security measures.
I am not a robot. I am a unicorn.
That brings back some good memories.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
..and rubbish. I manage over 90 firewalls as a fraction of my full-time duties and it's a cakewalk. Why? I'm competent with unix (and a bunch of scripting languages). GUI's are for the command-line challenged..
whooooshhhh!!!
It's called CSM and it's amazing! It does everything for you and never fucks up!!! :D
Seriously though, we're so far from this I couldn't even begin to tell you. Half the time the application vendor can't even tell you what ports are required and they wrote the software that's making the connections. It's pathetic. I get requests from clueless lusers who obviously don't even know what they're requesting, then the question ("No you can't have an IP any. No, ugh, never mind what that means...just ask the vendor what you need.") goes to the vendor and half the time they can't answer it.
Truthfully there is really no great way of doing this. Even if you can profile the software running on the machine, you're not going to know if it's making all the connections it needs to make during the time you profile it. You also need to have some kind of idea what you're doing so you don't wind up exposing 139/445 to the internet or something dumb like that. They pay us infosec people a salary to do this stuff for a reason: we can't always tell you what you want, but we can usually tell you what you don't want. Making these kinds of changes requires thought, risk analysis, and planning. It's not something that should be a drag and drop routine that any user can do...at least not at this point in history.
Maybe at smaller companies sys admins have the knowledge necessary to make these sort of decisions responsibly but I can tell you from experience that being a sys admin does not automatically confer on you the ability to make smart decisions about what firewall exceptions to request. We've had users escalate requests WAY up the chain after being denied by us, only to have them sending 911 pages to us literally 20 minutes after it's implemented to have it shut off. Just because your sshd is up to date and you use strong passwords doesn't mean you want the entire internet beating down your door 24/7/365...sometimes it really is better for you to have your users connect to the VPN first. That's the knowledge that infosec brings to the table, and that's why we don't want you making your own exceptions.
I can't think of a single reason why knowing what the rules do precludes using a GUI tool to simplify and automate management.
Manually editing text is time-consuming, fatiguing and error prone. Have a tool to automate that sort of thing is one of the fundamental reasons for having computers in the first place.
The thing is the GUI design is very difficult. You need to know your users and their tasks in advance.
They are good for things that are easy to specify in a high level language, and difficult in a low level language. Of course, the domain of problems to be solved needs to be small for a GUI to succeed in that task.
The tool is not going to be simpler than the problem, so I think the best you could get would be some sort of iptables IDE, and that is not what came to my mind when I read "a GUI tool". Of course, all text editing can be "augmented" by a good tool, but I don't think it can be replaced. Text editing is _the_ way to configure complex stuff, maybe a good IDE can help you edit it better, or easier, but that's as far at it goes, in my opinion.
Three, always reboot it three times before posting.
"There ought to be limits to freedom." -George W. Bush
I can't think of a single reason why knowing what the rules do precludes using a GUI tool to simplify and automate management.
I can think of lots of reasons. The only reason I can think of having a GUI automated management tool is so some dumbass that doesn't know what he's doing can appear to manage firewalls.
Now, I can see the purpose of a GUI inspection tool for independent verification. But even then, I believe automated scripts are better.
Manually editing text is time-consuming, fatiguing and error prone. Have a tool to automate that sort of thing is one of the fundamental reasons for having computers in the first place.
This is why we have scripts. I would never manually configure the thing more than once, and that's only during the initial discovery phase. After that, it's script and test, script and test, then deploy when the scripts are spotless. This way I can always recreate anything at any time, without having to go dig up the guy that configured firewall xya 3 years ago and moved on to another division or even external job.
Scripts are repeatable. Scripts and their results can be objectively validated and verified.
GUI tools cannot. They're a nicety for inspection for those that cannot read or understand the scripts, however.
The cesspool just got a check and balance.
Apple has taken an interesting approach that at first I hated but have come to like. It's actually simpler once you get used to it. The OS keeps a database of all applications that have ever asked to open a port to listen on. If an application asks to open a port to listen on and it's not on the list, the OS prompts you to allow it. This is a more intuitive way to manage security. Definitely does not solve all issues but is an interesting approach that works pretty well.
Currently hooked on AMP
Taco Bell again?
Secure perimeters are illusions. Every machine needs its own defense. Firewalls are good for NAT, which foils a few, and stateful inspection, which fools a few more. Otherwise, internal firewalling and boundary checks are the only answer, coupled to download security hashing checks-- and those get bitten, too.
Secure perimeters are real, if done correctly. I know of one personally that has not been breached in a decade. :)
Every machine needs to be properly configured (I guess that can be stated as having its own defense, but I doubt you meant it this way)
Firewalls are not good for NAT. They have nothing to do with NAT.
Firewalls are not good for stateful inspection, they have nothing to do with that either.
What firewalls do is allow connections inbound and outbound. The better ones allow for more rich rules like which protocols on which ports, which machines/macs can connect or even force a user authentication before they can connect to an IP/port. There are also the on the desktop firewalls that allow an application IP/port designation. But that's all a Firewall does.
You do have one point though - if you're running MS desktops yes, they can be owned if they're allowed to connect to external entities at all, and that includes USB drives.
The cesspool just got a check and balance.
What about an idea like the SPAN framework presented at the USENIX HOTSEC '09 conference:
http://www.eecs.umich.edu/~aprakash/span.pdf
Seems like a promising direction for R&D.
Informative?! WTF?!
http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1191993,00.html
A couple of years old but does anyone have an update? Or a better idea?
---
Duh.
I agree with you. I would be very wary of using a simple solution for firewall management. Yeah, putting in tons of rules for firewalls can be a time consuming pain in the ass but I really think it is better that way. More than not trusting the interface/firmware/device/software I wouldn't trust MYSELF. I have to put more thought into typing/manually selecting than I do with a drag and drop type setup. That helps me avoid making mistakes.....and at any level of business a mistake on the firewall can turn out to be a big, big disaster.
I work with Check Point and Juniper firewalls. Most of the stuff you are asking about exists.
> 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 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?
Check Point's SmartCenter Server and Juniper's NSM allow dragging and dropping policy elements among multiple rule bases and devices. If you wish, you can have one rule base applied to multiple firewalls.
> 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?
I'm sure every major manufacturer supports firewall authentication. Usually through http, telnet, ftp, etc.
In my opinion, "ease of use" should not be a feature of an enterprise firewall. Don't get me wrong, it has to be intuitive enough to complete the necessary tasks. However, firewalls today are becoming more and more complex, and if inexperienced people feel they can manage them, the likelihood of problems and downtime rises. Firewall admins should take the time to really understand the product. When that is the case, the more granular policies (setting the IP addresses and ports) are usually more secure and favorable.
The thing is the GUI design is very difficult. You need to know your users and their tasks in advance.
Which shouldn't be a significant problem for a domain as narrow as firewall management. Particularly given that the majority of firewalls are going to have large proportions of their configurations be very similar, if not completely identical.
The tool is not going to be simpler than the problem, so I think the best you could get would be some sort of iptables IDE, and that is not what came to my mind when I read "a GUI tool".
Consider something simple like adding a host to a standard ACL list for webservers. Why should it be any harder than dragging an icon for the server into a "Webservers" group, ticking a "webserver" box next to the hostname, or attaching a "webserver" profile ?
Why should any of these things require manual, slow, error-prone meddling into a text configuration interface ?
I can think of lots of reasons. The only reason I can think of having a GUI automated management tool is so some dumbass that doesn't know what he's doing can appear to manage firewalls.
That is a criticism of the user, not the tool. A criticism that applies equally to a collection of automated scripts.
Now, I can see the purpose of a GUI inspection tool for independent verification. But even then, I believe automated scripts are better.
Why ? Graphical representations of complex systems are nearly always easier and quicker to understand than lines of text describing same.
GUI tools cannot. They're a nicety for inspection for those that cannot read or understand the scripts, however.
GUIs are most certainly repeatable and their results can absolutely be inspected and verified.
Check out FWBuilder. Anything beyond that concept would be overkill and extremely error-prone.
Check out StoneGate, it offers a GUI where you can drag&drop all kinds of stuff with a very powerful management system. The learning curve is a bit steep, but it's really meant for network admins who use it as a central part of their jobs. I think it has most of the features you're thinking about.
It's really ideal for large enterprise-level installations with multi-homing network connections, but works in smaller installations just as well (I used it also at home). It requires two servers: at least one firewall node (you can build clusters), and a management server (can be your desktop machine). You can do logging on yet another server, etc. They also offer IPS (intrusion prevention system) for detecting nasty behaviour.
Being able to import visio files as configuration into our firewall is a great idea, it means now management can help design firewall rules and get them set up without any interaction from a system admin.
I really agree with Firethorn:
- Keep the firewall simple. Its job is to keep the rough bulk of attacks from an extranet outside.
- Protect your data where it resides (always!), even against intranet abuse (strong(!) authentication, working access control).
- Monitor use (intrusion detection, normal use / abuse patterns, traffic anomalities, logs)
In todays environment there are plenty of attack vectors that circumvent elaborate firewall constructs (like: USB sticks being used for data exchange, laptops being connected to arbitrary networks while on the road and then brought back into the company network, Blackberrys or iPhones being used to create additional (non-firewalled) connections to the Net, ...) so the distinction between inside and outside has mostly become moot, except (as stated above) for a rough triage.
Far too many company networks today follow the clam model: Strong (and inflexible) shell, mushy interior.
Some commercial solutions handle this as well. I used to have a set of hardware FW that would all share a central repository of rules, each box applying the rule as they need it. It also came with intrusion detection and prevention, and auto vpn tunel meshing between box, so all was neatly availlable in the same configuration tool; wich was not so good looking, but was still significantly faster than manual edition. At the end of the day, one could revert to full text based administration and find oneself in a familiar unix-like environment.
Unfortunately, it ended up being a lot less reliable than what was previously thought.
I have seen people consider their firewall a bulletproof way to keep the baddies out... well, until the next Web browser exploit shows this isn't a workable strategy.
In reality, a decent sized company not just needs an external firewall, but in addition, a router separating the DMZ from the internal network, an IDS to detect incoming and outgoing packets, find the source if there is a known exploit and shut it down, a content filter (to keep Joe Sixpack in Receiving from ogling at boobs, then Jane Nubile from HR sees it and then promptly files a sexual harassment lawsuit when she sees it), NAC devices (to enforce presence of antivirus utilities likely forced per agreements), equipment to log packets (ACTA will force all ISPs and carriers to log *every* packet across their network for 7 years. Not headers. Entire packets).
Even with all this network functionality, this doesn't mean the hosts are secure. They need some protection just in case there was an open wireless segment. So, if a Windows system admin is smart, they would have policies pushed out to all the Windows 7 boxes with rulesets for the inbound/outbound communication, such as no port 25 out unless it is to a dedicated machine, blocking unneeded ports to internal machines, and so on. By having this configured on the boxes themselves, a compromised process wanting to phone home would have to get admin rights on the box and turn off the firewall to do its dirty deeds.
Of course, the more complex the configurations to keep items secure, the more problems arise, especially with app troubleshooting. So having a tangled web of allow/deny ACLs on machines may result in some unexpected interactions.
Juniper, who is right up there at the top with Cisco has a management platform called NSM.. You can copy and past rules between devices, have configuration inheritance via templates, O and it does version control with rollback for configurations and policies. It also manages firmware updates and holds common objects (hosts, subnets, application ports) that are shared among all devices.. The devices them selves can be managed purely by command-line, a complete web GUI, or NSM.. Newer JunOS devices use XML to pass configuration information instead of trying to interpret a list of commands like Cisco devices still do.
JunOS is also very consistent across devices, which makes scripting against it much easier.
How does sniffing 443 work? I thought the point of HTTPS/SSL was to give security to the connection?
Unfortunately, 90% of corporate networks seem to treat the external firewalls as the *only* line of defence... Once you get behind it, however you do that, the inside is pretty trivial to compromise very thoroughly.
Quite often you see content filters on email/web traffic (another perimeter only defence), but these systems typically work on a blacklisting approach so there are always ways around...
I work as a security tester and incident response (ie identifying what happened after something got compromised), and every network i test is based on the egg model - hard outside, squishy inside... And every machine i encounter which has been compromised has some kind of av installed, and usually gets infected *through* some kind of content filtering device. The most amusing part is that every single piece of malware i've found on client machines was detectable by some av products, just not by the specific one in use - and companies typically use the same av on both their content filters and the individual workstations.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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?
OpenBSD has had this for a while now. It's called authpf, and it can dynamically load NAT or redirection rules in addition to simply opening ports.
You won't find a better firewall than pf. It's secure, extremely capable, and has a logical and refined syntax for defining rulesets.
I am in no way associated with the Firewall Builder project. It's an application I came across it in the January issue of Linux Journal that sounds like it could solve some of the original poster's issues.
The article is available online, as is of course the project homepage.
I have not used it yet, but it looks promising and sounds like one of the "cool projects" the submitter needs to know about. It gives you a graphical representation, it can deploy configurations via SSH to various machines or to Linksys, D-Link, DD-WRT or OpenWRT devices, Cisco routers and Cisco ASA (PIX) firewalls. It supports IPV4 and IPV6 and the client is available for Windows, OSX, Linux (ubuntu, fedora, debian repositories at least), OpenBSD and FreeBSD.
At least that's what they promise, but it has been in development for some time (1999) so I expect it to be pretty good.
computers let you make more mistakes faster, with the possible exception of handguns and tequila.
One issue that I have seen with firewalls - I call it an issue because it can be a problem - is that some firewalls today uses Universal Plug and Play that allows items behind the firewall to control the firewall - often without the owner knowing it.
And on some routers/firewalls this overrides the manual firewall configuration - without notifying the user. From my point of view this is a security issue.
As an example - a friend of mine did install a NAS and he is running a web site behind the firewall, but the NAS hijacked the web site and caused a lot of confusion. This means that the UPNP functionality also can offer attack vectors for malicious people.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
that would be great.... chaise lounge chairs bookkeeping prude
Text config files force you to understand everything , read every detail.
GUI's are nice and shiny , but they hide details. In order to distinguish shapes you need white space around them and so you're left with little space for valuable information.<br>
Sure one or two tools out there might have a decent idea about graphically representing firewalls but in the end you're still left with understanding everything so that it works and once you're there you'll realize you had enough time to build the same config file in a text editor three times over. <br>
What gui's are good at is summarizing everything for somebody new taking over.
If you expanded your horizons to the 'professional' market, you'd find numerous such tools. Solsoft NP does exactly as you describe (draw a network diagram, join clouds/hosts with lines, generate policy for all involved firewalls) and has been around for more than 10 years. Clearly no one wants it, as it's been bought up by Loglogic and disappeared.
Checkpoint has a hierarchical policy editor which can force templates and global policy across multiple organisations and firewalls. At the very least a single policy can easily be shared across multiple enforcement points. It also has user authentication to activate rules. No-one uses either of these very much either..
Fwbuilder is a great checkpoint-like policy manager for linux, pix, asa, bsd etc. - why don't you use that and buy some support?
I think you mean 'why do people not want to pay for or use better firewall management tools, especially on linux?'
Good day to you, Sir,
I am writing to you under the utmost duress of financial necessity. I am the late son of King Rumumbalek the Third, ruler of the (... skipped ...)
(...skip skip...)
To get our calculating systems to commence the transfermission of the 40.000.000.000.000.000.000.000 blapohtrillions between our financial systems, please be so kind as to run the attached 419.sh file (as root) in a *nix console of your choice. Rest assured (... skipped...)
Dear lord, gui based management of a fleet of firewalls? You want to drag and drop things and make magic happen when you do that? Sounds pretty reckless and dangerous to me. That's like saying because you can ride a bicycle, you should be allowed to drive a hazmat semi at top speed through downtown LA. If you don't understand what the rules are and how they will be applied in the first place, you are likely just going to cause problems (like accidentally shutting off your company's ability to sell their trinkets online because you locked it down on accident.)
On the flip side, just because you can operate a text editor doesn't mean you should be modifying your company's firewall either.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
I was looking for something like this a few years ago when I was working on a carrier-grade scalable multi-tenant CC project. Pretty much the only thing I could find was from SolSoft (which has morphed somehow into LogLogic in the meantime) called "Solsoft Security Change Manager". In the end, we decided to go with the high-paid admin approach so we didn't do any serious testing, but it might be what you are looking for. FWIW, I got the tip for Solsoft from a guy who worked on Netfilter.
http://www.loglogic.com/products/security-change-management/index.php
Steve -- If you have to call it a system, you don't know what it is.
> Dear lord, gui based management of a fleet of firewalls?
I think a company called F-Secure had something like that. I don't recall what the name was but it would manage firewalls and VPN configuration. I think the focus was on the workstations. As far as I remember it was working pretty well.
Manually editing text is time-consuming, fatiguing and error prone. Have a tool to automate that sort of thing is one of the fundamental reasons for having computers in the first place.
Frankly I'm kind of stunned that people still manually edit text files for major firewalls in some critical networks. A robust GUI tool is an essential safeguard for something as simple a typo bringing everything down. Seen it happen. A UI can have necessary warnings and reflect the policies process so a change doesn't make the network eat itself.
After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
Don't do that.
The revolution will not be televised... but it will have a page on Wikipedia
... and it's broken networking.
Fact is, off the top of my head, I can't think of a single piece of application software that is written properly with the network in mind, and by that I mean that in the manual it lists *precisely* what inbound and outbound ports and protocols it uses, and *why* in each case.
In most cases port selection is pick a random number between 1024 and 50000, pick a random protocol, start pinging and fingering, and then wonder why the application doesn't play nicely with your firewall / router / ip tables / etc
For the home user Draytek / Vigor have for many years now been making fairly nice little boxed, with a browser based admin that should in theory be more than adequate for anything the home user would want, and far better than you get in a generic router / firewall.
What happens? User fires up X app or Y game and things don't work, and guess what, the firewall / router gets the blame.
I can remember spending a day as a well paid external consultant in the offices of a specialist financial company that managed investments for the privately wealthy, hello, lots of new bits of application software that I had never heard of before, and one in particular just wasn't working properly.
I did all the usual, looked at configs, sniffed, even RTFM in some depth, in the end I said balls to it and rang the published and stayed on the line until I was connected with a coder.
The result?
Sorry sir, that software is written to work on a standalone machine ONLY, it was not written to network between multiple installs on multiple machines on a network.
Too bad that the financial company, and the computer company that called me in, had just installed a new network with 12 new desktop machines running 98 and a new server running nt 3.5, and decided to have 3 or 4 of those machines run this package in question, and a couple of others.
In hindsight, the funniest thing of all was when I told the company director, and the director of the hardware company that hired me to fix the product that they had sold, what the problem was... naturally enough I got the blame.
Six months later I met the director of the financial company, he had finally parted ways with the hardware company, and would I consider coming in and sorting their network out.
Thanks, but no thanks.
Once bitten by assholes, forever shy.
http://slashdot.org/~GuyFawkes/journal
When you finish your MBA- it'll all become clear.
After I got my MSSE (I guess the MBA for Nerds, though I didn't realize it at the time), I figured that was because all firewalls were supposed to be rendered obsolete and unnecessary by IPv6. Which explains why we're still stuck in 1995.
So yeah, this is the answer, this is the ending. I shall drive without license, without clothing, without direction, and if I make it to Arkansas fine; if I'm running late; if I'm running a numbers game, it doesn't matter, I'll keep on running! Because a body in motion tends to stay in motion, and it's better to feel. Pain is better than emptiness. Emptiness is better than nothing; and nothing is better than this.
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.
Yes. That's by design, believe it or not the Internet still operates around rules that were in place in 1995. Sorry 'bout that. Unfortunately, the telepathic OS and Application sense UI hasn't been developed yet.
What's available for managing complex firewall arrangements?
Every player has one. I personally like the concept of CSM(Cisco) and Juniper(NSM) both of those tools will allow for consistent portions of the policy across several devices while allowing you to change the hierarchy when necessary for a section or rule to take precedence locally. The things that I think they have over CheckPoint Provider-1 (1) Common ports and protocols, nothing new to allow for NSM, or CSM (2)The configs can include things like SNMP servers and routes.
Caveat: CSM interface stinks. CSM4.0 is looking better, but who knows when that goes GA?
What's being developed?
Look into the above. Also take a look at Palo Alto, and Cisco NSM (for uber-large deployments)
Can I take a Visio diagram, run it through a script, and get a list of firewall rules?
No. If you did, it would suck. Anybody who said they were writing such a tool would get a guffaw from me. Icky, Icky.
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?
It would almost certainly be broken. Currently there are plenty o ways to administer your devices using objects. You can also create Objects that have multiple attributes such that you can drop an object into another object (a group) and then republish the ruleset and get the access that you desire. However, using this sort of shorthand is the kind of stuff that can get you to fail a pen test. However, if you balance it right you can get a lot of work done by a few FW admins, and still maintain a relatively high level of security. (For examples on how a template system for server types and drag and drop would be broken, please refer to just about any firewall and DNS enforcement in a Windows environment.) Also, most FW management platforms have GUI that illustrate the network as the management platform sees it. First thing that a competent FW admin does is turn the thing off for two reasons, 1. The diagram is wrong. 2. It sucks up resources on the manager and on the client (My workstation)
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?
Cisco, and Checkpoint do this with AAA rules. The cascade through multiple firewalls is stupid because if you're dealing with something that secure that you have to go through multiple layers then hopefully you're using multiple auth factors, one of which should be time limited (SecurID). You won't be able to re-use the authorization token. Palo Alto does this but requires that you depend on an AD polling service and that you have your auth groups set up in AD properly, and know one has jacked with them. Icky.
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?
Seriously? Multitasking security configuration? Umm. this is where the "MBA" moment really shines through in you post. Each config needs to be combed for optimization, conflicts, and general nonsense. You have to do this in an iterative and detail-oriented manner, or you suck.
Manually editing text is time-consuming, fatiguing and error prone. Have a tool to automate that sort of thing is one of the fundamental reasons for having computers in the first place.
There's a great tool called vi.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
a content filter (to keep Joe Sixpack in Receiving from ogling at boobs, then Jane Nubile from HR sees it and then promptly files a sexual harassment lawsuit when she sees it). NAC devices (to enforce presence of antivirus utilities likely forced per agreements), equipment to log packets (ACTA will force all ISPs and carriers to log *every* packet across their network for 7 years. Not headers. Entire packets).
I always follow the Intensive Poulty Farming Best Practices. Both Joe and Jane are thus spayed, declawed, detoothed and lobotomised before entering the cubicle farm. Thus they have no interest in boobs and or of concepts like "sexual harassment".
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
no, that only comes with the IT degree.
Juniper IC Controller will do this for you
That is a criticism of the user, not the tool.
It's a criticism of both. GUIs by nature are ad-hoc tools that allow individual tweaking - that's their purpose in life. Granted, you could create a tool that would allow for a creation of settings that could then be applied across multiple systems, but that would be much more than a mere GUI tool.
A criticism that applies equally to a collection of automated scripts
No, it doesn't. While scripts can be run by individuals with no sense or knowledge, at least the initial creation and testing of such scripts were done by someone that knew enough to create them. (Granted, there's an assumption here that the script result is meaningful and that the script itself was written by someone with knowledge)
Why ? Graphical representations of complex systems are nearly always easier and quicker to understand than lines of text describing same.
Graphical representation of tabular data is easier and faster to understand than... tabular data?
I think the bigger problem is the presentation of the data than any difference between GUI vs Text output for the topic at hand.
GUIs are most certainly repeatable and their results can absolutely be inspected and verified.
Really? GUIs are repeatable? Have you ever done web QA? The only time it's repeatable is when the system is completely locked down and nothing changes outside of your control. And even then....
When the system behind a GUI has deep dependencies that the GUI glosses over or "flattens" for "ease of understanding", then there's plenty of openings for new unexpected behavior to crop up.
The cesspool just got a check and balance.
As apposed to giving the web server a name in the firewall and adding that name to the web server group? Ever admin a few hundred firewalls the GUI's are the slow and error prone not the text interface. The thing people seem to forget is you want the rules on the smallest required set of devices. That nearly universally means 2 as firewalls are required to be network choke points.
No sir I dont like it.
Anything that is not properly encrypted is suspect...
If I used a sig over again, would anyone notice?
Open heart surgery for example.
It is doable, no question about it, but I prefer the insight of an specialist.
By dragging and dropping stuff when dealing with firewalls you are asking for trouble. Most likely somebody will miss a complex rule or will open a security hole in an unintended way.
By being textually precise you avoid these and other possible pitfalls.
Most importantly, you can document precisely what you are doing.
All the point and click lovers always fail to explain how they can document any changes to their infrastructure in an efficient, clear manner .
their GUI makes configuring firewalls and routers fairly simple. it's just god-awful expensive, considering it's based off linux and OSS utilities.
sudo mod me up! http://capirca.googlecode.com/ "Developed internally at Google, this system is designed to utilize common definitions of networks and services and high-level policy files to facilitate the development and manipulation of network access control filters (ACLs) for various platforms. "
And Cisco isn't the only one who can handle an enterprise security infrastructure. The current Check Point line features much of what you're talking about, including building a graphical map of your network based on the information you give it so you can see how things are arranged and working.
As the parent poster said though, Belkin and LInksys are not firewalls. They are NAT capable home routers with limited ACL capability. :: Corporate security :: Trained Russian Bear cavalry.
Linksys
Yorkshire Terrier
I'm a fiscal conservative, it's a pity we don't have a political party anymore
THANK YOU ! You took the words right out of my mouth.... As I finished reading TFA I just couldn't help but scream "Keep the poster away from IT Management!!" I'm so sick of unrealistic demands being put unto us. and the way things are going it's just getting worse.
End of Line.
The only reason I can think of having a GUI automated management tool is so some dumbass that doesn't know what he's doing can appear to manage firewalls.
The only reason I can think of having a high level programming language is so some dumbass that doesn't know assembly can appear to write programs.
Some things are better off getting simpler over time. Yes, having a proper network engineer to manage your firewalls is best. But not everyone can afford -- or even needs to hire one. If their network can now be protected relatively well because of a GUI config tool, when it was not protected at all before, everyone on the Internet is better off as a result.
Don't worry, you're not.
Frankly the poster is totally correct. Manually specifying which port on which firewall needs to allow which traffic from what IP to which destination is utterly antiquated and most of all insecure and completely insufficient. Everyone in the security industry knows that, and this deficiency has spawned a huge array of commercial products trying to patch the holes up - deep packet inspection, NIDS, etc...but none of these can solve the root problem.
As an ISP network admin since 15+ years, I've been waiting for a better solution for over 10 years.
Someone needs to pull an iPhone and reinvent the whole way we manage security on the network level.
Think about it: I should just be able to say: allow this app from here to communicate with that app over there. The software should manage the configuration from end to end - that includes configuring the firewalls/access controls - on the source and destination servers themselves.
There are at least two gaping holes in current firewall management and design:
- hosts are traditionally wide open to every other host on the subnet. A great many enterprises address this by using absurdly small subnets, which is idiotic from a management point of view. The only solution is local firewalls, but if the firewall management tool doesn't automatically handle these on the same policies as the central firewalls, forget it. End result: wide open subnets.
- firewalls block based simply on ports. Basically if you can send whatever crap you want through the firewall so long as it's going on the port the firewall "thinks" is reserved for, say, a database connection. Yes, deep packet inspection helps to some extent but is hardly a complete solution. The only real solution: the firewall should have an agent installed on the local servers that not only handles the first point (the subnet issue) but also can effectively authenticate based on the originating and receiving _process_ - end to end.
None of this is really complex. The firewall management just has to include an agent that basically handles something like SElinux (at best) or just the native iptables (at least). All this functionality exists already in your standard local firewall products like zonealarm and every major vendors "security suite", the only thing missing is the central management of it from one central console where you can just say let application A communicate with application Z.
For an enterprise this would be a huge step up from the current disjointed security practices. Best of all whoever develops this first has a huge advantage over the competition and gets a bunch of vendor lock-in to boot ...
from http://www.securepassage.com
I feel the need to comment to your sig...
That mac pro mini you mention... wouldn't that be the Ipad ?
If so - 2 down, 2 to go.
Unicode killed the ASCII-art *
The top-tier firewalls, Checkpoint, Netscreen, Palo Alto, all have competent GUIs designed to manage large installations of firewalls, including global rules that apply across policies. Cisco is really the only firewall platform dependent on the CLI (and brother, that's one ugly CLI. I know! Let's take PIX and make it sort of like IOS! No! Let's take IOS and cram PIX in there! No, no, wait! I have it! We'll do both arbitrarily!) No pro I know of spends their time on the wall's command line or mangling policies in a text editor if they can avoid it. The problem is that all of the firewall vendors are too busy re-inventing the wheel with Java and Web app interfaces instead of finding an industry standard toolkit and sticking to it, so we don't get cool things like you'd find in a MacOS or iPad interface. Give it a couple years, and drag-and-drop of rules and address objects between policies will be easier than it is now, and the global rules will be smarter in adapting to new networks and hosts on the fly.
The Open Source world is perpetually 3-10 years behind the cutting edge in application design, and network admins (especially in all-Cisco shops) can get tunnel vision sometimes, but those of us who do have CISSP and GCFW on our business cards know that what the guy wants isn't unreasonable, and a lot of it will be arriving in the next few years, as well as some sexy stuff not brought up by the OP. (NIDS and Firewall and DLP as separate concepts is going away - too much crap being crammed through 80 and 443, you need the firewall to profile the traffic, too. Also, along the same lines: application specific firewalls - it only deals with web servers, or it only deals with database servers, or it only deals with SIP - are on their way up. )
The biggest problem is that there won't be a one-stop shop that does all this, and the different vendors would rather choke on an 8" DSDD floppy and die than work with each other, even if their businesses aren't actually competing directly.
The only secure perimeter is the air gap, and that inside a well-grounded Faraday cage.
I don't believe you and your citation of a secure perimeter. It's likely highly infected. Firewalls do often include NAT, so that they can watch statefull packet exchange. But I get the feeling you're new at this, so I'll leave your observations alone.
People who brag about these things, as in never's-been-breached, are usually fools.
---- Teach Peace. It's Cheaper Than War.
Well, part of what you're describing can be bought today. ...
Appliances from Palo Alto Networks do just that : User awareness, L7 identification (even in SSL) so that allowing TCP 80 or 443 doesn't mean allowing everything,
They still lack many things from Checkpoint/Juniper/Cisco (PBR or IPSec aren't fully there yet IMHO) but they're quite impressive.
On some tests I did, it was able to see random encrypted UDP P2P packets as "Bittorrent". Not to mention that many webapps are seen as protocols (gmail, gmail chat, mail.ru, yahoo finance, etc...)
Kinda weird to define security policies by user|group/application instead of IP/port. (you can still do that if it makes you feel more comfortable: use RFC ports or self-defined ports)
Sexy HW architecture with FPGAs and dedicated CPUs for each tasks, nice web interface with reporting: it's a real gap from a typical appliance firewall, but it costs an arm and a leg...
--I like 2 kinds of women : GIFs and JPEGs--
I love how you *nix guys don't ever take end users into consideration.
Because end users do not have the training, skills or experience required to properly and effectively manage today's sophisticated network security issues. Even most "*nix guys" do not.
Your gripe is essentially the same thing as expecting layperson passengers to be able to fly the jetliners instead of the pilots.
I don't think that having more network or firewall knowledge would really help with what the story submitter is really after. As someone who's part of a team that manages firewalls with 3k+ rule bases, I can say that it doesn't take a networking genius to configure a new rule for someone, and it really doesn't matter what interface you use (CheckPoint GUI, PIX/ASA command line, etc.). Well, sometimes it does... we have some environments that are so arcane/legacy/"hysterical reasons" that it's not funny any more.
The hardest part is managing the mess that's generated when you have 5 requests for changes per day, every day. You can't just put in new rules for every request, because then you have so many rules that the firewall can't keep up. When you start piggy-backing off of existing rules, it makes it hard to remove access when it's no longer needed (in the extremely rare case that someone even tells you they don't need it any more).
What we'd really like to see is a way that we can take a specific requests for access (Bob Smith's app server x.x.x.x needs SFTP access to to vendor Y's servers at y.y.y.y and z.z.z.z) and compile them into an optimized rule base (using traffic/usage stats to order the rules). That way, when Bob comes back and says he doesn't need SFTP (or we look at old stuff and ask if he still needs it), we can just remove his request from the source, and recompile the rule base, and know that it won't disturb anyone else's access. That way, your "source" rule base is basically an actual picture of what's needed in a business sense, rather than what the firewall is doing to implement it.
If we could integrate such a system into our process management tools, so that a firewall engineer only has to verify a request and schedule it for an appropriate change window to be automatically added, that would be even better.
If you look at Palo Alto Networks, you'll see that all of those features exist...For Enterprises. The real issue is that comsumer networking is slim margins. How many people are still running their original 2003 .11g firmware?
DDWRT gets you closer, but managing several "firewalls" for consumers? I don't think the average "Joe Sixpack" has more than the one at his network gateway. And they usually don't even configure that. Walk down a densly populated street and tell me how many open wifi networks you find and you'll see why a lot of these features haven't made it to the consumer market.
The real question is why the networking "prosumer" market hasn't gotten bigger. And that's mostly because of price. You could look at a Checkpoint UTM-1 that has all the features you'll looking for, logging, IPS, Content Aware Firewall, but you'll pay out the nose for it. Even a Cisco ASA is ~$700 and it doesn't have all of those features.
Would you drop a cool grand on a small box that "just sits there"? That's the mentality that you're facing.
It gives security and privacy to some degree. But it doesn't hide how much data is going through, how often, in what kind of packgages... Those can give pretty good hints that there is something else going on than visiting a normal website through https.
For a single unix server I use firehol. It is pretty easy to use its simple English-like settings file which is used to generate the iptables firewall. It's not Star Trek, not even a gui, but seems to do the simple job well. Possibly this could be run on the router.
It would be nice if you could have a program that is updated with information about how to set up various manufacturers' products, and lets you describe your setup, then programs your firewalls on the various machines.
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?
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.
Cisco Adaptive Security Device Manager is good enough GUI for me - it even shows a small diagram of your rule just to ensure you typed in everything correctly.
Also for the fabric I often jump into Cisco's Network Assistant - cheaper (free) than Solar Winds (LAN Surveyor) for a quick interactive network topology.
It seems as though a good majority of people commenting (and the original user who asked the question) actually don't work with networks much (maybe they work via a network).
Slashdot is an interesting meme that just won't die :)
Solsoft NP used to have graphical mgmt of firewalls (and other policy enforcement points). You could draw flows and have the rules configured automatically. It supported FW-1, PIX, Cisco IOS, Nortel, Netscreen, and several others. They even had the ability to draw VPNs and have those configured too. They were purchased awhile back and now can be found at http://www.loglogic.com/products/security-change-management/index.php
We already have the standard for configuring the firewall ports and NAT; it's called UPnP. It works just fine on a home network. On corporate networks it is usually not enabled due to security concerns. If the protocol designers could fix the perceived security problems with UPnP, the all the problems in the article would be solved.
Yes, one often can just click on the smiley face and have hordes of unknown, unattributed and unappreciated coders do all the work.
Yet, there's something to be said for RTFM.
Give it a shot, and if you do magically learn something, please try to pass it along...
You don't see such tools because the most important rule for us network engineers in an enterprise environment is to know what,why and how each device is doing its job on the network. As a tutor once said you should always be in control of the network and not the other way around.
We do not spend countless hours away from family life and spend an enormous amount of money on taining and certification only to later depend on a tool to automate configuration from a diagram - this dumbs down the industry as any idiot with a mouse can point and click without understanding the reason behind the pointing and clicking.
Firewalls play only one part of the network, you need to stop and have a think about what sits on both sides of the device and how complex the designs nowadays have to be in order for users to enjoy the various network services available. Only then will you realise how ridiculously narrow minded your concept is.
A GUI is an inteface not a philosophy. There's nothing that says that they're only for individual tweaking, or that making a tool that applies settings across multiple systems would be beyond what a GUI tool can do.
There's also nothing that says that whoever created the GUI interface won't be knowledgeable or able to encapsulate a scipt's function withing a graphical design.
Again you are confusing the fact that a GUI is simply an interface. There's no additional random or uncontrollable things happening on the side. If you have a set of buttons they can only be clicked or left alone, they're not going to suddenly do anything else.
The GUI just allows you to view a problem in a different way, it doesn't make the problem more or less complex. Once a script or configuration becomes very large and complex it can be just as hard to find out what's going on and just as easy to introduce unexpected problems. You can have the data in a flat file, or you can have it in a tree view, it doesn't change the data, only how it is represented to the user.
The clash of honour calls, to stand when others fall.
I don't see anything wrong with wanting to visualize your firewall rules. If done right, it could be a huge boon and might help you spot holes or weaknesses you might otherwise have missed. I don't think anyone has yet come up with such a rule visualizer, but drag and dropping seems like a great way to build rules so that the spatial part of your brain can be engaged.
If you've ever used Network Magic, it's a great tool to visualize your network. I'd love to see something similar for firewalls.
If you need web hosting, you could do worse than here
Firewall Builder
That's about as good as it gets without the risk of a PHB letting the orcs in!
-- Sig Sig Sputnik
Watchguard uses a GUI.
The Uptime Group ( http://www.TheUptimeGroup.com ) develops their own firewall for their clients. It has a central management and any change can be pushed out to all the clients or only to the clients that need it. Rules, updates etc.
Manually editing text is time-consuming, fatiguing and error prone. Have a tool to automate that sort of thing is one of the fundamental reasons for having computers in the first place.
There's a great tool called vi.
Blasphemer! Vi is not great. Vi is evil incarnate, a tool for infidels.
Emacs is great. Emacs smiles upon the faithful. All praise emacs in its glory!
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
No it doesn't. It means a quad-core, latest ATI video card, and 8GB RAM in a Mac Mini form factor.
That is NOT the Mac Pro.
If you mean the Mac BOOK Pro? Then that's the Mac Air.
The iPad is still a childs toy compared to any of the above.
Now an Apple Mac convertible tablet, THAT I still want to see.
You bring up a good point. You have no idea how many times I've been forced to tunnel SSH traffic over HTTP or SSL to get to resources I needed to use to do a job.
Nevermind the constant influx of vendors and customers, and field people or home workers on VPN.
Securing a network is tough work.
Doesn't fwbuilder do some of this for the FOSS world? Why couldn't the Poster take this and improve on it?
try pfsense
Cheap storage VM.
firewalls are also useful for consolidating access to internal machines, load-balancing, terminating remote access, and a host of other things.
Cheap storage VM.
On one machine I see, say, a thousand ssh break in attempts a day. If I change the ssh port from 22 to 578 (for instance) I just cut that 1000 down to maybe 20 + legitimate users...and those 20 are the ones to be most worried about out of the 1000! That's a win.
And what if you tunnel traffic over SSL over port 443? Wouldn't such traffic be indistinguishable from HTTPS traffic, or do they go based on typical use - ie https traffic is usually small request followed by big reply and traffic not like that is likely to be something else.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
I don't believe you and your citation of a secure perimeter. It's likely highly infected.
It actually is separated from the internet, except for a serious hodge podge dual email system. Yes, that means no web access.
Firewalls do often include NAT, so that they can watch statefull packet exchange. But I get the feeling you're new at this, so I'll leave your observations alone.
They may include it, but it certainly isn't necessary, nor has any meaning in defining a firewall. They also often include a switch. This also is totally outside the realm of firewall functionality.
People who brag about these things, as in never's-been-breached, are usually fools.
And some just flaunt their ignorance.
Note that I did not say it was invincible, just that this particular one had not been breached. I do happen to know of several others that are "unbreachable".
The cesspool just got a check and balance.
If you have no web access, you've stanched the majority of infection and cracking sources. In terms of "unbreachable", I'll cite the airgap and earthed-Faraday cage above. Nothing is foolproof, as fools are so ingenious.
NAT takes care of many problems, e.g. direct probes and their consequences. Many firewalls perform NAT, and it's needed for stateful inspection.
Only a handful of systems are uncrackable. And that's for today.
---- Teach Peace. It's Cheaper Than War.
the "unbreachable" ones meet your requirements and also have no ability for external devices to be hooked up.
The cesspool just got a check and balance.
You're not going to like this, but I know of two platforms that already do SSL intercept - they don't allow direct connection over HTTPS, but force you to accept the firewall's cert, and the firewall then handles the HTTPS traffic - essentially a MITM attack. It gets worse still, stuff like Palo Alto doesn't even need to decrypt your SSL connection - it can tell what sort of traffic is running through it encrypted. If it's SFTP or SSH, the firewall will kill the session, and block further connections.
Gigantic PITA for geeks who like to SSH across network boundaries, but the larger issue is that malware and other forms of corporate espionage are using SSH and SFTP disguised as something else, too. If you want to play Nethack on the SGI Indy you've got set up in your bedroom while at work, you're going to need to get to know your Firewall admin and ask pretty please. And then you'll need to get to know the auditors he works with, because they =will= catch that shit and whine at the CIO/CSO/(Insert boss in charge of infosec here).
Maybe it's just me, but every piece of hardware I've owned with uPnP support had an option in the bios to disable it.
Some of them took some looking around to find it, but they ALL had it.
Maybe your friend should've spent more time getting to know his hardware/software before installing it and expecting it to be secure.
User-friendly is the primary concern for consumer grade equipment, with security trailing at a distant second.
It's a criticism of both. GUIs by nature are ad-hoc tools that allow individual tweaking - that's their purpose in life.
Rubbish.
Granted, you could create a tool that would allow for a creation of settings that could then be applied across multiple systems, but that would be much more than a mere GUI tool.
Why ? Because anything that's useful must be "more than a mere GUI tool" ?
No, it doesn't. While scripts can be run by individuals with no sense or knowledge, at least the initial creation and testing of such scripts were done by someone that knew enough to create them.
So, just like a GUI, then ?
Graphical representation of tabular data is easier and faster to understand than... tabular data?
Almost always. The easiest and most obvious example: graphs.
Really? GUIs are repeatable? Have you ever done web QA? The only time it's repeatable is when the system is completely locked down and nothing changes outside of your control. And even then....
You seem to be using a different definition of "repeatable" than any I know. If it's "repeatable" it means the same actions produce the same results.
When the system behind a GUI has deep dependencies that the GUI glosses over or "flattens" for "ease of understanding", then there's plenty of openings for new unexpected behavior to crop up.
There is no inherent need for a GUI interface to be oversimplified, or less capable.
As apposed to giving the web server a name in the firewall and adding that name to the web server group?
So, two possibilities for a simple typo to cause problems from benign to catastrophic ?
Don't try to sell me :D
I despise apple - so whatever they do doesn't much affect me. I pretty much think of Apple's products as an etch-a-sketch with a filter so you can't draw naughty pictures. I was just wondering if your sig may be out of date. I think it's clear that the product you dream of there is not the one they are marketing so hard.
Unicode killed the ASCII-art *
Granted, you could create a tool that would allow for a creation of settings that could then be applied across multiple systems, but that would be much more than a mere GUI tool.
Why ? Because anything that's useful must be "more than a mere GUI tool" ?
No, because in the current topic thread what someone wanted was a GUI to look at a firewall, not an enterprise application run by a well designed GUI. It would help if you followed the thread.
Graphical representation of tabular data is easier and faster to understand than... tabular data?
Almost always. The easiest and most obvious example: graphs.
Please graph a firewall configuration in a manner that is meaningful in this discussion for configuring firewalls.
Last time I checked, firewalls consisted of data best represented in tabular format.
When the system behind a GUI has deep dependencies that the GUI glosses over or "flattens" for "ease of understanding", then there's plenty of openings for new unexpected behavior to crop up.
There is no inherent need for a GUI interface to be oversimplified, or less capable.
The topic started with the whine that firewalls are too difficult, and gee, wouldn't it be nice to just drag n drop firewall configs....
Do keep up.
I'm well aware that a proper interface to a firewall could be written. It will still require almost as much understanding to use as the current effort to write scripts. If you were to make it easier, then you're dumbing it down and "flattening" the problem domain, and all above mentioned criticisms are valid.
The cesspool just got a check and balance.
No, because in the current topic thread what someone wanted was a GUI to look at a firewall, not an enterprise application run by a well designed GUI. It would help if you followed the thread.
I am following the thread. The arguments against GUIs are nearly all predicated on using them to management complex, "enterprise" environments. Therefore, either the arguments are invalid in context (because the environment is not complex or "enterprise"), or we can proceed with the assumption that any such GUI would be "an enterprise application".
Please graph a firewall configuration in a manner that is meaningful in this discussion for configuring firewalls.
C (www) --- | ---> S
This simple diagram above showing a firewall rule allowing web traffic from one or more clients to one or more webservers could quite easily represent multiple lines of "tabular data" defining a firewall configuration, yet it can be quickly and intuitively understood even by people with little knowledge of how that specific firewall is configured, let alone the commands and syntax required to actually implement the rule(s).
The topic started with the whine that firewalls are too difficult, and gee, wouldn't it be nice to just drag n drop firewall configs....
And ? "Easier" does not implicitly mean "less capable".
I'm well aware that a proper interface to a firewall could be written. It will still require almost as much understanding to use as the current effort to write scripts.
It would not, because you would not need intricate knowledge of command syntax and scripting languages.
If you were to make it easier, then you're dumbing it down and "flattening" the problem domain, and all above mentioned criticisms are valid.
There is absolutely no inherent reason for a solution that makes a process easier to also make the results less complete. None.
What you would be doing, would be isolating the "problem domains" (managing a firewall, knowing the syntax of that specific firewall, knowing how to script changes) and removing the ones that are not essential (knowing the syntax of that specific firewall, knowing how to script changes) from the solution.
A company called Exaprotect, which acquired a company called Solsoft, made a pretty neat tool that visualized the network and you could put enforcement points onto a map based on topology and apply rules. My company uses the tool for some things in our network. It's an amazing tool once you get it up and running, but there is a level of effort and understanding of how the tool works that is involved. Sadly Exaprotect is making the tool End of Life because they didn't see enough demand/profit from it. The killer feature of it was that once you got a policy looking like you wanted, and you needed to add a subnet or host. You'd simply manipulate the object at that point in the topology then click on all the enforcement points involved (easy to do because it could track them down via the policy layout) and then click "Update Policy Enforcement Point". If anyone knows of a good replacement please let me know, we're looking for one as Exaprotect is killing this product. -K
Seriously, check out check point. It doesn't have everything you are asking for (yet) but that seems to be the closest and you can porbably talk to them about other enhancements.
I've hard good things about their "next generation" firewalls. Anyone have any comments?
Please graph a firewall configuration in a manner that is meaningful in this discussion for configuring firewalls.
C (www) --- | ---> S
This simple diagram above showing a firewall rule allowing web traffic from one or more clients to one or more webservers could quite easily represent multiple lines of "tabular data" defining a firewall configuration, yet it can be quickly and intuitively understood even by people with little knowledge of how that specific firewall is configured, let alone the commands and syntax required to actually implement the rule(s).
Hmm, that's easier to read than
Inbound port . . . Destination
80 . . . . . . . webserver.mydomain.com:8080
('. . . " -> because we cannot do tables)
Instead of not having a clue what "s" is, now I know exactly where an inbound port 80 winds up. (this one includes a little more than a basic firewall by also adding in routing - ie, proxying or NAT)
And, how do I know "(www)" means port 80? (It could be any port, www is irrelevant). What if I was running sshd on 80? What then? What if I was really sneaky and multiplexed port 80 for web and sshd via some proxy client I wrote?
This is where the GUI paradigm being discussed breaks down when you're talking firewalls. Honestly - you cannot make a GUI easier to understand than tabular data regarding firewalls, since firewalls are inherently tabular data. Don't try to fit square pegs into round holes.
Having said that - you can create a GUI/management application that allows some predefined set of configurations that might be a little easier to understand, but that would be a small subset of what we're discussing above.
The cesspool just got a check and balance.
Hmm, that's easier to read than
At a glance, absolutely. Primarily because if there are other associated ports that could go with the rule (eg: to 443) that can then be captured in the diagram but not the table. Similarly, if there are half a dozen rules, rather than just one, the graphical representation becomes even easier to understand, because the more lines of very similar text you add, the harder it becomes to pick out particular ones (and more importantly, identify errors in them). Additionally, your tabular representation contains information that is not relevant at the design/conceptual level (port numbers).
And, how do I know "(www)" means port 80? (It could be any port, www is irrelevant).
Because you've defined it elsewhere in the interface.
What if I was running sshd on 80? What then? What if I was really sneaky and multiplexed port 80 for web and sshd via some proxy client I wrote?
Then you define those things elsewhere as well. Once, so you don't need to keep repeating relatively unimportant information.
This is where the GUI paradigm being discussed breaks down when you're talking firewalls. Honestly - you cannot make a GUI easier to understand than tabular data regarding firewalls, since firewalls are inherently tabular data. Don't try to fit square pegs into round holes.
Of course you can. That graphical representations are easier and quicker to understand than raw numbers is something that's been known for centuries. Again, this is why we use graphs to help interpret data rather than starting at lines of numbers.
Having said that - you can create a GUI/management application that allows some predefined set of configurations that might be a little easier to understand, but that would be a small subset of what we're discussing above.
All you need is the ability to define your own data definitions. Which, of course, any remotely good tool would have.
Your example is 100% backwards. Consider something simple like adding a host to a standard ACL list for webservers. Why should it be any harder than simply editing a plain text file? Why should it involve some meaningless symbolism of dragging one shape into another shape? How do I grep through these shapes? How do I filter them into reports? How do I back up old configurations? How do I copy configuration from one system to another?
Why should configuring a computer system require manual, slow, error-prone, use of a GUI?
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Uh, right. That's why flow charts remain so popular.
Some things are better expressed in text; some in figures. A set of rules -- like those for a firewall -- are better expressed in text.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Your example is 100% backwards. Consider something simple like adding a host to a standard ACL list for webservers. Why should it be any harder than simply editing a plain text file?
Because editing text files is a manual and error-prone process. There's little to no input validation, sanity checking, or ability restrict access and delegate responsibilities. Just type it in, proofread, cross your fingers and go.
Why should it involve some meaningless symbolism of dragging one shape into another shape?
In what way are icons any less meaningless symbolism than configuration syntax keywords ?
How do I grep through these shapes?
You use the organisational and search constructs in the GUI.
How do I filter them into reports?
By using the reporting in the GUI.
How do I back up old configurations? How do I copy configuration from one system to another?
By exporting them to some machine-readable file.
Uh, right. That's why flow charts remain so popular.
Flow charts (and their descendants) are *massively* easier to understand and follow than something like pages of if...then statements. That's exactly why they _are_ popular.
Some things are better expressed in text; some in figures. A set of rules -- like those for a firewall -- are better expressed in text.
Why ? Which firewall's syntax are you going to express your rules in ? How long does it take for understanding of your ruleset to transfer to those unfamiliar with that syntax ? How do you delegate access and control of specific subsets of the rules ?
Not to endorse a commercial product, especially such a frustrating, one but it seems like Checkpoint had this covered many years ago. Maybe you're looking for enterprise features in a consumer product. Most of my firewall experience is close to 10 years old, but ...
> What's available for managing complex firewall arrangements? 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?
Checkpoint had a management console that could group users, machines, groups, networks, and policies, and operate on them visually in a network diagram. Then you could apply the rules generated by that diagram to any portion of or all firewalls.
> 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?
Seriously? Look up RADIUS. Plus, there were proprietary solutions in place before RADIUS was standardized.
> What's next for firewall management?"
I don't know but most of what you're talking about has been around for years.
Secure perimeters are illusions. Every machine needs its own defense. Firewalls are good for NAT, which foils a few, and stateful inspection, which fools a few more. Otherwise, internal firewalling and boundary checks are the only answer, coupled to download security hashing checks-- and those get bitten, too.
Belief in firewalls and secure perimeters are the reason that some 30% of all machines in a domain are bot'd somehow..... and protect each indivdual device, not just the perimeter.
I think you're contradicting yourself a bit here, but it's the single point of defense that is an illusion. There are many layers an ALL are important. You DO need a perimeter defense, you DO need inspection, you DO need network segmentation, you DO need machine perimeters, you DO need application defense, you DO need strong authentication, you DO need restricted user accounts/application sandboxes, and you DO need system and network monitoring. Most of all, you DO need to educate users about safe behaviors.
That is interesting, but how does a user know if the port is part of some update versus a program that got compromised by a code injection, and is dropping stuff off at a compromised machine?
I don't know if Apple handles this, but NetAlert kept application signatures. You could choose to allow once or allow always, and you'd be alerted if it wanted a new port or if the application changed in any way.
I think we'll have to agree to disagree on this.
You've now added clauses to define meanings elsewhere - and "hide" what I consider essential from the user.
I think our basic issue here is that I believe having 100% of the data given in a table is better than 50% of the data in a graphical representation (admittedly just a number pulled out of the air as there is no way to make a quantitative representation of something that will potentially be different for every single installation.)
Not only that, you've now introduced a paradigm where firewall A might be configured with one visualization regarding www, and firewall B with another, and they'll look the same unless you drill down.
So, in short, while it might seem easier on the surface, I believe it is much more complex and far more open to error than the straight tabular data. (btw, the tabular data could also have an initial column stating it's www, thus removing all your complaints about it as it now has all the viewable data. In fact, most are set up that way.)
The cesspool just got a check and balance.
I like OpenBSD PF which is essentially the same thing but with the Security of OpenBSD.
I am badly late on this topic, but I couldn't help to comment. Here's a link to public-key based firewall: http://www.usenix.org/event/usenix07/posters/lindqvist.pdf The idea is to ditch IP address-based access control lists in firewalls and to favour public-key authentication to support mobile devices. The approach is also based on end-to-end VPN rather than the popular end-to-middle VPNs. Here's a longer journal article: http://www.igi-global.com/Bookstore/Article.aspx?TitleId=39054
-- Miika Komu miika@iki.fi http://www.iki.fi/miika
Disable it in the bios of the device? Wtf, if you need security, disable it in the ROUTER. UPnP is for people who don't know how to set it manually. Why are you running your network on stock commodity hardware anyway?
I hate grammar Nazi's.