SmartDashboard on macOS

[sysroute]

Hello all,

How many of you use macOS as their primary OS? I know that Check Point don't care and most probably they will never release SmartDashboard for this OS.
So if I want to manage CP firewalls I have to start Windows VM every time? It's a bit silly because I have to have license for this Windows which will cost me additional tax.
I know many of the Linux users use WINE but I don't like this solution because it's very clumsy. Every time when I used WINE it crashed by some reason.

Have someone of you solved this issue somehow? How do you manage your firewalls from OS's different than Windows?

Thank you!

[northlandboy]

> It's a bit silly because I have to have license for this Windows which will cost me additional tax.

And what's the cost of that vs the amount your company has already paid to Check Point?

[tomersole']

we do care.

https://[your management server IP]/smartview

https://www.checkpoint.com/products/saas-security/

https://community.checkpoint.com/thr...agement-portal

https://community.checkpoint.com/docs/DOC-1974

more coming soon

[sysroute]

> It's a bit silly because I have to have license for this Windows which will cost me additional tax.

And what's the cost of that vs the amount your company has already paid to Check Point?

I never mentioned it will be paid by the company. But even if this is the case why additional amount of money should be spend?

[northlandboy]

Why would it *not* be paid by the company? Why would you buy your own Windows license to manage a company asset? That makes no sense.

> But even if this is the case why additional amount of money should be spend?

Software development companies have to make a choice about which platforms they will support. There is a cost associated to expanding that support. They make a decision one way, you are free to disagree with their decision, and choose to purchase other products. This is life.

[sysroute]

Why would it *not* be paid by the company? Why would you buy your own Windows license to manage a company asset? That makes no sense.

> But even if this is the case why additional amount of money should be spend?

Software development companies have to make a choice about which platforms they will support. There is a cost associated to expanding that support. They make a decision one way, you are free to disagree with their decision, and choose to purchase other products. This is life.

I didn't start that topic to argue with someone what is right and what is wrong. I just wanted to know how the other CP users deal with OS's different from Windows.

[PhoneBoy]

To provide a bit of background on the situation:

When Check Point designed R80, the goal was to have an outstanding UI experience for the administrator as well as flexible UI components, allowing for all monitoring and key functionality to be used on the web or mobile.

For heavy administrator usage, which accounts for the vast majority of use, a native Windows UI versus a web client was evaluated.
The native client was far superior for this use case, which is why it was chosen.

In parallel, strong API and CLI were developed as an alternate form of management.
Also, all logging and monitoring functions are native web interfaces.
You can see that with SmartView, which will be improved in R80.20 (available in Public EA now).

In the future, more web components will be added as well as mobile usage for specific scenarios.

[sysroute]

Thank you for your replies PhoneBoy and tomersole.

[Bob_Zimmerman]

Funny this should be the most recent thread in the off-topic forum. I was just trying to determine where to ask if anybody was interested in a little application I've been working on.

I'm solving the problem by building a Mac-native client which uses the APIs. It's still very much under development and is in no way ready for release.



It is screaming fast. It caches all data locally. Takes a few minutes to download everything the first time (speed seems to be processor-bound on the management), but the second and subsequent times, you can launch the application, log in, and be viewing your objects and rules in under two seconds.

The biggest downside right now is the APIs are limited. No log viewing. No hit counts for rules (Edited to add: turns out I was wrong about this! Hit counts work just fine, there's just an option I hadn't noticed.). Certain objects can't be created (though you can see them if they're created in SmartConsole). I haven't yet added any support for Provider-1. The UI is also definitely going to change from what you see in that screenshot.

I have no idea when this might be ready for release. I'm one developer, doing this in my spare time, and learning Apple's APIs as I go.

Does this interest anybody else? If not, I'll probably just keep making it for me. If it does, I might post occasional updates here as I figure things out.

[EricAnderson]

I'm solving the problem by building a Mac-native client which uses the APIs. It's still very much under development and is in no way ready for release.

I love the idea and applaud the effort. This is, I believe, a large part of why CP has put so much effort into developing/advancing API's.

I'd be happy to play with it for you, but I haven't even booted my "hackintosh" in a while, and can't be confident it'll still work - or be recent enough to be valid. I'm hoping someone else can/will give it a look and share their thoughts.

-E

