Presentation is loading. Please wait.

Presentation is loading. Please wait.

Proxysg policy optimization and troubleshooting

Similar presentations


Presentation on theme: "Proxysg policy optimization and troubleshooting"— Presentation transcript:

1 Proxysg policy optimization and troubleshooting
Thank you for joining today’s Blue Coat Customer Support Technical Webcast! The Webcast will begin just a minute or so after the top of the hour to allow today’s very large audience sufficient time to join You may join the teleconference through the numbers provided in your invite, or listen through your computer speakers Audio broadcast will go live only when the Webcast begins The Presentation will run approximately 60 minutes There will be a 30-minute Q/A session thereafter Please submit questions using the Webex Q/A feature!

2 ProxySG Policy best practices
Jason tinsley Sr. Consultant, Professional Services September 15, 2015

3 Agenda ProxySG Policy Structure Optimizing Policy Performance
Troubleshooting Policy Q&A

4 ProxySG Policy Structure
Policy Construct

5 Policy structure Topics Policy Overview General Best Practices
Policy Options Layers Rule Triggers and Actions Policy Flow VPM vs CPL

6 Policy Structure ProxySG Policy Subjective Powerful Flexible
Policy Formats CPL (Content Policy Language) VPM (Visual Policy Manager) Hybrid Blue Coat Policy Overview: Subjective. Many variations based on deployment method, company policies, and even personal preference. <click> is a powerful tool that allows administrators to create and apply flexible policies in their network. This flexibility utilizes an extensive set of conditions, properties, and actions, which give us the ability to create nearly limitless rule combinations As you become more familiar with policy (CPL and VPM), you may become confused as to whether you want to build your policy with CPL or with the VPM, and will no doubt want to know the best way to achieve a particular policy or set of policies, but keep in mind that sometimes the best method will be a hybrid of the two. So with all these various methods, what is the best/simplest way of constructing your policy?

7 Policy structure General Policy Best Practices
Express Separate Decisions in Separate Layers Easier to Maintain Keep Policy Logic Separate & Distinct One Layer or Two Adjacent Layers Be Consistent Use Comments First we’ll cover some of the General Guidelines: It is all well and good to create this “multi-layered, all-in-one” policy, that does everything you want, but you will need to remember that you will have to maintain that policy and it can be very easy to get lost in the weeds. <click> With that in mind, you will want to keep your policy decisions as independent as possible and express them in layers; particularly one policy per layer or two adjacent layers. This will not only make it easier to maintain, but will help to prevent you from creating rules with the unintentional result of canceling out the action of other rules. As your policy grows and becomes more complex, maintenance will become a significant issue. Maintenance will be easier if the logic for each aspect of a policy is separate and distinct. So the essence of your policy’s foundation is: make policy decisions as independent as possible, and express each policy in one layer or two adjacent layers. Example on next slide.

8 Policy structure Default Blue Coat Policy Policy Flow Allow Deny
Admin Controls SSL Auth Global Rules Exceptions to Global Rules Additional Actions (Content Analysis, Logging)

9 Policy structure ;Default Policy is DENY Define subnet corporate_subnet /24 end ;First, explicitly allow access to only our users <proxy "Web Access"> client.address=corporate_subnet ALLOW ;Next, impose any authentication requirements <proxy "Web Auth”> authenticate(corp_realm) ;Next, begin to exclude specific types of requests <proxy “Web Filter"> url.domain=playboy.com DENY category=(gambling, hacking, games) exception(content_filter_denied) ;Next begin exceptions to the general rule <proxy "Restricted Access"> group=execs, managers url.domain= fantasyfootball.com ALLOW In this example we have broken out the different sections by function to help show the different policy layers. --Explain slide, and use of the semi-colon in policy.-- Notice how when we use strictly CPL how the policy can tend to run together? This is where the VPM can help by segregating the policy layers in an easier to read format. <click>

10 Policy Structure

11 Policy structure Policy Options Policy Options
Here we can see where to set the Default Policy. Configuration  Policy  Policy Options Allow or Deny This is where we can also set the Policy Evaluation Order

