PA allowing IM (viber,line,zalo) | PA policy process

[searching1]

Hi,

target is to allow im apps but modify categires.

I have created a policy allowing IM and modify most categories as block. 

Policy sample:

Policy is SRC: 192.168.x.x | DST: any | Srv: any | App: IM (viberbased,im,googlebased,ssl) | Url:BLK_CATEG

BLK_CATEG (list of blocked categories)
News / Media
Travel
Vehicles
Sports / recreations
Society and Lifestyle
Social Networking
Shopping
Sex Education
Search Engines and Portals
Restaurants and Dining
Religion
Reference
Real Estate
Pornography
Political and Advocacy Groups
Personals and Dating
Pay To Surf
Online Brokage / trading
Online Banking
Nudism
Not Rated
Multimedia
Malware
Military
Job Search
Intimate Apparel / Swimsuits
Internet Watch Foundation CAIC
Internet Auctions
Information Technology / Computers
Illegal Skills / Questionable Skills
Humor / Jokes
Health
Hacking / Proxy Avoidance System
Games
Government
Gambling
Freeware / Software Downloads
For Kids
Email
Education
Drugs / Illegal Drugs
Cultural Institutions
Cult / Occult
Business / Economy
Arts / Entertainment
Alcohol / Tobacco
Advertisements
Adult / Mature Content
Abortion / Advocacy Groups
Violence, Hate and Racism
Weapons
Web Hosting
Web Communications
Application Viber based ssl google based
But still not working.

--------------–---------

User can ping internet access some allowed  site's and blocking is working. But, user can't download viber app on appstore and viber is not working "says like viber cant connect to internet" 

after removing blk_categ on policy profile it works but this is not our target policy. 

Question:

1. Categories is only for http/https traffic urls?

2. If we modify categories, do u think it can affect the applications?

3. On application under policy created we allowed im viber based googlebased. In PA process who comes first the application policy or url profile?

4. On logs/monitor traffic upon checking there's no blocking for viberpublic address.

5. How can we verify which policy categories blocking the viber?

6. any best practice in creating/blocking categories?

7. Please see below scenario

Also let's say i have policies

pol 1 

src 192.168.1.1 | dst: any 

pol 2 

src any | userid: user1 | dst: any

pol 3 

src 192.168.1.0 | dst: any

workstation ip address is 192.168.1.1

On monitor traffic

1. Why sometimes it's using/choosing the other policy and not the pol 1 since ip add and the policy 1 ive created is specific only for workstation ip add and has a higher seq. No. Than the other policy?

2. What if user1 id is using the workstation that has the ip address of 192.168.1.1 which policy will be preffered, pol 1 or pol 2?

3. Any best practice creating a policy for a specific host or ip? What process are we using to choose ip add over user id for policy?

Thanks

[searching1]

UPUPUP

[BPry]

Multiple things wrong with this but I'll take your questions first.

1. Categories is only for http/https traffic urls? No, It's all traffic

2. If we modify categories, do u think it can affect the applications? Don't modify the original cateogries just create custom

3. On application under policy created we allowed im viber based googlebased. In PA process who comes first the application policy or url profile? Everything on the PA is analyzed from top to bottom and from left to right. Therefore as long as your applicaiton is allowed it will then check your URL profile. If your URL profile is blocking the connection then you still get denied.

4. On logs/monitor traffic upon checking there's no blocking for viberpublic address. Never trust the logs from your device, as if you haven't enabled logging at start and end it can be off. If you are troubleshooting something run a PCAP.

5. How can we verify which policy categories blocking the viber? Look at the URL Filtering logs; it'll have what category it falls into.

6. any best practice in creating/blocking categories? Honestly, don't do it unless you know what the URL you are going to is actually going to fall under. Including this many block categories it would have been faster to actually create a list of what you have actually allowed. 

Okay now to the rest. 

This security policy is all messed up. One your applications that you are allowing doesn't include all the dependacies of the applications, you need to look at those and actually include them when you build a policy or it will never work. Secondly almost every application you can build out destination addresses instead of running any 'any' rule. Viber Media Inc has the IP addresses 54.225.248.192-255 and 54.225.251.128-255 currently assigned, include those and if you don't know what the addresses are build out the rule and allow it as needed. Third, don't include that large of a URL Filter with this rule; give it it's own rule after you build out the rule actually allowing your IM apps. While your at it don't include that many applications at once in one rule; I understand the want to keep your rule count down but doing so is kinda stupid unless you are actually hitting the policy ceiling. 

Keep in mind also that the ability to actually create rules based by app-id is deligated to how much visability that the firewall has on your traffic. If you aren't doing SSL decryption then sometimes app-ids just don't actually work. 

On monitor traffic

1. Why sometimes it's using/choosing the other policy and not the pol 1 since ip add and the policy 1 ive created is specific only for workstation ip add and has a higher seq. No. Than the other policy? You match the first policy that is actually created. If something is going past the first policy and hitting the second then the policies are not actually the same. 

2. What if user1 id is using the workstation that has the ip address of 192.168.1.1 which policy will be preffered, pol 1 or pol 2? It will use the first policy that it finds as a match; once it finds a matching rule it stops looking at the list.

3. Any best practice creating a policy for a specific host or ip? What process are we using to choose ip add over user id for policy? This doesn't really matter; if you have someone that moves around and needs specific access then build out their rule based on their user id. If you know for a fact that one machine that has a static address needs access to one specific thing that most others don't then build it by IP. The big thing to remember is that depending on your user-id setup you can have a slight delay in when a user-id is actually assigned to the IP that the user is currently using. 

I would really look at some different articles and read them and train up on how Palo Alto does things. All of these are questions that while I don't think anybody on the Live community minds answering, you included so many of them all in one post that could have been easily researched that taking the time to respond to them isn't something that most will do. Try to research your questions first and then when you do have to ask the community a question keep it shorter; you are by far more likely to get an answer 🙂