Skip navigation
McAfee Secure sites help keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams
1052 Views 10 Replies Latest reply: Jul 23, 2013 9:52 PM by btlyric RSS 1 2 Previous Next
btlyric Apprentice 184 posts since
Aug 1, 2012
Currently Being Moderated

Jul 8, 2013 8:21 PM

Expected Rule Traversal When Stop Cycle Invoked

If you have a rule in Global that invokes Stop Cycle, what cycles should you expect to see in Rule Tracing?

 

Asking because I have seen two different incarnations from the same source IP.

 

1) Request, Logging

2) Request, Response, Logging

 

In the case of #2, even though rule tracing stated that the Stop Cycle rule had been invoked, it then logged the full URL for the transaction. There was also, in one case, a 10 second delay between when Response cycle finished and Logging cycle started. In case #1, system logged the https://<URL.Host> and nothing additional.

 

Restarting the MWG services changed poorly performing #2 into decently performing #1.

 

Any ideas?

  • Jon Scholten McAfee SME 857 posts since
    Nov 3, 2009
    Currently Being Moderated
    1. Jul 9, 2013 12:30 PM (in response to btlyric)
    Re: Expected Rule Traversal When Stop Cycle Invoked

    Hi bylyric,

     

    When testing with HTTPS you may see results which may not be completley understood. I would recommend testing with HTTP to start and then deviating from there.

     

    With HTTPS there will be one trace purley for the SSL connection establishment (CONNECT and CERTVERIFY), and another for the transactions in the tunnel. This is why you may have varying results as new connections will be established and you will get new files etc...

     

    The SSL connection establishment will only show Request based cycles. Where as the tunnel will show request, response and whatever else.

     

    Best,

    Jon

  • Jon Scholten McAfee SME 857 posts since
    Nov 3, 2009
    Currently Being Moderated
    3. Jul 9, 2013 5:06 PM (in response to btlyric)
    Re: Expected Rule Traversal When Stop Cycle Invoked

    Hi btlyric,

     

    This assumes you have correctly stopped the cycle ;-)

     

    In transparent setups etc.. there are situations where you may think you are whitelisting something, but it might not actually be working.

     

    But to answer your question, if there is a stop cycle, then you should see no more rules executed after the action takes place. As for SSL there should not be a tunneled connection if the "SSL connection establishment" has taken place.

     

    Best,

    Jon

  • Jon Scholten McAfee SME 857 posts since
    Nov 3, 2009

    Please let me know if you feel like I am off track from your original concern but I think it may be related.

     

    Here is an example of what I mean.

     

    Rule trace of SSL connection establishment. You will see that the Command.Name in the top properties is CONNECT. The shown cycles are Request and Request 2. In "Request" the command name is CONNECT. In "Request 2" the Command.Name is "CERTVERIFY".

     

    retrace1_0_2013-07-09_171358.png retrace1_1cycles_2013-07-09_171358.png retrace1_2connect_2013-07-09_171358.png retrace1_3certverify_2013-07-09_171358.png

     

    In the rule trace in the tunnel, you see that the path information is included (in my case it was simply "/"), and the Command.Name is GET.

     

    retrace2_2013-07-09_171424.png

     

    Let me know if this helps,

     

    Best,

    Jon

  • Jon Scholten McAfee SME 857 posts since
    Nov 3, 2009

    This is what it would look like if I used stop cycle:

     

    retrace3_globalwhitelist_2013-07-09_172313.png

  • Jon Scholten McAfee SME 857 posts since
    Nov 3, 2009
    Currently Being Moderated
    7. Jul 10, 2013 10:45 AM (in response to btlyric)
    Re: Expected Rule Traversal When Stop Cycle Invoked

    Some context is still missing. The example above is the rule trace inside the tunnel (Command.Name equals GET). The above does not show the SSL connection establishment (Command.Name equals CONNECT).

     

    Just because you execute a Stop Cycle, does not mean the next cycle will not take place. It just means the following rules in the current cycle will not be executed.

     

    So if you Cycle in the Request Cycle, it stops processing further rules IN the request cycle. For the example above, the Response cycle will still be processed if you have a stop cycle in the Request cycle.

     

    Is it your goal to bypass SSL scanning for a particular URL? That's what I think you are trying to do.

     

    Please show me the rule trace from the SSL connection establishment, and post the values of URL.Host and URL.Destination.IP.

     

    Best,

    Jon

  • asabban McAfee SME 1,354 posts since
    Nov 3, 2009
    Currently Being Moderated
    9. Jul 23, 2013 2:58 AM (in response to btlyric)
    Re: Expected Rule Traversal When Stop Cycle Invoked

    Hello,

     

    while I completely understand the wish to "tweak" the mentioned settings to obtain a maximum performance I always recommend to not touch any of the settings mentioned. The default values have been defined after long discussions, lab tests and analysis and usually there is really no noticable benefit when changing those settings. On the other hand this could lead to various unforeseen issues and support and engineering will have a very hard time in troubleshooting.

     

    In case there is a reason such as performance issues that cause you to look into those settings the issues should be tracked by support and changes should only be applied in case engineering/support advises to do so. Especially the working threads may seem low but the setting works for some of the largest installations I am aware of.

     

    Actually MWG has a "no hidden settings" philosophy which causes many settings to show up in the UI which you usually don't want to touch... As mentioned I can fully understand the intention to understand and change the defaults, but as someone who has supported the product for a couple of years I can assure that most "improvements" I have seen done by customers in regards to timeouts or memory stack sizes had a negative impact :-)

     

    For finding the best values I unfortunately don't know a best practice. From our end what we do is measure the "maximum throughput", e.g. how many requests can flow through MWG before we start noticing delays or seeing errors. That is rather hard to simulate, on our end it is simulated with "lab traffic", so the settings are optimized in that fashion. "Tweaking" for my understanding would mean that you adjust the settings to get the best performance for the very unique profile of traffic genrated by the users in your company. This would mean you need to capture "typical" traffic for a while and get an idea of what is special for your company. You need details such as

     

    - how many requests do I see? what kind of requests? (GET, POST)

    - sizes of requests/responses

    - HTTP/HTTPS

    - what media types go through and how much of the traffic is for a specific media type? (jpg, gif, png, css, js, html, exe, ...)

    - ratio of HTTP 1.0/1.1

    - probably also include different clients and their special behaviour (e.g. maximum concurrent connections per second, window sizes, ...)

    - what kinds of websites are called? (complex websites causing browsers to create multiple TCP connections, simple websites with few objects)

    - what about persistent connections, caused by applications such as Office365, Google Docs, ...

    - big uploads/downloads, "web storage" (cloud storage, dropbox, skydrive...)

    - all the "non-HTTP" traffic that is probably somehow tunneled through MWG by non-browser applications

    - updates such as windows updates, adobe updates, AV updates (how often, how much traffic, how many clients, ...)

    - FTP?

    - how much of the traffic is blocked by your MWG policies (in request cycle (= no communication to server), in response cycle (= communication to server but only error page for client)

    - additionally other devices can influence how the data flows, such as firewalls, other involved proxies, transparent solutions such as DLPs or IDSs

    - DNS performance

     

    And probably many more (I am not a QA/Performance person)... what I want to express is that it would be a very tough challenge to optimize MWG especially for your company profile and therefore living with the defaults should be suitable. Apart from that you can only change a setting and see if something changes for the users OR find a way to simulate your companies traffic as detailled as possible and measure the performance. Then change settings, measure performance again, and so on.

     

    While I am aware that I did not answer the question I hope it makes some sense :-)

     

    Best,

    Andre

1 2 Previous Next

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 5 points
  • Helpful Answers - 3 points