12 Policy structure Ordering of Layers Layer Type Logical Implementation
<admin> Admin Authentication Layer Admin Access Layer <dns-proxy> DNS Access Layer <proxy> SOCKS Authentication Layer <ssl-intercept> SSL Intercept Layer <ssl> SSL Access Layer Web Authentication Layer Web Access Layer <cache> Web Content Layer <forward> Forwarding Layer Blue Coat policy supports several types of layers. If you are using the Visual Policy Manager (VPM), the layers are labeled with logical descriptions and the ordering of the layers displayed in the Policy layer selection menu reflects the preferred ordering of the layers in policy. If you are writing CPL, the equivalent layer types are shown here on the left column: It would also be a good idea to name your layers based on what function of filtering they are providing. In the VPM it is evident as to the name, but you can rename them as well as number them. In the CPL you can also name the layer. <examples of both in the next slide>

13 Policy structure Admin Authentication Layer
Authenticate/Force Authenticate ProxySG Admins Admin Access Layer Allow Read-Only/Read-Write Access to ProxySG Admins SNMP Access

14 Policy structure DNS Access Layer Modify DNS caching behavior
Take actions based on DNS responses SSL Intercept Layer Intercept/Tunnel SSL Traffic Preserve Untrusted Issuers (Self-Signed Sites)

15 Policy structure SSL Access Layer
Allow or Deny Access Based on SSL Information Modify SSL Validation Behavior

16 Policy structure Web Access Layer Allow/Deny Web Traffic
Log Web Traffic Notify Users Send Exception Pages And More….

17 Policy structure Web Authentication Layer Authenticates Users
Web Content Layer Sends Request/Response Traffic to ICAP Services Modify Caching/Bandwidth Behavior

18 Policy structure Allow/Deny Trace Force_Deny Exception
To understand the integrity of policy, we first need to understand how that policy is made up. This would be a good time to look at exactly what the proxy policy is looking to evaluate. Triggers and Actions CPL rules consist of triggering conditions and actions VPM grouped the available triggers into multiple columns CPL Triggers contain an “=“ Just as you can have multiple triggers, you can also have multiple Actions on a single rule; such as Allow & Trace & Bandwidth Mgt. <click> Allow/Deny Trace Force_Deny Exception

19 Policy structure

20 Policy structure

21 Policy structure VPM CPL User-friendly Can be scripted Graphical
Using the Visual Policy Manager (VPM) versus Content Policy Language (CPL) VPM User-friendly Graphical Easy to use Preferred method of configuring policy for most administrators Supports subset of the functionality available through CPL CPL Can be scripted For implementing policy not available in the VPM Using the Visual Policy Manager (VPM) versus Content Policy Language (CPL) The VPM was designed to provide a user-friendly way for administrators to quickly create and install policy. While the VPM is the preferred method of configuring policy for most administrators, due to its ease of use, it currently supports only a subset of the functionality available through policy. For implementing policy not available in the VPM; administrators can choose to maintain only a local (CPL) policy file, or you can also create a CPL layer in the VPM which allows for all the same syntax and configuration as the local file. <click>

22 Optimizing Policy Performance
Policy Optimization

23 Policy performance Topics Rule Placement Subnets URL Conditions
Combined Objects/Conditions Server Response-Based Objects DNS-Based Objects Layer Guards Deny vs Force Deny Regular Expressions ICAP Best Practices General Guidelines Place Rules Most Likely to Match at the Beginning of the Layer <click> Place Like Conditions Together Within the Layer If your policy contains layers with hundreds of rules, you can optimize policy evaluation by placing rules with like conditions together. Even though the number of rules is the same, the compiler is able to apply optimizations to the policy. This should be done only if the ordering of the rules within the layer does not change the intended behavior of the layer. Use Subnets When Possible Select the Appropriate URL Condition This goes back to knowing the triggers and what exactly you are filtering for (scheme, url, domain, file path, file-extension…) Use Definitions to Minimize the Number of Rules Fewer rules means faster processing Use Layer Guards to Prevent Layers from Being Evaluated Unnecessarily layer guards can be implemented to first check if the common condition to the group of policy rules is true before rule evaluation begins. Now let’s take a look at a few examples of optimizing our policy:

