Enterprise style Central Management Interface - {Now $1900}

dingo

My implementation does not run on pfSense. It is a standalone application to manage infrastructure. it should not be run physically on the pfSense firewall itself, but yes could probably be turned into a "application". CMI is a good start but Im going way further down the road then CMI has gone so far.

Jonb

Just as a suggestion I have used Checkpoint firewall in the past and the way they have done it is:

The main firewall holds all the settings
Then the remote firewalls have their info pushed out to them

But to manage all of this there is an exe application that connects to the main firewall. All the config and rules you create you then select what firewall these rules apply to. After you hit save it prompts what firewalls to update after hit ok and it rolls out.

This thing I did like about the Checkpoints is that they had a drag and drop firewall creation in the app which did speed things up.

If any screen shots are helpfull I can post.

kapara

I see one issue with this bounty and probably similar to others is if it were to be completed, it would probably require tremendous maintenance since anytime items might be changed or added into pfSense they would have to be updated in this solution. And due to the fact that people would become heavily dependent on this interface it would probably need to be either updated or patched with each release. That may or may not require support from the core pfSense team. This solution might be easier if we were to use 1.3 as an appliance because (Correct me if I am wrong) anything that were accessible via the pfSense gui would be fairly easy to add to this appliance since its guts would be fairly similar or how a call is made would be similar when making a request via the web interface. (Correct me if I am wrong please). My concern about this solution being a separate application, ie…not built similarly to the existing pfSense is it would make it very time consuming to update and might decrease the amount of people who could work on it or that would be willing to support updating it. Dingo, You mentioned that with your solution you would be looking far past what the m0n0wall-CMI is capable of doing or what it could do. My question is does your solution have the possibility to eliminate the desire of other to be willing to contribute time to this solution? I am not a programmer and could be completely off track, and if so would be more than happy to be corrected. Maybe explaining more about how your solution would work would be a good idea.

Thanks,

Mark

dingo

My solution takes into account future growth, it accomodates data structures based on the xml config file
by dynamically loading data, and parsing it for variables. Though i am not conceptually happy with the way mono
interacts with its hosts via backup/restore, I believe a SSL pipe for communication of XML data is a more likely solution
the system would have to be keep in sync with pfSense releases, or automated enough to update itself when new
releases came out. It must also understand packages installed, and hopefully be capable enough to also configure them.
it will be syslog capable. so all your logs are belong to us…. it should also be portal capable of digging into host rrd traffic
graphs also, something i need to research more deeply. I also belive at some time managed firewalls should be webless,
meaning no http running. now all this requires some interaction with the developer team and buy in from the design perspective.
they should also be monitorable, and you should be able to mass depoly templates to all managed systems in emergencys
like new firewall rules, or config data to mass update all systems. I am of the old school where i belive in the minimal processes should
be running or installed on a firewall. Though we all have our needs. This will be a centralized system, though it might be designed to run
on a pfSense appliance as a base

mastrboy

just one suggestion, if any of you are going to make an "application/binary" instead of web based for this, please make it OS-Independent.. Not everyone use windows or even have a legal windows license..

I would prefer a GTK/QT based app, as it can run on most systems. but overall i would prefer it to be web based with alot of ajax..

I might chip in some money for this if it looks good enough feature-wise.

dotdash

For my part, I'd like to see mon0wall-cmi extended, or something similar.
I'm going to put the following caveats on my portion of the bounty:

Must be open-source.
Must be web-based.
Must run on FreeBSD. A package for 'pfSense-Appliance' would be fine, but it seems it might be easier to make the application first, and then create a package. Support for Linux/Windows/whatever is nice, but not important to me.
Must have option to leave existing ssh/https management. I still need the box to be accessible to a tech/manager at the site. In other words, the app should not force me to use it as the only way to manage the box.
Must be able to view status and manage all firewalls centrally. (I know, Duh…)

Features that I think would be nice:

Main view configurable similar to the pfSense dashboard: you could choose to show VPN status, CARP status, etc.
Ability to email alerts.
Having centrally-maintained alias' that could be sync'd to all firewalls.
Periodic config backups.

Jonb

You could use java based if you wanted it os independant.

sullrich

@Jonb:

You could use java based if you wanted it os independant.

Gross. Please do not use Java. I can promise you that a majority of the pfSense developers will not touch anything that runs on Java. HINT: you are going to be limiting contributions if you do.