[PhoneBoy]

Funny this should be the most recent thread in the off-topic forum. I was just trying to determine where to ask if anybody was interested in a little application I've been working on.

I'm solving the problem by building a Mac-native client which uses the APIs. It's still very much under development and is in no way ready for release.

You realize we are building web version of SmartConsole in R81, right?
Not suggesting your effort won't be useful, or that our web SmartConsole won't have limitations.
For logs, you can use SmartView (web-based).

[Bob_Zimmerman]

You realize we are building web version of SmartConsole in R81, right?
Not suggesting your effort won't be useful, or that our web SmartConsole won't have limitations.
For logs, you can use SmartView (web-based).

I was not aware, but web applications are universally pretty awful. You have reduced working space due to the browser's chrome on top of the application chrome. In-page state interacts in really unpredictable (and sometimes hilariously destructive) ways with the browser's back button. They constantly vomit errors into every log they can reach. Lots are entirely unusable with screen readers. I've never seen one handle both left-to-right and right-to-left languages at all, let alone well. Little to no ability to automate on the client side (if you haven't used it, AppleScript can do some amazing things without making people learn the ins-and-outs of the backend of the application). And performance is so bad the W3C made WebAssembly to run code more directly on the hardware, bringing us from the mainframe model of AJAX back to the edge computing model. Web applications are definitely better than nothing, but not by a whole lot.

With a native application, I can do things like live searching without needing the latency and throughput hits of round trips to the server. Since it downloads everything and works locally, this application should be usable over a satellite link. This isn't exactly a design requirement for me, just a nice side-effect of some design decisions I have made. This could even allow for other interesting things like working entirely offline to stage some changes, then attempting to merge them once connectivity is reestablished.

[PhoneBoy]

With a native application, I can do things like live searching without needing the latency and throughput hits of round trips to the server. Since it downloads everything and works locally, this application should be usable over a satellite link. This isn't exactly a design requirement for me, just a nice side-effect of some design decisions I have made. This could even allow for other interesting things like working entirely offline to stage some changes, then attempting to merge them once connectivity is reestablished.

If you look at how SmartDashboard operated (R77.30 and earlier), it pretty much operated on the same principle.
It downloaded the relevant configuration (objects, active policy package), effectively worked with it offline, then when you saved, it committed the changes to the server.
However, there was no support for concurrent admins, something the current design does allow for.

If you wanted to support offline usage, you'd have to figure out what happens when the objects you modify "offline" changed online and how to handle that.
But it doesn't seem like an insurmountable issue.

[jflemingeds]

Funny this should be the most recent thread in the off-topic forum. I was just trying to determine where to ask if anybody was interested in a little application I've been working on.

I'm solving the problem by building a Mac-native client which uses the APIs. It's still very much under development and is in no way ready for release.



It is screaming fast. It caches all data locally. Takes a few minutes to download everything the first time (speed seems to be processor-bound on the management), but the second and subsequent times, you can launch the application, log in, and be viewing your objects and rules in under two seconds.

The biggest downside right now is the APIs are limited. No log viewing. No hit counts for rules. Certain objects can't be created (though you can see them if they're created in SmartConsole). I haven't yet added any support for Provider-1. The UI is also definitely going to change from what you see in that screenshot.

I have no idea when this might be ready for release. I'm one developer, doing this in my spare time, and learning Apple's APIs as I go.

Does this interest anybody else? If not, I'll probably just keep making it for me. If it does, I might post occasional updates here as I figure things out.

Bug report #1.

Creates invalid clean up rule. :D

J/K. What did you write it in?

[Bob_Zimmerman]

Bug report #1.

Creates invalid clean up rule. :D

J/K. What did you write it in?

It's 100% Swift 5.2. It's a very nice language. Easy to reason about. Automatic reference counting for memory management, a good static analyzer, good exception handling capabilities.

The UI is a mix of SwiftUI (mostly the object list on the left) and AppKit (the outline for the rules). SwiftUI makes iteration very fast, but it's still pretty limited. It doesn't have the ability to do tables or outlines like the rule view needs. Maybe someday.

[Bob_Zimmerman]

If you look at how SmartDashboard operated (R77.30 and earlier), it pretty much operated on the same principle.
It downloaded the relevant configuration (objects, active policy package), effectively worked with it offline, then when you saved, it committed the changes to the server.
However, there was no support for concurrent admins, something the current design does allow for.

