After migration from Checkpoint, any tips?

[steveo]

All,

We recently migrated from Checkpoint to PANOS (via the conversion tool) and so far things are looking pretty good. The next step of our project is to convert port based rules to app type rules and I wanted to get some feedback, tips, etc from others that have done the same thing..

We have about 550 security rules and would love to be able to consolidate, and generally rework everything going forward..

So, what do you think? What should we make sure we do or don't do? Any custom reports we should create to help with the task? Anything else ??

Any and all help is greatly appreciated!

Thanks much!

-Steve

[mikand]

In my opinion you shouldnt rely entirely on appid but rather appid + service (service is the PAN name for ports). Preferly using custom service but using "default" should be fine too.

The point here is to setup your PA device like a SPI firewall and then add application identification to go into the NGFW mode.

The reason for this is that in order to successfully identify an application the firewall must let some (or more) packet(s) through. If you set "service:any" this means that ALL ports will be forwarded to your device you try to protect and if you are really unlucky this single packet (or these few packets before the flow is successfully identified) will do bad stuff to your device.

At first it might seem like climbing mount everest in order to go through 550 rules but I think its still doable. Take them in batches and take short breaks in between and you should be able to go through them all in a day or two 🙂

To make it easier to maintain in future a good idea might be to organize your rules by destination ip/network. So rules regarding server X are bundled close to each other. This also means that, depending on taste, it might be good to avoid aggregate too many rules into one.

For example

src:NMS

dst: server1, server2, server3

appid: snmp

service:default

src:Admins

dst: server1, server2, server3

appid: ssh

service:default

vs.

src:NMS

dst: server1

appid: snmp

service:default

src:Admins

dst: server1

appid: ssh

service:default

src:NMS

dst: server2

appid: snmp

service:default

src:Admins

dst: server2

appid: ssh

service:default

src:NMS

dst: server3

appid: snmp

service:default

src:Admins

dst: server3

appid: ssh

service:default

[steveo]

So there isn't really a need to turn services off once you have an app rule, more so just add the app rule to your existing service rules, you could remove the service rules later, but it might be better just to leave them in there.. I got ya..

What about reports that were helpful for you to get that stuff under control?

Or anything else I need to start looking at?

Thanks much!

-Steve

[mikand]

Depends on how well documented your environment already is.

A way to (hopefully) need to convert less rules could be to ask each server owner if the rules you currently got in your CP is still valid.

Perhaps some servers have been removed or some port/protocols is no longer in use.

This is for example how I would setup security rules for a webserver running TCP80 (http) and TCP443 (https):

Instead of a single rule which says something like:

1)

dstzone: DMZ

dstip: <serverip>

appid: web-browsing, ssl

service: any

action: accept

log option: log on session-end

2)

srczone: any

srcip: any

dstzone: any

dstip: any

appid: any

service: any

action: deny

log option: log on session-end

I would go for:

1)

dstzone: DMZ

dstip: <serverip>

appid: web-browsing

service: TCP80

action: accept

log option: log on session-end

2)

dstzone: DMZ

dstip: <serverip>

appid: ssl

service: TCP443

action: accept

log option: log on session-end

3)

srczone: any

srcip: any

dstzone: any

dstip: any

appid: any

service: any

action: deny

log option: log on session-end

But again its a matter of taste along with how strict you wish to protect your golden eggs.

Regarding log-option the last "log and deny" rule will only need "on session-end" (since the session ends with the deny ) however the accept rules might need "on session-start" aswell (good for troubleshooting otherwise the client will show up in the logs only after the connection is reset or fin/acked). You need "on session-end" in order to get transmitted volume and some other parameter which I always forgets (appid?).

Another methology is to place your PA inline (using virtual wire) or in tap-mode (spanned port on the router/switch in front of your current CP setup) for a week or two (or even a month) and then generate reports to see which traffic you actually have in your network and from that build your ruleset (of course at the same time comparing with the old ruleset but this way you will see which ports/protocols (applications) is still in use today in case the server owners isnt helpful regarding documenting what their servers are doing to the network).

[steveo]

Well, we've already migrated to the PAs which has been in place for about 2 weeks now.. We're running various reports to see what rules are hit, then the thought was to enter an App rule above then, then disable the service rule... Although you mentioned keeping the service rule in place even after the App has been enaled... That's something else we're looking at too..

Lots to do!

Thanks a bunch for the pointers!

-Steve