kapara

So besides Dingo, is there anyone else who might actually be able to contribute to the developement of this product/solution? So far it seems like only Dingo has mentioned any serious interest in this bounty from a deveopement standpoint…ie taking on the bounty. Of course I would prefer a solution which would have developement support from a larger group of members, but as it stands....most of the devs do not seem to be interested in this bounty for possibly several reasons...too busy with other bounties, do not consider this bounty something which would benefit the pfsense project...or the bounty is not high enough....If I missed somehting please fill in the gaps. As it stands, I really would prefer to stay with the pfSense product, and since I am not able to code this on my own I would probably go with a solution which Dingo would come up with. Pity because I think this would really be a great addition to the pfSense. Even for people who do no manage multiple customers but might have a main office with satellite offices would benefit from this. If anyone has any suggestions on how we might be able to gain more interest in this bounty please let me know. I am not easily offended so if you think I am off my rocker on this.. :P Let me know.

If the solutionDingo has would be supported by other users..ie maintaining... then great!

Peace...

Mark

sullrich

I will be helping out longer term but will not be participating in the bounty. If for some reason you all use some wacky language (like java) then I will be putting my efforts behind http://m0n0wall-cmi.sourceforge.net/ … I would like to see http://m0n0wall-cmi.sourceforge.net/ being used as a base but I cannot stop whoever claims the bounty.

cybrsrfr

@sullrich:

I will be helping out longer term but will not be participating in the bounty. If for some reason you all use some wacky language (like java) then I will be putting my efforts behind http://m0n0wall-cmi.sourceforge.net/ … I would like to see http://m0n0wall-cmi.sourceforge.net/ being used as a base but I cannot stop whoever claims the bounty.

I agree with everything Scott said.

@dotdash:

For my part, I'd like to see mon0wall-cmi extended, or something similar.
I'm going to put the following caveats on my portion of the bounty:

Must be open-source.

Must be web-based.

Must run on FreeBSD. A package for 'pfSense-Appliance' would be fine, but it seems it might be easier to make the application first, and then create a package. Support for Linux/Windows/whatever is nice, but not important to me.

Must have option to leave existing ssh/https management. I still need the box to be accessible to a tech/manager at the site. In other words, the app should not force me to use it as the only way to manage the box.

Must be able to view status and manage all firewalls centrally. (I know, Duh…)

Features that I think would be nice:

Main view configurable similar to the pfSense dashboard: you could choose to show VPN status, CARP status, etc.

Ability to email alerts.

Having centrally-maintained alias' that could be sync'd to all firewalls.

Periodic config backups.

I agree with everything dotdash has said.

I'm planning on working on this and starting by extending http://m0n0wall-cmi.sourceforge.net/. I believe a multi-platform application such as this will work great with PHP. It would be an ideal package for the PFSense Appliance I would even go so far as to say that it validates the need for the PFSense Appliance.

As I have said before PHP will work on every Operating System. PHP is scalable if you don't believe me ask yahoo.com in fact for that matter go to php.net look at the bottom left hand corner and you will see that the main PHP mirror is provided by yahoo. If you want to learn why they provide the mirror read http://www.radwin.org/michael/talks/yahoo-phpcon2002.htm. Still not convinced IBM backed Linux (too bad they didn't choose FreeBSD) and it its popularity in businesses skyrocketed for a year or more now IBM has done the same the for PHP. Oracle support soon followed with a PDO extension for Oracle. Zend has also made a deal with Microsoft to improve PHP on Windows (It already outperforms some Microsoft web technologies). PHP has a vast developer base and that means many potential contributors to this project.

A desktop application often locks the application to one computer. A web application however can be accessed by several groups of people from anywhere.

Next week I will have time to begin contributing to this project. I would like a guesstimate from Scott or other core admin for a snapshot download of the PFSense Appliance. So I can load it and turn m0n0wall-cmi into a package. My plan is to install it. Then play with it with m0n0wall and make some of the class names more general. For example I noticed one class name was prefixed with m0n0wall and the database class has mysql in its name. Will add PDO as an option to the database class. Then start extending features to include PFSense. Once the system can handle PFSense and m0n0wall then begin to extend the CMI features. The more contributors the better especially if they are willing to help out beyond the life of the bounty.

Best Regards

eri--