If you wanted to support offline usage, you'd have to figure out what happens when the objects you modify "offline" changed online and how to handle that.
But it doesn't seem like an insurmountable issue.

That's actually the thing I find most disappointing about the API. It was a chance for a clean break. You could have provided a VCS like Hg or Git (or even non-distributed; something like SVN), but you didn't. In the other direction, you could have gone full REST, but you didn't. Instead, we have this weird mix of stuff which doesn't really work the same way as anything else people might already have experience with.

There are reasons to do it this way, sure. I don't even think the API working this way was a bad decision. It just would have been really nice if we could have had proper VCS-style interaction. Particularly since defect and change management systems for programmers are far more capable than such systems for other disciplines. Ticket comes in, admin creates a pull request, change approver approves or rejects the pull request. These interaction paths are extremely well-tested, since they're what millions of programmers use to adjust their own code.

Linters to enforce conventions like sticking names in DNS. Static analysis to identify security issues, configuration conflicts, or new paths to add to testing. Continuous integration to automatically squash duplicate objects. What might have been. Oh well.

[Bob_Zimmerman]

Bug report #1.

Creates invalid clean up rule. :D

J/K. What did you write it in?

Your comment did remind me I forgot to handle cell negation. Simple enough fix. I just added a "negate" variable in my cell view, and fed it the appropriate value from the working row. SwiftUI is great for this sort of thing, as all the views are composable. The diff is just five lines, one of which is this:

.background(negate ? Color.red.opacity(0.5) : Color.clear)



Edited to add: This application is now 963 kB ready to run, or 244 kB zipped. Tons of limitations, but it's good to know I can make a useful GUI application for a modern OS within a floppy of space.

[PhoneBoy]

That's actually the thing I find most disappointing about the API. It was a chance for a clean break. You could have provided a VCS like Hg or Git (or even non-distributed; something like SVN), but you didn't. In the other direction, you could have gone full REST, but you didn't. Instead, we have this weird mix of stuff which doesn't really work the same way as anything else people might already have experience with.

There is still some "legacy" CPMI stuff there as well, which is why it's not quite as RESTy as it could be.
The latest R80.40 JHF closes some gaps, which of course will be in R81.

[Bob_Zimmerman]

For my initial development, I skipped dealing with certificates and so on. Instead, I coded it to use custom TLS trust evaluation, and to blindly trust any certificate presented by a particular IP address (the address for my personal SmartCenter). I have now fixed that. Certificate trust works like it does in Safari. If you have already visited the web UI in Safari, the current client version will trust the certificate Safari added to your Keychain. If you haven't, the client will ask you if you want to trust the certificate (though I don't currently present it, so the decision is only partially-informed right now), and if you choose to, it adds it to your Keychain with trust evaluation overrides such that the web UI will work in Safari. User credentials can also be saved in the Keychain.

I also added a picker to let you select an access layer to view. I still have a few rule ordering issues. Most notably, empty sections wind up at the top, rather than where they should be. This isn't enormously common, but I sometimes use blocks of empty sections to provide clear visual emphasis in a policy. Stuff like:

"########################################"
"########################################"
"Don't touch rules above this without talking to Zimmerman!"
"########################################"
"########################################"

This is mostly a cosmetic issue, and I'm sure I'll figure it out soon enough.

[Bob_Zimmerman]

Still working on the ordering of empty sections.

Since I last posted, I have:

• Added NAT rulebase display.
• Added a picker to choose the policy package you want to view. It also has a special entry for all layers.
• Reworked the access layer picker to show you only the access layers in the selected policy package (or all layers if that special entry is selected). If you have selected a policy package, this one has a special NAT item to let you view the NAT rules for that policy.

And here's a big one:

• Added support for multiple managements!

I had been using an application-wide database, so that last one involved figuring out how to partition that into a separate file per management. I'm still working out the details of how it should work long-term, but it's functional right now.

Still a lot left to do before it's ready for other people to use, but it's advancing.

Does anybody happen to have a spare MDS license sitting around? ;-)

Edited to add: Also added basic hit counts. Turns out I was wrong earlier, the API supports them. I just hadn't looked closely enough at the options for 'show access-rulebase'.