24 Policy performance Rule placement speeds processing:
Typical Implementation <proxy> url.domain= DENY url= DENY url= DENY url.domain= DENY im.buddy_id=bill DENY url.domain= DENY im.buddy_id=bob DENY Optimized Implementation <proxy> url.domain= DENY url.domain= DENY url.domain= DENY url= DENY url= DENY im.buddy_id=bill DENY im.buddy_id=bob DENY Rule Placement: In this example we are assuming that users will visit those domains more often than Bill or Bob use their chat application. So, if your policy contains layers with hundreds or even thousands of rules, you can optimize policy evaluation by placing those rules that are most likely to match at the beginning of the layer. Since layers are evaluated only until a rule matches, placing the rules most likely to match at the beginning of the layer will provide a performance benefit because the rest of the layer does not need to be evaluated. *Be cognizant that this can be done only if the ordering of the rules within the layer does not change the intended behavior of the layer.

25 Policy performance Rule placement speeds processing:
Typical Implementation <proxy> client.address= DENY client.address= DENY client.address= DENY client.address= DENY Optimized Implementation <proxy> client.address= /30 DENY Use of Subnets *what are the common variables? – in this case all are clients within the same subnet utilizing the same action. When implementing any policy that involves IP addresses, use subnets if at all possible. Instead of referencing , , , and , use /30. For lists of IP addresses that cannot be referenced by a single subnet, or for lists of subnets, the define subnet definition should be used which we will see in a future example.

26 Policy performance url.domain=company.com url.domain= url.domain= url.path=”/cgi-bin/” url= url= Use the Appropriate URL Condition The most common policy rule involves some form of a URL. Often, administrators use the url= condition because it seems the most straightforward, although in many cases another condition would better accomplish the desired result. When adding a URL-based policy rule, determine whether the desired decision should be based on the domain, subdomain, the domain+path, a portion of the URL, or the complete URL. For a full list of conditions, be sure to consult the Content Policy Guide. <click>

27 Policy performance Protocol Host Port Path File Extension Query url.scheme= url.path= url.path.regex= url.query= url.query.regex= url.host= url.host.regex= url.address= url.port= url.extension= url.domain= url= url.regex=