I will be helping out longer term but will not be participating in the bounty. If for some reason you all use some wacky language (like java) then I will be putting my efforts behind http://m0n0wall-cmi.sourceforge.net/ … I would like to see http://m0n0wall-cmi.sourceforge.net/ being used as a base but I cannot stop whoever claims the bounty.

+1

kapara

I am happy to hear more support on this. Since there is support for having it be based on m0n0wall-cmi….PHP.....etc then I am for having this bounty be based on that solution also...or at least my contribution..$$$. I have implemented several pfsenses at several customer sites but would like to introduce a managed services solution similar to what Iomega is doing with Juniper Firewalls. This solution would finally allow me to build a business solution which would be able to generate revenue for my business. Once the money starts to flow I will have more to contribute...but I am starting at ground level right now...Still struggling with ways to standardize the boxes and keep them under $150...Dell boxes work for now but looking for something more professional.

The more contributors the better especially if they are willing to help out beyond the life of the bounty

As I mentioned before, I don't see this bounty as simple as adding a new feature with does not change much after building it. I do believe this type of solution will need constant maintenance with every build so I accept that even after the inital product is created it will need continued financial support. Once I can get this type of solution in place, I can begin to sell it to my customers as a managed service and will continue to contribute to this solution…

I have a mixed enviroment which I support...Cisco, Juniper, Sonicwall..pfSense....etc and have been on the fence on finding a solution to standardize on because of the issue of cost and managing all solutions. When I saw the m0n0wall-cmi it was the turning point for me where I realized that this could really be a final answer to my desire to provide managed firewall services without having to either charge or spend tremendous amounts of money to either support or provide as a service.

Anyways...my initial bounty is not final and I do plan to add more as this progresses...ie more money comes in to the coffers.

This might be part of another bounty but I did hear mention about SQL connectivity..I really like the idea about being able to generate reports which could be presented to my my customers as part of the provided service.

Mark

mastrboy

@Jonb:

You could use java based if you wanted it os independant.

:( the bounty is for a management interface not a memory consuming good for nothing application

Juve

Agree with a lot of things, mostly the one that Java should not be used.

dingo

god no NOT JAVA….. as i said it will be designed to work in appliance mode, it does use the base of monoCMI but also is being extended to
meet other needs and requirements I also have. such as secure communications to firewalls/appliances and additional monitoring functionalities
enbedded. My overall goal honestly is to functionally be capable of monitoring and management of pfsense, m0n0wall, askoiza, FreeNAS and
potentially other m0no/pfsense based derivitives. as they all have some commonalities. I plan to develop this to meet the needs of not just pfSense,
but other BSD based appliances. We have a common framework BSD, PHP, XML that is central to all these. I have additional functionality I require
from a design and architecture standpoint. as I also plan to use a standard (REST) while developing this application.

Jonb

Fair enough only a suggestion just incase PHP wasn't an option, but yes memory hog it is.

kapara

I have been doing some research on solutions that might be able to be used for this solution. My thinking is rather than reinvent the wheel that there might be the possibility to incorporate solutions that have already been developed into this solution. In doing my search I made sure that any information I found did not involve Java since that seems to be an undesired application. All the links either are built for BSD or are compatible. Some use XML and as far as I could see all use PHP. All look to have the same licensing ie..GNU General Public License (GPL). Some of the links are more geared towards a network monitoring solutions…ie servers and applications which may or may not be something that could be part of the solution or as plugins requested via new bounties. Either way I hope that the information can help with the project.

Thanks,

Mark

http://sourceforge.net/projects/node-runner/

http://snm.sourceforge.net/

http://sourceforge.net/projects/ntm/

http://sourceforge.net/projects/hexsys/

http://sourceforge.net/projects/netsaint/

http://sourceforge.net/projects/nav/

cybrsrfr

Another requirement for my bounty. Sorry this thread keeps throwing suprises that I didn't realize would even be considered.
1. Must not be GPL.

If I wanted to use GPL I would use Linux and a Linux firewall.

The license is one major reason I like PFSense. That is also why I want PHP PDO support in this so that there is a non GPL database option.

If this management system does find itself with a GPL license then I believe you will find that development will get split so that there will be a central management system that will harmonize closely with PFSense's license.

sullrich

I will not touch anything that is GPL. Do your own homework on GPL vs BSD. This is not the place to open that can of worms since its been hashed to death on various lists such as FreeBSD's own lists.