28 Policy performance Place Common Items Into a Condition (Combined Policy Object) Typical Implementation <proxy> client.address= /8 category=(gambling) OK client.address= /16 category=(gambling) OK client.address= category=(gambling) OK client.address= category=(gambling) OK category=(gambling) exception(content_filter_denied) Optimized Implementation define subnet test_network /8 /16 end <proxy> client.address=test_network category=(gambling) OK category=(gambling) exception(content_filter_denied Blue Coat policy supports the use of definitions to bind a set of conditions, actions, or transformations to a user-defined label. More importantly, implementing definitions and later referencing those definitions in policy rules results in faster policy evaluation than using multiple policy rules to accomplish the same thing. Explain example: *what are the common variables? - category Fewer rules to evaluate means faster policy processing. If there is a way to reduce the number of rules and have the resulting policy accomplish the same thing as the original, that is the preferred policy design.

29 Policy performance Server Response-Based Objects
Must wait for a response before processing If site access fails from proxy to OCS, can result in unexpected behavior Example: <proxy> ALLOW condition=Whitelist DENY http.response.apparent_data_type=(executable, cabinet) DENY condition=Blocked_Categories If the request is blocked upstream, the request results in a Service Unavailable instead of a Forbidden Solution: User layers and layer guards to minimize traffic checking response-based rules

30 Policy performance DNS-Based Objects
Overhead associated with doing queries Host (DNS-based) Object If DNS is slow to respond, performance will suffer If hostname doesn’t have RDNS entry, request will fail Solution: Minimize use of DNS-based objects and restrict DNS lookups More information at: NSlookupsontheProxySG

31 Policy performance Layer Guards
<Proxy “Corp Web Access”> group=corporate_user url.domain=competitor.com DENY category=(gambling) exception(content_filter_denied) Layer Guards: allow execution/evaluation of a layer upon condition match When creating layer guards in CPL, the condition goes on the same line as the Layer identifier. In the VPM, it sits above the rule set. Any rules below a layer guard will only be read if the condition of the layer guard is met.

32 Policy performance Layer guards allow execution of a layer upon condition match Typical Implementation <proxy> authenticate(myrealm) group=hr user=bluecoat\bob.kent OK group=hr url.domain=mercurynews.com OK group=hr url.domain=sfgate.com/jobs/ group=hr url.address= DENY group=hr category=(news/media) exception(content_filter_denied) Optimized Implementation <proxy> authenticate(myrealm) <proxy> group=hr user=bluecoat\bob.kent OK url.domain=mercurynews.com/hotjobs OK url.domain=sfgate.com/jobs/ OK url.address= DENY category=(news/media) exception(content_filter_denied) Describe example with attention to common conditions & Layer Guard usage. <click>

33 Policy performance Layer Guard – VPM Example

34 ALLOW DENY Deny Vs. Force Deny: DENY FORCE_DENY Policy performance
Category = (suspicious) DENY <policy> Category = (suspicious) Force_DENY <policy> Client.address = ALLOW <policy> Client.address = ALLOW Deny can be over-written in policy, Force_Deny cannot. Authenticate and Force_Authenticate Use of Force Deny is optimal as well, as once there is a Force Deny match, no more web access filters will be evaluated, thus saving time and CPU. ALLOW DENY

35 Policy performance Authenticate Vs. Force Authenticate
NOT the same as Deny/Force Deny! Authenticate – Does not ask the user to authenticate if the request will be denied Force Authenticate – Asks the user to authenticate even if the request will be denied If performance is more important, use Authenticate If policy requires all requests be associated with a username, use Force Authenticate More information at: ontent/Solutions/Authentication/IWA/IWA_policy_ta.htm

36 Policy performance Regular Expressions
Use Only When Absolutely Necessary CPU-intensive Often Misused or Used When Not Necessary Although not recommended, we will go ahead and look at a few of the common Regex implementations and discuss their liabilities. Conditions using regular expressions, while extremely powerful, are the most CPU-intensive policy that you can implement, and are therefor not recommended. Regular expressions are used because admins are not fully aware of the numerous conditions available, or simply do not understand them. This results in sub-optimized policy and, in many cases, also results in the regular expression matching content that is unintended (in addition to the content it is desired to match). In most cases where regular expressions are used, an alternate solution is available which will not only result in faster policy processing, but prevent unintended matches. Let’s take a look at some common examples. <next slide>

37 Be careful with special characters: \ ^ $ . | ? * + ( ) { } [ ]
Policy performance Be careful with special characters: \ ^ $ | ? * ( ) { } [ ] * is not a wildcard! * or .* are almost always unnecessary! Be specific in what you are looking at: Yes Avoid url.host.regex url.path.regex url.query.regex url.regex (the entire URL) Here we see a list of common Meta-characters. I’d like to draw your attention to the “splat” or asterisk, as it is commonly mis-perceived and used as a wildcard… Below we have some examples with the focus on being as specific as possible. A full URI can contain a large amount of characters, and the wrong use of regex will cause the policy to evaluate every single character for every transaction. That is a large CPU cost.

38 Be specific in what you are looking for:
Policy performance Be specific in what you are looking for: Regex Finds url.host.regex=\.com$ Finds hosts ending in “.com” – note that the period is escaped url.host.regex=x+ Matches “x” one or more times url.host.regex=x{2,5} Matches “x” 2 to 5 times url.path.regex=^\/bad-directory\/ Finds all URLs that begin with “/bad-directory” url.query.regex=login=matt Finds query strings that contain login=matt (anchor this if possible) Here are a few more examples, and I would like to draw your attention to the top example. Here is the correct use of the regex for the host of .com, an incorrect value (url.regex) would also capture the file-extension of .com which may or may not be intentional. We don’t want to advocate the non-use of regex, but just want to impress that it is not always practical, because not all admins are fluent with regex, and it can make your policy more difficult to read. But if you do decide to use regex, be as specific in your queries as possible! --you are not trying to code, you are just writing proxy policy.

39 Policy performance Audit Policy Periodically
Delete Unused Rules/Layers Fewer Rules = Faster Performance

40 Policy performance ICAP Best Practices
Make use of delete_on_abandonment(yes) Minimize Queued Requests Verify Current Connections < Max Connections ip>:8082/OPP/Statistics Refer to ntegration.pdf

41 Troubleshooting Policy

42 Policy troubleshooting
Topics Policy Tracing Policy Coverage Statistics

43 Policy troubleshooting
Policy Tracing Logs what decisions are made on a session Can only trace intercepted sessions CPU intensive

44 Policy troubleshooting
Enable Global Tracing Configuration -> Policy -> Policy Options Enabling default policy tracing is not recommended in production!

45 Policy troubleshooting
Policy Tracing Create Web Access Layer Action is None Track Object Contains Trace

46 Policy troubleshooting
View Traces Located at ip>:8082/policy

47 Policy troubleshooting
Trace Output start transaction CPL Evaluation Trace: transaction ID=826812 transaction type: qualifier-index=1 name=http service=SG-HTTP-Service module=HTTP ... <Proxy> condition=!__is_notify_internal MATCH: DENY url.domain=//cnn.com/ <ssl> condition=!__is_notify_internal miss : url.domain=//gmail.com/ miss : server.connection.negotiated_cipher=AES128-SHA MATCH: client.address= trace.request(yes) trace.rules(all) trace.destination(my_trace.html) Highlight shows identification for the start of a transaction.

48 Policy troubleshooting
Trace Output start transaction CPL Evaluation Trace: transaction ID=826812 transaction type: qualifier-index=1 name=http service=SG-HTTP-Service module=HTTP ... <Proxy> condition=!__is_notify_internal MATCH: DENY url.domain=//cnn.com/ <ssl> condition=!__is_notify_internal miss : url.domain=//gmail.com/ miss : server.connection.negotiated_cipher=AES128-SHA MATCH: client.address= trace.request(yes) trace.rules(all) trace.destination(my_trace.html) Highlight shows the layers the transaction went through.

49 Policy troubleshooting
Trace Output start transaction CPL Evaluation Trace: transaction ID=826812 transaction type: qualifier-index=1 name=http service=SG-HTTP-Service module=HTTP ... <Proxy> condition=!__is_notify_internal MATCH: DENY url.domain=//cnn.com/ <ssl> condition=!__is_notify_internal miss : url.domain=//gmail.com/ miss : server.connection.negotiated_cipher=AES128-SHA MATCH: client.address= trace.request(yes) trace.rules(all) trace.destination(my_trace.html) Highlight shows the matching rule in each layer the transaction passed through.

50 Policy troubleshooting
Trace Output ... user: unauthenticated authentication status='not_attempted' authorization status='not_attempted‘ DENIED: Either 'deny' or 'exception' was matched in policy server.response.code: 200 client.response.code: 403 application.name: CNN application.operation: none DSCP client outbound: 65 DSCP server outbound: 65 Transaction timing: total-transaction-time 125 ms Checkpoint timings: stop transaction Highlight shows the transaction’s user authentication results.

51 Policy troubleshooting
Trace Output ... user: unauthenticated authentication status='not_attempted' authorization status='not_attempted‘ DENIED: Either 'deny' or 'exception' was matched in policy server.response.code: 200 client.response.code: 403 application.name: CNN application.operation: none DSCP client outbound: 65 DSCP server outbound: 65 Transaction timing: total-transaction-time 125 ms Checkpoint timings: stop transaction Highlight shows the final result of the transaction.

52 Policy troubleshooting
Trace Output ... user: unauthenticated authentication status='not_attempted' authorization status='not_attempted‘ DENIED: Either 'deny' or 'exception' was matched in policy server.response.code: 200 client.response.code: 403 application.name: CNN application.operation: none DSCP client outbound: 65 DSCP server outbound: 65 Transaction timing: total-transaction-time 125 ms Checkpoint timings: stop transaction Highlight shows the response code, application, and QoS tags for the transaction.

53 Policy troubleshooting
Trace Output ... user: unauthenticated authentication status='not_attempted' authorization status='not_attempted‘ DENIED: Either 'deny' or 'exception' was matched in policy server.response.code: 200 client.response.code: 403 application.name: CNN application.operation: none DSCP client outbound: 65 DSCP server outbound: 65 Transaction timing: total-transaction-time 125 ms Checkpoint timings: stop transaction Highlight shows the total time to complete the transaction.

54 Policy troubleshooting
Trace Output ... Transaction timing: total-transaction-time 108 ms Checkpoint timings: new-connection: start 1 elapsed 0 ms client-in: start 1 elapsed 0 ms scan-request-completed: start 1 elapsed 0 ms server-out: start 1 elapsed 0 ms server-in: start 107 elapsed 0 ms client-out: start 107 elapsed 0 ms access-logging: start 108 elapsed 0 ms stop-transaction: start 108 elapsed 0 ms Total Policy evaluation time: 0 ms stop transaction Highlight shows the end of the transaction marker.

55 Policy troubleshooting
Trace Output ... Transaction timing: total-transaction-time 108 ms url_categorization not completed server connection: start 1 DNS Lookup: start 1 elapsed 66 ms server connection: connected 86 first-byte 107 last_byte 108 client connection: first-response-byte 108 last-response-byte 108 Total time added: 0 ms Total latency to first byte: 86 ms Request latency: 0 ms OCS connect time: 85 ms Response latency (first byte): 1 ms Response latency (last byte): 0 ms stop transaction Highlight shows the end of the transaction marker.

56 Policy troubleshooting
Trace Output ... user: unauthenticated authentication status='not_attempted' authorization status='not_attempted‘ DENIED: Either 'deny' or 'exception' was matched in policy server.response.code: 200 client.response.code: 403 application.name: CNN application.operation: none DSCP client outbound: 65 DSCP server outbound: 65 Transaction timing: total-transaction-time 125 ms Checkpoint timings: stop transaction Highlight shows the end of the transaction marker.

57 Policy troubleshooting
Additional Resources: Policy Tracing licytracetodebugaccessissues Checkpoint Timing

58 Policy troubleshooting
Policy Coverage Statistics Located at ip>:8082/Policy/Coverage Statistics -> Advanced -> Policy -> Policy Coverage Statistics Reset every time policy is pushed Only reports rule matches, not specific objects in a list

59 Policy troubleshooting
Policy Coverage Output ... 40: <Proxy> condition=!__is_notify_internal (40) 1: DENY url.domain=//cnn.com/ (1) 39: ALLOW : <ssl-intercept> 0: category="Financial Services" (0) ssl.forward_proxy(no) 37: ssl.forward_proxy(https) Discuss what each item means: The number is the count (number of times that policy object/rule has been matched). There are lines for each rule and layer. Objects and layer guards also have a coverage count in parenthesis.

60 Policy troubleshooting
SSL Troubleshooting Policy Trace Check Browser Warnings Verify Encryption Browsers Sunsetting Weak Encryption (AES-128 and weaker) One or more certificates in the ProxySG chain aren’t strong enough Solution: Certificates in the chain should be AES-256 or stronger Example ProxySG SSL Error Certificate Hostname Mismatch DNS and Certificate CN don’t match Solution: Align the URL/DNS/CN information on OCS Workaround: Add an Ignore Hostname Mismatch rule for the site Highlight a few of the more common errors seen with SSL and explain why these errors are seen and ways to address the underlying issue (or work around it, if the optimal solution cannot be implemented).

61 Additional resources SSL Deployment Guide ICAP Best Practices
oyment_Guide_6.5_later.pdf ICAP Best Practices egration.pdf Policy Self-Help

62 Blue Coat Customer Forums
Community where you can learn from and share your valuable knowledge and experience with other Blue Coat customers Research, post and reply to topics relevant to you at your own convenience Blue Coat Moderator Team ready to offer guidance, answer questions, and help get you on the right track Access at forums.bluecoat.com and register for an account today!

63 More technical training available
Practical Knowledge sessions on ProxySG Policy Optimization are scheduled September 21-25 WebEx based, complimentary training for Blue Coat customers Login to BTO to sign up Link to sign up in the follow-up you will receive following this webcast Join Blue Coat senior technical instructor Keith Chomentowski for a more in-depth discussion on: Policy Framework and Best Practice Layer and rule ordering Security best practice policy  HTTPS/SSL Policy Explicit vs. Transparent mode SSL Intercept Layer Policy SSL Access Layer Policy  Policy Trace and Policy Statistics Setup, analyze, explain trace components Policy Coverage stats, Reference/Policy ID

64 Thank you for Joining Today!
Please provide feedback on this webcast and suggestions for future webcasts to: Webcast replay and slide deck found here: er-support-technical-webcasts (requires BTO login)

65 **Submit using Webex Q/A**
Questions? **Submit using Webex Q/A**

66


Download ppt "Proxysg policy optimization and troubleshooting"

Similar presentations


Ads by Google